From tjarvi at qbang.org  Thu Jun  1 11:13:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 11:13:40 -0600 (MDT)
Subject: [Rxtx] custom baud rate win32
In-Reply-To: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606011107210.30220@www>


Hi Daren

I can't imagine that 1953 is possibly the actual value on the UART.  Maybe 
if your baud base is very high with a custom serial board.  More likely, 
the driver just remembers that what you asked for and did something else.

I'll have more to say on the dcb->BaudRate after I try some things here. 
I have managed to do something like that in the past as a quick hack but 
it was for 14400.  I may have used the CBR_14400.

If we can't access this through the win32 API with protected mode, there 
is another layer of complication.  With real mode, it would be easy.
With protected mode, I assume there would have to be some kernel driver or 
a hook I'm not aware of to access the MCR directly (bang a memory 
addresss).



On Thu, 1 Jun 2006, Daren wrote:

> Trent,
> I have managed to successfully open the port at this speed using Realterm
> (available on sourceforge). From memory this uses DLPortIO.
>
> Using portmon.exe with realterm, even there it says that the port has opened
> at 1953.
>
> I changed termios.c:560 to
> dcb->BaudRate        = 1953 ;
>
> and it still opens the port at 9600.
>
> Daren
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Trent Jarvi
> Sent: Thursday, 1 June 2006 1:44 PM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] custom baud rate win32
>
> On Thu, 1 Jun 2006, Daren wrote:
>
>> Hi all,
>>
>> I downloaded 2.1.7-pre16 and managed to build it and get it going. I made
>> the changes as suggested by Peter Smith in an old post, by adding his code
>> to SerialImpl.c, uncommenting the TIOCGSERIAL and TIOCSSERIAL, and
> defining
>> ASYNC_SPD_CUST which is equal to 0x0030 (according to linus header
> files)..
>>
>>
>> Still not working, it opens the port at 9600 according to portmon.exe .
> Has
>> anyone managed to get this going at a custom rate?
>>
>> Here is the post I'm referring to:
>> http://marc.theaimsgroup.com/?l=rxtx&m=106270038110713&w=2
>>
>>
>> Thanks,
>> Daren
>>
>> ________________________________________
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
>> Daren
>> Sent: Wednesday, 31 May 2006 10:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] (no subject)
>>
>> Hi All,
>> I have been using rxtx for a little while and needed to get it working at
>> 1953, like a past user in the mailing list, who seemed to have got it
>> working by changing some C code.
>>
>> I wanted to build rxtx myself with these changes but don't know where to
>> start. I have windows here and FC4 at home. I downloaded cygwin and
> mingw32,
>> each build works by building a rxtxSerial.dll file that is ~11k smaller
> than
>> the original, and I always get the following error when testing the dll:
>>
>> Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at
>> PC=0x8077655
>> Function=[Unknown.]
>> Library=C:\opt\java\j2sdk1.4.2\jre\bin\client\jvm.dll
>>
>> NOTE: We are unable to locate the function name symbol for the error
>>      just occurred. Please refer to release documentation for possible
>>      reason and solutions.
>>
>>
>> Current Java thread:
>> 	at gnu.io.RXTXPort.open(Native Method)
>> 	- locked <0x1002c800> (a gnu.io.RXTXPort)
>> 	at gnu.io.RXTXPort.<init>(RXTXPort.java:84)
>>
>> Anyone know what im doing wrong?
>>
>>
>>
>>
>
> Hi Daren
>
> You are running into the same rats nest I'm looking at now.
>
> With win32 and specific custom baud rates, I'm not sure how this will go.
> I've got the Linux custom baud rates working very nicely.  I did much like
> the post you linked.  In fact I had forgot about that post.  You probably
> noticed that it becomes a bunch of dirt roads going noplace fast in
> termios.c for w32.
>
> I'm probably only going to get 14400, 28800, 128000 and 256000 working
> with the next release on w32.  I'll look a little further.  If you have an
> example w32 that works at 1953 I'd really like to hear.  Thats an unusual
> baud rate.
>
> Assuming a baud_base of 128000, your divisor will be 65 or 66.
>
> 128000/66=1939 -14
> 128000/65=1969 +13
>
> One thing I've been wondering about with linux is which would be the right
> answer in cases like this.  Right now it would just go with a baud base of
> 65 and ignore the modulus details.
>
> It appears to be a general trend for kernel developers to hide these
> details thinking that they can come up with a general solution.  Then they
> run out of time.  Perahps the solution is to help out but there are
> ultiple OS's rxtx supports making that nontrivial.
>
> If you look at current linux kernels, the 'tricks' above have been marked
> deprecated with no replacement.  Windows has some hard defines and then
> ancient near magic.  I've not looked at Solaris via Open Solaris yet but
> doubt there is a solution at all.
>
> What I'd try since you have the equipment and the monitor software is to
> hardcode the dcb->Baud in termios.c to 1953 (no define) and see what the
> w32 kernel does with it.  I think if you toss a baud rate at the driver it
> will try to come close.  You may try comming closer to a real baudrate
> based upon the 128000 baud base as shown above.
>
> If it works, it is worth looking at the rest of the ping/pong logic then.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
>
>
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From doug at dupreeinc.com  Thu Jun  1 13:22:13 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 12:22:13 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011107210.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
Message-ID: <447F3E65.1020809@dupreeinc.com>

Hello,

I am still trying to get this startup a little faster so I turned on the 
debug of a few of the classes.  The COM ports are scanned really fast 
and the delay occurs during the LPT scan.  The console output looks like 
this:

    ...
      LPT1
      LPT2
      LPT3
     valid port prefixes:
      LPT
    LPT1 LPT
    1 1
    LPT2 LPT
    2 2                                                                 
      * <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
    CommPortIdentifier:addPortName(LPT2)
    CommPortIdentifier:AddIdentifierToList()
    LPT3 LPT
    3 3
    CommPortIdentifier:addPortName(LPT3)
    CommPortIdentifier:AddIdentifierToList()
    CommPortIdentifier:AddIdentifierToList() index.next
    Leaving registerValidPorts()
    Have not implemented native_psmisc_report_owner(PortName)); in
    CommPortIdentifier
    CommPortIdentifier:getPortIdentifier(COM3)
    CommPortIdentifier:open(densConnect, 30000)
    RXTXCommDriver:getCommPort(COM3,1)
    ...

It would seem to me that if I removed the code for port scanning of LPT 
ports I could solve this problem. I would much prefer to use unmodified 
code if at all possible.  Do any of you have alternate suggestions?

Thank you for your time.

Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/cf433ee7/attachment-0005.html

From tjarvi at qbang.org  Thu Jun  1 13:52:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 13:52:06 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F3E65.1020809@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011348380.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I am still trying to get this startup a little faster so I turned on the 
> debug of a few of the classes.  The COM ports are scanned really fast and the 
> delay occurs during the LPT scan.  The console output looks like this:
>
>   ...
>     LPT1
>     LPT2
>     LPT3
>    valid port prefixes:
>     LPT
>   LPT1 LPT
>   1 1
>   LPT2 LPT
>   2 2                                                                      * 
> <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>   CommPortIdentifier:addPortName(LPT2)
>   CommPortIdentifier:AddIdentifierToList()
>   LPT3 LPT
>   3 3
>   CommPortIdentifier:addPortName(LPT3)
>   CommPortIdentifier:AddIdentifierToList()
>   CommPortIdentifier:AddIdentifierToList() index.next
>   Leaving registerValidPorts()
>   Have not implemented native_psmisc_report_owner(PortName)); in
>   CommPortIdentifier
>   CommPortIdentifier:getPortIdentifier(COM3)
>   CommPortIdentifier:open(densConnect, 30000)
>   RXTXCommDriver:getCommPort(COM3,1)
>   ...
>
> It would seem to me that if I removed the code for port scanning of LPT ports 
> I could solve this problem. I would much prefer to use unmodified code if at 
> all possible.  Do any of you have alternate suggestions?
>
> Thank you for your time.
>
> Doug
>


Does commenting out the LPT enumeration actually help?  There can often be 
differences between debug information printed and whats really going on. 
When you combine various environments the debug info can even come out in 
the wrong order.

I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
I do not think this problem is universal.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Thu Jun  1 14:29:44 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:29:44 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4E38.2060004@dupreeinc.com>

I will give it a try.  One thing to note on this PC is it has no LPT 
Parallel ports.

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
>>Hello,
>>
>>I am still trying to get this startup a little faster so I turned on the 
>>debug of a few of the classes.  The COM ports are scanned really fast and the 
>>delay occurs during the LPT scan.  The console output looks like this:
>>
>>  ...
>>    LPT1
>>    LPT2
>>    LPT3
>>   valid port prefixes:
>>    LPT
>>  LPT1 LPT
>>  1 1
>>  LPT2 LPT
>>  2 2                                                                      * 
>><<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>>  CommPortIdentifier:addPortName(LPT2)
>>  CommPortIdentifier:AddIdentifierToList()
>>  LPT3 LPT
>>  3 3
>>  CommPortIdentifier:addPortName(LPT3)
>>  CommPortIdentifier:AddIdentifierToList()
>>  CommPortIdentifier:AddIdentifierToList() index.next
>>  Leaving registerValidPorts()
>>  Have not implemented native_psmisc_report_owner(PortName)); in
>>  CommPortIdentifier
>>  CommPortIdentifier:getPortIdentifier(COM3)
>>  CommPortIdentifier:open(densConnect, 30000)
>>  RXTXCommDriver:getCommPort(COM3,1)
>>  ...
>>
>>It would seem to me that if I removed the code for port scanning of LPT ports 
>>I could solve this problem. I would much prefer to use unmodified code if at 
>>all possible.  Do any of you have alternate suggestions?
>>
>>Thank you for your time.
>>
>>Doug
>>
>>    
>>
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/dd31fed5/attachment-0005.html

From doug at dupreeinc.com  Thu Jun  1 14:36:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:36:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4FC8.9080106@dupreeinc.com>

Trent,

I commented out the section in RegisterScannedPorts() that adds the 
three LPT ports to the CandidateDeviceNames string array.  The 
application started immediately.  This is probably not the way to do 
this, but it was quick ,dirty, and worked.

It would be nice if there was a way to pole the OS to see if there is 
even a port there, though I guess this is what this code is suppose to do...

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
> ...
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From lynn at swcp.com  Thu Jun  1 14:49:34 2006
From: lynn at swcp.com (lynn@swcp.com)
Date: Thu, 1 Jun 2006 20:49:34 -0000
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>,
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <twig.1149194974.97617@swcp.com>

Perhaps we could add an argument to port enumeration where if not specified,
you get the default behavior that looks for everything.  With a new
constructor that has an argument(or more) you could optionally declare it to
not inspect printer ports.

Existing code would work as it always has.  New code could be smarter.

Lynn



Doug Thistlethwaite <doug at dupreeinc.com> said:

> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
> >On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
> >
> >  
> >
> > ...
> >
> >
> >Does commenting out the LPT enumeration actually help?  There can often be 
> >differences between debug information printed and whats really going on. 
> >When you combine various environments the debug info can even come out in 
> >the wrong order.
> >
> >I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
> >I do not think this problem is universal.
> >
> >--
> >Trent Jarvi
> >tjarvi at qbang.org
> >_______________________________________________
> >Rxtx mailing list
> >Rxtx at qbang.org
> >http://mailman.qbang.org/mailman/listinfo/rxtx
> >
> >
> >  
> >
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



-- 





From jredman at ergotech.com  Thu Jun  1 15:20:20 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 01 Jun 2006 15:20:20 -0600
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
Message-ID: <447F5A14.6010803@ergotech.com>

Doug,

If you specifically request ports, eg:

-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

or
 
-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

Depending upon the version  (Windows is COM1:COM2, etc. I assume).

Does it still enumerate the parallel ports?

Jim

Doug Thistlethwaite wrote:
> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
>> On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>
>>  
>>
>> ...
>>
>>
>> Does commenting out the LPT enumeration actually help?  There can often be 
>> differences between debug information printed and whats really going on. 
>> When you combine various environments the debug info can even come out in 
>> the wrong order.
>>
>> I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>> I do not think this problem is universal.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>>
>>  
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  1 16:49:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:49:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6EF4.7080709@dupreeinc.com>

I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
folder.  I created this file and added the following to the file:

gnu.io.rxtx.SerialPorts=COM3

and I get the following error on the console:
CommPortIdentifier:static initialization()
RXTXCommDriver {}
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
RXTXCommDriver:
    Jar version = RXTX-2.1-7
    native lib Version = RXTX-2.1-7
RXTXCommDriver:initialize()
checking for system-known ports of type 1
checking registry for ports of type 1

RXTXCommDriver:addSpecifiedPorts()
Exception in thread "main" java.lang.ExceptionInInitializerError
    at 
densconnect.SerialConnection.openConnection(SerialConnection.java:136)
    at densconnect.DensTalk.<init>(DensTalk.java:165)
    at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
    at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
    at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
    at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
Caused by: java.lang.NullPointerException
    at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
CommPortIdentifier:addPortName(COM3)
CommPortIdentifier:AddIdentifierToList()
CommPortIdentifier:AddIdentifierToList() null
...


It looks like it  read COM3 from the file, but it had the above 
exception that killed it.  The strange this is this error is from 
RXTXCommDriver initialize function (if statement line):

        OS = System.getProperty("os.name");
                System.out.println("OS NAME: " + OS);
        if(OS.toLowerCase().indexOf("linux") == -1)

OS is returning null, thus the error.

If the file is not present, it scans the ports and reads the OS.

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>Doug Thistlethwaite wrote:
>  
>
>>Trent,
>>
>>I commented out the section in RegisterScannedPorts() that adds the 
>>three LPT ports to the CandidateDeviceNames string array.  The 
>>application started immediately.  This is probably not the way to do 
>>this, but it was quick ,dirty, and worked.
>>
>>It would be nice if there was a way to pole the OS to see if there is 
>>even a port there, though I guess this is what this code is suppose to do...
>>
>>Doug
>>
>>Trent Jarvi wrote:
>>
>>    
>>
>>>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>>
>>> 
>>>
>>>...
>>>
>>>
>>>Does commenting out the LPT enumeration actually help?  There can often be 
>>>differences between debug information printed and whats really going on. 
>>>When you combine various environments the debug info can even come out in 
>>>the wrong order.
>>>
>>>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>>>I do not think this problem is universal.
>>>
>>>--
>>>Trent Jarvi
>>>tjarvi at qbang.org
>>>_______________________________________________
>>>Rxtx mailing list
>>>Rxtx at qbang.org
>>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>>
>>>
>>> 
>>>
>>>      
>>>
>>_______________________________________________
>>Rxtx mailing list
>>Rxtx at qbang.org
>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>    
>>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/bf4cca0e/attachment-0005.html

From doug at dupreeinc.com  Thu Jun  1 16:51:26 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:51:26 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6F6E.5060603@dupreeinc.com>

Jim,

I did not try your suggestion as I do not understand where I would put 
these command line parameters (it that is what they are).  It appears 
that using the properties file should do that same thing...

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>
>  
>


From doug at dupreeinc.com  Thu Jun  1 17:56:19 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 16:56:19 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
Message-ID: <447F7EA3.6050400@dupreeinc.com>

I think there is an error in the registerSpecifiedPorts() method.  When 
I have a gnu.io.rxtx.properties file in the ext directory, this function 
kills the System class  IF I call System.getProperty("os.name") before 
the call  to registerSpecifiedPorts(), it returns the os name, after the 
call, it returns null.  I have not played much with properties, except 
for reading them, so I don't really understand the code.

Doug



From doug at dupreeinc.com  Thu Jun  1 18:11:14 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 17:11:14 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F7EA3.6050400@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com>
Message-ID: <447F8222.3060402@dupreeinc.com>

Ok, I just hacked this thing up and got it to read the 
gnu.io.rxtx.properties file.

I commented out the line:
System.setProperties(p); in the method registerSpecifiedPorts() in 
RXTXCommDriver class.  I really don't understand that much about 
properties, but this call kills the System class.

I used the following in the gnu.io.rxtx.properties file:

gnu.io.rxtx.SerialPorts=COM3
gnu.io.rxtx.ParallelPorts=null

This allows the application to open very quickly without any errors.  
Whomever coded this class or somebody who understands properties should 
look at this method and make sure it is doing what they expect.

Doug




Doug Thistlethwaite wrote:

>I think there is an error in the registerSpecifiedPorts() method.  When 
>I have a gnu.io.rxtx.properties file in the ext directory, this function 
>kills the System class  IF I call System.getProperty("os.name") before 
>the call  to registerSpecifiedPorts(), it returns the os name, after the 
>call, it returns null.  I have not played much with properties, except 
>for reading them, so I don't really understand the code.
>
>Doug
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From tjarvi at qbang.org  Thu Jun  1 18:32:50 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 18:32:50 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F6EF4.7080709@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com> <447F6EF4.7080709@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011831510.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
> folder.  I created this file and added the following to the file:
>
> gnu.io.rxtx.SerialPorts=COM3
>
> and I get the following error on the console:
> CommPortIdentifier:static initialization()
> RXTXCommDriver {}
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
> RXTXCommDriver:
>   Jar version = RXTX-2.1-7
>   native lib Version = RXTX-2.1-7
> RXTXCommDriver:initialize()
> checking for system-known ports of type 1
> checking registry for ports of type 1
>
> RXTXCommDriver:addSpecifiedPorts()
> Exception in thread "main" java.lang.ExceptionInInitializerError
>   at densconnect.SerialConnection.openConnection(SerialConnection.java:136)
>   at densconnect.DensTalk.<init>(DensTalk.java:165)
>   at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
>   at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
>   at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
>   at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
> Caused by: java.lang.NullPointerException
>   at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
> CommPortIdentifier:addPortName(COM3)
> CommPortIdentifier:AddIdentifierToList()
> CommPortIdentifier:AddIdentifierToList() null
> ...
>
>

There is a solution for this bug.

http://bugzilla.qbang.org/show_bug.cgi?id=54

We have been horribly slow at getting the next round of patches in but 
they are comming.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  2 00:58:02 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 08:58:02 +0200
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F8222.3060402@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
Message-ID: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>

Hi Doug,

you wrote in an earlier message, that you would prefer an unchanged  
version. What about simply removing the RXTX parallel lib from the  
ext directory. This does not fix the bug, but it should fix your  
problem.

In general I think it is not a good idea to put the RXTX files in a  
system wide location. Putting the libs in the application folder and  
including the .jar in the application classpath (or application jar)  
is all that is required.

Regards,
Joachim

On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:

> Ok, I just hacked this thing up and got it to read the
> gnu.io.rxtx.properties file.
>
> I commented out the line:
> System.setProperties(p); in the method registerSpecifiedPorts() in
> RXTXCommDriver class.  I really don't understand that much about
> properties, but this call kills the System class.
>
> I used the following in the gnu.io.rxtx.properties file:
>
> gnu.io.rxtx.SerialPorts=COM3
> gnu.io.rxtx.ParallelPorts=null
>
> This allows the application to open very quickly without any errors.
> Whomever coded this class or somebody who understands properties  
> should
> look at this method and make sure it is doing what they expect.
>
> Doug
>
>
>
>
> Doug Thistlethwaite wrote:
>
>> I think there is an error in the registerSpecifiedPorts() method.   
>> When
>> I have a gnu.io.rxtx.properties file in the ext directory, this  
>> function
>> kills the System class  IF I call System.getProperty("os.name")  
>> before
>> the call  to registerSpecifiedPorts(), it returns the os name,  
>> after the
>> call, it returns null.  I have not played much with properties,  
>> except
>> for reading them, so I don't really understand the code.
>>
>> 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 antonio.luis at iscte.pt  Fri Jun  2 02:42:28 2006
From: antonio.luis at iscte.pt (=?ISO-8859-1?Q?Ant=F3nio_Lopes?=)
Date: Fri, 02 Jun 2006 09:42:28 +0100
Subject: [Rxtx] Exception when closing serial port
Message-ID: <447FF9F4.7060209@iscte.pt>

Hello everyone,
I've been using RXTX in a Java application in my Pocket PC.
The communication through the (bluetooth) serial port is working perfectly.

However, when I disconnect the app and close the serial port, sometimes I get 
the following error:

"1149237595000: RXTXPort:close detected bad File Descriptor"

The problem is that after this error occurs, the app is no longer able to 
connect to the serial port and I have to soft-reset the device in order to be 
able to connect to it again.

Any ideas on how to solve this issue?

Any help is appreciated.
Thanks,
regards,
-- 
Ant?nio Lopes

@contact: antonio.luis at iscte.pt
@work: ADETTI - ISCTE
@web: http://antonio.lopes.googlepages.com


From paul.klissner at sun.com  Fri Jun  2 02:44:34 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 01:44:34 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to RXTX
	again
Message-ID: <447FFA72.6040807@sun.com>

After looking into javax.comm 3.1 and what it would take to re-engineer it
to be compatible with RXTX platform libraries, I've decided, due my group's
priorities, complexity of the effort vs. benefit, and limited resources, 
to re-post
javax.comm 2.0 binaries on Sun's software download server, unsupported,
with disclaimers, as it was previously.

I don't think there will be any snags doing this from the standpoint of Sun
management or legality.  I will try to have it  posted there in the next 
week
or two, depending on how fast we can get it pushed through the process.

I'd like to think of this as a stop gap measure... ie. a compromise, 
where, at some
point in the not too distant future RXTX implements their own version of the
Java side of the API, as is normally done by javax.extension porters. 
That way
we avoid uncomfortable dependencies in the future.  And that really is 
the Java
development model.

Since RXTX already has the back-end code, porting the java code shouldn't
be a gargantuan effort at all, and RXTX will be in full control of the 
code top
to bottom. I think RXTX can do at least as good a job as the original 
coder.
Prepping 2.0 to be open sourced is more trouble than it is worth. ie. I 
don't
think the current implementation warrants it.

Ultimately, it would be nice to see someone open up a JSR and re-architect
the comm. API to overcome some of it's current design flaws (ie. be more
adaptable to modern platforms, more pluggable, better defined SPI, better
port ownership handling, etc...). A superior architecture would allow for
better collaboration in the future and better interchangeability of 
components
among projects.

Sun's 3.1 version of javax.comm, which is Sun's currently supported version,
has changes pertaining mostly to Sun platform-specific portmapping and has
some minor additional interactions with our back end code, but generally
has little bearing on RXTX. 

Paul



From joachim at buechse.de  Fri Jun  2 04:00:19 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 12:00:19 +0200
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
	RXTX again
In-Reply-To: <447FFA72.6040807@sun.com>
References: <447FFA72.6040807@sun.com>
Message-ID: <1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>

Good day Paul!

A clean architecture with loadable drivers and reusable code would be  
very beneficial for the future, I think everybody agrees. However  
this could be several years into the future. In the meantime, there  
is a real existing problem with IO support on Java. I have the strong  
feeling that most programmers want to code against one specification  
(javax.comm) and be able to replace the underlying implementation via  
a "plugin" on platforms where the SUN implementation is not  
sufficient. RXTX could be just this plugin (reusing very close to 0%  
of the javax.comm implementation but 100% of its API).

I want to propose an API addition and implementation change that will  
take less then 2 hours of manpower to implement and create a solution  
that can bridge the years until javax.comm has been based on a new  
architecture.

Looking at the javax.comm api at http://java.sun.com/products/ 
javacomm/reference/api/index.html I would like to propose the following:

The only entry point to javax.comm is CommPortIdentifier. It has 3  
static methods plus the constructor.

1) define one additional Interface

public interface CommProvider {
    CommPortIdentifier getPortIdentifier(CommPort port);
    CommPortIdentifier getPortIdentifier(String portName);
    Enumeration getPortIdentifiers ();
}

2) add one method to CommPortIdentifier

   public static setCustomCommProvider (CommProvider);

3) change the three static methods of CommPortIdentifier to dispatch  
to the CommProvider if it is set

4) change the constructor of CommPortIdentifier to

   public CommPortIdentifier(...) {
      if (isProviderSet && this.getClass() ==  
javax.comm.CommPortIdentifier) {
          throw new RuntimeException("illegal creation of  
CommPortIndentifier, custom CommProvider is in use");
      }

5) (this is optional, but would be very nice) automatically set a  
custom CommProvider if it is found on the classpath or defined via a  
system property.


The above 1) - 4) can be implemented in less than 1hour. 5) may take  
another hour. I agree that this is not the most elegant design, but  
it would solve a lot of problems with very little effort. It would  
certainly allow RXTX to move forward. If the javax.comm API needs to  
be redesigned completely this addition will not hurt, as people will  
move to the new API anyway and javax.comm 3.0 was so far never  
included in the main distribution.

Best regards,
Joachim

On 02.06.2006, at 10:44, Paul Klissner wrote:

> After looking into javax.comm 3.1 and what it would take to re- 
> engineer it
> to be compatible with RXTX platform libraries, I've decided, due my  
> group's
> priorities, complexity of the effort vs. benefit, and limited  
> resources,
> to re-post
> javax.comm 2.0 binaries on Sun's software download server,  
> unsupported,
> with disclaimers, as it was previously.
>
> I don't think there will be any snags doing this from the  
> standpoint of Sun
> management or legality.  I will try to have it  posted there in the  
> next
> week
> or two, depending on how fast we can get it pushed through the  
> process.
>
> I'd like to think of this as a stop gap measure... ie. a compromise,
> where, at some
> point in the not too distant future RXTX implements their own  
> version of the
> Java side of the API, as is normally done by javax.extension porters.
> That way
> we avoid uncomfortable dependencies in the future.  And that really is
> the Java
> development model.
>
> Since RXTX already has the back-end code, porting the java code  
> shouldn't
> be a gargantuan effort at all, and RXTX will be in full control of the
> code top
> to bottom. I think RXTX can do at least as good a job as the original
> coder.
> Prepping 2.0 to be open sourced is more trouble than it is worth.  
> ie. I
> don't
> think the current implementation warrants it.
>
> Ultimately, it would be nice to see someone open up a JSR and re- 
> architect
> the comm. API to overcome some of it's current design flaws (ie. be  
> more
> adaptable to modern platforms, more pluggable, better defined SPI,  
> better
> port ownership handling, etc...). A superior architecture would  
> allow for
> better collaboration in the future and better interchangeability of
> components
> among projects.
>
> Sun's 3.1 version of javax.comm, which is Sun's currently supported  
> version,
> has changes pertaining mostly to Sun platform-specific portmapping  
> and has
> some minor additional interactions with our back end code, but  
> generally
> has little bearing on RXTX.
>
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Fri Jun  2 09:10:13 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Fri, 2 Jun 2006 09:10:13 -0600 (MDT)
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <447FFA72.6040807@sun.com>
References: <447FFA72.6040807@sun.com>
Message-ID: <Pine.LNX.4.61.0606020906400.15971@www>

On Fri, 2 Jun 2006, Paul Klissner wrote:

> After looking into javax.comm 3.1 and what it would take to re-engineer it
> to be compatible with RXTX platform libraries, I've decided, due my group's
> priorities, complexity of the effort vs. benefit, and limited resources,
> to re-post
> javax.comm 2.0 binaries on Sun's software download server, unsupported,
> with disclaimers, as it was previously.
>

Hi Paul

To address users' immediate needs, we can release rxtx 2.0-7 (final) to 
match the 2.0 binaries from Sun when they are offered for download.

We can discuss potential long term solutions after that.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Fri Jun  2 10:20:09 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 02 Jun 2006 09:20:09 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
	<9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
Message-ID: <44806539.8080902@dupreeinc.com>

Thanks for the suggestion, I will give it a try.

Doug

Joachim Buechse wrote:

>Hi Doug,
>
>you wrote in an earlier message, that you would prefer an unchanged  
>version. What about simply removing the RXTX parallel lib from the  
>ext directory. This does not fix the bug, but it should fix your  
>problem.
>
>In general I think it is not a good idea to put the RXTX files in a  
>system wide location. Putting the libs in the application folder and  
>including the .jar in the application classpath (or application jar)  
>is all that is required.
>
>Regards,
>Joachim
>
>On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:
>
>  
>
>>Ok, I just hacked this thing up and got it to read the
>>gnu.io.rxtx.properties file.
>>
>>I commented out the line:
>>System.setProperties(p); in the method registerSpecifiedPorts() in
>>RXTXCommDriver class.  I really don't understand that much about
>>properties, but this call kills the System class.
>>
>>I used the following in the gnu.io.rxtx.properties file:
>>
>>gnu.io.rxtx.SerialPorts=COM3
>>gnu.io.rxtx.ParallelPorts=null
>>
>>This allows the application to open very quickly without any errors.
>>Whomever coded this class or somebody who understands properties  
>>should
>>look at this method and make sure it is doing what they expect.
>>
>>Doug
>>
>>
>>
>>
>>Doug Thistlethwaite wrote:
>>
>>    
>>
>>>I think there is an error in the registerSpecifiedPorts() method.   
>>>When
>>>I have a gnu.io.rxtx.properties file in the ext directory, this  
>>>function
>>>kills the System class  IF I call System.getProperty("os.name")  
>>>before
>>>the call  to registerSpecifiedPorts(), it returns the os name,  
>>>after the
>>>call, it returns null.  I have not played much with properties,  
>>>except
>>>for reading them, so I don't really understand the code.
>>>
>>>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
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060602/c8892a46/attachment-0005.html

From paul.klissner at sun.com  Fri Jun  2 12:09:26 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 11:09:26 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
Message-ID: <44807ED6.8000903@sun.com>

Joachim Buechse wrote:
> Good day Paul!
>
> A clean architecture with loadable drivers and reusable code would be  
> very beneficial for the future, I think everybody agrees. However  
> this could be several years into the future. In the meantime, there  
> is a real existing problem with IO support on Java. I have the strong  
> feeling that most programmers want to code against one specification  
> (javax.comm) and be able to replace the underlying implementation via  
> a "plugin" on platforms where the SUN implementation is not  
> sufficient. RXTX could be just this plugin (reusing very close to 0%  
> of the javax.comm implementation but 100% of its API).
>
> I want to propose an API addition and implementation change that will  
> take less then 2 hours of manpower to implement and create a solution  
> that can bridge the years until javax.comm has been based on a new  
> architecture.
>
> Looking at the javax.comm api at http://java.sun.com/products/ 
> javacomm/reference/api/index.html I would like to propose the following:
>
> The only entry point to javax.comm is CommPortIdentifier. It has 3  
> static methods plus the constructor.
>
> 1) define one additional Interface
>
> public interface CommProvider {
>     CommPortIdentifier getPortIdentifier(CommPort port);
>     CommPortIdentifier getPortIdentifier(String portName);
>     Enumeration getPortIdentifiers ();
> }
>
> 2) add one method to CommPortIdentifier
>
>    public static setCustomCommProvider (CommProvider);
>
> 3) change the three static methods of CommPortIdentifier to dispatch  
> to the CommProvider if it is set
>
> 4) change the constructor of CommPortIdentifier to
>
>    public CommPortIdentifier(...) {
>       if (isProviderSet && this.getClass() ==  
> javax.comm.CommPortIdentifier) {
>           throw new RuntimeException("illegal creation of  
> CommPortIndentifier, custom CommProvider is in use");
>       }
>
> 5) (this is optional, but would be very nice) automatically set a  
> custom CommProvider if it is found on the classpath or defined via a  
> system property.
>
>
> The above 1) - 4) can be implemented in less than 1hour. 5) may take  
> another hour. I agree that this is not the most elegant design, but  
> it would solve a lot of problems with very little effort. It would  
> certainly allow RXTX to move forward. If the javax.comm API needs to  
> be redesigned completely this addition will not hurt, as people will  
> move to the new API anyway and javax.comm 3.0 was so far never  
> included in the main distribution.
>
> Best regards,
> Joachi
I'm afraid modifying the interface classes isn't my call.  There was 
actually
a TCK written and one of the tests was to ensure that the interface classes
match the spec.  Thus my hands have already been tied since this project
was essentially grandfathered into the JCP.

That's why we need to open a new JSR and find someone who wants
to be the spec lead, and go in with a new reference implementation.
I'm not sure why it would have to take years, since this isn't bleeding edge
technology and there are only so many things that can be done with it,
and we already have practical experience about many functional aspects
that we could cite precedence on.

As it becomes clear that the specification is being accepted completely
or by-and-large by the community, nothing would stop people from
starting adapting to the new API (using the reference implementation or
porting it) and using it in their projects prior to it's final community and
JCP approval, since approval is required only to make it official and
get the "100% pure java" certification for platform ports.

You have one idea already.  Why don't you implement it, solicit some
design feedback from Sun and the RXTX, and create a functional
implementation that addresses the needs of the community, then
we can document it and open a JSR.  That's it.  It should march through
the approval stages reasonably quickly I would imagine, and meantime
RXTX could start using it.

Paul




From doug at dupreeinc.com  Fri Jun  2 12:45:01 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 02 Jun 2006 11:45:01 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
	<9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
Message-ID: <4480872D.6000605@dupreeinc.com>

Joachim,

Thank you for the suggestion.  I restored the jar file to the one I 
downloaded, moved the dll files into the project directory, and added 
the jar to the classpath.  The SerialDemo program that was included with 
the Sun commapi started in 12 seconds instead of the 58 seconds when the 
parallel dll is present.  I did get the startup time to about a second 
by modifying the java code and adding the properties file but this is 
probably not a good idea.

Doug

Joachim Buechse wrote:

>Hi Doug,
>
>you wrote in an earlier message, that you would prefer an unchanged  
>version. What about simply removing the RXTX parallel lib from the  
>ext directory. This does not fix the bug, but it should fix your  
>problem.
>
>In general I think it is not a good idea to put the RXTX files in a  
>system wide location. Putting the libs in the application folder and  
>including the .jar in the application classpath (or application jar)  
>is all that is required.
>
>Regards,
>Joachim
>
>On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:
>
>  
>
>>Ok, I just hacked this thing up and got it to read the
>>gnu.io.rxtx.properties file.
>>
>>I commented out the line:
>>System.setProperties(p); in the method registerSpecifiedPorts() in
>>RXTXCommDriver class.  I really don't understand that much about
>>properties, but this call kills the System class.
>>
>>I used the following in the gnu.io.rxtx.properties file:
>>
>>gnu.io.rxtx.SerialPorts=COM3
>>gnu.io.rxtx.ParallelPorts=null
>>
>>This allows the application to open very quickly without any errors.
>>Whomever coded this class or somebody who understands properties  
>>should
>>look at this method and make sure it is doing what they expect.
>>
>>Doug
>>
>>
>>
>>
>>Doug Thistlethwaite wrote:
>>
>>    
>>
>>>I think there is an error in the registerSpecifiedPorts() method.   
>>>When
>>>I have a gnu.io.rxtx.properties file in the ext directory, this  
>>>function
>>>kills the System class  IF I call System.getProperty("os.name")  
>>>before
>>>the call  to registerSpecifiedPorts(), it returns the os name,  
>>>after the
>>>call, it returns null.  I have not played much with properties,  
>>>except
>>>for reading them, so I don't really understand the code.
>>>
>>>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
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060602/3c0e420f/attachment-0005.html

From joachim at buechse.de  Fri Jun  2 13:46:36 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 21:46:36 +0200
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
	RXTX again
In-Reply-To: <44807ED6.8000903@sun.com>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
	<44807ED6.8000903@sun.com>
Message-ID: <6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>

Hello Paul,

of course, the basic change I suggested could be done "hidden".  The  
CommProvider interface could live somewhere in sun.xyz.*
The setCustomCommProvider method would not be in CommPortIdentifier  
but also somewhere in sun.xyz.* This would be an unofficial feature,  
the official interface stays exactly the same. However RXTX (and  
others) could access the hidden interface.

Don't get me wrong, I don't want to harass you into making changes  
you don't like (which probably wouldn't work anyway;-). But I'm a  
long time Java programmer and seeing the state of cross platform  
serial support for Java makes me feel really sad. In fact, when I  
started to look into Java serial port programming some months ago I  
was very surprised that javax.comm never made it into the JDK.

I'm sorry that I did not contribute my feedback to the JSR for  
javax.comm 3.0. However at the time I didn't do serial port  
programming in Java. I agree that a new JSR should be opened - I'm  
not an expert on JSRs or the JCP process, but from looking quickly  
over the progress of some JSRs I would be very surprised if we can  
have a new version in less then a year. In the meanwhile some people  
will start using javax.comm 3.0 (which can not be supported by RXTX),  
some will use javax.comm 2.0 (which means the 2.0.7 release of RXTX  
still needs to be maintained). This may get even worse if eg Apple  
decides to port and include javax.comm 3.0 at which point it may get  
very tricky to write a cross platform Java application.

All of this simply means, that we are loosing a lot of man-power that  
could otherwise be invested in building a clean solution and/or to  
add features that are becoming more and more important (USB events...).

In the automation / machine control universe Java makes a lot of  
sense. Right now many people are migrating to Linux or from  
propietary systems (even DOS) to Windows. Writing the control/ 
configuration applications in Java is the kings way to unify the code  
base.

Best regards,
Joachim


On 02.06.2006, at 20:09, Paul Klissner wrote:

> Joachim Buechse wrote:
>> Good day Paul!
>>
>> A clean architecture with loadable drivers and reusable code would be
>> very beneficial for the future, I think everybody agrees. However
>> this could be several years into the future. In the meantime, there
>> is a real existing problem with IO support on Java. I have the strong
>> feeling that most programmers want to code against one specification
>> (javax.comm) and be able to replace the underlying implementation via
>> a "plugin" on platforms where the SUN implementation is not
>> sufficient. RXTX could be just this plugin (reusing very close to 0%
>> of the javax.comm implementation but 100% of its API).
>>
>> I want to propose an API addition and implementation change that will
>> take less then 2 hours of manpower to implement and create a solution
>> that can bridge the years until javax.comm has been based on a new
>> architecture.
>>
>> Looking at the javax.comm api at http://java.sun.com/products/
>> javacomm/reference/api/index.html I would like to propose the  
>> following:
>>
>> The only entry point to javax.comm is CommPortIdentifier. It has 3
>> static methods plus the constructor.
>>
>> 1) define one additional Interface
>>
>> public interface CommProvider {
>>     CommPortIdentifier getPortIdentifier(CommPort port);
>>     CommPortIdentifier getPortIdentifier(String portName);
>>     Enumeration getPortIdentifiers ();
>> }
>>
>> 2) add one method to CommPortIdentifier
>>
>>    public static setCustomCommProvider (CommProvider);
>>
>> 3) change the three static methods of CommPortIdentifier to dispatch
>> to the CommProvider if it is set
>>
>> 4) change the constructor of CommPortIdentifier to
>>
>>    public CommPortIdentifier(...) {
>>       if (isProviderSet && this.getClass() ==
>> javax.comm.CommPortIdentifier) {
>>           throw new RuntimeException("illegal creation of
>> CommPortIndentifier, custom CommProvider is in use");
>>       }
>>
>> 5) (this is optional, but would be very nice) automatically set a
>> custom CommProvider if it is found on the classpath or defined via a
>> system property.
>>
>>
>> The above 1) - 4) can be implemented in less than 1hour. 5) may take
>> another hour. I agree that this is not the most elegant design, but
>> it would solve a lot of problems with very little effort. It would
>> certainly allow RXTX to move forward. If the javax.comm API needs to
>> be redesigned completely this addition will not hurt, as people will
>> move to the new API anyway and javax.comm 3.0 was so far never
>> included in the main distribution.
>>
>> Best regards,
>> Joachi
> I'm afraid modifying the interface classes isn't my call.  There was
> actually
> a TCK written and one of the tests was to ensure that the interface  
> classes
> match the spec.  Thus my hands have already been tied since this  
> project
> was essentially grandfathered into the JCP.
>
> That's why we need to open a new JSR and find someone who wants
> to be the spec lead, and go in with a new reference implementation.
> I'm not sure why it would have to take years, since this isn't  
> bleeding edge
> technology and there are only so many things that can be done with it,
> and we already have practical experience about many functional aspects
> that we could cite precedence on.
>
> As it becomes clear that the specification is being accepted  
> completely
> or by-and-large by the community, nothing would stop people from
> starting adapting to the new API (using the reference  
> implementation or
> porting it) and using it in their projects prior to it's final  
> community and
> JCP approval, since approval is required only to make it official and
> get the "100% pure java" certification for platform ports.
>
> You have one idea already.  Why don't you implement it, solicit some
> design feedback from Sun and the RXTX, and create a functional
> implementation that addresses the needs of the community, then
> we can document it and open a JSR.  That's it.  It should march  
> through
> the approval stages reasonably quickly I would imagine, and meantime
> RXTX could start using it.
>
> Paul
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From paul.klissner at sun.com  Fri Jun  2 14:38:49 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 13:38:49 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
	<44807ED6.8000903@sun.com>
	<6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>
Message-ID: <4480A1D9.5060106@sun.com>

Joachim Buechse wrote:
> Hello Paul,
>
> of course, the basic change I suggested could be done "hidden".  The  
> CommProvider interface could live somewhere in sun.xyz.*
> The setCustomCommProvider method would not be in CommPortIdentifier  
> but also somewhere in sun.xyz.* This would be an unofficial feature,  
> the official interface stays exactly the same. However RXTX (and  
> others) could access the hidden interface.
>
> Don't get me wrong, I don't want to harass you into making changes  
> you don't like (which probably wouldn't work anyway;-). But I'm a  
> long time Java programmer and seeing the state of cross platform  
> serial support for Java makes me feel really sad. In fact, when I  
> started to look into Java serial port programming some months ago I  
> was very surprised that javax.comm never made it into the JDK.
>
> I'm sorry that I did not contribute my feedback to the JSR for  
> javax.comm 3.0. 
There was no JSR for 3.0, because we didn't have the resources to make 
the commitment.
Yet Sun needed to add support for platform-dependent port name mapping, 
which had to
be done 'under the hood', since the API isn't designed to handle that in 
a pluggable way.
But these quick fixes aren't the right approach, they just kick the dog 
down the road,
setting bad precedent, inviting confusion and more intractable problems 
(such as the
one plaguing us now).

My changes could have been layered better, it was a trade off between 
achieving an
ideal architecture, trying to find internal reviewers, and meet the 
needs of big customers
in a timely way.  Thus my namespace changes collided with RXTX's 
dependencies.
I was unaware of Jagane's rogue agreement made with the RXTX community 7 
years ago,
before Jagane left Sun.  I think this was a wag-the-dog situation.

Now it is time to do it right, and I don't think it is going to be as 
much trouble as people
some people fear. If RXTX wants to sponsor the JSR and seed a new spec, 
Sun can join
the Expert Group.  And we'd be largely in agreement, since we're not 
talking about
humongous changes, and looking for mutually beneficial changes. The core 
API is already
largely proved and tested.
> However at the time I didn't do serial port  
> programming in Java. I agree that a new JSR should be opened - I'm  
> not an expert on JSRs or the JCP process, but from looking quickly  
> over the progress of some JSRs I would be very surprised if we can  
> have a new version in less then a year. 
*Approved*  But that doesn't mean the spec couldn't be 99.9% stable 
before that.  Once
the delta rate declines and changes approach nil, people could start 
adapting to the API in
advance of formal approval.   It isn't going to be drawn out like 
javax.usb, which was new
technology, a very complex API, and involved precedent setting corporate 
disputes and
policy issues to resolve.

> In the meanwhile some people  
> will start using javax.comm 3.0 (which can not be supported by RXTX),  
> some will use javax.comm 2.0 (which means the 2.0.7 release of RXTX  
> still needs to be maintained). This may get even worse if eg Apple  
> decides to port and include javax.comm 3.0 at which point it may get  
> very tricky to write a cross platform Java application.
>   
The interfaces haven't changed since 1.0.  If we open a JSR ,we can 
contact Apple and
allow them to be on the E.G., if they want.  That might make the JSR a 
bit more drawn out,
but then we'd arrive ultimately arrive at a best-of-all-worlds API that 
most people would
accept, perhaps forever, and arrive at a respectable set of compromises.

-Paul

> All of this simply means, that we are loosing a lot of man-power that  
> could otherwise be invested in building a clean solution and/or to  
> add features that are becoming more and more important (USB events...).
>
> In the automation / machine control universe Java makes a lot of  
> sense. Right now many people are migrating to Linux or from  
> propietary systems (even DOS) to Windows. Writing the control/ 
> configuration applications in Java is the kings way to unify the code  
> base.
>
> Best regards,
> Joachim
>
>
> On 02.06.2006, at 20:09, Paul Klissner wrote:
>
>   
>> Joachim Buechse wrote:
>>     
>>> Good day Paul!
>>>
>>> A clean architecture with loadable drivers and reusable code would be
>>> very beneficial for the future, I think everybody agrees. However
>>> this could be several years into the future. In the meantime, there
>>> is a real existing problem with IO support on Java. I have the strong
>>> feeling that most programmers want to code against one specification
>>> (javax.comm) and be able to replace the underlying implementation via
>>> a "plugin" on platforms where the SUN implementation is not
>>> sufficient. RXTX could be just this plugin (reusing very close to 0%
>>> of the javax.comm implementation but 100% of its API).
>>>
>>> I want to propose an API addition and implementation change that will
>>> take less then 2 hours of manpower to implement and create a solution
>>> that can bridge the years until javax.comm has been based on a new
>>> architecture.
>>>
>>> Looking at the javax.comm api at http://java.sun.com/products/
>>> javacomm/reference/api/index.html I would like to propose the  
>>> following:
>>>
>>> The only entry point to javax.comm is CommPortIdentifier. It has 3
>>> static methods plus the constructor.
>>>
>>> 1) define one additional Interface
>>>
>>> public interface CommProvider {
>>>     CommPortIdentifier getPortIdentifier(CommPort port);
>>>     CommPortIdentifier getPortIdentifier(String portName);
>>>     Enumeration getPortIdentifiers ();
>>> }
>>>
>>> 2) add one method to CommPortIdentifier
>>>
>>>    public static setCustomCommProvider (CommProvider);
>>>
>>> 3) change the three static methods of CommPortIdentifier to dispatch
>>> to the CommProvider if it is set
>>>
>>> 4) change the constructor of CommPortIdentifier to
>>>
>>>    public CommPortIdentifier(...) {
>>>       if (isProviderSet && this.getClass() ==
>>> javax.comm.CommPortIdentifier) {
>>>           throw new RuntimeException("illegal creation of
>>> CommPortIndentifier, custom CommProvider is in use");
>>>       }
>>>
>>> 5) (this is optional, but would be very nice) automatically set a
>>> custom CommProvider if it is found on the classpath or defined via a
>>> system property.
>>>
>>>
>>> The above 1) - 4) can be implemented in less than 1hour. 5) may take
>>> another hour. I agree that this is not the most elegant design, but
>>> it would solve a lot of problems with very little effort. It would
>>> certainly allow RXTX to move forward. If the javax.comm API needs to
>>> be redesigned completely this addition will not hurt, as people will
>>> move to the new API anyway and javax.comm 3.0 was so far never
>>> included in the main distribution.
>>>
>>> Best regards,
>>> Joachi
>>>       
>> I'm afraid modifying the interface classes isn't my call.  There was
>> actually
>> a TCK written and one of the tests was to ensure that the interface  
>> classes
>> match the spec.  Thus my hands have already been tied since this  
>> project
>> was essentially grandfathered into the JCP.
>>
>> That's why we need to open a new JSR and find someone who wants
>> to be the spec lead, and go in with a new reference implementation.
>> I'm not sure why it would have to take years, since this isn't  
>> bleeding edge
>> technology and there are only so many things that can be done with it,
>> and we already have practical experience about many functional aspects
>> that we could cite precedence on.
>>
>> As it becomes clear that the specification is being accepted  
>> completely
>> or by-and-large by the community, nothing would stop people from
>> starting adapting to the new API (using the reference  
>> implementation or
>> porting it) and using it in their projects prior to it's final  
>> community and
>> JCP approval, since approval is required only to make it official and
>> get the "100% pure java" certification for platform ports.
>>
>> You have one idea already.  Why don't you implement it, solicit some
>> design feedback from Sun and the RXTX, and create a functional
>> implementation that addresses the needs of the community, then
>> we can document it and open a JSR.  That's it.  It should march  
>> through
>> the approval stages reasonably quickly I would imagine, and meantime
>> RXTX could start using it.
>>
>> Paul
>>
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at 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  Sat Jun  3 18:15:24 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 18:15:24 -0600 (MDT)
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
Message-ID: <Pine.LNX.4.61.0606031715100.10890@www>


The attached patch allows baud rates of 14400, 28800, 128000 and 256000.

That was my goal.

[import standard disclaimer]

But I took some time to look a little further.  I got custom baud rates 
working enough that someone (perhaps me) can properly fix them in the 
future.  Proof of concept.

As an undocumented bonus, you can toss random baudrates (say 1953), at the 
API and it will set it to something close to that on windows and linux. 
Solaris should say the baud rate is not supported but I have not tested it 
yet.  Mac OS X behavior is unknown at this point.  Just dont expect 
correct behavior at ~8192-9009 baudrates or baudrates less than 20 on 
windows; these baud rates overlap with defines in win32termios.h.  I 
conveniently closed my eyes there.  Try another value close.  On Linux, a 
baud base and divisor are guestimated and set.  On windows, we wave pixie 
dust over the kernel driver and hope.  Do not expect pixie dust and 
guestimates to be the same on windows and linux.  They may well round to 
different values in yet to be tested ways.  There are only so many 
divisors.  If it isn't working, try a little higher or lower.

In the example of 1953 for instance, there is no divisor for commodity 
hardware that comes to that baudrate.  We just come close on one side or 
the other.  If tools tell you they got 1953 exactly, the tools may be 
questionable and just reading values not directly related to the actual 
hardware settings.

These fixes have been tested on Linux and Windows while using an 
oscilloscope to confirm they change relative to known baudrates at 9600, 
14400*, 19200, 28800* (and 1800, 1953** and 2400).

* = previously unsupported.
** = still not supported but probably works from what I saw.

There could be future discussion in this area.  For now this is working 
for almost all unusual baud rate demands.  Cleaning up the custom baud 
rate should be easier with a working starting point.  Baud bases other 
than 128000 have not been characterized.  Yes.. this overlapps with two of 
the baud rates enabled.

Feedback and ideas are welcome.

--
Trent Jarvi
tjarvi at qbang.org
-------------- next part --------------
Index: SerialImp.c
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v
retrieving revision 1.46.2.187
diff -u -r1.46.2.187 SerialImp.c
--- SerialImp.c	29 Jan 2006 22:19:04 -0000	1.46.2.187
+++ SerialImp.c	3 Jun 2006 23:12:40 -0000
@@ -793,6 +793,19 @@
 		result &= ~TIOCM_DTR;
 		ioctl( fd, TIOCMSET, &result );
 	}
+	/*
+	   B38400 is a special case in Linux for custom baud rates.
+
+	   We just treat this as a custom speed for now.  If you take this ifdef
+	   out and select baud rates 38400 then 28800 then 38400, you will get
+	   a final baud rate of 28800 because you did not update the divisor.
+
+	   See the next ifdef below for the divisor.
+	*/
+#if defined(TIOCGSERIAL)
+	if ( cspeed == B38400 )
+		cspeed = 38400;
+#endif /* TIOCGSERIAL */
 	if(     cfsetispeed( &ttyset, cspeed ) < 0 ||
 		cfsetospeed( &ttyset, cspeed ) < 0 )
 	{
@@ -814,6 +827,7 @@
 		*/
 
 #if defined(TIOCGSERIAL)
+		ioctl( fd, TIOCGSERIAL, &sstruct );
 		sstruct.custom_divisor = ( sstruct.baud_base/cspeed );
 		cspeed = B38400;
 #endif /* TIOCGSERIAL */
@@ -827,7 +841,7 @@
 #if defined(TIOCSSERIAL)
 		/*  It is assumed Win32 does this for us */
 		if (	sstruct.baud_base < 1 ||
-			ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
+		ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
 		{
 			return( 1 );
 		}
Index: termios.c
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v
retrieving revision 1.9.2.56
diff -u -r1.9.2.56 termios.c
--- termios.c	16 Jan 2006 02:50:32 -0000	1.9.2.56
+++ termios.c	3 Jun 2006 23:12:40 -0000
@@ -323,8 +323,8 @@
 		case CBR_3500000:	return( B3500000 );
 		case CBR_4000000:	return( B4000000 );
 		default:
-			set_errno(EINVAL );
-			return -1;
+			/* assume custom baudrate */
+			return( Baud );
 	}
 }
 
@@ -361,12 +361,13 @@
 		case B9600:	ret = CBR_9600;		break;
 		case B14400:	ret = CBR_14400;	break;
 		case B19200:	ret = CBR_19200;	break;
+		case B28800:	ret = CBR_28800;	break;
 		case B38400:	ret = CBR_38400;	break;
 		case B57600:	ret = CBR_57600;	break;
 		case B115200:	ret = CBR_115200;	break;
 		case B128000:	ret = CBR_128000;	break;
-		case B256000: 	ret = CBR_256000;	break;
 		case B230400:	ret = CBR_230400;	break;
+		case B256000: 	ret = CBR_256000;	break;
 		case B460800:	ret = CBR_460800;	break;
 		case B500000:	ret = CBR_500000;	break;
 		case B576000:	ret = CBR_576000;	break;
@@ -381,10 +382,8 @@
 		case B4000000:	ret = CBR_4000000;	break;
 	
 		default:
-			fprintf( stderr, "B_to_CBR: invalid baudrate: %#o\n",
-				Baud );
-			set_errno( EINVAL );
-			return -1;
+			/* assume custom baudrate */
+			return Baud;
 	}
 	LEAVE( "B_to_CBR" );
 	return ret;
@@ -708,12 +707,9 @@
 	ENTER( "init_serial_struct" );
 
 	/*
-	FIXME
-
-	This needs to use inb() to read the actual baud_base
-	and divisor from the UART registers.  Question is how
-	far do we take this?
-
+	use of custom_divisor and baud_base requires access to
+	kernel space.  The kernel does try its best if you just
+	toss a baud rate at it though.
 	*/
 
 	sstruct->custom_divisor = 0;
@@ -1678,16 +1674,17 @@
 {
 	char message[80];
 	ENTER( "cfsetospeed" );
+	/* clear baudrate */
+	s_termios->c_cflag &= ~CBAUD;
 	if ( speed & ~CBAUD )
 	{
 		sprintf( message, "cfsetospeed: not speed: %#o\n", speed );
 		report( message );
-		return 0;
+		/* continue assuming its a custom baudrate */
+		s_termios->c_cflag |= B38400;  /* use 38400 during custom */
+		s_termios->c_cflag |= CBAUDEX; /* use CBAUDEX for custom */
 	}
-	s_termios->c_ispeed = s_termios->c_ospeed = speed;
-	/* clear baudrate */
-	s_termios->c_cflag &= ~CBAUD;
-	if( speed )
+	else if( speed )
 	{
 		s_termios->c_cflag |= speed;
 	}
@@ -1696,6 +1693,7 @@
 		/* PC blows up with speed 0 handled in Java */
 		s_termios->c_cflag |= B9600;
 	}
+	s_termios->c_ispeed = s_termios->c_ospeed = speed;
 	LEAVE( "cfsetospeed" );
 	return 1;
 }
@@ -1767,25 +1765,6 @@
 }
 
 /*----------------------------------------------------------
-serial_struct_to_DCB()
-
-   accept:      
-   perform:     
-   return:      
-   exceptions:  
-   win32api:     None
-   comments:    
-----------------------------------------------------------*/
-int serial_struct_to_DCB( struct serial_struct *sstruct, DCB *dcb )
-{
-	/* 5 Baud rate fix
-	sstruct.baud_base
-	sstruct.custom_divisor = ( sstruct.baud_base/cspeed );
-	*/
-	return(0);
-}
-
-/*----------------------------------------------------------
 termios_to_DCB()
 
    accept:      
@@ -1798,7 +1777,8 @@
 int termios_to_DCB( struct termios *s_termios, DCB *dcb )
 {
 	ENTER( "termios_to_DCB" );
-	s_termios->c_ispeed = s_termios->c_ospeed = s_termios->c_cflag & CBAUD;
+	if ( !(s_termios->c_cflag & CBAUDEX) )
+		s_termios->c_ispeed = s_termios->c_ospeed = s_termios->c_cflag & CBAUD;
 	dcb->BaudRate        = B_to_CBR( s_termios->c_ispeed );
 	dcb->ByteSize = termios_to_bytesize( s_termios->c_cflag );
 
@@ -2863,11 +2843,6 @@
 			GetCommState( index->hComm, dcb );
 
 			index->sstruct = va_arg( ap, struct serial_struct * );
-			if ( serial_struct_to_DCB( index->sstruct, dcb ) < 0 )
-			{
-				va_end( ap );
-				return -1;
-			}
 
 			report( "TIOCSSERIAL\n" );
 			free(dcb);
Index: win32termios.h
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v
retrieving revision 1.5.2.28
diff -u -r1.5.2.28 win32termios.h
--- win32termios.h	30 Jun 2005 20:23:26 -0000	1.5.2.28
+++ win32termios.h	3 Jun 2006 23:12:40 -0000
@@ -279,7 +279,7 @@
 #define XTABS	01000000 /* Hmm.. Linux/i386 considers this part of TABDLY.. */
 
 /* c_cflag bit meaning */
-# define CBAUD	0010017
+#define  CBAUD  0030017
 #define  B0	0000000		/* hang up */
 #define  B50	0000001
 #define  B75	0000002
@@ -312,13 +312,16 @@
 #define  B3500000 0010016
 #define  B4000000 0010017
 
-/* glue for unsupported linux speeds see also SerialImp.h */
-/* hosed */
-
-#define B14400		1010001
-#define B28800		1010002
-#define B128000		1010003
-#define B256000		1010004
+/*
+	glue for unsupported linux speeds see also SerialImp.h 
+	custom baud rates around 8192-9000 will not work because
+	of these.
+*/
+
+#define B14400		0020001
+#define B28800		0020002
+#define B128000		0020003
+#define B256000		0020004
 
 #define EXTA B19200
 #define EXTB B38400
@@ -356,8 +359,10 @@
 
 /* glue for unsupported windows speeds */
 
-#define CBR_230400	230400
 #define CBR_28800	28800
+#define CBR_128000	128000
+#define CBR_230400	230400
+#define CBR_256000	256000
 #define CBR_460800	460800
 #define CBR_500000	500000
 #define CBR_576000	576000

From impakt01 at optusnet.com.au  Sat Jun  3 18:30:37 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 10:30:37 +1000
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
In-Reply-To: <Pine.LNX.4.61.0606031715100.10890@www>
Message-ID: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>

Hi Trent,
I'd love to try the patch but I can't get the latest build compiling, only
pre16. 

Can you attach the rxtxSerial.dll file with this patch?

Also, I hardcoded 1953 in a couple more places last night on pre16 and it
managed to open the port at the right speed, but stopped receiving anything
after 100-150 bytes, even though more data was getting sent to the port.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 10:15 AM
To: rxtx at qbang.org
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.


The attached patch allows baud rates of 14400, 28800, 128000 and 256000.

That was my goal.

[import standard disclaimer]

But I took some time to look a little further.  I got custom baud rates 
working enough that someone (perhaps me) can properly fix them in the 
future.  Proof of concept.

As an undocumented bonus, you can toss random baudrates (say 1953), at the 
API and it will set it to something close to that on windows and linux. 
Solaris should say the baud rate is not supported but I have not tested it 
yet.  Mac OS X behavior is unknown at this point.  Just dont expect 
correct behavior at ~8192-9009 baudrates or baudrates less than 20 on 
windows; these baud rates overlap with defines in win32termios.h.  I 
conveniently closed my eyes there.  Try another value close.  On Linux, a 
baud base and divisor are guestimated and set.  On windows, we wave pixie 
dust over the kernel driver and hope.  Do not expect pixie dust and 
guestimates to be the same on windows and linux.  They may well round to 
different values in yet to be tested ways.  There are only so many 
divisors.  If it isn't working, try a little higher or lower.

In the example of 1953 for instance, there is no divisor for commodity 
hardware that comes to that baudrate.  We just come close on one side or 
the other.  If tools tell you they got 1953 exactly, the tools may be 
questionable and just reading values not directly related to the actual 
hardware settings.

These fixes have been tested on Linux and Windows while using an 
oscilloscope to confirm they change relative to known baudrates at 9600, 
14400*, 19200, 28800* (and 1800, 1953** and 2400).

* = previously unsupported.
** = still not supported but probably works from what I saw.

There could be future discussion in this area.  For now this is working 
for almost all unusual baud rate demands.  Cleaning up the custom baud 
rate should be easier with a working starting point.  Baud bases other 
than 128000 have not been characterized.  Yes.. this overlapps with two of 
the baud rates enabled.

Feedback and ideas are welcome.

--
Trent Jarvi
tjarvi at qbang.org



From tjarvi at qbang.org  Sat Jun  3 19:05:11 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 19:05:11 -0600 (MDT)
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
In-Reply-To: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>
References: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606031840400.10890@www>

On Sun, 4 Jun 2006, Daren wrote:

> Hi Trent,
> I'd love to try the patch but I can't get the latest build compiling, only
> pre16.
>
> Can you attach the rxtxSerial.dll file with this patch?
>
> Also, I hardcoded 1953 in a couple more places last night on pre16 and it
> managed to open the port at the right speed, but stopped receiving anything
> after 100-150 bytes, even though more data was getting sent to the port.
>


ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing

I dont think they will hang.  But I was just testing via loopback/break 
out box/scope.

I'll be putting about 10 patches and another set of binaries in that 
directory shortly.  For now the binaries should just have the baud_rate 
fix.

I'll announce all the patches at once.  but wont be releasing 2.1-8 right 
away.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Sat Jun  3 21:00:01 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 21:00:01 -0600 (MDT)
Subject: [Rxtx] CVS for 2.1 should have everything
Message-ID: <Pine.LNX.4.61.0606032056190.10890@www>


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org


From impakt01 at optusnet.com.au  Sat Jun  3 21:08:14 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 13:08:14 +1000
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <Pine.LNX.4.61.0606032056190.10890@www>
Message-ID: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>

Hi Trent,
I tried the latest dll and it opens the port, receives 100-200 bytes and
then stops receiving anything else..

I'll keep playing with it.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 1:00 PM
To: rxtx at qbang.org
Subject: [Rxtx] CVS for 2.1 should have everything


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From impakt01 at optusnet.com.au  Sat Jun  3 21:22:41 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 13:22:41 +1000
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
Message-ID: <200606040322.k543MqW1008455@mail12.syd.optusnet.com.au>

Played with it, problem, with a while loop in my code, working great now

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Daren
Sent: Sunday, 4 June 2006 1:08 PM
To: 'RXTX Developers and Users'
Subject: Re: [Rxtx] CVS for 2.1 should have everything

Hi Trent,
I tried the latest dll and it opens the port, receives 100-200 bytes and
then stops receiving anything else..

I'll keep playing with it.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 1:00 PM
To: rxtx at qbang.org
Subject: [Rxtx] CVS for 2.1 should have everything


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Sat Jun  3 21:35:41 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 21:35:41 -0600 (MDT)
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
References: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606032131140.10890@www>

On Sun, 4 Jun 2006, Daren wrote:

> Hi Trent,
> I tried the latest dll and it opens the port, receives 100-200 bytes and
> then stops receiving anything else..
>
> I'll keep playing with it.
>
> Daren

The difference may be that I'm talking to something at the exact same baud 
rate (loopback).

You may also try setting the baudrate to ~1933 and ~1973 to force the 
guesses one way or the other.  If you are on windows, we are not doing 
anything fancy in the end.  Thats the kernel guessing.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sun Jun  4 04:12:09 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sun, 4 Jun 2006 12:12:09 +0200
Subject: [Rxtx] Update of OSX installer, Readme, etc
Message-ID: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>

Good day,

after the latest changes a lot of OS X specific files should be  
updated. Especially the installer!

- The "MaxOSX" readme file on the root level is outdated (ie  
CodeWarrior information). Maybe we could even rename it to README.OSX  
to be in line with README.IPAQ, README.SCO (Trent do you mind copying/ 
renaming ,v files in the repository?).

- The lock files are no longer used and hence the user group magic  
and lock folder creation should be removed from the installer.

- MACOSX_IDE/ForPackageMaker/Resources/ReadMe.rtf and Welcome.rtf  
need to be updated.

- I suggest to replace the current installation instruction for OS X:  
Installation should occur into the application directory, not in the  
Java-VM directory. This simplifies things a lot, as the Mac Installer  
can be removed completely.

- The xcodeproject's build settings need to be updated to generate  
JAVA 1.1 format class files.


Dimitry: do you have time to tackle this? I could do it, but as this  
is "your baby" I thought you may prefer to do it yourself.

Regards,
Joachim



From dmarkman at mac.com  Sun Jun  4 11:27:53 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Sun, 4 Jun 2006 13:27:53 -0400
Subject: [Rxtx] Update of OSX installer, Readme, etc
In-Reply-To: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
References: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
Message-ID: <26E7A202-962B-4C19-93B6-29426C467249@mac.com>

Joachim,
unfortunately I don't have time right now to do that
so if you can do that, please do

it's not only my baby
it's yours too :-)

thanks


On Jun 4, 2006, at 6:12 AM, Joachim Buechse wrote:

> Good day,
>
> after the latest changes a lot of OS X specific files should be
> updated. Especially the installer!
>
> - The "MaxOSX" readme file on the root level is outdated (ie
> CodeWarrior information). Maybe we could even rename it to README.OSX
> to be in line with README.IPAQ, README.SCO (Trent do you mind copying/
> renaming ,v files in the repository?).
>
> - The lock files are no longer used and hence the user group magic
> and lock folder creation should be removed from the installer.
>
> - MACOSX_IDE/ForPackageMaker/Resources/ReadMe.rtf and Welcome.rtf
> need to be updated.
>
> - I suggest to replace the current installation instruction for OS X:
> Installation should occur into the application directory, not in the
> Java-VM directory. This simplifies things a lot, as the Mac Installer
> can be removed completely.
>
> - The xcodeproject's build settings need to be updated to generate
> JAVA 1.1 format class files.
>
>
> Dimitry: do you have time to tackle this? I could do it, but as this
> is "your baby" I thought you may prefer to do it yourself.
>
> Regards,
> Joachim
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman



From tjarvi at qbang.org  Sun Jun  4 13:54:02 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 4 Jun 2006 13:54:02 -0600 (MDT)
Subject: [Rxtx] Update of OSX installer, Readme, etc
In-Reply-To: <26E7A202-962B-4C19-93B6-29426C467249@mac.com>
References: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
	<26E7A202-962B-4C19-93B6-29426C467249@mac.com>
Message-ID: <Pine.LNX.4.61.0606041353040.22522@www>

On Sun, 4 Jun 2006, Dmitry Markman wrote:

> Joachim,
> unfortunately I don't have time right now to do that
> so if you can do that, please do
>
> it's not only my baby
> it's yours too :-)
>

I've given Joachim cvs access.  He has shown good work in bugzilla.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Mon Jun  5 10:08:32 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 5 Jun 2006 18:08:32 +0200
Subject: [Rxtx] Build process changes for Mac OS X
Message-ID: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>

Good day,

I have cleaned up some outdated Mac OSX specific build files in the  
repository.

There was not a lot left of the readme file "MacOSX" after cleaning  
it up, so I decided to rename it README.OSX to be in harmony with the  
other files in the directory (ie README.IPAQ, README.SCO, ...)

I added an (uncompressed) XCode 2.3 project file/structure  
with .cvsignore files that will ignore the user specific settings.  
This should work "out of the box" for OSX10.4. Users of 10.2/10.3 may  
have to switch the build settings.

[It's kind of tricky to choose "the right" setting. Afaik there is no  
way to compile a universal binary that will work on 10.3 or before.  
So it's either UniversalBinary OR Legacy. Maybe we should have  
different build targets for these different targets?? I would like to  
get some feedback from the Mac developers on this list regarding the  
subject].

Besides other things the OSX installer is no longer required. Since  
the next version (2.1.8) will no longer use lockfiles on OSX, the  
group/permission magic is no longer required and hence there remains  
basicly no work for the installer - other than copying 2 files to the  
VM extension directory. Then again, this is not the best way to  
install RXTX. So I removed the installer completely without modifying  
it, this should simplify a "resurrection" should it ever get necessary.

I had problems with the (compressed, ie sit.hqx) legacy project files  
on the latest installation of OSX (javac 1.5 creating non JDK1.1  
class files and some minor problems). To reduce potential confusion  
for newcomers I decided to remove them. This means that there is no  
longer a simple way to build RXTX for OSX 10.0 and 10.1 (I deeply  
apologize if anyone still relied on this ... well the files are in  
the Attiq).

Best regards,
Joachim


From joachim at buechse.de  Mon Jun  5 10:16:37 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 5 Jun 2006 18:16:37 +0200
Subject: [Rxtx] RXTX and lockfiles on OSX [it is fixed now]
Message-ID: <7D2C4418-9397-4B59-8091-9FDE4ED67836@buechse.de>

Quite a number of people contacted me in the last couple of weeks  
because of problems installing RXTX on OSX. I told you to wait for  
the "official" fix. Well, it has been fixed.

So if you were among the people waiting for the solution, you can now  
download the source rxtx-2.1-7r2.zip from the website. Once unpacked  
dont forget to use "cvs up" to update the files to the latest  
version. You can then open MACOSX_IDE/XCode/ 
LibSerialUniversal.xcodeproj with XCode 2.3 and build the libraries  
that no longer try to create lock files.

Regards,
Joachim


From brian at mbari.org  Mon Jun  5 10:52:43 2006
From: brian at mbari.org (Brian Schlining)
Date: Mon, 5 Jun 2006 09:52:43 -0700
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
Message-ID: <78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>

Hi Joachim,

> [It's kind of tricky to choose "the right" setting. Afaik there is no
> way to compile a universal binary that will work on 10.3 or before.
> So it's either UniversalBinary OR Legacy. Maybe we should have
> different build targets for these different targets?? I would like to
> get some feedback from the Mac developers on this list regarding the
> subject].

I imagine most developers will be compiling on 10.4 (It's the nature  
of the coder...gotta have the latest and greatest) and deploying to  
both 10.3 and 10.4; both of which will run Universal Binaries (see  
http://forums.macrumors.com/showthread.php?t=205348). So it sounds  
like you've covered the majority of users. Still, you know someone's  
going to pipe up about needing RXTX on 10.2 so it would be nice to  
have a target to make a PPC only build.

Just my 2 cents

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/1cac8c39/attachment-0005.html

From dmarkman at mac.com  Mon Jun  5 13:47:50 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Mon, 5 Jun 2006 15:47:50 -0400
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
Message-ID: <686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>

I don't think it will be a problem to run universal binary
on 10.2
however if binary has some calls that aren't implemented in 10.2
then you'll have a problem


On Jun 5, 2006, at 12:52 PM, Brian Schlining wrote:

> Hi Joachim,
>
>> [It's kind of tricky to choose "the right" setting. Afaik there is no
>> way to compile a universal binary that will work on 10.3 or before.
>> So it's either UniversalBinary OR Legacy. Maybe we should have
>> different build targets for these different targets?? I would like to
>> get some feedback from the Mac developers on this list regarding the
>> subject].
>
> I imagine most developers will be compiling on 10.4 (It's the  
> nature of the coder...gotta have the latest and greatest) and  
> deploying to both 10.3 and 10.4; both of which will run Universal  
> Binaries (see http://forums.macrumors.com/showthread.php?t=205348).  
> So it sounds like you've covered the majority of users. Still, you  
> know someone's going to pipe up about needing RXTX on 10.2 so it  
> would be nice to have a target to make a PPC only build.
>
> Just my 2 cents
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/9fafc878/attachment-0005.html

From brian at mbari.org  Mon Jun  5 14:52:41 2006
From: brian at mbari.org (Brian Schlining)
Date: Mon, 5 Jun 2006 13:52:41 -0700
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
Message-ID: <E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>

Hi Dmitry,

> I don't think it will be a problem to run universal binary
> on 10.2
> however if binary has some calls that aren't implemented in 10.2
> then you'll have a problem

You're right...I stand corrected.

Note however, to deploy a universal binary to 10.2 RXTX will need to  
use the 10.2 SDK to build the PPC side. (see http:// 
developer.apple.com/documentation/DeveloperTools/Conceptual/ 
cross_development/UniversalBinaries/chapter_4_section_1.html). I  
haven't been paying close attention to the new locking mechanism used  
by RXTX on the Mac...does 10.2 support it?

Joachim, which SDK will you be using by default for building the Mac  
PPC binaries?

>> Hi Joachim,
>>
>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>> is no
>>> way to compile a universal binary that will work on 10.3 or before.
>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>> different build targets for these different targets?? I would  
>>> like to
>>> get some feedback from the Mac developers on this list regarding the
>>> subject].
>>
>> I imagine most developers will be compiling on 10.4 (It's the  
>> nature of the coder...gotta have the latest and greatest) and  
>> deploying to both 10.3 and 10.4; both of which will run Universal  
>> Binaries (see http://forums.macrumors.com/showthread.php? 
>> t=205348). So it sounds like you've covered the majority of users.  
>> Still, you know someone's going to pipe up about needing RXTX on  
>> 10.2 so it would be nice to have a target to make a PPC only build.

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/153bf50e/attachment-0005.html

From dmarkman at mac.com  Mon Jun  5 19:02:04 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Mon, 5 Jun 2006 21:02:04 -0400
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
Message-ID: <7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>

if Joachim didn't change xcode project setting

/Developer/SDKs/MacOSX10.4u.sdk is used to build universal binary

so it's quite possible that it won't run properly on 10.2

so we have to change the building process, so ppc part will be built
with
/Developer/SDKs/MacOSX10.2.8.sdk

and finally to use lipo utility to build universal binaries

Joachim, did you use some specific locking API that wasn't implemented

in MacOSX10.2.8.sdk?

thanks


On Jun 5, 2006, at 4:52 PM, Brian Schlining wrote:

> Hi Dmitry,
>
>> I don't think it will be a problem to run universal binary
>> on 10.2
>> however if binary has some calls that aren't implemented in 10.2
>> then you'll have a problem
>
> You're right...I stand corrected.
>
> Note however, to deploy a universal binary to 10.2 RXTX will need  
> to use the 10.2 SDK to build the PPC side. (see http:// 
> developer.apple.com/documentation/DeveloperTools/Conceptual/ 
> cross_development/UniversalBinaries/chapter_4_section_1.html). I  
> haven't been paying close attention to the new locking mechanism  
> used by RXTX on the Mac...does 10.2 support it?
>
> Joachim, which SDK will you be using by default for building the  
> Mac PPC binaries?
>
>>> Hi Joachim,
>>>
>>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>>> is no
>>>> way to compile a universal binary that will work on 10.3 or before.
>>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>>> different build targets for these different targets?? I would  
>>>> like to
>>>> get some feedback from the Mac developers on this list regarding  
>>>> the
>>>> subject].
>>>
>>> I imagine most developers will be compiling on 10.4 (It's the  
>>> nature of the coder...gotta have the latest and greatest) and  
>>> deploying to both 10.3 and 10.4; both of which will run Universal  
>>> Binaries (see http://forums.macrumors.com/showthread.php? 
>>> t=205348). So it sounds like you've covered the majority of  
>>> users. Still, you know someone's going to pipe up about needing  
>>> RXTX on 10.2 so it would be nice to have a target to make a PPC  
>>> only build.
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/84790f80/attachment-0005.html

From joachim at buechse.de  Tue Jun  6 02:40:47 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 6 Jun 2006 10:40:47 +0200
Subject: [Rxtx] Building on OS X, Impl Changes
In-Reply-To: <7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
Message-ID: <CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>

Good day!

What's in the XCode project setting?
----------

The xcode project remained pretty much the same as before. I excluded  
the user specific files from CVS and changed some settings. I kept  
all the built targets (you shouldn't change what you don't understand;-)

Currently we the following build targets:
    RXTXComm (java files)
    librxtxParallel.jnilib (usefull on the Mac???)
    libI2C.jnilib (not yet working in RXTX)
    libRS485.jnilib (not yet working in RXTX)
    librxtxSerial.jnilib (1)
    librxtxSerial.jnilib Dynamic (2)
    rxtxSerial (3)
We also have the following build configurations for each target:
    Development
    Default
    Deployment

What was changed in the xcode project from previous versions:
- java.souce=1.3 and java.target=1.1 in RXTXComm settings
- removed copying of build products into installer directory
- removed "(Upgraded)" from build target names

What remains to be changed:
- choosing a "non-debug" Build-configuration as default
- potentially removing "Default"/"Development" Build-configurations
- reducing the number of build targets
- creating 10.2 compatible universal binaries

I suggest, that the build configurations should be reduced to 2  
(Debug/Deployment), possibly even 1 (Debug).
I have not yet found the deeper meaning of the build targets(1)(2) 
(3), it seems to me like they should be reduced into one "doing the  
right thing" or maybe into two "rxtxSerial.jnilib Legacy" (back to  
10.2, universal if possible) and "rxtxSerial.jnilib 10.4 
+" (universal, 10.4+).

Should the code work on 10.2?
----------

Absolutely. The code should work on NextStep, in fact on any BSD  
unix. I would go as far as saying, this code should work on any  
POSSIX based unix. All that was added is the call "ioctl(fd,  
TIOCEXCL)" to request excusivity of the port:

http://gemma.apple.com/documentation/DeviceDrivers/Conceptual/ 
WorkingWSerial/WWSerial_SerialDevs/chapter_2_section_8.html

It is not yet "the perfect solution". Normally an open /dev/tty  
(listen for incomming connection) should be "preemptable" by opening  
a /dev/cu (outgoing connection) for the same port. This is not yet  
implemented as it needs calls outside of POSSIX on OSX.

On "classic" systems (like NextStep) this worked based on the  
"carried detect line". open() on /dev/tty.xxx would block until the  
carrier detect signal was raised. As the device was not "opened"  
opening /dev/cu.xxx worked without a hitch. When they ported to the  
Mac this broke. On Macs the "carier detect" is usually not wired.  
Furthermore FAX modems did no longer raise the line. So the OSX  
implementor defined a new call, which is documented here:

http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00045.html

Best regards,
Joachim




On 06.06.2006, at 03:02, Dmitry Markman wrote:

> if Joachim didn't change xcode project setting
>
> /Developer/SDKs/MacOSX10.4u.sdk is used to build universal binary
>
> so it's quite possible that it won't run properly on 10.2
>
> so we have to change the building process, so ppc part will be built
> with
> /Developer/SDKs/MacOSX10.2.8.sdk
>
> and finally to use lipo utility to build universal binaries
>
> Joachim, did you use some specific locking API that wasn't implemented
>
> in MacOSX10.2.8.sdk?
>
> thanks
>
>
> On Jun 5, 2006, at 4:52 PM, Brian Schlining wrote:
>
>> Hi Dmitry,
>>
>>> I don't think it will be a problem to run universal binary
>>> on 10.2
>>> however if binary has some calls that aren't implemented in 10.2
>>> then you'll have a problem
>>
>> You're right...I stand corrected.
>>
>> Note however, to deploy a universal binary to 10.2 RXTX will need  
>> to use the 10.2 SDK to build the PPC side. (see http:// 
>> developer.apple.com/documentation/DeveloperTools/Conceptual/ 
>> cross_development/UniversalBinaries/chapter_4_section_1.html). I  
>> haven't been paying close attention to the new locking mechanism  
>> used by RXTX on the Mac...does 10.2 support it?
>>
>> Joachim, which SDK will you be using by default for building the  
>> Mac PPC binaries?
>>
>>>> Hi Joachim,
>>>>
>>>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>>>> is no
>>>>> way to compile a universal binary that will work on 10.3 or  
>>>>> before.
>>>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>>>> different build targets for these different targets?? I would  
>>>>> like to
>>>>> get some feedback from the Mac developers on this list  
>>>>> regarding the
>>>>> subject].
>>>>
>>>> I imagine most developers will be compiling on 10.4 (It's the  
>>>> nature of the coder...gotta have the latest and greatest) and  
>>>> deploying to both 10.3 and 10.4; both of which will run  
>>>> Universal Binaries (see http://forums.macrumors.com/ 
>>>> showthread.php?t=205348). So it sounds like you've covered the  
>>>> majority of users. Still, you know someone's going to pipe up  
>>>> about needing RXTX on 10.2 so it would be nice to have a target  
>>>> to make a PPC only build.
>>
>> Brian Schlining
>> Software Engineer
>> http://www.mbari.org
>>
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> Dmitry Markman
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Tue Jun  6 07:01:06 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 6 Jun 2006 15:01:06 +0200
Subject: [Rxtx] Serial port code for OS X, future steps
In-Reply-To: <CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
	<CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
Message-ID: <8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>

I posted the "wrong link". There is a correction here:

    http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00059.html

In fact, the 2.1.7 implementation of RXTX has quite some deficiencies  
on OSX. I have tried to supply some patches that don't interfere to  
much with the existing RXTX code base, but there are limits to what  
can be done with local patches.

There are some very intrusive changes that should be done. Ie proper  
mapping of /dev/tty <-> /dev/cu handling to correct behaviour of  
CommPortOwnershipListener (http://java.sun.com/products/javacomm/ 
reference/api/index.html). I dont think this can be done with  
patches. Hence I think, RXTX should be rewritten from scratch de- 
unifying the native code base (and implementing thread safe code on  
the Java side).


How "should" /dev/tty vs /dev/cu be implemented?

=====
The Unix contract is this: An open /dev/tty.xxx port (incomming)  
should be interrupted/auto-closed when opening /dev/cu.xxx (outgoing)  
[if /dev/tty.xxx is not currently handling a communication].  /dev/ 
cu.xxx and /dev/tty.xxx refer to the same device, so owning  
"exclusively" should block both. This should be respected across all  
applications native or Java.

This contract is realizable on OSX with the existing javax.comm  
interface while also respecting (to the biggest part) the contract  
defined by javax.comm.PortOwnershipListener.

The one point where the suggested implementation "breaks" the  
javax.comm contract, is by the fact that one can loose a /dev/tty  
port without calling close. However, the only option I see is to  
always open serial ports "non-exclusively" which would outrule Java  
as a platform for (dormant) applications waiting for incoming  
connections/faxes/etc. There could be a system property to choose the  
intended behavior.
=====

Here is how it could be done on OSX:

Calling port=ComportIdentifier.open("/dev/cu.xxx") opens and owns the  
port exclusively until port.close() is called.
- Java applications listening with a PortOwnershipListener should get  
a PORT_OWNED event reasonably soon.
- Any further attempt by a Java or native application to open "/dev/ 
cu.xxx" or "/dev/tty.xxx" fails.
- /dev/cu.xxx is for "outgoing" connections, so receiving  
PORT_OWNERSHIP_REQUESTED makes little to no sense. With native  
applications it can not be implemented. For Java applications it  
could be implemented (by a hidden communication channel). I think  
it's not worth bothering. If anyone is willing to give up a port to  
others he should use /dev/tty.xxx instead of /dev/cu.xxx.

Registering a PortOwnershipListener on "/dev/cu.xxx" without opening  
it, uses /dev/tty.xxx (native open()) non-exclusively and polls its  
state. PORT_OWNED and PORT_UNOWNED can be produced.

Calling port=ComportIdentifier.open("/dev/tty.xxx") should open the  
port non-exclusively.
- Adding a SerialPortEventListener and reading from the port could be  
allowed while keeping it non-exclusive.
- When port.getOutputStream() is called, the state should be changed  
to an "exclusive" ownership. This may be configurable via a system  
property.
- To return to the non-exclusive state the port must be closed and  
reopened.
- While non-exclusively opened, opening the corresponding /dev/cu.xxx  
produces a PORT_OWNERSHIP_REQUESTED event. Which should be responded  
by closing the port from within the callback (as described in  
java.comm.PortOwnershipListener). If there is a pending read, it will  
return after the listener finishes (with -1 or "0 bytes read").
- Calling write() on the /dev/tty.xxx after somebody opened /dev/ 
cu.xxx will fail with a descriptive IOException.
- Calling read() on the /dev/tty.xxx after somebody opened /dev/ 
cu.xxx will fail with a descriptive IOException (or potentially  
block, see side notes below).

CommPortIdentifier.getCurrentOwner() can be implemented by an  
external call to lsof.

CommPortIdentifier.isCurrentlyOwned() can be implemented by trying an  
open on the /dev/tty.
- It returns true if the port is currently held "exclusively".
- Whether it should also return true on /dev/tty if /dev/tty is  
already opened non-exclusively might be a system property option. In  
general, having several applications waiting for incoming connections  
on the same port will require an application level "arbitration"  
protocol...

[[side note1: One interesting question is, what happens if the  
process holding /dev/tty non-exclusively ignores  
PORT_OWNERSHIP_REQUESTED. Ie after "loosing" a non-exclusively opened  
"dev/tty.xxx" port to another process. One possible implementation  
is, that the port is "regained" when the other process gives up the  
port. This would mean that in the meanwhile read() returns no data,  
and any changes to the configuration of the port are stored but not  
forwarded. I guess, the safe (and simple) way to do this is to make  
the close() mandatory (ie setting the port into an "awaiting_close"  
state which produces IOExceptions to any other call than close). ]]

[[side note2:  Another interesting question is, what should happen if  
several applications open the same /dev/tty.xxx port "non- 
exclusively" and start to change the settings of the device.]]

Regards,
Joachim



On 06.06.2006, at 10:40, Joachim Buechse wrote:

> Should the code work on 10.2?
> ----------
>
> Absolutely. The code should work on NextStep, in fact on any BSD
> unix. I would go as far as saying, this code should work on any
> POSSIX based unix. All that was added is the call "ioctl(fd,
> TIOCEXCL)" to request excusivity of the port:
>
> http://gemma.apple.com/documentation/DeviceDrivers/Conceptual/
> WorkingWSerial/WWSerial_SerialDevs/chapter_2_section_8.html
>
> It is not yet "the perfect solution". Normally an open /dev/tty
> (listen for incomming connection) should be "preemptable" by opening
> a /dev/cu (outgoing connection) for the same port. This is not yet
> implemented as it needs calls outside of POSSIX on OSX.
>
> On "classic" systems (like NextStep) this worked based on the
> "carried detect line". open() on /dev/tty.xxx would block until the
> carrier detect signal was raised. As the device was not "opened"
> opening /dev/cu.xxx worked without a hitch. When they ported to the
> Mac this broke. On Macs the "carier detect" is usually not wired.
> Furthermore FAX modems did no longer raise the line. So the OSX
> implementor defined a new call, which is documented here:
>
> http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00045.html
>
> Best regards,
> Joachim



From sds at dcs.gla.ac.uk  Tue Jun  6 11:22:45 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Tue, 06 Jun 2006 18:22:45 +0100
Subject: [Rxtx] Correct compile flag for HP iPAQ hx4700 running Familiar
	Linux?
Message-ID: <1149614565.19496.10.camel@addu>

Hi,

I'd like to use RXTX 2.1 on my HP iPAQ hx4700. The iPAQ is running
Familiar Linux 0.8.2 (as I recall), with Blackdown Java 1.3.1.

I can compile and run a test program which uses RXTX on my i686 machine,
and it works fine. But I can't seem to get things working quite right on
my PDA.

I compile the code on the laptop with the following commands:
	./configure --host=arm-gnu-linux && make
... as suggested in a post to this list, albeit some time ago. This
compiles, I transfer the files, set up LD_LIBRARY_PATH and CLASSPATH
variables, and get the following error on the PDA:

sds at ipaq-pxa-2:~# java Test
java.lang.UnsatisfiedLinkError: /usr/local/lib/ext/librxtxSerial.so: /usr/local/lib/ext/librxtxSerial.so: cannot open shared object file: No such file or directory thrown while loading gnu.io.RXTXCommDriver
Exception in thread "main"
java.lang.UnsatisfiedLinkError: /usr/local/lib/ext/librxtxSerial.so: /usr/local/lib/ext/librxtxSerial.so: cannot open shared object file: No such file or directory
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1382)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1290)
        at java.lang.Runtime.loadLibrary0(Runtime.java:749)
        at java.lang.System.loadLibrary(System.java:820)
        at
gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:83)
        at Test.<init>(Test.java:9)
        at Test.main(Test.java:32)
sds at ipaq-pxa-2:~# 

Note that I'm copying the files to /usr/local/lib/ext/ along with the
RXTXcomm.jar file, purely to keep things separate from the rest of the
system while testing. The location of the .so files doesn't seem to have
any bearing on whether "java Test" will succeed or not. The contents of
this directory are:

sds at ipaq-pxa-2:~$ ls /usr/local/lib/ext/
RXTXcomm.jar              librxtxParallel-2.1-7.so  librxtxRS485.so
librxtxSerial-2.1-7.so
librxtxI2C-2.1-7.so       librxtxParallel.so        librxtxRaw-2.1-7.so
librxtxSerial.so
librxtxI2C.so             librxtxRS485-2.1-7.so     librxtxRaw.so
sds at ipaq-pxa-2:~$

Test.java fails on the first real line of code I'm using to test that
things are working, prior to real development, and was carefully pinched
from the web:
Enumeration portIdentifiers = CommPortIdentifier.getPortIdentifiers();


I assume that I've gotten my --host flag wrong way back up there at
the ./configure step. But if that's the case, what should I set it to?
Or am I missing something more obvious?


Cheers,
Stephen Strowes,
University of Glasgow.




From tjarvi at qbang.org  Tue Jun  6 13:39:41 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 6 Jun 2006 13:39:41 -0600 (MDT)
Subject: [Rxtx] Serial port code for OS X, future steps
In-Reply-To: <8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
	<CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
	<8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>
Message-ID: <Pine.LNX.4.61.0606061315070.9856@www>


>>
There are some very intrusive changes that should be done. Ie proper
mapping of /dev/tty <-> /dev/cu handling to correct behaviour of
CommPortOwnershipListener (http://java.sun.com/products/javacomm/
reference/api/index.html). I dont think this can be done with
patches. Hence I think, RXTX should be rewritten from scratch de-
unifying the native code base (and implementing thread safe code on
the Java side).
<<

This appears to be a very small amount of functionality for a total 
rewrite.  The port ownership only needs maybe 3 native calls if it is done 
with native calls at all.

Those features which are not part of the Unix standard(s) can be special 
cased.  I'm not sure /dev/cu is standard.  We can look.  I know linux 
deprecated /dev/cua years ago.

Thread safe Java code is not a platform specific issue.

--
Trent Jarvi
tjarvi at qbang.org


From sds at dcs.gla.ac.uk  Wed Jun  7 12:36:43 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Wed, 07 Jun 2006 19:36:43 +0100
Subject: [Rxtx] Expected RXTX behaviour?
In-Reply-To: <1149703900.30891.19.camel@addu>
References: <1149703900.30891.19.camel@addu>
Message-ID: <1149705403.30891.25.camel@addu>

Apologies, caught the problem. Had to append '\r' to the end of the AT
string. A non obvious but stupid mistake... :-)

Final quick question though: How might I stop the echoing of
outputStream data back into the inputStream? I still see the ATI
commands on the inputStream, along with the output from the device.


Cheers,
S.



On Wed, 2006-06-07 at 19:11 +0100, Stephen Strowes wrote:
> Hi,
> 
> I managed to get RXTX to compile for my iPAQ following my previous post
> to this list. Quick query though:
> 
> I want to be able to issue AT commands to a device, and interpret the
> responses. For this, I assume I do the following, in psuedo-form:
> 
> 	CommPortIdentifier.getPortIdentifiers();
> 	// find the correct device id
> 	serialPort= (SerialPort)portID.open("Test");
> 	// Set parameters and flow control
> 	outputStream= serialPort.getOutputStream();
> 	inputStream=  serialPort.getInputStream();
> 
> ... following this, I spawn a thread to respond to DATA_AVAILABLE events
> on serialPort with inputStream, and occasionally write and flush an
> "ATI" onto the outputStream. Nothing complex, I just want to see it
> work.
> 
> I would have expected inputStream to give the same information back from
> an "ATI" command as minicom provides, but instead inputStream only sees
> the "ATI" I put onto the outputStream.
> 
> Have I missed something?
> 
> 
> Cheers,
> S.
> 



From sds at dcs.gla.ac.uk  Wed Jun  7 12:11:40 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Wed, 07 Jun 2006 19:11:40 +0100
Subject: [Rxtx] Expected RXTX behaviour?
Message-ID: <1149703900.30891.19.camel@addu>

Hi,

I managed to get RXTX to compile for my iPAQ following my previous post
to this list. Quick query though:

I want to be able to issue AT commands to a device, and interpret the
responses. For this, I assume I do the following, in psuedo-form:

	CommPortIdentifier.getPortIdentifiers();
	// find the correct device id
	serialPort= (SerialPort)portID.open("Test");
	// Set parameters and flow control
	outputStream= serialPort.getOutputStream();
	inputStream=  serialPort.getInputStream();

... following this, I spawn a thread to respond to DATA_AVAILABLE events
on serialPort with inputStream, and occasionally write and flush an
"ATI" onto the outputStream. Nothing complex, I just want to see it
work.

I would have expected inputStream to give the same information back from
an "ATI" command as minicom provides, but instead inputStream only sees
the "ATI" I put onto the outputStream.

Have I missed something?


Cheers,
S.




From joachim at buechse.de  Wed Jun  7 09:02:13 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 7 Jun 2006 17:02:13 +0200
Subject: [Rxtx] Update of build process for OSX (XCode project)
Message-ID: <62EC47B1-46BD-4ECA-B9EC-C4061D147CDA@buechse.de>

With the help of Dmitry Markman and Brian Schilling I have updated  
(and largely simplifed) the XCode project file for Mac OS X.

Changes:
- compiles a universal binary library with intel=OSX10.4+, ppc=OSX10.2 
+ support
- compiles the Java sources into a JRE1.1 compatible, compressed jar.

Please test on your configuration, especially if you have computers  
running 10.2/10.3 or intel.

Best regards,
Joachim


From joachim at buechse.de  Wed Jun  7 14:36:37 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 7 Jun 2006 22:36:37 +0200
Subject: [Rxtx] Expected RXTX behaviour?
In-Reply-To: <1149705403.30891.25.camel@addu>
References: <1149703900.30891.19.camel@addu> <1149705403.30891.25.camel@addu>
Message-ID: <D3AD6EAF-27BB-455E-9697-86C1121920C3@buechse.de>

Echoing is a feature of the modem. Try ATE0 which works with most  
"rockwell" compatible modems.

Regards,
Joachim


On 07.06.2006, at 20:36, Stephen Strowes wrote:

> Apologies, caught the problem. Had to append '\r' to the end of the AT
> string. A non obvious but stupid mistake... :-)
>
> Final quick question though: How might I stop the echoing of
> outputStream data back into the inputStream? I still see the ATI
> commands on the inputStream, along with the output from the device.
>
>
> Cheers,
> S.
>
>
>
> On Wed, 2006-06-07 at 19:11 +0100, Stephen Strowes wrote:
>> Hi,
>>
>> I managed to get RXTX to compile for my iPAQ following my previous  
>> post
>> to this list. Quick query though:
>>
>> I want to be able to issue AT commands to a device, and interpret the
>> responses. For this, I assume I do the following, in psuedo-form:
>>
>> 	CommPortIdentifier.getPortIdentifiers();
>> 	// find the correct device id
>> 	serialPort= (SerialPort)portID.open("Test");
>> 	// Set parameters and flow control
>> 	outputStream= serialPort.getOutputStream();
>> 	inputStream=  serialPort.getInputStream();
>>
>> ... following this, I spawn a thread to respond to DATA_AVAILABLE  
>> events
>> on serialPort with inputStream, and occasionally write and flush an
>> "ATI" onto the outputStream. Nothing complex, I just want to see it
>> work.
>>
>> I would have expected inputStream to give the same information  
>> back from
>> an "ATI" command as minicom provides, but instead inputStream only  
>> sees
>> the "ATI" I put onto the outputStream.
>>
>> Have I missed something?
>>
>>
>> Cheers,
>> S.
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From g_petrini at yahoo.it  Thu Jun  8 01:41:58 2006
From: g_petrini at yahoo.it (Giacomo Petrini)
Date: Thu, 8 Jun 2006 09:41:58 +0200 (CEST)
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from FieldTalk
Message-ID: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>

Hi,
I'm evaluating the library for the modbus protocol
from FieldTalk
(http://www.modbusdriver.com/fieldtalk/.
I'm using J2SE 5.0 and RXTX 2.1 on win XP.
The problem is that the modbus lib has a method (the
openProtocol method, but maybe there are others) tha
throws the
javax.comm.UnsupportedCommOperationException.
Now, in RXTX 2.1 the namespace has changed in gnu.io,
so the modbus library doesn't work anymore (it look
for things in javax.comm). I've already sent an email
to fieldtalk to see if they are aware of the problem.
The solution should be to use JavaComm + RXTX 2.0. But
I've read somewhere that JavaComm 2.0 does not work
with Java 5.0 and JavaComm 3.0 does not work with RXTX
2.0 so I don't know what to do.

Any ideas?

Thanks Jack

PS: can you make a CC to my personal email
(g_petrini at yahoo.it) too please?

Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 


From rxtx at tapastda.co.uk  Thu Jun  8 02:27:57 2006
From: rxtx at tapastda.co.uk (rxtx@tapastda.co.uk)
Date: Thu, 08 Jun 2006 09:27:57 +0100
Subject: [Rxtx] Win XP and Infrared based serial port
Message-ID: <4487DF8D.5050807@tapastda.co.uk>

I'm attempting to use RXTX 2.1.7 on Win XP with J2SE 5.0 to communicate with a
GSM mobile using a COM port. A peculiarity that I've seen is that whilst I can
communicate successfully with a mobile which uses an infrared based COM port
using the SUN provided javax.comm (v2.0) I cannot use RXTX because it fails to
read anything from the port (i.e. read timeout always occurs returning zero bytes).

I assumed that this could be the result of flow control problems and thus I've
tried setting either software or hardware based flow control on the port however
this has no affect.

Can you suggest any other port configuration changes which might be required to
make such a port work with RXTX.

Thanks
Stu
-- 
Stuart
Tapastda Limited


From tjarvi at qbang.org  Thu Jun  8 05:17:12 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 8 Jun 2006 05:17:12 -0600 (MDT)
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from
	FieldTalk
In-Reply-To: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
References: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606080504480.9856@www>

On Thu, 8 Jun 2006, Giacomo Petrini wrote:

> Hi,
> I'm evaluating the library for the modbus protocol
> from FieldTalk
> (http://www.modbusdriver.com/fieldtalk/.
> I'm using J2SE 5.0 and RXTX 2.1 on win XP.
> The problem is that the modbus lib has a method (the
> openProtocol method, but maybe there are others) tha
> throws the
> javax.comm.UnsupportedCommOperationException.
> Now, in RXTX 2.1 the namespace has changed in gnu.io,
> so the modbus library doesn't work anymore (it look
> for things in javax.comm). I've already sent an email
> to fieldtalk to see if they are aware of the problem.
> The solution should be to use JavaComm + RXTX 2.0. But
> I've read somewhere that JavaComm 2.0 does not work
> with Java 5.0 and JavaComm 3.0 does not work with RXTX
> 2.0 so I don't know what to do.
>
> Any ideas?
>
> Thanks Jack
>


Hi Jack

There are plans for Sun to rerelease JavaComm 2.0 mentioned in the rxtx 
mail-list archives.  When this happens rxtx will release a current rxtx 
2.0 library that works with it.

There are no dates promised by either side but rxtx will do it as soon as 
possible after Sun's rerelease.  Just to give you a feel for the time 
frame, this started last year and no significant progress has been made. 
There have been friendly talks pointing towards solutions (rerelease 2.0) 
but that does not get your application working today.  rxtx is preparing 
for its second release in gnu.io since then.

--
Trent Jarvi
tjarvi at qbang.org




From jredman at ergotech.com  Thu Jun  8 08:47:23 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 08 Jun 2006 08:47:23 -0600
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from
	FieldTalk
In-Reply-To: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
References: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
Message-ID: <4488387B.6040903@ergotech.com>

You could always try a different library, eg.

http://sourceforge.net/projects/jamod

I've only used the slave side since we have our own implementation of 
Modbus Client (and a host of other PLC protocols).  However the client 
side seems to be pretty well supported and fairly widely used.  Since 
the source is there you could change to gnu.io.

I think I should take more of an interest in this issue.  We generally 
run 1.4.2 on Linux, but also have some J9 and old platforms that we 
support that are basically Personal Java.  5.0 on Linux has some 
horrible MDI bugs, to the point of being unusable.   Sounds as though we 
are going to have code compatibility problems across these platforms.

Jim


Giacomo Petrini wrote:
> Hi,
> I'm evaluating the library for the modbus protocol
> from FieldTalk
> (http://www.modbusdriver.com/fieldtalk/.
> I'm using J2SE 5.0 and RXTX 2.1 on win XP.
> The problem is that the modbus lib has a method (the
> openProtocol method, but maybe there are others) tha
> throws the
> javax.comm.UnsupportedCommOperationException.
> Now, in RXTX 2.1 the namespace has changed in gnu.io,
> so the modbus library doesn't work anymore (it look
> for things in javax.comm). I've already sent an email
> to fieldtalk to see if they are aware of the problem.
> The solution should be to use JavaComm + RXTX 2.0. But
> I've read somewhere that JavaComm 2.0 does not work
> with Java 5.0 and JavaComm 3.0 does not work with RXTX
> 2.0 so I don't know what to do.
> 
> Any ideas?
> 
> Thanks Jack
> 
> PS: can you make a CC to my personal email
> (g_petrini at yahoo.it) too please?
> 
> Chiacchiera con i tuoi amici in tempo reale! 
>  http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  8 18:17:23 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 08 Jun 2006 17:17:23 -0700
Subject: [Rxtx] rxtx access is denied error
Message-ID: <4488BE13.2050706@dupreeinc.com>

Hello,

I have been trying to replace the commapi from sun with rxtx for a 
project that communicates with a serial port that is a USB-Serial 
interface.  To be exact, I am using the FTDI VCP driver with one of 
their modules connected to a windows XP system.

I have the RXTX package working pretty well as long as nothing goes wrong.

If a user disconnects the USB port while my java application is running, 
my application goes into an endless loop with lots of messages in the  
errors stream  like the ones below:

    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(481):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.


I believe when this happens the COM port completely disappears and the 
rxtx driver has a heart attack.  Obviously, the user should not do this, 
but my application needs to ideally, correct the situation or as a worse 
case, terminate with a little dignity.  Currently, I have not figured 
out how to catch this error.

The closest I have come is to trap an exception to my input stream read  
that says "No error in readByte"  This error appears to be outside of 
the endless loop of the errors listed above.

Does anybody have an idea of how to identify and trap this error?  Any 
suggestions on how to gracefully recover from it would be greatly 
appreciated!

Thank you for your time,

Doug Thistlethwaite




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060608/9cfca302/attachment-0005.html

From tjarvi at qbang.org  Thu Jun  8 20:54:17 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 8 Jun 2006 20:54:17 -0600 (MDT)
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <4488BE13.2050706@dupreeinc.com>
References: <4488BE13.2050706@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606082022580.1323@www>

On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I have been trying to replace the commapi from sun with rxtx for a project 
> that communicates with a serial port that is a USB-Serial interface.  To be 
> exact, I am using the FTDI VCP driver with one of their modules connected to 
> a windows XP system.
>
> I have the RXTX package working pretty well as long as nothing goes wrong.
>
> If a user disconnects the USB port while my java application is running, my 
> application goes into an endless loop with lots of messages in the  errors 
> stream  like the ones below:
>
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(481):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>
>
> I believe when this happens the COM port completely disappears and the rxtx 
> driver has a heart attack.  Obviously, the user should not do this, but my 
> application needs to ideally, correct the situation or as a worse case, 
> terminate with a little dignity.  Currently, I have not figured out how to 
> catch this error.
>
> The closest I have come is to trap an exception to my input stream read  that 
> says "No error in readByte"  This error appears to be outside of the endless 
> loop of the errors listed above.
>
> Does anybody have an idea of how to identify and trap this error?  Any 
> suggestions on how to gracefully recover from it would be greatly 
> appreciated!
>

Hi Doug

Sadly I don't have a quick solution for you.

Termios has no knowlage about the JVM so it wont be throwing exceptions 
you can catch.

We can return error and set the error number to something reasonable that 
results in an exception.  The No Error message simply means we did not set 
an error number in termios.c.  Those are the line numbers in the code you 
see.  SerialImp.c realizes it errored but does not know much more yet. 
Everything touching the file descriptor is going to error after the port 
is gone presumably.

We don't currently have a plan in place for vanishing (or appearing) com 
ports.

Another example of what we need to think about is what happens if you 
start your application and then plug in the dongle?  Or what if you unplug 
and then plug it in again?

So in each of these three cases, what would the behavior of the (yet to 
be) correct implementation do?

How will the enumerated ports be handled during these changes?

There can also be hints from the OS that could be taken into 
consideration.

We can probably get some exceptions thrown that make sense and null the 
file descriptor when it happens to prevent io attempts.  That would be a 
crude way to let applications know something strange has happened.

Is anyone else tinkering with this problem?

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  9 01:31:29 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 9 Jun 2006 09:31:29 +0200
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <Pine.LNX.4.61.0606082022580.1323@www>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
Message-ID: <AC6EDDDD-0A64-401F-B16B-E484788CDF4A@buechse.de>

Hello Trent,

I am not tinkering with this on the Source Level - but I think it  
should work pretty much the same way as it currently does in OSX.  
When the port goes away you get an IOException thrown for any read/ 
write. It will no longer be in the list of ports from  
CommPortIdentifier.getPortIdentifiers(). When a port (re-)appears it  
is added to the list. It's up to the application to re-check the list  
from time to time.

On Windows you can't do much better then that, because the ports  
don't have useful names. Which USB "virtual com port" is on which  
COMx depends on the order the devices were added. So reconnecting to  
the same device may mean connecting to another port.

Regarding the exception thrown: it would be nice to use an  
IOException subclass but the Exception message should definetly be  
informative also as most applications may want to keep compatibility  
with javax.comm.

Regards,
Joachim


On 09.06.2006, at 04:54, Trent Jarvi wrote:

> On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:
>
>> Hello,
>>
>> I have been trying to replace the commapi from sun with rxtx for a  
>> project
>> that communicates with a serial port that is a USB-Serial  
>> interface.  To be
>> exact, I am using the FTDI VCP driver with one of their modules  
>> connected to
>> a windows XP system.
>>
>> I have the RXTX package working pretty well as long as nothing  
>> goes wrong.
>>
>> If a user disconnects the USB port while my java application is  
>> running, my
>> application goes into an endless loop with lots of messages in  
>> the  errors
>> stream  like the ones below:
>>
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (481):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>
>>
>> I believe when this happens the COM port completely disappears and  
>> the rxtx
>> driver has a heart attack.  Obviously, the user should not do  
>> this, but my
>> application needs to ideally, correct the situation or as a worse  
>> case,
>> terminate with a little dignity.  Currently, I have not figured  
>> out how to
>> catch this error.
>>
>> The closest I have come is to trap an exception to my input stream  
>> read  that
>> says "No error in readByte"  This error appears to be outside of  
>> the endless
>> loop of the errors listed above.
>>
>> Does anybody have an idea of how to identify and trap this error?   
>> Any
>> suggestions on how to gracefully recover from it would be greatly
>> appreciated!
>>
>
> Hi Doug
>
> Sadly I don't have a quick solution for you.
>
> Termios has no knowlage about the JVM so it wont be throwing  
> exceptions
> you can catch.
>
> We can return error and set the error number to something  
> reasonable that
> results in an exception.  The No Error message simply means we did  
> not set
> an error number in termios.c.  Those are the line numbers in the  
> code you
> see.  SerialImp.c realizes it errored but does not know much more yet.
> Everything touching the file descriptor is going to error after the  
> port
> is gone presumably.
>
> We don't currently have a plan in place for vanishing (or  
> appearing) com
> ports.
>
> Another example of what we need to think about is what happens if you
> start your application and then plug in the dongle?  Or what if you  
> unplug
> and then plug it in again?
>
> So in each of these three cases, what would the behavior of the  
> (yet to
> be) correct implementation do?
>
> How will the enumerated ports be handled during these changes?
>
> There can also be hints from the OS that could be taken into
> consideration.
>
> We can probably get some exceptions thrown that make sense and null  
> the
> file descriptor when it happens to prevent io attempts.  That would  
> be a
> crude way to let applications know something strange has happened.
>
> Is anyone else tinkering with this problem?
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From doug at dupreeinc.com  Fri Jun  9 13:09:58 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 09 Jun 2006 12:09:58 -0700
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <Pine.LNX.4.61.0606082022580.1323@www>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
Message-ID: <4489C786.9050504@dupreeinc.com>


Ideally, it would be nice if it would throw an exception and terminate 
the loop.  I am still trying to figure out how to detect the condition 
and recover form it in some form...  I am getting the "No error in 
readByte" exception in my serialEvent() method after an input stream 
read.  It appears to me that the only graceful recovery is to close the 
port and then reopen it when it becomes available.  I can pass the event 
up to the update method in my main frame, but I still can't close the 
port from within that thread.  Any suggestions on how to pass this event 
to a location where the port can be safely closed?

Re: Slow startup in windows XP
I have been looking into this a little closer and have found out the 
following:
System Windows XP Pro 3GHz dual core with 1GB RAM and NO parallel port.
Starting the SerialDemo included with the commapi using the rxtx instead 
of javax.comm takes 60 seconds.
Starting the SerialDemo using rxrx with the rxtxParallel.dll file 
removed takes about 20 seconds.
Modify initialize in RXRXCommDriver.java to not test the parallel ports 
takes less than 1 second.

It would be nice if the initialize routine could detect the presence of 
rxtxParallel.dll file and just skip the whole process if not present.  
Is there an easy way to check for the presence of this file without 
running the parallel port test?

Doug


 

Trent Jarvi wrote:

>On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:
>...
>  
>
>
>Hi Doug
>
>Sadly I don't have a quick solution for you.
>
>Termios has no knowlage about the JVM so it wont be throwing exceptions 
>you can catch.
>
>We can return error and set the error number to something reasonable that 
>results in an exception.  The No Error message simply means we did not set 
>an error number in termios.c.  Those are the line numbers in the code you 
>see.  SerialImp.c realizes it errored but does not know much more yet. 
>Everything touching the file descriptor is going to error after the port 
>is gone presumably.
>
>We don't currently have a plan in place for vanishing (or appearing) com 
>ports.
>
>Another example of what we need to think about is what happens if you 
>start your application and then plug in the dongle?  Or what if you unplug 
>and then plug it in again?
>
>So in each of these three cases, what would the behavior of the (yet to 
>be) correct implementation do?
>
>How will the enumerated ports be handled during these changes?
>
>There can also be hints from the OS that could be taken into 
>consideration.
>
>We can probably get some exceptions thrown that make sense and null the 
>file descriptor when it happens to prevent io attempts.  That would be a 
>crude way to let applications know something strange has happened.
>
>Is anyone else tinkering with this problem?
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060609/911ed787/attachment-0005.html

From Ugo.Landini at Sun.COM  Fri Jun  2 14:23:47 2006
From: Ugo.Landini at Sun.COM (Ugo Landini)
Date: Fri, 02 Jun 2006 22:23:47 +0200
Subject: [Rxtx] OSX 10.4.7 and usb
Message-ID: <44809E53.2070905@sun.com>

Hi, I have installed the library and the native libraries on OSX 10.4.7. 
Then I have run this simple code:

...
while (portList.hasMoreElements()) {
             portId = (CommPortIdentifier) portList.nextElement();
             System.out.println("-> " + portId.getName() + " Port Type:" 
+ portId.getPortType());
...

and the output is:

Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7

Ports found:
-> /dev/tty.Bluetooth-PDA-Sync Port Type:1
-> /dev/cu.Bluetooth-PDA-Sync Port Type:1
-> /dev/tty.Bluetooth-Modem Port Type:1
-> /dev/cu.Bluetooth-Modem Port Type:1

I can't see any USB ports... with javax.comm on linux I could see the 
/dev/ttyUSB stuff, but that's not the case with OSX. Any idea?

tia

uL


From tod at todbot.com  Sun Jun 11 12:04:37 2006
From: tod at todbot.com (Tod E. Kurt)
Date: Sun, 11 Jun 2006 11:04:37 -0700
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <44809E53.2070905@sun.com>
References: <44809E53.2070905@sun.com>
Message-ID: <E2EB14A1-20A7-4611-8F1A-E3D2ABE41F48@todbot.com>

A dumb question, but: do you have the USB serial adapters plugged  
in?  They only show up in /dev when plugged in.  Also, you can verify  
they exist independent of RXTX by doing something like "ls -l /dev/ 
cu.*".

On Jun 2, 2006, at 1:23 PM, Ugo Landini wrote:

> Hi, I have installed the library and the native libraries on OSX  
> 10.4.7.
> Then I have run this simple code:
>
> ...
> while (portList.hasMoreElements()) {
>              portId = (CommPortIdentifier) portList.nextElement();
>              System.out.println("-> " + portId.getName() + " Port  
> Type:"
> + portId.getPortType());
> ...
>
> and the output is:
>
> Experimental:  JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
>
> Ports found:
> -> /dev/tty.Bluetooth-PDA-Sync Port Type:1
> -> /dev/cu.Bluetooth-PDA-Sync Port Type:1
> -> /dev/tty.Bluetooth-Modem Port Type:1
> -> /dev/cu.Bluetooth-Modem Port Type:1
>
> I can't see any USB ports... with javax.comm on linux I could see the
> /dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>
> tia
>
> uL
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>



From lyon at docjava.com  Sun Jun 11 12:14:50 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Sun, 11 Jun 2006 14:14:50 -0400
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <44809E53.2070905@sun.com>
References: <44809E53.2070905@sun.com>
Message-ID: <p06020444c0b20de7d248@[192.168.1.152]>

>Hi Ugo,

Do you have any USB serial ports (like the keyspan 19-HS) plugged
into the mac?
Thanks!
  - DL


>Hi, I have installed the library and the native libraries on OSX 10.4.7.
>Then I have run this simple code:
>
>...
>while (portList.hasMoreElements()) {
>              portId = (CommPortIdentifier) portList.nextElement();
>              System.out.println("-> " + portId.getName() + " Port Type:"
>+ portId.getPortType());
>...
>
>and the output is:
>
>Experimental:  JNI_OnLoad called.
>Stable Library
>=========================================
>Native lib Version = RXTX-2.1-7
>Java lib Version   = RXTX-2.1-7
>
>Ports found:
>-> /dev/tty.Bluetooth-PDA-Sync Port Type:1
>-> /dev/cu.Bluetooth-PDA-Sync Port Type:1
>-> /dev/tty.Bluetooth-Modem Port Type:1
>-> /dev/cu.Bluetooth-Modem Port Type:1
>
>I can't see any USB ports... with javax.comm on linux I could see the
>/dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>
>tia
>
>uL
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx



From dmarkman at mac.com  Sun Jun 11 14:30:27 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Sun, 11 Jun 2006 16:30:27 -0400
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <p06020444c0b20de7d248@[192.168.1.152]>
References: <44809E53.2070905@sun.com> <p06020444c0b20de7d248@[192.168.1.152]>
Message-ID: <B9C1606B-4339-4564-A175-FE83DFFA7D76@mac.com>

afaik
10.4.7 wasn't released yet
it will soon, no doubts


On Jun 11, 2006, at 2:14 PM, Dr. Douglas Lyon wrote:

>> Hi Ugo,
>
> Do you have any USB serial ports (like the keyspan 19-HS) plugged
> into the mac?
> Thanks!
>   - DL
>
>
>> Hi, I have installed the library and the native libraries on OSX  
>> 10.4.7.
>> Then I have run this simple code:
>>
>> ...
>> while (portList.hasMoreElements()) {
>>              portId = (CommPortIdentifier) portList.nextElement();
>>              System.out.println("-> " + portId.getName() + " Port  
>> Type:"
>> + portId.getPortType());
>> ...
>>
>> and the output is:
>>
>> Experimental:  JNI_OnLoad called.
>> Stable Library
>> =========================================
>> Native lib Version = RXTX-2.1-7
>> Java lib Version   = RXTX-2.1-7
>>
>> Ports found:
>> -> /dev/tty.Bluetooth-PDA-Sync Port Type:1
>> -> /dev/cu.Bluetooth-PDA-Sync Port Type:1
>> -> /dev/tty.Bluetooth-Modem Port Type:1
>> -> /dev/cu.Bluetooth-Modem Port Type:1
>>
>> I can't see any USB ports... with javax.comm on linux I could see the
>> /dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>>
>> tia
>>
>> uL
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman



From tjarvi at qbang.org  Sun Jun 11 18:52:59 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 11 Jun 2006 18:52:59 -0600 (MDT)
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <4489C786.9050504@dupreeinc.com>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
	<4489C786.9050504@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606111845430.7274@www>

On Fri, 9 Jun 2006, Doug Thistlethwaite wrote:

>
> Ideally, it would be nice if it would throw an exception and terminate the 
> loop.  I am still trying to figure out how to detect the condition and 
> recover form it in some form...  I am getting the "No error in readByte" 
> exception in my serialEvent() method after an input stream read.  It appears 
> to me that the only graceful recovery is to close the port and then reopen it 
> when it becomes available.  I can pass the event up to the update method in 
> my main frame, but I still can't close the port from within that thread.  Any 
> suggestions on how to pass this event to a location where the port can be 
> safely closed?
>

I've gone through and cleaned up the termios.c layer.  I need to get to a 
windows machine with a USB dongle and see where the ioctl() is being 
called.  Probably the eventLoop.  But all of the ioctls should probably 
result in an IOException during this condition.

I'll probably finish this up Monday night when I can borrow a USB 
dongle.

There is no point in putting the code into CVS yet.  If you are tinkering 
I can mail the patch.  I think we will want to make a couple fixes in 
SerialImp.c to handle errors before it's ready.

--
Trent Jarvi
tjarvi at qbang.org



From bob_tai2001 at yahoo.com  Mon Jun 12 09:42:14 2006
From: bob_tai2001 at yahoo.com (Bob Tai)
Date: Mon, 12 Jun 2006 08:42:14 -0700 (PDT)
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to RXTX
	again
Message-ID: <20060612154214.58219.qmail@web32804.mail.mud.yahoo.com>


thank you Paul, Joachim, Trent and everyone try to
workout the java comm and Rxtx situation.  At least
now I have something that is solid enough to make my
decision.  

thank you,
     Bob

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From Ralph.Buchfelder at gmx.net  Mon Jun 12 15:30:20 2006
From: Ralph.Buchfelder at gmx.net (Ralph Buchfelder)
Date: Mon, 12 Jun 2006 23:30:20 +0200
Subject: [Rxtx] rxtx binaries or porting to XSCALE Windows Mobile 2003 / 2005
Message-ID: <448DDCEC.7090506@gmx.net>

dear group,

i have been carefully reading your homepage, wiki and archives
but there seems to be no detailled information on porting to Windows 
Mobile/CE.

as far as i understood from the 'porting' section you can do porting to 
winCE. but how? do i only need to obtain the sourcecode (which one?) and 
compile this in Microsoft eMbedded Visual C++ for ARM/Xscale?
Any other ways?


unfortunately i must admit that i do have little linux skills but i have 
made my way through gcc and makefiles. right now i need to implement com 
  communication in a J2ME application and found your website as >the< 
solution.

best regards
Ralph Buchfelder

University of Regensburg
Department of Geography

PS: i dont care about Javacomm compliancy (ie. 2.0 or 2.1) - i just need 
a working serial port API in IBM J9 VM.


From paul.klissner at sun.com  Wed Jun 14 18:12:58 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Wed, 14 Jun 2006 17:12:58 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
Message-ID: <4490A60A.9090305@sun.com>

Hello RxTx community,

I finally think I have a compromise in place that will stand in the gap.

If you go to http://www.sun.com and search for javax.comm, you'll
get taken to a download page, where now users can get a copy of the
comm.jar file out of 2.0.3, along with just a license and a README.

I trust this will suffice until such time as RxTx decided to implement
their own java classes or we can get a JSR going to mitigate some
of the problems (the readme in the comm.jar 2.0.3 zip file
contains my thoughts on that).

Thanks,
Paul



From tjarvi at qbang.org  Wed Jun 14 21:15:35 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 14 Jun 2006 21:15:35 -0600 (MDT)
Subject: [Rxtx] rxtx-2.0-7 (final) src is in CVS
Message-ID: <Pine.LNX.4.61.0606142100500.2742@www>


I wasn't expecting to be working on rxtx 2.0 tonight :)

Thanks go out to Paul Klissner for his work in making the coming release 
of rxtx-2.0-7 possible for users that require package javax.comm on many 
platforms.

Most people know that rxtx 2.0 is for use with Sun's CommAPI 2.0 for 
Solaris or the Generic CommAPI 2.0-3 available for download at Sun.  If 
you need javax.comm packages on many platforms, you are probably 
interested.  If you use rxtx 2.1 in package gnu.io, then you are not going 
to care much.

I've tried to update the rxtx 2.0 src directory in preparation for 
rxtx-2.0-7 (final).  Linux should compile.  Windows will compile if you 
generate your own .def files (I'll generate these tomorrow).  If you have 
some time to do basic testing of the source, I'd appreciate it.  The 
source should be good but you may find classes not found.  This source is 
a backport from rxtx 2.1.

I wanted to get things started so anyone interested on Mac OS X could get 
a head start.

All of this is in CVS.  http://www.rxtx.org/cvs.html

I suspect we will have binaries for testing in a couple days if you are 
unable to compile.   Consider this a smoke test.

--
Trent Jarvi
tjarvi at qbang.org


From legolas.w at gmail.com  Wed Jun 14 22:04:28 2006
From: legolas.w at gmail.com (Legolas Woodland)
Date: Wed, 14 Jun 2006 21:04:28 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <4490A60A.9090305@sun.com>
References: <4490A60A.9090305@sun.com>
Message-ID: <87ee9b170606142104p745fcef0vea622fbc8f528bfc@mail.gmail.com>

is there anything new in this version of javax.comm ?
thanks


On 6/14/06, Paul Klissner <paul.klissner at sun.com> wrote:
>
> Hello RxTx community,
>
> I finally think I have a compromise in place that will stand in the gap.
>
> If you go to http://www.sun.com and search for javax.comm, you'll
> get taken to a download page, where now users can get a copy of the
> comm.jar file out of 2.0.3, along with just a license and a README.
>
> I trust this will suffice until such time as RxTx decided to implement
> their own java classes or we can get a JSR going to mitigate some
> of the problems (the readme in the comm.jar 2.0.3 zip file
> contains my thoughts on that).
>
> Thanks,
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060614/5ff4dfbc/attachment-0005.html

From joachim at buechse.de  Thu Jun 15 07:22:48 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 15 Jun 2006 15:22:48 +0200
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
Message-ID: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>

Good day!

Some of my users report problems using RXTX 2.1.7 on Windows98 to  
communicate with an FTDI FT245BM chip (using their latest VCP  
driver). Either no ports are being shown (ie returned form  
CommPortIdentifier.getPortIdentifiers()) or the transfers fail.

Did anyone run into similar Problems with Win98??

Best regards,
Joachim



From ajmas at sympatico.ca  Thu Jun 15 08:12:28 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Thu, 15 Jun 2006 10:12:28 -0400
Subject: [Rxtx] API change question
Message-ID: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

How closely do you follow the Java Communication API spec? The reason I ask is because I would be interested in augmenting the CommPortIdentifier class to include a getDisplayName() method. By default it would return the same value as getName(), but would provide the possibility of displaying a 'user friendly' name, for platforms where the display name is not the same as the device name. An example of this is on MacOS X, where currently the names seem to be of the form /dev/cu.* and /dev/tty.*, yet what the expects to see is simply the part after the full-stop. Although I could move this logic into the Java code, it would be nice to see it transparent to the Java code.

Andre




From ajmas at sympatico.ca  Thu Jun 15 08:16:22 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Thu, 15 Jun 2006 10:16:22 -0400
Subject: [Rxtx] Package to use
Message-ID: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

While the Java API spec refers to javax.comm, I see that only gnu.io is provide by the rxtx project. Should our projects refer to the gnu.io package or the javax.comm API?

Andre



From joachim at buechse.de  Thu Jun 15 08:45:05 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 15 Jun 2006 16:45:05 +0200
Subject: [Rxtx] API change question
In-Reply-To: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>

Hello Andre,

the /dev/cu and /dev/tty have different semantics on OS X. It is much  
more than a simply naming issue to unify them, see my recent mail to  
the list...

Best regards,
Joachim


On 15.06.2006, at 16:12, Andre-John Mas wrote:

> Hi,
>
> How closely do you follow the Java Communication API spec? The  
> reason I ask is because I would be interested in augmenting the  
> CommPortIdentifier class to include a getDisplayName() method. By  
> default it would return the same value as getName(), but would  
> provide the possibility of displaying a 'user friendly' name, for  
> platforms where the display name is not the same as the device  
> name. An example of this is on MacOS X, where currently the names  
> seem to be of the form /dev/cu.* and /dev/tty.*, yet what the  
> expects to see is simply the part after the full-stop. Although I  
> could move this logic into the Java code, it would be nice to see  
> it transparent to the Java code.
>
> Andre
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From lyon at docjava.com  Thu Jun 15 10:16:29 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Thu, 15 Jun 2006 12:16:29 -0400
Subject: [Rxtx] cu.modem != /dev/ttya on mac.
In-Reply-To: <763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
	<763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>
Message-ID: <p0602046cc0b7378a95b0@[192.168.1.152]>

>Hi All,

I think that Joachim is correct. For the longest time,
I have been trying to figure out how to direct dial using
the cu.modem on the mac under os x.

As a less-than-optimal approach to auto-dialing, I have used
a keyspan USB 19HS adapter, along with an external modem, to
obtain the dialing feature.

Ideally, it would be better to dial with the built-in modem...but that did not
always seem to work, for some reason. Have others had some experience with
using the built in modem for dialing on the mac?

Thanks!
  - Doug


>Hello Andre,
>
>the /dev/cu and /dev/tty have different semantics on OS X. It is much?
>more than a simply naming issue to unify them, see my recent mail to?
>the list...
>
>Best regards,
>Joachim
>



From doug at dupreeinc.com  Thu Jun 15 14:52:50 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 15 Jun 2006 13:52:50 -0700
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
In-Reply-To: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
References: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
Message-ID: <4491C8A2.8090108@dupreeinc.com>

Hi Joachim,

I have been doing a lot with the new FTDI driver with win XP and have 
not had that particular problem.  I did notice that the new driver 
(dated May19th, 2006) is only for XP, Server 2003, and 2000.  Are they 
trying to use the 2.00.00 drivers or the old 1.09.06 version.  I am 
using a FT232R based module, but it uses the same drivers and I assume 
it would have the same problems.  Let me know which driver they are 
using and I can load up a 98 system here and see if  I can duplicate the 
problem.

Doug

Joachim Buechse wrote:

>Good day!
>
>Some of my users report problems using RXTX 2.1.7 on Windows98 to  
>communicate with an FTDI FT245BM chip (using their latest VCP  
>driver). Either no ports are being shown (ie returned form  
>CommPortIdentifier.getPortIdentifiers()) or the transfers fail.
>
>Did anyone run into similar Problems with Win98??
>
>Best regards,
>Joachim
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From matthewhepp at yahoo.com  Thu Jun 15 17:34:47 2006
From: matthewhepp at yahoo.com (Matthew Hepp)
Date: Thu, 15 Jun 2006 16:34:47 -0700 (PDT)
Subject: [Rxtx] Wither the XCode project?
Message-ID: <20060615233447.48064.qmail@web50311.mail.yahoo.com>

Either I don't know how to properly use CVS (entirely possibl), or the XCode
project is not making through the update properly. Doing a "cvs update" against
2.1-7 creates an XCode folder in MACOSX_IDE, and therein a
LibSerialUniversal.xcodeproj, but trying to open it yields a "Unable to Open
Project - Project rxtx-devel/MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj
cannot be opened because it is missing its project.pbxproj file" error. Showing
package contents reveals just the cvs-related files. Perhaps this is why
previous xcode projects have been saved as an sit.hqx - to retain the resource
fork?

Can someone point me in the right direction?

Thanks,

Matt

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Thu Jun 15 19:53:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 19:53:06 -0600 (MDT)
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
In-Reply-To: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
References: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
Message-ID: <Pine.LNX.4.61.0606151944070.23137@www>

On Thu, 15 Jun 2006, Joachim Buechse wrote:

> Good day!
>
> Some of my users report problems using RXTX 2.1.7 on Windows98 to
> communicate with an FTDI FT245BM chip (using their latest VCP
> driver). Either no ports are being shown (ie returned form
> CommPortIdentifier.getPortIdentifiers()) or the transfers fail.
>
> Did anyone run into similar Problems with Win98??
>

Hi Joachim

It has been a long time since I've tested win98.  I know rxtx-2.1-7pre16 
did get testing on win98 with ~jdk 1.3 though.  I wonder if jdks are still 
tested on that platform.

With win98 you usually have older boxes.  They can be short on CPU and 
memory.  Enumeration should work but I could picture runtime performance 
issues on win98.

The enumeration problems could result from other copies of your 
application if various states of decay still holding onto the port.  When 
things go wrong, people also like to open other terminal software to see 
whats going on which can interfere.  You can't open a windows port with 
two apps.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Thu Jun 15 20:08:53 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 20:08:53 -0600 (MDT)
Subject: [Rxtx] API change question
In-Reply-To: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606151954270.23137@www>

On Thu, 15 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> How closely do you follow the Java Communication API spec?

I can explain how this worked in the past.  How we do it in the future is 
open for discussion.

In the past we have tried to follow it as close as possible in gnu.io 
(rxtx 2.1).  We have added extensions but try to discourage their use. 
The extensions are clearly marked as such in the source code and javadocs.

rxtx 2.0 was intended to be a strict implementation of part of the spec. 
We let Sun's interfaces decide what methods can be called. There are 
differences not covered by the spec such as default values.  Thats not 
intentional but rather hard to avoid.

--
Trent Jarvi
tjarvi at qbang.org





From tjarvi at qbang.org  Thu Jun 15 21:09:11 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 21:09:11 -0600 (MDT)
Subject: [Rxtx] Package to use
In-Reply-To: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606152026120.23137@www>

On Thu, 15 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> While the Java API spec refers to javax.comm, I see that only gnu.io is 
> provide by the rxtx project. Should our projects refer to the gnu.io 
> package or the javax.comm API?
>

Hi Andre

Lets see if I can give a fair and balanced answer to that.

If you are starting a new project and want to use RXTX, I would recommend 
using gnu.io.  The community support for gnu.io will not be going away 
anytime soon.  You can switch between gnu.io (2.1) and javax.comm (2.0) 
fairly easily.  They are not intended to be incompatible.  You just change 
package names and libs.

You can also consider the combination of rxtx 2.0 with Sun's commapi 
2.0-3.  This is considered a stop-gap measure by Sun for previous users of 
that combination.  Together rxtx 2.0 and Sun CommAPI 2.0 work in namespace 
javax.comm for programmers.

Finally, you can opt to just use Sun's oferrings in CommAPI 3.0 without 
rxtx.  That would be in namespace javax.comm also.  CommAPI 3.0 may be 
of more interest to you if you are looking at POS with Sun computers. 
Rxtx does not currently support the changes in CommAPI 3.0 or have firm 
plans to do so.  That does not mean we wouldn't implement them.  It just 
means nobody has contributed code yet.

You can't combine rxtx with CommAPI 3.0 for technical reasons that wont 
likely be fixed soon.

It's up to you as far as what you use.  We like to provide the freedom so 
you can choose.  Realistically, we will be supporting gnu.io mainly 
because we have some control over that name space and can support it.

Things may happen in the future that enable rxtx to provide more support 
in the javax namespace but that has not happened yet.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun 16 00:33:06 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 08:33:06 +0200
Subject: [Rxtx] Wither the XCode project?
In-Reply-To: <20060615233447.48064.qmail@web50311.mail.yahoo.com>
References: <20060615233447.48064.qmail@web50311.mail.yahoo.com>
Message-ID: <D30D660F-A49B-464E-AE4C-6B4563893682@buechse.de>

Hello Matthew,

could you please send me the contents of your

   rxtx-devel/CVS
   rxtx-devel/MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj/CVS

directories as a zip to my personal email address. This should  
indicate why the file is not checked out. I can see that it exists on  
the correct branch in the repository, so something must have gone  
wrong during the "cvs update"...

Best regards,
Joachim

On 16.06.2006, at 01:34, Matthew Hepp wrote:

> Either I don't know how to properly use CVS (entirely possibl), or  
> the XCode
> project is not making through the update properly. Doing a "cvs  
> update" against
> 2.1-7 creates an XCode folder in MACOSX_IDE, and therein a
> LibSerialUniversal.xcodeproj, but trying to open it yields a  
> "Unable to Open
> Project - Project rxtx-devel/MACOSX_IDE/XCode/ 
> LibSerialUniversal.xcodeproj
> cannot be opened because it is missing its project.pbxproj file"  
> error. Showing
> package contents reveals just the cvs-related files. Perhaps this  
> is why
> previous xcode projects have been saved as an sit.hqx - to retain  
> the resource
> fork?
>
> Can someone point me in the right direction?



From joachim at buechse.de  Fri Jun 16 10:41:20 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 18:41:20 +0200
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <p06230903c0b88613dca6@[10.0.1.7]>
References: <p06230903c0b88613dca6@[10.0.1.7]>
Message-ID: <03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>

Hello Bob,

until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was  
behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if  
Trent has migrated all recent changes from 2.1 to 2.0.

I have added the XCode project and updated documentation only to the  
gnu.io branch. Once the 2.0 implementation is up to date I will copy  
over the documentation/build files make them work.

Best regards,
Joachim

On 16.06.2006, at 18:07, Bob Jacobsen wrote:

> I'm one of the developers for the JMRI project, which provides  
> model railroad software in Java.  We've been using RXTX to provide  
> serial port access on MacOS X and Linux; we use the old javax.comm  
> 2.0 on Windows, OS/2 and Solaris.  Because of that, we need to stay  
> with RXTX 2.0, not 2.1
>
> We've been using the 2.0-pre17 installer for a long time, but it's  
> not compatible with Intel macs.
>
> Can you point me to where I can find the right files for RXTX 2.0  
> to package with the program?
>
> The current situation is confusing to me.  I've been pointed to  
> recent 2.1 versions (but we need the javax.comm names), to an even  
> older installer, etc.  I've been reading that some versions require  
> an installer, and others don't, but I haven't been able to figure  
> out which (if any) of those are where in CVS.
>
> I'd really appreciate a clear statement of what files to use and  
> what to do with them that I can pass on to our users.
>
> I'm more than happy to put files in the local classpath, have users  
> run an installer, or anything else.  Whatever is easiest for you.
>
> Thanks!  I really appreciate all that you do to keep RXTX working.
>
> Bob
> -- 
> Bob Jacobsen +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG



From joachim at buechse.de  Fri Jun 16 09:59:28 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 17:59:28 +0200
Subject: [Rxtx] Wither the XCode project?
In-Reply-To: <20060616150240.49464.qmail@web50309.mail.yahoo.com>
References: <20060616150240.49464.qmail@web50309.mail.yahoo.com>
Message-ID: <D9935E05-2B83-488D-86DD-42599E229052@buechse.de>

Hello Matthew,

you have checked out the trunk (which is the 2.0.7 javax.comm.xxx  
release). For rxtx-2.1.7 (gnu.io.xxx release) you need to check out  
the branch

      commapi-0-0-1

The easiest way to do this is to download the rxtx src archive,  
unpack it and then do a cvs up inside the decompressed tree.  
Optionally you could do a

      cvs co -r commapi-0-0-1

but this will take much longer!

Best regards,
Joachim

When you do a cvs status it will show the sticky tag.

41:~/jdevelop/rxtx-2.1-7r2 joachim$ cvs status README.OSX
===================================================================
File: README.OSX        Status: Up-to-date

    Working revision:    1.1.2.1
    Repository revision: 1.1.2.1 /usr/local/cvsroot/rxtx-devel/Attic/ 
README.OSX,v
    Sticky Tag:          commapi-0-0-1 (branch: 1.1.2)
    Sticky Date:         (none)
    Sticky Options:      (none)




On 16.06.2006, at 17:02, Matthew Hepp wrote:

> %cvs status README.MACOSX
> ===================================================================
> File: README.MACOSX     Status: Up-to-date
>
>    Working revision:    1.1
>    Repository revision: 1.1     /usr/local/cvsroot/rxtx-devel/ 
> README.MACOSX,v
>    Sticky Tag:          (none)
>    Sticky Date:         (none)
>    Sticky Options:      (none)



From tjarvi at qbang.org  Fri Jun 16 16:31:18 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Fri, 16 Jun 2006 16:31:18 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
Message-ID: <Pine.LNX.4.61.0606161630030.14139@www>

On Fri, 16 Jun 2006, Joachim Buechse wrote:

> Hello Bob,
>
> until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was
> behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if
> Trent has migrated all recent changes from 2.1 to 2.0.
>

The src/ directory and configure.in/configure files should be fine.  I 
have not touched the Mac OS X directories.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sat Jun 17 02:39:55 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sat, 17 Jun 2006 10:39:55 +0200
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <Pine.LNX.4.61.0606161630030.14139@www>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
Message-ID: <350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>

Hello Trent,

apparently the IOEXCL changes have not made it into 2.0. I will add  
them to achieve a minimal diff between 2.0 and 2.1.

One other thing that bugs me for a while...

Shouldn't we replace "if !defined(TIOCSERGETLSR) && !defined(WIN32)"  
by a definition of its own "if defined(DRAINTHREAD)"? I think this  
would make the code clearer for people starting to read it.

Regards,
Joachim


On 17.06.2006, at 00:31, Trent Jarvi wrote:

> On Fri, 16 Jun 2006, Joachim Buechse wrote:
>
>> Hello Bob,
>>
>> until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was
>> behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if
>> Trent has migrated all recent changes from 2.1 to 2.0.
>>
>
> The src/ directory and configure.in/configure files should be fine.  I
> have not touched the Mac OS X directories.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From tropicsu at hotmail.com  Sat Jun 17 09:32:48 2006
From: tropicsu at hotmail.com (Yoke K)
Date: Sat, 17 Jun 2006 15:32:48 +0000
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
Message-ID: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>

Hi,

I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to work with 
MAC OS X.
I am using iTegno 3000 - USB GPRS Modem.

Files in /dev and a symbolic link as follows:

crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 -> tty.usbserial

In my SendMessage.java, I have this line:
CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");

Appreciate any help ?

- Jon


Errors as follows:

>>INFO: SMSLib API for Java / v1.2.2
>>INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>INFO: JRE Version: 1.5.0_06
>>INFO: JRE Impl Version: 1.5.0_06-64
>>INFO: O/S: Mac OS X / ppc / 10.4.6
>>INFO: Using Wavecom (Generic) AT handler.

SendMessage(): Send a message.
  Using SMSLib API for Java v1.2.2

Connecting ..... :
>>INFO: CSerialDriver(): Connecting...
Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
>>INFO: CSerialDriver(): Disconnecting...
gnu.io.NoSuchPortException
        at 
gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:218)
        at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
        at org.smslib.CService.connect(CService.java:197)
        at SendMessage.main(SendMessage.java:38)

_________________________________________________________________
Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/



From tjarvi at qbang.org  Sat Jun 17 10:12:30 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 10:12:30 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
	<350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
Message-ID: <Pine.LNX.4.61.0606171010060.14139@www>

On Sat, 17 Jun 2006, Joachim Buechse wrote:

> Hello Trent,
>
> apparently the IOEXCL changes have not made it into 2.0. I will add
> them to achieve a minimal diff between 2.0 and 2.1.
>

Hi Joachim

As I recall the IOEXCL change was after 2.1-7.  I was just syncing with 
2.1-7.  We can release 2.1-8 and 2.0-8 with the same changes.

> One other thing that bugs me for a while...
>
> Shouldn't we replace "if !defined(TIOCSERGETLSR) && !defined(WIN32)"
> by a definition of its own "if defined(DRAINTHREAD)"? I think this
> would make the code clearer for people starting to read it.
>


Sure.  We can do that for -8.  The TIOCSERGETLSR code should be a special 
case not the expected.  I think only Linux uses it.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Sat Jun 17 10:48:21 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 10:48:21 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <Pine.LNX.4.61.0606171010060.14139@www>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
	<350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
	<Pine.LNX.4.61.0606171010060.14139@www>
Message-ID: <Pine.LNX.4.61.0606171047310.14139@www>

On Sat, 17 Jun 2006, Trent Jarvi wrote:

> On Sat, 17 Jun 2006, Joachim Buechse wrote:
>
>> Hello Trent,
>>
>> apparently the IOEXCL changes have not made it into 2.0. I will add
>> them to achieve a minimal diff between 2.0 and 2.1.
>>
>
> Hi Joachim
>
> As I recall the IOEXCL change was after 2.1-7.  I was just syncing with
> 2.1-7.  We can release 2.1-8 and 2.0-8 with the same changes.
>

We could just move to 2.1-8 and 2.0-8.

--
Trent Jarvi
tjarvi at qbang.org


From brian.t.lamb at gmail.com  Tue Jun 13 13:54:13 2006
From: brian.t.lamb at gmail.com (Brian Lamb)
Date: Tue, 13 Jun 2006 15:54:13 -0400
Subject: [Rxtx] Windows XP Installation
Message-ID: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>

I've not installed Java packages on Windows before and am unsure how to
proceed. All the documentation I've seen provides detailed instructions on
how to install on Linux or Solaris. I was wondering how to install rxtx on
Windows XP.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060613/6f68cd5c/attachment-0005.html

From tjarvi at qbang.org  Sat Jun 17 13:57:03 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 13:57:03 -0600 (MDT)
Subject: [Rxtx] Windows XP Installation
In-Reply-To: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>
References: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0606171356120.14139@www>

On Tue, 13 Jun 2006, Brian Lamb wrote:

> I've not installed Java packages on Windows before and am unsure how to
> proceed. All the documentation I've seen provides detailed instructions on
> how to install on Linux or Solaris. I was wondering how to install rxtx on
> Windows XP.
>

Hi Brian

Which rxtx version are you trying to install?

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sun Jun 18 10:41:44 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sun, 18 Jun 2006 18:41:44 +0200
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
References: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
Message-ID: <8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>

Hello Jon,

 From OSX's standpoint a symbolic link is not a device (as far as I  
know). What stops you from using tty.usbserial? Did you try hard- 
linking?

Regards,
Joachim

On 17.06.2006, at 17:32, Yoke K wrote:
> Hi,
>
> I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to  
> work with
> MAC OS X.
> I am using iTegno 3000 - USB GPRS Modem.
>
> Files in /dev and a symbolic link as follows:
>
> crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
> crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
> lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->  
> tty.usbserial
>
> In my SendMessage.java, I have this line:
> CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
>
> Appreciate any help ?
>
> - Jon
>
>
> Errors as follows:
>
>>> INFO: SMSLib API for Java / v1.2.2
>>> INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>> INFO: JRE Version: 1.5.0_06
>>> INFO: JRE Impl Version: 1.5.0_06-64
>>> INFO: O/S: Mac OS X / ppc / 10.4.6
>>> INFO: Using Wavecom (Generic) AT handler.
>
> SendMessage(): Send a message.
>   Using SMSLib API for Java v1.2.2
>
> Connecting ..... :
>>> INFO: CSerialDriver(): Connecting...
> Experimental:  JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
>>> INFO: CSerialDriver(): Disconnecting...
> gnu.io.NoSuchPortException
>         at
> gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java: 
> 218)
>         at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
>         at org.smslib.CService.connect(CService.java:197)
>         at SendMessage.main(SendMessage.java:38)
>
> _________________________________________________________________
> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Sun Jun 18 10:56:55 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 12:56:55 -0400
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>
References: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
	<8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>
Message-ID: <7B6834E3-F41D-46B6-B979-55466BC73859@sympatico.ca>

Have you been able to get any other software to talk with your
modem? What port is it using? Have tried using the cu.usbserial
instead?

Andre

On 18-Jun-06, at 12:41 , Joachim Buechse wrote:

> Hello Jon,
>
>  From OSX's standpoint a symbolic link is not a device (as far as I
> know). What stops you from using tty.usbserial? Did you try hard-
> linking?
>
> Regards,
> Joachim
>
> On 17.06.2006, at 17:32, Yoke K wrote:
>> Hi,
>>
>> I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to
>> work with
>> MAC OS X.
>> I am using iTegno 3000 - USB GPRS Modem.
>>
>> Files in /dev and a symbolic link as follows:
>>
>> crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
>> crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
>> lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->
>> tty.usbserial
>>
>> In my SendMessage.java, I have this line:
>> CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
>>
>> Appreciate any help ?
>>
>> - Jon
>>
>>
>> Errors as follows:
>>
>>>> INFO: SMSLib API for Java / v1.2.2
>>>> INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>>> INFO: JRE Version: 1.5.0_06
>>>> INFO: JRE Impl Version: 1.5.0_06-64
>>>> INFO: O/S: Mac OS X / ppc / 10.4.6
>>>> INFO: Using Wavecom (Generic) AT handler.
>>
>> SendMessage(): Send a message.
>>   Using SMSLib API for Java v1.2.2
>>
>> Connecting ..... :
>>>> INFO: CSerialDriver(): Connecting...
>> Experimental:  JNI_OnLoad called.
>> Stable Library
>> =========================================
>> Native lib Version = RXTX-2.1-7
>> Java lib Version   = RXTX-2.1-7
>>>> INFO: CSerialDriver(): Disconnecting...
>> gnu.io.NoSuchPortException
>>         at
>> gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:
>> 218)
>>         at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
>>         at org.smslib.CService.connect(CService.java:197)
>>         at SendMessage.main(SendMessage.java:38)
>>
>> _________________________________________________________________
>> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Sun Jun 18 17:33:08 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 19:33:08 -0400
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
Message-ID: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>

Hi,

I am have a program that I wrote in Java to communicate with a  
Bluetooth GPS device. I am
trying to get this working on my Mac, but I keep getting told that:

gnu.io.PortInUseException: Unknown Application

but

portIdentifier.isCurrentlyOwned()

returns false and when I do lsof on the device I am trying to connect  
to, I see no application
using it. As the same time if I go to the command line and use  
minicom I have no issues. The
exception happens with this call:

CommPort commPort = portIdentifier.open(null,0);

Any suggestions?

Andre


From ajmas at sympatico.ca  Sun Jun 18 17:45:11 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 19:45:11 -0400
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
Message-ID: <30245B30-682D-4EAE-8084-8227B719F10D@sympatico.ca>

BTW My code snippet is:

     private InputStream connectToSerial () throws IOException,  
Exception
     {
         InputStream in = null;

         Enumeration portEnum = CommPortIdentifier.getPortIdentifiers();
         while ( portEnum.hasMoreElements() )
         {
             CommPortIdentifier portIdentifier = (CommPortIdentifier)  
portEnum.nextElement();
             System.out.println(portIdentifier.getName() + " - " +  
portIdentifier.getPortType() );
         }

         CommPortIdentifier portIdentifier =  
CommPortIdentifier.getPortIdentifier("/dev/cu.BTGPS-SPPslave-1");
         System.out.println("current owner: " +  
portIdentifier.getCurrentOwner());
         if ( portIdentifier.isCurrentlyOwned() )
         {
             System.out.println("Error: Port is currently in use");
             return null;
         }
         else
         {
             CommPort commPort = portIdentifier.open(this.getClass 
().getName(),2000);

             if ( commPort instanceof SerialPort )
             {
                 SerialPort serialPort = (SerialPort) commPort;
                 serialPort.setSerialPortParams 
(4800,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE 
);
                 in = serialPort.getInputStream();

                 return in;
             }
             else
             {
                 System.out.println("Error: Only serial ports are  
handled.");
             }
         }


         return in;
     }


On 18-Jun-06, at 19:33 , Andr?-John Mas wrote:

> Hi,
>
> I am have a program that I wrote in Java to communicate with a
> Bluetooth GPS device. I am
> trying to get this working on my Mac, but I keep getting told that:
>
> gnu.io.PortInUseException: Unknown Application
>
> but
>
> portIdentifier.isCurrentlyOwned()
>
> returns false and when I do lsof on the device I am trying to connect
> to, I see no application
> using it. As the same time if I go to the command line and use
> minicom I have no issues. The
> exception happens with this call:
>
> CommPort commPort = portIdentifier.open(null,0);
>
> Any suggestions?
>
> Andre
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From joachim at buechse.de  Mon Jun 19 05:54:49 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 13:54:49 +0200
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de>

This is most likely due to a problem with lock files. If you have  
downloaded the binaries of 2.17 rxtx will try to create non-standard  
lock files on OSX. We have since changed the code to use OSX device  
locking - however the binaries have not been updated yet. The 2.18  
release fixing this issue is due shortly.

Regards,
Joachim

On 19.06.2006, at 01:33, Andr?-John Mas wrote:

> Hi,
>
> I am have a program that I wrote in Java to communicate with a
> Bluetooth GPS device. I am
> trying to get this working on my Mac, but I keep getting told that:
>
> gnu.io.PortInUseException: Unknown Application
>
> but
>
> portIdentifier.isCurrentlyOwned()
>
> returns false and when I do lsof on the device I am trying to connect
> to, I see no application
> using it. As the same time if I go to the command line and use
> minicom I have no issues. The
> exception happens with this call:
>
> CommPort commPort = portIdentifier.open(null,0);
>
> Any suggestions?
>
> Andre
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From joachim at buechse.de  Mon Jun 19 06:44:27 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 14:44:27 +0200
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <4490A60A.9090305@sun.com>
References: <4490A60A.9090305@sun.com>
Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>

Hello Paul,

I just downloaded the "generic" javax.comm version now available. A  
first check indicates, that it was compiled with a JDK 1.4 javac  
without setting the target classfile version. In other words in can  
not be loaded by 1.1-1.3 VMs (or PersonalJava).

Do you see any chance to provide a version compiled with classfile  
format 45.3 (ie JVM1.1).

---
52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose  
javax.comm.SerialPort | head -5
Compiled from "SerialPort.java"
public abstract class javax.comm.SerialPort extends javax.comm.CommPort
   SourceFile: "SerialPort.java"
   minor version: 0
   major version: 48
---

Best regards,
Joachim


On 15.06.2006, at 02:12, Paul Klissner wrote:

> Hello RxTx community,
>
> I finally think I have a compromise in place that will stand in the  
> gap.
>
> If you go to http://www.sun.com and search for javax.comm, you'll
> get taken to a download page, where now users can get a copy of the
> comm.jar file out of 2.0.3, along with just a license and a README.
>
> I trust this will suffice until such time as RxTx decided to implement
> their own java classes or we can get a JSR going to mitigate some
> of the problems (the readme in the comm.jar 2.0.3 zip file
> contains my thoughts on that).
>
> Thanks,
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Mon Jun 19 09:11:45 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Mon, 19 Jun 2006 11:11:45 -0400
Subject: [Rxtx] Examples added to Wiki
Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

I have added a couple of examples to the Wiki:

http://rxtx.qbang.org/wiki/index.php/Examples

If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :)

Andre



From paul.klissner at sun.com  Mon Jun 19 10:42:47 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Mon, 19 Jun 2006 09:42:47 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>
References: <4490A60A.9090305@sun.com>
	<03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>
Message-ID: <4496D407.1090609@sun.com>

Joachim Buechse wrote:
> Hello Paul,
> 
> I just downloaded the "generic" javax.comm version now available. A  
> first check indicates, that it was compiled with a JDK 1.4 javac  
> without setting the target classfile version. In other words in can  
> not be loaded by 1.1-1.3 VMs (or PersonalJava).
> 
> Do you see any chance to provide a version compiled with classfile  
> format 45.3 (ie JVM1.1).
> 
> ---
> 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose  
> javax.comm.SerialPort | head -5
> Compiled from "SerialPort.java"
> public abstract class javax.comm.SerialPort extends javax.comm.CommPort
>    SourceFile: "SerialPort.java"
>    minor version: 0
>    major version: 48
> ---

I cannot promise when I can do that. Since we thought we were done
with javax.comm, the build environment got moved around, and right
now it doesn't even compile in it's new home.  I tried and it was
not cooperative at all. I was never impressed with that workspace
(in fact far far from it, it is a mess, which is why I migrated 3.0
to ant and never looked back).  It will take some real determination
for me to rebuild it, and frankly, right now I'm swamped.  If I can
find a bit of time over the next few weeks to do it, and it isn't
too bad an ordeal, I will.

Posting that will give me an excuse to post javax.comm 3.0, Update 2 as
well, while I'm working with the people who put content up on our
download center.  The only reason for a new update to 3.0 is that
I've changed the distribution to provide ispt (Interactive Serial
Port Tool), such that it can be launched as soon as the zip file
is unpacked, via a provided script.  ISPT is a command line
interactive tool for  manipulating one or two serial port,
sending data, managing events, etc... I've found it to be so useful
for doing certain kinds of validation  that I assume others will
find it useful to.  ISPT is already in 3.0u1, but one has to set
up their own classpath and launch it and since few people ever read
the documentation most won't know about it.  I've added the ability
to set stop bits and parity since 3.0u1 too.  But I digress.

Paul


From joachim at buechse.de  Mon Jun 19 11:01:28 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 19:01:28 +0200
Subject: [Rxtx] load mechanism of 2.0x
Message-ID: <CFD1440C-21AA-4D3B-9EA6-270D0FF9D6FC@buechse.de>

Good day,

I am trying to figure out, how the 2.0x distribution interacts with  
Suns implementation of javax.comm.CommPortIdentifier.

1) Apparently one can put javax.comm.properties in {java.home}/lib
2) The javax.comm package also reacts to -Djavax.comm.properties="...."

Looking at the javap output it also seems like CommPortIdentifier  
tries to find it's jar file and load the properties from there??


What I'm really looking for is a solution that allows using  
javax.comm with RXTX without modifying the VM installation. So I  
would prefer not to use 1) but I can't figure out how to use 2).

Any hints are welcome,
Joachim



From bob_tai2001 at yahoo.com  Mon Jun 19 15:00:35 2006
From: bob_tai2001 at yahoo.com (Bob Tai)
Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT)
Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place
	to start?
Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>

Hi, 

I got  rxtx Windows 2000 installed.  I did not use the
"best" way ... I just follow the insturuction and dump
the necessary files into the jre... I know it's "best"
idea, I got lazy didn't want to change my setting to
my Eclipse and classpath.

I was able to modify SimpleWrite.java to print on my
AddMaster serial printer.  I think I am ready to code!
But I need to make sure I can handle exceptions and so
on.  I notice the \samples\NullDriver\  has two files
seems to have some of the require method done, should
I start coding from those file?  I like the idea it
has the "time out" and basic exceptions done.   I am
slowly digging into the samples, but if you think any
of the code from Sun is good to checkout please let me
know.

btw, http://rxtx.qbang.org/wiki/index.php/Examples/
was very helpful, wish there are more examples.

thank you,

    Bob


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Mon Jun 19 15:55:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT)
Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good
 place to start?
In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>
References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606191542260.14139@www>

> I am
> slowly digging into the samples, but if you think any
> of the code from Sun is good to checkout please let me
> know.
>

I think NullDriver.java was an example stub driver for implementing 
something like rxtx.  It has been a while.  Unless they have been updated, 
you will find the examples are very dated.  You can look at how they use 
the port but avoid the GUI and hard coded variables (number of ports for 
instance).

There was no Swing and nobody knew what requirements today's compilers 
would make on code.  The examples worked fine with jdk 1.1 but times have 
changed.

--
Trent Jarvi
tjarvi at qbang.org


From tropicsu at hotmail.com  Mon Jun 19 19:49:08 2006
From: tropicsu at hotmail.com (Yoke K)
Date: Tue, 20 Jun 2006 01:49:08 +0000
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
Message-ID: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>

An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0005.html

From ajmas at sympatico.ca  Mon Jun 19 21:14:37 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Mon, 19 Jun 2006 23:14:37 -0400
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>
References: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>
Message-ID: <CA22AB2A-5712-458B-9984-68477C6042AF@sympatico.ca>

Regarding the PortInUseException, I had a similar issue and got
this response from the mailing list:

   http://mailman.qbang.org/pipermail/rxtx/Week-of- 
Mon-20060619/062838.html

Andre
On 19-Jun-06, at 21:49 , Yoke K wrote:

> Hi Andre, Joachim
>
> I have tried using /dev/tty.usbserial and also /dev/cu.usbserial  
> and it also reported error as  "gnu.io.PortInUseException".
>
> The iTegno modem works in windows environment. As I moving around  
> using my ibook and I need to get it work on MAC OS as well.
>
> >> INFO: SMSLib API for Java / v1.2.2
> >> INFO: Using port: /dev/tty.usbserial @ 115200 baud.
> >> INFO: JRE Version: 1.5.0_06
> >> INFO: JRE Impl Version: 1.5.0_06-64
> >> INFO: O/S: Mac OS X / ppc / 10.4.6
> >> INFO: Using Wavecom (Generic) AT handler.
>
> SendMessage(): Send a message.
> Using SMSLib API for Java v1.2.2
>
> Connecting ..... :
> >> INFO: CSerialDriver(): Connecting...
> Experimental: JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version = RXTX-2.1-7
> >> INFO: CSerialDriver(): Disconnecting...
> gnu.io.PortInUseException: Unknown Application
> at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354)
> at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1)
> at org.smslib.CService.connect(CService.java:197)
> at SendMessage.main(SendMessage.java:38)
>
> Thanks.
>
> - Jon
>
>
>
>
> ====================
>
> Hello Jon,
>
> From OSX's standpoint a symbolic link is not a device (as far as I
> know). What stops you from using tty.usbserial? Did you try hard-
> linking?
>
> Regards,
> Joachim
>
>
>
> From:  "Yoke K" <tropicsu at hotmail.com>
> To:  rxtx at qbang.org
> Subject:  RXTX-2.1-7 / MAC OS X / NoSuchPortException
> Date:  Sat, 17 Jun 2006 15:32:48 +0000
> >Hi,
> >
> >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to
> >work with MAC OS X.
> >I am using iTegno 3000 - USB GPRS Modem.
> >
> >Files in /dev and a symbolic link as follows:
> >
> >crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
> >crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
> >lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->
> >tty.usbserial
> >
> >In my SendMessage.java, I have this line:
> >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
> >
> >Appreciate any help ?
> >
> >- Jon
> >
> >
> >Errors as follows:
> >
> >>>INFO: SMSLib API for Java / v1.2.2
> >>>INFO: Using port: /dev/ttyS1 @ 56000 baud.
> >>>INFO: JRE Version: 1.5.0_06
> >>>INFO: JRE Impl Version: 1.5.0_06-64
> >>>INFO: O/S: Mac OS X / ppc / 10.4.6
> >>>INFO: Using Wavecom (Generic) AT handler.
> >
> >SendMessage(): Send a message.
> >  Using SMSLib API for Java v1.2.2
> >
> >Connecting ..... :
> >>>INFO: CSerialDriver(): Connecting...
> >Experimental:  JNI_OnLoad called.
> >Stable Library
> >=========================================
> >Native lib Version = RXTX-2.1-7
> >Java lib Version   = RXTX-2.1-7
> >>>INFO: CSerialDriver(): Disconnecting...
> >gnu.io.NoSuchPortException
> >        at
> >gnu.io.CommPortIdentifier.getPortIdentifier 
> (CommPortIdentifier.java:218)
> >        at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
> >        at org.smslib.CService.connect(CService.java:197)
> >        at SendMessage.main(SendMessage.java:38)
> >
> >_________________________________________________________________
> >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
> >
>
> Find love online with MSN Personals
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Tue Jun 20 02:35:24 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 10:35:24 +0200
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>

Hello everybody,

I have been fighting a bit with the javax.comm version of RXTX the  
last days. I am working on the README .OSX now and try to figure out  
which should be the "suggested" installation.

The facts:
------

- the "generic" comm.jar version of javax.comm which has been made re- 
available tries to load com.sun.comm.SolarisDriver
- this classname can be overridden ONLY by putting a file  
javax.comm.properties in {java.home}/lib
- if it is not overridden and SolarisDriver.class is not found  
CommPortIdentifier will be disfunctional (in particual it is not  
possible to add CommPort's via CommPortIdentifier.add).
- the license distributed with comm.jar does not allow the  
modification/addition of classes in javax.comm (however no mention of  
com.sun...)


What really bothers me is to suggest putting this config file in the  
"global" vm installation. This is particularly ugly on the Mac as  
there are several VM installations and the file may be forgotten.  
Additionally it may create versioning problems. I prefer an  
installation where all files are local to the application (even  
comm.jar).

In my opinion the ideal situation would be:
------

1) The author of a program compiles against javax.comm.
2a) For platforms supported by Sun the user is free to use the 3.0  
comm.jar download from Sun
2b) For platforms not supported by Sun the user adds RXTXComm.jar to  
the classpath of the application (and librxtxSerial.jnilib to the  
application directory). Also he will need the 2.0.3 generic comm.jar  
from Sun.
3) Nobody messes with the global VM installation.

Of course 2a) and 2b) could be handled by the author of the program  
via an appropriate installer. The author could also decide to always  
use RXTX and include the generic javax.comm classes as well as the  
RXTX classes in his application jar. [If he further uses an explicit  
call to System.load() he may even include the jnilib(s) in the jar,  
extract it (based on the platform name) at runtime to a temp file and  
load it from there.]


Suggested solution:
------

We only need to put the following class in the classpath BEFORE Suns  
comm.jar

   package com.sun.comm;
   public class SolarisDriver extends gnu.io.RXTXCommDriver {
   }

This is not "the pure art" (TM). It depends on an implementation  
detail of the generic driver. However, so does the  
javax.comm.properties file - as we have seen when Sun released 3.0.  
It has the following advantages:

- The "generic" javax.comm implementation will happily load this  
class as its primary driver.
- No javax.comm.properties file is required.
- This does not violate the javax.comm license agreement as there is  
no mention of the "com.sun.comm" package in this license agreement at  
all.
- Authors packaging comm.jar with their application can strip out all  
com.sun.comm classes from comm.jar


Please comment!

Joachim



From joachim at buechse.de  Tue Jun 20 02:50:36 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 10:50:36 +0200
Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar
Message-ID: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>

There has been some discussions about the best way to install RXTX  
and where to place files.

I suggest that,

- we include the native libraries for the most common operating  
systems (in a special version of) RXTXcomm.jar
- we add loader code which tries to extract and load the platform  
specific binary at runtime
- on failure the current mechanism remains as a fallback

Wether the current mechanism should have priority (ie loadLibrary  
before load) remains to be discussed.


The advantages of this solution are
  - users of RXTX do not need to worry about java/platform specific  
file placement.
  - authors of applications may fully merge RXTX into their  
application jar (which provides a double-clickable application for  
Windows and OSX, Linux?).

Please comment,
Joachim

PS: Of course the suggested solution is already possible today,  
however relatively few programmers know how to correctly extract a  
binary resource file via the class loader and load it as a native  
library.


From tjarvi at qbang.org  Tue Jun 20 03:58:12 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT)
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
Message-ID: <Pine.LNX.4.61.0606200335190.14139@www>

> 2a) For platforms supported by Sun the user is free to use the 3.0
> comm.jar download from Sun
> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to
> the classpath of the application (and librxtxSerial.jnilib to the
> application directory). Also he will need the 2.0.3 generic comm.jar
> from Sun.

As there are no plans to support CommAPI 3.0 due to the limitations in its 
implementation mentioned before, I would not recommend projects use Sun's 
3.0 comm.jar.  They will lose the freedom to chose their low level 
implementation by being locked into vendor specific modifications.

Projects should chose between platform neutrality in CommAPI 2.0 and 
reduced platform neutrality in commapi 3.0.  Projects should also strongly 
consider the fact that the 2.0 comm.jar targets only a reduced number of 
JVMs.

Projects can go with rxtx 2.1 or other packages but should probably only 
consider using Sun CommAPI with rxtx if they did so in the past.  They 
should take steps to no longer depend upon this option being available.

> Suggested solution:
> ------
>
> We only need to put the following class in the classpath BEFORE Suns
> comm.jar
>
>   package com.sun.comm;
>   public class SolarisDriver extends gnu.io.RXTXCommDriver {
>   }
>
> This is not "the pure art" (TM). It depends on an implementation
> detail of the generic driver. However, so does the
> javax.comm.properties file - as we have seen when Sun released 3.0.
> It has the following advantages:
>
> - The "generic" javax.comm implementation will happily load this
> class as its primary driver.
> - No javax.comm.properties file is required.
> - This does not violate the javax.comm license agreement as there is
> no mention of the "com.sun.comm" package in this license agreement at
> all.
> - Authors packaging comm.jar with their application can strip out all
> com.sun.comm classes from comm.jar
>

I would not encourage people to place packages in the com.sun.comm 
namespace.  Authors using Sun's commapi 2.0 should just realize it is 
greatly limited in practical utility and consider moving to something that 
isn't being rescued from EOL.

The primary focus of this release is projects previously depending upon 
Sun CommAPI + RXTX.  There are no plans at this time to provide future 
support in this arrangement due to technical incompatabilities we have no 
control over in commapi 3.0 and limited utility of Sun's generic comm.jar 
in commapi 2.0 offered.  Projects should be aware of this so they can make 
appropriate plans.

--
Trent Jarvi
tjarvi at qbang.org


From paul.klissner at sun.com  Tue Jun 20 05:24:00 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Tue, 20 Jun 2006 04:24:00 -0700
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
In-Reply-To: <Pine.LNX.4.61.0606200335190.14139@www>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
	<Pine.LNX.4.61.0606200335190.14139@www>
Message-ID: <4497DAD0.10803@sun.com>

Trent Jarvi wrote:
>> 2a) For platforms supported by Sun the user is free to use the 3.0
>> comm.jar download from Sun
>> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to
>> the classpath of the application (and librxtxSerial.jnilib to the
>> application directory). Also he will need the 2.0.3 generic comm.jar
>> from Sun.
> 
> As there are no plans to support CommAPI 3.0 due to the limitations in its 
> implementation mentioned before, I would not recommend projects use Sun's 
> 3.0 comm.jar.  They will lose the freedom to chose their low level 
> implementation by being locked into vendor specific modifications.
> 
> Projects should chose between platform neutrality in CommAPI 2.0 and 
> reduced platform neutrality in commapi 3.0.  Projects should also strongly 
> consider the fact that the 2.0 comm.jar targets only a reduced number of 
> JVMs.

Well, that's a little ambiguous because the API is the same
either way.  We're talking about Sun's implementation vs.
other implementations.
> 
> Projects can go with rxtx 2.1 or other packages but should probably only 
> consider using Sun CommAPI with rxtx if they did so in the past.  They 
> should take steps to no longer depend upon this option being available.

3.0 is platform centric because there is a need to add some
platform awareness to Sun's implementation, and the choices
for how to do that are limited by the constraints of the API,
as mentioned in the javax.comm 2.0.3 comm.jar download's README.

I am really advocating getting a JSR open (http://www.jcp.org)
to push a new comm API that is more pluggable, platform neutral
and addresses some of the deficiencies of the current API. Then
we can achieve the optimal of platform neutrality while
simulataneously allowing the API to flexibly adapt to
heterogeneous environments.

This is not a question of attitude, this is an issue of resources,
time and commitment.  The current owners of javax.comm within
Sun would like nothing better than to see the ideal reached for
the API and a model that will extend well beyond the foreseeable
future and work for the industry overall.



> 
>> Suggested solution:
>> ------
>>
>> We only need to put the following class in the classpath BEFORE Suns
>> comm.jar
>>
>>   package com.sun.comm;
>>   public class SolarisDriver extends gnu.io.RXTXCommDriver {
>>   }
>>
>> This is not "the pure art" (TM). It depends on an implementation
>> detail of the generic driver. However, so does the
>> javax.comm.properties file - as we have seen when Sun released 3.0.
>> It has the following advantages:
>>
>> - The "generic" javax.comm implementation will happily load this
>> class as its primary driver.
>> - No javax.comm.properties file is required.
>> - This does not violate the javax.comm license agreement as there is
>> no mention of the "com.sun.comm" package in this license agreement at
>> all.
>> - Authors packaging comm.jar with their application can strip out all
>> com.sun.comm classes from comm.jar
>>
> 
> I would not encourage people to place packages in the com.sun.comm 
> namespace.  Authors using Sun's commapi 2.0 should just realize it is 
> greatly limited in practical utility and consider moving to something that 
> isn't being rescued from EOL.
> 
> The primary focus of this release is projects previously depending upon 
> Sun CommAPI + RXTX.  There are no plans at this time to provide future 
> support in this arrangement due to technical incompatabilities we have no 
> control over in commapi 3.0 and limited utility of Sun's generic comm.jar 
> in commapi 2.0 offered.  Projects should be aware of this so they can make 
> appropriate plans.

Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86,
or need the powerful portmapping features in javax.com 3.0, or would like to
acquire the Interactive Serial Port Test utility.

-Paul


From paul.klissner at sun.com  Tue Jun 20 05:33:44 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Tue, 20 Jun 2006 04:33:44 -0700
Subject: [Rxtx] Suggested installation RXTX 2.0x...
In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
Message-ID: <4497DD18.70207@sun.com>

Joachim Buechse wrote:
> Hello everybody,
> 
> I have been fighting a bit with the javax.comm version of RXTX the  
> last days. I am working on the README .OSX now and try to figure out  
> which should be the "suggested" installation.
> 
> The facts:
> ------
> 
> - the "generic" comm.jar version of javax.comm which has been made re- 
> available tries to load com.sun.comm.SolarisDriver
> - this classname can be overridden ONLY by putting a file  
> javax.comm.properties in {java.home}/lib
> - if it is not overridden and SolarisDriver.class is not found  
> CommPortIdentifier will be disfunctional (in particual it is not  
> possible to add CommPort's via CommPortIdentifier.add).
> - the license distributed with comm.jar does not allow the  
> modification/addition of classes in javax.comm (however no mention of  
> com.sun...)
> 
> 
> What really bothers me is to suggest putting this config file in the  
> "global" vm installation. This is particularly ugly on the Mac as  
> there are several VM installations and the file may be forgotten.  
> Additionally it may create versioning problems. I prefer an  
> installation where all files are local to the application (even  
> comm.jar).
> 
> In my opinion the ideal situation would be:
> ------
> 
> 1) The author of a program compiles against javax.comm.
> 2a) For platforms supported by Sun the user is free to use the 3.0  
> comm.jar download from Sun
> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to  
> the classpath of the application (and librxtxSerial.jnilib to the  
> application directory). Also he will need the 2.0.3 generic comm.jar  
> from Sun.
> 3) Nobody messes with the global VM installation.
> 
> Of course 2a) and 2b) could be handled by the author of the program  
> via an appropriate installer. The author could also decide to always  
> use RXTX and include the generic javax.comm classes as well as the  
> RXTX classes in his application jar. [If he further uses an explicit  
> call to System.load() he may even include the jnilib(s) in the jar,  
> extract it (based on the platform name) at runtime to a temp file and  
> load it from there.]
> 

This was how the Sun implementation originated (I did not write
that code).  I completely agree, and I fixed the whole conf file
locating mechanism in 3.0 to avoid the problems youmentioned.
However, I was unaware of how RxTx was using Sun's implementation,
so I didn't architect it in such a way as to avoid namespace pollution
in the native space in for the backend provider.  In retrospect,
I should have done that differently just as a design principle,
but at this point I don't have the spare cycles to get that all
re-factored.  Further, I'm loathe to do it, because the whole
thing will still be an under-the-hood hack due to the constraints
of the API itself.

Paul





From brian at mbari.org  Tue Jun 20 10:23:54 2006
From: brian at mbari.org (Brian Schlining)
Date: Tue, 20 Jun 2006 09:23:54 -0700
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>


Hi Joachim,

> There has been some discussions about the best way to install RXTX
> and where to place files.
>
> I suggest that,
>
> - we include the native libraries for the most common operating
> systems (in a special version of) RXTXcomm.jar
> - we add loader code which tries to extract and load the platform
> specific binary at runtime
> - on failure the current mechanism remains as a fallback

I like your suggestion. However, my understanding is that in general  
the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH  
(Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to  
be loaded by the JVM. The alternative is to point to your native lib  
directory using -Djava.library.path=/my/dir/with/native/libs when you  
launch the JVM. So, I'm very interested to know how you're planning  
to work around this.

> PS: Of course the suggested solution is already possible today,
> however relatively few programmers know how to correctly extract a
> binary resource file via the class loader and load it as a native
> library.

So how do you use it to dynamically load a native lib? I've read that  
you can't really modify the java.library.path after the JVM has been  
launched. (http://forum.java.sun.com/thread.jspa? 
threadID=627890&tstart=90)

Thanks

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0005.html

From joachim at buechse.de  Tue Jun 20 09:20:29 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 17:20:29 +0200
Subject: [Rxtx] 2.0x in sync with 2.1x
Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>

I have added most of the changes from the 2.1 branch to the 2.0 branch.

This includes
  - correction of illegal javadoc comments
  - implementation errors in handling of Thread.interrupt in  
RXTXPort.java
  - MacOS X locking without lock files/special user groups
  - XCode project which builds a universal binary library
  - updated documentation for OSX

I have done some minimal testing (only G4).
[Trent: there are still some changes you made for specific baud  
rates. I will not sync this, as I can not test them. From my  
perspective we are ready for 2.08/2.18]

The updated documentation can be found in the file README.OSX. Here  
it is:

------------------------ Required files -----------------------

To use or compile RXTX 2.0.x you need to downlad the "generic"  
version (2.0.3)
of the javax.comm implementation from Sun. The zip you download  
contains an
archive comm.jar which is required:

- To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar

- To run the app you will need comm.jar in the classpath or in  
{java.lib.path}


------------------------ Installation on MacOSX -----------------------

WARNING: Please read this section until the end.

---
Preparation
---

You may want to spare your users the burden of modifying the global VM
installation. OSX has several different VM versions installed by  
default and
regular users will be unable to figure out which version will load your
application.

If you provide the class

package com.sun.comm;
public class SolarisDriver extends gnu.io.RXTXCommDriver {
}

and make sure, that it is present in the classpath before Suns  
"generic" comm.jar
your users can skip the following step:

Create a file named
    javax.comm.properties
in the directory
    /System/Library/Frameworks/JavaVM.framework/Home/lib/
which contains (only) the following line (no leading space):
    Driver=gnu.io.RXTXCommDriver



----
The unsafe way of using RXTX on OS X:
----

RXTX can be installed by putting the files
   libSerial.jnilib
   RXTXcomm.jar
   comm.jar
into the folder
   /Library/Java/Extensions

This is NOT RECOMMENDED as it creates versioning conflicts among  
applications.
However you may be forced to install it this way if an application  
was written
for Windows or Linux, requires RXTX and you are not able to change  
its starter.


----
The safe way of using RXTX on OS X:
----

Make sure that you have no (older) version of RXTX installed in
   /Library/Java/Extensions
   /System/Library/Java/Extensions
   /usr/lib/java

Put
   libSerial.jnilib
in the directory of the application (the JavaVM will find it there). Add
   RXTXComm.jar
   comm.jar
to the application classpath or include the classes in the  
application jar.
(Some applications already include the RXTX classes in their  
application jar,
in which case only the file libSerial.jnilib is required).


----
History
----

Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation  
of lockfiles
required special permissions for the user executing an application  
based on RXTX.
To simplify the setup RXTX came with an installer modifying group  
permissions
and installing RXTX in the global location /Library/Java/Extensions.  
However
this was prune to versioning conflicts and is no longer recommended.

--------------------- Build instructions for OSX XCode  
-------------------

contributed by Joachim Buechse <joachim at buechse.de>
original version by Dmitry Markman <dmarkman at mac.com>

System requirements for building:
MacOSX 10.4
XCode 2.3

   open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj
   choose libSerial.jnilib target
   build

After the build you will find RXTXcomm.jar and libSerial.jnilib files  
in the
directory build/Development.

In case you can't find RXTXcomm.jar build the RXTXcomm target manually.
In case of (serious) problems feel free to contact joachim at buechse.de .



From tjarvi at qbang.org  Tue Jun 20 22:01:45 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT)
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
Message-ID: <Pine.LNX.4.61.0606202127270.14139@www>

> ---
> Preparation
> ---
>
> You may want to spare your users the burden of modifying the global VM
> installation. OSX has several different VM versions installed by
> default and
> regular users will be unable to figure out which version will load your
> application.
>
> If you provide the class
>
> package com.sun.comm;
> public class SolarisDriver extends gnu.io.RXTXCommDriver {
> }
>
> and make sure, that it is present in the classpath before Suns
> "generic" comm.jar
> your users can skip the following step:

Hi Joachim

With regards to the above, I have not seen that we have Sun's OK to 
promote that.  I'm not very comfortable with the distribution 
documentation advocating this without Sun agreeing.

I see your point but I'd rather not actively promote putting classes in 
Sun's namespace without permission if you don't mind.  This isn't about 
what is in a license.

I'll go through the code tomorrow night.  It was a late night at work 
today.  There is also a w32 fix comming for people opening and closing 
multiple ports.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Wed Jun 21 01:56:45 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 21 Jun 2006 09:56:45 +0200
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <Pine.LNX.4.61.0606202127270.14139@www>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
	<Pine.LNX.4.61.0606202127270.14139@www>
Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>

Hello Trent,

I guess we will not get an explicit OK from Sun for such a hack. I  
think Paul has made it pretty clear, that he does not have the  
resources to modify the 2.x or 3.x code for the needs of RXTX. I'm  
not thrilled but OK with the current API. Hence I dont agree with  
Paul's idea to start a new JSR to fix the implementation - but that's  
mainly because I dont have the time to push it. According to their  
Readme Sun sees no business case in having cross platform support for  
javax.comm - that is sad but it's none of my business. However I  
prefer to program versus javax.comm in my projects as this gives an  
advanced user the chance to exchange the provider without access to  
the code.

I interpret Pauls reponse to my original "Request for comment" as a  
quiet acceptance of the hack I propose (he did respond, but not at  
all to the sun.comm namespace suggestion). This is certainly not  
something we should put into RXTXcomm.jar but hinting a work around  
for implementation errors should be allowed. That's why I've choosen  
the wording "You may want to spare" and "If you provide". The company  
I worked for has choosen similar hacks for years to fix bugs in swing  
for JDK1.1 applications. Those hacks were usually included in their  
own swingpatch.jar.

Having said all that - I do not take it as an insult if you remove  
the paragraph from the Readme. I appreciate that you notified me  
before. It would be interesting to hear some more opinions from the  
list members...

Best regards,
Joachim


On 21.06.2006, at 06:01, Trent Jarvi wrote:

>> ---
>> Preparation
>> ---
>>
>> You may want to spare your users the burden of modifying the  
>> global VM
>> installation. OSX has several different VM versions installed by
>> default and
>> regular users will be unable to figure out which version will load  
>> your
>> application.
>>
>> If you provide the class
>>
>> package com.sun.comm;
>> public class SolarisDriver extends gnu.io.RXTXCommDriver {
>> }
>>
>> and make sure, that it is present in the classpath before Suns
>> "generic" comm.jar
>> your users can skip the following step:
>
> Hi Joachim
>
> With regards to the above, I have not seen that we have Sun's OK to
> promote that.  I'm not very comfortable with the distribution
> documentation advocating this without Sun agreeing.
>
> I see your point but I'd rather not actively promote putting  
> classes in
> Sun's namespace without permission if you don't mind.  This isn't  
> about
> what is in a license.
>
> I'll go through the code tomorrow night.  It was a late night at work
> today.  There is also a w32 fix comming for people opening and closing
> multiple ports.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Wed Jun 21 02:03:33 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 21 Jun 2006 10:03:33 +0200
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
	<6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
Message-ID: <BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>

See System.load(String) [it's also mentioned under the URL you posted].

Regards,
Joachim


On 20.06.2006, at 18:23, Brian Schlining wrote:

> So how do you use it to dynamically load a native lib? I've read  
> that you can't really modify the java.library.path after the JVM  
> has been launched. (http://forum.java.sun.com/thread.jspa? 
> threadID=627890&tstart=90)
>
> Thanks
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From baris.ozkan at elikasu.com.tr  Wed Jun 21 07:58:06 2006
From: baris.ozkan at elikasu.com.tr (Baris)
Date: Wed, 21 Jun 2006 16:58:06 +0300
Subject: [Rxtx] RS 232 ..additional parameters
Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>

Hi,
 
Currently i am developing an application that requires to connect to a
remote rs232 device through  a dialup connection.
 
My problem is that the communication needs several more connection
parameters (i extracted that information from the vendor's dll , listed at
the end of the message)
 
I explored rxtx API and src files and could not find methods to set a
majority  of the parameters.
Am i missing any point or does rxtx is limited to soem standard set of
functionality(e.g. commAPI)? How  is it possible ,if i want to put some
extensions(???) to current rxtx implementation?
 
I am not very good at rs232 programming so excuse me if this message  is
boring one.
 
Thanx
 
Baris Ozkan
 
 
A Listing of Parameters:
 
 
typedef struct _DCB {

DWORD DCBlength; /* sizeof(DCB) */

DWORD BaudRate; /* Baudrate at which running */

DWORD fBinary: 1; /* Binary Mode (skip EOF check) */

DWORD fParity: 1; /* Enable parity checking */

DWORD fOutxCtsFlow:1; /* CTS handshaking on output */

DWORD fOutxDsrFlow:1; /* DSR handshaking on output */

DWORD fDtrControl:2; /* DTR Flow control */

DWORD fDsrSensitivity:1; /* DSR Sensitivity */

DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */

DWORD fOutX: 1; /* Enable output X-ON/X-OFF */

DWORD fInX: 1; /* Enable input X-ON/X-OFF */

DWORD fErrorChar: 1; /* Enable Err Replacement */

DWORD fNull: 1; /* Enable Null stripping */

DWORD fRtsControl:2; /* Rts Flow control */

DWORD fAbortOnError:1; /* Abort all reads and writes on Error */

DWORD fDummy2:17; /* Reserved */

WORD wReserved; /* Not currently used */

WORD XonLim; /* Transmit X-ON threshold */

WORD XoffLim; /* Transmit X-OFF threshold */

BYTE ByteSize; /* Number of bits/byte, 4-8 */

BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */

BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */

char XonChar; /* Tx and Rx X-ON character */

char XoffChar; /* Tx and Rx X-OFF character */

char ErrorChar; /* Error replacement char */

char EofChar; /* End of Input character */

char EvtChar; /* Received Event character */

WORD wReserved1; /* Fill for now. */

} DCB, *LPDCB;

typedef struct _COMMTIMEOUTS {

DWORD ReadIntervalTimeout; /* Maximum time between read chars. */

DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */

DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */

DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */

DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */

} COMMTIMEOUTS,*LPCOMMTIMEOUTS;

dcb.fOutX = FALSE;

dcb.fInX = FALSE;

dcb.fOutxCtsFlow = FALSE;

dcb.fBinary = TRUE;

dcb.fRtsControl = RTS_CONTROL_ENABLE;

SetCommState(hComm , &dcb ); 

COMMTIMEOUTS commTimeOut;

GetCommTimeouts(hComm, &commTimeOut );

commTimeOut.WriteTotalTimeoutMultiplier = 1; 

commTimeOut.WriteTotalTimeoutConstant = 18; 

// commTimeOut.ReadIntervalTimeout = 28; 

commTimeOut.ReadIntervalTimeout = 0; 

// commTimeOut.ReadTotalTimeoutMultiplier = 184; 

commTimeOut.ReadTotalTimeoutMultiplier = 300; 

// commTimeOut.ReadTotalTimeoutConstant = 1200;

commTimeOut.ReadTotalTimeoutConstant = 1200;

SetCommTimeouts(hComm, &commTimeOut);

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0005.html

From ajmas at sympatico.ca  Wed Jun 21 08:14:26 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Wed, 21 Jun 2006 10:14:26 -0400
Subject: [Rxtx] When is 2.18 planned for?
Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

Just curious as to know if there is a target date for 2.18?

Andre



From brian at mbari.org  Wed Jun 21 09:36:00 2006
From: brian at mbari.org (Brian Schlining)
Date: Wed, 21 Jun 2006 08:36:00 -0700
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
	<6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
	<BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>
Message-ID: <A21C9BC0-7894-4B08-AC82-44E11AB3D461@mbari.org>

Ha!!

I suppose I should read my own postings. ;-)

Thanks
B

On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote:

> See System.load(String) [it's also mentioned under the URL you  
> posted].
>
> Regards,
> Joachim
>
>
> On 20.06.2006, at 18:23, Brian Schlining wrote:
>
>> So how do you use it to dynamically load a native lib? I've read
>> that you can't really modify the java.library.path after the JVM
>> has been launched. (http://forum.java.sun.com/thread.jspa?
>> threadID=627890&tstart=90)

Brian Schlining
Software Engineer
http://www.mbari.org




From ajmas at sympatico.ca  Wed Jun 21 16:41:28 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Wed, 21 Jun 2006 18:41:28 -0400
Subject: [Rxtx] CVS build question
Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X:

 The JCL extension to RxTx requires comm.jar
 If you intend to use RxTx for commapi support comm.jar
 needs to be located in  /System/Library/Frameworks/JavaVM.framework/
  Versions/1.5/Home/lib/ext/comm.jar

I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me.

On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native).

Andre






From tjarvi at qbang.org  Wed Jun 21 18:00:04 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT)
Subject: [Rxtx] CVS build question
In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606211756310.14139@www>

On Wed, 21 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> Is the CVS repository meant to build for gnu.io or javax.comm? I ask 
> this, because I see the following when calling ./configure from MacOS X:
>
> The JCL extension to RxTx requires comm.jar
> If you intend to use RxTx for commapi support comm.jar
> needs to be located in  /System/Library/Frameworks/JavaVM.framework/
>  Versions/1.5/Home/lib/ext/comm.jar
>
> I am wanting to build for the gnu.io package, since I want to jump ahead 
> and see if the changes, intended for 2.18 for MacOS X, work for me.
>
> On a side note /Library/Java/Extensions should be included as a valid 
> search path for the JAR, since this is where Apple recommends placing 
> third party extensions (both Java and native).
>

rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel"
rxtx 2.0 src is obtained with "cvs checkout rxtx-devel"

rxtx 2.1 is a complete package in namespace gnu.io
rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 18:02:23 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT)
Subject: [Rxtx] When is 2.18 planned for?
In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606211800180.14139@www>

On Wed, 21 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> Just curious as to know if there is a target date for 2.18?
>

Hi Andre

"When it is ready" :)

Probably this weekend.  Maybe sooner.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 18:10:18 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT)
Subject: [Rxtx] RS 232 ..additional parameters
In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>
References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>
Message-ID: <Pine.LNX.4.61.0606211805010.14139@www>

On Wed, 21 Jun 2006, Baris wrote:

> Hi,
>
> Currently i am developing an application that requires to connect to a
> remote rs232 device through  a dialup connection.
>
> My problem is that the communication needs several more connection
> parameters (i extracted that information from the vendor's dll , listed at
> the end of the message)
>
> I explored rxtx API and src files and could not find methods to set a
> majority  of the parameters.
> Am i missing any point or does rxtx is limited to soem standard set of
> functionality(e.g. commAPI)? How  is it possible ,if i want to put some
> extensions(???) to current rxtx implementation?
>
> I am not very good at rs232 programming so excuse me if this message  is
> boring one.
>
> Thanx
>

Hi Baris

> typedef struct _DCB {
> typedef struct _COMMTIMEOUTS {

These are all handled in termios.c.  It is possible to add extensions to 
rxtx 2.1.  It may well be that the defaults are the same for the variables 
not covered by the existing API.  You can dump the DCB and COMMTIMEOUTS 
from inside termios.c to compare.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 20:23:30 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT)
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
	<Pine.LNX.4.61.0606202127270.14139@www>
	<789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>
Message-ID: <Pine.LNX.4.61.0606212012210.14139@www>

> I'm
> not thrilled but OK with the current API. Hence I dont agree with
> Paul's idea to start a new JSR to fix the implementation - but that's
> mainly because I dont have the time to push it. According to their
> Readme Sun sees no business case in having cross platform support for
> javax.comm - that is sad but it's none of my business. However I
> prefer to program versus javax.comm in my projects as this gives an
> advanced user the chance to exchange the provider without access to
> the code.

Hi Joachim

With regards to the JSR, I think that would be Doug's call.  The effort I 
put in would have to be on my own time which would not be a great deal.  I 
could help things go smoothly but thats not the same as pushing something 
through.

--
Trent Jarvi
tjarvi at qbang.org



From vt at freehold.crocodile.org  Wed Jun 21 21:05:22 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Wed, 21 Jun 2006 20:05:22 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
Message-ID: <449A08F2.3020106@freehold.crocodile.org>

Hello all,

I know this question may belong to JSR lists, but since all interested 
parties are here, I thought I just ask this question here, again...

A while ago I run into a problem and wrote a rant, here: 
http://servomaster.sourceforge.net/dev/serial-usb.html
At the time of writing I didn't think of adding another possible 
solution - changing the CommAPI specs to support removable devices. 
Apparently, Serial/USB bridges are here to stay, and this issue has to 
be addressed.

Wonder if anything changed since, and any abstractions for supporting 
removable devices made it into current or future Java CommAPI drafts - 
Paul, any comments?

--vt



From joachim at buechse.de  Thu Jun 22 01:59:54 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 22 Jun 2006 09:59:54 +0200
Subject: [Rxtx] CVS build question
In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de>

Hello Andre,

I am not sure how well the configure/make mechanism will work on OSX.  
I know that a while ago some contributors tried to get configure/make  
working on OSX but from comments I found in the readmes this work was  
only partially successfull. For compilation on OSX we have used the  
ProjectBuilder/XCode projects you can find in MACOSX_IDE.

Regarding the  ./configure comment:
RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config  
file javax.comm.properties. The later MUST reside in {java.home}/lib.  
As the two only work together putting comm.jar into  /Library/Java/ 
Extensions  and hence making it available to all current and future  
VM installations will only add to confusion.

Regards,
Joachim

On 22.06.2006, at 00:41, Andre-John Mas wrote:

> Hi,
>
> Is the CVS repository meant to build for gnu.io or javax.comm? I  
> ask this, because I see the following when calling ./configure from  
> MacOS X:
>
>  The JCL extension to RxTx requires comm.jar
>  If you intend to use RxTx for commapi support comm.jar
>  needs to be located in  /System/Library/Frameworks/JavaVM.framework/
>   Versions/1.5/Home/lib/ext/comm.jar
>
> I am wanting to build for the gnu.io package, since I want to jump  
> ahead and see if the changes, intended for 2.18 for MacOS X, work  
> for me.
>
> On a side note /Library/Java/Extensions should be included as a  
> valid search path for the JAR, since this is where Apple recommends  
> placing third party extensions (both Java and native).
>
> Andre
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Thu Jun 22 02:51:05 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 22 Jun 2006 10:51:05 +0200
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449A08F2.3020106@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>

Hello Vadim,

I think that your rant is to the point. However it is a bit like  
saying that Windows is at the source of email degradation and the  
only solution is to have users switch to safer operating systems.

I don't see how javax.comm or RXTX can address the problems you  
mention. Of course it would be super cool if javax.comm could magicly  
find the "matching" usb-device and query it's configuration via the  
usb protocol - however this magic (mapping /dev/xyz to its underlying  
USB device) is not supported by any kernel APIs I am aware of. It  
could be supported via POSSIX ioctl calls but then you should address  
your rant to the POSSIX group...

So for the time beeing it's either up to the virtual comm port driver  
to provide a usefull name under /dev/ or to the user choosing the  
right port to use. One example of a smart(er) com port driver is the  
KDDI driver for OSX, which will create device names like "/dev/ 
cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- 
encoded into the bridge chip. The same driver for windows also has  
some options allowing it in theory to recreate the same COMx every  
time a device is plugged/unplugged.

For most industrial applications however it will be up to the user to  
choose the right port (without getting a lot of help doing so).

Probing serial ports can go wrong, that's right. However any serial  
device developper would be well adviced to implement a basic set of  
Hayes AT modem commands (be it a modem or not). Especially AT I0.  
Anyone failing to do so risks that the users favourite TCP/PPP/FAX  
application or stack will kill the device in short time.

Best regards,
Joachim


On 22.06.2006, at 05:05, Vadim Tkachenko wrote:

> Hello all,
>
> I know this question may belong to JSR lists, but since all interested
> parties are here, I thought I just ask this question here, again...
>
> A while ago I run into a problem and wrote a rant, here:
> http://servomaster.sourceforge.net/dev/serial-usb.html
> At the time of writing I didn't think of adding another possible
> solution - changing the CommAPI specs to support removable devices.
> Apparently, Serial/USB bridges are here to stay, and this issue has to
> be addressed.
>
> Wonder if anything changed since, and any abstractions for supporting
> removable devices made it into current or future Java CommAPI drafts -
> Paul, any comments?
>
> --vt
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From vt at freehold.crocodile.org  Thu Jun 22 13:16:03 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 12:16:03 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
Message-ID: <20060622191603.GA17487@freehold.crocodile.org>

Hello Joachim,

> I think that your rant is to the point. However it is a bit like  
> saying that Windows is at the source of email degradation and the  
> only solution is to have users switch to safer operating systems.

I guess the problem is that the rant itself is obsolete and has to be
updated according to latest developments. At the time of writing there
weren't that many bridges around, and the trend didn't manifest itself as it
does now.

> I don't see how javax.comm or RXTX can address the problems you  
> mention.

I would agree that javax.comm won't be able to address the problem, at least
in the short run. As for RxTx - well, nobody prevents it from being a
superset of CommAPI specification, right? RxTx being the de-facto standard
for quite a few platforms, I'd daresay the standard may follow.

> Of course it would be super cool if javax.comm could magicly find the
> "matching" usb-device and query it's configuration via the usb protocol -
> however this magic (mapping /dev/xyz to its underlying USB device) is not
> supported by any kernel APIs I am aware of. It could be supported via
> POSSIX ioctl calls but then you should address your rant to the POSSIX
> group...

As a matter of fact, my bigger concern is addressing the fact that a serial
device can now be removable. This hasn't been the case before, and it
clearly is now. Regarding the above, well, I guess if we accept this fact,
we also need to accept the fact that we need at least rudimentary means of
identification of a serial device. For the USB case, it would usually be the
vendor/product ID, plus possible serial number - but it is irrelevant what
exactly the identifying information is, as long as it allows to identify the
device.

A paradigm shift is required, this is what I wanted to say. Serial devices
can be removed and replaced, it's now our turn to learn to deal with it.

> Joachim

--vt


From jredman at ergotech.com  Thu Jun 22 13:41:44 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 13:41:44 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
Message-ID: <449AF278.6000903@ergotech.com>


Vadim Tkachenko wrote:
> A paradigm shift is required, this is what I wanted to say. Serial devices
> can be removed and replaced, it's now our turn to learn to deal with it.

The removal if the serial port hardly significantly different from the 
removal of the device attached to the serial port.   Different, 
slightly, but not a "paradigm shift".

And yes, someone could unplug a USB serial device and plug it into a 
different USB port so that it has a different name/number, but they 
could do that with the device itself, move it from com1 to com2.

Am I missing something?

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 13:57:27 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 12:57:27 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449AF278.6000903@ergotech.com>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
Message-ID: <20060622195727.GA20247@freehold.crocodile.org>

On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote:
> 
> Vadim Tkachenko wrote:
> > A paradigm shift is required, this is what I wanted to say. Serial devices
> > can be removed and replaced, it's now our turn to learn to deal with it.
> 
> The removal if the serial port hardly significantly different from the 
> removal of the device attached to the serial port.   Different, 
> slightly, but not a "paradigm shift".
> 
> And yes, someone could unplug a USB serial device and plug it into a 
> different USB port so that it has a different name/number, but they 
> could do that with the device itself, move it from com1 to com2.
> 
> Am I missing something?

Yes, the fact that they could unplug a device A and plug a device B. With
the introduction of the concept of removability, the notion of the serial
port itself is not as important anymore, but the notion of the unique device
identifier is.

Consider a situation: long running system (enterprise HVAC, tens of nodes,
tens of thousands square feet area, hundreds of thousand dollars worth of
equipment being conditioned, can't shut down), serial/usb device fails, is
replaced by an identical device with a different serial #.

A little bit farfetched, but hopefully highlighting the point I'm trying to
make.

> Jim

--vt


From jredman at ergotech.com  Thu Jun 22 14:37:38 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 14:37:38 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>	<20060622191603.GA17487@freehold.crocodile.org>	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
Message-ID: <449AFF92.8080003@ergotech.com>


Vadim Tkachenko wrote:
>>
>> Am I missing something?
> 
> Yes, the fact that they could unplug a device A and plug a device B. With
> the introduction of the concept of removability, the notion of the serial
> port itself is not as important anymore, but the notion of the unique device
> identifier is.

Serial devices are always removable.  I could unplug _serial_ device A 
and plug in _serial_ device B.  We have systems running with two RS485 
ports, one talks to a Modbus PLC network one to a number of drives on a 
proprietary protocol.  If you plug the wrong DB9 into the wrong port the 
application doesn't work.

If you dangle a USB 485 converter on the end of the DB9 you've just 
moved the problem from RS485 to USB, but the problem/effect is the same.

> 
> Consider a situation: long running system (enterprise HVAC, tens of nodes,
> tens of thousands square feet area, hundreds of thousand dollars worth of
> equipment being conditioned, can't shut down), serial/usb device fails, is
> replaced by an identical device with a different serial #.
> 
> A little bit farfetched, but hopefully highlighting the point I'm trying to
> make.

Nothing's changed.  If I had a 4 port ISA board and plugged it into my 
new shiny '386 machine.  I could have com ports 9-12.  If I took a board 
off the shelf and didn't set the jumpers, I would have com ports 3-6.

The problem's the same.  If you replace with identical product then the 
com ports  will be the same - no software changes required.  If you 
replace one piece of hardware with hardware from a different 
manufacturer, then the naming/numbering may change.  You're physically 
changing the system, so may reasonably expect to have to make a software 
change.  RXTX actually handles this situation quite well with the -D 
command line option.  (My experience has generally been that the port 
number depends more on the USB port used than the hardware - so the 
chances are even with a hardware change the port number/name will be the 
same.)

Slightly Off Topic - there is a reason why industrial users will pay a 
premium for continued availability of hardware.  Yes you can mail-order 
a $10 USB converter and it will work, but there's no guarantee that the 
next time you buy the same part number from the same vendor it will be 
the same.  The industrial vendors will charge you $100+ for the same 
item, but it will be the same every time you buy it for the next 5 to 10 
years.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 14:37:19 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 13:37:19 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
Message-ID: <20060622203719.GA22521@freehold.crocodile.org>

Hello again,

And while I'm at it, why don't just say this: give me one good reason to
write 3+ different ways of handling removable devices, one for USB, one for
FireWire, one for serial...

I understand very well that this goes way beyond the scope of RxTx and
CommAPI and will require cooperation between them and javax.usb and whatever
JSR is responsible for FireWire implementation - but the end result is well
worth it. Abstract out and generalize arrival/departure/monitoring/discovery
API, provide protocol specific extensions for each, live happily ever after.

--vt


On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote:
> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote:
> > 
> > Vadim Tkachenko wrote:
> > > A paradigm shift is required, this is what I wanted to say. Serial devices
> > > can be removed and replaced, it's now our turn to learn to deal with it.
> > 
> > The removal if the serial port hardly significantly different from the 
> > removal of the device attached to the serial port.   Different, 
> > slightly, but not a "paradigm shift".
> > 
> > And yes, someone could unplug a USB serial device and plug it into a 
> > different USB port so that it has a different name/number, but they 
> > could do that with the device itself, move it from com1 to com2.
> > 
> > Am I missing something?
> 
> Yes, the fact that they could unplug a device A and plug a device B. With
> the introduction of the concept of removability, the notion of the serial
> port itself is not as important anymore, but the notion of the unique device
> identifier is.
> 
> Consider a situation: long running system (enterprise HVAC, tens of nodes,
> tens of thousands square feet area, hundreds of thousand dollars worth of
> equipment being conditioned, can't shut down), serial/usb device fails, is
> replaced by an identical device with a different serial #.
> 
> A little bit farfetched, but hopefully highlighting the point I'm trying to
> make.
> 
> > Jim
> 
> --vt
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx


From jredman at ergotech.com  Thu Jun 22 15:13:49 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 15:13:49 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>	<20060622191603.GA17487@freehold.crocodile.org>	<449AF278.6000903@ergotech.com>	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
Message-ID: <449B080D.9080208@ergotech.com>


Vadim Tkachenko wrote:
> Hello again,
> 
> And while I'm at it, why don't just say this: give me one good reason to
> write 3+ different ways of handling removable devices, one for USB, one for
> FireWire, one for serial...

You don't, they're all the same "I have lost communication with my 
serial device".

The only thing you could really do is improve error reporting by knowing 
the exact sub-system.  ("Device X which is/was attached to USB port Y is 
no longer functioning, please check the USB ports, the device, the 
cables and anything else you can think of that may be a cause of 
failure.")  That just requires an intelligent description of the port.

> I understand very well that this goes way beyond the scope of RxTx and
> CommAPI and will require cooperation between them and javax.usb and whatever
> JSR is responsible for FireWire implementation - but the end result is well
> worth it. Abstract out and generalize arrival/departure/monitoring/discovery
> API, provide protocol specific extensions for each, live happily ever after.

There's a huge list of pseudo-serial devices each with a different set 
of requirements, Bluetooth, RFC 2217, a host of proprietary systems, 
etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I 
have no clue how you'd implement them in a general/cross platform sense.

You haven't convinced me (and only me, others may see something that I 
don't, I'm not speaking for them) that this mechanism can be implemented 
in any practical sense.  That is, that the implementation could be wide 
enough to be consider generally available in RXTX regardless of the 
serial port implementation, platform, etc..  However, if you can come up 
with a general design and a reference implementation for one subsystem, 
I'd like to see it and might get on board.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 15:40:55 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 14:40:55 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449B080D.9080208@ergotech.com>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
Message-ID: <20060622214055.GA25497@freehold.crocodile.org>

On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote:
> 
> Vadim Tkachenko wrote:
> > Hello again,
> > 
> > And while I'm at it, why don't just say this: give me one good reason to
> > write 3+ different ways of handling removable devices, one for USB, one for
> > FireWire, one for serial...
> 
> You don't, they're all the same "I have lost communication with my 
> serial device".

"I have lost communication with my ${protocol} device".

> The only thing you could really do is improve error reporting by knowing 
> the exact sub-system.  ("Device X which is/was attached to USB port Y is 
> no longer functioning, please check the USB ports, the device, the 
> cables and anything else you can think of that may be a cause of 
> failure.")

"Device ${id} which is/was attached to ${protocol} port ${port} is no longer
functioning, please check the ${protocol} ports, the device, the
${protocol_media} and anything else you can think of that may be a cause of
failure".

>  That just requires an intelligent description of the port.

Agree absolutely.

> > I understand very well that this goes way beyond the scope of RxTx and
> > CommAPI and will require cooperation between them and javax.usb and whatever
> > JSR is responsible for FireWire implementation - but the end result is well
> > worth it. Abstract out and generalize arrival/departure/monitoring/discovery
> > API, provide protocol specific extensions for each, live happily ever after.
> 
> There's a huge list of pseudo-serial devices each with a different set 
> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, 
> etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I 
> have no clue how you'd implement them in a general/cross platform sense.

That's because some of the protocols were created decades ago when
autoconfiguration wasn't even conceived, much less practical. RS232/RS485
don't have a clue about identity discovery, and even capabilities discovery
beyond obvious 8N1 etc.

I agree that today all these protocols have generally incompatible
strategies for handling the situations I'm trying to address, but there's
nothing that says it's not an oversight. Besides, we're dealing with the
devices at a level of abstraction that allows some simplifications and
generalizations, at least part of the time - unless it's the protocol
specific features we're dealing with.

> You haven't convinced me (and only me, others may see something that I 
> don't, I'm not speaking for them) that this mechanism can be implemented 
> in any practical sense.  That is, that the implementation could be wide 
> enough to be consider generally available in RXTX regardless of the 
> serial port implementation, platform, etc..  However, if you can come up 
> with a general design and a reference implementation for one subsystem, 
> I'd like to see it and might get on board.

Actually, I wasn't even thinking about all this stuff when I wrote the first
message on the subject :) Now that you mention it - well, I'm not sure I can
chew the piece I just tried to bite in reasonable amount of time.

How do you eat an elephant? One bite at a time. If we could agree that a
small step in the specification is acceptable at this time, and express
further intentions, things may start happening.

To put it succinctly:

- Concept of a "port" should be augmented with a concept of a "device". A
device may be attached to a port in an implicit or explicit way.
- Implicitly connected device is exactly what the current scope of the
specification covers. No new functionality is offered.
- Explicitly connected device supports detachable device semantics, just as
other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a
few).
- The input and output streams are not properties of a port now, but
properties of the device attached to the port.
- A mechanism to allow listening for device arrivals and departures must be
made available.

That's it, off the top of my head.

I understand that this goes completely against current javax.comm specs, but
an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be
difficult to implement without disrupting javax.comm compatibility.

One concern is how to deal with the device identity - but there's no general
way of dealing with this at this time, devices may or may not offer identity
discovery.

> Jim

--vt


From joachim at buechse.de  Fri Jun 23 02:12:43 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 23 Jun 2006 10:12:43 +0200
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
Message-ID: <CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>

Hello++ Vadim,

I would like to repeat that your request is best addressed to the  
POSSIX standardization group - or maybe the BSD/Linux maintainers. If  
you convince the BSD or Linux guys to add this kind of functionality  
(they can as most of there VCP drivers are open source), there is a  
certain chance that other vendors will pick it up. I assure you that  
RXTX will happily provide this functionality once it's possible - I'm  
sure there is more than one maintainer that would love to add it.  
Having this concept penetrate the market may take some years though.

SHORT: The solution you would like to see could be added to the API  
but it can not be implemented (at least not on the platforms I know).  
There are currently no hooks in the kernel that allow you to discover  
"the device" or even the "means of connection" based on an existing  
"device file descriptor" ie COM-port or /dev/... entry. The name  
mapping of the device is handled by the virtual com port driver of  
the device. Unless you are suggesting RXTX should reimplement virtual  
com port drivers for all usb/serial bridges out there your request is  
understandable from a users viewpoint but simply not realizable. It's  
like asking that the Socket api should identify the computer behind  
an IP address (ie by its Ethernet address). While this COULD be  
implemented in TCP/IP, it IS not, and hence there is no point adding  
such a function to the Socket API.

The current trend for USB/Bluetooth/Irda/etc connected devices is  
going away from serial port abstraction towards RPC (ie the drivers  
provide a device specific or device class specific driver that  
provides an application level api to the device functions). The line  
level protocol is often not even published.

Best regards,
Joachim

On 22.06.2006, at 23:40, Vadim Tkachenko wrote:

> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote:
>>
>> Vadim Tkachenko wrote:
>>> Hello again,
>>>
>>> And while I'm at it, why don't just say this: give me one good  
>>> reason to
>>> write 3+ different ways of handling removable devices, one for  
>>> USB, one for
>>> FireWire, one for serial...
>>
>> You don't, they're all the same "I have lost communication with my
>> serial device".
>
> "I have lost communication with my ${protocol} device".
>
>> The only thing you could really do is improve error reporting by  
>> knowing
>> the exact sub-system.  ("Device X which is/was attached to USB  
>> port Y is
>> no longer functioning, please check the USB ports, the device, the
>> cables and anything else you can think of that may be a cause of
>> failure.")
>
> "Device ${id} which is/was attached to ${protocol} port ${port} is  
> no longer
> functioning, please check the ${protocol} ports, the device, the
> ${protocol_media} and anything else you can think of that may be a  
> cause of
> failure".
>
>>  That just requires an intelligent description of the port.
>
> Agree absolutely.
>
>>> I understand very well that this goes way beyond the scope of  
>>> RxTx and
>>> CommAPI and will require cooperation between them and javax.usb  
>>> and whatever
>>> JSR is responsible for FireWire implementation - but the end  
>>> result is well
>>> worth it. Abstract out and generalize arrival/departure/ 
>>> monitoring/discovery
>>> API, provide protocol specific extensions for each, live happily  
>>> ever after.
>>
>> There's a huge list of pseudo-serial devices each with a different  
>> set
>> of requirements, Bluetooth, RFC 2217, a host of proprietary systems,
>> etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I
>> have no clue how you'd implement them in a general/cross platform  
>> sense.
>
> That's because some of the protocols were created decades ago when
> autoconfiguration wasn't even conceived, much less practical. RS232/ 
> RS485
> don't have a clue about identity discovery, and even capabilities  
> discovery
> beyond obvious 8N1 etc.
>
> I agree that today all these protocols have generally incompatible
> strategies for handling the situations I'm trying to address, but  
> there's
> nothing that says it's not an oversight. Besides, we're dealing  
> with the
> devices at a level of abstraction that allows some simplifications and
> generalizations, at least part of the time - unless it's the protocol
> specific features we're dealing with.
>
>> You haven't convinced me (and only me, others may see something  
>> that I
>> don't, I'm not speaking for them) that this mechanism can be  
>> implemented
>> in any practical sense.  That is, that the implementation could be  
>> wide
>> enough to be consider generally available in RXTX regardless of the
>> serial port implementation, platform, etc..  However, if you can  
>> come up
>> with a general design and a reference implementation for one  
>> subsystem,
>> I'd like to see it and might get on board.
>
> Actually, I wasn't even thinking about all this stuff when I wrote  
> the first
> message on the subject :) Now that you mention it - well, I'm not  
> sure I can
> chew the piece I just tried to bite in reasonable amount of time.
>
> How do you eat an elephant? One bite at a time. If we could agree  
> that a
> small step in the specification is acceptable at this time, and  
> express
> further intentions, things may start happening.
>
> To put it succinctly:
>
> - Concept of a "port" should be augmented with a concept of a  
> "device". A
> device may be attached to a port in an implicit or explicit way.
> - Implicitly connected device is exactly what the current scope of the
> specification covers. No new functionality is offered.
> - Explicitly connected device supports detachable device semantics,  
> just as
> other protocols do (USB, FireWire, Wireless USB, Bluetooth, to  
> mention a
> few).
> - The input and output streams are not properties of a port now, but
> properties of the device attached to the port.
> - A mechanism to allow listening for device arrivals and departures  
> must be
> made available.
>
> That's it, off the top of my head.
>
> I understand that this goes completely against current javax.comm  
> specs, but
> an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern )  
> won't be
> difficult to implement without disrupting javax.comm compatibility.
>
> One concern is how to deal with the device identity - but there's  
> no general
> way of dealing with this at this time, devices may or may not offer  
> identity
> discovery.
>
>> Jim
>
> --vt
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From vt at freehold.crocodile.org  Fri Jun 23 11:28:29 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Fri, 23 Jun 2006 10:28:29 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
	<CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
Message-ID: <20060623172829.GA5335@freehold.crocodile.org>

Hello Joachim,

> I would like to repeat that your request is best addressed to the POSSIX
> standardization group - or maybe the BSD/Linux maintainers. If you
> convince the BSD or Linux guys to add this kind of functionality (they can
> as most of there VCP drivers are open source), there is a certain chance
> that other vendors will pick it up. I assure you that RXTX will happily
> provide this functionality once it's possible - I'm sure there is more
> than one maintainer that would love to add it.

I realize this thing is bigger than RxTx itself, and I'm afraid it's too
global not to cause people to laugh before they think about it :)

> Having this concept penetrate the market may take some years though.

Well, I'm sure it'll get there, the only question is - when.

> SHORT: The solution you would like to see could be added to the API but it
> can not be implemented (at least not on the platforms I know).

I guess I'm concerned about the abstraction more than I'm concerned about
the implementation at this point.
  
> There are currently no hooks in the kernel that allow you to discover  
> "the device" or even the "means of connection" based on an existing  
> "device file descriptor" ie COM-port or /dev/... entry.

Well, I'm not so sure you need to keep the literal mapping from /dev
namespace to your device namespace. As long as you can consistently offer a
virtual serial device on top of a virtual serial port, it may be irrelevant
whether you can map it into /dev. The mapping is going be schitzofrenic
anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the
representation...

> The name mapping of the device is handled by the virtual com port driver
> of the device. Unless you are suggesting RXTX should reimplement virtual
> com port drivers for all usb/serial bridges out there your request is
> understandable from a users viewpoint but simply not realizable.

It's not so much a request but rather an offer of participation. I run a few
projects actively using serial communications, as well as USB device
drivers, in different degrees of readiness (Servomaster, Haywire, DIY
Zoning) - and it would be a perfect playground.

You mentioned above that this task is about two things: a) abstraction b)
implementation. I could start the abstraction part of it without changing
the current CommAPI, on top of it, as an adapter. Even if the removable
device semantics are not implemented, but offered, this is already a step
forward.

> It's like asking that the Socket api should identify the computer behind
> an IP address (ie by its Ethernet address). While this COULD be
> implemented in TCP/IP, it IS not, and hence there is no point adding such
> a function to the Socket API.

Thank you for bringing up this example - I guess this is just about the same
thing that I'd like to see. Socket transparently provides you with the
input/output streams, at the same time offering protocol level specifics to
you.

> The current trend for USB/Bluetooth/Irda/etc connected devices is going
> away from serial port abstraction towards RPC (ie the drivers provide a
> device specific or device class specific driver that provides an
> application level api to the device functions). The line level protocol is
> often not even published.

I can't say I'm that happy with it. The best (or, rather, worst) example is
suchlike support for the Phidget servo controller - zealous Linux developers
implemented kernel module support for it, completely hijacking a possibility
of using it on a different level (it's somewhat fixed by now, thankfully).

I believe that whenever an abstraction is offered, it must be made optional
and/or pluggable so it can be replaced by something more suited to the task.

The nature of Java applications is such that they'd probably care much more
about Java API offered, than about no matter how rich application level api
that is offered outside of Java. I've dealt with JNI adapters in the past,
and whereas they can be made reasonably stable, the very fact that you are
forced to deal with things that are not on the critical timing/memory path
and could've been done much easier in Java causes endless grief.

> Joachim

--vt


From lyon at docjava.com  Sat Jun 24 04:54:12 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Sat, 24 Jun 2006 06:54:12 -0400
Subject: [Rxtx] jsr
In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
	<CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
	<20060623172829.GA5335@freehold.crocodile.org>
Message-ID: <p060204a3c0c2c9dde4f8@[192.168.1.152]>

Hi All,
I have had some off-list discussion with Trent.
Opening up a JSR with Sun, as per Peters' suggestion
seems like a reasonable idea, to us.

Does anyone having any concerns about the JSR process
that they would like to raise?

Thanks!
  - Doug



From the.grey.lantern at gmail.com  Sat Jun 24 18:15:26 2006
From: the.grey.lantern at gmail.com (Craig Nicoll)
Date: Sun, 25 Jun 2006 01:15:26 +0100
Subject: [Rxtx] Cannot create virtual serial port
Message-ID: <a1221cc50606241715g2d1e2af6r747347dd4c20e997@mail.gmail.com>

Hello,

This is my first post on this mailing list and I hope someone can help me.

I am having great difficult establishing a virtual serial port for the
Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia
7600.

Every time I try to run the SendMessage program that comes with SMSLib, I
get the following exception: gnu.io.NoSuchPortException

The port names I have tried are:
rfcomm0
rfcomm
/dev/rfcomm0
/dev/rfcomm

This is what I have done so far:
Modified /etc/bluetooth/rfcomm.conf to include the address of my phone:

rfcomm0 {
# Automatically bind the device at startup
bind no;

# Bluetooth address of the device
device 00:0e:6d:7a:98:43;

# RFCOMM channel for the connection
channel 1;

# Description of the connection
comment "Example Bluetooth device";
}

I also tried running the following command: rfcomm bind /dev/rfcomm0

I have searched the mailing list archives and found this post where someone
had a very similar problem to me:
http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried
changing the system properties as suggested and it made no difference.

I have also been scouring Google all day to no avail.

I would be incredibly grateful if anyone could give me some tips.

Thank you,

Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0005.html

From tjarvi at qbang.org  Sun Jun 25 19:56:08 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT)
Subject: [Rxtx] Pending release
Message-ID: <Pine.LNX.4.61.0606251942460.15744@www>


With frustration, I was unable to get to the pending release this weekend.
The release should be comming this next week once things calm down.
The source is in CVS except for a fix for multiple ports in windows.

I had planned on doing the release this weekend but that was disrupted by 
my transportation failing in a spectacular fashion.

--
Trent Jarvi
tjarvi at qbang.org


From Pawan.Kharbanda at dot.state.co.us  Tue Jun 27 22:28:51 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 27 Jun 2006 22:28:51 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>

 Trent, 
   I have an application running in a cluster in linux environment and I
am using RXTX2.1.7 (final) with JDK1.5. The application opens and closes
serial comm ports every 30 seconds and exchanges datas. I have
experienced some of my Comm Ports are left hanging (I can see the
LCK..cufXX lock files under /var/lock folder). On putting the debugs I
found out that, it is stuck at a native call line 809 in RXTXPort.java
class (Please see the code snippet below). Can you help me explain what
this method does in the native code? Am I getting into some thread
deadlocks? Thanks in advance.

Pawan Kharbanda 


public void removeEventListener()
	{
		if (debug)
			z.reportln( "RXTXPort:removeEventListener()
called");
		waitForTheNativeCodeSilly();
		//if( monThread != null && monThread.isAlive() )
		if( monThreadisInterrupted == true )
		{
			z.reportln( "	RXTXPort:removeEventListener()
already interrupted");
			monThread = null;
			SPEventListener = null;
			return;
		}
		else if( monThread != null && monThread.isAlive() )
		{
			if (debug)
				z.reportln( "
RXTXPort:Interrupt=true");
			monThreadisInterrupted=true;
			/*
			   Notify all threads in this PID that something
is up
			   They will call back to see if its their
thread
			   using isInterrupted().
			*/
			if (debug)
				z.reportln( "	RXTXPort:calling
interruptEventLoop");
// LINE 809			interruptEventLoop( ); It never returns
out of this 
			
			if (debug)
				z.reportln( "	RXTXPort:calling
monThread.join()");
			try {
				monThread.join(1000);
			} catch (Exception ex) {
				/* yikes */
				ex.printStackTrace();
			}
			if (debug)
				z.reportln( "	RXTXPort:waiting on
isAlive()");
			while( monThread.isAlive() )
			{
				if ( debug )
					z.reportln( "	MonThread is
still alive!");
				try {
					monThread.join(1000);
					Thread.sleep( 1000 );
				} catch( Exception e ){} 
				//monThread.stop();
			}
			
		}
		if (debug)
			z.reportln( "	RXTXPort:calling gc()");
		monThread = null;
		SPEventListener = null;
		MonitorThreadLock = false;
		MonitorThreadAlive=false;
		monThreadisInterrupted=true;
		z.reportln( "RXTXPort:removeEventListener() returning");
	} 

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Sunday, June 25, 2006 7:56 PM
To: rxtx at qbang.org
Subject: [Rxtx] Pending release


With frustration, I was unable to get to the pending release this
weekend.
The release should be comming this next week once things calm down.
The source is in CVS except for a fix for multiple ports in windows.

I had planned on doing the release this weekend but that was disrupted
by my transportation failing in a spectacular fashion.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Wed Jun 28 04:17:29 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 28 Jun 2006 04:17:29 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606280406330.9561@www>



Hi Pawan

You may have found a deadlock but I've not seen on recently on linux.

If you can, please update from CVS.  This will have some close fixes. 
I'm running with the same code as is in CVS.  It is not perfect but I've 
not seen anything like you mention.  Be sure to set timeouts and 
thresholds on the port.  It may be that the port is waiting on pending io 
that never happens.  I think the CVS patches deal with this also but it 
looks like your in a better test environment to know for sure.

The exploded vehicle mentioned below is expected to be fixed today.  It 
was just a ninja small radiator hose.  The pressure test afterwards 
created its own set of problems.  Until this is resolved, I'm spending 
most of my free time commuting by bicycle.

On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>   I have an application running in a cluster in linux environment and I
> am using RXTX2.1.7 (final) with JDK1.5. The application opens and closes
> serial comm ports every 30 seconds and exchanges datas. I have
> experienced some of my Comm Ports are left hanging (I can see the
> LCK..cufXX lock files under /var/lock folder). On putting the debugs I
> found out that, it is stuck at a native call line 809 in RXTXPort.java
> class (Please see the code snippet below). Can you help me explain what
> this method does in the native code? Am I getting into some thread
> deadlocks? Thanks in advance.
>
> Pawan Kharbanda
>
>
> public void removeEventListener()
> 	{
> 		if (debug)
> 			z.reportln( "RXTXPort:removeEventListener()
> called");
> 		waitForTheNativeCodeSilly();
> 		//if( monThread != null && monThread.isAlive() )
> 		if( monThreadisInterrupted == true )
> 		{
> 			z.reportln( "	RXTXPort:removeEventListener()
> already interrupted");
> 			monThread = null;
> 			SPEventListener = null;
> 			return;
> 		}
> 		else if( monThread != null && monThread.isAlive() )
> 		{
> 			if (debug)
> 				z.reportln( "
> RXTXPort:Interrupt=true");
> 			monThreadisInterrupted=true;
> 			/*
> 			   Notify all threads in this PID that something
> is up
> 			   They will call back to see if its their
> thread
> 			   using isInterrupted().
> 			*/
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> interruptEventLoop");
> // LINE 809			interruptEventLoop( ); It never returns
> out of this
>
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> monThread.join()");
> 			try {
> 				monThread.join(1000);
> 			} catch (Exception ex) {
> 				/* yikes */
> 				ex.printStackTrace();
> 			}
> 			if (debug)
> 				z.reportln( "	RXTXPort:waiting on
> isAlive()");
> 			while( monThread.isAlive() )
> 			{
> 				if ( debug )
> 					z.reportln( "	MonThread is
> still alive!");
> 				try {
> 					monThread.join(1000);
> 					Thread.sleep( 1000 );
> 				} catch( Exception e ){}
> 				//monThread.stop();
> 			}
>
> 		}
> 		if (debug)
> 			z.reportln( "	RXTXPort:calling gc()");
> 		monThread = null;
> 		SPEventListener = null;
> 		MonitorThreadLock = false;
> 		MonitorThreadAlive=false;
> 		monThreadisInterrupted=true;
> 		z.reportln( "RXTXPort:removeEventListener() returning");
> 	}
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Sunday, June 25, 2006 7:56 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] Pending release
>
>
> With frustration, I was unable to get to the pending release this
> weekend.
> The release should be comming this next week once things calm down.
> The source is in CVS except for a fix for multiple ports in windows.
>
> I had planned on doing the release this weekend but that was disrupted
> by my transportation failing in a spectacular fashion.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From Pawan.Kharbanda at dot.state.co.us  Wed Jun 28 12:11:06 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Wed, 28 Jun 2006 12:11:06 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>

Trent,
    Again thanks for the reply. First of all I have Receive timeouts set
on all communications including Max no of bytes to expect during the
call. I have noticed the problem is during "closing the connection". I
am not sure if the RXTX is 100% thread-safe yet. There seems to be a
glitch in the native calls. I am sure I have the latest code I did the
update on the Version 2.1.7 from CVS, is this where the latest updates
are located, I have noticed another version in CVS "rxtx-devel".

Regards
Pawan Kharbanda

    

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Wednesday, June 28, 2006 4:17 AM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports



Hi Pawan

You may have found a deadlock but I've not seen on recently on linux.

If you can, please update from CVS.  This will have some close fixes. 
I'm running with the same code as is in CVS.  It is not perfect but I've
not seen anything like you mention.  Be sure to set timeouts and
thresholds on the port.  It may be that the port is waiting on pending
io that never happens.  I think the CVS patches deal with this also but
it looks like your in a better test environment to know for sure.

The exploded vehicle mentioned below is expected to be fixed today.  It
was just a ninja small radiator hose.  The pressure test afterwards
created its own set of problems.  Until this is resolved, I'm spending
most of my free time commuting by bicycle.

On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>   I have an application running in a cluster in linux environment and 
> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and 
> closes serial comm ports every 30 seconds and exchanges datas. I have 
> experienced some of my Comm Ports are left hanging (I can see the 
> LCK..cufXX lock files under /var/lock folder). On putting the debugs I

> found out that, it is stuck at a native call line 809 in RXTXPort.java

> class (Please see the code snippet below). Can you help me explain 
> what this method does in the native code? Am I getting into some 
> thread deadlocks? Thanks in advance.
>
> Pawan Kharbanda
>
>
> public void removeEventListener()
> 	{
> 		if (debug)
> 			z.reportln( "RXTXPort:removeEventListener()
called");
> 		waitForTheNativeCodeSilly();
> 		//if( monThread != null && monThread.isAlive() )
> 		if( monThreadisInterrupted == true )
> 		{
> 			z.reportln( "	RXTXPort:removeEventListener()
> already interrupted");
> 			monThread = null;
> 			SPEventListener = null;
> 			return;
> 		}
> 		else if( monThread != null && monThread.isAlive() )
> 		{
> 			if (debug)
> 				z.reportln( "
> RXTXPort:Interrupt=true");
> 			monThreadisInterrupted=true;
> 			/*
> 			   Notify all threads in this PID that something
is up
> 			   They will call back to see if its their
thread
> 			   using isInterrupted().
> 			*/
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> interruptEventLoop");
> // LINE 809			interruptEventLoop( ); It never returns
> out of this
>
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> monThread.join()");
> 			try {
> 				monThread.join(1000);
> 			} catch (Exception ex) {
> 				/* yikes */
> 				ex.printStackTrace();
> 			}
> 			if (debug)
> 				z.reportln( "	RXTXPort:waiting on
> isAlive()");
> 			while( monThread.isAlive() )
> 			{
> 				if ( debug )
> 					z.reportln( "	MonThread is
> still alive!");
> 				try {
> 					monThread.join(1000);
> 					Thread.sleep( 1000 );
> 				} catch( Exception e ){}
> 				//monThread.stop();
> 			}
>
> 		}
> 		if (debug)
> 			z.reportln( "	RXTXPort:calling gc()");
> 		monThread = null;
> 		SPEventListener = null;
> 		MonitorThreadLock = false;
> 		MonitorThreadAlive=false;
> 		monThreadisInterrupted=true;
> 		z.reportln( "RXTXPort:removeEventListener() returning");
> 	}
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf

> Of Trent Jarvi
> Sent: Sunday, June 25, 2006 7:56 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] Pending release
>
>
> With frustration, I was unable to get to the pending release this 
> weekend.
> The release should be comming this next week once things calm down.
> The source is in CVS except for a fix for multiple ports in windows.
>
> I had planned on doing the release this weekend but that was disrupted

> by my transportation failing in a spectacular fashion.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Wed Jun 28 12:26:21 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 28 Jun 2006 12:26:21 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606281222420.9561@www>


Hi Pawan

If you did a cvs update from the 2.1-7 tar ball, you have the current 
version.  All rxtx in CVS is under rxtx-devel.  The 2.1-7 just has -r
commapi-0-0-1.

You may well have found something.  I have seen win32 fail on closing 
ports but not linux that I can think of.  Your use is much different than 
I normally see too.

Could you give us more information on how we would reproduce this and the 
frequency?


On Wed, 28 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>    Again thanks for the reply. First of all I have Receive timeouts set
> on all communications including Max no of bytes to expect during the
> call. I have noticed the problem is during "closing the connection". I
> am not sure if the RXTX is 100% thread-safe yet. There seems to be a
> glitch in the native calls. I am sure I have the latest code I did the
> update on the Version 2.1.7 from CVS, is this where the latest updates
> are located, I have noticed another version in CVS "rxtx-devel".
>
> Regards
> Pawan Kharbanda
>
>
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Wednesday, June 28, 2006 4:17 AM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] Locked Ports
>
>
>
> Hi Pawan
>
> You may have found a deadlock but I've not seen on recently on linux.
>
> If you can, please update from CVS.  This will have some close fixes.
> I'm running with the same code as is in CVS.  It is not perfect but I've
> not seen anything like you mention.  Be sure to set timeouts and
> thresholds on the port.  It may be that the port is waiting on pending
> io that never happens.  I think the CVS patches deal with this also but
> it looks like your in a better test environment to know for sure.
>
> The exploded vehicle mentioned below is expected to be fixed today.  It
> was just a ninja small radiator hose.  The pressure test afterwards
> created its own set of problems.  Until this is resolved, I'm spending
> most of my free time commuting by bicycle.
>
> On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:
>
>> Trent,
>>   I have an application running in a cluster in linux environment and
>> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and
>> closes serial comm ports every 30 seconds and exchanges datas. I have
>> experienced some of my Comm Ports are left hanging (I can see the
>> LCK..cufXX lock files under /var/lock folder). On putting the debugs I
>
>> found out that, it is stuck at a native call line 809 in RXTXPort.java
>
>> class (Please see the code snippet below). Can you help me explain
>> what this method does in the native code? Am I getting into some
>> thread deadlocks? Thanks in advance.
>>
>> Pawan Kharbanda
>>
>>
>> public void removeEventListener()
>> 	{
>> 		if (debug)
>> 			z.reportln( "RXTXPort:removeEventListener()
> called");
>> 		waitForTheNativeCodeSilly();
>> 		//if( monThread != null && monThread.isAlive() )
>> 		if( monThreadisInterrupted == true )
>> 		{
>> 			z.reportln( "	RXTXPort:removeEventListener()
>> already interrupted");
>> 			monThread = null;
>> 			SPEventListener = null;
>> 			return;
>> 		}
>> 		else if( monThread != null && monThread.isAlive() )
>> 		{
>> 			if (debug)
>> 				z.reportln( "
>> RXTXPort:Interrupt=true");
>> 			monThreadisInterrupted=true;
>> 			/*
>> 			   Notify all threads in this PID that something
> is up
>> 			   They will call back to see if its their
> thread
>> 			   using isInterrupted().
>> 			*/
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> interruptEventLoop");
>> // LINE 809			interruptEventLoop( ); It never returns
>> out of this
>>
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> monThread.join()");
>> 			try {
>> 				monThread.join(1000);
>> 			} catch (Exception ex) {
>> 				/* yikes */
>> 				ex.printStackTrace();
>> 			}
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:waiting on
>> isAlive()");
>> 			while( monThread.isAlive() )
>> 			{
>> 				if ( debug )
>> 					z.reportln( "	MonThread is
>> still alive!");
>> 				try {
>> 					monThread.join(1000);
>> 					Thread.sleep( 1000 );
>> 				} catch( Exception e ){}
>> 				//monThread.stop();
>> 			}
>>
>> 		}
>> 		if (debug)
>> 			z.reportln( "	RXTXPort:calling gc()");
>> 		monThread = null;
>> 		SPEventListener = null;
>> 		MonitorThreadLock = false;
>> 		MonitorThreadAlive=false;
>> 		monThreadisInterrupted=true;
>> 		z.reportln( "RXTXPort:removeEventListener() returning");
>> 	}
>>
>> -----Original Message-----
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
>
>> Of Trent Jarvi
>> Sent: Sunday, June 25, 2006 7:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] Pending release
>>
>>
>> With frustration, I was unable to get to the pending release this
>> weekend.
>> The release should be comming this next week once things calm down.
>> The source is in CVS except for a fix for multiple ports in windows.
>>
>> I had planned on doing the release this weekend but that was disrupted
>
>> by my transportation failing in a spectacular fashion.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From Pawan.Kharbanda at dot.state.co.us  Wed Jun 28 15:42:49 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Wed, 28 Jun 2006 15:42:49 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>

Trent,
    I will try to explain how I am setup and will try to write you a
Sample code little later to reproduce this. On our system we have
DigiBoxes installed on the 2 Linux servers. Both of them have RXTX2.1-7
version installed with the JRE(1.5) and both the machines have the same
port mappings in gnu.io.rxtx.properties (Currently in the production
system I have 64 ports). This is how the system works:

1) A thick Map based client initiates a Action on the Device on the
field. One of the Thread Workers(Asynchronous Call) in the Cluster picks
up the request. 
2) Once the worker gets the request it locks the Device and
Communication port in the DB's(These are our persistent locks, because
most of the devices do one to one communication with the serial ports).
After that the worker (or Comm Server) opens up the connection and after
exchanging the information calls the "Close" and returns.
3) Once the connection is closed , the DB lock is removed on the comm
port and is made available to accept future calls. Here is where the
glitch is the Serial Comm Close method never returns due to the
deadlock. 

I have noticed that the deadlocks are very inconsistent, sometime it
happens right away as soon as Application server starts and sometimes I
don't see any deadlocks for days, but it happens for sure. 

Here is how you can test if you have resources/ test environment. Write
a program and try to open/close  different ports(I will say have a
minimum of four) randomly and very frequently(may be 30 seconds), I am
pretty sure you will see the deadlocks and it happens in the native call
to interrptEventLoop in RXTXPort.java in removeEventListener() method
call.

Also I have noticed that the JVM carshes (without any memrory errors or
JVM errors. Its just not there) when native call is made to eventLoop()
in run() method in MonitorThread inner class. I am still investigating
why this is happening, but at this point I can just tell you the
location. You might have a question How I am so sure about the location?
My application is configured with Log4J and I have enabled the debugs on
the RXTXPort.java, so every time my JVM dies I see these logs at the end
of the file.

"2006-06-28 15:27:15,183 INFO  [STDOUT] RXTXPort:RXTXPort(/dev/cub01)
called
2006-06-28 15:27:15,218 INFO  [STDOUT]
RXTXPort:MontitorThread:MonitorThread()
2006-06-28 15:27:15,219 INFO  [STDOUT] RXTXPort:MontitorThread:run()"

I surely do have a luxury of a testing environment(ports, devices etc.)
and can help you fix these problems? Please advise me how we can resolve
these issues.

Thanks 
Pawan Kharbanda
303-478-2991





-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Wednesday, June 28, 2006 12:26 PM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports


Hi Pawan

If you did a cvs update from the 2.1-7 tar ball, you have the current
version.  All rxtx in CVS is under rxtx-devel.  The 2.1-7 just has -r
commapi-0-0-1.

You may well have found something.  I have seen win32 fail on closing
ports but not linux that I can think of.  Your use is much different
than I normally see too.

Could you give us more information on how we would reproduce this and
the frequency?


On Wed, 28 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>    Again thanks for the reply. First of all I have Receive timeouts
set
> on all communications including Max no of bytes to expect during the
> call. I have noticed the problem is during "closing the connection". I
> am not sure if the RXTX is 100% thread-safe yet. There seems to be a
> glitch in the native calls. I am sure I have the latest code I did the
> update on the Version 2.1.7 from CVS, is this where the latest updates
> are located, I have noticed another version in CVS "rxtx-devel".
>
> Regards
> Pawan Kharbanda
>
>
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Wednesday, June 28, 2006 4:17 AM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] Locked Ports
>
>
>
> Hi Pawan
>
> You may have found a deadlock but I've not seen on recently on linux.
>
> If you can, please update from CVS.  This will have some close fixes.
> I'm running with the same code as is in CVS.  It is not perfect but
I've
> not seen anything like you mention.  Be sure to set timeouts and
> thresholds on the port.  It may be that the port is waiting on pending
> io that never happens.  I think the CVS patches deal with this also
but
> it looks like your in a better test environment to know for sure.
>
> The exploded vehicle mentioned below is expected to be fixed today.
It
> was just a ninja small radiator hose.  The pressure test afterwards
> created its own set of problems.  Until this is resolved, I'm spending
> most of my free time commuting by bicycle.
>
> On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:
>
>> Trent,
>>   I have an application running in a cluster in linux environment and
>> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and
>> closes serial comm ports every 30 seconds and exchanges datas. I have
>> experienced some of my Comm Ports are left hanging (I can see the
>> LCK..cufXX lock files under /var/lock folder). On putting the debugs
I
>
>> found out that, it is stuck at a native call line 809 in
RXTXPort.java
>
>> class (Please see the code snippet below). Can you help me explain
>> what this method does in the native code? Am I getting into some
>> thread deadlocks? Thanks in advance.
>>
>> Pawan Kharbanda
>>
>>
>> public void removeEventListener()
>> 	{
>> 		if (debug)
>> 			z.reportln( "RXTXPort:removeEventListener()
> called");
>> 		waitForTheNativeCodeSilly();
>> 		//if( monThread != null && monThread.isAlive() )
>> 		if( monThreadisInterrupted == true )
>> 		{
>> 			z.reportln( "	RXTXPort:removeEventListener()
>> already interrupted");
>> 			monThread = null;
>> 			SPEventListener = null;
>> 			return;
>> 		}
>> 		else if( monThread != null && monThread.isAlive() )
>> 		{
>> 			if (debug)
>> 				z.reportln( "
>> RXTXPort:Interrupt=true");
>> 			monThreadisInterrupted=true;
>> 			/*
>> 			   Notify all threads in this PID that something
> is up
>> 			   They will call back to see if its their
> thread
>> 			   using isInterrupted().
>> 			*/
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> interruptEventLoop");
>> // LINE 809			interruptEventLoop( ); It never returns
>> out of this
>>
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> monThread.join()");
>> 			try {
>> 				monThread.join(1000);
>> 			} catch (Exception ex) {
>> 				/* yikes */
>> 				ex.printStackTrace();
>> 			}
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:waiting on
>> isAlive()");
>> 			while( monThread.isAlive() )
>> 			{
>> 				if ( debug )
>> 					z.reportln( "	MonThread is
>> still alive!");
>> 				try {
>> 					monThread.join(1000);
>> 					Thread.sleep( 1000 );
>> 				} catch( Exception e ){}
>> 				//monThread.stop();
>> 			}
>>
>> 		}
>> 		if (debug)
>> 			z.reportln( "	RXTXPort:calling gc()");
>> 		monThread = null;
>> 		SPEventListener = null;
>> 		MonitorThreadLock = false;
>> 		MonitorThreadAlive=false;
>> 		monThreadisInterrupted=true;
>> 		z.reportln( "RXTXPort:removeEventListener() returning");
>> 	}
>>
>> -----Original Message-----
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On
Behalf
>
>> Of Trent Jarvi
>> Sent: Sunday, June 25, 2006 7:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] Pending release
>>
>>
>> With frustration, I was unable to get to the pending release this
>> weekend.
>> The release should be comming this next week once things calm down.
>> The source is in CVS except for a fix for multiple ports in windows.
>>
>> I had planned on doing the release this weekend but that was
disrupted
>
>> by my transportation failing in a spectacular fashion.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx 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 khattar31 at yahoo.com  Wed Jun 28 22:04:59 2006
From: khattar31 at yahoo.com (rahul khattar)
Date: Wed, 28 Jun 2006 21:04:59 -0700 (PDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
Message-ID: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>

Hi All,

I was looking at the src file on the last release.
I did notice a missing header file while trying to
compile the parallelport.dll. Would somebody be kind
enoughf to share the missing header file:
gnu_io_LPRPort.h

I am using MinGw to compile the same from Parinya
(which is an execellent tool)


Regards,
Rahul Khattar

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Thu Jun 29 03:43:53 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 03:43:53 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>
References: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606290341210.9561@www>

On Wed, 28 Jun 2006, rahul khattar wrote:

> Hi All,
>
> I was looking at the src file on the last release.
> I did notice a missing header file while trying to
> compile the parallelport.dll. Would somebody be kind
> enoughf to share the missing header file:
> gnu_io_LPRPort.h
>
> I am using MinGw to compile the same from Parinya
> (which is an execellent tool)
>

Hi Rahul

The gnu.io_LPRPort.h file is generated with javah.  You can see the 
command in the Makefile I presume.  You do not need rxtxParallel.dll to 
use w32 serial btw.

--
Trent Jarvi
tjarvi at qbang.org


From khattar31 at yahoo.com  Thu Jun 29 04:47:01 2006
From: khattar31 at yahoo.com (rahul khattar)
Date: Thu, 29 Jun 2006 03:47:01 -0700 (PDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606290341210.9561@www>
Message-ID: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>

Hi Trent 
I did notice this file is required in the source file
ParallelImp.c
on line 38

Attached the O/P 

Regards,
Rahul Khattar




--- Trent Jarvi <tjarvi at qbang.org> wrote:

> On Wed, 28 Jun 2006, rahul khattar wrote:
> 
> > Hi All,
> >
> > I was looking at the src file on the last release.
> > I did notice a missing header file while trying to
> > compile the parallelport.dll. Would somebody be
> kind
> > enoughf to share the missing header file:
> > gnu_io_LPRPort.h
> >
> > I am using MinGw to compile the same from Parinya
> > (which is an execellent tool)
> >
> 
> Hi Rahul
> 
> The gnu.io_LPRPort.h file is generated with javah. 
> You can see the 
> command in the Makefile I presume.  You do not need
> rxtxParallel.dll to 
> use w32 serial btw.
> 
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Error.zip
Type: application/x-zip-compressed
Size: 1746 bytes
Desc: 2948039066-Error.zip
Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060629/a5b6f783/Error-0005.bin

From tjarvi at qbang.org  Thu Jun 29 06:16:24 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 06:16:24 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606290614530.9561@www>

On Thu, 29 Jun 2006, rahul khattar wrote:

> Hi Trent
> I did notice this file is required in the source file
> ParallelImp.c
> on line 38
>
> Attached the O/P
>

The command to generate the .h file will be something like:

javah -classpath . -jni gnu.io.LPRPort

The makefile should have this.  There are several approaches to creating 
or using makefiles so I have no idea which one you used if any.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Thu Jun 29 06:20:51 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 06:20:51 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606290616420.9561@www>

> Here is how you can test if you have resources/ test environment. Write
> a program and try to open/close  different ports(I will say have a
> minimum of four) randomly and very frequently(may be 30 seconds), I am
> pretty sure you will see the deadlocks and it happens in the native call
> to interrptEventLoop in RXTXPort.java in removeEventListener() method
> call.

Hi Pawan

I'll try to find a way to reproduce this.  One thing to note is that you 
are using different kernel drivers (digi) to perform this task.  So I 
probably will not be able to reproduce the exact same environment.

In general, multiport kernel drivers have been tested far less than 
typical serial drivers.  This may or may not be an issue.

--
Trent Jarvi
tjarvi at qbang.org



From jhaysonn at gmail.com  Thu Jun 29 12:29:13 2006
From: jhaysonn at gmail.com (jhaysonn pathak)
Date: Thu, 29 Jun 2006 14:29:13 -0400
Subject: [Rxtx] RXTX install
Message-ID: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>

Hi Guys,

I'm doing trying to write a generative piece of Sonic Art using an EEG
plugged into a mac runnning Max/MSP.  I just recently discovered RXTX
drivers in my search for a piece of software that might give me more
output options for my EEG (I'm using the CEO from MindPeak).  I found
Bioera which uses RXTX drivers.  Thing is - I can't figure out how to
install RXTX correctly.

After I build the 'libSerial.jnilib' target inside of
'LibSerial.pbproj' I can't find the libSerial.jnilib file that
accompanies the RXTXcomm.jar nor do I know where to put them.

I also don't understand this part at the bottom of the OS X instructions at all:

"AFTER INSTALLATION VERY IMPORTANT
	check existence of the folder /var/spool/uucp
	if you don't have it create it with command
	sudo mkdir /var/spool/uucp
	permissions should be: drwxrwxr-x
	if they are not do command
	sudo chmod 775 /var/spool/uucp

	YOU should be a member of the uucp group
	you can check it with command
		niutil -readprop / /groups/uucp users
	you should see your name in output of the niutil command
	if you don't do following:
		sudo niutil -appendprop / /groups/uucp users <yourname>
			substitute  <yourname> with your user's name
			for example if your user name is peter:
				sudo niutil -appendprop / /groups/uucp users peter

	NOTES: RXTX.pkg should create uucp folder and insert your name  in
uucp group automatically"



I really appreciate any help that you guys can offer.  I've been
struggling with this for a while now as part of a research grant that
I was awarded.  Thanks again for the help.

Jhaysonn Pathak


From naranjo.manuel at gmail.com  Thu Jun 29 07:19:15 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 10:19:15 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606290614530.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www>
Message-ID: <44A3D353.6010605@gmail.com>

Speaking about Windows Support, I had seen that inside the 
rxtx-2.1-7-bins-r2 package inside Windows directory it says:
"i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will 
not make harm to anyone, and i'm almost sure that someone has noticed it 
before.
Cheers,
Manuel


From joachim at buechse.de  Thu Jun 29 13:25:16 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 29 Jun 2006 21:25:16 +0200
Subject: [Rxtx] RXTX install
In-Reply-To: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>
References: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>
Message-ID: <2A003E42-97E1-4237-8438-646BDE2E3961@buechse.de>

Hello Jhaysonn,

I assume you are trying to use the javax.comm version of RXTX.

Please use "cvs up" to update your download to the latest version of  
the repository. The latest version does not use lock files, so the  
mentioned process is no longer needed. Updating with CVS will also  
provide you with a new README.OSX file that should be simpler to  
understand.

You will find LibSerialUniversal.xcodeproj in MACOSX_IDE/Xcode. Put  
comm.jar (downloaded from Sun) into MACOSX_IDE/Xcode. Compile the  
library. You will find RXTXcomm.jar and librxtxSerial.jnilib in  
MACOSX_IDE/Xcode/build/Default

Best regards,
Joachim
---
Joachim B?chse
Softwarel?sungen und Beratung
Hadlaubsteig 2
CH-8006 Z?rich


On 29.06.2006, at 20:29, jhaysonn pathak wrote:

> Hi Guys,
>
> I'm doing trying to write a generative piece of Sonic Art using an EEG
> plugged into a mac runnning Max/MSP.  I just recently discovered RXTX
> drivers in my search for a piece of software that might give me more
> output options for my EEG (I'm using the CEO from MindPeak).  I found
> Bioera which uses RXTX drivers.  Thing is - I can't figure out how to
> install RXTX correctly.
>
> After I build the 'libSerial.jnilib' target inside of
> 'LibSerial.pbproj' I can't find the libSerial.jnilib file that
> accompanies the RXTXcomm.jar nor do I know where to put them.
>
> I also don't understand this part at the bottom of the OS X  
> instructions at all:
>
> "AFTER INSTALLATION VERY IMPORTANT
> 	check existence of the folder /var/spool/uucp
> 	if you don't have it create it with command
> 	sudo mkdir /var/spool/uucp
> 	permissions should be: drwxrwxr-x
> 	if they are not do command
> 	sudo chmod 775 /var/spool/uucp
>
> 	YOU should be a member of the uucp group
> 	you can check it with command
> 		niutil -readprop / /groups/uucp users
> 	you should see your name in output of the niutil command
> 	if you don't do following:
> 		sudo niutil -appendprop / /groups/uucp users <yourname>
> 			substitute  <yourname> with your user's name
> 			for example if your user name is peter:
> 				sudo niutil -appendprop / /groups/uucp users peter
>
> 	NOTES: RXTX.pkg should create uucp folder and insert your name  in
> uucp group automatically"
>
>
>
> I really appreciate any help that you guys can offer.  I've been
> struggling with this for a while now as part of a research grant that
> I was awarded.  Thanks again for the help.
>
> Jhaysonn Pathak
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From tjarvi at qbang.org  Thu Jun 29 19:30:00 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 19:30:00 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A3D353.6010605@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
Message-ID: <Pine.LNX.4.61.0606291923000.9561@www>

On Thu, 29 Jun 2006, Manuel Naranjo wrote:

> Speaking about Windows Support, I had seen that inside the
> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
> not make harm to anyone, and i'm almost sure that someone has noticed it
> before.

Hi Manuel

         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
     47421  01-30-06 00:23 
rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
     77759  03-01-06 12:01 
rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README


It looks normal to me.  There are no fancy tools used there :)

--
Trent Jarvi
tjarvi at qbang.org

From naranjo.manuel at gmail.com  Thu Jun 29 19:38:16 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 22:38:16 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606291923000.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com> <Pine.LNX.4.61.0606291923000.9561@www>
Message-ID: <44A48088.2040407@gmail.com>

> On Thu, 29 Jun 2006, Manuel Naranjo wrote:
> 
>> Speaking about Windows Support, I had seen that inside the
>> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
>> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
>> not make harm to anyone, and i'm almost sure that someone has noticed it
>> before.
> 
> Hi Manuel
> 
>         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
>         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
>     47421  01-30-06 00:23 
> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
>     77759  03-01-06 12:01 
> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
>       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README
> 
> 
> It looks normal to me.  There are no fancy tools used there :)
> 
Hi Trent:
Is not the i368 representing the name of the Architecture?? If so the 
name should start with i386 it will not break any system, is simply miss
written, I saw that and wanted to report it. It a silly thing.
Ohh I forgoten I must congratulate you for your GREAT libray, I was able 
to make an .exe with JSmooth that launches an application that uses RXTX 
with out the need to install RXTX on users system :). The .exe tells JVM 
where to find the RXTX Library and Binaries. I tried with Sun's Java 
Comm but it was imposible.
Regards,
Manuel


From tjarvi at qbang.org  Thu Jun 29 19:52:45 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 19:52:45 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A48088.2040407@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
	<Pine.LNX.4.61.0606291923000.9561@www> <44A48088.2040407@gmail.com>
Message-ID: <Pine.LNX.4.61.0606291945060.9561@www>

On Thu, 29 Jun 2006, Manuel Naranjo wrote:

>> On Thu, 29 Jun 2006, Manuel Naranjo wrote:
>>
>>> Speaking about Windows Support, I had seen that inside the
>>> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
>>> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
>>> not make harm to anyone, and i'm almost sure that someone has noticed it
>>> before.
>>
>> Hi Manuel
>>
>>         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
>>         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
>>     47421  01-30-06 00:23
>> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
>>     77759  03-01-06 12:01
>> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
>>       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README
>>
>>
>> It looks normal to me.  There are no fancy tools used there :)
>>
> Hi Trent:
> Is not the i368 representing the name of the Architecture?? If so the
> name should start with i386 it will not break any system, is simply miss
> written, I saw that and wanted to report it. It a silly thing.
> Ohh I forgoten I must congratulate you for your GREAT libray, I was able
> to make an .exe with JSmooth that launches an application that uses RXTX
> with out the need to install RXTX on users system :). The .exe tells JVM
> where to find the RXTX Library and Binaries. I tried with Sun's Java
> Comm but it was imposible.

Hi Manuel

The compiler uses only the i386 instruction set for windows.  I doubt 
there will be any measurable advantages with going to later instruction 
sets.  In theory rxtx would run on a 386 but I doubt anyone does that.

So it looks odd but is not a typo.

We could compile to i686 but don't.  The compiler used does not appear to 
be a problem yet so I don't see any point in changing it.  Right now, we 
could not compile 64 bit windows binaries.  gcc/mingw/... do not support 
them that I know of.  People will have to compile those with closed source 
tools on their own until an option is available.

--
Trent Jarvi
tjarvi at qbang.org

From naranjo.manuel at gmail.com  Thu Jun 29 20:00:48 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 23:00:48 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606291945060.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com>	<Pine.LNX.4.61.0606291923000.9561@www>
	<44A48088.2040407@gmail.com> <Pine.LNX.4.61.0606291945060.9561@www>
Message-ID: <44A485D0.7050202@gmail.com>

Trent you did not get my point
The folder says 368 three hundred sixty eight, when
it should say 386 three hundred eighty six. Is simply a miss writting.
Regards,
Manuel


From tjarvi at qbang.org  Thu Jun 29 20:12:15 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 20:12:15 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A485D0.7050202@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
	<Pine.LNX.4.61.0606291923000.9561@www> <44A48088.2040407@gmail.com>
	<Pine.LNX.4.61.0606291945060.9561@www> <44A485D0.7050202@gmail.com>
Message-ID: <Pine.LNX.4.61.0606292008061.9561@www>


On Thu, 29 Jun 2006, Manuel Naranjo wrote:

> Trent you did not get my point
> The folder says 368 three hundred sixty eight, when
> it should say 386 three hundred eighty six. Is simply a miss writting.

hehe..  OK.  My bad.  It's been a long day.

Nevermind :)

--
Trent Jarvi
tjarvi at qbang.org




From naranjo.manuel at gmail.com  Thu Jun 29 20:18:44 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 23:18:44 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606292008061.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com>	<Pine.LNX.4.61.0606291923000.9561@www>
	<44A48088.2040407@gmail.com>	<Pine.LNX.4.61.0606291945060.9561@www>
	<44A485D0.7050202@gmail.com> <Pine.LNX.4.61.0606292008061.9561@www>
Message-ID: <44A48A04.9040401@gmail.com>

Don't worry Trent.
About 64 bits compilation, I would like to colaborate, I have a Pc with 
64 bits, the only problem is that i do not have windows 64 bits 
installed :(.




From Pawan.Kharbanda at dot.state.co.us  Fri Jun 30 08:49:52 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 30 Jun 2006 08:49:52 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E996@hqexchange3.dot.state.co.us>

Trent,  
    Can you explain what the interruptedEventLoop() native method is
doing is there a possibility that method is somehow getting into the
infinite loop(there are 2 while loops without any break statements).
This might be a very basic question how can I debug the native code(or
print the debug statements).  Again thanks for the help. 

Pawan Kharbanda

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Thursday, June 29, 2006 6:21 AM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports

> Here is how you can test if you have resources/ test environment. 
> Write a program and try to open/close  different ports(I will say have

> a minimum of four) randomly and very frequently(may be 30 seconds), I 
> am pretty sure you will see the deadlocks and it happens in the native

> call to interrptEventLoop in RXTXPort.java in removeEventListener() 
> method call.

Hi Pawan

I'll try to find a way to reproduce this.  One thing to note is that you
are using different kernel drivers (digi) to perform this task.  So I
probably will not be able to reproduce the exact same environment.

In general, multiport kernel drivers have been tested far less than
typical serial drivers.  This may or may not be an issue.

--
Trent Jarvi
tjarvi at qbang.org

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From cpine at wrsystems.com  Thu Jun 29 15:17:12 2006
From: cpine at wrsystems.com (Chris Pine)
Date: Thu, 29 Jun 2006 17:17:12 -0400
Subject: [Rxtx]  Controlling Individual Signals DTR and RTS
Message-ID: <MAIL4FJo0S8ACLEBajJ000005cf@mail4.wrsystems.com>

Dear Moussa Ba,
	I hope I am not being too forward, but we are having the exact same
issue with needing to control DTR from RXTX in Linux.  Did you ever have any
luck figuring it out?

Thank you very much for your time,

Chris Pine




From tjarvi at qbang.org  Thu Jun  1 11:13:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 11:13:40 -0600 (MDT)
Subject: [Rxtx] custom baud rate win32
In-Reply-To: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606011107210.30220@www>


Hi Daren

I can't imagine that 1953 is possibly the actual value on the UART.  Maybe 
if your baud base is very high with a custom serial board.  More likely, 
the driver just remembers that what you asked for and did something else.

I'll have more to say on the dcb->BaudRate after I try some things here. 
I have managed to do something like that in the past as a quick hack but 
it was for 14400.  I may have used the CBR_14400.

If we can't access this through the win32 API with protected mode, there 
is another layer of complication.  With real mode, it would be easy.
With protected mode, I assume there would have to be some kernel driver or 
a hook I'm not aware of to access the MCR directly (bang a memory 
addresss).



On Thu, 1 Jun 2006, Daren wrote:

> Trent,
> I have managed to successfully open the port at this speed using Realterm
> (available on sourceforge). From memory this uses DLPortIO.
>
> Using portmon.exe with realterm, even there it says that the port has opened
> at 1953.
>
> I changed termios.c:560 to
> dcb->BaudRate        = 1953 ;
>
> and it still opens the port at 9600.
>
> Daren
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Trent Jarvi
> Sent: Thursday, 1 June 2006 1:44 PM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] custom baud rate win32
>
> On Thu, 1 Jun 2006, Daren wrote:
>
>> Hi all,
>>
>> I downloaded 2.1.7-pre16 and managed to build it and get it going. I made
>> the changes as suggested by Peter Smith in an old post, by adding his code
>> to SerialImpl.c, uncommenting the TIOCGSERIAL and TIOCSSERIAL, and
> defining
>> ASYNC_SPD_CUST which is equal to 0x0030 (according to linus header
> files)..
>>
>>
>> Still not working, it opens the port at 9600 according to portmon.exe .
> Has
>> anyone managed to get this going at a custom rate?
>>
>> Here is the post I'm referring to:
>> http://marc.theaimsgroup.com/?l=rxtx&m=106270038110713&w=2
>>
>>
>> Thanks,
>> Daren
>>
>> ________________________________________
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
>> Daren
>> Sent: Wednesday, 31 May 2006 10:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] (no subject)
>>
>> Hi All,
>> I have been using rxtx for a little while and needed to get it working at
>> 1953, like a past user in the mailing list, who seemed to have got it
>> working by changing some C code.
>>
>> I wanted to build rxtx myself with these changes but don't know where to
>> start. I have windows here and FC4 at home. I downloaded cygwin and
> mingw32,
>> each build works by building a rxtxSerial.dll file that is ~11k smaller
> than
>> the original, and I always get the following error when testing the dll:
>>
>> Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at
>> PC=0x8077655
>> Function=[Unknown.]
>> Library=C:\opt\java\j2sdk1.4.2\jre\bin\client\jvm.dll
>>
>> NOTE: We are unable to locate the function name symbol for the error
>>      just occurred. Please refer to release documentation for possible
>>      reason and solutions.
>>
>>
>> Current Java thread:
>> 	at gnu.io.RXTXPort.open(Native Method)
>> 	- locked <0x1002c800> (a gnu.io.RXTXPort)
>> 	at gnu.io.RXTXPort.<init>(RXTXPort.java:84)
>>
>> Anyone know what im doing wrong?
>>
>>
>>
>>
>
> Hi Daren
>
> You are running into the same rats nest I'm looking at now.
>
> With win32 and specific custom baud rates, I'm not sure how this will go.
> I've got the Linux custom baud rates working very nicely.  I did much like
> the post you linked.  In fact I had forgot about that post.  You probably
> noticed that it becomes a bunch of dirt roads going noplace fast in
> termios.c for w32.
>
> I'm probably only going to get 14400, 28800, 128000 and 256000 working
> with the next release on w32.  I'll look a little further.  If you have an
> example w32 that works at 1953 I'd really like to hear.  Thats an unusual
> baud rate.
>
> Assuming a baud_base of 128000, your divisor will be 65 or 66.
>
> 128000/66=1939 -14
> 128000/65=1969 +13
>
> One thing I've been wondering about with linux is which would be the right
> answer in cases like this.  Right now it would just go with a baud base of
> 65 and ignore the modulus details.
>
> It appears to be a general trend for kernel developers to hide these
> details thinking that they can come up with a general solution.  Then they
> run out of time.  Perahps the solution is to help out but there are
> ultiple OS's rxtx supports making that nontrivial.
>
> If you look at current linux kernels, the 'tricks' above have been marked
> deprecated with no replacement.  Windows has some hard defines and then
> ancient near magic.  I've not looked at Solaris via Open Solaris yet but
> doubt there is a solution at all.
>
> What I'd try since you have the equipment and the monitor software is to
> hardcode the dcb->Baud in termios.c to 1953 (no define) and see what the
> w32 kernel does with it.  I think if you toss a baud rate at the driver it
> will try to come close.  You may try comming closer to a real baudrate
> based upon the 128000 baud base as shown above.
>
> If it works, it is worth looking at the rest of the ping/pong logic then.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
>
>
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From doug at dupreeinc.com  Thu Jun  1 13:22:13 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 12:22:13 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011107210.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
Message-ID: <447F3E65.1020809@dupreeinc.com>

Hello,

I am still trying to get this startup a little faster so I turned on the 
debug of a few of the classes.  The COM ports are scanned really fast 
and the delay occurs during the LPT scan.  The console output looks like 
this:

    ...
      LPT1
      LPT2
      LPT3
     valid port prefixes:
      LPT
    LPT1 LPT
    1 1
    LPT2 LPT
    2 2                                                                 
      * <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
    CommPortIdentifier:addPortName(LPT2)
    CommPortIdentifier:AddIdentifierToList()
    LPT3 LPT
    3 3
    CommPortIdentifier:addPortName(LPT3)
    CommPortIdentifier:AddIdentifierToList()
    CommPortIdentifier:AddIdentifierToList() index.next
    Leaving registerValidPorts()
    Have not implemented native_psmisc_report_owner(PortName)); in
    CommPortIdentifier
    CommPortIdentifier:getPortIdentifier(COM3)
    CommPortIdentifier:open(densConnect, 30000)
    RXTXCommDriver:getCommPort(COM3,1)
    ...

It would seem to me that if I removed the code for port scanning of LPT 
ports I could solve this problem. I would much prefer to use unmodified 
code if at all possible.  Do any of you have alternate suggestions?

Thank you for your time.

Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/cf433ee7/attachment-0006.html

From tjarvi at qbang.org  Thu Jun  1 13:52:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 13:52:06 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F3E65.1020809@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011348380.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I am still trying to get this startup a little faster so I turned on the 
> debug of a few of the classes.  The COM ports are scanned really fast and the 
> delay occurs during the LPT scan.  The console output looks like this:
>
>   ...
>     LPT1
>     LPT2
>     LPT3
>    valid port prefixes:
>     LPT
>   LPT1 LPT
>   1 1
>   LPT2 LPT
>   2 2                                                                      * 
> <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>   CommPortIdentifier:addPortName(LPT2)
>   CommPortIdentifier:AddIdentifierToList()
>   LPT3 LPT
>   3 3
>   CommPortIdentifier:addPortName(LPT3)
>   CommPortIdentifier:AddIdentifierToList()
>   CommPortIdentifier:AddIdentifierToList() index.next
>   Leaving registerValidPorts()
>   Have not implemented native_psmisc_report_owner(PortName)); in
>   CommPortIdentifier
>   CommPortIdentifier:getPortIdentifier(COM3)
>   CommPortIdentifier:open(densConnect, 30000)
>   RXTXCommDriver:getCommPort(COM3,1)
>   ...
>
> It would seem to me that if I removed the code for port scanning of LPT ports 
> I could solve this problem. I would much prefer to use unmodified code if at 
> all possible.  Do any of you have alternate suggestions?
>
> Thank you for your time.
>
> Doug
>


Does commenting out the LPT enumeration actually help?  There can often be 
differences between debug information printed and whats really going on. 
When you combine various environments the debug info can even come out in 
the wrong order.

I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
I do not think this problem is universal.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Thu Jun  1 14:29:44 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:29:44 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4E38.2060004@dupreeinc.com>

I will give it a try.  One thing to note on this PC is it has no LPT 
Parallel ports.

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
>>Hello,
>>
>>I am still trying to get this startup a little faster so I turned on the 
>>debug of a few of the classes.  The COM ports are scanned really fast and the 
>>delay occurs during the LPT scan.  The console output looks like this:
>>
>>  ...
>>    LPT1
>>    LPT2
>>    LPT3
>>   valid port prefixes:
>>    LPT
>>  LPT1 LPT
>>  1 1
>>  LPT2 LPT
>>  2 2                                                                      * 
>><<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>>  CommPortIdentifier:addPortName(LPT2)
>>  CommPortIdentifier:AddIdentifierToList()
>>  LPT3 LPT
>>  3 3
>>  CommPortIdentifier:addPortName(LPT3)
>>  CommPortIdentifier:AddIdentifierToList()
>>  CommPortIdentifier:AddIdentifierToList() index.next
>>  Leaving registerValidPorts()
>>  Have not implemented native_psmisc_report_owner(PortName)); in
>>  CommPortIdentifier
>>  CommPortIdentifier:getPortIdentifier(COM3)
>>  CommPortIdentifier:open(densConnect, 30000)
>>  RXTXCommDriver:getCommPort(COM3,1)
>>  ...
>>
>>It would seem to me that if I removed the code for port scanning of LPT ports 
>>I could solve this problem. I would much prefer to use unmodified code if at 
>>all possible.  Do any of you have alternate suggestions?
>>
>>Thank you for your time.
>>
>>Doug
>>
>>    
>>
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/dd31fed5/attachment-0006.html

From doug at dupreeinc.com  Thu Jun  1 14:36:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:36:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4FC8.9080106@dupreeinc.com>

Trent,

I commented out the section in RegisterScannedPorts() that adds the 
three LPT ports to the CandidateDeviceNames string array.  The 
application started immediately.  This is probably not the way to do 
this, but it was quick ,dirty, and worked.

It would be nice if there was a way to pole the OS to see if there is 
even a port there, though I guess this is what this code is suppose to do...

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
> ...
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From lynn at swcp.com  Thu Jun  1 14:49:34 2006
From: lynn at swcp.com (lynn@swcp.com)
Date: Thu, 1 Jun 2006 20:49:34 -0000
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>,
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <twig.1149194974.97617@swcp.com>

Perhaps we could add an argument to port enumeration where if not specified,
you get the default behavior that looks for everything.  With a new
constructor that has an argument(or more) you could optionally declare it to
not inspect printer ports.

Existing code would work as it always has.  New code could be smarter.

Lynn



Doug Thistlethwaite <doug at dupreeinc.com> said:

> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
> >On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
> >
> >  
> >
> > ...
> >
> >
> >Does commenting out the LPT enumeration actually help?  There can often be 
> >differences between debug information printed and whats really going on. 
> >When you combine various environments the debug info can even come out in 
> >the wrong order.
> >
> >I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
> >I do not think this problem is universal.
> >
> >--
> >Trent Jarvi
> >tjarvi at qbang.org
> >_______________________________________________
> >Rxtx mailing list
> >Rxtx at qbang.org
> >http://mailman.qbang.org/mailman/listinfo/rxtx
> >
> >
> >  
> >
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



-- 





From jredman at ergotech.com  Thu Jun  1 15:20:20 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 01 Jun 2006 15:20:20 -0600
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
Message-ID: <447F5A14.6010803@ergotech.com>

Doug,

If you specifically request ports, eg:

-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

or
 
-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

Depending upon the version  (Windows is COM1:COM2, etc. I assume).

Does it still enumerate the parallel ports?

Jim

Doug Thistlethwaite wrote:
> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
>> On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>
>>  
>>
>> ...
>>
>>
>> Does commenting out the LPT enumeration actually help?  There can often be 
>> differences between debug information printed and whats really going on. 
>> When you combine various environments the debug info can even come out in 
>> the wrong order.
>>
>> I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>> I do not think this problem is universal.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>>
>>  
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  1 16:49:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:49:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6EF4.7080709@dupreeinc.com>

I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
folder.  I created this file and added the following to the file:

gnu.io.rxtx.SerialPorts=COM3

and I get the following error on the console:
CommPortIdentifier:static initialization()
RXTXCommDriver {}
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
RXTXCommDriver:
    Jar version = RXTX-2.1-7
    native lib Version = RXTX-2.1-7
RXTXCommDriver:initialize()
checking for system-known ports of type 1
checking registry for ports of type 1

RXTXCommDriver:addSpecifiedPorts()
Exception in thread "main" java.lang.ExceptionInInitializerError
    at 
densconnect.SerialConnection.openConnection(SerialConnection.java:136)
    at densconnect.DensTalk.<init>(DensTalk.java:165)
    at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
    at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
    at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
    at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
Caused by: java.lang.NullPointerException
    at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
CommPortIdentifier:addPortName(COM3)
CommPortIdentifier:AddIdentifierToList()
CommPortIdentifier:AddIdentifierToList() null
...


It looks like it  read COM3 from the file, but it had the above 
exception that killed it.  The strange this is this error is from 
RXTXCommDriver initialize function (if statement line):

        OS = System.getProperty("os.name");
                System.out.println("OS NAME: " + OS);
        if(OS.toLowerCase().indexOf("linux") == -1)

OS is returning null, thus the error.

If the file is not present, it scans the ports and reads the OS.

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>Doug Thistlethwaite wrote:
>  
>
>>Trent,
>>
>>I commented out the section in RegisterScannedPorts() that adds the 
>>three LPT ports to the CandidateDeviceNames string array.  The 
>>application started immediately.  This is probably not the way to do 
>>this, but it was quick ,dirty, and worked.
>>
>>It would be nice if there was a way to pole the OS to see if there is 
>>even a port there, though I guess this is what this code is suppose to do...
>>
>>Doug
>>
>>Trent Jarvi wrote:
>>
>>    
>>
>>>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>>
>>> 
>>>
>>>...
>>>
>>>
>>>Does commenting out the LPT enumeration actually help?  There can often be 
>>>differences between debug information printed and whats really going on. 
>>>When you combine various environments the debug info can even come out in 
>>>the wrong order.
>>>
>>>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>>>I do not think this problem is universal.
>>>
>>>--
>>>Trent Jarvi
>>>tjarvi at qbang.org
>>>_______________________________________________
>>>Rxtx mailing list
>>>Rxtx at qbang.org
>>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>>
>>>
>>> 
>>>
>>>      
>>>
>>_______________________________________________
>>Rxtx mailing list
>>Rxtx at qbang.org
>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>    
>>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/bf4cca0e/attachment-0006.html

From doug at dupreeinc.com  Thu Jun  1 16:51:26 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:51:26 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6F6E.5060603@dupreeinc.com>

Jim,

I did not try your suggestion as I do not understand where I would put 
these command line parameters (it that is what they are).  It appears 
that using the properties file should do that same thing...

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>
>  
>


From doug at dupreeinc.com  Thu Jun  1 17:56:19 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 16:56:19 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
Message-ID: <447F7EA3.6050400@dupreeinc.com>

I think there is an error in the registerSpecifiedPorts() method.  When 
I have a gnu.io.rxtx.properties file in the ext directory, this function 
kills the System class  IF I call System.getProperty("os.name") before 
the call  to registerSpecifiedPorts(), it returns the os name, after the 
call, it returns null.  I have not played much with properties, except 
for reading them, so I don't really understand the code.

Doug



From doug at dupreeinc.com  Thu Jun  1 18:11:14 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 17:11:14 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F7EA3.6050400@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com>
Message-ID: <447F8222.3060402@dupreeinc.com>

Ok, I just hacked this thing up and got it to read the 
gnu.io.rxtx.properties file.

I commented out the line:
System.setProperties(p); in the method registerSpecifiedPorts() in 
RXTXCommDriver class.  I really don't understand that much about 
properties, but this call kills the System class.

I used the following in the gnu.io.rxtx.properties file:

gnu.io.rxtx.SerialPorts=COM3
gnu.io.rxtx.ParallelPorts=null

This allows the application to open very quickly without any errors.  
Whomever coded this class or somebody who understands properties should 
look at this method and make sure it is doing what they expect.

Doug




Doug Thistlethwaite wrote:

>I think there is an error in the registerSpecifiedPorts() method.  When 
>I have a gnu.io.rxtx.properties file in the ext directory, this function 
>kills the System class  IF I call System.getProperty("os.name") before 
>the call  to registerSpecifiedPorts(), it returns the os name, after the 
>call, it returns null.  I have not played much with properties, except 
>for reading them, so I don't really understand the code.
>
>Doug
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From tjarvi at qbang.org  Thu Jun  1 18:32:50 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 18:32:50 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F6EF4.7080709@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com> <447F6EF4.7080709@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011831510.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
> folder.  I created this file and added the following to the file:
>
> gnu.io.rxtx.SerialPorts=COM3
>
> and I get the following error on the console:
> CommPortIdentifier:static initialization()
> RXTXCommDriver {}
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
> RXTXCommDriver:
>   Jar version = RXTX-2.1-7
>   native lib Version = RXTX-2.1-7
> RXTXCommDriver:initialize()
> checking for system-known ports of type 1
> checking registry for ports of type 1
>
> RXTXCommDriver:addSpecifiedPorts()
> Exception in thread "main" java.lang.ExceptionInInitializerError
>   at densconnect.SerialConnection.openConnection(SerialConnection.java:136)
>   at densconnect.DensTalk.<init>(DensTalk.java:165)
>   at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
>   at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
>   at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
>   at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
> Caused by: java.lang.NullPointerException
>   at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
> CommPortIdentifier:addPortName(COM3)
> CommPortIdentifier:AddIdentifierToList()
> CommPortIdentifier:AddIdentifierToList() null
> ...
>
>

There is a solution for this bug.

http://bugzilla.qbang.org/show_bug.cgi?id=54

We have been horribly slow at getting the next round of patches in but 
they are comming.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  2 00:58:02 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 08:58:02 +0200
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F8222.3060402@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
Message-ID: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>

Hi Doug,

you wrote in an earlier message, that you would prefer an unchanged  
version. What about simply removing the RXTX parallel lib from the  
ext directory. This does not fix the bug, but it should fix your  
problem.

In general I think it is not a good idea to put the RXTX files in a  
system wide location. Putting the libs in the application folder and  
including the .jar in the application classpath (or application jar)  
is all that is required.

Regards,
Joachim

On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:

> Ok, I just hacked this thing up and got it to read the
> gnu.io.rxtx.properties file.
>
> I commented out the line:
> System.setProperties(p); in the method registerSpecifiedPorts() in
> RXTXCommDriver class.  I really don't understand that much about
> properties, but this call kills the System class.
>
> I used the following in the gnu.io.rxtx.properties file:
>
> gnu.io.rxtx.SerialPorts=COM3
> gnu.io.rxtx.ParallelPorts=null
>
> This allows the application to open very quickly without any errors.
> Whomever coded this class or somebody who understands properties  
> should
> look at this method and make sure it is doing what they expect.
>
> Doug
>
>
>
>
> Doug Thistlethwaite wrote:
>
>> I think there is an error in the registerSpecifiedPorts() method.   
>> When
>> I have a gnu.io.rxtx.properties file in the ext directory, this  
>> function
>> kills the System class  IF I call System.getProperty("os.name")  
>> before
>> the call  to registerSpecifiedPorts(), it returns the os name,  
>> after the
>> call, it returns null.  I have not played much with properties,  
>> except
>> for reading them, so I don't really understand the code.
>>
>> 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 antonio.luis at iscte.pt  Fri Jun  2 02:42:28 2006
From: antonio.luis at iscte.pt (=?ISO-8859-1?Q?Ant=F3nio_Lopes?=)
Date: Fri, 02 Jun 2006 09:42:28 +0100
Subject: [Rxtx] Exception when closing serial port
Message-ID: <447FF9F4.7060209@iscte.pt>

Hello everyone,
I've been using RXTX in a Java application in my Pocket PC.
The communication through the (bluetooth) serial port is working perfectly.

However, when I disconnect the app and close the serial port, sometimes I get 
the following error:

"1149237595000: RXTXPort:close detected bad File Descriptor"

The problem is that after this error occurs, the app is no longer able to 
connect to the serial port and I have to soft-reset the device in order to be 
able to connect to it again.

Any ideas on how to solve this issue?

Any help is appreciated.
Thanks,
regards,
-- 
Ant?nio Lopes

@contact: antonio.luis at iscte.pt
@work: ADETTI - ISCTE
@web: http://antonio.lopes.googlepages.com


From paul.klissner at sun.com  Fri Jun  2 02:44:34 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 01:44:34 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to RXTX
	again
Message-ID: <447FFA72.6040807@sun.com>

After looking into javax.comm 3.1 and what it would take to re-engineer it
to be compatible with RXTX platform libraries, I've decided, due my group's
priorities, complexity of the effort vs. benefit, and limited resources, 
to re-post
javax.comm 2.0 binaries on Sun's software download server, unsupported,
with disclaimers, as it was previously.

I don't think there will be any snags doing this from the standpoint of Sun
management or legality.  I will try to have it  posted there in the next 
week
or two, depending on how fast we can get it pushed through the process.

I'd like to think of this as a stop gap measure... ie. a compromise, 
where, at some
point in the not too distant future RXTX implements their own version of the
Java side of the API, as is normally done by javax.extension porters. 
That way
we avoid uncomfortable dependencies in the future.  And that really is 
the Java
development model.

Since RXTX already has the back-end code, porting the java code shouldn't
be a gargantuan effort at all, and RXTX will be in full control of the 
code top
to bottom. I think RXTX can do at least as good a job as the original 
coder.
Prepping 2.0 to be open sourced is more trouble than it is worth. ie. I 
don't
think the current implementation warrants it.

Ultimately, it would be nice to see someone open up a JSR and re-architect
the comm. API to overcome some of it's current design flaws (ie. be more
adaptable to modern platforms, more pluggable, better defined SPI, better
port ownership handling, etc...). A superior architecture would allow for
better collaboration in the future and better interchangeability of 
components
among projects.

Sun's 3.1 version of javax.comm, which is Sun's currently supported version,
has changes pertaining mostly to Sun platform-specific portmapping and has
some minor additional interactions with our back end code, but generally
has little bearing on RXTX. 

Paul



From joachim at buechse.de  Fri Jun  2 04:00:19 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 12:00:19 +0200
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
	RXTX again
In-Reply-To: <447FFA72.6040807@sun.com>
References: <447FFA72.6040807@sun.com>
Message-ID: <1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>

Good day Paul!

A clean architecture with loadable drivers and reusable code would be  
very beneficial for the future, I think everybody agrees. However  
this could be several years into the future. In the meantime, there  
is a real existing problem with IO support on Java. I have the strong  
feeling that most programmers want to code against one specification  
(javax.comm) and be able to replace the underlying implementation via  
a "plugin" on platforms where the SUN implementation is not  
sufficient. RXTX could be just this plugin (reusing very close to 0%  
of the javax.comm implementation but 100% of its API).

I want to propose an API addition and implementation change that will  
take less then 2 hours of manpower to implement and create a solution  
that can bridge the years until javax.comm has been based on a new  
architecture.

Looking at the javax.comm api at http://java.sun.com/products/ 
javacomm/reference/api/index.html I would like to propose the following:

The only entry point to javax.comm is CommPortIdentifier. It has 3  
static methods plus the constructor.

1) define one additional Interface

public interface CommProvider {
    CommPortIdentifier getPortIdentifier(CommPort port);
    CommPortIdentifier getPortIdentifier(String portName);
    Enumeration getPortIdentifiers ();
}

2) add one method to CommPortIdentifier

   public static setCustomCommProvider (CommProvider);

3) change the three static methods of CommPortIdentifier to dispatch  
to the CommProvider if it is set

4) change the constructor of CommPortIdentifier to

   public CommPortIdentifier(...) {
      if (isProviderSet && this.getClass() ==  
javax.comm.CommPortIdentifier) {
          throw new RuntimeException("illegal creation of  
CommPortIndentifier, custom CommProvider is in use");
      }

5) (this is optional, but would be very nice) automatically set a  
custom CommProvider if it is found on the classpath or defined via a  
system property.


The above 1) - 4) can be implemented in less than 1hour. 5) may take  
another hour. I agree that this is not the most elegant design, but  
it would solve a lot of problems with very little effort. It would  
certainly allow RXTX to move forward. If the javax.comm API needs to  
be redesigned completely this addition will not hurt, as people will  
move to the new API anyway and javax.comm 3.0 was so far never  
included in the main distribution.

Best regards,
Joachim

On 02.06.2006, at 10:44, Paul Klissner wrote:

> After looking into javax.comm 3.1 and what it would take to re- 
> engineer it
> to be compatible with RXTX platform libraries, I've decided, due my  
> group's
> priorities, complexity of the effort vs. benefit, and limited  
> resources,
> to re-post
> javax.comm 2.0 binaries on Sun's software download server,  
> unsupported,
> with disclaimers, as it was previously.
>
> I don't think there will be any snags doing this from the  
> standpoint of Sun
> management or legality.  I will try to have it  posted there in the  
> next
> week
> or two, depending on how fast we can get it pushed through the  
> process.
>
> I'd like to think of this as a stop gap measure... ie. a compromise,
> where, at some
> point in the not too distant future RXTX implements their own  
> version of the
> Java side of the API, as is normally done by javax.extension porters.
> That way
> we avoid uncomfortable dependencies in the future.  And that really is
> the Java
> development model.
>
> Since RXTX already has the back-end code, porting the java code  
> shouldn't
> be a gargantuan effort at all, and RXTX will be in full control of the
> code top
> to bottom. I think RXTX can do at least as good a job as the original
> coder.
> Prepping 2.0 to be open sourced is more trouble than it is worth.  
> ie. I
> don't
> think the current implementation warrants it.
>
> Ultimately, it would be nice to see someone open up a JSR and re- 
> architect
> the comm. API to overcome some of it's current design flaws (ie. be  
> more
> adaptable to modern platforms, more pluggable, better defined SPI,  
> better
> port ownership handling, etc...). A superior architecture would  
> allow for
> better collaboration in the future and better interchangeability of
> components
> among projects.
>
> Sun's 3.1 version of javax.comm, which is Sun's currently supported  
> version,
> has changes pertaining mostly to Sun platform-specific portmapping  
> and has
> some minor additional interactions with our back end code, but  
> generally
> has little bearing on RXTX.
>
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Fri Jun  2 09:10:13 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Fri, 2 Jun 2006 09:10:13 -0600 (MDT)
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <447FFA72.6040807@sun.com>
References: <447FFA72.6040807@sun.com>
Message-ID: <Pine.LNX.4.61.0606020906400.15971@www>

On Fri, 2 Jun 2006, Paul Klissner wrote:

> After looking into javax.comm 3.1 and what it would take to re-engineer it
> to be compatible with RXTX platform libraries, I've decided, due my group's
> priorities, complexity of the effort vs. benefit, and limited resources,
> to re-post
> javax.comm 2.0 binaries on Sun's software download server, unsupported,
> with disclaimers, as it was previously.
>

Hi Paul

To address users' immediate needs, we can release rxtx 2.0-7 (final) to 
match the 2.0 binaries from Sun when they are offered for download.

We can discuss potential long term solutions after that.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Fri Jun  2 10:20:09 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 02 Jun 2006 09:20:09 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
	<9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
Message-ID: <44806539.8080902@dupreeinc.com>

Thanks for the suggestion, I will give it a try.

Doug

Joachim Buechse wrote:

>Hi Doug,
>
>you wrote in an earlier message, that you would prefer an unchanged  
>version. What about simply removing the RXTX parallel lib from the  
>ext directory. This does not fix the bug, but it should fix your  
>problem.
>
>In general I think it is not a good idea to put the RXTX files in a  
>system wide location. Putting the libs in the application folder and  
>including the .jar in the application classpath (or application jar)  
>is all that is required.
>
>Regards,
>Joachim
>
>On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:
>
>  
>
>>Ok, I just hacked this thing up and got it to read the
>>gnu.io.rxtx.properties file.
>>
>>I commented out the line:
>>System.setProperties(p); in the method registerSpecifiedPorts() in
>>RXTXCommDriver class.  I really don't understand that much about
>>properties, but this call kills the System class.
>>
>>I used the following in the gnu.io.rxtx.properties file:
>>
>>gnu.io.rxtx.SerialPorts=COM3
>>gnu.io.rxtx.ParallelPorts=null
>>
>>This allows the application to open very quickly without any errors.
>>Whomever coded this class or somebody who understands properties  
>>should
>>look at this method and make sure it is doing what they expect.
>>
>>Doug
>>
>>
>>
>>
>>Doug Thistlethwaite wrote:
>>
>>    
>>
>>>I think there is an error in the registerSpecifiedPorts() method.   
>>>When
>>>I have a gnu.io.rxtx.properties file in the ext directory, this  
>>>function
>>>kills the System class  IF I call System.getProperty("os.name")  
>>>before
>>>the call  to registerSpecifiedPorts(), it returns the os name,  
>>>after the
>>>call, it returns null.  I have not played much with properties,  
>>>except
>>>for reading them, so I don't really understand the code.
>>>
>>>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
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060602/c8892a46/attachment-0006.html

From paul.klissner at sun.com  Fri Jun  2 12:09:26 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 11:09:26 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
Message-ID: <44807ED6.8000903@sun.com>

Joachim Buechse wrote:
> Good day Paul!
>
> A clean architecture with loadable drivers and reusable code would be  
> very beneficial for the future, I think everybody agrees. However  
> this could be several years into the future. In the meantime, there  
> is a real existing problem with IO support on Java. I have the strong  
> feeling that most programmers want to code against one specification  
> (javax.comm) and be able to replace the underlying implementation via  
> a "plugin" on platforms where the SUN implementation is not  
> sufficient. RXTX could be just this plugin (reusing very close to 0%  
> of the javax.comm implementation but 100% of its API).
>
> I want to propose an API addition and implementation change that will  
> take less then 2 hours of manpower to implement and create a solution  
> that can bridge the years until javax.comm has been based on a new  
> architecture.
>
> Looking at the javax.comm api at http://java.sun.com/products/ 
> javacomm/reference/api/index.html I would like to propose the following:
>
> The only entry point to javax.comm is CommPortIdentifier. It has 3  
> static methods plus the constructor.
>
> 1) define one additional Interface
>
> public interface CommProvider {
>     CommPortIdentifier getPortIdentifier(CommPort port);
>     CommPortIdentifier getPortIdentifier(String portName);
>     Enumeration getPortIdentifiers ();
> }
>
> 2) add one method to CommPortIdentifier
>
>    public static setCustomCommProvider (CommProvider);
>
> 3) change the three static methods of CommPortIdentifier to dispatch  
> to the CommProvider if it is set
>
> 4) change the constructor of CommPortIdentifier to
>
>    public CommPortIdentifier(...) {
>       if (isProviderSet && this.getClass() ==  
> javax.comm.CommPortIdentifier) {
>           throw new RuntimeException("illegal creation of  
> CommPortIndentifier, custom CommProvider is in use");
>       }
>
> 5) (this is optional, but would be very nice) automatically set a  
> custom CommProvider if it is found on the classpath or defined via a  
> system property.
>
>
> The above 1) - 4) can be implemented in less than 1hour. 5) may take  
> another hour. I agree that this is not the most elegant design, but  
> it would solve a lot of problems with very little effort. It would  
> certainly allow RXTX to move forward. If the javax.comm API needs to  
> be redesigned completely this addition will not hurt, as people will  
> move to the new API anyway and javax.comm 3.0 was so far never  
> included in the main distribution.
>
> Best regards,
> Joachi
I'm afraid modifying the interface classes isn't my call.  There was 
actually
a TCK written and one of the tests was to ensure that the interface classes
match the spec.  Thus my hands have already been tied since this project
was essentially grandfathered into the JCP.

That's why we need to open a new JSR and find someone who wants
to be the spec lead, and go in with a new reference implementation.
I'm not sure why it would have to take years, since this isn't bleeding edge
technology and there are only so many things that can be done with it,
and we already have practical experience about many functional aspects
that we could cite precedence on.

As it becomes clear that the specification is being accepted completely
or by-and-large by the community, nothing would stop people from
starting adapting to the new API (using the reference implementation or
porting it) and using it in their projects prior to it's final community and
JCP approval, since approval is required only to make it official and
get the "100% pure java" certification for platform ports.

You have one idea already.  Why don't you implement it, solicit some
design feedback from Sun and the RXTX, and create a functional
implementation that addresses the needs of the community, then
we can document it and open a JSR.  That's it.  It should march through
the approval stages reasonably quickly I would imagine, and meantime
RXTX could start using it.

Paul




From doug at dupreeinc.com  Fri Jun  2 12:45:01 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 02 Jun 2006 11:45:01 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
	<9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
Message-ID: <4480872D.6000605@dupreeinc.com>

Joachim,

Thank you for the suggestion.  I restored the jar file to the one I 
downloaded, moved the dll files into the project directory, and added 
the jar to the classpath.  The SerialDemo program that was included with 
the Sun commapi started in 12 seconds instead of the 58 seconds when the 
parallel dll is present.  I did get the startup time to about a second 
by modifying the java code and adding the properties file but this is 
probably not a good idea.

Doug

Joachim Buechse wrote:

>Hi Doug,
>
>you wrote in an earlier message, that you would prefer an unchanged  
>version. What about simply removing the RXTX parallel lib from the  
>ext directory. This does not fix the bug, but it should fix your  
>problem.
>
>In general I think it is not a good idea to put the RXTX files in a  
>system wide location. Putting the libs in the application folder and  
>including the .jar in the application classpath (or application jar)  
>is all that is required.
>
>Regards,
>Joachim
>
>On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:
>
>  
>
>>Ok, I just hacked this thing up and got it to read the
>>gnu.io.rxtx.properties file.
>>
>>I commented out the line:
>>System.setProperties(p); in the method registerSpecifiedPorts() in
>>RXTXCommDriver class.  I really don't understand that much about
>>properties, but this call kills the System class.
>>
>>I used the following in the gnu.io.rxtx.properties file:
>>
>>gnu.io.rxtx.SerialPorts=COM3
>>gnu.io.rxtx.ParallelPorts=null
>>
>>This allows the application to open very quickly without any errors.
>>Whomever coded this class or somebody who understands properties  
>>should
>>look at this method and make sure it is doing what they expect.
>>
>>Doug
>>
>>
>>
>>
>>Doug Thistlethwaite wrote:
>>
>>    
>>
>>>I think there is an error in the registerSpecifiedPorts() method.   
>>>When
>>>I have a gnu.io.rxtx.properties file in the ext directory, this  
>>>function
>>>kills the System class  IF I call System.getProperty("os.name")  
>>>before
>>>the call  to registerSpecifiedPorts(), it returns the os name,  
>>>after the
>>>call, it returns null.  I have not played much with properties,  
>>>except
>>>for reading them, so I don't really understand the code.
>>>
>>>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
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060602/3c0e420f/attachment-0006.html

From joachim at buechse.de  Fri Jun  2 13:46:36 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 21:46:36 +0200
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
	RXTX again
In-Reply-To: <44807ED6.8000903@sun.com>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
	<44807ED6.8000903@sun.com>
Message-ID: <6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>

Hello Paul,

of course, the basic change I suggested could be done "hidden".  The  
CommProvider interface could live somewhere in sun.xyz.*
The setCustomCommProvider method would not be in CommPortIdentifier  
but also somewhere in sun.xyz.* This would be an unofficial feature,  
the official interface stays exactly the same. However RXTX (and  
others) could access the hidden interface.

Don't get me wrong, I don't want to harass you into making changes  
you don't like (which probably wouldn't work anyway;-). But I'm a  
long time Java programmer and seeing the state of cross platform  
serial support for Java makes me feel really sad. In fact, when I  
started to look into Java serial port programming some months ago I  
was very surprised that javax.comm never made it into the JDK.

I'm sorry that I did not contribute my feedback to the JSR for  
javax.comm 3.0. However at the time I didn't do serial port  
programming in Java. I agree that a new JSR should be opened - I'm  
not an expert on JSRs or the JCP process, but from looking quickly  
over the progress of some JSRs I would be very surprised if we can  
have a new version in less then a year. In the meanwhile some people  
will start using javax.comm 3.0 (which can not be supported by RXTX),  
some will use javax.comm 2.0 (which means the 2.0.7 release of RXTX  
still needs to be maintained). This may get even worse if eg Apple  
decides to port and include javax.comm 3.0 at which point it may get  
very tricky to write a cross platform Java application.

All of this simply means, that we are loosing a lot of man-power that  
could otherwise be invested in building a clean solution and/or to  
add features that are becoming more and more important (USB events...).

In the automation / machine control universe Java makes a lot of  
sense. Right now many people are migrating to Linux or from  
propietary systems (even DOS) to Windows. Writing the control/ 
configuration applications in Java is the kings way to unify the code  
base.

Best regards,
Joachim


On 02.06.2006, at 20:09, Paul Klissner wrote:

> Joachim Buechse wrote:
>> Good day Paul!
>>
>> A clean architecture with loadable drivers and reusable code would be
>> very beneficial for the future, I think everybody agrees. However
>> this could be several years into the future. In the meantime, there
>> is a real existing problem with IO support on Java. I have the strong
>> feeling that most programmers want to code against one specification
>> (javax.comm) and be able to replace the underlying implementation via
>> a "plugin" on platforms where the SUN implementation is not
>> sufficient. RXTX could be just this plugin (reusing very close to 0%
>> of the javax.comm implementation but 100% of its API).
>>
>> I want to propose an API addition and implementation change that will
>> take less then 2 hours of manpower to implement and create a solution
>> that can bridge the years until javax.comm has been based on a new
>> architecture.
>>
>> Looking at the javax.comm api at http://java.sun.com/products/
>> javacomm/reference/api/index.html I would like to propose the  
>> following:
>>
>> The only entry point to javax.comm is CommPortIdentifier. It has 3
>> static methods plus the constructor.
>>
>> 1) define one additional Interface
>>
>> public interface CommProvider {
>>     CommPortIdentifier getPortIdentifier(CommPort port);
>>     CommPortIdentifier getPortIdentifier(String portName);
>>     Enumeration getPortIdentifiers ();
>> }
>>
>> 2) add one method to CommPortIdentifier
>>
>>    public static setCustomCommProvider (CommProvider);
>>
>> 3) change the three static methods of CommPortIdentifier to dispatch
>> to the CommProvider if it is set
>>
>> 4) change the constructor of CommPortIdentifier to
>>
>>    public CommPortIdentifier(...) {
>>       if (isProviderSet && this.getClass() ==
>> javax.comm.CommPortIdentifier) {
>>           throw new RuntimeException("illegal creation of
>> CommPortIndentifier, custom CommProvider is in use");
>>       }
>>
>> 5) (this is optional, but would be very nice) automatically set a
>> custom CommProvider if it is found on the classpath or defined via a
>> system property.
>>
>>
>> The above 1) - 4) can be implemented in less than 1hour. 5) may take
>> another hour. I agree that this is not the most elegant design, but
>> it would solve a lot of problems with very little effort. It would
>> certainly allow RXTX to move forward. If the javax.comm API needs to
>> be redesigned completely this addition will not hurt, as people will
>> move to the new API anyway and javax.comm 3.0 was so far never
>> included in the main distribution.
>>
>> Best regards,
>> Joachi
> I'm afraid modifying the interface classes isn't my call.  There was
> actually
> a TCK written and one of the tests was to ensure that the interface  
> classes
> match the spec.  Thus my hands have already been tied since this  
> project
> was essentially grandfathered into the JCP.
>
> That's why we need to open a new JSR and find someone who wants
> to be the spec lead, and go in with a new reference implementation.
> I'm not sure why it would have to take years, since this isn't  
> bleeding edge
> technology and there are only so many things that can be done with it,
> and we already have practical experience about many functional aspects
> that we could cite precedence on.
>
> As it becomes clear that the specification is being accepted  
> completely
> or by-and-large by the community, nothing would stop people from
> starting adapting to the new API (using the reference  
> implementation or
> porting it) and using it in their projects prior to it's final  
> community and
> JCP approval, since approval is required only to make it official and
> get the "100% pure java" certification for platform ports.
>
> You have one idea already.  Why don't you implement it, solicit some
> design feedback from Sun and the RXTX, and create a functional
> implementation that addresses the needs of the community, then
> we can document it and open a JSR.  That's it.  It should march  
> through
> the approval stages reasonably quickly I would imagine, and meantime
> RXTX could start using it.
>
> Paul
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From paul.klissner at sun.com  Fri Jun  2 14:38:49 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 13:38:49 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
	<44807ED6.8000903@sun.com>
	<6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>
Message-ID: <4480A1D9.5060106@sun.com>

Joachim Buechse wrote:
> Hello Paul,
>
> of course, the basic change I suggested could be done "hidden".  The  
> CommProvider interface could live somewhere in sun.xyz.*
> The setCustomCommProvider method would not be in CommPortIdentifier  
> but also somewhere in sun.xyz.* This would be an unofficial feature,  
> the official interface stays exactly the same. However RXTX (and  
> others) could access the hidden interface.
>
> Don't get me wrong, I don't want to harass you into making changes  
> you don't like (which probably wouldn't work anyway;-). But I'm a  
> long time Java programmer and seeing the state of cross platform  
> serial support for Java makes me feel really sad. In fact, when I  
> started to look into Java serial port programming some months ago I  
> was very surprised that javax.comm never made it into the JDK.
>
> I'm sorry that I did not contribute my feedback to the JSR for  
> javax.comm 3.0. 
There was no JSR for 3.0, because we didn't have the resources to make 
the commitment.
Yet Sun needed to add support for platform-dependent port name mapping, 
which had to
be done 'under the hood', since the API isn't designed to handle that in 
a pluggable way.
But these quick fixes aren't the right approach, they just kick the dog 
down the road,
setting bad precedent, inviting confusion and more intractable problems 
(such as the
one plaguing us now).

My changes could have been layered better, it was a trade off between 
achieving an
ideal architecture, trying to find internal reviewers, and meet the 
needs of big customers
in a timely way.  Thus my namespace changes collided with RXTX's 
dependencies.
I was unaware of Jagane's rogue agreement made with the RXTX community 7 
years ago,
before Jagane left Sun.  I think this was a wag-the-dog situation.

Now it is time to do it right, and I don't think it is going to be as 
much trouble as people
some people fear. If RXTX wants to sponsor the JSR and seed a new spec, 
Sun can join
the Expert Group.  And we'd be largely in agreement, since we're not 
talking about
humongous changes, and looking for mutually beneficial changes. The core 
API is already
largely proved and tested.
> However at the time I didn't do serial port  
> programming in Java. I agree that a new JSR should be opened - I'm  
> not an expert on JSRs or the JCP process, but from looking quickly  
> over the progress of some JSRs I would be very surprised if we can  
> have a new version in less then a year. 
*Approved*  But that doesn't mean the spec couldn't be 99.9% stable 
before that.  Once
the delta rate declines and changes approach nil, people could start 
adapting to the API in
advance of formal approval.   It isn't going to be drawn out like 
javax.usb, which was new
technology, a very complex API, and involved precedent setting corporate 
disputes and
policy issues to resolve.

> In the meanwhile some people  
> will start using javax.comm 3.0 (which can not be supported by RXTX),  
> some will use javax.comm 2.0 (which means the 2.0.7 release of RXTX  
> still needs to be maintained). This may get even worse if eg Apple  
> decides to port and include javax.comm 3.0 at which point it may get  
> very tricky to write a cross platform Java application.
>   
The interfaces haven't changed since 1.0.  If we open a JSR ,we can 
contact Apple and
allow them to be on the E.G., if they want.  That might make the JSR a 
bit more drawn out,
but then we'd arrive ultimately arrive at a best-of-all-worlds API that 
most people would
accept, perhaps forever, and arrive at a respectable set of compromises.

-Paul

> All of this simply means, that we are loosing a lot of man-power that  
> could otherwise be invested in building a clean solution and/or to  
> add features that are becoming more and more important (USB events...).
>
> In the automation / machine control universe Java makes a lot of  
> sense. Right now many people are migrating to Linux or from  
> propietary systems (even DOS) to Windows. Writing the control/ 
> configuration applications in Java is the kings way to unify the code  
> base.
>
> Best regards,
> Joachim
>
>
> On 02.06.2006, at 20:09, Paul Klissner wrote:
>
>   
>> Joachim Buechse wrote:
>>     
>>> Good day Paul!
>>>
>>> A clean architecture with loadable drivers and reusable code would be
>>> very beneficial for the future, I think everybody agrees. However
>>> this could be several years into the future. In the meantime, there
>>> is a real existing problem with IO support on Java. I have the strong
>>> feeling that most programmers want to code against one specification
>>> (javax.comm) and be able to replace the underlying implementation via
>>> a "plugin" on platforms where the SUN implementation is not
>>> sufficient. RXTX could be just this plugin (reusing very close to 0%
>>> of the javax.comm implementation but 100% of its API).
>>>
>>> I want to propose an API addition and implementation change that will
>>> take less then 2 hours of manpower to implement and create a solution
>>> that can bridge the years until javax.comm has been based on a new
>>> architecture.
>>>
>>> Looking at the javax.comm api at http://java.sun.com/products/
>>> javacomm/reference/api/index.html I would like to propose the  
>>> following:
>>>
>>> The only entry point to javax.comm is CommPortIdentifier. It has 3
>>> static methods plus the constructor.
>>>
>>> 1) define one additional Interface
>>>
>>> public interface CommProvider {
>>>     CommPortIdentifier getPortIdentifier(CommPort port);
>>>     CommPortIdentifier getPortIdentifier(String portName);
>>>     Enumeration getPortIdentifiers ();
>>> }
>>>
>>> 2) add one method to CommPortIdentifier
>>>
>>>    public static setCustomCommProvider (CommProvider);
>>>
>>> 3) change the three static methods of CommPortIdentifier to dispatch
>>> to the CommProvider if it is set
>>>
>>> 4) change the constructor of CommPortIdentifier to
>>>
>>>    public CommPortIdentifier(...) {
>>>       if (isProviderSet && this.getClass() ==
>>> javax.comm.CommPortIdentifier) {
>>>           throw new RuntimeException("illegal creation of
>>> CommPortIndentifier, custom CommProvider is in use");
>>>       }
>>>
>>> 5) (this is optional, but would be very nice) automatically set a
>>> custom CommProvider if it is found on the classpath or defined via a
>>> system property.
>>>
>>>
>>> The above 1) - 4) can be implemented in less than 1hour. 5) may take
>>> another hour. I agree that this is not the most elegant design, but
>>> it would solve a lot of problems with very little effort. It would
>>> certainly allow RXTX to move forward. If the javax.comm API needs to
>>> be redesigned completely this addition will not hurt, as people will
>>> move to the new API anyway and javax.comm 3.0 was so far never
>>> included in the main distribution.
>>>
>>> Best regards,
>>> Joachi
>>>       
>> I'm afraid modifying the interface classes isn't my call.  There was
>> actually
>> a TCK written and one of the tests was to ensure that the interface  
>> classes
>> match the spec.  Thus my hands have already been tied since this  
>> project
>> was essentially grandfathered into the JCP.
>>
>> That's why we need to open a new JSR and find someone who wants
>> to be the spec lead, and go in with a new reference implementation.
>> I'm not sure why it would have to take years, since this isn't  
>> bleeding edge
>> technology and there are only so many things that can be done with it,
>> and we already have practical experience about many functional aspects
>> that we could cite precedence on.
>>
>> As it becomes clear that the specification is being accepted  
>> completely
>> or by-and-large by the community, nothing would stop people from
>> starting adapting to the new API (using the reference  
>> implementation or
>> porting it) and using it in their projects prior to it's final  
>> community and
>> JCP approval, since approval is required only to make it official and
>> get the "100% pure java" certification for platform ports.
>>
>> You have one idea already.  Why don't you implement it, solicit some
>> design feedback from Sun and the RXTX, and create a functional
>> implementation that addresses the needs of the community, then
>> we can document it and open a JSR.  That's it.  It should march  
>> through
>> the approval stages reasonably quickly I would imagine, and meantime
>> RXTX could start using it.
>>
>> Paul
>>
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at 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  Sat Jun  3 18:15:24 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 18:15:24 -0600 (MDT)
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
Message-ID: <Pine.LNX.4.61.0606031715100.10890@www>


The attached patch allows baud rates of 14400, 28800, 128000 and 256000.

That was my goal.

[import standard disclaimer]

But I took some time to look a little further.  I got custom baud rates 
working enough that someone (perhaps me) can properly fix them in the 
future.  Proof of concept.

As an undocumented bonus, you can toss random baudrates (say 1953), at the 
API and it will set it to something close to that on windows and linux. 
Solaris should say the baud rate is not supported but I have not tested it 
yet.  Mac OS X behavior is unknown at this point.  Just dont expect 
correct behavior at ~8192-9009 baudrates or baudrates less than 20 on 
windows; these baud rates overlap with defines in win32termios.h.  I 
conveniently closed my eyes there.  Try another value close.  On Linux, a 
baud base and divisor are guestimated and set.  On windows, we wave pixie 
dust over the kernel driver and hope.  Do not expect pixie dust and 
guestimates to be the same on windows and linux.  They may well round to 
different values in yet to be tested ways.  There are only so many 
divisors.  If it isn't working, try a little higher or lower.

In the example of 1953 for instance, there is no divisor for commodity 
hardware that comes to that baudrate.  We just come close on one side or 
the other.  If tools tell you they got 1953 exactly, the tools may be 
questionable and just reading values not directly related to the actual 
hardware settings.

These fixes have been tested on Linux and Windows while using an 
oscilloscope to confirm they change relative to known baudrates at 9600, 
14400*, 19200, 28800* (and 1800, 1953** and 2400).

* = previously unsupported.
** = still not supported but probably works from what I saw.

There could be future discussion in this area.  For now this is working 
for almost all unusual baud rate demands.  Cleaning up the custom baud 
rate should be easier with a working starting point.  Baud bases other 
than 128000 have not been characterized.  Yes.. this overlapps with two of 
the baud rates enabled.

Feedback and ideas are welcome.

--
Trent Jarvi
tjarvi at qbang.org
-------------- next part --------------
Index: SerialImp.c
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v
retrieving revision 1.46.2.187
diff -u -r1.46.2.187 SerialImp.c
--- SerialImp.c	29 Jan 2006 22:19:04 -0000	1.46.2.187
+++ SerialImp.c	3 Jun 2006 23:12:40 -0000
@@ -793,6 +793,19 @@
 		result &= ~TIOCM_DTR;
 		ioctl( fd, TIOCMSET, &result );
 	}
+	/*
+	   B38400 is a special case in Linux for custom baud rates.
+
+	   We just treat this as a custom speed for now.  If you take this ifdef
+	   out and select baud rates 38400 then 28800 then 38400, you will get
+	   a final baud rate of 28800 because you did not update the divisor.
+
+	   See the next ifdef below for the divisor.
+	*/
+#if defined(TIOCGSERIAL)
+	if ( cspeed == B38400 )
+		cspeed = 38400;
+#endif /* TIOCGSERIAL */
 	if(     cfsetispeed( &ttyset, cspeed ) < 0 ||
 		cfsetospeed( &ttyset, cspeed ) < 0 )
 	{
@@ -814,6 +827,7 @@
 		*/
 
 #if defined(TIOCGSERIAL)
+		ioctl( fd, TIOCGSERIAL, &sstruct );
 		sstruct.custom_divisor = ( sstruct.baud_base/cspeed );
 		cspeed = B38400;
 #endif /* TIOCGSERIAL */
@@ -827,7 +841,7 @@
 #if defined(TIOCSSERIAL)
 		/*  It is assumed Win32 does this for us */
 		if (	sstruct.baud_base < 1 ||
-			ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
+		ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
 		{
 			return( 1 );
 		}
Index: termios.c
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v
retrieving revision 1.9.2.56
diff -u -r1.9.2.56 termios.c
--- termios.c	16 Jan 2006 02:50:32 -0000	1.9.2.56
+++ termios.c	3 Jun 2006 23:12:40 -0000
@@ -323,8 +323,8 @@
 		case CBR_3500000:	return( B3500000 );
 		case CBR_4000000:	return( B4000000 );
 		default:
-			set_errno(EINVAL );
-			return -1;
+			/* assume custom baudrate */
+			return( Baud );
 	}
 }
 
@@ -361,12 +361,13 @@
 		case B9600:	ret = CBR_9600;		break;
 		case B14400:	ret = CBR_14400;	break;
 		case B19200:	ret = CBR_19200;	break;
+		case B28800:	ret = CBR_28800;	break;
 		case B38400:	ret = CBR_38400;	break;
 		case B57600:	ret = CBR_57600;	break;
 		case B115200:	ret = CBR_115200;	break;
 		case B128000:	ret = CBR_128000;	break;
-		case B256000: 	ret = CBR_256000;	break;
 		case B230400:	ret = CBR_230400;	break;
+		case B256000: 	ret = CBR_256000;	break;
 		case B460800:	ret = CBR_460800;	break;
 		case B500000:	ret = CBR_500000;	break;
 		case B576000:	ret = CBR_576000;	break;
@@ -381,10 +382,8 @@
 		case B4000000:	ret = CBR_4000000;	break;
 	
 		default:
-			fprintf( stderr, "B_to_CBR: invalid baudrate: %#o\n",
-				Baud );
-			set_errno( EINVAL );
-			return -1;
+			/* assume custom baudrate */
+			return Baud;
 	}
 	LEAVE( "B_to_CBR" );
 	return ret;
@@ -708,12 +707,9 @@
 	ENTER( "init_serial_struct" );
 
 	/*
-	FIXME
-
-	This needs to use inb() to read the actual baud_base
-	and divisor from the UART registers.  Question is how
-	far do we take this?
-
+	use of custom_divisor and baud_base requires access to
+	kernel space.  The kernel does try its best if you just
+	toss a baud rate at it though.
 	*/
 
 	sstruct->custom_divisor = 0;
@@ -1678,16 +1674,17 @@
 {
 	char message[80];
 	ENTER( "cfsetospeed" );
+	/* clear baudrate */
+	s_termios->c_cflag &= ~CBAUD;
 	if ( speed & ~CBAUD )
 	{
 		sprintf( message, "cfsetospeed: not speed: %#o\n", speed );
 		report( message );
-		return 0;
+		/* continue assuming its a custom baudrate */
+		s_termios->c_cflag |= B38400;  /* use 38400 during custom */
+		s_termios->c_cflag |= CBAUDEX; /* use CBAUDEX for custom */
 	}
-	s_termios->c_ispeed = s_termios->c_ospeed = speed;
-	/* clear baudrate */
-	s_termios->c_cflag &= ~CBAUD;
-	if( speed )
+	else if( speed )
 	{
 		s_termios->c_cflag |= speed;
 	}
@@ -1696,6 +1693,7 @@
 		/* PC blows up with speed 0 handled in Java */
 		s_termios->c_cflag |= B9600;
 	}
+	s_termios->c_ispeed = s_termios->c_ospeed = speed;
 	LEAVE( "cfsetospeed" );
 	return 1;
 }
@@ -1767,25 +1765,6 @@
 }
 
 /*----------------------------------------------------------
-serial_struct_to_DCB()
-
-   accept:      
-   perform:     
-   return:      
-   exceptions:  
-   win32api:     None
-   comments:    
-----------------------------------------------------------*/
-int serial_struct_to_DCB( struct serial_struct *sstruct, DCB *dcb )
-{
-	/* 5 Baud rate fix
-	sstruct.baud_base
-	sstruct.custom_divisor = ( sstruct.baud_base/cspeed );
-	*/
-	return(0);
-}
-
-/*----------------------------------------------------------
 termios_to_DCB()
 
    accept:      
@@ -1798,7 +1777,8 @@
 int termios_to_DCB( struct termios *s_termios, DCB *dcb )
 {
 	ENTER( "termios_to_DCB" );
-	s_termios->c_ispeed = s_termios->c_ospeed = s_termios->c_cflag & CBAUD;
+	if ( !(s_termios->c_cflag & CBAUDEX) )
+		s_termios->c_ispeed = s_termios->c_ospeed = s_termios->c_cflag & CBAUD;
 	dcb->BaudRate        = B_to_CBR( s_termios->c_ispeed );
 	dcb->ByteSize = termios_to_bytesize( s_termios->c_cflag );
 
@@ -2863,11 +2843,6 @@
 			GetCommState( index->hComm, dcb );
 
 			index->sstruct = va_arg( ap, struct serial_struct * );
-			if ( serial_struct_to_DCB( index->sstruct, dcb ) < 0 )
-			{
-				va_end( ap );
-				return -1;
-			}
 
 			report( "TIOCSSERIAL\n" );
 			free(dcb);
Index: win32termios.h
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v
retrieving revision 1.5.2.28
diff -u -r1.5.2.28 win32termios.h
--- win32termios.h	30 Jun 2005 20:23:26 -0000	1.5.2.28
+++ win32termios.h	3 Jun 2006 23:12:40 -0000
@@ -279,7 +279,7 @@
 #define XTABS	01000000 /* Hmm.. Linux/i386 considers this part of TABDLY.. */
 
 /* c_cflag bit meaning */
-# define CBAUD	0010017
+#define  CBAUD  0030017
 #define  B0	0000000		/* hang up */
 #define  B50	0000001
 #define  B75	0000002
@@ -312,13 +312,16 @@
 #define  B3500000 0010016
 #define  B4000000 0010017
 
-/* glue for unsupported linux speeds see also SerialImp.h */
-/* hosed */
-
-#define B14400		1010001
-#define B28800		1010002
-#define B128000		1010003
-#define B256000		1010004
+/*
+	glue for unsupported linux speeds see also SerialImp.h 
+	custom baud rates around 8192-9000 will not work because
+	of these.
+*/
+
+#define B14400		0020001
+#define B28800		0020002
+#define B128000		0020003
+#define B256000		0020004
 
 #define EXTA B19200
 #define EXTB B38400
@@ -356,8 +359,10 @@
 
 /* glue for unsupported windows speeds */
 
-#define CBR_230400	230400
 #define CBR_28800	28800
+#define CBR_128000	128000
+#define CBR_230400	230400
+#define CBR_256000	256000
 #define CBR_460800	460800
 #define CBR_500000	500000
 #define CBR_576000	576000

From impakt01 at optusnet.com.au  Sat Jun  3 18:30:37 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 10:30:37 +1000
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
In-Reply-To: <Pine.LNX.4.61.0606031715100.10890@www>
Message-ID: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>

Hi Trent,
I'd love to try the patch but I can't get the latest build compiling, only
pre16. 

Can you attach the rxtxSerial.dll file with this patch?

Also, I hardcoded 1953 in a couple more places last night on pre16 and it
managed to open the port at the right speed, but stopped receiving anything
after 100-150 bytes, even though more data was getting sent to the port.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 10:15 AM
To: rxtx at qbang.org
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.


The attached patch allows baud rates of 14400, 28800, 128000 and 256000.

That was my goal.

[import standard disclaimer]

But I took some time to look a little further.  I got custom baud rates 
working enough that someone (perhaps me) can properly fix them in the 
future.  Proof of concept.

As an undocumented bonus, you can toss random baudrates (say 1953), at the 
API and it will set it to something close to that on windows and linux. 
Solaris should say the baud rate is not supported but I have not tested it 
yet.  Mac OS X behavior is unknown at this point.  Just dont expect 
correct behavior at ~8192-9009 baudrates or baudrates less than 20 on 
windows; these baud rates overlap with defines in win32termios.h.  I 
conveniently closed my eyes there.  Try another value close.  On Linux, a 
baud base and divisor are guestimated and set.  On windows, we wave pixie 
dust over the kernel driver and hope.  Do not expect pixie dust and 
guestimates to be the same on windows and linux.  They may well round to 
different values in yet to be tested ways.  There are only so many 
divisors.  If it isn't working, try a little higher or lower.

In the example of 1953 for instance, there is no divisor for commodity 
hardware that comes to that baudrate.  We just come close on one side or 
the other.  If tools tell you they got 1953 exactly, the tools may be 
questionable and just reading values not directly related to the actual 
hardware settings.

These fixes have been tested on Linux and Windows while using an 
oscilloscope to confirm they change relative to known baudrates at 9600, 
14400*, 19200, 28800* (and 1800, 1953** and 2400).

* = previously unsupported.
** = still not supported but probably works from what I saw.

There could be future discussion in this area.  For now this is working 
for almost all unusual baud rate demands.  Cleaning up the custom baud 
rate should be easier with a working starting point.  Baud bases other 
than 128000 have not been characterized.  Yes.. this overlapps with two of 
the baud rates enabled.

Feedback and ideas are welcome.

--
Trent Jarvi
tjarvi at qbang.org



From tjarvi at qbang.org  Sat Jun  3 19:05:11 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 19:05:11 -0600 (MDT)
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
In-Reply-To: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>
References: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606031840400.10890@www>

On Sun, 4 Jun 2006, Daren wrote:

> Hi Trent,
> I'd love to try the patch but I can't get the latest build compiling, only
> pre16.
>
> Can you attach the rxtxSerial.dll file with this patch?
>
> Also, I hardcoded 1953 in a couple more places last night on pre16 and it
> managed to open the port at the right speed, but stopped receiving anything
> after 100-150 bytes, even though more data was getting sent to the port.
>


ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing

I dont think they will hang.  But I was just testing via loopback/break 
out box/scope.

I'll be putting about 10 patches and another set of binaries in that 
directory shortly.  For now the binaries should just have the baud_rate 
fix.

I'll announce all the patches at once.  but wont be releasing 2.1-8 right 
away.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Sat Jun  3 21:00:01 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 21:00:01 -0600 (MDT)
Subject: [Rxtx] CVS for 2.1 should have everything
Message-ID: <Pine.LNX.4.61.0606032056190.10890@www>


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org


From impakt01 at optusnet.com.au  Sat Jun  3 21:08:14 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 13:08:14 +1000
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <Pine.LNX.4.61.0606032056190.10890@www>
Message-ID: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>

Hi Trent,
I tried the latest dll and it opens the port, receives 100-200 bytes and
then stops receiving anything else..

I'll keep playing with it.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 1:00 PM
To: rxtx at qbang.org
Subject: [Rxtx] CVS for 2.1 should have everything


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From impakt01 at optusnet.com.au  Sat Jun  3 21:22:41 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 13:22:41 +1000
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
Message-ID: <200606040322.k543MqW1008455@mail12.syd.optusnet.com.au>

Played with it, problem, with a while loop in my code, working great now

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Daren
Sent: Sunday, 4 June 2006 1:08 PM
To: 'RXTX Developers and Users'
Subject: Re: [Rxtx] CVS for 2.1 should have everything

Hi Trent,
I tried the latest dll and it opens the port, receives 100-200 bytes and
then stops receiving anything else..

I'll keep playing with it.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 1:00 PM
To: rxtx at qbang.org
Subject: [Rxtx] CVS for 2.1 should have everything


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Sat Jun  3 21:35:41 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 21:35:41 -0600 (MDT)
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
References: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606032131140.10890@www>

On Sun, 4 Jun 2006, Daren wrote:

> Hi Trent,
> I tried the latest dll and it opens the port, receives 100-200 bytes and
> then stops receiving anything else..
>
> I'll keep playing with it.
>
> Daren

The difference may be that I'm talking to something at the exact same baud 
rate (loopback).

You may also try setting the baudrate to ~1933 and ~1973 to force the 
guesses one way or the other.  If you are on windows, we are not doing 
anything fancy in the end.  Thats the kernel guessing.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sun Jun  4 04:12:09 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sun, 4 Jun 2006 12:12:09 +0200
Subject: [Rxtx] Update of OSX installer, Readme, etc
Message-ID: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>

Good day,

after the latest changes a lot of OS X specific files should be  
updated. Especially the installer!

- The "MaxOSX" readme file on the root level is outdated (ie  
CodeWarrior information). Maybe we could even rename it to README.OSX  
to be in line with README.IPAQ, README.SCO (Trent do you mind copying/ 
renaming ,v files in the repository?).

- The lock files are no longer used and hence the user group magic  
and lock folder creation should be removed from the installer.

- MACOSX_IDE/ForPackageMaker/Resources/ReadMe.rtf and Welcome.rtf  
need to be updated.

- I suggest to replace the current installation instruction for OS X:  
Installation should occur into the application directory, not in the  
Java-VM directory. This simplifies things a lot, as the Mac Installer  
can be removed completely.

- The xcodeproject's build settings need to be updated to generate  
JAVA 1.1 format class files.


Dimitry: do you have time to tackle this? I could do it, but as this  
is "your baby" I thought you may prefer to do it yourself.

Regards,
Joachim



From dmarkman at mac.com  Sun Jun  4 11:27:53 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Sun, 4 Jun 2006 13:27:53 -0400
Subject: [Rxtx] Update of OSX installer, Readme, etc
In-Reply-To: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
References: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
Message-ID: <26E7A202-962B-4C19-93B6-29426C467249@mac.com>

Joachim,
unfortunately I don't have time right now to do that
so if you can do that, please do

it's not only my baby
it's yours too :-)

thanks


On Jun 4, 2006, at 6:12 AM, Joachim Buechse wrote:

> Good day,
>
> after the latest changes a lot of OS X specific files should be
> updated. Especially the installer!
>
> - The "MaxOSX" readme file on the root level is outdated (ie
> CodeWarrior information). Maybe we could even rename it to README.OSX
> to be in line with README.IPAQ, README.SCO (Trent do you mind copying/
> renaming ,v files in the repository?).
>
> - The lock files are no longer used and hence the user group magic
> and lock folder creation should be removed from the installer.
>
> - MACOSX_IDE/ForPackageMaker/Resources/ReadMe.rtf and Welcome.rtf
> need to be updated.
>
> - I suggest to replace the current installation instruction for OS X:
> Installation should occur into the application directory, not in the
> Java-VM directory. This simplifies things a lot, as the Mac Installer
> can be removed completely.
>
> - The xcodeproject's build settings need to be updated to generate
> JAVA 1.1 format class files.
>
>
> Dimitry: do you have time to tackle this? I could do it, but as this
> is "your baby" I thought you may prefer to do it yourself.
>
> Regards,
> Joachim
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman



From tjarvi at qbang.org  Sun Jun  4 13:54:02 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 4 Jun 2006 13:54:02 -0600 (MDT)
Subject: [Rxtx] Update of OSX installer, Readme, etc
In-Reply-To: <26E7A202-962B-4C19-93B6-29426C467249@mac.com>
References: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
	<26E7A202-962B-4C19-93B6-29426C467249@mac.com>
Message-ID: <Pine.LNX.4.61.0606041353040.22522@www>

On Sun, 4 Jun 2006, Dmitry Markman wrote:

> Joachim,
> unfortunately I don't have time right now to do that
> so if you can do that, please do
>
> it's not only my baby
> it's yours too :-)
>

I've given Joachim cvs access.  He has shown good work in bugzilla.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Mon Jun  5 10:08:32 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 5 Jun 2006 18:08:32 +0200
Subject: [Rxtx] Build process changes for Mac OS X
Message-ID: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>

Good day,

I have cleaned up some outdated Mac OSX specific build files in the  
repository.

There was not a lot left of the readme file "MacOSX" after cleaning  
it up, so I decided to rename it README.OSX to be in harmony with the  
other files in the directory (ie README.IPAQ, README.SCO, ...)

I added an (uncompressed) XCode 2.3 project file/structure  
with .cvsignore files that will ignore the user specific settings.  
This should work "out of the box" for OSX10.4. Users of 10.2/10.3 may  
have to switch the build settings.

[It's kind of tricky to choose "the right" setting. Afaik there is no  
way to compile a universal binary that will work on 10.3 or before.  
So it's either UniversalBinary OR Legacy. Maybe we should have  
different build targets for these different targets?? I would like to  
get some feedback from the Mac developers on this list regarding the  
subject].

Besides other things the OSX installer is no longer required. Since  
the next version (2.1.8) will no longer use lockfiles on OSX, the  
group/permission magic is no longer required and hence there remains  
basicly no work for the installer - other than copying 2 files to the  
VM extension directory. Then again, this is not the best way to  
install RXTX. So I removed the installer completely without modifying  
it, this should simplify a "resurrection" should it ever get necessary.

I had problems with the (compressed, ie sit.hqx) legacy project files  
on the latest installation of OSX (javac 1.5 creating non JDK1.1  
class files and some minor problems). To reduce potential confusion  
for newcomers I decided to remove them. This means that there is no  
longer a simple way to build RXTX for OSX 10.0 and 10.1 (I deeply  
apologize if anyone still relied on this ... well the files are in  
the Attiq).

Best regards,
Joachim


From joachim at buechse.de  Mon Jun  5 10:16:37 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 5 Jun 2006 18:16:37 +0200
Subject: [Rxtx] RXTX and lockfiles on OSX [it is fixed now]
Message-ID: <7D2C4418-9397-4B59-8091-9FDE4ED67836@buechse.de>

Quite a number of people contacted me in the last couple of weeks  
because of problems installing RXTX on OSX. I told you to wait for  
the "official" fix. Well, it has been fixed.

So if you were among the people waiting for the solution, you can now  
download the source rxtx-2.1-7r2.zip from the website. Once unpacked  
dont forget to use "cvs up" to update the files to the latest  
version. You can then open MACOSX_IDE/XCode/ 
LibSerialUniversal.xcodeproj with XCode 2.3 and build the libraries  
that no longer try to create lock files.

Regards,
Joachim


From brian at mbari.org  Mon Jun  5 10:52:43 2006
From: brian at mbari.org (Brian Schlining)
Date: Mon, 5 Jun 2006 09:52:43 -0700
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
Message-ID: <78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>

Hi Joachim,

> [It's kind of tricky to choose "the right" setting. Afaik there is no
> way to compile a universal binary that will work on 10.3 or before.
> So it's either UniversalBinary OR Legacy. Maybe we should have
> different build targets for these different targets?? I would like to
> get some feedback from the Mac developers on this list regarding the
> subject].

I imagine most developers will be compiling on 10.4 (It's the nature  
of the coder...gotta have the latest and greatest) and deploying to  
both 10.3 and 10.4; both of which will run Universal Binaries (see  
http://forums.macrumors.com/showthread.php?t=205348). So it sounds  
like you've covered the majority of users. Still, you know someone's  
going to pipe up about needing RXTX on 10.2 so it would be nice to  
have a target to make a PPC only build.

Just my 2 cents

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/1cac8c39/attachment-0006.html

From dmarkman at mac.com  Mon Jun  5 13:47:50 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Mon, 5 Jun 2006 15:47:50 -0400
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
Message-ID: <686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>

I don't think it will be a problem to run universal binary
on 10.2
however if binary has some calls that aren't implemented in 10.2
then you'll have a problem


On Jun 5, 2006, at 12:52 PM, Brian Schlining wrote:

> Hi Joachim,
>
>> [It's kind of tricky to choose "the right" setting. Afaik there is no
>> way to compile a universal binary that will work on 10.3 or before.
>> So it's either UniversalBinary OR Legacy. Maybe we should have
>> different build targets for these different targets?? I would like to
>> get some feedback from the Mac developers on this list regarding the
>> subject].
>
> I imagine most developers will be compiling on 10.4 (It's the  
> nature of the coder...gotta have the latest and greatest) and  
> deploying to both 10.3 and 10.4; both of which will run Universal  
> Binaries (see http://forums.macrumors.com/showthread.php?t=205348).  
> So it sounds like you've covered the majority of users. Still, you  
> know someone's going to pipe up about needing RXTX on 10.2 so it  
> would be nice to have a target to make a PPC only build.
>
> Just my 2 cents
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/9fafc878/attachment-0006.html

From brian at mbari.org  Mon Jun  5 14:52:41 2006
From: brian at mbari.org (Brian Schlining)
Date: Mon, 5 Jun 2006 13:52:41 -0700
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
Message-ID: <E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>

Hi Dmitry,

> I don't think it will be a problem to run universal binary
> on 10.2
> however if binary has some calls that aren't implemented in 10.2
> then you'll have a problem

You're right...I stand corrected.

Note however, to deploy a universal binary to 10.2 RXTX will need to  
use the 10.2 SDK to build the PPC side. (see http:// 
developer.apple.com/documentation/DeveloperTools/Conceptual/ 
cross_development/UniversalBinaries/chapter_4_section_1.html). I  
haven't been paying close attention to the new locking mechanism used  
by RXTX on the Mac...does 10.2 support it?

Joachim, which SDK will you be using by default for building the Mac  
PPC binaries?

>> Hi Joachim,
>>
>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>> is no
>>> way to compile a universal binary that will work on 10.3 or before.
>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>> different build targets for these different targets?? I would  
>>> like to
>>> get some feedback from the Mac developers on this list regarding the
>>> subject].
>>
>> I imagine most developers will be compiling on 10.4 (It's the  
>> nature of the coder...gotta have the latest and greatest) and  
>> deploying to both 10.3 and 10.4; both of which will run Universal  
>> Binaries (see http://forums.macrumors.com/showthread.php? 
>> t=205348). So it sounds like you've covered the majority of users.  
>> Still, you know someone's going to pipe up about needing RXTX on  
>> 10.2 so it would be nice to have a target to make a PPC only build.

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/153bf50e/attachment-0006.html

From dmarkman at mac.com  Mon Jun  5 19:02:04 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Mon, 5 Jun 2006 21:02:04 -0400
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
Message-ID: <7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>

if Joachim didn't change xcode project setting

/Developer/SDKs/MacOSX10.4u.sdk is used to build universal binary

so it's quite possible that it won't run properly on 10.2

so we have to change the building process, so ppc part will be built
with
/Developer/SDKs/MacOSX10.2.8.sdk

and finally to use lipo utility to build universal binaries

Joachim, did you use some specific locking API that wasn't implemented

in MacOSX10.2.8.sdk?

thanks


On Jun 5, 2006, at 4:52 PM, Brian Schlining wrote:

> Hi Dmitry,
>
>> I don't think it will be a problem to run universal binary
>> on 10.2
>> however if binary has some calls that aren't implemented in 10.2
>> then you'll have a problem
>
> You're right...I stand corrected.
>
> Note however, to deploy a universal binary to 10.2 RXTX will need  
> to use the 10.2 SDK to build the PPC side. (see http:// 
> developer.apple.com/documentation/DeveloperTools/Conceptual/ 
> cross_development/UniversalBinaries/chapter_4_section_1.html). I  
> haven't been paying close attention to the new locking mechanism  
> used by RXTX on the Mac...does 10.2 support it?
>
> Joachim, which SDK will you be using by default for building the  
> Mac PPC binaries?
>
>>> Hi Joachim,
>>>
>>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>>> is no
>>>> way to compile a universal binary that will work on 10.3 or before.
>>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>>> different build targets for these different targets?? I would  
>>>> like to
>>>> get some feedback from the Mac developers on this list regarding  
>>>> the
>>>> subject].
>>>
>>> I imagine most developers will be compiling on 10.4 (It's the  
>>> nature of the coder...gotta have the latest and greatest) and  
>>> deploying to both 10.3 and 10.4; both of which will run Universal  
>>> Binaries (see http://forums.macrumors.com/showthread.php? 
>>> t=205348). So it sounds like you've covered the majority of  
>>> users. Still, you know someone's going to pipe up about needing  
>>> RXTX on 10.2 so it would be nice to have a target to make a PPC  
>>> only build.
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/84790f80/attachment-0006.html

From joachim at buechse.de  Tue Jun  6 02:40:47 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 6 Jun 2006 10:40:47 +0200
Subject: [Rxtx] Building on OS X, Impl Changes
In-Reply-To: <7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
Message-ID: <CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>

Good day!

What's in the XCode project setting?
----------

The xcode project remained pretty much the same as before. I excluded  
the user specific files from CVS and changed some settings. I kept  
all the built targets (you shouldn't change what you don't understand;-)

Currently we the following build targets:
    RXTXComm (java files)
    librxtxParallel.jnilib (usefull on the Mac???)
    libI2C.jnilib (not yet working in RXTX)
    libRS485.jnilib (not yet working in RXTX)
    librxtxSerial.jnilib (1)
    librxtxSerial.jnilib Dynamic (2)
    rxtxSerial (3)
We also have the following build configurations for each target:
    Development
    Default
    Deployment

What was changed in the xcode project from previous versions:
- java.souce=1.3 and java.target=1.1 in RXTXComm settings
- removed copying of build products into installer directory
- removed "(Upgraded)" from build target names

What remains to be changed:
- choosing a "non-debug" Build-configuration as default
- potentially removing "Default"/"Development" Build-configurations
- reducing the number of build targets
- creating 10.2 compatible universal binaries

I suggest, that the build configurations should be reduced to 2  
(Debug/Deployment), possibly even 1 (Debug).
I have not yet found the deeper meaning of the build targets(1)(2) 
(3), it seems to me like they should be reduced into one "doing the  
right thing" or maybe into two "rxtxSerial.jnilib Legacy" (back to  
10.2, universal if possible) and "rxtxSerial.jnilib 10.4 
+" (universal, 10.4+).

Should the code work on 10.2?
----------

Absolutely. The code should work on NextStep, in fact on any BSD  
unix. I would go as far as saying, this code should work on any  
POSSIX based unix. All that was added is the call "ioctl(fd,  
TIOCEXCL)" to request excusivity of the port:

http://gemma.apple.com/documentation/DeviceDrivers/Conceptual/ 
WorkingWSerial/WWSerial_SerialDevs/chapter_2_section_8.html

It is not yet "the perfect solution". Normally an open /dev/tty  
(listen for incomming connection) should be "preemptable" by opening  
a /dev/cu (outgoing connection) for the same port. This is not yet  
implemented as it needs calls outside of POSSIX on OSX.

On "classic" systems (like NextStep) this worked based on the  
"carried detect line". open() on /dev/tty.xxx would block until the  
carrier detect signal was raised. As the device was not "opened"  
opening /dev/cu.xxx worked without a hitch. When they ported to the  
Mac this broke. On Macs the "carier detect" is usually not wired.  
Furthermore FAX modems did no longer raise the line. So the OSX  
implementor defined a new call, which is documented here:

http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00045.html

Best regards,
Joachim




On 06.06.2006, at 03:02, Dmitry Markman wrote:

> if Joachim didn't change xcode project setting
>
> /Developer/SDKs/MacOSX10.4u.sdk is used to build universal binary
>
> so it's quite possible that it won't run properly on 10.2
>
> so we have to change the building process, so ppc part will be built
> with
> /Developer/SDKs/MacOSX10.2.8.sdk
>
> and finally to use lipo utility to build universal binaries
>
> Joachim, did you use some specific locking API that wasn't implemented
>
> in MacOSX10.2.8.sdk?
>
> thanks
>
>
> On Jun 5, 2006, at 4:52 PM, Brian Schlining wrote:
>
>> Hi Dmitry,
>>
>>> I don't think it will be a problem to run universal binary
>>> on 10.2
>>> however if binary has some calls that aren't implemented in 10.2
>>> then you'll have a problem
>>
>> You're right...I stand corrected.
>>
>> Note however, to deploy a universal binary to 10.2 RXTX will need  
>> to use the 10.2 SDK to build the PPC side. (see http:// 
>> developer.apple.com/documentation/DeveloperTools/Conceptual/ 
>> cross_development/UniversalBinaries/chapter_4_section_1.html). I  
>> haven't been paying close attention to the new locking mechanism  
>> used by RXTX on the Mac...does 10.2 support it?
>>
>> Joachim, which SDK will you be using by default for building the  
>> Mac PPC binaries?
>>
>>>> Hi Joachim,
>>>>
>>>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>>>> is no
>>>>> way to compile a universal binary that will work on 10.3 or  
>>>>> before.
>>>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>>>> different build targets for these different targets?? I would  
>>>>> like to
>>>>> get some feedback from the Mac developers on this list  
>>>>> regarding the
>>>>> subject].
>>>>
>>>> I imagine most developers will be compiling on 10.4 (It's the  
>>>> nature of the coder...gotta have the latest and greatest) and  
>>>> deploying to both 10.3 and 10.4; both of which will run  
>>>> Universal Binaries (see http://forums.macrumors.com/ 
>>>> showthread.php?t=205348). So it sounds like you've covered the  
>>>> majority of users. Still, you know someone's going to pipe up  
>>>> about needing RXTX on 10.2 so it would be nice to have a target  
>>>> to make a PPC only build.
>>
>> Brian Schlining
>> Software Engineer
>> http://www.mbari.org
>>
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> Dmitry Markman
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Tue Jun  6 07:01:06 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 6 Jun 2006 15:01:06 +0200
Subject: [Rxtx] Serial port code for OS X, future steps
In-Reply-To: <CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
	<CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
Message-ID: <8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>

I posted the "wrong link". There is a correction here:

    http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00059.html

In fact, the 2.1.7 implementation of RXTX has quite some deficiencies  
on OSX. I have tried to supply some patches that don't interfere to  
much with the existing RXTX code base, but there are limits to what  
can be done with local patches.

There are some very intrusive changes that should be done. Ie proper  
mapping of /dev/tty <-> /dev/cu handling to correct behaviour of  
CommPortOwnershipListener (http://java.sun.com/products/javacomm/ 
reference/api/index.html). I dont think this can be done with  
patches. Hence I think, RXTX should be rewritten from scratch de- 
unifying the native code base (and implementing thread safe code on  
the Java side).


How "should" /dev/tty vs /dev/cu be implemented?

=====
The Unix contract is this: An open /dev/tty.xxx port (incomming)  
should be interrupted/auto-closed when opening /dev/cu.xxx (outgoing)  
[if /dev/tty.xxx is not currently handling a communication].  /dev/ 
cu.xxx and /dev/tty.xxx refer to the same device, so owning  
"exclusively" should block both. This should be respected across all  
applications native or Java.

This contract is realizable on OSX with the existing javax.comm  
interface while also respecting (to the biggest part) the contract  
defined by javax.comm.PortOwnershipListener.

The one point where the suggested implementation "breaks" the  
javax.comm contract, is by the fact that one can loose a /dev/tty  
port without calling close. However, the only option I see is to  
always open serial ports "non-exclusively" which would outrule Java  
as a platform for (dormant) applications waiting for incoming  
connections/faxes/etc. There could be a system property to choose the  
intended behavior.
=====

Here is how it could be done on OSX:

Calling port=ComportIdentifier.open("/dev/cu.xxx") opens and owns the  
port exclusively until port.close() is called.
- Java applications listening with a PortOwnershipListener should get  
a PORT_OWNED event reasonably soon.
- Any further attempt by a Java or native application to open "/dev/ 
cu.xxx" or "/dev/tty.xxx" fails.
- /dev/cu.xxx is for "outgoing" connections, so receiving  
PORT_OWNERSHIP_REQUESTED makes little to no sense. With native  
applications it can not be implemented. For Java applications it  
could be implemented (by a hidden communication channel). I think  
it's not worth bothering. If anyone is willing to give up a port to  
others he should use /dev/tty.xxx instead of /dev/cu.xxx.

Registering a PortOwnershipListener on "/dev/cu.xxx" without opening  
it, uses /dev/tty.xxx (native open()) non-exclusively and polls its  
state. PORT_OWNED and PORT_UNOWNED can be produced.

Calling port=ComportIdentifier.open("/dev/tty.xxx") should open the  
port non-exclusively.
- Adding a SerialPortEventListener and reading from the port could be  
allowed while keeping it non-exclusive.
- When port.getOutputStream() is called, the state should be changed  
to an "exclusive" ownership. This may be configurable via a system  
property.
- To return to the non-exclusive state the port must be closed and  
reopened.
- While non-exclusively opened, opening the corresponding /dev/cu.xxx  
produces a PORT_OWNERSHIP_REQUESTED event. Which should be responded  
by closing the port from within the callback (as described in  
java.comm.PortOwnershipListener). If there is a pending read, it will  
return after the listener finishes (with -1 or "0 bytes read").
- Calling write() on the /dev/tty.xxx after somebody opened /dev/ 
cu.xxx will fail with a descriptive IOException.
- Calling read() on the /dev/tty.xxx after somebody opened /dev/ 
cu.xxx will fail with a descriptive IOException (or potentially  
block, see side notes below).

CommPortIdentifier.getCurrentOwner() can be implemented by an  
external call to lsof.

CommPortIdentifier.isCurrentlyOwned() can be implemented by trying an  
open on the /dev/tty.
- It returns true if the port is currently held "exclusively".
- Whether it should also return true on /dev/tty if /dev/tty is  
already opened non-exclusively might be a system property option. In  
general, having several applications waiting for incoming connections  
on the same port will require an application level "arbitration"  
protocol...

[[side note1: One interesting question is, what happens if the  
process holding /dev/tty non-exclusively ignores  
PORT_OWNERSHIP_REQUESTED. Ie after "loosing" a non-exclusively opened  
"dev/tty.xxx" port to another process. One possible implementation  
is, that the port is "regained" when the other process gives up the  
port. This would mean that in the meanwhile read() returns no data,  
and any changes to the configuration of the port are stored but not  
forwarded. I guess, the safe (and simple) way to do this is to make  
the close() mandatory (ie setting the port into an "awaiting_close"  
state which produces IOExceptions to any other call than close). ]]

[[side note2:  Another interesting question is, what should happen if  
several applications open the same /dev/tty.xxx port "non- 
exclusively" and start to change the settings of the device.]]

Regards,
Joachim



On 06.06.2006, at 10:40, Joachim Buechse wrote:

> Should the code work on 10.2?
> ----------
>
> Absolutely. The code should work on NextStep, in fact on any BSD
> unix. I would go as far as saying, this code should work on any
> POSSIX based unix. All that was added is the call "ioctl(fd,
> TIOCEXCL)" to request excusivity of the port:
>
> http://gemma.apple.com/documentation/DeviceDrivers/Conceptual/
> WorkingWSerial/WWSerial_SerialDevs/chapter_2_section_8.html
>
> It is not yet "the perfect solution". Normally an open /dev/tty
> (listen for incomming connection) should be "preemptable" by opening
> a /dev/cu (outgoing connection) for the same port. This is not yet
> implemented as it needs calls outside of POSSIX on OSX.
>
> On "classic" systems (like NextStep) this worked based on the
> "carried detect line". open() on /dev/tty.xxx would block until the
> carrier detect signal was raised. As the device was not "opened"
> opening /dev/cu.xxx worked without a hitch. When they ported to the
> Mac this broke. On Macs the "carier detect" is usually not wired.
> Furthermore FAX modems did no longer raise the line. So the OSX
> implementor defined a new call, which is documented here:
>
> http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00045.html
>
> Best regards,
> Joachim



From sds at dcs.gla.ac.uk  Tue Jun  6 11:22:45 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Tue, 06 Jun 2006 18:22:45 +0100
Subject: [Rxtx] Correct compile flag for HP iPAQ hx4700 running Familiar
	Linux?
Message-ID: <1149614565.19496.10.camel@addu>

Hi,

I'd like to use RXTX 2.1 on my HP iPAQ hx4700. The iPAQ is running
Familiar Linux 0.8.2 (as I recall), with Blackdown Java 1.3.1.

I can compile and run a test program which uses RXTX on my i686 machine,
and it works fine. But I can't seem to get things working quite right on
my PDA.

I compile the code on the laptop with the following commands:
	./configure --host=arm-gnu-linux && make
... as suggested in a post to this list, albeit some time ago. This
compiles, I transfer the files, set up LD_LIBRARY_PATH and CLASSPATH
variables, and get the following error on the PDA:

sds at ipaq-pxa-2:~# java Test
java.lang.UnsatisfiedLinkError: /usr/local/lib/ext/librxtxSerial.so: /usr/local/lib/ext/librxtxSerial.so: cannot open shared object file: No such file or directory thrown while loading gnu.io.RXTXCommDriver
Exception in thread "main"
java.lang.UnsatisfiedLinkError: /usr/local/lib/ext/librxtxSerial.so: /usr/local/lib/ext/librxtxSerial.so: cannot open shared object file: No such file or directory
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1382)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1290)
        at java.lang.Runtime.loadLibrary0(Runtime.java:749)
        at java.lang.System.loadLibrary(System.java:820)
        at
gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:83)
        at Test.<init>(Test.java:9)
        at Test.main(Test.java:32)
sds at ipaq-pxa-2:~# 

Note that I'm copying the files to /usr/local/lib/ext/ along with the
RXTXcomm.jar file, purely to keep things separate from the rest of the
system while testing. The location of the .so files doesn't seem to have
any bearing on whether "java Test" will succeed or not. The contents of
this directory are:

sds at ipaq-pxa-2:~$ ls /usr/local/lib/ext/
RXTXcomm.jar              librxtxParallel-2.1-7.so  librxtxRS485.so
librxtxSerial-2.1-7.so
librxtxI2C-2.1-7.so       librxtxParallel.so        librxtxRaw-2.1-7.so
librxtxSerial.so
librxtxI2C.so             librxtxRS485-2.1-7.so     librxtxRaw.so
sds at ipaq-pxa-2:~$

Test.java fails on the first real line of code I'm using to test that
things are working, prior to real development, and was carefully pinched
from the web:
Enumeration portIdentifiers = CommPortIdentifier.getPortIdentifiers();


I assume that I've gotten my --host flag wrong way back up there at
the ./configure step. But if that's the case, what should I set it to?
Or am I missing something more obvious?


Cheers,
Stephen Strowes,
University of Glasgow.




From tjarvi at qbang.org  Tue Jun  6 13:39:41 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 6 Jun 2006 13:39:41 -0600 (MDT)
Subject: [Rxtx] Serial port code for OS X, future steps
In-Reply-To: <8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
	<CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
	<8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>
Message-ID: <Pine.LNX.4.61.0606061315070.9856@www>


>>
There are some very intrusive changes that should be done. Ie proper
mapping of /dev/tty <-> /dev/cu handling to correct behaviour of
CommPortOwnershipListener (http://java.sun.com/products/javacomm/
reference/api/index.html). I dont think this can be done with
patches. Hence I think, RXTX should be rewritten from scratch de-
unifying the native code base (and implementing thread safe code on
the Java side).
<<

This appears to be a very small amount of functionality for a total 
rewrite.  The port ownership only needs maybe 3 native calls if it is done 
with native calls at all.

Those features which are not part of the Unix standard(s) can be special 
cased.  I'm not sure /dev/cu is standard.  We can look.  I know linux 
deprecated /dev/cua years ago.

Thread safe Java code is not a platform specific issue.

--
Trent Jarvi
tjarvi at qbang.org


From sds at dcs.gla.ac.uk  Wed Jun  7 12:36:43 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Wed, 07 Jun 2006 19:36:43 +0100
Subject: [Rxtx] Expected RXTX behaviour?
In-Reply-To: <1149703900.30891.19.camel@addu>
References: <1149703900.30891.19.camel@addu>
Message-ID: <1149705403.30891.25.camel@addu>

Apologies, caught the problem. Had to append '\r' to the end of the AT
string. A non obvious but stupid mistake... :-)

Final quick question though: How might I stop the echoing of
outputStream data back into the inputStream? I still see the ATI
commands on the inputStream, along with the output from the device.


Cheers,
S.



On Wed, 2006-06-07 at 19:11 +0100, Stephen Strowes wrote:
> Hi,
> 
> I managed to get RXTX to compile for my iPAQ following my previous post
> to this list. Quick query though:
> 
> I want to be able to issue AT commands to a device, and interpret the
> responses. For this, I assume I do the following, in psuedo-form:
> 
> 	CommPortIdentifier.getPortIdentifiers();
> 	// find the correct device id
> 	serialPort= (SerialPort)portID.open("Test");
> 	// Set parameters and flow control
> 	outputStream= serialPort.getOutputStream();
> 	inputStream=  serialPort.getInputStream();
> 
> ... following this, I spawn a thread to respond to DATA_AVAILABLE events
> on serialPort with inputStream, and occasionally write and flush an
> "ATI" onto the outputStream. Nothing complex, I just want to see it
> work.
> 
> I would have expected inputStream to give the same information back from
> an "ATI" command as minicom provides, but instead inputStream only sees
> the "ATI" I put onto the outputStream.
> 
> Have I missed something?
> 
> 
> Cheers,
> S.
> 



From sds at dcs.gla.ac.uk  Wed Jun  7 12:11:40 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Wed, 07 Jun 2006 19:11:40 +0100
Subject: [Rxtx] Expected RXTX behaviour?
Message-ID: <1149703900.30891.19.camel@addu>

Hi,

I managed to get RXTX to compile for my iPAQ following my previous post
to this list. Quick query though:

I want to be able to issue AT commands to a device, and interpret the
responses. For this, I assume I do the following, in psuedo-form:

	CommPortIdentifier.getPortIdentifiers();
	// find the correct device id
	serialPort= (SerialPort)portID.open("Test");
	// Set parameters and flow control
	outputStream= serialPort.getOutputStream();
	inputStream=  serialPort.getInputStream();

... following this, I spawn a thread to respond to DATA_AVAILABLE events
on serialPort with inputStream, and occasionally write and flush an
"ATI" onto the outputStream. Nothing complex, I just want to see it
work.

I would have expected inputStream to give the same information back from
an "ATI" command as minicom provides, but instead inputStream only sees
the "ATI" I put onto the outputStream.

Have I missed something?


Cheers,
S.




From joachim at buechse.de  Wed Jun  7 09:02:13 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 7 Jun 2006 17:02:13 +0200
Subject: [Rxtx] Update of build process for OSX (XCode project)
Message-ID: <62EC47B1-46BD-4ECA-B9EC-C4061D147CDA@buechse.de>

With the help of Dmitry Markman and Brian Schilling I have updated  
(and largely simplifed) the XCode project file for Mac OS X.

Changes:
- compiles a universal binary library with intel=OSX10.4+, ppc=OSX10.2 
+ support
- compiles the Java sources into a JRE1.1 compatible, compressed jar.

Please test on your configuration, especially if you have computers  
running 10.2/10.3 or intel.

Best regards,
Joachim


From joachim at buechse.de  Wed Jun  7 14:36:37 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 7 Jun 2006 22:36:37 +0200
Subject: [Rxtx] Expected RXTX behaviour?
In-Reply-To: <1149705403.30891.25.camel@addu>
References: <1149703900.30891.19.camel@addu> <1149705403.30891.25.camel@addu>
Message-ID: <D3AD6EAF-27BB-455E-9697-86C1121920C3@buechse.de>

Echoing is a feature of the modem. Try ATE0 which works with most  
"rockwell" compatible modems.

Regards,
Joachim


On 07.06.2006, at 20:36, Stephen Strowes wrote:

> Apologies, caught the problem. Had to append '\r' to the end of the AT
> string. A non obvious but stupid mistake... :-)
>
> Final quick question though: How might I stop the echoing of
> outputStream data back into the inputStream? I still see the ATI
> commands on the inputStream, along with the output from the device.
>
>
> Cheers,
> S.
>
>
>
> On Wed, 2006-06-07 at 19:11 +0100, Stephen Strowes wrote:
>> Hi,
>>
>> I managed to get RXTX to compile for my iPAQ following my previous  
>> post
>> to this list. Quick query though:
>>
>> I want to be able to issue AT commands to a device, and interpret the
>> responses. For this, I assume I do the following, in psuedo-form:
>>
>> 	CommPortIdentifier.getPortIdentifiers();
>> 	// find the correct device id
>> 	serialPort= (SerialPort)portID.open("Test");
>> 	// Set parameters and flow control
>> 	outputStream= serialPort.getOutputStream();
>> 	inputStream=  serialPort.getInputStream();
>>
>> ... following this, I spawn a thread to respond to DATA_AVAILABLE  
>> events
>> on serialPort with inputStream, and occasionally write and flush an
>> "ATI" onto the outputStream. Nothing complex, I just want to see it
>> work.
>>
>> I would have expected inputStream to give the same information  
>> back from
>> an "ATI" command as minicom provides, but instead inputStream only  
>> sees
>> the "ATI" I put onto the outputStream.
>>
>> Have I missed something?
>>
>>
>> Cheers,
>> S.
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From g_petrini at yahoo.it  Thu Jun  8 01:41:58 2006
From: g_petrini at yahoo.it (Giacomo Petrini)
Date: Thu, 8 Jun 2006 09:41:58 +0200 (CEST)
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from FieldTalk
Message-ID: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>

Hi,
I'm evaluating the library for the modbus protocol
from FieldTalk
(http://www.modbusdriver.com/fieldtalk/.
I'm using J2SE 5.0 and RXTX 2.1 on win XP.
The problem is that the modbus lib has a method (the
openProtocol method, but maybe there are others) tha
throws the
javax.comm.UnsupportedCommOperationException.
Now, in RXTX 2.1 the namespace has changed in gnu.io,
so the modbus library doesn't work anymore (it look
for things in javax.comm). I've already sent an email
to fieldtalk to see if they are aware of the problem.
The solution should be to use JavaComm + RXTX 2.0. But
I've read somewhere that JavaComm 2.0 does not work
with Java 5.0 and JavaComm 3.0 does not work with RXTX
2.0 so I don't know what to do.

Any ideas?

Thanks Jack

PS: can you make a CC to my personal email
(g_petrini at yahoo.it) too please?

Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 


From rxtx at tapastda.co.uk  Thu Jun  8 02:27:57 2006
From: rxtx at tapastda.co.uk (rxtx@tapastda.co.uk)
Date: Thu, 08 Jun 2006 09:27:57 +0100
Subject: [Rxtx] Win XP and Infrared based serial port
Message-ID: <4487DF8D.5050807@tapastda.co.uk>

I'm attempting to use RXTX 2.1.7 on Win XP with J2SE 5.0 to communicate with a
GSM mobile using a COM port. A peculiarity that I've seen is that whilst I can
communicate successfully with a mobile which uses an infrared based COM port
using the SUN provided javax.comm (v2.0) I cannot use RXTX because it fails to
read anything from the port (i.e. read timeout always occurs returning zero bytes).

I assumed that this could be the result of flow control problems and thus I've
tried setting either software or hardware based flow control on the port however
this has no affect.

Can you suggest any other port configuration changes which might be required to
make such a port work with RXTX.

Thanks
Stu
-- 
Stuart
Tapastda Limited


From tjarvi at qbang.org  Thu Jun  8 05:17:12 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 8 Jun 2006 05:17:12 -0600 (MDT)
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from
	FieldTalk
In-Reply-To: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
References: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606080504480.9856@www>

On Thu, 8 Jun 2006, Giacomo Petrini wrote:

> Hi,
> I'm evaluating the library for the modbus protocol
> from FieldTalk
> (http://www.modbusdriver.com/fieldtalk/.
> I'm using J2SE 5.0 and RXTX 2.1 on win XP.
> The problem is that the modbus lib has a method (the
> openProtocol method, but maybe there are others) tha
> throws the
> javax.comm.UnsupportedCommOperationException.
> Now, in RXTX 2.1 the namespace has changed in gnu.io,
> so the modbus library doesn't work anymore (it look
> for things in javax.comm). I've already sent an email
> to fieldtalk to see if they are aware of the problem.
> The solution should be to use JavaComm + RXTX 2.0. But
> I've read somewhere that JavaComm 2.0 does not work
> with Java 5.0 and JavaComm 3.0 does not work with RXTX
> 2.0 so I don't know what to do.
>
> Any ideas?
>
> Thanks Jack
>


Hi Jack

There are plans for Sun to rerelease JavaComm 2.0 mentioned in the rxtx 
mail-list archives.  When this happens rxtx will release a current rxtx 
2.0 library that works with it.

There are no dates promised by either side but rxtx will do it as soon as 
possible after Sun's rerelease.  Just to give you a feel for the time 
frame, this started last year and no significant progress has been made. 
There have been friendly talks pointing towards solutions (rerelease 2.0) 
but that does not get your application working today.  rxtx is preparing 
for its second release in gnu.io since then.

--
Trent Jarvi
tjarvi at qbang.org




From jredman at ergotech.com  Thu Jun  8 08:47:23 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 08 Jun 2006 08:47:23 -0600
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from
	FieldTalk
In-Reply-To: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
References: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
Message-ID: <4488387B.6040903@ergotech.com>

You could always try a different library, eg.

http://sourceforge.net/projects/jamod

I've only used the slave side since we have our own implementation of 
Modbus Client (and a host of other PLC protocols).  However the client 
side seems to be pretty well supported and fairly widely used.  Since 
the source is there you could change to gnu.io.

I think I should take more of an interest in this issue.  We generally 
run 1.4.2 on Linux, but also have some J9 and old platforms that we 
support that are basically Personal Java.  5.0 on Linux has some 
horrible MDI bugs, to the point of being unusable.   Sounds as though we 
are going to have code compatibility problems across these platforms.

Jim


Giacomo Petrini wrote:
> Hi,
> I'm evaluating the library for the modbus protocol
> from FieldTalk
> (http://www.modbusdriver.com/fieldtalk/.
> I'm using J2SE 5.0 and RXTX 2.1 on win XP.
> The problem is that the modbus lib has a method (the
> openProtocol method, but maybe there are others) tha
> throws the
> javax.comm.UnsupportedCommOperationException.
> Now, in RXTX 2.1 the namespace has changed in gnu.io,
> so the modbus library doesn't work anymore (it look
> for things in javax.comm). I've already sent an email
> to fieldtalk to see if they are aware of the problem.
> The solution should be to use JavaComm + RXTX 2.0. But
> I've read somewhere that JavaComm 2.0 does not work
> with Java 5.0 and JavaComm 3.0 does not work with RXTX
> 2.0 so I don't know what to do.
> 
> Any ideas?
> 
> Thanks Jack
> 
> PS: can you make a CC to my personal email
> (g_petrini at yahoo.it) too please?
> 
> Chiacchiera con i tuoi amici in tempo reale! 
>  http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  8 18:17:23 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 08 Jun 2006 17:17:23 -0700
Subject: [Rxtx] rxtx access is denied error
Message-ID: <4488BE13.2050706@dupreeinc.com>

Hello,

I have been trying to replace the commapi from sun with rxtx for a 
project that communicates with a serial port that is a USB-Serial 
interface.  To be exact, I am using the FTDI VCP driver with one of 
their modules connected to a windows XP system.

I have the RXTX package working pretty well as long as nothing goes wrong.

If a user disconnects the USB port while my java application is running, 
my application goes into an endless loop with lots of messages in the  
errors stream  like the ones below:

    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(481):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.


I believe when this happens the COM port completely disappears and the 
rxtx driver has a heart attack.  Obviously, the user should not do this, 
but my application needs to ideally, correct the situation or as a worse 
case, terminate with a little dignity.  Currently, I have not figured 
out how to catch this error.

The closest I have come is to trap an exception to my input stream read  
that says "No error in readByte"  This error appears to be outside of 
the endless loop of the errors listed above.

Does anybody have an idea of how to identify and trap this error?  Any 
suggestions on how to gracefully recover from it would be greatly 
appreciated!

Thank you for your time,

Doug Thistlethwaite




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060608/9cfca302/attachment-0006.html

From tjarvi at qbang.org  Thu Jun  8 20:54:17 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 8 Jun 2006 20:54:17 -0600 (MDT)
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <4488BE13.2050706@dupreeinc.com>
References: <4488BE13.2050706@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606082022580.1323@www>

On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I have been trying to replace the commapi from sun with rxtx for a project 
> that communicates with a serial port that is a USB-Serial interface.  To be 
> exact, I am using the FTDI VCP driver with one of their modules connected to 
> a windows XP system.
>
> I have the RXTX package working pretty well as long as nothing goes wrong.
>
> If a user disconnects the USB port while my java application is running, my 
> application goes into an endless loop with lots of messages in the  errors 
> stream  like the ones below:
>
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(481):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>
>
> I believe when this happens the COM port completely disappears and the rxtx 
> driver has a heart attack.  Obviously, the user should not do this, but my 
> application needs to ideally, correct the situation or as a worse case, 
> terminate with a little dignity.  Currently, I have not figured out how to 
> catch this error.
>
> The closest I have come is to trap an exception to my input stream read  that 
> says "No error in readByte"  This error appears to be outside of the endless 
> loop of the errors listed above.
>
> Does anybody have an idea of how to identify and trap this error?  Any 
> suggestions on how to gracefully recover from it would be greatly 
> appreciated!
>

Hi Doug

Sadly I don't have a quick solution for you.

Termios has no knowlage about the JVM so it wont be throwing exceptions 
you can catch.

We can return error and set the error number to something reasonable that 
results in an exception.  The No Error message simply means we did not set 
an error number in termios.c.  Those are the line numbers in the code you 
see.  SerialImp.c realizes it errored but does not know much more yet. 
Everything touching the file descriptor is going to error after the port 
is gone presumably.

We don't currently have a plan in place for vanishing (or appearing) com 
ports.

Another example of what we need to think about is what happens if you 
start your application and then plug in the dongle?  Or what if you unplug 
and then plug it in again?

So in each of these three cases, what would the behavior of the (yet to 
be) correct implementation do?

How will the enumerated ports be handled during these changes?

There can also be hints from the OS that could be taken into 
consideration.

We can probably get some exceptions thrown that make sense and null the 
file descriptor when it happens to prevent io attempts.  That would be a 
crude way to let applications know something strange has happened.

Is anyone else tinkering with this problem?

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  9 01:31:29 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 9 Jun 2006 09:31:29 +0200
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <Pine.LNX.4.61.0606082022580.1323@www>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
Message-ID: <AC6EDDDD-0A64-401F-B16B-E484788CDF4A@buechse.de>

Hello Trent,

I am not tinkering with this on the Source Level - but I think it  
should work pretty much the same way as it currently does in OSX.  
When the port goes away you get an IOException thrown for any read/ 
write. It will no longer be in the list of ports from  
CommPortIdentifier.getPortIdentifiers(). When a port (re-)appears it  
is added to the list. It's up to the application to re-check the list  
from time to time.

On Windows you can't do much better then that, because the ports  
don't have useful names. Which USB "virtual com port" is on which  
COMx depends on the order the devices were added. So reconnecting to  
the same device may mean connecting to another port.

Regarding the exception thrown: it would be nice to use an  
IOException subclass but the Exception message should definetly be  
informative also as most applications may want to keep compatibility  
with javax.comm.

Regards,
Joachim


On 09.06.2006, at 04:54, Trent Jarvi wrote:

> On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:
>
>> Hello,
>>
>> I have been trying to replace the commapi from sun with rxtx for a  
>> project
>> that communicates with a serial port that is a USB-Serial  
>> interface.  To be
>> exact, I am using the FTDI VCP driver with one of their modules  
>> connected to
>> a windows XP system.
>>
>> I have the RXTX package working pretty well as long as nothing  
>> goes wrong.
>>
>> If a user disconnects the USB port while my java application is  
>> running, my
>> application goes into an endless loop with lots of messages in  
>> the  errors
>> stream  like the ones below:
>>
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (481):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>
>>
>> I believe when this happens the COM port completely disappears and  
>> the rxtx
>> driver has a heart attack.  Obviously, the user should not do  
>> this, but my
>> application needs to ideally, correct the situation or as a worse  
>> case,
>> terminate with a little dignity.  Currently, I have not figured  
>> out how to
>> catch this error.
>>
>> The closest I have come is to trap an exception to my input stream  
>> read  that
>> says "No error in readByte"  This error appears to be outside of  
>> the endless
>> loop of the errors listed above.
>>
>> Does anybody have an idea of how to identify and trap this error?   
>> Any
>> suggestions on how to gracefully recover from it would be greatly
>> appreciated!
>>
>
> Hi Doug
>
> Sadly I don't have a quick solution for you.
>
> Termios has no knowlage about the JVM so it wont be throwing  
> exceptions
> you can catch.
>
> We can return error and set the error number to something  
> reasonable that
> results in an exception.  The No Error message simply means we did  
> not set
> an error number in termios.c.  Those are the line numbers in the  
> code you
> see.  SerialImp.c realizes it errored but does not know much more yet.
> Everything touching the file descriptor is going to error after the  
> port
> is gone presumably.
>
> We don't currently have a plan in place for vanishing (or  
> appearing) com
> ports.
>
> Another example of what we need to think about is what happens if you
> start your application and then plug in the dongle?  Or what if you  
> unplug
> and then plug it in again?
>
> So in each of these three cases, what would the behavior of the  
> (yet to
> be) correct implementation do?
>
> How will the enumerated ports be handled during these changes?
>
> There can also be hints from the OS that could be taken into
> consideration.
>
> We can probably get some exceptions thrown that make sense and null  
> the
> file descriptor when it happens to prevent io attempts.  That would  
> be a
> crude way to let applications know something strange has happened.
>
> Is anyone else tinkering with this problem?
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From doug at dupreeinc.com  Fri Jun  9 13:09:58 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 09 Jun 2006 12:09:58 -0700
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <Pine.LNX.4.61.0606082022580.1323@www>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
Message-ID: <4489C786.9050504@dupreeinc.com>


Ideally, it would be nice if it would throw an exception and terminate 
the loop.  I am still trying to figure out how to detect the condition 
and recover form it in some form...  I am getting the "No error in 
readByte" exception in my serialEvent() method after an input stream 
read.  It appears to me that the only graceful recovery is to close the 
port and then reopen it when it becomes available.  I can pass the event 
up to the update method in my main frame, but I still can't close the 
port from within that thread.  Any suggestions on how to pass this event 
to a location where the port can be safely closed?

Re: Slow startup in windows XP
I have been looking into this a little closer and have found out the 
following:
System Windows XP Pro 3GHz dual core with 1GB RAM and NO parallel port.
Starting the SerialDemo included with the commapi using the rxtx instead 
of javax.comm takes 60 seconds.
Starting the SerialDemo using rxrx with the rxtxParallel.dll file 
removed takes about 20 seconds.
Modify initialize in RXRXCommDriver.java to not test the parallel ports 
takes less than 1 second.

It would be nice if the initialize routine could detect the presence of 
rxtxParallel.dll file and just skip the whole process if not present.  
Is there an easy way to check for the presence of this file without 
running the parallel port test?

Doug


 

Trent Jarvi wrote:

>On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:
>...
>  
>
>
>Hi Doug
>
>Sadly I don't have a quick solution for you.
>
>Termios has no knowlage about the JVM so it wont be throwing exceptions 
>you can catch.
>
>We can return error and set the error number to something reasonable that 
>results in an exception.  The No Error message simply means we did not set 
>an error number in termios.c.  Those are the line numbers in the code you 
>see.  SerialImp.c realizes it errored but does not know much more yet. 
>Everything touching the file descriptor is going to error after the port 
>is gone presumably.
>
>We don't currently have a plan in place for vanishing (or appearing) com 
>ports.
>
>Another example of what we need to think about is what happens if you 
>start your application and then plug in the dongle?  Or what if you unplug 
>and then plug it in again?
>
>So in each of these three cases, what would the behavior of the (yet to 
>be) correct implementation do?
>
>How will the enumerated ports be handled during these changes?
>
>There can also be hints from the OS that could be taken into 
>consideration.
>
>We can probably get some exceptions thrown that make sense and null the 
>file descriptor when it happens to prevent io attempts.  That would be a 
>crude way to let applications know something strange has happened.
>
>Is anyone else tinkering with this problem?
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060609/911ed787/attachment-0006.html

From Ugo.Landini at Sun.COM  Fri Jun  2 14:23:47 2006
From: Ugo.Landini at Sun.COM (Ugo Landini)
Date: Fri, 02 Jun 2006 22:23:47 +0200
Subject: [Rxtx] OSX 10.4.7 and usb
Message-ID: <44809E53.2070905@sun.com>

Hi, I have installed the library and the native libraries on OSX 10.4.7. 
Then I have run this simple code:

...
while (portList.hasMoreElements()) {
             portId = (CommPortIdentifier) portList.nextElement();
             System.out.println("-> " + portId.getName() + " Port Type:" 
+ portId.getPortType());
...

and the output is:

Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7

Ports found:
-> /dev/tty.Bluetooth-PDA-Sync Port Type:1
-> /dev/cu.Bluetooth-PDA-Sync Port Type:1
-> /dev/tty.Bluetooth-Modem Port Type:1
-> /dev/cu.Bluetooth-Modem Port Type:1

I can't see any USB ports... with javax.comm on linux I could see the 
/dev/ttyUSB stuff, but that's not the case with OSX. Any idea?

tia

uL


From tod at todbot.com  Sun Jun 11 12:04:37 2006
From: tod at todbot.com (Tod E. Kurt)
Date: Sun, 11 Jun 2006 11:04:37 -0700
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <44809E53.2070905@sun.com>
References: <44809E53.2070905@sun.com>
Message-ID: <E2EB14A1-20A7-4611-8F1A-E3D2ABE41F48@todbot.com>

A dumb question, but: do you have the USB serial adapters plugged  
in?  They only show up in /dev when plugged in.  Also, you can verify  
they exist independent of RXTX by doing something like "ls -l /dev/ 
cu.*".

On Jun 2, 2006, at 1:23 PM, Ugo Landini wrote:

> Hi, I have installed the library and the native libraries on OSX  
> 10.4.7.
> Then I have run this simple code:
>
> ...
> while (portList.hasMoreElements()) {
>              portId = (CommPortIdentifier) portList.nextElement();
>              System.out.println("-> " + portId.getName() + " Port  
> Type:"
> + portId.getPortType());
> ...
>
> and the output is:
>
> Experimental:  JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
>
> Ports found:
> -> /dev/tty.Bluetooth-PDA-Sync Port Type:1
> -> /dev/cu.Bluetooth-PDA-Sync Port Type:1
> -> /dev/tty.Bluetooth-Modem Port Type:1
> -> /dev/cu.Bluetooth-Modem Port Type:1
>
> I can't see any USB ports... with javax.comm on linux I could see the
> /dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>
> tia
>
> uL
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>



From lyon at docjava.com  Sun Jun 11 12:14:50 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Sun, 11 Jun 2006 14:14:50 -0400
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <44809E53.2070905@sun.com>
References: <44809E53.2070905@sun.com>
Message-ID: <p06020444c0b20de7d248@[192.168.1.152]>

>Hi Ugo,

Do you have any USB serial ports (like the keyspan 19-HS) plugged
into the mac?
Thanks!
  - DL


>Hi, I have installed the library and the native libraries on OSX 10.4.7.
>Then I have run this simple code:
>
>...
>while (portList.hasMoreElements()) {
>              portId = (CommPortIdentifier) portList.nextElement();
>              System.out.println("-> " + portId.getName() + " Port Type:"
>+ portId.getPortType());
>...
>
>and the output is:
>
>Experimental:  JNI_OnLoad called.
>Stable Library
>=========================================
>Native lib Version = RXTX-2.1-7
>Java lib Version   = RXTX-2.1-7
>
>Ports found:
>-> /dev/tty.Bluetooth-PDA-Sync Port Type:1
>-> /dev/cu.Bluetooth-PDA-Sync Port Type:1
>-> /dev/tty.Bluetooth-Modem Port Type:1
>-> /dev/cu.Bluetooth-Modem Port Type:1
>
>I can't see any USB ports... with javax.comm on linux I could see the
>/dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>
>tia
>
>uL
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx



From dmarkman at mac.com  Sun Jun 11 14:30:27 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Sun, 11 Jun 2006 16:30:27 -0400
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <p06020444c0b20de7d248@[192.168.1.152]>
References: <44809E53.2070905@sun.com> <p06020444c0b20de7d248@[192.168.1.152]>
Message-ID: <B9C1606B-4339-4564-A175-FE83DFFA7D76@mac.com>

afaik
10.4.7 wasn't released yet
it will soon, no doubts


On Jun 11, 2006, at 2:14 PM, Dr. Douglas Lyon wrote:

>> Hi Ugo,
>
> Do you have any USB serial ports (like the keyspan 19-HS) plugged
> into the mac?
> Thanks!
>   - DL
>
>
>> Hi, I have installed the library and the native libraries on OSX  
>> 10.4.7.
>> Then I have run this simple code:
>>
>> ...
>> while (portList.hasMoreElements()) {
>>              portId = (CommPortIdentifier) portList.nextElement();
>>              System.out.println("-> " + portId.getName() + " Port  
>> Type:"
>> + portId.getPortType());
>> ...
>>
>> and the output is:
>>
>> Experimental:  JNI_OnLoad called.
>> Stable Library
>> =========================================
>> Native lib Version = RXTX-2.1-7
>> Java lib Version   = RXTX-2.1-7
>>
>> Ports found:
>> -> /dev/tty.Bluetooth-PDA-Sync Port Type:1
>> -> /dev/cu.Bluetooth-PDA-Sync Port Type:1
>> -> /dev/tty.Bluetooth-Modem Port Type:1
>> -> /dev/cu.Bluetooth-Modem Port Type:1
>>
>> I can't see any USB ports... with javax.comm on linux I could see the
>> /dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>>
>> tia
>>
>> uL
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman



From tjarvi at qbang.org  Sun Jun 11 18:52:59 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 11 Jun 2006 18:52:59 -0600 (MDT)
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <4489C786.9050504@dupreeinc.com>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
	<4489C786.9050504@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606111845430.7274@www>

On Fri, 9 Jun 2006, Doug Thistlethwaite wrote:

>
> Ideally, it would be nice if it would throw an exception and terminate the 
> loop.  I am still trying to figure out how to detect the condition and 
> recover form it in some form...  I am getting the "No error in readByte" 
> exception in my serialEvent() method after an input stream read.  It appears 
> to me that the only graceful recovery is to close the port and then reopen it 
> when it becomes available.  I can pass the event up to the update method in 
> my main frame, but I still can't close the port from within that thread.  Any 
> suggestions on how to pass this event to a location where the port can be 
> safely closed?
>

I've gone through and cleaned up the termios.c layer.  I need to get to a 
windows machine with a USB dongle and see where the ioctl() is being 
called.  Probably the eventLoop.  But all of the ioctls should probably 
result in an IOException during this condition.

I'll probably finish this up Monday night when I can borrow a USB 
dongle.

There is no point in putting the code into CVS yet.  If you are tinkering 
I can mail the patch.  I think we will want to make a couple fixes in 
SerialImp.c to handle errors before it's ready.

--
Trent Jarvi
tjarvi at qbang.org



From bob_tai2001 at yahoo.com  Mon Jun 12 09:42:14 2006
From: bob_tai2001 at yahoo.com (Bob Tai)
Date: Mon, 12 Jun 2006 08:42:14 -0700 (PDT)
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to RXTX
	again
Message-ID: <20060612154214.58219.qmail@web32804.mail.mud.yahoo.com>


thank you Paul, Joachim, Trent and everyone try to
workout the java comm and Rxtx situation.  At least
now I have something that is solid enough to make my
decision.  

thank you,
     Bob

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From Ralph.Buchfelder at gmx.net  Mon Jun 12 15:30:20 2006
From: Ralph.Buchfelder at gmx.net (Ralph Buchfelder)
Date: Mon, 12 Jun 2006 23:30:20 +0200
Subject: [Rxtx] rxtx binaries or porting to XSCALE Windows Mobile 2003 / 2005
Message-ID: <448DDCEC.7090506@gmx.net>

dear group,

i have been carefully reading your homepage, wiki and archives
but there seems to be no detailled information on porting to Windows 
Mobile/CE.

as far as i understood from the 'porting' section you can do porting to 
winCE. but how? do i only need to obtain the sourcecode (which one?) and 
compile this in Microsoft eMbedded Visual C++ for ARM/Xscale?
Any other ways?


unfortunately i must admit that i do have little linux skills but i have 
made my way through gcc and makefiles. right now i need to implement com 
  communication in a J2ME application and found your website as >the< 
solution.

best regards
Ralph Buchfelder

University of Regensburg
Department of Geography

PS: i dont care about Javacomm compliancy (ie. 2.0 or 2.1) - i just need 
a working serial port API in IBM J9 VM.


From paul.klissner at sun.com  Wed Jun 14 18:12:58 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Wed, 14 Jun 2006 17:12:58 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
Message-ID: <4490A60A.9090305@sun.com>

Hello RxTx community,

I finally think I have a compromise in place that will stand in the gap.

If you go to http://www.sun.com and search for javax.comm, you'll
get taken to a download page, where now users can get a copy of the
comm.jar file out of 2.0.3, along with just a license and a README.

I trust this will suffice until such time as RxTx decided to implement
their own java classes or we can get a JSR going to mitigate some
of the problems (the readme in the comm.jar 2.0.3 zip file
contains my thoughts on that).

Thanks,
Paul



From tjarvi at qbang.org  Wed Jun 14 21:15:35 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 14 Jun 2006 21:15:35 -0600 (MDT)
Subject: [Rxtx] rxtx-2.0-7 (final) src is in CVS
Message-ID: <Pine.LNX.4.61.0606142100500.2742@www>


I wasn't expecting to be working on rxtx 2.0 tonight :)

Thanks go out to Paul Klissner for his work in making the coming release 
of rxtx-2.0-7 possible for users that require package javax.comm on many 
platforms.

Most people know that rxtx 2.0 is for use with Sun's CommAPI 2.0 for 
Solaris or the Generic CommAPI 2.0-3 available for download at Sun.  If 
you need javax.comm packages on many platforms, you are probably 
interested.  If you use rxtx 2.1 in package gnu.io, then you are not going 
to care much.

I've tried to update the rxtx 2.0 src directory in preparation for 
rxtx-2.0-7 (final).  Linux should compile.  Windows will compile if you 
generate your own .def files (I'll generate these tomorrow).  If you have 
some time to do basic testing of the source, I'd appreciate it.  The 
source should be good but you may find classes not found.  This source is 
a backport from rxtx 2.1.

I wanted to get things started so anyone interested on Mac OS X could get 
a head start.

All of this is in CVS.  http://www.rxtx.org/cvs.html

I suspect we will have binaries for testing in a couple days if you are 
unable to compile.   Consider this a smoke test.

--
Trent Jarvi
tjarvi at qbang.org


From legolas.w at gmail.com  Wed Jun 14 22:04:28 2006
From: legolas.w at gmail.com (Legolas Woodland)
Date: Wed, 14 Jun 2006 21:04:28 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <4490A60A.9090305@sun.com>
References: <4490A60A.9090305@sun.com>
Message-ID: <87ee9b170606142104p745fcef0vea622fbc8f528bfc@mail.gmail.com>

is there anything new in this version of javax.comm ?
thanks


On 6/14/06, Paul Klissner <paul.klissner at sun.com> wrote:
>
> Hello RxTx community,
>
> I finally think I have a compromise in place that will stand in the gap.
>
> If you go to http://www.sun.com and search for javax.comm, you'll
> get taken to a download page, where now users can get a copy of the
> comm.jar file out of 2.0.3, along with just a license and a README.
>
> I trust this will suffice until such time as RxTx decided to implement
> their own java classes or we can get a JSR going to mitigate some
> of the problems (the readme in the comm.jar 2.0.3 zip file
> contains my thoughts on that).
>
> Thanks,
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060614/5ff4dfbc/attachment-0006.html

From joachim at buechse.de  Thu Jun 15 07:22:48 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 15 Jun 2006 15:22:48 +0200
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
Message-ID: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>

Good day!

Some of my users report problems using RXTX 2.1.7 on Windows98 to  
communicate with an FTDI FT245BM chip (using their latest VCP  
driver). Either no ports are being shown (ie returned form  
CommPortIdentifier.getPortIdentifiers()) or the transfers fail.

Did anyone run into similar Problems with Win98??

Best regards,
Joachim



From ajmas at sympatico.ca  Thu Jun 15 08:12:28 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Thu, 15 Jun 2006 10:12:28 -0400
Subject: [Rxtx] API change question
Message-ID: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

How closely do you follow the Java Communication API spec? The reason I ask is because I would be interested in augmenting the CommPortIdentifier class to include a getDisplayName() method. By default it would return the same value as getName(), but would provide the possibility of displaying a 'user friendly' name, for platforms where the display name is not the same as the device name. An example of this is on MacOS X, where currently the names seem to be of the form /dev/cu.* and /dev/tty.*, yet what the expects to see is simply the part after the full-stop. Although I could move this logic into the Java code, it would be nice to see it transparent to the Java code.

Andre




From ajmas at sympatico.ca  Thu Jun 15 08:16:22 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Thu, 15 Jun 2006 10:16:22 -0400
Subject: [Rxtx] Package to use
Message-ID: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

While the Java API spec refers to javax.comm, I see that only gnu.io is provide by the rxtx project. Should our projects refer to the gnu.io package or the javax.comm API?

Andre



From joachim at buechse.de  Thu Jun 15 08:45:05 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 15 Jun 2006 16:45:05 +0200
Subject: [Rxtx] API change question
In-Reply-To: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>

Hello Andre,

the /dev/cu and /dev/tty have different semantics on OS X. It is much  
more than a simply naming issue to unify them, see my recent mail to  
the list...

Best regards,
Joachim


On 15.06.2006, at 16:12, Andre-John Mas wrote:

> Hi,
>
> How closely do you follow the Java Communication API spec? The  
> reason I ask is because I would be interested in augmenting the  
> CommPortIdentifier class to include a getDisplayName() method. By  
> default it would return the same value as getName(), but would  
> provide the possibility of displaying a 'user friendly' name, for  
> platforms where the display name is not the same as the device  
> name. An example of this is on MacOS X, where currently the names  
> seem to be of the form /dev/cu.* and /dev/tty.*, yet what the  
> expects to see is simply the part after the full-stop. Although I  
> could move this logic into the Java code, it would be nice to see  
> it transparent to the Java code.
>
> Andre
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From lyon at docjava.com  Thu Jun 15 10:16:29 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Thu, 15 Jun 2006 12:16:29 -0400
Subject: [Rxtx] cu.modem != /dev/ttya on mac.
In-Reply-To: <763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
	<763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>
Message-ID: <p0602046cc0b7378a95b0@[192.168.1.152]>

>Hi All,

I think that Joachim is correct. For the longest time,
I have been trying to figure out how to direct dial using
the cu.modem on the mac under os x.

As a less-than-optimal approach to auto-dialing, I have used
a keyspan USB 19HS adapter, along with an external modem, to
obtain the dialing feature.

Ideally, it would be better to dial with the built-in modem...but that did not
always seem to work, for some reason. Have others had some experience with
using the built in modem for dialing on the mac?

Thanks!
  - Doug


>Hello Andre,
>
>the /dev/cu and /dev/tty have different semantics on OS X. It is much?
>more than a simply naming issue to unify them, see my recent mail to?
>the list...
>
>Best regards,
>Joachim
>



From doug at dupreeinc.com  Thu Jun 15 14:52:50 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 15 Jun 2006 13:52:50 -0700
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
In-Reply-To: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
References: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
Message-ID: <4491C8A2.8090108@dupreeinc.com>

Hi Joachim,

I have been doing a lot with the new FTDI driver with win XP and have 
not had that particular problem.  I did notice that the new driver 
(dated May19th, 2006) is only for XP, Server 2003, and 2000.  Are they 
trying to use the 2.00.00 drivers or the old 1.09.06 version.  I am 
using a FT232R based module, but it uses the same drivers and I assume 
it would have the same problems.  Let me know which driver they are 
using and I can load up a 98 system here and see if  I can duplicate the 
problem.

Doug

Joachim Buechse wrote:

>Good day!
>
>Some of my users report problems using RXTX 2.1.7 on Windows98 to  
>communicate with an FTDI FT245BM chip (using their latest VCP  
>driver). Either no ports are being shown (ie returned form  
>CommPortIdentifier.getPortIdentifiers()) or the transfers fail.
>
>Did anyone run into similar Problems with Win98??
>
>Best regards,
>Joachim
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From matthewhepp at yahoo.com  Thu Jun 15 17:34:47 2006
From: matthewhepp at yahoo.com (Matthew Hepp)
Date: Thu, 15 Jun 2006 16:34:47 -0700 (PDT)
Subject: [Rxtx] Wither the XCode project?
Message-ID: <20060615233447.48064.qmail@web50311.mail.yahoo.com>

Either I don't know how to properly use CVS (entirely possibl), or the XCode
project is not making through the update properly. Doing a "cvs update" against
2.1-7 creates an XCode folder in MACOSX_IDE, and therein a
LibSerialUniversal.xcodeproj, but trying to open it yields a "Unable to Open
Project - Project rxtx-devel/MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj
cannot be opened because it is missing its project.pbxproj file" error. Showing
package contents reveals just the cvs-related files. Perhaps this is why
previous xcode projects have been saved as an sit.hqx - to retain the resource
fork?

Can someone point me in the right direction?

Thanks,

Matt

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Thu Jun 15 19:53:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 19:53:06 -0600 (MDT)
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
In-Reply-To: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
References: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
Message-ID: <Pine.LNX.4.61.0606151944070.23137@www>

On Thu, 15 Jun 2006, Joachim Buechse wrote:

> Good day!
>
> Some of my users report problems using RXTX 2.1.7 on Windows98 to
> communicate with an FTDI FT245BM chip (using their latest VCP
> driver). Either no ports are being shown (ie returned form
> CommPortIdentifier.getPortIdentifiers()) or the transfers fail.
>
> Did anyone run into similar Problems with Win98??
>

Hi Joachim

It has been a long time since I've tested win98.  I know rxtx-2.1-7pre16 
did get testing on win98 with ~jdk 1.3 though.  I wonder if jdks are still 
tested on that platform.

With win98 you usually have older boxes.  They can be short on CPU and 
memory.  Enumeration should work but I could picture runtime performance 
issues on win98.

The enumeration problems could result from other copies of your 
application if various states of decay still holding onto the port.  When 
things go wrong, people also like to open other terminal software to see 
whats going on which can interfere.  You can't open a windows port with 
two apps.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Thu Jun 15 20:08:53 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 20:08:53 -0600 (MDT)
Subject: [Rxtx] API change question
In-Reply-To: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606151954270.23137@www>

On Thu, 15 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> How closely do you follow the Java Communication API spec?

I can explain how this worked in the past.  How we do it in the future is 
open for discussion.

In the past we have tried to follow it as close as possible in gnu.io 
(rxtx 2.1).  We have added extensions but try to discourage their use. 
The extensions are clearly marked as such in the source code and javadocs.

rxtx 2.0 was intended to be a strict implementation of part of the spec. 
We let Sun's interfaces decide what methods can be called. There are 
differences not covered by the spec such as default values.  Thats not 
intentional but rather hard to avoid.

--
Trent Jarvi
tjarvi at qbang.org





From tjarvi at qbang.org  Thu Jun 15 21:09:11 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 21:09:11 -0600 (MDT)
Subject: [Rxtx] Package to use
In-Reply-To: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606152026120.23137@www>

On Thu, 15 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> While the Java API spec refers to javax.comm, I see that only gnu.io is 
> provide by the rxtx project. Should our projects refer to the gnu.io 
> package or the javax.comm API?
>

Hi Andre

Lets see if I can give a fair and balanced answer to that.

If you are starting a new project and want to use RXTX, I would recommend 
using gnu.io.  The community support for gnu.io will not be going away 
anytime soon.  You can switch between gnu.io (2.1) and javax.comm (2.0) 
fairly easily.  They are not intended to be incompatible.  You just change 
package names and libs.

You can also consider the combination of rxtx 2.0 with Sun's commapi 
2.0-3.  This is considered a stop-gap measure by Sun for previous users of 
that combination.  Together rxtx 2.0 and Sun CommAPI 2.0 work in namespace 
javax.comm for programmers.

Finally, you can opt to just use Sun's oferrings in CommAPI 3.0 without 
rxtx.  That would be in namespace javax.comm also.  CommAPI 3.0 may be 
of more interest to you if you are looking at POS with Sun computers. 
Rxtx does not currently support the changes in CommAPI 3.0 or have firm 
plans to do so.  That does not mean we wouldn't implement them.  It just 
means nobody has contributed code yet.

You can't combine rxtx with CommAPI 3.0 for technical reasons that wont 
likely be fixed soon.

It's up to you as far as what you use.  We like to provide the freedom so 
you can choose.  Realistically, we will be supporting gnu.io mainly 
because we have some control over that name space and can support it.

Things may happen in the future that enable rxtx to provide more support 
in the javax namespace but that has not happened yet.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun 16 00:33:06 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 08:33:06 +0200
Subject: [Rxtx] Wither the XCode project?
In-Reply-To: <20060615233447.48064.qmail@web50311.mail.yahoo.com>
References: <20060615233447.48064.qmail@web50311.mail.yahoo.com>
Message-ID: <D30D660F-A49B-464E-AE4C-6B4563893682@buechse.de>

Hello Matthew,

could you please send me the contents of your

   rxtx-devel/CVS
   rxtx-devel/MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj/CVS

directories as a zip to my personal email address. This should  
indicate why the file is not checked out. I can see that it exists on  
the correct branch in the repository, so something must have gone  
wrong during the "cvs update"...

Best regards,
Joachim

On 16.06.2006, at 01:34, Matthew Hepp wrote:

> Either I don't know how to properly use CVS (entirely possibl), or  
> the XCode
> project is not making through the update properly. Doing a "cvs  
> update" against
> 2.1-7 creates an XCode folder in MACOSX_IDE, and therein a
> LibSerialUniversal.xcodeproj, but trying to open it yields a  
> "Unable to Open
> Project - Project rxtx-devel/MACOSX_IDE/XCode/ 
> LibSerialUniversal.xcodeproj
> cannot be opened because it is missing its project.pbxproj file"  
> error. Showing
> package contents reveals just the cvs-related files. Perhaps this  
> is why
> previous xcode projects have been saved as an sit.hqx - to retain  
> the resource
> fork?
>
> Can someone point me in the right direction?



From joachim at buechse.de  Fri Jun 16 10:41:20 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 18:41:20 +0200
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <p06230903c0b88613dca6@[10.0.1.7]>
References: <p06230903c0b88613dca6@[10.0.1.7]>
Message-ID: <03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>

Hello Bob,

until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was  
behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if  
Trent has migrated all recent changes from 2.1 to 2.0.

I have added the XCode project and updated documentation only to the  
gnu.io branch. Once the 2.0 implementation is up to date I will copy  
over the documentation/build files make them work.

Best regards,
Joachim

On 16.06.2006, at 18:07, Bob Jacobsen wrote:

> I'm one of the developers for the JMRI project, which provides  
> model railroad software in Java.  We've been using RXTX to provide  
> serial port access on MacOS X and Linux; we use the old javax.comm  
> 2.0 on Windows, OS/2 and Solaris.  Because of that, we need to stay  
> with RXTX 2.0, not 2.1
>
> We've been using the 2.0-pre17 installer for a long time, but it's  
> not compatible with Intel macs.
>
> Can you point me to where I can find the right files for RXTX 2.0  
> to package with the program?
>
> The current situation is confusing to me.  I've been pointed to  
> recent 2.1 versions (but we need the javax.comm names), to an even  
> older installer, etc.  I've been reading that some versions require  
> an installer, and others don't, but I haven't been able to figure  
> out which (if any) of those are where in CVS.
>
> I'd really appreciate a clear statement of what files to use and  
> what to do with them that I can pass on to our users.
>
> I'm more than happy to put files in the local classpath, have users  
> run an installer, or anything else.  Whatever is easiest for you.
>
> Thanks!  I really appreciate all that you do to keep RXTX working.
>
> Bob
> -- 
> Bob Jacobsen +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG



From joachim at buechse.de  Fri Jun 16 09:59:28 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 17:59:28 +0200
Subject: [Rxtx] Wither the XCode project?
In-Reply-To: <20060616150240.49464.qmail@web50309.mail.yahoo.com>
References: <20060616150240.49464.qmail@web50309.mail.yahoo.com>
Message-ID: <D9935E05-2B83-488D-86DD-42599E229052@buechse.de>

Hello Matthew,

you have checked out the trunk (which is the 2.0.7 javax.comm.xxx  
release). For rxtx-2.1.7 (gnu.io.xxx release) you need to check out  
the branch

      commapi-0-0-1

The easiest way to do this is to download the rxtx src archive,  
unpack it and then do a cvs up inside the decompressed tree.  
Optionally you could do a

      cvs co -r commapi-0-0-1

but this will take much longer!

Best regards,
Joachim

When you do a cvs status it will show the sticky tag.

41:~/jdevelop/rxtx-2.1-7r2 joachim$ cvs status README.OSX
===================================================================
File: README.OSX        Status: Up-to-date

    Working revision:    1.1.2.1
    Repository revision: 1.1.2.1 /usr/local/cvsroot/rxtx-devel/Attic/ 
README.OSX,v
    Sticky Tag:          commapi-0-0-1 (branch: 1.1.2)
    Sticky Date:         (none)
    Sticky Options:      (none)




On 16.06.2006, at 17:02, Matthew Hepp wrote:

> %cvs status README.MACOSX
> ===================================================================
> File: README.MACOSX     Status: Up-to-date
>
>    Working revision:    1.1
>    Repository revision: 1.1     /usr/local/cvsroot/rxtx-devel/ 
> README.MACOSX,v
>    Sticky Tag:          (none)
>    Sticky Date:         (none)
>    Sticky Options:      (none)



From tjarvi at qbang.org  Fri Jun 16 16:31:18 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Fri, 16 Jun 2006 16:31:18 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
Message-ID: <Pine.LNX.4.61.0606161630030.14139@www>

On Fri, 16 Jun 2006, Joachim Buechse wrote:

> Hello Bob,
>
> until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was
> behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if
> Trent has migrated all recent changes from 2.1 to 2.0.
>

The src/ directory and configure.in/configure files should be fine.  I 
have not touched the Mac OS X directories.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sat Jun 17 02:39:55 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sat, 17 Jun 2006 10:39:55 +0200
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <Pine.LNX.4.61.0606161630030.14139@www>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
Message-ID: <350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>

Hello Trent,

apparently the IOEXCL changes have not made it into 2.0. I will add  
them to achieve a minimal diff between 2.0 and 2.1.

One other thing that bugs me for a while...

Shouldn't we replace "if !defined(TIOCSERGETLSR) && !defined(WIN32)"  
by a definition of its own "if defined(DRAINTHREAD)"? I think this  
would make the code clearer for people starting to read it.

Regards,
Joachim


On 17.06.2006, at 00:31, Trent Jarvi wrote:

> On Fri, 16 Jun 2006, Joachim Buechse wrote:
>
>> Hello Bob,
>>
>> until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was
>> behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if
>> Trent has migrated all recent changes from 2.1 to 2.0.
>>
>
> The src/ directory and configure.in/configure files should be fine.  I
> have not touched the Mac OS X directories.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From tropicsu at hotmail.com  Sat Jun 17 09:32:48 2006
From: tropicsu at hotmail.com (Yoke K)
Date: Sat, 17 Jun 2006 15:32:48 +0000
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
Message-ID: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>

Hi,

I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to work with 
MAC OS X.
I am using iTegno 3000 - USB GPRS Modem.

Files in /dev and a symbolic link as follows:

crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 -> tty.usbserial

In my SendMessage.java, I have this line:
CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");

Appreciate any help ?

- Jon


Errors as follows:

>>INFO: SMSLib API for Java / v1.2.2
>>INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>INFO: JRE Version: 1.5.0_06
>>INFO: JRE Impl Version: 1.5.0_06-64
>>INFO: O/S: Mac OS X / ppc / 10.4.6
>>INFO: Using Wavecom (Generic) AT handler.

SendMessage(): Send a message.
  Using SMSLib API for Java v1.2.2

Connecting ..... :
>>INFO: CSerialDriver(): Connecting...
Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
>>INFO: CSerialDriver(): Disconnecting...
gnu.io.NoSuchPortException
        at 
gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:218)
        at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
        at org.smslib.CService.connect(CService.java:197)
        at SendMessage.main(SendMessage.java:38)

_________________________________________________________________
Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/



From tjarvi at qbang.org  Sat Jun 17 10:12:30 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 10:12:30 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
	<350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
Message-ID: <Pine.LNX.4.61.0606171010060.14139@www>

On Sat, 17 Jun 2006, Joachim Buechse wrote:

> Hello Trent,
>
> apparently the IOEXCL changes have not made it into 2.0. I will add
> them to achieve a minimal diff between 2.0 and 2.1.
>

Hi Joachim

As I recall the IOEXCL change was after 2.1-7.  I was just syncing with 
2.1-7.  We can release 2.1-8 and 2.0-8 with the same changes.

> One other thing that bugs me for a while...
>
> Shouldn't we replace "if !defined(TIOCSERGETLSR) && !defined(WIN32)"
> by a definition of its own "if defined(DRAINTHREAD)"? I think this
> would make the code clearer for people starting to read it.
>


Sure.  We can do that for -8.  The TIOCSERGETLSR code should be a special 
case not the expected.  I think only Linux uses it.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Sat Jun 17 10:48:21 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 10:48:21 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <Pine.LNX.4.61.0606171010060.14139@www>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
	<350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
	<Pine.LNX.4.61.0606171010060.14139@www>
Message-ID: <Pine.LNX.4.61.0606171047310.14139@www>

On Sat, 17 Jun 2006, Trent Jarvi wrote:

> On Sat, 17 Jun 2006, Joachim Buechse wrote:
>
>> Hello Trent,
>>
>> apparently the IOEXCL changes have not made it into 2.0. I will add
>> them to achieve a minimal diff between 2.0 and 2.1.
>>
>
> Hi Joachim
>
> As I recall the IOEXCL change was after 2.1-7.  I was just syncing with
> 2.1-7.  We can release 2.1-8 and 2.0-8 with the same changes.
>

We could just move to 2.1-8 and 2.0-8.

--
Trent Jarvi
tjarvi at qbang.org


From brian.t.lamb at gmail.com  Tue Jun 13 13:54:13 2006
From: brian.t.lamb at gmail.com (Brian Lamb)
Date: Tue, 13 Jun 2006 15:54:13 -0400
Subject: [Rxtx] Windows XP Installation
Message-ID: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>

I've not installed Java packages on Windows before and am unsure how to
proceed. All the documentation I've seen provides detailed instructions on
how to install on Linux or Solaris. I was wondering how to install rxtx on
Windows XP.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060613/6f68cd5c/attachment-0006.html

From tjarvi at qbang.org  Sat Jun 17 13:57:03 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 13:57:03 -0600 (MDT)
Subject: [Rxtx] Windows XP Installation
In-Reply-To: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>
References: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0606171356120.14139@www>

On Tue, 13 Jun 2006, Brian Lamb wrote:

> I've not installed Java packages on Windows before and am unsure how to
> proceed. All the documentation I've seen provides detailed instructions on
> how to install on Linux or Solaris. I was wondering how to install rxtx on
> Windows XP.
>

Hi Brian

Which rxtx version are you trying to install?

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sun Jun 18 10:41:44 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sun, 18 Jun 2006 18:41:44 +0200
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
References: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
Message-ID: <8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>

Hello Jon,

 From OSX's standpoint a symbolic link is not a device (as far as I  
know). What stops you from using tty.usbserial? Did you try hard- 
linking?

Regards,
Joachim

On 17.06.2006, at 17:32, Yoke K wrote:
> Hi,
>
> I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to  
> work with
> MAC OS X.
> I am using iTegno 3000 - USB GPRS Modem.
>
> Files in /dev and a symbolic link as follows:
>
> crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
> crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
> lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->  
> tty.usbserial
>
> In my SendMessage.java, I have this line:
> CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
>
> Appreciate any help ?
>
> - Jon
>
>
> Errors as follows:
>
>>> INFO: SMSLib API for Java / v1.2.2
>>> INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>> INFO: JRE Version: 1.5.0_06
>>> INFO: JRE Impl Version: 1.5.0_06-64
>>> INFO: O/S: Mac OS X / ppc / 10.4.6
>>> INFO: Using Wavecom (Generic) AT handler.
>
> SendMessage(): Send a message.
>   Using SMSLib API for Java v1.2.2
>
> Connecting ..... :
>>> INFO: CSerialDriver(): Connecting...
> Experimental:  JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
>>> INFO: CSerialDriver(): Disconnecting...
> gnu.io.NoSuchPortException
>         at
> gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java: 
> 218)
>         at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
>         at org.smslib.CService.connect(CService.java:197)
>         at SendMessage.main(SendMessage.java:38)
>
> _________________________________________________________________
> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Sun Jun 18 10:56:55 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 12:56:55 -0400
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>
References: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
	<8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>
Message-ID: <7B6834E3-F41D-46B6-B979-55466BC73859@sympatico.ca>

Have you been able to get any other software to talk with your
modem? What port is it using? Have tried using the cu.usbserial
instead?

Andre

On 18-Jun-06, at 12:41 , Joachim Buechse wrote:

> Hello Jon,
>
>  From OSX's standpoint a symbolic link is not a device (as far as I
> know). What stops you from using tty.usbserial? Did you try hard-
> linking?
>
> Regards,
> Joachim
>
> On 17.06.2006, at 17:32, Yoke K wrote:
>> Hi,
>>
>> I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to
>> work with
>> MAC OS X.
>> I am using iTegno 3000 - USB GPRS Modem.
>>
>> Files in /dev and a symbolic link as follows:
>>
>> crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
>> crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
>> lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->
>> tty.usbserial
>>
>> In my SendMessage.java, I have this line:
>> CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
>>
>> Appreciate any help ?
>>
>> - Jon
>>
>>
>> Errors as follows:
>>
>>>> INFO: SMSLib API for Java / v1.2.2
>>>> INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>>> INFO: JRE Version: 1.5.0_06
>>>> INFO: JRE Impl Version: 1.5.0_06-64
>>>> INFO: O/S: Mac OS X / ppc / 10.4.6
>>>> INFO: Using Wavecom (Generic) AT handler.
>>
>> SendMessage(): Send a message.
>>   Using SMSLib API for Java v1.2.2
>>
>> Connecting ..... :
>>>> INFO: CSerialDriver(): Connecting...
>> Experimental:  JNI_OnLoad called.
>> Stable Library
>> =========================================
>> Native lib Version = RXTX-2.1-7
>> Java lib Version   = RXTX-2.1-7
>>>> INFO: CSerialDriver(): Disconnecting...
>> gnu.io.NoSuchPortException
>>         at
>> gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:
>> 218)
>>         at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
>>         at org.smslib.CService.connect(CService.java:197)
>>         at SendMessage.main(SendMessage.java:38)
>>
>> _________________________________________________________________
>> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Sun Jun 18 17:33:08 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 19:33:08 -0400
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
Message-ID: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>

Hi,

I am have a program that I wrote in Java to communicate with a  
Bluetooth GPS device. I am
trying to get this working on my Mac, but I keep getting told that:

gnu.io.PortInUseException: Unknown Application

but

portIdentifier.isCurrentlyOwned()

returns false and when I do lsof on the device I am trying to connect  
to, I see no application
using it. As the same time if I go to the command line and use  
minicom I have no issues. The
exception happens with this call:

CommPort commPort = portIdentifier.open(null,0);

Any suggestions?

Andre


From ajmas at sympatico.ca  Sun Jun 18 17:45:11 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 19:45:11 -0400
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
Message-ID: <30245B30-682D-4EAE-8084-8227B719F10D@sympatico.ca>

BTW My code snippet is:

     private InputStream connectToSerial () throws IOException,  
Exception
     {
         InputStream in = null;

         Enumeration portEnum = CommPortIdentifier.getPortIdentifiers();
         while ( portEnum.hasMoreElements() )
         {
             CommPortIdentifier portIdentifier = (CommPortIdentifier)  
portEnum.nextElement();
             System.out.println(portIdentifier.getName() + " - " +  
portIdentifier.getPortType() );
         }

         CommPortIdentifier portIdentifier =  
CommPortIdentifier.getPortIdentifier("/dev/cu.BTGPS-SPPslave-1");
         System.out.println("current owner: " +  
portIdentifier.getCurrentOwner());
         if ( portIdentifier.isCurrentlyOwned() )
         {
             System.out.println("Error: Port is currently in use");
             return null;
         }
         else
         {
             CommPort commPort = portIdentifier.open(this.getClass 
().getName(),2000);

             if ( commPort instanceof SerialPort )
             {
                 SerialPort serialPort = (SerialPort) commPort;
                 serialPort.setSerialPortParams 
(4800,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE 
);
                 in = serialPort.getInputStream();

                 return in;
             }
             else
             {
                 System.out.println("Error: Only serial ports are  
handled.");
             }
         }


         return in;
     }


On 18-Jun-06, at 19:33 , Andr?-John Mas wrote:

> Hi,
>
> I am have a program that I wrote in Java to communicate with a
> Bluetooth GPS device. I am
> trying to get this working on my Mac, but I keep getting told that:
>
> gnu.io.PortInUseException: Unknown Application
>
> but
>
> portIdentifier.isCurrentlyOwned()
>
> returns false and when I do lsof on the device I am trying to connect
> to, I see no application
> using it. As the same time if I go to the command line and use
> minicom I have no issues. The
> exception happens with this call:
>
> CommPort commPort = portIdentifier.open(null,0);
>
> Any suggestions?
>
> Andre
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From joachim at buechse.de  Mon Jun 19 05:54:49 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 13:54:49 +0200
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de>

This is most likely due to a problem with lock files. If you have  
downloaded the binaries of 2.17 rxtx will try to create non-standard  
lock files on OSX. We have since changed the code to use OSX device  
locking - however the binaries have not been updated yet. The 2.18  
release fixing this issue is due shortly.

Regards,
Joachim

On 19.06.2006, at 01:33, Andr?-John Mas wrote:

> Hi,
>
> I am have a program that I wrote in Java to communicate with a
> Bluetooth GPS device. I am
> trying to get this working on my Mac, but I keep getting told that:
>
> gnu.io.PortInUseException: Unknown Application
>
> but
>
> portIdentifier.isCurrentlyOwned()
>
> returns false and when I do lsof on the device I am trying to connect
> to, I see no application
> using it. As the same time if I go to the command line and use
> minicom I have no issues. The
> exception happens with this call:
>
> CommPort commPort = portIdentifier.open(null,0);
>
> Any suggestions?
>
> Andre
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From joachim at buechse.de  Mon Jun 19 06:44:27 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 14:44:27 +0200
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <4490A60A.9090305@sun.com>
References: <4490A60A.9090305@sun.com>
Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>

Hello Paul,

I just downloaded the "generic" javax.comm version now available. A  
first check indicates, that it was compiled with a JDK 1.4 javac  
without setting the target classfile version. In other words in can  
not be loaded by 1.1-1.3 VMs (or PersonalJava).

Do you see any chance to provide a version compiled with classfile  
format 45.3 (ie JVM1.1).

---
52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose  
javax.comm.SerialPort | head -5
Compiled from "SerialPort.java"
public abstract class javax.comm.SerialPort extends javax.comm.CommPort
   SourceFile: "SerialPort.java"
   minor version: 0
   major version: 48
---

Best regards,
Joachim


On 15.06.2006, at 02:12, Paul Klissner wrote:

> Hello RxTx community,
>
> I finally think I have a compromise in place that will stand in the  
> gap.
>
> If you go to http://www.sun.com and search for javax.comm, you'll
> get taken to a download page, where now users can get a copy of the
> comm.jar file out of 2.0.3, along with just a license and a README.
>
> I trust this will suffice until such time as RxTx decided to implement
> their own java classes or we can get a JSR going to mitigate some
> of the problems (the readme in the comm.jar 2.0.3 zip file
> contains my thoughts on that).
>
> Thanks,
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Mon Jun 19 09:11:45 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Mon, 19 Jun 2006 11:11:45 -0400
Subject: [Rxtx] Examples added to Wiki
Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

I have added a couple of examples to the Wiki:

http://rxtx.qbang.org/wiki/index.php/Examples

If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :)

Andre



From paul.klissner at sun.com  Mon Jun 19 10:42:47 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Mon, 19 Jun 2006 09:42:47 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>
References: <4490A60A.9090305@sun.com>
	<03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>
Message-ID: <4496D407.1090609@sun.com>

Joachim Buechse wrote:
> Hello Paul,
> 
> I just downloaded the "generic" javax.comm version now available. A  
> first check indicates, that it was compiled with a JDK 1.4 javac  
> without setting the target classfile version. In other words in can  
> not be loaded by 1.1-1.3 VMs (or PersonalJava).
> 
> Do you see any chance to provide a version compiled with classfile  
> format 45.3 (ie JVM1.1).
> 
> ---
> 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose  
> javax.comm.SerialPort | head -5
> Compiled from "SerialPort.java"
> public abstract class javax.comm.SerialPort extends javax.comm.CommPort
>    SourceFile: "SerialPort.java"
>    minor version: 0
>    major version: 48
> ---

I cannot promise when I can do that. Since we thought we were done
with javax.comm, the build environment got moved around, and right
now it doesn't even compile in it's new home.  I tried and it was
not cooperative at all. I was never impressed with that workspace
(in fact far far from it, it is a mess, which is why I migrated 3.0
to ant and never looked back).  It will take some real determination
for me to rebuild it, and frankly, right now I'm swamped.  If I can
find a bit of time over the next few weeks to do it, and it isn't
too bad an ordeal, I will.

Posting that will give me an excuse to post javax.comm 3.0, Update 2 as
well, while I'm working with the people who put content up on our
download center.  The only reason for a new update to 3.0 is that
I've changed the distribution to provide ispt (Interactive Serial
Port Tool), such that it can be launched as soon as the zip file
is unpacked, via a provided script.  ISPT is a command line
interactive tool for  manipulating one or two serial port,
sending data, managing events, etc... I've found it to be so useful
for doing certain kinds of validation  that I assume others will
find it useful to.  ISPT is already in 3.0u1, but one has to set
up their own classpath and launch it and since few people ever read
the documentation most won't know about it.  I've added the ability
to set stop bits and parity since 3.0u1 too.  But I digress.

Paul


From joachim at buechse.de  Mon Jun 19 11:01:28 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 19:01:28 +0200
Subject: [Rxtx] load mechanism of 2.0x
Message-ID: <CFD1440C-21AA-4D3B-9EA6-270D0FF9D6FC@buechse.de>

Good day,

I am trying to figure out, how the 2.0x distribution interacts with  
Suns implementation of javax.comm.CommPortIdentifier.

1) Apparently one can put javax.comm.properties in {java.home}/lib
2) The javax.comm package also reacts to -Djavax.comm.properties="...."

Looking at the javap output it also seems like CommPortIdentifier  
tries to find it's jar file and load the properties from there??


What I'm really looking for is a solution that allows using  
javax.comm with RXTX without modifying the VM installation. So I  
would prefer not to use 1) but I can't figure out how to use 2).

Any hints are welcome,
Joachim



From bob_tai2001 at yahoo.com  Mon Jun 19 15:00:35 2006
From: bob_tai2001 at yahoo.com (Bob Tai)
Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT)
Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place
	to start?
Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>

Hi, 

I got  rxtx Windows 2000 installed.  I did not use the
"best" way ... I just follow the insturuction and dump
the necessary files into the jre... I know it's "best"
idea, I got lazy didn't want to change my setting to
my Eclipse and classpath.

I was able to modify SimpleWrite.java to print on my
AddMaster serial printer.  I think I am ready to code!
But I need to make sure I can handle exceptions and so
on.  I notice the \samples\NullDriver\  has two files
seems to have some of the require method done, should
I start coding from those file?  I like the idea it
has the "time out" and basic exceptions done.   I am
slowly digging into the samples, but if you think any
of the code from Sun is good to checkout please let me
know.

btw, http://rxtx.qbang.org/wiki/index.php/Examples/
was very helpful, wish there are more examples.

thank you,

    Bob


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Mon Jun 19 15:55:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT)
Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good
 place to start?
In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>
References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606191542260.14139@www>

> I am
> slowly digging into the samples, but if you think any
> of the code from Sun is good to checkout please let me
> know.
>

I think NullDriver.java was an example stub driver for implementing 
something like rxtx.  It has been a while.  Unless they have been updated, 
you will find the examples are very dated.  You can look at how they use 
the port but avoid the GUI and hard coded variables (number of ports for 
instance).

There was no Swing and nobody knew what requirements today's compilers 
would make on code.  The examples worked fine with jdk 1.1 but times have 
changed.

--
Trent Jarvi
tjarvi at qbang.org


From tropicsu at hotmail.com  Mon Jun 19 19:49:08 2006
From: tropicsu at hotmail.com (Yoke K)
Date: Tue, 20 Jun 2006 01:49:08 +0000
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
Message-ID: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>

An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0006.html

From ajmas at sympatico.ca  Mon Jun 19 21:14:37 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Mon, 19 Jun 2006 23:14:37 -0400
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>
References: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>
Message-ID: <CA22AB2A-5712-458B-9984-68477C6042AF@sympatico.ca>

Regarding the PortInUseException, I had a similar issue and got
this response from the mailing list:

   http://mailman.qbang.org/pipermail/rxtx/Week-of- 
Mon-20060619/062838.html

Andre
On 19-Jun-06, at 21:49 , Yoke K wrote:

> Hi Andre, Joachim
>
> I have tried using /dev/tty.usbserial and also /dev/cu.usbserial  
> and it also reported error as  "gnu.io.PortInUseException".
>
> The iTegno modem works in windows environment. As I moving around  
> using my ibook and I need to get it work on MAC OS as well.
>
> >> INFO: SMSLib API for Java / v1.2.2
> >> INFO: Using port: /dev/tty.usbserial @ 115200 baud.
> >> INFO: JRE Version: 1.5.0_06
> >> INFO: JRE Impl Version: 1.5.0_06-64
> >> INFO: O/S: Mac OS X / ppc / 10.4.6
> >> INFO: Using Wavecom (Generic) AT handler.
>
> SendMessage(): Send a message.
> Using SMSLib API for Java v1.2.2
>
> Connecting ..... :
> >> INFO: CSerialDriver(): Connecting...
> Experimental: JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version = RXTX-2.1-7
> >> INFO: CSerialDriver(): Disconnecting...
> gnu.io.PortInUseException: Unknown Application
> at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354)
> at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1)
> at org.smslib.CService.connect(CService.java:197)
> at SendMessage.main(SendMessage.java:38)
>
> Thanks.
>
> - Jon
>
>
>
>
> ====================
>
> Hello Jon,
>
> From OSX's standpoint a symbolic link is not a device (as far as I
> know). What stops you from using tty.usbserial? Did you try hard-
> linking?
>
> Regards,
> Joachim
>
>
>
> From:  "Yoke K" <tropicsu at hotmail.com>
> To:  rxtx at qbang.org
> Subject:  RXTX-2.1-7 / MAC OS X / NoSuchPortException
> Date:  Sat, 17 Jun 2006 15:32:48 +0000
> >Hi,
> >
> >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to
> >work with MAC OS X.
> >I am using iTegno 3000 - USB GPRS Modem.
> >
> >Files in /dev and a symbolic link as follows:
> >
> >crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
> >crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
> >lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->
> >tty.usbserial
> >
> >In my SendMessage.java, I have this line:
> >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
> >
> >Appreciate any help ?
> >
> >- Jon
> >
> >
> >Errors as follows:
> >
> >>>INFO: SMSLib API for Java / v1.2.2
> >>>INFO: Using port: /dev/ttyS1 @ 56000 baud.
> >>>INFO: JRE Version: 1.5.0_06
> >>>INFO: JRE Impl Version: 1.5.0_06-64
> >>>INFO: O/S: Mac OS X / ppc / 10.4.6
> >>>INFO: Using Wavecom (Generic) AT handler.
> >
> >SendMessage(): Send a message.
> >  Using SMSLib API for Java v1.2.2
> >
> >Connecting ..... :
> >>>INFO: CSerialDriver(): Connecting...
> >Experimental:  JNI_OnLoad called.
> >Stable Library
> >=========================================
> >Native lib Version = RXTX-2.1-7
> >Java lib Version   = RXTX-2.1-7
> >>>INFO: CSerialDriver(): Disconnecting...
> >gnu.io.NoSuchPortException
> >        at
> >gnu.io.CommPortIdentifier.getPortIdentifier 
> (CommPortIdentifier.java:218)
> >        at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
> >        at org.smslib.CService.connect(CService.java:197)
> >        at SendMessage.main(SendMessage.java:38)
> >
> >_________________________________________________________________
> >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
> >
>
> Find love online with MSN Personals
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Tue Jun 20 02:35:24 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 10:35:24 +0200
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>

Hello everybody,

I have been fighting a bit with the javax.comm version of RXTX the  
last days. I am working on the README .OSX now and try to figure out  
which should be the "suggested" installation.

The facts:
------

- the "generic" comm.jar version of javax.comm which has been made re- 
available tries to load com.sun.comm.SolarisDriver
- this classname can be overridden ONLY by putting a file  
javax.comm.properties in {java.home}/lib
- if it is not overridden and SolarisDriver.class is not found  
CommPortIdentifier will be disfunctional (in particual it is not  
possible to add CommPort's via CommPortIdentifier.add).
- the license distributed with comm.jar does not allow the  
modification/addition of classes in javax.comm (however no mention of  
com.sun...)


What really bothers me is to suggest putting this config file in the  
"global" vm installation. This is particularly ugly on the Mac as  
there are several VM installations and the file may be forgotten.  
Additionally it may create versioning problems. I prefer an  
installation where all files are local to the application (even  
comm.jar).

In my opinion the ideal situation would be:
------

1) The author of a program compiles against javax.comm.
2a) For platforms supported by Sun the user is free to use the 3.0  
comm.jar download from Sun
2b) For platforms not supported by Sun the user adds RXTXComm.jar to  
the classpath of the application (and librxtxSerial.jnilib to the  
application directory). Also he will need the 2.0.3 generic comm.jar  
from Sun.
3) Nobody messes with the global VM installation.

Of course 2a) and 2b) could be handled by the author of the program  
via an appropriate installer. The author could also decide to always  
use RXTX and include the generic javax.comm classes as well as the  
RXTX classes in his application jar. [If he further uses an explicit  
call to System.load() he may even include the jnilib(s) in the jar,  
extract it (based on the platform name) at runtime to a temp file and  
load it from there.]


Suggested solution:
------

We only need to put the following class in the classpath BEFORE Suns  
comm.jar

   package com.sun.comm;
   public class SolarisDriver extends gnu.io.RXTXCommDriver {
   }

This is not "the pure art" (TM). It depends on an implementation  
detail of the generic driver. However, so does the  
javax.comm.properties file - as we have seen when Sun released 3.0.  
It has the following advantages:

- The "generic" javax.comm implementation will happily load this  
class as its primary driver.
- No javax.comm.properties file is required.
- This does not violate the javax.comm license agreement as there is  
no mention of the "com.sun.comm" package in this license agreement at  
all.
- Authors packaging comm.jar with their application can strip out all  
com.sun.comm classes from comm.jar


Please comment!

Joachim



From joachim at buechse.de  Tue Jun 20 02:50:36 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 10:50:36 +0200
Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar
Message-ID: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>

There has been some discussions about the best way to install RXTX  
and where to place files.

I suggest that,

- we include the native libraries for the most common operating  
systems (in a special version of) RXTXcomm.jar
- we add loader code which tries to extract and load the platform  
specific binary at runtime
- on failure the current mechanism remains as a fallback

Wether the current mechanism should have priority (ie loadLibrary  
before load) remains to be discussed.


The advantages of this solution are
  - users of RXTX do not need to worry about java/platform specific  
file placement.
  - authors of applications may fully merge RXTX into their  
application jar (which provides a double-clickable application for  
Windows and OSX, Linux?).

Please comment,
Joachim

PS: Of course the suggested solution is already possible today,  
however relatively few programmers know how to correctly extract a  
binary resource file via the class loader and load it as a native  
library.


From tjarvi at qbang.org  Tue Jun 20 03:58:12 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT)
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
Message-ID: <Pine.LNX.4.61.0606200335190.14139@www>

> 2a) For platforms supported by Sun the user is free to use the 3.0
> comm.jar download from Sun
> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to
> the classpath of the application (and librxtxSerial.jnilib to the
> application directory). Also he will need the 2.0.3 generic comm.jar
> from Sun.

As there are no plans to support CommAPI 3.0 due to the limitations in its 
implementation mentioned before, I would not recommend projects use Sun's 
3.0 comm.jar.  They will lose the freedom to chose their low level 
implementation by being locked into vendor specific modifications.

Projects should chose between platform neutrality in CommAPI 2.0 and 
reduced platform neutrality in commapi 3.0.  Projects should also strongly 
consider the fact that the 2.0 comm.jar targets only a reduced number of 
JVMs.

Projects can go with rxtx 2.1 or other packages but should probably only 
consider using Sun CommAPI with rxtx if they did so in the past.  They 
should take steps to no longer depend upon this option being available.

> Suggested solution:
> ------
>
> We only need to put the following class in the classpath BEFORE Suns
> comm.jar
>
>   package com.sun.comm;
>   public class SolarisDriver extends gnu.io.RXTXCommDriver {
>   }
>
> This is not "the pure art" (TM). It depends on an implementation
> detail of the generic driver. However, so does the
> javax.comm.properties file - as we have seen when Sun released 3.0.
> It has the following advantages:
>
> - The "generic" javax.comm implementation will happily load this
> class as its primary driver.
> - No javax.comm.properties file is required.
> - This does not violate the javax.comm license agreement as there is
> no mention of the "com.sun.comm" package in this license agreement at
> all.
> - Authors packaging comm.jar with their application can strip out all
> com.sun.comm classes from comm.jar
>

I would not encourage people to place packages in the com.sun.comm 
namespace.  Authors using Sun's commapi 2.0 should just realize it is 
greatly limited in practical utility and consider moving to something that 
isn't being rescued from EOL.

The primary focus of this release is projects previously depending upon 
Sun CommAPI + RXTX.  There are no plans at this time to provide future 
support in this arrangement due to technical incompatabilities we have no 
control over in commapi 3.0 and limited utility of Sun's generic comm.jar 
in commapi 2.0 offered.  Projects should be aware of this so they can make 
appropriate plans.

--
Trent Jarvi
tjarvi at qbang.org


From paul.klissner at sun.com  Tue Jun 20 05:24:00 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Tue, 20 Jun 2006 04:24:00 -0700
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
In-Reply-To: <Pine.LNX.4.61.0606200335190.14139@www>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
	<Pine.LNX.4.61.0606200335190.14139@www>
Message-ID: <4497DAD0.10803@sun.com>

Trent Jarvi wrote:
>> 2a) For platforms supported by Sun the user is free to use the 3.0
>> comm.jar download from Sun
>> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to
>> the classpath of the application (and librxtxSerial.jnilib to the
>> application directory). Also he will need the 2.0.3 generic comm.jar
>> from Sun.
> 
> As there are no plans to support CommAPI 3.0 due to the limitations in its 
> implementation mentioned before, I would not recommend projects use Sun's 
> 3.0 comm.jar.  They will lose the freedom to chose their low level 
> implementation by being locked into vendor specific modifications.
> 
> Projects should chose between platform neutrality in CommAPI 2.0 and 
> reduced platform neutrality in commapi 3.0.  Projects should also strongly 
> consider the fact that the 2.0 comm.jar targets only a reduced number of 
> JVMs.

Well, that's a little ambiguous because the API is the same
either way.  We're talking about Sun's implementation vs.
other implementations.
> 
> Projects can go with rxtx 2.1 or other packages but should probably only 
> consider using Sun CommAPI with rxtx if they did so in the past.  They 
> should take steps to no longer depend upon this option being available.

3.0 is platform centric because there is a need to add some
platform awareness to Sun's implementation, and the choices
for how to do that are limited by the constraints of the API,
as mentioned in the javax.comm 2.0.3 comm.jar download's README.

I am really advocating getting a JSR open (http://www.jcp.org)
to push a new comm API that is more pluggable, platform neutral
and addresses some of the deficiencies of the current API. Then
we can achieve the optimal of platform neutrality while
simulataneously allowing the API to flexibly adapt to
heterogeneous environments.

This is not a question of attitude, this is an issue of resources,
time and commitment.  The current owners of javax.comm within
Sun would like nothing better than to see the ideal reached for
the API and a model that will extend well beyond the foreseeable
future and work for the industry overall.



> 
>> Suggested solution:
>> ------
>>
>> We only need to put the following class in the classpath BEFORE Suns
>> comm.jar
>>
>>   package com.sun.comm;
>>   public class SolarisDriver extends gnu.io.RXTXCommDriver {
>>   }
>>
>> This is not "the pure art" (TM). It depends on an implementation
>> detail of the generic driver. However, so does the
>> javax.comm.properties file - as we have seen when Sun released 3.0.
>> It has the following advantages:
>>
>> - The "generic" javax.comm implementation will happily load this
>> class as its primary driver.
>> - No javax.comm.properties file is required.
>> - This does not violate the javax.comm license agreement as there is
>> no mention of the "com.sun.comm" package in this license agreement at
>> all.
>> - Authors packaging comm.jar with their application can strip out all
>> com.sun.comm classes from comm.jar
>>
> 
> I would not encourage people to place packages in the com.sun.comm 
> namespace.  Authors using Sun's commapi 2.0 should just realize it is 
> greatly limited in practical utility and consider moving to something that 
> isn't being rescued from EOL.
> 
> The primary focus of this release is projects previously depending upon 
> Sun CommAPI + RXTX.  There are no plans at this time to provide future 
> support in this arrangement due to technical incompatabilities we have no 
> control over in commapi 3.0 and limited utility of Sun's generic comm.jar 
> in commapi 2.0 offered.  Projects should be aware of this so they can make 
> appropriate plans.

Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86,
or need the powerful portmapping features in javax.com 3.0, or would like to
acquire the Interactive Serial Port Test utility.

-Paul


From paul.klissner at sun.com  Tue Jun 20 05:33:44 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Tue, 20 Jun 2006 04:33:44 -0700
Subject: [Rxtx] Suggested installation RXTX 2.0x...
In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
Message-ID: <4497DD18.70207@sun.com>

Joachim Buechse wrote:
> Hello everybody,
> 
> I have been fighting a bit with the javax.comm version of RXTX the  
> last days. I am working on the README .OSX now and try to figure out  
> which should be the "suggested" installation.
> 
> The facts:
> ------
> 
> - the "generic" comm.jar version of javax.comm which has been made re- 
> available tries to load com.sun.comm.SolarisDriver
> - this classname can be overridden ONLY by putting a file  
> javax.comm.properties in {java.home}/lib
> - if it is not overridden and SolarisDriver.class is not found  
> CommPortIdentifier will be disfunctional (in particual it is not  
> possible to add CommPort's via CommPortIdentifier.add).
> - the license distributed with comm.jar does not allow the  
> modification/addition of classes in javax.comm (however no mention of  
> com.sun...)
> 
> 
> What really bothers me is to suggest putting this config file in the  
> "global" vm installation. This is particularly ugly on the Mac as  
> there are several VM installations and the file may be forgotten.  
> Additionally it may create versioning problems. I prefer an  
> installation where all files are local to the application (even  
> comm.jar).
> 
> In my opinion the ideal situation would be:
> ------
> 
> 1) The author of a program compiles against javax.comm.
> 2a) For platforms supported by Sun the user is free to use the 3.0  
> comm.jar download from Sun
> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to  
> the classpath of the application (and librxtxSerial.jnilib to the  
> application directory). Also he will need the 2.0.3 generic comm.jar  
> from Sun.
> 3) Nobody messes with the global VM installation.
> 
> Of course 2a) and 2b) could be handled by the author of the program  
> via an appropriate installer. The author could also decide to always  
> use RXTX and include the generic javax.comm classes as well as the  
> RXTX classes in his application jar. [If he further uses an explicit  
> call to System.load() he may even include the jnilib(s) in the jar,  
> extract it (based on the platform name) at runtime to a temp file and  
> load it from there.]
> 

This was how the Sun implementation originated (I did not write
that code).  I completely agree, and I fixed the whole conf file
locating mechanism in 3.0 to avoid the problems youmentioned.
However, I was unaware of how RxTx was using Sun's implementation,
so I didn't architect it in such a way as to avoid namespace pollution
in the native space in for the backend provider.  In retrospect,
I should have done that differently just as a design principle,
but at this point I don't have the spare cycles to get that all
re-factored.  Further, I'm loathe to do it, because the whole
thing will still be an under-the-hood hack due to the constraints
of the API itself.

Paul





From brian at mbari.org  Tue Jun 20 10:23:54 2006
From: brian at mbari.org (Brian Schlining)
Date: Tue, 20 Jun 2006 09:23:54 -0700
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>


Hi Joachim,

> There has been some discussions about the best way to install RXTX
> and where to place files.
>
> I suggest that,
>
> - we include the native libraries for the most common operating
> systems (in a special version of) RXTXcomm.jar
> - we add loader code which tries to extract and load the platform
> specific binary at runtime
> - on failure the current mechanism remains as a fallback

I like your suggestion. However, my understanding is that in general  
the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH  
(Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to  
be loaded by the JVM. The alternative is to point to your native lib  
directory using -Djava.library.path=/my/dir/with/native/libs when you  
launch the JVM. So, I'm very interested to know how you're planning  
to work around this.

> PS: Of course the suggested solution is already possible today,
> however relatively few programmers know how to correctly extract a
> binary resource file via the class loader and load it as a native
> library.

So how do you use it to dynamically load a native lib? I've read that  
you can't really modify the java.library.path after the JVM has been  
launched. (http://forum.java.sun.com/thread.jspa? 
threadID=627890&tstart=90)

Thanks

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0006.html

From joachim at buechse.de  Tue Jun 20 09:20:29 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 17:20:29 +0200
Subject: [Rxtx] 2.0x in sync with 2.1x
Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>

I have added most of the changes from the 2.1 branch to the 2.0 branch.

This includes
  - correction of illegal javadoc comments
  - implementation errors in handling of Thread.interrupt in  
RXTXPort.java
  - MacOS X locking without lock files/special user groups
  - XCode project which builds a universal binary library
  - updated documentation for OSX

I have done some minimal testing (only G4).
[Trent: there are still some changes you made for specific baud  
rates. I will not sync this, as I can not test them. From my  
perspective we are ready for 2.08/2.18]

The updated documentation can be found in the file README.OSX. Here  
it is:

------------------------ Required files -----------------------

To use or compile RXTX 2.0.x you need to downlad the "generic"  
version (2.0.3)
of the javax.comm implementation from Sun. The zip you download  
contains an
archive comm.jar which is required:

- To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar

- To run the app you will need comm.jar in the classpath or in  
{java.lib.path}


------------------------ Installation on MacOSX -----------------------

WARNING: Please read this section until the end.

---
Preparation
---

You may want to spare your users the burden of modifying the global VM
installation. OSX has several different VM versions installed by  
default and
regular users will be unable to figure out which version will load your
application.

If you provide the class

package com.sun.comm;
public class SolarisDriver extends gnu.io.RXTXCommDriver {
}

and make sure, that it is present in the classpath before Suns  
"generic" comm.jar
your users can skip the following step:

Create a file named
    javax.comm.properties
in the directory
    /System/Library/Frameworks/JavaVM.framework/Home/lib/
which contains (only) the following line (no leading space):
    Driver=gnu.io.RXTXCommDriver



----
The unsafe way of using RXTX on OS X:
----

RXTX can be installed by putting the files
   libSerial.jnilib
   RXTXcomm.jar
   comm.jar
into the folder
   /Library/Java/Extensions

This is NOT RECOMMENDED as it creates versioning conflicts among  
applications.
However you may be forced to install it this way if an application  
was written
for Windows or Linux, requires RXTX and you are not able to change  
its starter.


----
The safe way of using RXTX on OS X:
----

Make sure that you have no (older) version of RXTX installed in
   /Library/Java/Extensions
   /System/Library/Java/Extensions
   /usr/lib/java

Put
   libSerial.jnilib
in the directory of the application (the JavaVM will find it there). Add
   RXTXComm.jar
   comm.jar
to the application classpath or include the classes in the  
application jar.
(Some applications already include the RXTX classes in their  
application jar,
in which case only the file libSerial.jnilib is required).


----
History
----

Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation  
of lockfiles
required special permissions for the user executing an application  
based on RXTX.
To simplify the setup RXTX came with an installer modifying group  
permissions
and installing RXTX in the global location /Library/Java/Extensions.  
However
this was prune to versioning conflicts and is no longer recommended.

--------------------- Build instructions for OSX XCode  
-------------------

contributed by Joachim Buechse <joachim at buechse.de>
original version by Dmitry Markman <dmarkman at mac.com>

System requirements for building:
MacOSX 10.4
XCode 2.3

   open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj
   choose libSerial.jnilib target
   build

After the build you will find RXTXcomm.jar and libSerial.jnilib files  
in the
directory build/Development.

In case you can't find RXTXcomm.jar build the RXTXcomm target manually.
In case of (serious) problems feel free to contact joachim at buechse.de .



From tjarvi at qbang.org  Tue Jun 20 22:01:45 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT)
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
Message-ID: <Pine.LNX.4.61.0606202127270.14139@www>

> ---
> Preparation
> ---
>
> You may want to spare your users the burden of modifying the global VM
> installation. OSX has several different VM versions installed by
> default and
> regular users will be unable to figure out which version will load your
> application.
>
> If you provide the class
>
> package com.sun.comm;
> public class SolarisDriver extends gnu.io.RXTXCommDriver {
> }
>
> and make sure, that it is present in the classpath before Suns
> "generic" comm.jar
> your users can skip the following step:

Hi Joachim

With regards to the above, I have not seen that we have Sun's OK to 
promote that.  I'm not very comfortable with the distribution 
documentation advocating this without Sun agreeing.

I see your point but I'd rather not actively promote putting classes in 
Sun's namespace without permission if you don't mind.  This isn't about 
what is in a license.

I'll go through the code tomorrow night.  It was a late night at work 
today.  There is also a w32 fix comming for people opening and closing 
multiple ports.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Wed Jun 21 01:56:45 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 21 Jun 2006 09:56:45 +0200
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <Pine.LNX.4.61.0606202127270.14139@www>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
	<Pine.LNX.4.61.0606202127270.14139@www>
Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>

Hello Trent,

I guess we will not get an explicit OK from Sun for such a hack. I  
think Paul has made it pretty clear, that he does not have the  
resources to modify the 2.x or 3.x code for the needs of RXTX. I'm  
not thrilled but OK with the current API. Hence I dont agree with  
Paul's idea to start a new JSR to fix the implementation - but that's  
mainly because I dont have the time to push it. According to their  
Readme Sun sees no business case in having cross platform support for  
javax.comm - that is sad but it's none of my business. However I  
prefer to program versus javax.comm in my projects as this gives an  
advanced user the chance to exchange the provider without access to  
the code.

I interpret Pauls reponse to my original "Request for comment" as a  
quiet acceptance of the hack I propose (he did respond, but not at  
all to the sun.comm namespace suggestion). This is certainly not  
something we should put into RXTXcomm.jar but hinting a work around  
for implementation errors should be allowed. That's why I've choosen  
the wording "You may want to spare" and "If you provide". The company  
I worked for has choosen similar hacks for years to fix bugs in swing  
for JDK1.1 applications. Those hacks were usually included in their  
own swingpatch.jar.

Having said all that - I do not take it as an insult if you remove  
the paragraph from the Readme. I appreciate that you notified me  
before. It would be interesting to hear some more opinions from the  
list members...

Best regards,
Joachim


On 21.06.2006, at 06:01, Trent Jarvi wrote:

>> ---
>> Preparation
>> ---
>>
>> You may want to spare your users the burden of modifying the  
>> global VM
>> installation. OSX has several different VM versions installed by
>> default and
>> regular users will be unable to figure out which version will load  
>> your
>> application.
>>
>> If you provide the class
>>
>> package com.sun.comm;
>> public class SolarisDriver extends gnu.io.RXTXCommDriver {
>> }
>>
>> and make sure, that it is present in the classpath before Suns
>> "generic" comm.jar
>> your users can skip the following step:
>
> Hi Joachim
>
> With regards to the above, I have not seen that we have Sun's OK to
> promote that.  I'm not very comfortable with the distribution
> documentation advocating this without Sun agreeing.
>
> I see your point but I'd rather not actively promote putting  
> classes in
> Sun's namespace without permission if you don't mind.  This isn't  
> about
> what is in a license.
>
> I'll go through the code tomorrow night.  It was a late night at work
> today.  There is also a w32 fix comming for people opening and closing
> multiple ports.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Wed Jun 21 02:03:33 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 21 Jun 2006 10:03:33 +0200
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
	<6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
Message-ID: <BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>

See System.load(String) [it's also mentioned under the URL you posted].

Regards,
Joachim


On 20.06.2006, at 18:23, Brian Schlining wrote:

> So how do you use it to dynamically load a native lib? I've read  
> that you can't really modify the java.library.path after the JVM  
> has been launched. (http://forum.java.sun.com/thread.jspa? 
> threadID=627890&tstart=90)
>
> Thanks
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From baris.ozkan at elikasu.com.tr  Wed Jun 21 07:58:06 2006
From: baris.ozkan at elikasu.com.tr (Baris)
Date: Wed, 21 Jun 2006 16:58:06 +0300
Subject: [Rxtx] RS 232 ..additional parameters
Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>

Hi,
 
Currently i am developing an application that requires to connect to a
remote rs232 device through  a dialup connection.
 
My problem is that the communication needs several more connection
parameters (i extracted that information from the vendor's dll , listed at
the end of the message)
 
I explored rxtx API and src files and could not find methods to set a
majority  of the parameters.
Am i missing any point or does rxtx is limited to soem standard set of
functionality(e.g. commAPI)? How  is it possible ,if i want to put some
extensions(???) to current rxtx implementation?
 
I am not very good at rs232 programming so excuse me if this message  is
boring one.
 
Thanx
 
Baris Ozkan
 
 
A Listing of Parameters:
 
 
typedef struct _DCB {

DWORD DCBlength; /* sizeof(DCB) */

DWORD BaudRate; /* Baudrate at which running */

DWORD fBinary: 1; /* Binary Mode (skip EOF check) */

DWORD fParity: 1; /* Enable parity checking */

DWORD fOutxCtsFlow:1; /* CTS handshaking on output */

DWORD fOutxDsrFlow:1; /* DSR handshaking on output */

DWORD fDtrControl:2; /* DTR Flow control */

DWORD fDsrSensitivity:1; /* DSR Sensitivity */

DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */

DWORD fOutX: 1; /* Enable output X-ON/X-OFF */

DWORD fInX: 1; /* Enable input X-ON/X-OFF */

DWORD fErrorChar: 1; /* Enable Err Replacement */

DWORD fNull: 1; /* Enable Null stripping */

DWORD fRtsControl:2; /* Rts Flow control */

DWORD fAbortOnError:1; /* Abort all reads and writes on Error */

DWORD fDummy2:17; /* Reserved */

WORD wReserved; /* Not currently used */

WORD XonLim; /* Transmit X-ON threshold */

WORD XoffLim; /* Transmit X-OFF threshold */

BYTE ByteSize; /* Number of bits/byte, 4-8 */

BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */

BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */

char XonChar; /* Tx and Rx X-ON character */

char XoffChar; /* Tx and Rx X-OFF character */

char ErrorChar; /* Error replacement char */

char EofChar; /* End of Input character */

char EvtChar; /* Received Event character */

WORD wReserved1; /* Fill for now. */

} DCB, *LPDCB;

typedef struct _COMMTIMEOUTS {

DWORD ReadIntervalTimeout; /* Maximum time between read chars. */

DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */

DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */

DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */

DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */

} COMMTIMEOUTS,*LPCOMMTIMEOUTS;

dcb.fOutX = FALSE;

dcb.fInX = FALSE;

dcb.fOutxCtsFlow = FALSE;

dcb.fBinary = TRUE;

dcb.fRtsControl = RTS_CONTROL_ENABLE;

SetCommState(hComm , &dcb ); 

COMMTIMEOUTS commTimeOut;

GetCommTimeouts(hComm, &commTimeOut );

commTimeOut.WriteTotalTimeoutMultiplier = 1; 

commTimeOut.WriteTotalTimeoutConstant = 18; 

// commTimeOut.ReadIntervalTimeout = 28; 

commTimeOut.ReadIntervalTimeout = 0; 

// commTimeOut.ReadTotalTimeoutMultiplier = 184; 

commTimeOut.ReadTotalTimeoutMultiplier = 300; 

// commTimeOut.ReadTotalTimeoutConstant = 1200;

commTimeOut.ReadTotalTimeoutConstant = 1200;

SetCommTimeouts(hComm, &commTimeOut);

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0006.html

From ajmas at sympatico.ca  Wed Jun 21 08:14:26 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Wed, 21 Jun 2006 10:14:26 -0400
Subject: [Rxtx] When is 2.18 planned for?
Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

Just curious as to know if there is a target date for 2.18?

Andre



From brian at mbari.org  Wed Jun 21 09:36:00 2006
From: brian at mbari.org (Brian Schlining)
Date: Wed, 21 Jun 2006 08:36:00 -0700
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
	<6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
	<BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>
Message-ID: <A21C9BC0-7894-4B08-AC82-44E11AB3D461@mbari.org>

Ha!!

I suppose I should read my own postings. ;-)

Thanks
B

On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote:

> See System.load(String) [it's also mentioned under the URL you  
> posted].
>
> Regards,
> Joachim
>
>
> On 20.06.2006, at 18:23, Brian Schlining wrote:
>
>> So how do you use it to dynamically load a native lib? I've read
>> that you can't really modify the java.library.path after the JVM
>> has been launched. (http://forum.java.sun.com/thread.jspa?
>> threadID=627890&tstart=90)

Brian Schlining
Software Engineer
http://www.mbari.org




From ajmas at sympatico.ca  Wed Jun 21 16:41:28 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Wed, 21 Jun 2006 18:41:28 -0400
Subject: [Rxtx] CVS build question
Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X:

 The JCL extension to RxTx requires comm.jar
 If you intend to use RxTx for commapi support comm.jar
 needs to be located in  /System/Library/Frameworks/JavaVM.framework/
  Versions/1.5/Home/lib/ext/comm.jar

I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me.

On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native).

Andre






From tjarvi at qbang.org  Wed Jun 21 18:00:04 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT)
Subject: [Rxtx] CVS build question
In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606211756310.14139@www>

On Wed, 21 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> Is the CVS repository meant to build for gnu.io or javax.comm? I ask 
> this, because I see the following when calling ./configure from MacOS X:
>
> The JCL extension to RxTx requires comm.jar
> If you intend to use RxTx for commapi support comm.jar
> needs to be located in  /System/Library/Frameworks/JavaVM.framework/
>  Versions/1.5/Home/lib/ext/comm.jar
>
> I am wanting to build for the gnu.io package, since I want to jump ahead 
> and see if the changes, intended for 2.18 for MacOS X, work for me.
>
> On a side note /Library/Java/Extensions should be included as a valid 
> search path for the JAR, since this is where Apple recommends placing 
> third party extensions (both Java and native).
>

rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel"
rxtx 2.0 src is obtained with "cvs checkout rxtx-devel"

rxtx 2.1 is a complete package in namespace gnu.io
rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 18:02:23 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT)
Subject: [Rxtx] When is 2.18 planned for?
In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606211800180.14139@www>

On Wed, 21 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> Just curious as to know if there is a target date for 2.18?
>

Hi Andre

"When it is ready" :)

Probably this weekend.  Maybe sooner.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 18:10:18 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT)
Subject: [Rxtx] RS 232 ..additional parameters
In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>
References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>
Message-ID: <Pine.LNX.4.61.0606211805010.14139@www>

On Wed, 21 Jun 2006, Baris wrote:

> Hi,
>
> Currently i am developing an application that requires to connect to a
> remote rs232 device through  a dialup connection.
>
> My problem is that the communication needs several more connection
> parameters (i extracted that information from the vendor's dll , listed at
> the end of the message)
>
> I explored rxtx API and src files and could not find methods to set a
> majority  of the parameters.
> Am i missing any point or does rxtx is limited to soem standard set of
> functionality(e.g. commAPI)? How  is it possible ,if i want to put some
> extensions(???) to current rxtx implementation?
>
> I am not very good at rs232 programming so excuse me if this message  is
> boring one.
>
> Thanx
>

Hi Baris

> typedef struct _DCB {
> typedef struct _COMMTIMEOUTS {

These are all handled in termios.c.  It is possible to add extensions to 
rxtx 2.1.  It may well be that the defaults are the same for the variables 
not covered by the existing API.  You can dump the DCB and COMMTIMEOUTS 
from inside termios.c to compare.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 20:23:30 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT)
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
	<Pine.LNX.4.61.0606202127270.14139@www>
	<789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>
Message-ID: <Pine.LNX.4.61.0606212012210.14139@www>

> I'm
> not thrilled but OK with the current API. Hence I dont agree with
> Paul's idea to start a new JSR to fix the implementation - but that's
> mainly because I dont have the time to push it. According to their
> Readme Sun sees no business case in having cross platform support for
> javax.comm - that is sad but it's none of my business. However I
> prefer to program versus javax.comm in my projects as this gives an
> advanced user the chance to exchange the provider without access to
> the code.

Hi Joachim

With regards to the JSR, I think that would be Doug's call.  The effort I 
put in would have to be on my own time which would not be a great deal.  I 
could help things go smoothly but thats not the same as pushing something 
through.

--
Trent Jarvi
tjarvi at qbang.org



From vt at freehold.crocodile.org  Wed Jun 21 21:05:22 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Wed, 21 Jun 2006 20:05:22 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
Message-ID: <449A08F2.3020106@freehold.crocodile.org>

Hello all,

I know this question may belong to JSR lists, but since all interested 
parties are here, I thought I just ask this question here, again...

A while ago I run into a problem and wrote a rant, here: 
http://servomaster.sourceforge.net/dev/serial-usb.html
At the time of writing I didn't think of adding another possible 
solution - changing the CommAPI specs to support removable devices. 
Apparently, Serial/USB bridges are here to stay, and this issue has to 
be addressed.

Wonder if anything changed since, and any abstractions for supporting 
removable devices made it into current or future Java CommAPI drafts - 
Paul, any comments?

--vt



From joachim at buechse.de  Thu Jun 22 01:59:54 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 22 Jun 2006 09:59:54 +0200
Subject: [Rxtx] CVS build question
In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de>

Hello Andre,

I am not sure how well the configure/make mechanism will work on OSX.  
I know that a while ago some contributors tried to get configure/make  
working on OSX but from comments I found in the readmes this work was  
only partially successfull. For compilation on OSX we have used the  
ProjectBuilder/XCode projects you can find in MACOSX_IDE.

Regarding the  ./configure comment:
RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config  
file javax.comm.properties. The later MUST reside in {java.home}/lib.  
As the two only work together putting comm.jar into  /Library/Java/ 
Extensions  and hence making it available to all current and future  
VM installations will only add to confusion.

Regards,
Joachim

On 22.06.2006, at 00:41, Andre-John Mas wrote:

> Hi,
>
> Is the CVS repository meant to build for gnu.io or javax.comm? I  
> ask this, because I see the following when calling ./configure from  
> MacOS X:
>
>  The JCL extension to RxTx requires comm.jar
>  If you intend to use RxTx for commapi support comm.jar
>  needs to be located in  /System/Library/Frameworks/JavaVM.framework/
>   Versions/1.5/Home/lib/ext/comm.jar
>
> I am wanting to build for the gnu.io package, since I want to jump  
> ahead and see if the changes, intended for 2.18 for MacOS X, work  
> for me.
>
> On a side note /Library/Java/Extensions should be included as a  
> valid search path for the JAR, since this is where Apple recommends  
> placing third party extensions (both Java and native).
>
> Andre
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Thu Jun 22 02:51:05 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 22 Jun 2006 10:51:05 +0200
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449A08F2.3020106@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>

Hello Vadim,

I think that your rant is to the point. However it is a bit like  
saying that Windows is at the source of email degradation and the  
only solution is to have users switch to safer operating systems.

I don't see how javax.comm or RXTX can address the problems you  
mention. Of course it would be super cool if javax.comm could magicly  
find the "matching" usb-device and query it's configuration via the  
usb protocol - however this magic (mapping /dev/xyz to its underlying  
USB device) is not supported by any kernel APIs I am aware of. It  
could be supported via POSSIX ioctl calls but then you should address  
your rant to the POSSIX group...

So for the time beeing it's either up to the virtual comm port driver  
to provide a usefull name under /dev/ or to the user choosing the  
right port to use. One example of a smart(er) com port driver is the  
KDDI driver for OSX, which will create device names like "/dev/ 
cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- 
encoded into the bridge chip. The same driver for windows also has  
some options allowing it in theory to recreate the same COMx every  
time a device is plugged/unplugged.

For most industrial applications however it will be up to the user to  
choose the right port (without getting a lot of help doing so).

Probing serial ports can go wrong, that's right. However any serial  
device developper would be well adviced to implement a basic set of  
Hayes AT modem commands (be it a modem or not). Especially AT I0.  
Anyone failing to do so risks that the users favourite TCP/PPP/FAX  
application or stack will kill the device in short time.

Best regards,
Joachim


On 22.06.2006, at 05:05, Vadim Tkachenko wrote:

> Hello all,
>
> I know this question may belong to JSR lists, but since all interested
> parties are here, I thought I just ask this question here, again...
>
> A while ago I run into a problem and wrote a rant, here:
> http://servomaster.sourceforge.net/dev/serial-usb.html
> At the time of writing I didn't think of adding another possible
> solution - changing the CommAPI specs to support removable devices.
> Apparently, Serial/USB bridges are here to stay, and this issue has to
> be addressed.
>
> Wonder if anything changed since, and any abstractions for supporting
> removable devices made it into current or future Java CommAPI drafts -
> Paul, any comments?
>
> --vt
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From vt at freehold.crocodile.org  Thu Jun 22 13:16:03 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 12:16:03 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
Message-ID: <20060622191603.GA17487@freehold.crocodile.org>

Hello Joachim,

> I think that your rant is to the point. However it is a bit like  
> saying that Windows is at the source of email degradation and the  
> only solution is to have users switch to safer operating systems.

I guess the problem is that the rant itself is obsolete and has to be
updated according to latest developments. At the time of writing there
weren't that many bridges around, and the trend didn't manifest itself as it
does now.

> I don't see how javax.comm or RXTX can address the problems you  
> mention.

I would agree that javax.comm won't be able to address the problem, at least
in the short run. As for RxTx - well, nobody prevents it from being a
superset of CommAPI specification, right? RxTx being the de-facto standard
for quite a few platforms, I'd daresay the standard may follow.

> Of course it would be super cool if javax.comm could magicly find the
> "matching" usb-device and query it's configuration via the usb protocol -
> however this magic (mapping /dev/xyz to its underlying USB device) is not
> supported by any kernel APIs I am aware of. It could be supported via
> POSSIX ioctl calls but then you should address your rant to the POSSIX
> group...

As a matter of fact, my bigger concern is addressing the fact that a serial
device can now be removable. This hasn't been the case before, and it
clearly is now. Regarding the above, well, I guess if we accept this fact,
we also need to accept the fact that we need at least rudimentary means of
identification of a serial device. For the USB case, it would usually be the
vendor/product ID, plus possible serial number - but it is irrelevant what
exactly the identifying information is, as long as it allows to identify the
device.

A paradigm shift is required, this is what I wanted to say. Serial devices
can be removed and replaced, it's now our turn to learn to deal with it.

> Joachim

--vt


From jredman at ergotech.com  Thu Jun 22 13:41:44 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 13:41:44 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
Message-ID: <449AF278.6000903@ergotech.com>


Vadim Tkachenko wrote:
> A paradigm shift is required, this is what I wanted to say. Serial devices
> can be removed and replaced, it's now our turn to learn to deal with it.

The removal if the serial port hardly significantly different from the 
removal of the device attached to the serial port.   Different, 
slightly, but not a "paradigm shift".

And yes, someone could unplug a USB serial device and plug it into a 
different USB port so that it has a different name/number, but they 
could do that with the device itself, move it from com1 to com2.

Am I missing something?

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 13:57:27 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 12:57:27 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449AF278.6000903@ergotech.com>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
Message-ID: <20060622195727.GA20247@freehold.crocodile.org>

On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote:
> 
> Vadim Tkachenko wrote:
> > A paradigm shift is required, this is what I wanted to say. Serial devices
> > can be removed and replaced, it's now our turn to learn to deal with it.
> 
> The removal if the serial port hardly significantly different from the 
> removal of the device attached to the serial port.   Different, 
> slightly, but not a "paradigm shift".
> 
> And yes, someone could unplug a USB serial device and plug it into a 
> different USB port so that it has a different name/number, but they 
> could do that with the device itself, move it from com1 to com2.
> 
> Am I missing something?

Yes, the fact that they could unplug a device A and plug a device B. With
the introduction of the concept of removability, the notion of the serial
port itself is not as important anymore, but the notion of the unique device
identifier is.

Consider a situation: long running system (enterprise HVAC, tens of nodes,
tens of thousands square feet area, hundreds of thousand dollars worth of
equipment being conditioned, can't shut down), serial/usb device fails, is
replaced by an identical device with a different serial #.

A little bit farfetched, but hopefully highlighting the point I'm trying to
make.

> Jim

--vt


From jredman at ergotech.com  Thu Jun 22 14:37:38 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 14:37:38 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>	<20060622191603.GA17487@freehold.crocodile.org>	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
Message-ID: <449AFF92.8080003@ergotech.com>


Vadim Tkachenko wrote:
>>
>> Am I missing something?
> 
> Yes, the fact that they could unplug a device A and plug a device B. With
> the introduction of the concept of removability, the notion of the serial
> port itself is not as important anymore, but the notion of the unique device
> identifier is.

Serial devices are always removable.  I could unplug _serial_ device A 
and plug in _serial_ device B.  We have systems running with two RS485 
ports, one talks to a Modbus PLC network one to a number of drives on a 
proprietary protocol.  If you plug the wrong DB9 into the wrong port the 
application doesn't work.

If you dangle a USB 485 converter on the end of the DB9 you've just 
moved the problem from RS485 to USB, but the problem/effect is the same.

> 
> Consider a situation: long running system (enterprise HVAC, tens of nodes,
> tens of thousands square feet area, hundreds of thousand dollars worth of
> equipment being conditioned, can't shut down), serial/usb device fails, is
> replaced by an identical device with a different serial #.
> 
> A little bit farfetched, but hopefully highlighting the point I'm trying to
> make.

Nothing's changed.  If I had a 4 port ISA board and plugged it into my 
new shiny '386 machine.  I could have com ports 9-12.  If I took a board 
off the shelf and didn't set the jumpers, I would have com ports 3-6.

The problem's the same.  If you replace with identical product then the 
com ports  will be the same - no software changes required.  If you 
replace one piece of hardware with hardware from a different 
manufacturer, then the naming/numbering may change.  You're physically 
changing the system, so may reasonably expect to have to make a software 
change.  RXTX actually handles this situation quite well with the -D 
command line option.  (My experience has generally been that the port 
number depends more on the USB port used than the hardware - so the 
chances are even with a hardware change the port number/name will be the 
same.)

Slightly Off Topic - there is a reason why industrial users will pay a 
premium for continued availability of hardware.  Yes you can mail-order 
a $10 USB converter and it will work, but there's no guarantee that the 
next time you buy the same part number from the same vendor it will be 
the same.  The industrial vendors will charge you $100+ for the same 
item, but it will be the same every time you buy it for the next 5 to 10 
years.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 14:37:19 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 13:37:19 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
Message-ID: <20060622203719.GA22521@freehold.crocodile.org>

Hello again,

And while I'm at it, why don't just say this: give me one good reason to
write 3+ different ways of handling removable devices, one for USB, one for
FireWire, one for serial...

I understand very well that this goes way beyond the scope of RxTx and
CommAPI and will require cooperation between them and javax.usb and whatever
JSR is responsible for FireWire implementation - but the end result is well
worth it. Abstract out and generalize arrival/departure/monitoring/discovery
API, provide protocol specific extensions for each, live happily ever after.

--vt


On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote:
> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote:
> > 
> > Vadim Tkachenko wrote:
> > > A paradigm shift is required, this is what I wanted to say. Serial devices
> > > can be removed and replaced, it's now our turn to learn to deal with it.
> > 
> > The removal if the serial port hardly significantly different from the 
> > removal of the device attached to the serial port.   Different, 
> > slightly, but not a "paradigm shift".
> > 
> > And yes, someone could unplug a USB serial device and plug it into a 
> > different USB port so that it has a different name/number, but they 
> > could do that with the device itself, move it from com1 to com2.
> > 
> > Am I missing something?
> 
> Yes, the fact that they could unplug a device A and plug a device B. With
> the introduction of the concept of removability, the notion of the serial
> port itself is not as important anymore, but the notion of the unique device
> identifier is.
> 
> Consider a situation: long running system (enterprise HVAC, tens of nodes,
> tens of thousands square feet area, hundreds of thousand dollars worth of
> equipment being conditioned, can't shut down), serial/usb device fails, is
> replaced by an identical device with a different serial #.
> 
> A little bit farfetched, but hopefully highlighting the point I'm trying to
> make.
> 
> > Jim
> 
> --vt
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx


From jredman at ergotech.com  Thu Jun 22 15:13:49 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 15:13:49 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>	<20060622191603.GA17487@freehold.crocodile.org>	<449AF278.6000903@ergotech.com>	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
Message-ID: <449B080D.9080208@ergotech.com>


Vadim Tkachenko wrote:
> Hello again,
> 
> And while I'm at it, why don't just say this: give me one good reason to
> write 3+ different ways of handling removable devices, one for USB, one for
> FireWire, one for serial...

You don't, they're all the same "I have lost communication with my 
serial device".

The only thing you could really do is improve error reporting by knowing 
the exact sub-system.  ("Device X which is/was attached to USB port Y is 
no longer functioning, please check the USB ports, the device, the 
cables and anything else you can think of that may be a cause of 
failure.")  That just requires an intelligent description of the port.

> I understand very well that this goes way beyond the scope of RxTx and
> CommAPI and will require cooperation between them and javax.usb and whatever
> JSR is responsible for FireWire implementation - but the end result is well
> worth it. Abstract out and generalize arrival/departure/monitoring/discovery
> API, provide protocol specific extensions for each, live happily ever after.

There's a huge list of pseudo-serial devices each with a different set 
of requirements, Bluetooth, RFC 2217, a host of proprietary systems, 
etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I 
have no clue how you'd implement them in a general/cross platform sense.

You haven't convinced me (and only me, others may see something that I 
don't, I'm not speaking for them) that this mechanism can be implemented 
in any practical sense.  That is, that the implementation could be wide 
enough to be consider generally available in RXTX regardless of the 
serial port implementation, platform, etc..  However, if you can come up 
with a general design and a reference implementation for one subsystem, 
I'd like to see it and might get on board.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 15:40:55 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 14:40:55 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449B080D.9080208@ergotech.com>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
Message-ID: <20060622214055.GA25497@freehold.crocodile.org>

On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote:
> 
> Vadim Tkachenko wrote:
> > Hello again,
> > 
> > And while I'm at it, why don't just say this: give me one good reason to
> > write 3+ different ways of handling removable devices, one for USB, one for
> > FireWire, one for serial...
> 
> You don't, they're all the same "I have lost communication with my 
> serial device".

"I have lost communication with my ${protocol} device".

> The only thing you could really do is improve error reporting by knowing 
> the exact sub-system.  ("Device X which is/was attached to USB port Y is 
> no longer functioning, please check the USB ports, the device, the 
> cables and anything else you can think of that may be a cause of 
> failure.")

"Device ${id} which is/was attached to ${protocol} port ${port} is no longer
functioning, please check the ${protocol} ports, the device, the
${protocol_media} and anything else you can think of that may be a cause of
failure".

>  That just requires an intelligent description of the port.

Agree absolutely.

> > I understand very well that this goes way beyond the scope of RxTx and
> > CommAPI and will require cooperation between them and javax.usb and whatever
> > JSR is responsible for FireWire implementation - but the end result is well
> > worth it. Abstract out and generalize arrival/departure/monitoring/discovery
> > API, provide protocol specific extensions for each, live happily ever after.
> 
> There's a huge list of pseudo-serial devices each with a different set 
> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, 
> etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I 
> have no clue how you'd implement them in a general/cross platform sense.

That's because some of the protocols were created decades ago when
autoconfiguration wasn't even conceived, much less practical. RS232/RS485
don't have a clue about identity discovery, and even capabilities discovery
beyond obvious 8N1 etc.

I agree that today all these protocols have generally incompatible
strategies for handling the situations I'm trying to address, but there's
nothing that says it's not an oversight. Besides, we're dealing with the
devices at a level of abstraction that allows some simplifications and
generalizations, at least part of the time - unless it's the protocol
specific features we're dealing with.

> You haven't convinced me (and only me, others may see something that I 
> don't, I'm not speaking for them) that this mechanism can be implemented 
> in any practical sense.  That is, that the implementation could be wide 
> enough to be consider generally available in RXTX regardless of the 
> serial port implementation, platform, etc..  However, if you can come up 
> with a general design and a reference implementation for one subsystem, 
> I'd like to see it and might get on board.

Actually, I wasn't even thinking about all this stuff when I wrote the first
message on the subject :) Now that you mention it - well, I'm not sure I can
chew the piece I just tried to bite in reasonable amount of time.

How do you eat an elephant? One bite at a time. If we could agree that a
small step in the specification is acceptable at this time, and express
further intentions, things may start happening.

To put it succinctly:

- Concept of a "port" should be augmented with a concept of a "device". A
device may be attached to a port in an implicit or explicit way.
- Implicitly connected device is exactly what the current scope of the
specification covers. No new functionality is offered.
- Explicitly connected device supports detachable device semantics, just as
other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a
few).
- The input and output streams are not properties of a port now, but
properties of the device attached to the port.
- A mechanism to allow listening for device arrivals and departures must be
made available.

That's it, off the top of my head.

I understand that this goes completely against current javax.comm specs, but
an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be
difficult to implement without disrupting javax.comm compatibility.

One concern is how to deal with the device identity - but there's no general
way of dealing with this at this time, devices may or may not offer identity
discovery.

> Jim

--vt


From joachim at buechse.de  Fri Jun 23 02:12:43 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 23 Jun 2006 10:12:43 +0200
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
Message-ID: <CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>

Hello++ Vadim,

I would like to repeat that your request is best addressed to the  
POSSIX standardization group - or maybe the BSD/Linux maintainers. If  
you convince the BSD or Linux guys to add this kind of functionality  
(they can as most of there VCP drivers are open source), there is a  
certain chance that other vendors will pick it up. I assure you that  
RXTX will happily provide this functionality once it's possible - I'm  
sure there is more than one maintainer that would love to add it.  
Having this concept penetrate the market may take some years though.

SHORT: The solution you would like to see could be added to the API  
but it can not be implemented (at least not on the platforms I know).  
There are currently no hooks in the kernel that allow you to discover  
"the device" or even the "means of connection" based on an existing  
"device file descriptor" ie COM-port or /dev/... entry. The name  
mapping of the device is handled by the virtual com port driver of  
the device. Unless you are suggesting RXTX should reimplement virtual  
com port drivers for all usb/serial bridges out there your request is  
understandable from a users viewpoint but simply not realizable. It's  
like asking that the Socket api should identify the computer behind  
an IP address (ie by its Ethernet address). While this COULD be  
implemented in TCP/IP, it IS not, and hence there is no point adding  
such a function to the Socket API.

The current trend for USB/Bluetooth/Irda/etc connected devices is  
going away from serial port abstraction towards RPC (ie the drivers  
provide a device specific or device class specific driver that  
provides an application level api to the device functions). The line  
level protocol is often not even published.

Best regards,
Joachim

On 22.06.2006, at 23:40, Vadim Tkachenko wrote:

> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote:
>>
>> Vadim Tkachenko wrote:
>>> Hello again,
>>>
>>> And while I'm at it, why don't just say this: give me one good  
>>> reason to
>>> write 3+ different ways of handling removable devices, one for  
>>> USB, one for
>>> FireWire, one for serial...
>>
>> You don't, they're all the same "I have lost communication with my
>> serial device".
>
> "I have lost communication with my ${protocol} device".
>
>> The only thing you could really do is improve error reporting by  
>> knowing
>> the exact sub-system.  ("Device X which is/was attached to USB  
>> port Y is
>> no longer functioning, please check the USB ports, the device, the
>> cables and anything else you can think of that may be a cause of
>> failure.")
>
> "Device ${id} which is/was attached to ${protocol} port ${port} is  
> no longer
> functioning, please check the ${protocol} ports, the device, the
> ${protocol_media} and anything else you can think of that may be a  
> cause of
> failure".
>
>>  That just requires an intelligent description of the port.
>
> Agree absolutely.
>
>>> I understand very well that this goes way beyond the scope of  
>>> RxTx and
>>> CommAPI and will require cooperation between them and javax.usb  
>>> and whatever
>>> JSR is responsible for FireWire implementation - but the end  
>>> result is well
>>> worth it. Abstract out and generalize arrival/departure/ 
>>> monitoring/discovery
>>> API, provide protocol specific extensions for each, live happily  
>>> ever after.
>>
>> There's a huge list of pseudo-serial devices each with a different  
>> set
>> of requirements, Bluetooth, RFC 2217, a host of proprietary systems,
>> etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I
>> have no clue how you'd implement them in a general/cross platform  
>> sense.
>
> That's because some of the protocols were created decades ago when
> autoconfiguration wasn't even conceived, much less practical. RS232/ 
> RS485
> don't have a clue about identity discovery, and even capabilities  
> discovery
> beyond obvious 8N1 etc.
>
> I agree that today all these protocols have generally incompatible
> strategies for handling the situations I'm trying to address, but  
> there's
> nothing that says it's not an oversight. Besides, we're dealing  
> with the
> devices at a level of abstraction that allows some simplifications and
> generalizations, at least part of the time - unless it's the protocol
> specific features we're dealing with.
>
>> You haven't convinced me (and only me, others may see something  
>> that I
>> don't, I'm not speaking for them) that this mechanism can be  
>> implemented
>> in any practical sense.  That is, that the implementation could be  
>> wide
>> enough to be consider generally available in RXTX regardless of the
>> serial port implementation, platform, etc..  However, if you can  
>> come up
>> with a general design and a reference implementation for one  
>> subsystem,
>> I'd like to see it and might get on board.
>
> Actually, I wasn't even thinking about all this stuff when I wrote  
> the first
> message on the subject :) Now that you mention it - well, I'm not  
> sure I can
> chew the piece I just tried to bite in reasonable amount of time.
>
> How do you eat an elephant? One bite at a time. If we could agree  
> that a
> small step in the specification is acceptable at this time, and  
> express
> further intentions, things may start happening.
>
> To put it succinctly:
>
> - Concept of a "port" should be augmented with a concept of a  
> "device". A
> device may be attached to a port in an implicit or explicit way.
> - Implicitly connected device is exactly what the current scope of the
> specification covers. No new functionality is offered.
> - Explicitly connected device supports detachable device semantics,  
> just as
> other protocols do (USB, FireWire, Wireless USB, Bluetooth, to  
> mention a
> few).
> - The input and output streams are not properties of a port now, but
> properties of the device attached to the port.
> - A mechanism to allow listening for device arrivals and departures  
> must be
> made available.
>
> That's it, off the top of my head.
>
> I understand that this goes completely against current javax.comm  
> specs, but
> an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern )  
> won't be
> difficult to implement without disrupting javax.comm compatibility.
>
> One concern is how to deal with the device identity - but there's  
> no general
> way of dealing with this at this time, devices may or may not offer  
> identity
> discovery.
>
>> Jim
>
> --vt
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From vt at freehold.crocodile.org  Fri Jun 23 11:28:29 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Fri, 23 Jun 2006 10:28:29 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
	<CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
Message-ID: <20060623172829.GA5335@freehold.crocodile.org>

Hello Joachim,

> I would like to repeat that your request is best addressed to the POSSIX
> standardization group - or maybe the BSD/Linux maintainers. If you
> convince the BSD or Linux guys to add this kind of functionality (they can
> as most of there VCP drivers are open source), there is a certain chance
> that other vendors will pick it up. I assure you that RXTX will happily
> provide this functionality once it's possible - I'm sure there is more
> than one maintainer that would love to add it.

I realize this thing is bigger than RxTx itself, and I'm afraid it's too
global not to cause people to laugh before they think about it :)

> Having this concept penetrate the market may take some years though.

Well, I'm sure it'll get there, the only question is - when.

> SHORT: The solution you would like to see could be added to the API but it
> can not be implemented (at least not on the platforms I know).

I guess I'm concerned about the abstraction more than I'm concerned about
the implementation at this point.
  
> There are currently no hooks in the kernel that allow you to discover  
> "the device" or even the "means of connection" based on an existing  
> "device file descriptor" ie COM-port or /dev/... entry.

Well, I'm not so sure you need to keep the literal mapping from /dev
namespace to your device namespace. As long as you can consistently offer a
virtual serial device on top of a virtual serial port, it may be irrelevant
whether you can map it into /dev. The mapping is going be schitzofrenic
anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the
representation...

> The name mapping of the device is handled by the virtual com port driver
> of the device. Unless you are suggesting RXTX should reimplement virtual
> com port drivers for all usb/serial bridges out there your request is
> understandable from a users viewpoint but simply not realizable.

It's not so much a request but rather an offer of participation. I run a few
projects actively using serial communications, as well as USB device
drivers, in different degrees of readiness (Servomaster, Haywire, DIY
Zoning) - and it would be a perfect playground.

You mentioned above that this task is about two things: a) abstraction b)
implementation. I could start the abstraction part of it without changing
the current CommAPI, on top of it, as an adapter. Even if the removable
device semantics are not implemented, but offered, this is already a step
forward.

> It's like asking that the Socket api should identify the computer behind
> an IP address (ie by its Ethernet address). While this COULD be
> implemented in TCP/IP, it IS not, and hence there is no point adding such
> a function to the Socket API.

Thank you for bringing up this example - I guess this is just about the same
thing that I'd like to see. Socket transparently provides you with the
input/output streams, at the same time offering protocol level specifics to
you.

> The current trend for USB/Bluetooth/Irda/etc connected devices is going
> away from serial port abstraction towards RPC (ie the drivers provide a
> device specific or device class specific driver that provides an
> application level api to the device functions). The line level protocol is
> often not even published.

I can't say I'm that happy with it. The best (or, rather, worst) example is
suchlike support for the Phidget servo controller - zealous Linux developers
implemented kernel module support for it, completely hijacking a possibility
of using it on a different level (it's somewhat fixed by now, thankfully).

I believe that whenever an abstraction is offered, it must be made optional
and/or pluggable so it can be replaced by something more suited to the task.

The nature of Java applications is such that they'd probably care much more
about Java API offered, than about no matter how rich application level api
that is offered outside of Java. I've dealt with JNI adapters in the past,
and whereas they can be made reasonably stable, the very fact that you are
forced to deal with things that are not on the critical timing/memory path
and could've been done much easier in Java causes endless grief.

> Joachim

--vt


From lyon at docjava.com  Sat Jun 24 04:54:12 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Sat, 24 Jun 2006 06:54:12 -0400
Subject: [Rxtx] jsr
In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
	<CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
	<20060623172829.GA5335@freehold.crocodile.org>
Message-ID: <p060204a3c0c2c9dde4f8@[192.168.1.152]>

Hi All,
I have had some off-list discussion with Trent.
Opening up a JSR with Sun, as per Peters' suggestion
seems like a reasonable idea, to us.

Does anyone having any concerns about the JSR process
that they would like to raise?

Thanks!
  - Doug



From the.grey.lantern at gmail.com  Sat Jun 24 18:15:26 2006
From: the.grey.lantern at gmail.com (Craig Nicoll)
Date: Sun, 25 Jun 2006 01:15:26 +0100
Subject: [Rxtx] Cannot create virtual serial port
Message-ID: <a1221cc50606241715g2d1e2af6r747347dd4c20e997@mail.gmail.com>

Hello,

This is my first post on this mailing list and I hope someone can help me.

I am having great difficult establishing a virtual serial port for the
Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia
7600.

Every time I try to run the SendMessage program that comes with SMSLib, I
get the following exception: gnu.io.NoSuchPortException

The port names I have tried are:
rfcomm0
rfcomm
/dev/rfcomm0
/dev/rfcomm

This is what I have done so far:
Modified /etc/bluetooth/rfcomm.conf to include the address of my phone:

rfcomm0 {
# Automatically bind the device at startup
bind no;

# Bluetooth address of the device
device 00:0e:6d:7a:98:43;

# RFCOMM channel for the connection
channel 1;

# Description of the connection
comment "Example Bluetooth device";
}

I also tried running the following command: rfcomm bind /dev/rfcomm0

I have searched the mailing list archives and found this post where someone
had a very similar problem to me:
http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried
changing the system properties as suggested and it made no difference.

I have also been scouring Google all day to no avail.

I would be incredibly grateful if anyone could give me some tips.

Thank you,

Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0006.html

From tjarvi at qbang.org  Sun Jun 25 19:56:08 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT)
Subject: [Rxtx] Pending release
Message-ID: <Pine.LNX.4.61.0606251942460.15744@www>


With frustration, I was unable to get to the pending release this weekend.
The release should be comming this next week once things calm down.
The source is in CVS except for a fix for multiple ports in windows.

I had planned on doing the release this weekend but that was disrupted by 
my transportation failing in a spectacular fashion.

--
Trent Jarvi
tjarvi at qbang.org


From Pawan.Kharbanda at dot.state.co.us  Tue Jun 27 22:28:51 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 27 Jun 2006 22:28:51 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>

 Trent, 
   I have an application running in a cluster in linux environment and I
am using RXTX2.1.7 (final) with JDK1.5. The application opens and closes
serial comm ports every 30 seconds and exchanges datas. I have
experienced some of my Comm Ports are left hanging (I can see the
LCK..cufXX lock files under /var/lock folder). On putting the debugs I
found out that, it is stuck at a native call line 809 in RXTXPort.java
class (Please see the code snippet below). Can you help me explain what
this method does in the native code? Am I getting into some thread
deadlocks? Thanks in advance.

Pawan Kharbanda 


public void removeEventListener()
	{
		if (debug)
			z.reportln( "RXTXPort:removeEventListener()
called");
		waitForTheNativeCodeSilly();
		//if( monThread != null && monThread.isAlive() )
		if( monThreadisInterrupted == true )
		{
			z.reportln( "	RXTXPort:removeEventListener()
already interrupted");
			monThread = null;
			SPEventListener = null;
			return;
		}
		else if( monThread != null && monThread.isAlive() )
		{
			if (debug)
				z.reportln( "
RXTXPort:Interrupt=true");
			monThreadisInterrupted=true;
			/*
			   Notify all threads in this PID that something
is up
			   They will call back to see if its their
thread
			   using isInterrupted().
			*/
			if (debug)
				z.reportln( "	RXTXPort:calling
interruptEventLoop");
// LINE 809			interruptEventLoop( ); It never returns
out of this 
			
			if (debug)
				z.reportln( "	RXTXPort:calling
monThread.join()");
			try {
				monThread.join(1000);
			} catch (Exception ex) {
				/* yikes */
				ex.printStackTrace();
			}
			if (debug)
				z.reportln( "	RXTXPort:waiting on
isAlive()");
			while( monThread.isAlive() )
			{
				if ( debug )
					z.reportln( "	MonThread is
still alive!");
				try {
					monThread.join(1000);
					Thread.sleep( 1000 );
				} catch( Exception e ){} 
				//monThread.stop();
			}
			
		}
		if (debug)
			z.reportln( "	RXTXPort:calling gc()");
		monThread = null;
		SPEventListener = null;
		MonitorThreadLock = false;
		MonitorThreadAlive=false;
		monThreadisInterrupted=true;
		z.reportln( "RXTXPort:removeEventListener() returning");
	} 

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Sunday, June 25, 2006 7:56 PM
To: rxtx at qbang.org
Subject: [Rxtx] Pending release


With frustration, I was unable to get to the pending release this
weekend.
The release should be comming this next week once things calm down.
The source is in CVS except for a fix for multiple ports in windows.

I had planned on doing the release this weekend but that was disrupted
by my transportation failing in a spectacular fashion.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Wed Jun 28 04:17:29 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 28 Jun 2006 04:17:29 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606280406330.9561@www>



Hi Pawan

You may have found a deadlock but I've not seen on recently on linux.

If you can, please update from CVS.  This will have some close fixes. 
I'm running with the same code as is in CVS.  It is not perfect but I've 
not seen anything like you mention.  Be sure to set timeouts and 
thresholds on the port.  It may be that the port is waiting on pending io 
that never happens.  I think the CVS patches deal with this also but it 
looks like your in a better test environment to know for sure.

The exploded vehicle mentioned below is expected to be fixed today.  It 
was just a ninja small radiator hose.  The pressure test afterwards 
created its own set of problems.  Until this is resolved, I'm spending 
most of my free time commuting by bicycle.

On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>   I have an application running in a cluster in linux environment and I
> am using RXTX2.1.7 (final) with JDK1.5. The application opens and closes
> serial comm ports every 30 seconds and exchanges datas. I have
> experienced some of my Comm Ports are left hanging (I can see the
> LCK..cufXX lock files under /var/lock folder). On putting the debugs I
> found out that, it is stuck at a native call line 809 in RXTXPort.java
> class (Please see the code snippet below). Can you help me explain what
> this method does in the native code? Am I getting into some thread
> deadlocks? Thanks in advance.
>
> Pawan Kharbanda
>
>
> public void removeEventListener()
> 	{
> 		if (debug)
> 			z.reportln( "RXTXPort:removeEventListener()
> called");
> 		waitForTheNativeCodeSilly();
> 		//if( monThread != null && monThread.isAlive() )
> 		if( monThreadisInterrupted == true )
> 		{
> 			z.reportln( "	RXTXPort:removeEventListener()
> already interrupted");
> 			monThread = null;
> 			SPEventListener = null;
> 			return;
> 		}
> 		else if( monThread != null && monThread.isAlive() )
> 		{
> 			if (debug)
> 				z.reportln( "
> RXTXPort:Interrupt=true");
> 			monThreadisInterrupted=true;
> 			/*
> 			   Notify all threads in this PID that something
> is up
> 			   They will call back to see if its their
> thread
> 			   using isInterrupted().
> 			*/
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> interruptEventLoop");
> // LINE 809			interruptEventLoop( ); It never returns
> out of this
>
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> monThread.join()");
> 			try {
> 				monThread.join(1000);
> 			} catch (Exception ex) {
> 				/* yikes */
> 				ex.printStackTrace();
> 			}
> 			if (debug)
> 				z.reportln( "	RXTXPort:waiting on
> isAlive()");
> 			while( monThread.isAlive() )
> 			{
> 				if ( debug )
> 					z.reportln( "	MonThread is
> still alive!");
> 				try {
> 					monThread.join(1000);
> 					Thread.sleep( 1000 );
> 				} catch( Exception e ){}
> 				//monThread.stop();
> 			}
>
> 		}
> 		if (debug)
> 			z.reportln( "	RXTXPort:calling gc()");
> 		monThread = null;
> 		SPEventListener = null;
> 		MonitorThreadLock = false;
> 		MonitorThreadAlive=false;
> 		monThreadisInterrupted=true;
> 		z.reportln( "RXTXPort:removeEventListener() returning");
> 	}
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Sunday, June 25, 2006 7:56 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] Pending release
>
>
> With frustration, I was unable to get to the pending release this
> weekend.
> The release should be comming this next week once things calm down.
> The source is in CVS except for a fix for multiple ports in windows.
>
> I had planned on doing the release this weekend but that was disrupted
> by my transportation failing in a spectacular fashion.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From Pawan.Kharbanda at dot.state.co.us  Wed Jun 28 12:11:06 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Wed, 28 Jun 2006 12:11:06 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>

Trent,
    Again thanks for the reply. First of all I have Receive timeouts set
on all communications including Max no of bytes to expect during the
call. I have noticed the problem is during "closing the connection". I
am not sure if the RXTX is 100% thread-safe yet. There seems to be a
glitch in the native calls. I am sure I have the latest code I did the
update on the Version 2.1.7 from CVS, is this where the latest updates
are located, I have noticed another version in CVS "rxtx-devel".

Regards
Pawan Kharbanda

    

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Wednesday, June 28, 2006 4:17 AM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports



Hi Pawan

You may have found a deadlock but I've not seen on recently on linux.

If you can, please update from CVS.  This will have some close fixes. 
I'm running with the same code as is in CVS.  It is not perfect but I've
not seen anything like you mention.  Be sure to set timeouts and
thresholds on the port.  It may be that the port is waiting on pending
io that never happens.  I think the CVS patches deal with this also but
it looks like your in a better test environment to know for sure.

The exploded vehicle mentioned below is expected to be fixed today.  It
was just a ninja small radiator hose.  The pressure test afterwards
created its own set of problems.  Until this is resolved, I'm spending
most of my free time commuting by bicycle.

On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>   I have an application running in a cluster in linux environment and 
> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and 
> closes serial comm ports every 30 seconds and exchanges datas. I have 
> experienced some of my Comm Ports are left hanging (I can see the 
> LCK..cufXX lock files under /var/lock folder). On putting the debugs I

> found out that, it is stuck at a native call line 809 in RXTXPort.java

> class (Please see the code snippet below). Can you help me explain 
> what this method does in the native code? Am I getting into some 
> thread deadlocks? Thanks in advance.
>
> Pawan Kharbanda
>
>
> public void removeEventListener()
> 	{
> 		if (debug)
> 			z.reportln( "RXTXPort:removeEventListener()
called");
> 		waitForTheNativeCodeSilly();
> 		//if( monThread != null && monThread.isAlive() )
> 		if( monThreadisInterrupted == true )
> 		{
> 			z.reportln( "	RXTXPort:removeEventListener()
> already interrupted");
> 			monThread = null;
> 			SPEventListener = null;
> 			return;
> 		}
> 		else if( monThread != null && monThread.isAlive() )
> 		{
> 			if (debug)
> 				z.reportln( "
> RXTXPort:Interrupt=true");
> 			monThreadisInterrupted=true;
> 			/*
> 			   Notify all threads in this PID that something
is up
> 			   They will call back to see if its their
thread
> 			   using isInterrupted().
> 			*/
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> interruptEventLoop");
> // LINE 809			interruptEventLoop( ); It never returns
> out of this
>
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> monThread.join()");
> 			try {
> 				monThread.join(1000);
> 			} catch (Exception ex) {
> 				/* yikes */
> 				ex.printStackTrace();
> 			}
> 			if (debug)
> 				z.reportln( "	RXTXPort:waiting on
> isAlive()");
> 			while( monThread.isAlive() )
> 			{
> 				if ( debug )
> 					z.reportln( "	MonThread is
> still alive!");
> 				try {
> 					monThread.join(1000);
> 					Thread.sleep( 1000 );
> 				} catch( Exception e ){}
> 				//monThread.stop();
> 			}
>
> 		}
> 		if (debug)
> 			z.reportln( "	RXTXPort:calling gc()");
> 		monThread = null;
> 		SPEventListener = null;
> 		MonitorThreadLock = false;
> 		MonitorThreadAlive=false;
> 		monThreadisInterrupted=true;
> 		z.reportln( "RXTXPort:removeEventListener() returning");
> 	}
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf

> Of Trent Jarvi
> Sent: Sunday, June 25, 2006 7:56 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] Pending release
>
>
> With frustration, I was unable to get to the pending release this 
> weekend.
> The release should be comming this next week once things calm down.
> The source is in CVS except for a fix for multiple ports in windows.
>
> I had planned on doing the release this weekend but that was disrupted

> by my transportation failing in a spectacular fashion.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Wed Jun 28 12:26:21 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 28 Jun 2006 12:26:21 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606281222420.9561@www>


Hi Pawan

If you did a cvs update from the 2.1-7 tar ball, you have the current 
version.  All rxtx in CVS is under rxtx-devel.  The 2.1-7 just has -r
commapi-0-0-1.

You may well have found something.  I have seen win32 fail on closing 
ports but not linux that I can think of.  Your use is much different than 
I normally see too.

Could you give us more information on how we would reproduce this and the 
frequency?


On Wed, 28 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>    Again thanks for the reply. First of all I have Receive timeouts set
> on all communications including Max no of bytes to expect during the
> call. I have noticed the problem is during "closing the connection". I
> am not sure if the RXTX is 100% thread-safe yet. There seems to be a
> glitch in the native calls. I am sure I have the latest code I did the
> update on the Version 2.1.7 from CVS, is this where the latest updates
> are located, I have noticed another version in CVS "rxtx-devel".
>
> Regards
> Pawan Kharbanda
>
>
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Wednesday, June 28, 2006 4:17 AM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] Locked Ports
>
>
>
> Hi Pawan
>
> You may have found a deadlock but I've not seen on recently on linux.
>
> If you can, please update from CVS.  This will have some close fixes.
> I'm running with the same code as is in CVS.  It is not perfect but I've
> not seen anything like you mention.  Be sure to set timeouts and
> thresholds on the port.  It may be that the port is waiting on pending
> io that never happens.  I think the CVS patches deal with this also but
> it looks like your in a better test environment to know for sure.
>
> The exploded vehicle mentioned below is expected to be fixed today.  It
> was just a ninja small radiator hose.  The pressure test afterwards
> created its own set of problems.  Until this is resolved, I'm spending
> most of my free time commuting by bicycle.
>
> On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:
>
>> Trent,
>>   I have an application running in a cluster in linux environment and
>> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and
>> closes serial comm ports every 30 seconds and exchanges datas. I have
>> experienced some of my Comm Ports are left hanging (I can see the
>> LCK..cufXX lock files under /var/lock folder). On putting the debugs I
>
>> found out that, it is stuck at a native call line 809 in RXTXPort.java
>
>> class (Please see the code snippet below). Can you help me explain
>> what this method does in the native code? Am I getting into some
>> thread deadlocks? Thanks in advance.
>>
>> Pawan Kharbanda
>>
>>
>> public void removeEventListener()
>> 	{
>> 		if (debug)
>> 			z.reportln( "RXTXPort:removeEventListener()
> called");
>> 		waitForTheNativeCodeSilly();
>> 		//if( monThread != null && monThread.isAlive() )
>> 		if( monThreadisInterrupted == true )
>> 		{
>> 			z.reportln( "	RXTXPort:removeEventListener()
>> already interrupted");
>> 			monThread = null;
>> 			SPEventListener = null;
>> 			return;
>> 		}
>> 		else if( monThread != null && monThread.isAlive() )
>> 		{
>> 			if (debug)
>> 				z.reportln( "
>> RXTXPort:Interrupt=true");
>> 			monThreadisInterrupted=true;
>> 			/*
>> 			   Notify all threads in this PID that something
> is up
>> 			   They will call back to see if its their
> thread
>> 			   using isInterrupted().
>> 			*/
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> interruptEventLoop");
>> // LINE 809			interruptEventLoop( ); It never returns
>> out of this
>>
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> monThread.join()");
>> 			try {
>> 				monThread.join(1000);
>> 			} catch (Exception ex) {
>> 				/* yikes */
>> 				ex.printStackTrace();
>> 			}
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:waiting on
>> isAlive()");
>> 			while( monThread.isAlive() )
>> 			{
>> 				if ( debug )
>> 					z.reportln( "	MonThread is
>> still alive!");
>> 				try {
>> 					monThread.join(1000);
>> 					Thread.sleep( 1000 );
>> 				} catch( Exception e ){}
>> 				//monThread.stop();
>> 			}
>>
>> 		}
>> 		if (debug)
>> 			z.reportln( "	RXTXPort:calling gc()");
>> 		monThread = null;
>> 		SPEventListener = null;
>> 		MonitorThreadLock = false;
>> 		MonitorThreadAlive=false;
>> 		monThreadisInterrupted=true;
>> 		z.reportln( "RXTXPort:removeEventListener() returning");
>> 	}
>>
>> -----Original Message-----
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
>
>> Of Trent Jarvi
>> Sent: Sunday, June 25, 2006 7:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] Pending release
>>
>>
>> With frustration, I was unable to get to the pending release this
>> weekend.
>> The release should be comming this next week once things calm down.
>> The source is in CVS except for a fix for multiple ports in windows.
>>
>> I had planned on doing the release this weekend but that was disrupted
>
>> by my transportation failing in a spectacular fashion.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From Pawan.Kharbanda at dot.state.co.us  Wed Jun 28 15:42:49 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Wed, 28 Jun 2006 15:42:49 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>

Trent,
    I will try to explain how I am setup and will try to write you a
Sample code little later to reproduce this. On our system we have
DigiBoxes installed on the 2 Linux servers. Both of them have RXTX2.1-7
version installed with the JRE(1.5) and both the machines have the same
port mappings in gnu.io.rxtx.properties (Currently in the production
system I have 64 ports). This is how the system works:

1) A thick Map based client initiates a Action on the Device on the
field. One of the Thread Workers(Asynchronous Call) in the Cluster picks
up the request. 
2) Once the worker gets the request it locks the Device and
Communication port in the DB's(These are our persistent locks, because
most of the devices do one to one communication with the serial ports).
After that the worker (or Comm Server) opens up the connection and after
exchanging the information calls the "Close" and returns.
3) Once the connection is closed , the DB lock is removed on the comm
port and is made available to accept future calls. Here is where the
glitch is the Serial Comm Close method never returns due to the
deadlock. 

I have noticed that the deadlocks are very inconsistent, sometime it
happens right away as soon as Application server starts and sometimes I
don't see any deadlocks for days, but it happens for sure. 

Here is how you can test if you have resources/ test environment. Write
a program and try to open/close  different ports(I will say have a
minimum of four) randomly and very frequently(may be 30 seconds), I am
pretty sure you will see the deadlocks and it happens in the native call
to interrptEventLoop in RXTXPort.java in removeEventListener() method
call.

Also I have noticed that the JVM carshes (without any memrory errors or
JVM errors. Its just not there) when native call is made to eventLoop()
in run() method in MonitorThread inner class. I am still investigating
why this is happening, but at this point I can just tell you the
location. You might have a question How I am so sure about the location?
My application is configured with Log4J and I have enabled the debugs on
the RXTXPort.java, so every time my JVM dies I see these logs at the end
of the file.

"2006-06-28 15:27:15,183 INFO  [STDOUT] RXTXPort:RXTXPort(/dev/cub01)
called
2006-06-28 15:27:15,218 INFO  [STDOUT]
RXTXPort:MontitorThread:MonitorThread()
2006-06-28 15:27:15,219 INFO  [STDOUT] RXTXPort:MontitorThread:run()"

I surely do have a luxury of a testing environment(ports, devices etc.)
and can help you fix these problems? Please advise me how we can resolve
these issues.

Thanks 
Pawan Kharbanda
303-478-2991





-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Wednesday, June 28, 2006 12:26 PM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports


Hi Pawan

If you did a cvs update from the 2.1-7 tar ball, you have the current
version.  All rxtx in CVS is under rxtx-devel.  The 2.1-7 just has -r
commapi-0-0-1.

You may well have found something.  I have seen win32 fail on closing
ports but not linux that I can think of.  Your use is much different
than I normally see too.

Could you give us more information on how we would reproduce this and
the frequency?


On Wed, 28 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>    Again thanks for the reply. First of all I have Receive timeouts
set
> on all communications including Max no of bytes to expect during the
> call. I have noticed the problem is during "closing the connection". I
> am not sure if the RXTX is 100% thread-safe yet. There seems to be a
> glitch in the native calls. I am sure I have the latest code I did the
> update on the Version 2.1.7 from CVS, is this where the latest updates
> are located, I have noticed another version in CVS "rxtx-devel".
>
> Regards
> Pawan Kharbanda
>
>
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Wednesday, June 28, 2006 4:17 AM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] Locked Ports
>
>
>
> Hi Pawan
>
> You may have found a deadlock but I've not seen on recently on linux.
>
> If you can, please update from CVS.  This will have some close fixes.
> I'm running with the same code as is in CVS.  It is not perfect but
I've
> not seen anything like you mention.  Be sure to set timeouts and
> thresholds on the port.  It may be that the port is waiting on pending
> io that never happens.  I think the CVS patches deal with this also
but
> it looks like your in a better test environment to know for sure.
>
> The exploded vehicle mentioned below is expected to be fixed today.
It
> was just a ninja small radiator hose.  The pressure test afterwards
> created its own set of problems.  Until this is resolved, I'm spending
> most of my free time commuting by bicycle.
>
> On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:
>
>> Trent,
>>   I have an application running in a cluster in linux environment and
>> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and
>> closes serial comm ports every 30 seconds and exchanges datas. I have
>> experienced some of my Comm Ports are left hanging (I can see the
>> LCK..cufXX lock files under /var/lock folder). On putting the debugs
I
>
>> found out that, it is stuck at a native call line 809 in
RXTXPort.java
>
>> class (Please see the code snippet below). Can you help me explain
>> what this method does in the native code? Am I getting into some
>> thread deadlocks? Thanks in advance.
>>
>> Pawan Kharbanda
>>
>>
>> public void removeEventListener()
>> 	{
>> 		if (debug)
>> 			z.reportln( "RXTXPort:removeEventListener()
> called");
>> 		waitForTheNativeCodeSilly();
>> 		//if( monThread != null && monThread.isAlive() )
>> 		if( monThreadisInterrupted == true )
>> 		{
>> 			z.reportln( "	RXTXPort:removeEventListener()
>> already interrupted");
>> 			monThread = null;
>> 			SPEventListener = null;
>> 			return;
>> 		}
>> 		else if( monThread != null && monThread.isAlive() )
>> 		{
>> 			if (debug)
>> 				z.reportln( "
>> RXTXPort:Interrupt=true");
>> 			monThreadisInterrupted=true;
>> 			/*
>> 			   Notify all threads in this PID that something
> is up
>> 			   They will call back to see if its their
> thread
>> 			   using isInterrupted().
>> 			*/
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> interruptEventLoop");
>> // LINE 809			interruptEventLoop( ); It never returns
>> out of this
>>
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> monThread.join()");
>> 			try {
>> 				monThread.join(1000);
>> 			} catch (Exception ex) {
>> 				/* yikes */
>> 				ex.printStackTrace();
>> 			}
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:waiting on
>> isAlive()");
>> 			while( monThread.isAlive() )
>> 			{
>> 				if ( debug )
>> 					z.reportln( "	MonThread is
>> still alive!");
>> 				try {
>> 					monThread.join(1000);
>> 					Thread.sleep( 1000 );
>> 				} catch( Exception e ){}
>> 				//monThread.stop();
>> 			}
>>
>> 		}
>> 		if (debug)
>> 			z.reportln( "	RXTXPort:calling gc()");
>> 		monThread = null;
>> 		SPEventListener = null;
>> 		MonitorThreadLock = false;
>> 		MonitorThreadAlive=false;
>> 		monThreadisInterrupted=true;
>> 		z.reportln( "RXTXPort:removeEventListener() returning");
>> 	}
>>
>> -----Original Message-----
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On
Behalf
>
>> Of Trent Jarvi
>> Sent: Sunday, June 25, 2006 7:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] Pending release
>>
>>
>> With frustration, I was unable to get to the pending release this
>> weekend.
>> The release should be comming this next week once things calm down.
>> The source is in CVS except for a fix for multiple ports in windows.
>>
>> I had planned on doing the release this weekend but that was
disrupted
>
>> by my transportation failing in a spectacular fashion.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx 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 khattar31 at yahoo.com  Wed Jun 28 22:04:59 2006
From: khattar31 at yahoo.com (rahul khattar)
Date: Wed, 28 Jun 2006 21:04:59 -0700 (PDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
Message-ID: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>

Hi All,

I was looking at the src file on the last release.
I did notice a missing header file while trying to
compile the parallelport.dll. Would somebody be kind
enoughf to share the missing header file:
gnu_io_LPRPort.h

I am using MinGw to compile the same from Parinya
(which is an execellent tool)


Regards,
Rahul Khattar

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Thu Jun 29 03:43:53 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 03:43:53 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>
References: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606290341210.9561@www>

On Wed, 28 Jun 2006, rahul khattar wrote:

> Hi All,
>
> I was looking at the src file on the last release.
> I did notice a missing header file while trying to
> compile the parallelport.dll. Would somebody be kind
> enoughf to share the missing header file:
> gnu_io_LPRPort.h
>
> I am using MinGw to compile the same from Parinya
> (which is an execellent tool)
>

Hi Rahul

The gnu.io_LPRPort.h file is generated with javah.  You can see the 
command in the Makefile I presume.  You do not need rxtxParallel.dll to 
use w32 serial btw.

--
Trent Jarvi
tjarvi at qbang.org


From khattar31 at yahoo.com  Thu Jun 29 04:47:01 2006
From: khattar31 at yahoo.com (rahul khattar)
Date: Thu, 29 Jun 2006 03:47:01 -0700 (PDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606290341210.9561@www>
Message-ID: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>

Hi Trent 
I did notice this file is required in the source file
ParallelImp.c
on line 38

Attached the O/P 

Regards,
Rahul Khattar




--- Trent Jarvi <tjarvi at qbang.org> wrote:

> On Wed, 28 Jun 2006, rahul khattar wrote:
> 
> > Hi All,
> >
> > I was looking at the src file on the last release.
> > I did notice a missing header file while trying to
> > compile the parallelport.dll. Would somebody be
> kind
> > enoughf to share the missing header file:
> > gnu_io_LPRPort.h
> >
> > I am using MinGw to compile the same from Parinya
> > (which is an execellent tool)
> >
> 
> Hi Rahul
> 
> The gnu.io_LPRPort.h file is generated with javah. 
> You can see the 
> command in the Makefile I presume.  You do not need
> rxtxParallel.dll to 
> use w32 serial btw.
> 
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Error.zip
Type: application/x-zip-compressed
Size: 1746 bytes
Desc: 2948039066-Error.zip
Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060629/a5b6f783/Error-0006.bin

From tjarvi at qbang.org  Thu Jun 29 06:16:24 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 06:16:24 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606290614530.9561@www>

On Thu, 29 Jun 2006, rahul khattar wrote:

> Hi Trent
> I did notice this file is required in the source file
> ParallelImp.c
> on line 38
>
> Attached the O/P
>

The command to generate the .h file will be something like:

javah -classpath . -jni gnu.io.LPRPort

The makefile should have this.  There are several approaches to creating 
or using makefiles so I have no idea which one you used if any.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Thu Jun 29 06:20:51 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 06:20:51 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606290616420.9561@www>

> Here is how you can test if you have resources/ test environment. Write
> a program and try to open/close  different ports(I will say have a
> minimum of four) randomly and very frequently(may be 30 seconds), I am
> pretty sure you will see the deadlocks and it happens in the native call
> to interrptEventLoop in RXTXPort.java in removeEventListener() method
> call.

Hi Pawan

I'll try to find a way to reproduce this.  One thing to note is that you 
are using different kernel drivers (digi) to perform this task.  So I 
probably will not be able to reproduce the exact same environment.

In general, multiport kernel drivers have been tested far less than 
typical serial drivers.  This may or may not be an issue.

--
Trent Jarvi
tjarvi at qbang.org



From jhaysonn at gmail.com  Thu Jun 29 12:29:13 2006
From: jhaysonn at gmail.com (jhaysonn pathak)
Date: Thu, 29 Jun 2006 14:29:13 -0400
Subject: [Rxtx] RXTX install
Message-ID: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>

Hi Guys,

I'm doing trying to write a generative piece of Sonic Art using an EEG
plugged into a mac runnning Max/MSP.  I just recently discovered RXTX
drivers in my search for a piece of software that might give me more
output options for my EEG (I'm using the CEO from MindPeak).  I found
Bioera which uses RXTX drivers.  Thing is - I can't figure out how to
install RXTX correctly.

After I build the 'libSerial.jnilib' target inside of
'LibSerial.pbproj' I can't find the libSerial.jnilib file that
accompanies the RXTXcomm.jar nor do I know where to put them.

I also don't understand this part at the bottom of the OS X instructions at all:

"AFTER INSTALLATION VERY IMPORTANT
	check existence of the folder /var/spool/uucp
	if you don't have it create it with command
	sudo mkdir /var/spool/uucp
	permissions should be: drwxrwxr-x
	if they are not do command
	sudo chmod 775 /var/spool/uucp

	YOU should be a member of the uucp group
	you can check it with command
		niutil -readprop / /groups/uucp users
	you should see your name in output of the niutil command
	if you don't do following:
		sudo niutil -appendprop / /groups/uucp users <yourname>
			substitute  <yourname> with your user's name
			for example if your user name is peter:
				sudo niutil -appendprop / /groups/uucp users peter

	NOTES: RXTX.pkg should create uucp folder and insert your name  in
uucp group automatically"



I really appreciate any help that you guys can offer.  I've been
struggling with this for a while now as part of a research grant that
I was awarded.  Thanks again for the help.

Jhaysonn Pathak


From naranjo.manuel at gmail.com  Thu Jun 29 07:19:15 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 10:19:15 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606290614530.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www>
Message-ID: <44A3D353.6010605@gmail.com>

Speaking about Windows Support, I had seen that inside the 
rxtx-2.1-7-bins-r2 package inside Windows directory it says:
"i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will 
not make harm to anyone, and i'm almost sure that someone has noticed it 
before.
Cheers,
Manuel


From joachim at buechse.de  Thu Jun 29 13:25:16 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 29 Jun 2006 21:25:16 +0200
Subject: [Rxtx] RXTX install
In-Reply-To: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>
References: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>
Message-ID: <2A003E42-97E1-4237-8438-646BDE2E3961@buechse.de>

Hello Jhaysonn,

I assume you are trying to use the javax.comm version of RXTX.

Please use "cvs up" to update your download to the latest version of  
the repository. The latest version does not use lock files, so the  
mentioned process is no longer needed. Updating with CVS will also  
provide you with a new README.OSX file that should be simpler to  
understand.

You will find LibSerialUniversal.xcodeproj in MACOSX_IDE/Xcode. Put  
comm.jar (downloaded from Sun) into MACOSX_IDE/Xcode. Compile the  
library. You will find RXTXcomm.jar and librxtxSerial.jnilib in  
MACOSX_IDE/Xcode/build/Default

Best regards,
Joachim
---
Joachim B?chse
Softwarel?sungen und Beratung
Hadlaubsteig 2
CH-8006 Z?rich


On 29.06.2006, at 20:29, jhaysonn pathak wrote:

> Hi Guys,
>
> I'm doing trying to write a generative piece of Sonic Art using an EEG
> plugged into a mac runnning Max/MSP.  I just recently discovered RXTX
> drivers in my search for a piece of software that might give me more
> output options for my EEG (I'm using the CEO from MindPeak).  I found
> Bioera which uses RXTX drivers.  Thing is - I can't figure out how to
> install RXTX correctly.
>
> After I build the 'libSerial.jnilib' target inside of
> 'LibSerial.pbproj' I can't find the libSerial.jnilib file that
> accompanies the RXTXcomm.jar nor do I know where to put them.
>
> I also don't understand this part at the bottom of the OS X  
> instructions at all:
>
> "AFTER INSTALLATION VERY IMPORTANT
> 	check existence of the folder /var/spool/uucp
> 	if you don't have it create it with command
> 	sudo mkdir /var/spool/uucp
> 	permissions should be: drwxrwxr-x
> 	if they are not do command
> 	sudo chmod 775 /var/spool/uucp
>
> 	YOU should be a member of the uucp group
> 	you can check it with command
> 		niutil -readprop / /groups/uucp users
> 	you should see your name in output of the niutil command
> 	if you don't do following:
> 		sudo niutil -appendprop / /groups/uucp users <yourname>
> 			substitute  <yourname> with your user's name
> 			for example if your user name is peter:
> 				sudo niutil -appendprop / /groups/uucp users peter
>
> 	NOTES: RXTX.pkg should create uucp folder and insert your name  in
> uucp group automatically"
>
>
>
> I really appreciate any help that you guys can offer.  I've been
> struggling with this for a while now as part of a research grant that
> I was awarded.  Thanks again for the help.
>
> Jhaysonn Pathak
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From tjarvi at qbang.org  Thu Jun 29 19:30:00 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 19:30:00 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A3D353.6010605@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
Message-ID: <Pine.LNX.4.61.0606291923000.9561@www>

On Thu, 29 Jun 2006, Manuel Naranjo wrote:

> Speaking about Windows Support, I had seen that inside the
> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
> not make harm to anyone, and i'm almost sure that someone has noticed it
> before.

Hi Manuel

         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
     47421  01-30-06 00:23 
rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
     77759  03-01-06 12:01 
rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README


It looks normal to me.  There are no fancy tools used there :)

--
Trent Jarvi
tjarvi at qbang.org

From naranjo.manuel at gmail.com  Thu Jun 29 19:38:16 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 22:38:16 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606291923000.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com> <Pine.LNX.4.61.0606291923000.9561@www>
Message-ID: <44A48088.2040407@gmail.com>

> On Thu, 29 Jun 2006, Manuel Naranjo wrote:
> 
>> Speaking about Windows Support, I had seen that inside the
>> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
>> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
>> not make harm to anyone, and i'm almost sure that someone has noticed it
>> before.
> 
> Hi Manuel
> 
>         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
>         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
>     47421  01-30-06 00:23 
> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
>     77759  03-01-06 12:01 
> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
>       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README
> 
> 
> It looks normal to me.  There are no fancy tools used there :)
> 
Hi Trent:
Is not the i368 representing the name of the Architecture?? If so the 
name should start with i386 it will not break any system, is simply miss
written, I saw that and wanted to report it. It a silly thing.
Ohh I forgoten I must congratulate you for your GREAT libray, I was able 
to make an .exe with JSmooth that launches an application that uses RXTX 
with out the need to install RXTX on users system :). The .exe tells JVM 
where to find the RXTX Library and Binaries. I tried with Sun's Java 
Comm but it was imposible.
Regards,
Manuel


From tjarvi at qbang.org  Thu Jun 29 19:52:45 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 19:52:45 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A48088.2040407@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
	<Pine.LNX.4.61.0606291923000.9561@www> <44A48088.2040407@gmail.com>
Message-ID: <Pine.LNX.4.61.0606291945060.9561@www>

On Thu, 29 Jun 2006, Manuel Naranjo wrote:

>> On Thu, 29 Jun 2006, Manuel Naranjo wrote:
>>
>>> Speaking about Windows Support, I had seen that inside the
>>> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
>>> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
>>> not make harm to anyone, and i'm almost sure that someone has noticed it
>>> before.
>>
>> Hi Manuel
>>
>>         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
>>         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
>>     47421  01-30-06 00:23
>> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
>>     77759  03-01-06 12:01
>> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
>>       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README
>>
>>
>> It looks normal to me.  There are no fancy tools used there :)
>>
> Hi Trent:
> Is not the i368 representing the name of the Architecture?? If so the
> name should start with i386 it will not break any system, is simply miss
> written, I saw that and wanted to report it. It a silly thing.
> Ohh I forgoten I must congratulate you for your GREAT libray, I was able
> to make an .exe with JSmooth that launches an application that uses RXTX
> with out the need to install RXTX on users system :). The .exe tells JVM
> where to find the RXTX Library and Binaries. I tried with Sun's Java
> Comm but it was imposible.

Hi Manuel

The compiler uses only the i386 instruction set for windows.  I doubt 
there will be any measurable advantages with going to later instruction 
sets.  In theory rxtx would run on a 386 but I doubt anyone does that.

So it looks odd but is not a typo.

We could compile to i686 but don't.  The compiler used does not appear to 
be a problem yet so I don't see any point in changing it.  Right now, we 
could not compile 64 bit windows binaries.  gcc/mingw/... do not support 
them that I know of.  People will have to compile those with closed source 
tools on their own until an option is available.

--
Trent Jarvi
tjarvi at qbang.org

From naranjo.manuel at gmail.com  Thu Jun 29 20:00:48 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 23:00:48 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606291945060.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com>	<Pine.LNX.4.61.0606291923000.9561@www>
	<44A48088.2040407@gmail.com> <Pine.LNX.4.61.0606291945060.9561@www>
Message-ID: <44A485D0.7050202@gmail.com>

Trent you did not get my point
The folder says 368 three hundred sixty eight, when
it should say 386 three hundred eighty six. Is simply a miss writting.
Regards,
Manuel


From tjarvi at qbang.org  Thu Jun 29 20:12:15 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 20:12:15 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A485D0.7050202@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
	<Pine.LNX.4.61.0606291923000.9561@www> <44A48088.2040407@gmail.com>
	<Pine.LNX.4.61.0606291945060.9561@www> <44A485D0.7050202@gmail.com>
Message-ID: <Pine.LNX.4.61.0606292008061.9561@www>


On Thu, 29 Jun 2006, Manuel Naranjo wrote:

> Trent you did not get my point
> The folder says 368 three hundred sixty eight, when
> it should say 386 three hundred eighty six. Is simply a miss writting.

hehe..  OK.  My bad.  It's been a long day.

Nevermind :)

--
Trent Jarvi
tjarvi at qbang.org




From naranjo.manuel at gmail.com  Thu Jun 29 20:18:44 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 23:18:44 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606292008061.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com>	<Pine.LNX.4.61.0606291923000.9561@www>
	<44A48088.2040407@gmail.com>	<Pine.LNX.4.61.0606291945060.9561@www>
	<44A485D0.7050202@gmail.com> <Pine.LNX.4.61.0606292008061.9561@www>
Message-ID: <44A48A04.9040401@gmail.com>

Don't worry Trent.
About 64 bits compilation, I would like to colaborate, I have a Pc with 
64 bits, the only problem is that i do not have windows 64 bits 
installed :(.




From Pawan.Kharbanda at dot.state.co.us  Fri Jun 30 08:49:52 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 30 Jun 2006 08:49:52 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E996@hqexchange3.dot.state.co.us>

Trent,  
    Can you explain what the interruptedEventLoop() native method is
doing is there a possibility that method is somehow getting into the
infinite loop(there are 2 while loops without any break statements).
This might be a very basic question how can I debug the native code(or
print the debug statements).  Again thanks for the help. 

Pawan Kharbanda

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Thursday, June 29, 2006 6:21 AM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports

> Here is how you can test if you have resources/ test environment. 
> Write a program and try to open/close  different ports(I will say have

> a minimum of four) randomly and very frequently(may be 30 seconds), I 
> am pretty sure you will see the deadlocks and it happens in the native

> call to interrptEventLoop in RXTXPort.java in removeEventListener() 
> method call.

Hi Pawan

I'll try to find a way to reproduce this.  One thing to note is that you
are using different kernel drivers (digi) to perform this task.  So I
probably will not be able to reproduce the exact same environment.

In general, multiport kernel drivers have been tested far less than
typical serial drivers.  This may or may not be an issue.

--
Trent Jarvi
tjarvi at qbang.org

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From cpine at wrsystems.com  Thu Jun 29 15:17:12 2006
From: cpine at wrsystems.com (Chris Pine)
Date: Thu, 29 Jun 2006 17:17:12 -0400
Subject: [Rxtx]  Controlling Individual Signals DTR and RTS
Message-ID: <MAIL4FJo0S8ACLEBajJ000005cf@mail4.wrsystems.com>

Dear Moussa Ba,
	I hope I am not being too forward, but we are having the exact same
issue with needing to control DTR from RXTX in Linux.  Did you ever have any
luck figuring it out?

Thank you very much for your time,

Chris Pine




From tjarvi at qbang.org  Thu Jun  1 11:13:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 11:13:40 -0600 (MDT)
Subject: [Rxtx] custom baud rate win32
In-Reply-To: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606011107210.30220@www>


Hi Daren

I can't imagine that 1953 is possibly the actual value on the UART.  Maybe 
if your baud base is very high with a custom serial board.  More likely, 
the driver just remembers that what you asked for and did something else.

I'll have more to say on the dcb->BaudRate after I try some things here. 
I have managed to do something like that in the past as a quick hack but 
it was for 14400.  I may have used the CBR_14400.

If we can't access this through the win32 API with protected mode, there 
is another layer of complication.  With real mode, it would be easy.
With protected mode, I assume there would have to be some kernel driver or 
a hook I'm not aware of to access the MCR directly (bang a memory 
addresss).



On Thu, 1 Jun 2006, Daren wrote:

> Trent,
> I have managed to successfully open the port at this speed using Realterm
> (available on sourceforge). From memory this uses DLPortIO.
>
> Using portmon.exe with realterm, even there it says that the port has opened
> at 1953.
>
> I changed termios.c:560 to
> dcb->BaudRate        = 1953 ;
>
> and it still opens the port at 9600.
>
> Daren
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Trent Jarvi
> Sent: Thursday, 1 June 2006 1:44 PM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] custom baud rate win32
>
> On Thu, 1 Jun 2006, Daren wrote:
>
>> Hi all,
>>
>> I downloaded 2.1.7-pre16 and managed to build it and get it going. I made
>> the changes as suggested by Peter Smith in an old post, by adding his code
>> to SerialImpl.c, uncommenting the TIOCGSERIAL and TIOCSSERIAL, and
> defining
>> ASYNC_SPD_CUST which is equal to 0x0030 (according to linus header
> files)..
>>
>>
>> Still not working, it opens the port at 9600 according to portmon.exe .
> Has
>> anyone managed to get this going at a custom rate?
>>
>> Here is the post I'm referring to:
>> http://marc.theaimsgroup.com/?l=rxtx&m=106270038110713&w=2
>>
>>
>> Thanks,
>> Daren
>>
>> ________________________________________
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
>> Daren
>> Sent: Wednesday, 31 May 2006 10:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] (no subject)
>>
>> Hi All,
>> I have been using rxtx for a little while and needed to get it working at
>> 1953, like a past user in the mailing list, who seemed to have got it
>> working by changing some C code.
>>
>> I wanted to build rxtx myself with these changes but don't know where to
>> start. I have windows here and FC4 at home. I downloaded cygwin and
> mingw32,
>> each build works by building a rxtxSerial.dll file that is ~11k smaller
> than
>> the original, and I always get the following error when testing the dll:
>>
>> Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at
>> PC=0x8077655
>> Function=[Unknown.]
>> Library=C:\opt\java\j2sdk1.4.2\jre\bin\client\jvm.dll
>>
>> NOTE: We are unable to locate the function name symbol for the error
>>      just occurred. Please refer to release documentation for possible
>>      reason and solutions.
>>
>>
>> Current Java thread:
>> 	at gnu.io.RXTXPort.open(Native Method)
>> 	- locked <0x1002c800> (a gnu.io.RXTXPort)
>> 	at gnu.io.RXTXPort.<init>(RXTXPort.java:84)
>>
>> Anyone know what im doing wrong?
>>
>>
>>
>>
>
> Hi Daren
>
> You are running into the same rats nest I'm looking at now.
>
> With win32 and specific custom baud rates, I'm not sure how this will go.
> I've got the Linux custom baud rates working very nicely.  I did much like
> the post you linked.  In fact I had forgot about that post.  You probably
> noticed that it becomes a bunch of dirt roads going noplace fast in
> termios.c for w32.
>
> I'm probably only going to get 14400, 28800, 128000 and 256000 working
> with the next release on w32.  I'll look a little further.  If you have an
> example w32 that works at 1953 I'd really like to hear.  Thats an unusual
> baud rate.
>
> Assuming a baud_base of 128000, your divisor will be 65 or 66.
>
> 128000/66=1939 -14
> 128000/65=1969 +13
>
> One thing I've been wondering about with linux is which would be the right
> answer in cases like this.  Right now it would just go with a baud base of
> 65 and ignore the modulus details.
>
> It appears to be a general trend for kernel developers to hide these
> details thinking that they can come up with a general solution.  Then they
> run out of time.  Perahps the solution is to help out but there are
> ultiple OS's rxtx supports making that nontrivial.
>
> If you look at current linux kernels, the 'tricks' above have been marked
> deprecated with no replacement.  Windows has some hard defines and then
> ancient near magic.  I've not looked at Solaris via Open Solaris yet but
> doubt there is a solution at all.
>
> What I'd try since you have the equipment and the monitor software is to
> hardcode the dcb->Baud in termios.c to 1953 (no define) and see what the
> w32 kernel does with it.  I think if you toss a baud rate at the driver it
> will try to come close.  You may try comming closer to a real baudrate
> based upon the 128000 baud base as shown above.
>
> If it works, it is worth looking at the rest of the ping/pong logic then.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
>
>
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From doug at dupreeinc.com  Thu Jun  1 13:22:13 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 12:22:13 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011107210.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
Message-ID: <447F3E65.1020809@dupreeinc.com>

Hello,

I am still trying to get this startup a little faster so I turned on the 
debug of a few of the classes.  The COM ports are scanned really fast 
and the delay occurs during the LPT scan.  The console output looks like 
this:

    ...
      LPT1
      LPT2
      LPT3
     valid port prefixes:
      LPT
    LPT1 LPT
    1 1
    LPT2 LPT
    2 2                                                                 
      * <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
    CommPortIdentifier:addPortName(LPT2)
    CommPortIdentifier:AddIdentifierToList()
    LPT3 LPT
    3 3
    CommPortIdentifier:addPortName(LPT3)
    CommPortIdentifier:AddIdentifierToList()
    CommPortIdentifier:AddIdentifierToList() index.next
    Leaving registerValidPorts()
    Have not implemented native_psmisc_report_owner(PortName)); in
    CommPortIdentifier
    CommPortIdentifier:getPortIdentifier(COM3)
    CommPortIdentifier:open(densConnect, 30000)
    RXTXCommDriver:getCommPort(COM3,1)
    ...

It would seem to me that if I removed the code for port scanning of LPT 
ports I could solve this problem. I would much prefer to use unmodified 
code if at all possible.  Do any of you have alternate suggestions?

Thank you for your time.

Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/cf433ee7/attachment-0007.html

From tjarvi at qbang.org  Thu Jun  1 13:52:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 13:52:06 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F3E65.1020809@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011348380.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I am still trying to get this startup a little faster so I turned on the 
> debug of a few of the classes.  The COM ports are scanned really fast and the 
> delay occurs during the LPT scan.  The console output looks like this:
>
>   ...
>     LPT1
>     LPT2
>     LPT3
>    valid port prefixes:
>     LPT
>   LPT1 LPT
>   1 1
>   LPT2 LPT
>   2 2                                                                      * 
> <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>   CommPortIdentifier:addPortName(LPT2)
>   CommPortIdentifier:AddIdentifierToList()
>   LPT3 LPT
>   3 3
>   CommPortIdentifier:addPortName(LPT3)
>   CommPortIdentifier:AddIdentifierToList()
>   CommPortIdentifier:AddIdentifierToList() index.next
>   Leaving registerValidPorts()
>   Have not implemented native_psmisc_report_owner(PortName)); in
>   CommPortIdentifier
>   CommPortIdentifier:getPortIdentifier(COM3)
>   CommPortIdentifier:open(densConnect, 30000)
>   RXTXCommDriver:getCommPort(COM3,1)
>   ...
>
> It would seem to me that if I removed the code for port scanning of LPT ports 
> I could solve this problem. I would much prefer to use unmodified code if at 
> all possible.  Do any of you have alternate suggestions?
>
> Thank you for your time.
>
> Doug
>


Does commenting out the LPT enumeration actually help?  There can often be 
differences between debug information printed and whats really going on. 
When you combine various environments the debug info can even come out in 
the wrong order.

I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
I do not think this problem is universal.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Thu Jun  1 14:29:44 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:29:44 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4E38.2060004@dupreeinc.com>

I will give it a try.  One thing to note on this PC is it has no LPT 
Parallel ports.

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
>>Hello,
>>
>>I am still trying to get this startup a little faster so I turned on the 
>>debug of a few of the classes.  The COM ports are scanned really fast and the 
>>delay occurs during the LPT scan.  The console output looks like this:
>>
>>  ...
>>    LPT1
>>    LPT2
>>    LPT3
>>   valid port prefixes:
>>    LPT
>>  LPT1 LPT
>>  1 1
>>  LPT2 LPT
>>  2 2                                                                      * 
>><<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>>  CommPortIdentifier:addPortName(LPT2)
>>  CommPortIdentifier:AddIdentifierToList()
>>  LPT3 LPT
>>  3 3
>>  CommPortIdentifier:addPortName(LPT3)
>>  CommPortIdentifier:AddIdentifierToList()
>>  CommPortIdentifier:AddIdentifierToList() index.next
>>  Leaving registerValidPorts()
>>  Have not implemented native_psmisc_report_owner(PortName)); in
>>  CommPortIdentifier
>>  CommPortIdentifier:getPortIdentifier(COM3)
>>  CommPortIdentifier:open(densConnect, 30000)
>>  RXTXCommDriver:getCommPort(COM3,1)
>>  ...
>>
>>It would seem to me that if I removed the code for port scanning of LPT ports 
>>I could solve this problem. I would much prefer to use unmodified code if at 
>>all possible.  Do any of you have alternate suggestions?
>>
>>Thank you for your time.
>>
>>Doug
>>
>>    
>>
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/dd31fed5/attachment-0007.html

From doug at dupreeinc.com  Thu Jun  1 14:36:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:36:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4FC8.9080106@dupreeinc.com>

Trent,

I commented out the section in RegisterScannedPorts() that adds the 
three LPT ports to the CandidateDeviceNames string array.  The 
application started immediately.  This is probably not the way to do 
this, but it was quick ,dirty, and worked.

It would be nice if there was a way to pole the OS to see if there is 
even a port there, though I guess this is what this code is suppose to do...

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
> ...
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From lynn at swcp.com  Thu Jun  1 14:49:34 2006
From: lynn at swcp.com (lynn@swcp.com)
Date: Thu, 1 Jun 2006 20:49:34 -0000
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>,
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <twig.1149194974.97617@swcp.com>

Perhaps we could add an argument to port enumeration where if not specified,
you get the default behavior that looks for everything.  With a new
constructor that has an argument(or more) you could optionally declare it to
not inspect printer ports.

Existing code would work as it always has.  New code could be smarter.

Lynn



Doug Thistlethwaite <doug at dupreeinc.com> said:

> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
> >On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
> >
> >  
> >
> > ...
> >
> >
> >Does commenting out the LPT enumeration actually help?  There can often be 
> >differences between debug information printed and whats really going on. 
> >When you combine various environments the debug info can even come out in 
> >the wrong order.
> >
> >I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
> >I do not think this problem is universal.
> >
> >--
> >Trent Jarvi
> >tjarvi at qbang.org
> >_______________________________________________
> >Rxtx mailing list
> >Rxtx at qbang.org
> >http://mailman.qbang.org/mailman/listinfo/rxtx
> >
> >
> >  
> >
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



-- 





From jredman at ergotech.com  Thu Jun  1 15:20:20 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 01 Jun 2006 15:20:20 -0600
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
Message-ID: <447F5A14.6010803@ergotech.com>

Doug,

If you specifically request ports, eg:

-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

or
 
-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

Depending upon the version  (Windows is COM1:COM2, etc. I assume).

Does it still enumerate the parallel ports?

Jim

Doug Thistlethwaite wrote:
> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
>> On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>
>>  
>>
>> ...
>>
>>
>> Does commenting out the LPT enumeration actually help?  There can often be 
>> differences between debug information printed and whats really going on. 
>> When you combine various environments the debug info can even come out in 
>> the wrong order.
>>
>> I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>> I do not think this problem is universal.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>>
>>  
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  1 16:49:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:49:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6EF4.7080709@dupreeinc.com>

I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
folder.  I created this file and added the following to the file:

gnu.io.rxtx.SerialPorts=COM3

and I get the following error on the console:
CommPortIdentifier:static initialization()
RXTXCommDriver {}
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
RXTXCommDriver:
    Jar version = RXTX-2.1-7
    native lib Version = RXTX-2.1-7
RXTXCommDriver:initialize()
checking for system-known ports of type 1
checking registry for ports of type 1

RXTXCommDriver:addSpecifiedPorts()
Exception in thread "main" java.lang.ExceptionInInitializerError
    at 
densconnect.SerialConnection.openConnection(SerialConnection.java:136)
    at densconnect.DensTalk.<init>(DensTalk.java:165)
    at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
    at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
    at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
    at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
Caused by: java.lang.NullPointerException
    at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
CommPortIdentifier:addPortName(COM3)
CommPortIdentifier:AddIdentifierToList()
CommPortIdentifier:AddIdentifierToList() null
...


It looks like it  read COM3 from the file, but it had the above 
exception that killed it.  The strange this is this error is from 
RXTXCommDriver initialize function (if statement line):

        OS = System.getProperty("os.name");
                System.out.println("OS NAME: " + OS);
        if(OS.toLowerCase().indexOf("linux") == -1)

OS is returning null, thus the error.

If the file is not present, it scans the ports and reads the OS.

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>Doug Thistlethwaite wrote:
>  
>
>>Trent,
>>
>>I commented out the section in RegisterScannedPorts() that adds the 
>>three LPT ports to the CandidateDeviceNames string array.  The 
>>application started immediately.  This is probably not the way to do 
>>this, but it was quick ,dirty, and worked.
>>
>>It would be nice if there was a way to pole the OS to see if there is 
>>even a port there, though I guess this is what this code is suppose to do...
>>
>>Doug
>>
>>Trent Jarvi wrote:
>>
>>    
>>
>>>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>>
>>> 
>>>
>>>...
>>>
>>>
>>>Does commenting out the LPT enumeration actually help?  There can often be 
>>>differences between debug information printed and whats really going on. 
>>>When you combine various environments the debug info can even come out in 
>>>the wrong order.
>>>
>>>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>>>I do not think this problem is universal.
>>>
>>>--
>>>Trent Jarvi
>>>tjarvi at qbang.org
>>>_______________________________________________
>>>Rxtx mailing list
>>>Rxtx at qbang.org
>>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>>
>>>
>>> 
>>>
>>>      
>>>
>>_______________________________________________
>>Rxtx mailing list
>>Rxtx at qbang.org
>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>    
>>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/bf4cca0e/attachment-0007.html

From doug at dupreeinc.com  Thu Jun  1 16:51:26 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:51:26 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6F6E.5060603@dupreeinc.com>

Jim,

I did not try your suggestion as I do not understand where I would put 
these command line parameters (it that is what they are).  It appears 
that using the properties file should do that same thing...

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>
>  
>


From doug at dupreeinc.com  Thu Jun  1 17:56:19 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 16:56:19 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
Message-ID: <447F7EA3.6050400@dupreeinc.com>

I think there is an error in the registerSpecifiedPorts() method.  When 
I have a gnu.io.rxtx.properties file in the ext directory, this function 
kills the System class  IF I call System.getProperty("os.name") before 
the call  to registerSpecifiedPorts(), it returns the os name, after the 
call, it returns null.  I have not played much with properties, except 
for reading them, so I don't really understand the code.

Doug



From doug at dupreeinc.com  Thu Jun  1 18:11:14 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 17:11:14 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F7EA3.6050400@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com>
Message-ID: <447F8222.3060402@dupreeinc.com>

Ok, I just hacked this thing up and got it to read the 
gnu.io.rxtx.properties file.

I commented out the line:
System.setProperties(p); in the method registerSpecifiedPorts() in 
RXTXCommDriver class.  I really don't understand that much about 
properties, but this call kills the System class.

I used the following in the gnu.io.rxtx.properties file:

gnu.io.rxtx.SerialPorts=COM3
gnu.io.rxtx.ParallelPorts=null

This allows the application to open very quickly without any errors.  
Whomever coded this class or somebody who understands properties should 
look at this method and make sure it is doing what they expect.

Doug




Doug Thistlethwaite wrote:

>I think there is an error in the registerSpecifiedPorts() method.  When 
>I have a gnu.io.rxtx.properties file in the ext directory, this function 
>kills the System class  IF I call System.getProperty("os.name") before 
>the call  to registerSpecifiedPorts(), it returns the os name, after the 
>call, it returns null.  I have not played much with properties, except 
>for reading them, so I don't really understand the code.
>
>Doug
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From tjarvi at qbang.org  Thu Jun  1 18:32:50 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 18:32:50 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F6EF4.7080709@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com> <447F6EF4.7080709@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011831510.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
> folder.  I created this file and added the following to the file:
>
> gnu.io.rxtx.SerialPorts=COM3
>
> and I get the following error on the console:
> CommPortIdentifier:static initialization()
> RXTXCommDriver {}
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
> RXTXCommDriver:
>   Jar version = RXTX-2.1-7
>   native lib Version = RXTX-2.1-7
> RXTXCommDriver:initialize()
> checking for system-known ports of type 1
> checking registry for ports of type 1
>
> RXTXCommDriver:addSpecifiedPorts()
> Exception in thread "main" java.lang.ExceptionInInitializerError
>   at densconnect.SerialConnection.openConnection(SerialConnection.java:136)
>   at densconnect.DensTalk.<init>(DensTalk.java:165)
>   at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
>   at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
>   at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
>   at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
> Caused by: java.lang.NullPointerException
>   at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
> CommPortIdentifier:addPortName(COM3)
> CommPortIdentifier:AddIdentifierToList()
> CommPortIdentifier:AddIdentifierToList() null
> ...
>
>

There is a solution for this bug.

http://bugzilla.qbang.org/show_bug.cgi?id=54

We have been horribly slow at getting the next round of patches in but 
they are comming.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  2 00:58:02 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 08:58:02 +0200
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F8222.3060402@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
Message-ID: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>

Hi Doug,

you wrote in an earlier message, that you would prefer an unchanged  
version. What about simply removing the RXTX parallel lib from the  
ext directory. This does not fix the bug, but it should fix your  
problem.

In general I think it is not a good idea to put the RXTX files in a  
system wide location. Putting the libs in the application folder and  
including the .jar in the application classpath (or application jar)  
is all that is required.

Regards,
Joachim

On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:

> Ok, I just hacked this thing up and got it to read the
> gnu.io.rxtx.properties file.
>
> I commented out the line:
> System.setProperties(p); in the method registerSpecifiedPorts() in
> RXTXCommDriver class.  I really don't understand that much about
> properties, but this call kills the System class.
>
> I used the following in the gnu.io.rxtx.properties file:
>
> gnu.io.rxtx.SerialPorts=COM3
> gnu.io.rxtx.ParallelPorts=null
>
> This allows the application to open very quickly without any errors.
> Whomever coded this class or somebody who understands properties  
> should
> look at this method and make sure it is doing what they expect.
>
> Doug
>
>
>
>
> Doug Thistlethwaite wrote:
>
>> I think there is an error in the registerSpecifiedPorts() method.   
>> When
>> I have a gnu.io.rxtx.properties file in the ext directory, this  
>> function
>> kills the System class  IF I call System.getProperty("os.name")  
>> before
>> the call  to registerSpecifiedPorts(), it returns the os name,  
>> after the
>> call, it returns null.  I have not played much with properties,  
>> except
>> for reading them, so I don't really understand the code.
>>
>> 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 antonio.luis at iscte.pt  Fri Jun  2 02:42:28 2006
From: antonio.luis at iscte.pt (=?ISO-8859-1?Q?Ant=F3nio_Lopes?=)
Date: Fri, 02 Jun 2006 09:42:28 +0100
Subject: [Rxtx] Exception when closing serial port
Message-ID: <447FF9F4.7060209@iscte.pt>

Hello everyone,
I've been using RXTX in a Java application in my Pocket PC.
The communication through the (bluetooth) serial port is working perfectly.

However, when I disconnect the app and close the serial port, sometimes I get 
the following error:

"1149237595000: RXTXPort:close detected bad File Descriptor"

The problem is that after this error occurs, the app is no longer able to 
connect to the serial port and I have to soft-reset the device in order to be 
able to connect to it again.

Any ideas on how to solve this issue?

Any help is appreciated.
Thanks,
regards,
-- 
Ant?nio Lopes

@contact: antonio.luis at iscte.pt
@work: ADETTI - ISCTE
@web: http://antonio.lopes.googlepages.com


From paul.klissner at sun.com  Fri Jun  2 02:44:34 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 01:44:34 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to RXTX
	again
Message-ID: <447FFA72.6040807@sun.com>

After looking into javax.comm 3.1 and what it would take to re-engineer it
to be compatible with RXTX platform libraries, I've decided, due my group's
priorities, complexity of the effort vs. benefit, and limited resources, 
to re-post
javax.comm 2.0 binaries on Sun's software download server, unsupported,
with disclaimers, as it was previously.

I don't think there will be any snags doing this from the standpoint of Sun
management or legality.  I will try to have it  posted there in the next 
week
or two, depending on how fast we can get it pushed through the process.

I'd like to think of this as a stop gap measure... ie. a compromise, 
where, at some
point in the not too distant future RXTX implements their own version of the
Java side of the API, as is normally done by javax.extension porters. 
That way
we avoid uncomfortable dependencies in the future.  And that really is 
the Java
development model.

Since RXTX already has the back-end code, porting the java code shouldn't
be a gargantuan effort at all, and RXTX will be in full control of the 
code top
to bottom. I think RXTX can do at least as good a job as the original 
coder.
Prepping 2.0 to be open sourced is more trouble than it is worth. ie. I 
don't
think the current implementation warrants it.

Ultimately, it would be nice to see someone open up a JSR and re-architect
the comm. API to overcome some of it's current design flaws (ie. be more
adaptable to modern platforms, more pluggable, better defined SPI, better
port ownership handling, etc...). A superior architecture would allow for
better collaboration in the future and better interchangeability of 
components
among projects.

Sun's 3.1 version of javax.comm, which is Sun's currently supported version,
has changes pertaining mostly to Sun platform-specific portmapping and has
some minor additional interactions with our back end code, but generally
has little bearing on RXTX. 

Paul



From joachim at buechse.de  Fri Jun  2 04:00:19 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 12:00:19 +0200
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
	RXTX again
In-Reply-To: <447FFA72.6040807@sun.com>
References: <447FFA72.6040807@sun.com>
Message-ID: <1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>

Good day Paul!

A clean architecture with loadable drivers and reusable code would be  
very beneficial for the future, I think everybody agrees. However  
this could be several years into the future. In the meantime, there  
is a real existing problem with IO support on Java. I have the strong  
feeling that most programmers want to code against one specification  
(javax.comm) and be able to replace the underlying implementation via  
a "plugin" on platforms where the SUN implementation is not  
sufficient. RXTX could be just this plugin (reusing very close to 0%  
of the javax.comm implementation but 100% of its API).

I want to propose an API addition and implementation change that will  
take less then 2 hours of manpower to implement and create a solution  
that can bridge the years until javax.comm has been based on a new  
architecture.

Looking at the javax.comm api at http://java.sun.com/products/ 
javacomm/reference/api/index.html I would like to propose the following:

The only entry point to javax.comm is CommPortIdentifier. It has 3  
static methods plus the constructor.

1) define one additional Interface

public interface CommProvider {
    CommPortIdentifier getPortIdentifier(CommPort port);
    CommPortIdentifier getPortIdentifier(String portName);
    Enumeration getPortIdentifiers ();
}

2) add one method to CommPortIdentifier

   public static setCustomCommProvider (CommProvider);

3) change the three static methods of CommPortIdentifier to dispatch  
to the CommProvider if it is set

4) change the constructor of CommPortIdentifier to

   public CommPortIdentifier(...) {
      if (isProviderSet && this.getClass() ==  
javax.comm.CommPortIdentifier) {
          throw new RuntimeException("illegal creation of  
CommPortIndentifier, custom CommProvider is in use");
      }

5) (this is optional, but would be very nice) automatically set a  
custom CommProvider if it is found on the classpath or defined via a  
system property.


The above 1) - 4) can be implemented in less than 1hour. 5) may take  
another hour. I agree that this is not the most elegant design, but  
it would solve a lot of problems with very little effort. It would  
certainly allow RXTX to move forward. If the javax.comm API needs to  
be redesigned completely this addition will not hurt, as people will  
move to the new API anyway and javax.comm 3.0 was so far never  
included in the main distribution.

Best regards,
Joachim

On 02.06.2006, at 10:44, Paul Klissner wrote:

> After looking into javax.comm 3.1 and what it would take to re- 
> engineer it
> to be compatible with RXTX platform libraries, I've decided, due my  
> group's
> priorities, complexity of the effort vs. benefit, and limited  
> resources,
> to re-post
> javax.comm 2.0 binaries on Sun's software download server,  
> unsupported,
> with disclaimers, as it was previously.
>
> I don't think there will be any snags doing this from the  
> standpoint of Sun
> management or legality.  I will try to have it  posted there in the  
> next
> week
> or two, depending on how fast we can get it pushed through the  
> process.
>
> I'd like to think of this as a stop gap measure... ie. a compromise,
> where, at some
> point in the not too distant future RXTX implements their own  
> version of the
> Java side of the API, as is normally done by javax.extension porters.
> That way
> we avoid uncomfortable dependencies in the future.  And that really is
> the Java
> development model.
>
> Since RXTX already has the back-end code, porting the java code  
> shouldn't
> be a gargantuan effort at all, and RXTX will be in full control of the
> code top
> to bottom. I think RXTX can do at least as good a job as the original
> coder.
> Prepping 2.0 to be open sourced is more trouble than it is worth.  
> ie. I
> don't
> think the current implementation warrants it.
>
> Ultimately, it would be nice to see someone open up a JSR and re- 
> architect
> the comm. API to overcome some of it's current design flaws (ie. be  
> more
> adaptable to modern platforms, more pluggable, better defined SPI,  
> better
> port ownership handling, etc...). A superior architecture would  
> allow for
> better collaboration in the future and better interchangeability of
> components
> among projects.
>
> Sun's 3.1 version of javax.comm, which is Sun's currently supported  
> version,
> has changes pertaining mostly to Sun platform-specific portmapping  
> and has
> some minor additional interactions with our back end code, but  
> generally
> has little bearing on RXTX.
>
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Fri Jun  2 09:10:13 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Fri, 2 Jun 2006 09:10:13 -0600 (MDT)
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <447FFA72.6040807@sun.com>
References: <447FFA72.6040807@sun.com>
Message-ID: <Pine.LNX.4.61.0606020906400.15971@www>

On Fri, 2 Jun 2006, Paul Klissner wrote:

> After looking into javax.comm 3.1 and what it would take to re-engineer it
> to be compatible with RXTX platform libraries, I've decided, due my group's
> priorities, complexity of the effort vs. benefit, and limited resources,
> to re-post
> javax.comm 2.0 binaries on Sun's software download server, unsupported,
> with disclaimers, as it was previously.
>

Hi Paul

To address users' immediate needs, we can release rxtx 2.0-7 (final) to 
match the 2.0 binaries from Sun when they are offered for download.

We can discuss potential long term solutions after that.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Fri Jun  2 10:20:09 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 02 Jun 2006 09:20:09 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
	<9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
Message-ID: <44806539.8080902@dupreeinc.com>

Thanks for the suggestion, I will give it a try.

Doug

Joachim Buechse wrote:

>Hi Doug,
>
>you wrote in an earlier message, that you would prefer an unchanged  
>version. What about simply removing the RXTX parallel lib from the  
>ext directory. This does not fix the bug, but it should fix your  
>problem.
>
>In general I think it is not a good idea to put the RXTX files in a  
>system wide location. Putting the libs in the application folder and  
>including the .jar in the application classpath (or application jar)  
>is all that is required.
>
>Regards,
>Joachim
>
>On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:
>
>  
>
>>Ok, I just hacked this thing up and got it to read the
>>gnu.io.rxtx.properties file.
>>
>>I commented out the line:
>>System.setProperties(p); in the method registerSpecifiedPorts() in
>>RXTXCommDriver class.  I really don't understand that much about
>>properties, but this call kills the System class.
>>
>>I used the following in the gnu.io.rxtx.properties file:
>>
>>gnu.io.rxtx.SerialPorts=COM3
>>gnu.io.rxtx.ParallelPorts=null
>>
>>This allows the application to open very quickly without any errors.
>>Whomever coded this class or somebody who understands properties  
>>should
>>look at this method and make sure it is doing what they expect.
>>
>>Doug
>>
>>
>>
>>
>>Doug Thistlethwaite wrote:
>>
>>    
>>
>>>I think there is an error in the registerSpecifiedPorts() method.   
>>>When
>>>I have a gnu.io.rxtx.properties file in the ext directory, this  
>>>function
>>>kills the System class  IF I call System.getProperty("os.name")  
>>>before
>>>the call  to registerSpecifiedPorts(), it returns the os name,  
>>>after the
>>>call, it returns null.  I have not played much with properties,  
>>>except
>>>for reading them, so I don't really understand the code.
>>>
>>>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
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060602/c8892a46/attachment-0007.html

From paul.klissner at sun.com  Fri Jun  2 12:09:26 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 11:09:26 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
Message-ID: <44807ED6.8000903@sun.com>

Joachim Buechse wrote:
> Good day Paul!
>
> A clean architecture with loadable drivers and reusable code would be  
> very beneficial for the future, I think everybody agrees. However  
> this could be several years into the future. In the meantime, there  
> is a real existing problem with IO support on Java. I have the strong  
> feeling that most programmers want to code against one specification  
> (javax.comm) and be able to replace the underlying implementation via  
> a "plugin" on platforms where the SUN implementation is not  
> sufficient. RXTX could be just this plugin (reusing very close to 0%  
> of the javax.comm implementation but 100% of its API).
>
> I want to propose an API addition and implementation change that will  
> take less then 2 hours of manpower to implement and create a solution  
> that can bridge the years until javax.comm has been based on a new  
> architecture.
>
> Looking at the javax.comm api at http://java.sun.com/products/ 
> javacomm/reference/api/index.html I would like to propose the following:
>
> The only entry point to javax.comm is CommPortIdentifier. It has 3  
> static methods plus the constructor.
>
> 1) define one additional Interface
>
> public interface CommProvider {
>     CommPortIdentifier getPortIdentifier(CommPort port);
>     CommPortIdentifier getPortIdentifier(String portName);
>     Enumeration getPortIdentifiers ();
> }
>
> 2) add one method to CommPortIdentifier
>
>    public static setCustomCommProvider (CommProvider);
>
> 3) change the three static methods of CommPortIdentifier to dispatch  
> to the CommProvider if it is set
>
> 4) change the constructor of CommPortIdentifier to
>
>    public CommPortIdentifier(...) {
>       if (isProviderSet && this.getClass() ==  
> javax.comm.CommPortIdentifier) {
>           throw new RuntimeException("illegal creation of  
> CommPortIndentifier, custom CommProvider is in use");
>       }
>
> 5) (this is optional, but would be very nice) automatically set a  
> custom CommProvider if it is found on the classpath or defined via a  
> system property.
>
>
> The above 1) - 4) can be implemented in less than 1hour. 5) may take  
> another hour. I agree that this is not the most elegant design, but  
> it would solve a lot of problems with very little effort. It would  
> certainly allow RXTX to move forward. If the javax.comm API needs to  
> be redesigned completely this addition will not hurt, as people will  
> move to the new API anyway and javax.comm 3.0 was so far never  
> included in the main distribution.
>
> Best regards,
> Joachi
I'm afraid modifying the interface classes isn't my call.  There was 
actually
a TCK written and one of the tests was to ensure that the interface classes
match the spec.  Thus my hands have already been tied since this project
was essentially grandfathered into the JCP.

That's why we need to open a new JSR and find someone who wants
to be the spec lead, and go in with a new reference implementation.
I'm not sure why it would have to take years, since this isn't bleeding edge
technology and there are only so many things that can be done with it,
and we already have practical experience about many functional aspects
that we could cite precedence on.

As it becomes clear that the specification is being accepted completely
or by-and-large by the community, nothing would stop people from
starting adapting to the new API (using the reference implementation or
porting it) and using it in their projects prior to it's final community and
JCP approval, since approval is required only to make it official and
get the "100% pure java" certification for platform ports.

You have one idea already.  Why don't you implement it, solicit some
design feedback from Sun and the RXTX, and create a functional
implementation that addresses the needs of the community, then
we can document it and open a JSR.  That's it.  It should march through
the approval stages reasonably quickly I would imagine, and meantime
RXTX could start using it.

Paul




From doug at dupreeinc.com  Fri Jun  2 12:45:01 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 02 Jun 2006 11:45:01 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
	<9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
Message-ID: <4480872D.6000605@dupreeinc.com>

Joachim,

Thank you for the suggestion.  I restored the jar file to the one I 
downloaded, moved the dll files into the project directory, and added 
the jar to the classpath.  The SerialDemo program that was included with 
the Sun commapi started in 12 seconds instead of the 58 seconds when the 
parallel dll is present.  I did get the startup time to about a second 
by modifying the java code and adding the properties file but this is 
probably not a good idea.

Doug

Joachim Buechse wrote:

>Hi Doug,
>
>you wrote in an earlier message, that you would prefer an unchanged  
>version. What about simply removing the RXTX parallel lib from the  
>ext directory. This does not fix the bug, but it should fix your  
>problem.
>
>In general I think it is not a good idea to put the RXTX files in a  
>system wide location. Putting the libs in the application folder and  
>including the .jar in the application classpath (or application jar)  
>is all that is required.
>
>Regards,
>Joachim
>
>On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:
>
>  
>
>>Ok, I just hacked this thing up and got it to read the
>>gnu.io.rxtx.properties file.
>>
>>I commented out the line:
>>System.setProperties(p); in the method registerSpecifiedPorts() in
>>RXTXCommDriver class.  I really don't understand that much about
>>properties, but this call kills the System class.
>>
>>I used the following in the gnu.io.rxtx.properties file:
>>
>>gnu.io.rxtx.SerialPorts=COM3
>>gnu.io.rxtx.ParallelPorts=null
>>
>>This allows the application to open very quickly without any errors.
>>Whomever coded this class or somebody who understands properties  
>>should
>>look at this method and make sure it is doing what they expect.
>>
>>Doug
>>
>>
>>
>>
>>Doug Thistlethwaite wrote:
>>
>>    
>>
>>>I think there is an error in the registerSpecifiedPorts() method.   
>>>When
>>>I have a gnu.io.rxtx.properties file in the ext directory, this  
>>>function
>>>kills the System class  IF I call System.getProperty("os.name")  
>>>before
>>>the call  to registerSpecifiedPorts(), it returns the os name,  
>>>after the
>>>call, it returns null.  I have not played much with properties,  
>>>except
>>>for reading them, so I don't really understand the code.
>>>
>>>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
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060602/3c0e420f/attachment-0007.html

From joachim at buechse.de  Fri Jun  2 13:46:36 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 21:46:36 +0200
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
	RXTX again
In-Reply-To: <44807ED6.8000903@sun.com>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
	<44807ED6.8000903@sun.com>
Message-ID: <6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>

Hello Paul,

of course, the basic change I suggested could be done "hidden".  The  
CommProvider interface could live somewhere in sun.xyz.*
The setCustomCommProvider method would not be in CommPortIdentifier  
but also somewhere in sun.xyz.* This would be an unofficial feature,  
the official interface stays exactly the same. However RXTX (and  
others) could access the hidden interface.

Don't get me wrong, I don't want to harass you into making changes  
you don't like (which probably wouldn't work anyway;-). But I'm a  
long time Java programmer and seeing the state of cross platform  
serial support for Java makes me feel really sad. In fact, when I  
started to look into Java serial port programming some months ago I  
was very surprised that javax.comm never made it into the JDK.

I'm sorry that I did not contribute my feedback to the JSR for  
javax.comm 3.0. However at the time I didn't do serial port  
programming in Java. I agree that a new JSR should be opened - I'm  
not an expert on JSRs or the JCP process, but from looking quickly  
over the progress of some JSRs I would be very surprised if we can  
have a new version in less then a year. In the meanwhile some people  
will start using javax.comm 3.0 (which can not be supported by RXTX),  
some will use javax.comm 2.0 (which means the 2.0.7 release of RXTX  
still needs to be maintained). This may get even worse if eg Apple  
decides to port and include javax.comm 3.0 at which point it may get  
very tricky to write a cross platform Java application.

All of this simply means, that we are loosing a lot of man-power that  
could otherwise be invested in building a clean solution and/or to  
add features that are becoming more and more important (USB events...).

In the automation / machine control universe Java makes a lot of  
sense. Right now many people are migrating to Linux or from  
propietary systems (even DOS) to Windows. Writing the control/ 
configuration applications in Java is the kings way to unify the code  
base.

Best regards,
Joachim


On 02.06.2006, at 20:09, Paul Klissner wrote:

> Joachim Buechse wrote:
>> Good day Paul!
>>
>> A clean architecture with loadable drivers and reusable code would be
>> very beneficial for the future, I think everybody agrees. However
>> this could be several years into the future. In the meantime, there
>> is a real existing problem with IO support on Java. I have the strong
>> feeling that most programmers want to code against one specification
>> (javax.comm) and be able to replace the underlying implementation via
>> a "plugin" on platforms where the SUN implementation is not
>> sufficient. RXTX could be just this plugin (reusing very close to 0%
>> of the javax.comm implementation but 100% of its API).
>>
>> I want to propose an API addition and implementation change that will
>> take less then 2 hours of manpower to implement and create a solution
>> that can bridge the years until javax.comm has been based on a new
>> architecture.
>>
>> Looking at the javax.comm api at http://java.sun.com/products/
>> javacomm/reference/api/index.html I would like to propose the  
>> following:
>>
>> The only entry point to javax.comm is CommPortIdentifier. It has 3
>> static methods plus the constructor.
>>
>> 1) define one additional Interface
>>
>> public interface CommProvider {
>>     CommPortIdentifier getPortIdentifier(CommPort port);
>>     CommPortIdentifier getPortIdentifier(String portName);
>>     Enumeration getPortIdentifiers ();
>> }
>>
>> 2) add one method to CommPortIdentifier
>>
>>    public static setCustomCommProvider (CommProvider);
>>
>> 3) change the three static methods of CommPortIdentifier to dispatch
>> to the CommProvider if it is set
>>
>> 4) change the constructor of CommPortIdentifier to
>>
>>    public CommPortIdentifier(...) {
>>       if (isProviderSet && this.getClass() ==
>> javax.comm.CommPortIdentifier) {
>>           throw new RuntimeException("illegal creation of
>> CommPortIndentifier, custom CommProvider is in use");
>>       }
>>
>> 5) (this is optional, but would be very nice) automatically set a
>> custom CommProvider if it is found on the classpath or defined via a
>> system property.
>>
>>
>> The above 1) - 4) can be implemented in less than 1hour. 5) may take
>> another hour. I agree that this is not the most elegant design, but
>> it would solve a lot of problems with very little effort. It would
>> certainly allow RXTX to move forward. If the javax.comm API needs to
>> be redesigned completely this addition will not hurt, as people will
>> move to the new API anyway and javax.comm 3.0 was so far never
>> included in the main distribution.
>>
>> Best regards,
>> Joachi
> I'm afraid modifying the interface classes isn't my call.  There was
> actually
> a TCK written and one of the tests was to ensure that the interface  
> classes
> match the spec.  Thus my hands have already been tied since this  
> project
> was essentially grandfathered into the JCP.
>
> That's why we need to open a new JSR and find someone who wants
> to be the spec lead, and go in with a new reference implementation.
> I'm not sure why it would have to take years, since this isn't  
> bleeding edge
> technology and there are only so many things that can be done with it,
> and we already have practical experience about many functional aspects
> that we could cite precedence on.
>
> As it becomes clear that the specification is being accepted  
> completely
> or by-and-large by the community, nothing would stop people from
> starting adapting to the new API (using the reference  
> implementation or
> porting it) and using it in their projects prior to it's final  
> community and
> JCP approval, since approval is required only to make it official and
> get the "100% pure java" certification for platform ports.
>
> You have one idea already.  Why don't you implement it, solicit some
> design feedback from Sun and the RXTX, and create a functional
> implementation that addresses the needs of the community, then
> we can document it and open a JSR.  That's it.  It should march  
> through
> the approval stages reasonably quickly I would imagine, and meantime
> RXTX could start using it.
>
> Paul
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From paul.klissner at sun.com  Fri Jun  2 14:38:49 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 13:38:49 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
	<44807ED6.8000903@sun.com>
	<6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>
Message-ID: <4480A1D9.5060106@sun.com>

Joachim Buechse wrote:
> Hello Paul,
>
> of course, the basic change I suggested could be done "hidden".  The  
> CommProvider interface could live somewhere in sun.xyz.*
> The setCustomCommProvider method would not be in CommPortIdentifier  
> but also somewhere in sun.xyz.* This would be an unofficial feature,  
> the official interface stays exactly the same. However RXTX (and  
> others) could access the hidden interface.
>
> Don't get me wrong, I don't want to harass you into making changes  
> you don't like (which probably wouldn't work anyway;-). But I'm a  
> long time Java programmer and seeing the state of cross platform  
> serial support for Java makes me feel really sad. In fact, when I  
> started to look into Java serial port programming some months ago I  
> was very surprised that javax.comm never made it into the JDK.
>
> I'm sorry that I did not contribute my feedback to the JSR for  
> javax.comm 3.0. 
There was no JSR for 3.0, because we didn't have the resources to make 
the commitment.
Yet Sun needed to add support for platform-dependent port name mapping, 
which had to
be done 'under the hood', since the API isn't designed to handle that in 
a pluggable way.
But these quick fixes aren't the right approach, they just kick the dog 
down the road,
setting bad precedent, inviting confusion and more intractable problems 
(such as the
one plaguing us now).

My changes could have been layered better, it was a trade off between 
achieving an
ideal architecture, trying to find internal reviewers, and meet the 
needs of big customers
in a timely way.  Thus my namespace changes collided with RXTX's 
dependencies.
I was unaware of Jagane's rogue agreement made with the RXTX community 7 
years ago,
before Jagane left Sun.  I think this was a wag-the-dog situation.

Now it is time to do it right, and I don't think it is going to be as 
much trouble as people
some people fear. If RXTX wants to sponsor the JSR and seed a new spec, 
Sun can join
the Expert Group.  And we'd be largely in agreement, since we're not 
talking about
humongous changes, and looking for mutually beneficial changes. The core 
API is already
largely proved and tested.
> However at the time I didn't do serial port  
> programming in Java. I agree that a new JSR should be opened - I'm  
> not an expert on JSRs or the JCP process, but from looking quickly  
> over the progress of some JSRs I would be very surprised if we can  
> have a new version in less then a year. 
*Approved*  But that doesn't mean the spec couldn't be 99.9% stable 
before that.  Once
the delta rate declines and changes approach nil, people could start 
adapting to the API in
advance of formal approval.   It isn't going to be drawn out like 
javax.usb, which was new
technology, a very complex API, and involved precedent setting corporate 
disputes and
policy issues to resolve.

> In the meanwhile some people  
> will start using javax.comm 3.0 (which can not be supported by RXTX),  
> some will use javax.comm 2.0 (which means the 2.0.7 release of RXTX  
> still needs to be maintained). This may get even worse if eg Apple  
> decides to port and include javax.comm 3.0 at which point it may get  
> very tricky to write a cross platform Java application.
>   
The interfaces haven't changed since 1.0.  If we open a JSR ,we can 
contact Apple and
allow them to be on the E.G., if they want.  That might make the JSR a 
bit more drawn out,
but then we'd arrive ultimately arrive at a best-of-all-worlds API that 
most people would
accept, perhaps forever, and arrive at a respectable set of compromises.

-Paul

> All of this simply means, that we are loosing a lot of man-power that  
> could otherwise be invested in building a clean solution and/or to  
> add features that are becoming more and more important (USB events...).
>
> In the automation / machine control universe Java makes a lot of  
> sense. Right now many people are migrating to Linux or from  
> propietary systems (even DOS) to Windows. Writing the control/ 
> configuration applications in Java is the kings way to unify the code  
> base.
>
> Best regards,
> Joachim
>
>
> On 02.06.2006, at 20:09, Paul Klissner wrote:
>
>   
>> Joachim Buechse wrote:
>>     
>>> Good day Paul!
>>>
>>> A clean architecture with loadable drivers and reusable code would be
>>> very beneficial for the future, I think everybody agrees. However
>>> this could be several years into the future. In the meantime, there
>>> is a real existing problem with IO support on Java. I have the strong
>>> feeling that most programmers want to code against one specification
>>> (javax.comm) and be able to replace the underlying implementation via
>>> a "plugin" on platforms where the SUN implementation is not
>>> sufficient. RXTX could be just this plugin (reusing very close to 0%
>>> of the javax.comm implementation but 100% of its API).
>>>
>>> I want to propose an API addition and implementation change that will
>>> take less then 2 hours of manpower to implement and create a solution
>>> that can bridge the years until javax.comm has been based on a new
>>> architecture.
>>>
>>> Looking at the javax.comm api at http://java.sun.com/products/
>>> javacomm/reference/api/index.html I would like to propose the  
>>> following:
>>>
>>> The only entry point to javax.comm is CommPortIdentifier. It has 3
>>> static methods plus the constructor.
>>>
>>> 1) define one additional Interface
>>>
>>> public interface CommProvider {
>>>     CommPortIdentifier getPortIdentifier(CommPort port);
>>>     CommPortIdentifier getPortIdentifier(String portName);
>>>     Enumeration getPortIdentifiers ();
>>> }
>>>
>>> 2) add one method to CommPortIdentifier
>>>
>>>    public static setCustomCommProvider (CommProvider);
>>>
>>> 3) change the three static methods of CommPortIdentifier to dispatch
>>> to the CommProvider if it is set
>>>
>>> 4) change the constructor of CommPortIdentifier to
>>>
>>>    public CommPortIdentifier(...) {
>>>       if (isProviderSet && this.getClass() ==
>>> javax.comm.CommPortIdentifier) {
>>>           throw new RuntimeException("illegal creation of
>>> CommPortIndentifier, custom CommProvider is in use");
>>>       }
>>>
>>> 5) (this is optional, but would be very nice) automatically set a
>>> custom CommProvider if it is found on the classpath or defined via a
>>> system property.
>>>
>>>
>>> The above 1) - 4) can be implemented in less than 1hour. 5) may take
>>> another hour. I agree that this is not the most elegant design, but
>>> it would solve a lot of problems with very little effort. It would
>>> certainly allow RXTX to move forward. If the javax.comm API needs to
>>> be redesigned completely this addition will not hurt, as people will
>>> move to the new API anyway and javax.comm 3.0 was so far never
>>> included in the main distribution.
>>>
>>> Best regards,
>>> Joachi
>>>       
>> I'm afraid modifying the interface classes isn't my call.  There was
>> actually
>> a TCK written and one of the tests was to ensure that the interface  
>> classes
>> match the spec.  Thus my hands have already been tied since this  
>> project
>> was essentially grandfathered into the JCP.
>>
>> That's why we need to open a new JSR and find someone who wants
>> to be the spec lead, and go in with a new reference implementation.
>> I'm not sure why it would have to take years, since this isn't  
>> bleeding edge
>> technology and there are only so many things that can be done with it,
>> and we already have practical experience about many functional aspects
>> that we could cite precedence on.
>>
>> As it becomes clear that the specification is being accepted  
>> completely
>> or by-and-large by the community, nothing would stop people from
>> starting adapting to the new API (using the reference  
>> implementation or
>> porting it) and using it in their projects prior to it's final  
>> community and
>> JCP approval, since approval is required only to make it official and
>> get the "100% pure java" certification for platform ports.
>>
>> You have one idea already.  Why don't you implement it, solicit some
>> design feedback from Sun and the RXTX, and create a functional
>> implementation that addresses the needs of the community, then
>> we can document it and open a JSR.  That's it.  It should march  
>> through
>> the approval stages reasonably quickly I would imagine, and meantime
>> RXTX could start using it.
>>
>> Paul
>>
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at 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  Sat Jun  3 18:15:24 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 18:15:24 -0600 (MDT)
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
Message-ID: <Pine.LNX.4.61.0606031715100.10890@www>


The attached patch allows baud rates of 14400, 28800, 128000 and 256000.

That was my goal.

[import standard disclaimer]

But I took some time to look a little further.  I got custom baud rates 
working enough that someone (perhaps me) can properly fix them in the 
future.  Proof of concept.

As an undocumented bonus, you can toss random baudrates (say 1953), at the 
API and it will set it to something close to that on windows and linux. 
Solaris should say the baud rate is not supported but I have not tested it 
yet.  Mac OS X behavior is unknown at this point.  Just dont expect 
correct behavior at ~8192-9009 baudrates or baudrates less than 20 on 
windows; these baud rates overlap with defines in win32termios.h.  I 
conveniently closed my eyes there.  Try another value close.  On Linux, a 
baud base and divisor are guestimated and set.  On windows, we wave pixie 
dust over the kernel driver and hope.  Do not expect pixie dust and 
guestimates to be the same on windows and linux.  They may well round to 
different values in yet to be tested ways.  There are only so many 
divisors.  If it isn't working, try a little higher or lower.

In the example of 1953 for instance, there is no divisor for commodity 
hardware that comes to that baudrate.  We just come close on one side or 
the other.  If tools tell you they got 1953 exactly, the tools may be 
questionable and just reading values not directly related to the actual 
hardware settings.

These fixes have been tested on Linux and Windows while using an 
oscilloscope to confirm they change relative to known baudrates at 9600, 
14400*, 19200, 28800* (and 1800, 1953** and 2400).

* = previously unsupported.
** = still not supported but probably works from what I saw.

There could be future discussion in this area.  For now this is working 
for almost all unusual baud rate demands.  Cleaning up the custom baud 
rate should be easier with a working starting point.  Baud bases other 
than 128000 have not been characterized.  Yes.. this overlapps with two of 
the baud rates enabled.

Feedback and ideas are welcome.

--
Trent Jarvi
tjarvi at qbang.org
-------------- next part --------------
Index: SerialImp.c
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v
retrieving revision 1.46.2.187
diff -u -r1.46.2.187 SerialImp.c
--- SerialImp.c	29 Jan 2006 22:19:04 -0000	1.46.2.187
+++ SerialImp.c	3 Jun 2006 23:12:40 -0000
@@ -793,6 +793,19 @@
 		result &= ~TIOCM_DTR;
 		ioctl( fd, TIOCMSET, &result );
 	}
+	/*
+	   B38400 is a special case in Linux for custom baud rates.
+
+	   We just treat this as a custom speed for now.  If you take this ifdef
+	   out and select baud rates 38400 then 28800 then 38400, you will get
+	   a final baud rate of 28800 because you did not update the divisor.
+
+	   See the next ifdef below for the divisor.
+	*/
+#if defined(TIOCGSERIAL)
+	if ( cspeed == B38400 )
+		cspeed = 38400;
+#endif /* TIOCGSERIAL */
 	if(     cfsetispeed( &ttyset, cspeed ) < 0 ||
 		cfsetospeed( &ttyset, cspeed ) < 0 )
 	{
@@ -814,6 +827,7 @@
 		*/
 
 #if defined(TIOCGSERIAL)
+		ioctl( fd, TIOCGSERIAL, &sstruct );
 		sstruct.custom_divisor = ( sstruct.baud_base/cspeed );
 		cspeed = B38400;
 #endif /* TIOCGSERIAL */
@@ -827,7 +841,7 @@
 #if defined(TIOCSSERIAL)
 		/*  It is assumed Win32 does this for us */
 		if (	sstruct.baud_base < 1 ||
-			ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
+		ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
 		{
 			return( 1 );
 		}
Index: termios.c
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v
retrieving revision 1.9.2.56
diff -u -r1.9.2.56 termios.c
--- termios.c	16 Jan 2006 02:50:32 -0000	1.9.2.56
+++ termios.c	3 Jun 2006 23:12:40 -0000
@@ -323,8 +323,8 @@
 		case CBR_3500000:	return( B3500000 );
 		case CBR_4000000:	return( B4000000 );
 		default:
-			set_errno(EINVAL );
-			return -1;
+			/* assume custom baudrate */
+			return( Baud );
 	}
 }
 
@@ -361,12 +361,13 @@
 		case B9600:	ret = CBR_9600;		break;
 		case B14400:	ret = CBR_14400;	break;
 		case B19200:	ret = CBR_19200;	break;
+		case B28800:	ret = CBR_28800;	break;
 		case B38400:	ret = CBR_38400;	break;
 		case B57600:	ret = CBR_57600;	break;
 		case B115200:	ret = CBR_115200;	break;
 		case B128000:	ret = CBR_128000;	break;
-		case B256000: 	ret = CBR_256000;	break;
 		case B230400:	ret = CBR_230400;	break;
+		case B256000: 	ret = CBR_256000;	break;
 		case B460800:	ret = CBR_460800;	break;
 		case B500000:	ret = CBR_500000;	break;
 		case B576000:	ret = CBR_576000;	break;
@@ -381,10 +382,8 @@
 		case B4000000:	ret = CBR_4000000;	break;
 	
 		default:
-			fprintf( stderr, "B_to_CBR: invalid baudrate: %#o\n",
-				Baud );
-			set_errno( EINVAL );
-			return -1;
+			/* assume custom baudrate */
+			return Baud;
 	}
 	LEAVE( "B_to_CBR" );
 	return ret;
@@ -708,12 +707,9 @@
 	ENTER( "init_serial_struct" );
 
 	/*
-	FIXME
-
-	This needs to use inb() to read the actual baud_base
-	and divisor from the UART registers.  Question is how
-	far do we take this?
-
+	use of custom_divisor and baud_base requires access to
+	kernel space.  The kernel does try its best if you just
+	toss a baud rate at it though.
 	*/
 
 	sstruct->custom_divisor = 0;
@@ -1678,16 +1674,17 @@
 {
 	char message[80];
 	ENTER( "cfsetospeed" );
+	/* clear baudrate */
+	s_termios->c_cflag &= ~CBAUD;
 	if ( speed & ~CBAUD )
 	{
 		sprintf( message, "cfsetospeed: not speed: %#o\n", speed );
 		report( message );
-		return 0;
+		/* continue assuming its a custom baudrate */
+		s_termios->c_cflag |= B38400;  /* use 38400 during custom */
+		s_termios->c_cflag |= CBAUDEX; /* use CBAUDEX for custom */
 	}
-	s_termios->c_ispeed = s_termios->c_ospeed = speed;
-	/* clear baudrate */
-	s_termios->c_cflag &= ~CBAUD;
-	if( speed )
+	else if( speed )
 	{
 		s_termios->c_cflag |= speed;
 	}
@@ -1696,6 +1693,7 @@
 		/* PC blows up with speed 0 handled in Java */
 		s_termios->c_cflag |= B9600;
 	}
+	s_termios->c_ispeed = s_termios->c_ospeed = speed;
 	LEAVE( "cfsetospeed" );
 	return 1;
 }
@@ -1767,25 +1765,6 @@
 }
 
 /*----------------------------------------------------------
-serial_struct_to_DCB()
-
-   accept:      
-   perform:     
-   return:      
-   exceptions:  
-   win32api:     None
-   comments:    
-----------------------------------------------------------*/
-int serial_struct_to_DCB( struct serial_struct *sstruct, DCB *dcb )
-{
-	/* 5 Baud rate fix
-	sstruct.baud_base
-	sstruct.custom_divisor = ( sstruct.baud_base/cspeed );
-	*/
-	return(0);
-}
-
-/*----------------------------------------------------------
 termios_to_DCB()
 
    accept:      
@@ -1798,7 +1777,8 @@
 int termios_to_DCB( struct termios *s_termios, DCB *dcb )
 {
 	ENTER( "termios_to_DCB" );
-	s_termios->c_ispeed = s_termios->c_ospeed = s_termios->c_cflag & CBAUD;
+	if ( !(s_termios->c_cflag & CBAUDEX) )
+		s_termios->c_ispeed = s_termios->c_ospeed = s_termios->c_cflag & CBAUD;
 	dcb->BaudRate        = B_to_CBR( s_termios->c_ispeed );
 	dcb->ByteSize = termios_to_bytesize( s_termios->c_cflag );
 
@@ -2863,11 +2843,6 @@
 			GetCommState( index->hComm, dcb );
 
 			index->sstruct = va_arg( ap, struct serial_struct * );
-			if ( serial_struct_to_DCB( index->sstruct, dcb ) < 0 )
-			{
-				va_end( ap );
-				return -1;
-			}
 
 			report( "TIOCSSERIAL\n" );
 			free(dcb);
Index: win32termios.h
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v
retrieving revision 1.5.2.28
diff -u -r1.5.2.28 win32termios.h
--- win32termios.h	30 Jun 2005 20:23:26 -0000	1.5.2.28
+++ win32termios.h	3 Jun 2006 23:12:40 -0000
@@ -279,7 +279,7 @@
 #define XTABS	01000000 /* Hmm.. Linux/i386 considers this part of TABDLY.. */
 
 /* c_cflag bit meaning */
-# define CBAUD	0010017
+#define  CBAUD  0030017
 #define  B0	0000000		/* hang up */
 #define  B50	0000001
 #define  B75	0000002
@@ -312,13 +312,16 @@
 #define  B3500000 0010016
 #define  B4000000 0010017
 
-/* glue for unsupported linux speeds see also SerialImp.h */
-/* hosed */
-
-#define B14400		1010001
-#define B28800		1010002
-#define B128000		1010003
-#define B256000		1010004
+/*
+	glue for unsupported linux speeds see also SerialImp.h 
+	custom baud rates around 8192-9000 will not work because
+	of these.
+*/
+
+#define B14400		0020001
+#define B28800		0020002
+#define B128000		0020003
+#define B256000		0020004
 
 #define EXTA B19200
 #define EXTB B38400
@@ -356,8 +359,10 @@
 
 /* glue for unsupported windows speeds */
 
-#define CBR_230400	230400
 #define CBR_28800	28800
+#define CBR_128000	128000
+#define CBR_230400	230400
+#define CBR_256000	256000
 #define CBR_460800	460800
 #define CBR_500000	500000
 #define CBR_576000	576000

From impakt01 at optusnet.com.au  Sat Jun  3 18:30:37 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 10:30:37 +1000
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
In-Reply-To: <Pine.LNX.4.61.0606031715100.10890@www>
Message-ID: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>

Hi Trent,
I'd love to try the patch but I can't get the latest build compiling, only
pre16. 

Can you attach the rxtxSerial.dll file with this patch?

Also, I hardcoded 1953 in a couple more places last night on pre16 and it
managed to open the port at the right speed, but stopped receiving anything
after 100-150 bytes, even though more data was getting sent to the port.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 10:15 AM
To: rxtx at qbang.org
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.


The attached patch allows baud rates of 14400, 28800, 128000 and 256000.

That was my goal.

[import standard disclaimer]

But I took some time to look a little further.  I got custom baud rates 
working enough that someone (perhaps me) can properly fix them in the 
future.  Proof of concept.

As an undocumented bonus, you can toss random baudrates (say 1953), at the 
API and it will set it to something close to that on windows and linux. 
Solaris should say the baud rate is not supported but I have not tested it 
yet.  Mac OS X behavior is unknown at this point.  Just dont expect 
correct behavior at ~8192-9009 baudrates or baudrates less than 20 on 
windows; these baud rates overlap with defines in win32termios.h.  I 
conveniently closed my eyes there.  Try another value close.  On Linux, a 
baud base and divisor are guestimated and set.  On windows, we wave pixie 
dust over the kernel driver and hope.  Do not expect pixie dust and 
guestimates to be the same on windows and linux.  They may well round to 
different values in yet to be tested ways.  There are only so many 
divisors.  If it isn't working, try a little higher or lower.

In the example of 1953 for instance, there is no divisor for commodity 
hardware that comes to that baudrate.  We just come close on one side or 
the other.  If tools tell you they got 1953 exactly, the tools may be 
questionable and just reading values not directly related to the actual 
hardware settings.

These fixes have been tested on Linux and Windows while using an 
oscilloscope to confirm they change relative to known baudrates at 9600, 
14400*, 19200, 28800* (and 1800, 1953** and 2400).

* = previously unsupported.
** = still not supported but probably works from what I saw.

There could be future discussion in this area.  For now this is working 
for almost all unusual baud rate demands.  Cleaning up the custom baud 
rate should be easier with a working starting point.  Baud bases other 
than 128000 have not been characterized.  Yes.. this overlapps with two of 
the baud rates enabled.

Feedback and ideas are welcome.

--
Trent Jarvi
tjarvi at qbang.org



From tjarvi at qbang.org  Sat Jun  3 19:05:11 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 19:05:11 -0600 (MDT)
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
In-Reply-To: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>
References: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606031840400.10890@www>

On Sun, 4 Jun 2006, Daren wrote:

> Hi Trent,
> I'd love to try the patch but I can't get the latest build compiling, only
> pre16.
>
> Can you attach the rxtxSerial.dll file with this patch?
>
> Also, I hardcoded 1953 in a couple more places last night on pre16 and it
> managed to open the port at the right speed, but stopped receiving anything
> after 100-150 bytes, even though more data was getting sent to the port.
>


ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing

I dont think they will hang.  But I was just testing via loopback/break 
out box/scope.

I'll be putting about 10 patches and another set of binaries in that 
directory shortly.  For now the binaries should just have the baud_rate 
fix.

I'll announce all the patches at once.  but wont be releasing 2.1-8 right 
away.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Sat Jun  3 21:00:01 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 21:00:01 -0600 (MDT)
Subject: [Rxtx] CVS for 2.1 should have everything
Message-ID: <Pine.LNX.4.61.0606032056190.10890@www>


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org


From impakt01 at optusnet.com.au  Sat Jun  3 21:08:14 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 13:08:14 +1000
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <Pine.LNX.4.61.0606032056190.10890@www>
Message-ID: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>

Hi Trent,
I tried the latest dll and it opens the port, receives 100-200 bytes and
then stops receiving anything else..

I'll keep playing with it.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 1:00 PM
To: rxtx at qbang.org
Subject: [Rxtx] CVS for 2.1 should have everything


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From impakt01 at optusnet.com.au  Sat Jun  3 21:22:41 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 13:22:41 +1000
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
Message-ID: <200606040322.k543MqW1008455@mail12.syd.optusnet.com.au>

Played with it, problem, with a while loop in my code, working great now

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Daren
Sent: Sunday, 4 June 2006 1:08 PM
To: 'RXTX Developers and Users'
Subject: Re: [Rxtx] CVS for 2.1 should have everything

Hi Trent,
I tried the latest dll and it opens the port, receives 100-200 bytes and
then stops receiving anything else..

I'll keep playing with it.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 1:00 PM
To: rxtx at qbang.org
Subject: [Rxtx] CVS for 2.1 should have everything


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Sat Jun  3 21:35:41 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 21:35:41 -0600 (MDT)
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
References: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606032131140.10890@www>

On Sun, 4 Jun 2006, Daren wrote:

> Hi Trent,
> I tried the latest dll and it opens the port, receives 100-200 bytes and
> then stops receiving anything else..
>
> I'll keep playing with it.
>
> Daren

The difference may be that I'm talking to something at the exact same baud 
rate (loopback).

You may also try setting the baudrate to ~1933 and ~1973 to force the 
guesses one way or the other.  If you are on windows, we are not doing 
anything fancy in the end.  Thats the kernel guessing.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sun Jun  4 04:12:09 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sun, 4 Jun 2006 12:12:09 +0200
Subject: [Rxtx] Update of OSX installer, Readme, etc
Message-ID: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>

Good day,

after the latest changes a lot of OS X specific files should be  
updated. Especially the installer!

- The "MaxOSX" readme file on the root level is outdated (ie  
CodeWarrior information). Maybe we could even rename it to README.OSX  
to be in line with README.IPAQ, README.SCO (Trent do you mind copying/ 
renaming ,v files in the repository?).

- The lock files are no longer used and hence the user group magic  
and lock folder creation should be removed from the installer.

- MACOSX_IDE/ForPackageMaker/Resources/ReadMe.rtf and Welcome.rtf  
need to be updated.

- I suggest to replace the current installation instruction for OS X:  
Installation should occur into the application directory, not in the  
Java-VM directory. This simplifies things a lot, as the Mac Installer  
can be removed completely.

- The xcodeproject's build settings need to be updated to generate  
JAVA 1.1 format class files.


Dimitry: do you have time to tackle this? I could do it, but as this  
is "your baby" I thought you may prefer to do it yourself.

Regards,
Joachim



From dmarkman at mac.com  Sun Jun  4 11:27:53 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Sun, 4 Jun 2006 13:27:53 -0400
Subject: [Rxtx] Update of OSX installer, Readme, etc
In-Reply-To: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
References: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
Message-ID: <26E7A202-962B-4C19-93B6-29426C467249@mac.com>

Joachim,
unfortunately I don't have time right now to do that
so if you can do that, please do

it's not only my baby
it's yours too :-)

thanks


On Jun 4, 2006, at 6:12 AM, Joachim Buechse wrote:

> Good day,
>
> after the latest changes a lot of OS X specific files should be
> updated. Especially the installer!
>
> - The "MaxOSX" readme file on the root level is outdated (ie
> CodeWarrior information). Maybe we could even rename it to README.OSX
> to be in line with README.IPAQ, README.SCO (Trent do you mind copying/
> renaming ,v files in the repository?).
>
> - The lock files are no longer used and hence the user group magic
> and lock folder creation should be removed from the installer.
>
> - MACOSX_IDE/ForPackageMaker/Resources/ReadMe.rtf and Welcome.rtf
> need to be updated.
>
> - I suggest to replace the current installation instruction for OS X:
> Installation should occur into the application directory, not in the
> Java-VM directory. This simplifies things a lot, as the Mac Installer
> can be removed completely.
>
> - The xcodeproject's build settings need to be updated to generate
> JAVA 1.1 format class files.
>
>
> Dimitry: do you have time to tackle this? I could do it, but as this
> is "your baby" I thought you may prefer to do it yourself.
>
> Regards,
> Joachim
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman



From tjarvi at qbang.org  Sun Jun  4 13:54:02 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 4 Jun 2006 13:54:02 -0600 (MDT)
Subject: [Rxtx] Update of OSX installer, Readme, etc
In-Reply-To: <26E7A202-962B-4C19-93B6-29426C467249@mac.com>
References: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
	<26E7A202-962B-4C19-93B6-29426C467249@mac.com>
Message-ID: <Pine.LNX.4.61.0606041353040.22522@www>

On Sun, 4 Jun 2006, Dmitry Markman wrote:

> Joachim,
> unfortunately I don't have time right now to do that
> so if you can do that, please do
>
> it's not only my baby
> it's yours too :-)
>

I've given Joachim cvs access.  He has shown good work in bugzilla.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Mon Jun  5 10:08:32 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 5 Jun 2006 18:08:32 +0200
Subject: [Rxtx] Build process changes for Mac OS X
Message-ID: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>

Good day,

I have cleaned up some outdated Mac OSX specific build files in the  
repository.

There was not a lot left of the readme file "MacOSX" after cleaning  
it up, so I decided to rename it README.OSX to be in harmony with the  
other files in the directory (ie README.IPAQ, README.SCO, ...)

I added an (uncompressed) XCode 2.3 project file/structure  
with .cvsignore files that will ignore the user specific settings.  
This should work "out of the box" for OSX10.4. Users of 10.2/10.3 may  
have to switch the build settings.

[It's kind of tricky to choose "the right" setting. Afaik there is no  
way to compile a universal binary that will work on 10.3 or before.  
So it's either UniversalBinary OR Legacy. Maybe we should have  
different build targets for these different targets?? I would like to  
get some feedback from the Mac developers on this list regarding the  
subject].

Besides other things the OSX installer is no longer required. Since  
the next version (2.1.8) will no longer use lockfiles on OSX, the  
group/permission magic is no longer required and hence there remains  
basicly no work for the installer - other than copying 2 files to the  
VM extension directory. Then again, this is not the best way to  
install RXTX. So I removed the installer completely without modifying  
it, this should simplify a "resurrection" should it ever get necessary.

I had problems with the (compressed, ie sit.hqx) legacy project files  
on the latest installation of OSX (javac 1.5 creating non JDK1.1  
class files and some minor problems). To reduce potential confusion  
for newcomers I decided to remove them. This means that there is no  
longer a simple way to build RXTX for OSX 10.0 and 10.1 (I deeply  
apologize if anyone still relied on this ... well the files are in  
the Attiq).

Best regards,
Joachim


From joachim at buechse.de  Mon Jun  5 10:16:37 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 5 Jun 2006 18:16:37 +0200
Subject: [Rxtx] RXTX and lockfiles on OSX [it is fixed now]
Message-ID: <7D2C4418-9397-4B59-8091-9FDE4ED67836@buechse.de>

Quite a number of people contacted me in the last couple of weeks  
because of problems installing RXTX on OSX. I told you to wait for  
the "official" fix. Well, it has been fixed.

So if you were among the people waiting for the solution, you can now  
download the source rxtx-2.1-7r2.zip from the website. Once unpacked  
dont forget to use "cvs up" to update the files to the latest  
version. You can then open MACOSX_IDE/XCode/ 
LibSerialUniversal.xcodeproj with XCode 2.3 and build the libraries  
that no longer try to create lock files.

Regards,
Joachim


From brian at mbari.org  Mon Jun  5 10:52:43 2006
From: brian at mbari.org (Brian Schlining)
Date: Mon, 5 Jun 2006 09:52:43 -0700
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
Message-ID: <78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>

Hi Joachim,

> [It's kind of tricky to choose "the right" setting. Afaik there is no
> way to compile a universal binary that will work on 10.3 or before.
> So it's either UniversalBinary OR Legacy. Maybe we should have
> different build targets for these different targets?? I would like to
> get some feedback from the Mac developers on this list regarding the
> subject].

I imagine most developers will be compiling on 10.4 (It's the nature  
of the coder...gotta have the latest and greatest) and deploying to  
both 10.3 and 10.4; both of which will run Universal Binaries (see  
http://forums.macrumors.com/showthread.php?t=205348). So it sounds  
like you've covered the majority of users. Still, you know someone's  
going to pipe up about needing RXTX on 10.2 so it would be nice to  
have a target to make a PPC only build.

Just my 2 cents

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/1cac8c39/attachment-0007.html

From dmarkman at mac.com  Mon Jun  5 13:47:50 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Mon, 5 Jun 2006 15:47:50 -0400
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
Message-ID: <686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>

I don't think it will be a problem to run universal binary
on 10.2
however if binary has some calls that aren't implemented in 10.2
then you'll have a problem


On Jun 5, 2006, at 12:52 PM, Brian Schlining wrote:

> Hi Joachim,
>
>> [It's kind of tricky to choose "the right" setting. Afaik there is no
>> way to compile a universal binary that will work on 10.3 or before.
>> So it's either UniversalBinary OR Legacy. Maybe we should have
>> different build targets for these different targets?? I would like to
>> get some feedback from the Mac developers on this list regarding the
>> subject].
>
> I imagine most developers will be compiling on 10.4 (It's the  
> nature of the coder...gotta have the latest and greatest) and  
> deploying to both 10.3 and 10.4; both of which will run Universal  
> Binaries (see http://forums.macrumors.com/showthread.php?t=205348).  
> So it sounds like you've covered the majority of users. Still, you  
> know someone's going to pipe up about needing RXTX on 10.2 so it  
> would be nice to have a target to make a PPC only build.
>
> Just my 2 cents
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/9fafc878/attachment-0007.html

From brian at mbari.org  Mon Jun  5 14:52:41 2006
From: brian at mbari.org (Brian Schlining)
Date: Mon, 5 Jun 2006 13:52:41 -0700
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
Message-ID: <E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>

Hi Dmitry,

> I don't think it will be a problem to run universal binary
> on 10.2
> however if binary has some calls that aren't implemented in 10.2
> then you'll have a problem

You're right...I stand corrected.

Note however, to deploy a universal binary to 10.2 RXTX will need to  
use the 10.2 SDK to build the PPC side. (see http:// 
developer.apple.com/documentation/DeveloperTools/Conceptual/ 
cross_development/UniversalBinaries/chapter_4_section_1.html). I  
haven't been paying close attention to the new locking mechanism used  
by RXTX on the Mac...does 10.2 support it?

Joachim, which SDK will you be using by default for building the Mac  
PPC binaries?

>> Hi Joachim,
>>
>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>> is no
>>> way to compile a universal binary that will work on 10.3 or before.
>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>> different build targets for these different targets?? I would  
>>> like to
>>> get some feedback from the Mac developers on this list regarding the
>>> subject].
>>
>> I imagine most developers will be compiling on 10.4 (It's the  
>> nature of the coder...gotta have the latest and greatest) and  
>> deploying to both 10.3 and 10.4; both of which will run Universal  
>> Binaries (see http://forums.macrumors.com/showthread.php? 
>> t=205348). So it sounds like you've covered the majority of users.  
>> Still, you know someone's going to pipe up about needing RXTX on  
>> 10.2 so it would be nice to have a target to make a PPC only build.

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/153bf50e/attachment-0007.html

From dmarkman at mac.com  Mon Jun  5 19:02:04 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Mon, 5 Jun 2006 21:02:04 -0400
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
Message-ID: <7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>

if Joachim didn't change xcode project setting

/Developer/SDKs/MacOSX10.4u.sdk is used to build universal binary

so it's quite possible that it won't run properly on 10.2

so we have to change the building process, so ppc part will be built
with
/Developer/SDKs/MacOSX10.2.8.sdk

and finally to use lipo utility to build universal binaries

Joachim, did you use some specific locking API that wasn't implemented

in MacOSX10.2.8.sdk?

thanks


On Jun 5, 2006, at 4:52 PM, Brian Schlining wrote:

> Hi Dmitry,
>
>> I don't think it will be a problem to run universal binary
>> on 10.2
>> however if binary has some calls that aren't implemented in 10.2
>> then you'll have a problem
>
> You're right...I stand corrected.
>
> Note however, to deploy a universal binary to 10.2 RXTX will need  
> to use the 10.2 SDK to build the PPC side. (see http:// 
> developer.apple.com/documentation/DeveloperTools/Conceptual/ 
> cross_development/UniversalBinaries/chapter_4_section_1.html). I  
> haven't been paying close attention to the new locking mechanism  
> used by RXTX on the Mac...does 10.2 support it?
>
> Joachim, which SDK will you be using by default for building the  
> Mac PPC binaries?
>
>>> Hi Joachim,
>>>
>>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>>> is no
>>>> way to compile a universal binary that will work on 10.3 or before.
>>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>>> different build targets for these different targets?? I would  
>>>> like to
>>>> get some feedback from the Mac developers on this list regarding  
>>>> the
>>>> subject].
>>>
>>> I imagine most developers will be compiling on 10.4 (It's the  
>>> nature of the coder...gotta have the latest and greatest) and  
>>> deploying to both 10.3 and 10.4; both of which will run Universal  
>>> Binaries (see http://forums.macrumors.com/showthread.php? 
>>> t=205348). So it sounds like you've covered the majority of  
>>> users. Still, you know someone's going to pipe up about needing  
>>> RXTX on 10.2 so it would be nice to have a target to make a PPC  
>>> only build.
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/84790f80/attachment-0007.html

From joachim at buechse.de  Tue Jun  6 02:40:47 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 6 Jun 2006 10:40:47 +0200
Subject: [Rxtx] Building on OS X, Impl Changes
In-Reply-To: <7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
Message-ID: <CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>

Good day!

What's in the XCode project setting?
----------

The xcode project remained pretty much the same as before. I excluded  
the user specific files from CVS and changed some settings. I kept  
all the built targets (you shouldn't change what you don't understand;-)

Currently we the following build targets:
    RXTXComm (java files)
    librxtxParallel.jnilib (usefull on the Mac???)
    libI2C.jnilib (not yet working in RXTX)
    libRS485.jnilib (not yet working in RXTX)
    librxtxSerial.jnilib (1)
    librxtxSerial.jnilib Dynamic (2)
    rxtxSerial (3)
We also have the following build configurations for each target:
    Development
    Default
    Deployment

What was changed in the xcode project from previous versions:
- java.souce=1.3 and java.target=1.1 in RXTXComm settings
- removed copying of build products into installer directory
- removed "(Upgraded)" from build target names

What remains to be changed:
- choosing a "non-debug" Build-configuration as default
- potentially removing "Default"/"Development" Build-configurations
- reducing the number of build targets
- creating 10.2 compatible universal binaries

I suggest, that the build configurations should be reduced to 2  
(Debug/Deployment), possibly even 1 (Debug).
I have not yet found the deeper meaning of the build targets(1)(2) 
(3), it seems to me like they should be reduced into one "doing the  
right thing" or maybe into two "rxtxSerial.jnilib Legacy" (back to  
10.2, universal if possible) and "rxtxSerial.jnilib 10.4 
+" (universal, 10.4+).

Should the code work on 10.2?
----------

Absolutely. The code should work on NextStep, in fact on any BSD  
unix. I would go as far as saying, this code should work on any  
POSSIX based unix. All that was added is the call "ioctl(fd,  
TIOCEXCL)" to request excusivity of the port:

http://gemma.apple.com/documentation/DeviceDrivers/Conceptual/ 
WorkingWSerial/WWSerial_SerialDevs/chapter_2_section_8.html

It is not yet "the perfect solution". Normally an open /dev/tty  
(listen for incomming connection) should be "preemptable" by opening  
a /dev/cu (outgoing connection) for the same port. This is not yet  
implemented as it needs calls outside of POSSIX on OSX.

On "classic" systems (like NextStep) this worked based on the  
"carried detect line". open() on /dev/tty.xxx would block until the  
carrier detect signal was raised. As the device was not "opened"  
opening /dev/cu.xxx worked without a hitch. When they ported to the  
Mac this broke. On Macs the "carier detect" is usually not wired.  
Furthermore FAX modems did no longer raise the line. So the OSX  
implementor defined a new call, which is documented here:

http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00045.html

Best regards,
Joachim




On 06.06.2006, at 03:02, Dmitry Markman wrote:

> if Joachim didn't change xcode project setting
>
> /Developer/SDKs/MacOSX10.4u.sdk is used to build universal binary
>
> so it's quite possible that it won't run properly on 10.2
>
> so we have to change the building process, so ppc part will be built
> with
> /Developer/SDKs/MacOSX10.2.8.sdk
>
> and finally to use lipo utility to build universal binaries
>
> Joachim, did you use some specific locking API that wasn't implemented
>
> in MacOSX10.2.8.sdk?
>
> thanks
>
>
> On Jun 5, 2006, at 4:52 PM, Brian Schlining wrote:
>
>> Hi Dmitry,
>>
>>> I don't think it will be a problem to run universal binary
>>> on 10.2
>>> however if binary has some calls that aren't implemented in 10.2
>>> then you'll have a problem
>>
>> You're right...I stand corrected.
>>
>> Note however, to deploy a universal binary to 10.2 RXTX will need  
>> to use the 10.2 SDK to build the PPC side. (see http:// 
>> developer.apple.com/documentation/DeveloperTools/Conceptual/ 
>> cross_development/UniversalBinaries/chapter_4_section_1.html). I  
>> haven't been paying close attention to the new locking mechanism  
>> used by RXTX on the Mac...does 10.2 support it?
>>
>> Joachim, which SDK will you be using by default for building the  
>> Mac PPC binaries?
>>
>>>> Hi Joachim,
>>>>
>>>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>>>> is no
>>>>> way to compile a universal binary that will work on 10.3 or  
>>>>> before.
>>>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>>>> different build targets for these different targets?? I would  
>>>>> like to
>>>>> get some feedback from the Mac developers on this list  
>>>>> regarding the
>>>>> subject].
>>>>
>>>> I imagine most developers will be compiling on 10.4 (It's the  
>>>> nature of the coder...gotta have the latest and greatest) and  
>>>> deploying to both 10.3 and 10.4; both of which will run  
>>>> Universal Binaries (see http://forums.macrumors.com/ 
>>>> showthread.php?t=205348). So it sounds like you've covered the  
>>>> majority of users. Still, you know someone's going to pipe up  
>>>> about needing RXTX on 10.2 so it would be nice to have a target  
>>>> to make a PPC only build.
>>
>> Brian Schlining
>> Software Engineer
>> http://www.mbari.org
>>
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> Dmitry Markman
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Tue Jun  6 07:01:06 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 6 Jun 2006 15:01:06 +0200
Subject: [Rxtx] Serial port code for OS X, future steps
In-Reply-To: <CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
	<CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
Message-ID: <8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>

I posted the "wrong link". There is a correction here:

    http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00059.html

In fact, the 2.1.7 implementation of RXTX has quite some deficiencies  
on OSX. I have tried to supply some patches that don't interfere to  
much with the existing RXTX code base, but there are limits to what  
can be done with local patches.

There are some very intrusive changes that should be done. Ie proper  
mapping of /dev/tty <-> /dev/cu handling to correct behaviour of  
CommPortOwnershipListener (http://java.sun.com/products/javacomm/ 
reference/api/index.html). I dont think this can be done with  
patches. Hence I think, RXTX should be rewritten from scratch de- 
unifying the native code base (and implementing thread safe code on  
the Java side).


How "should" /dev/tty vs /dev/cu be implemented?

=====
The Unix contract is this: An open /dev/tty.xxx port (incomming)  
should be interrupted/auto-closed when opening /dev/cu.xxx (outgoing)  
[if /dev/tty.xxx is not currently handling a communication].  /dev/ 
cu.xxx and /dev/tty.xxx refer to the same device, so owning  
"exclusively" should block both. This should be respected across all  
applications native or Java.

This contract is realizable on OSX with the existing javax.comm  
interface while also respecting (to the biggest part) the contract  
defined by javax.comm.PortOwnershipListener.

The one point where the suggested implementation "breaks" the  
javax.comm contract, is by the fact that one can loose a /dev/tty  
port without calling close. However, the only option I see is to  
always open serial ports "non-exclusively" which would outrule Java  
as a platform for (dormant) applications waiting for incoming  
connections/faxes/etc. There could be a system property to choose the  
intended behavior.
=====

Here is how it could be done on OSX:

Calling port=ComportIdentifier.open("/dev/cu.xxx") opens and owns the  
port exclusively until port.close() is called.
- Java applications listening with a PortOwnershipListener should get  
a PORT_OWNED event reasonably soon.
- Any further attempt by a Java or native application to open "/dev/ 
cu.xxx" or "/dev/tty.xxx" fails.
- /dev/cu.xxx is for "outgoing" connections, so receiving  
PORT_OWNERSHIP_REQUESTED makes little to no sense. With native  
applications it can not be implemented. For Java applications it  
could be implemented (by a hidden communication channel). I think  
it's not worth bothering. If anyone is willing to give up a port to  
others he should use /dev/tty.xxx instead of /dev/cu.xxx.

Registering a PortOwnershipListener on "/dev/cu.xxx" without opening  
it, uses /dev/tty.xxx (native open()) non-exclusively and polls its  
state. PORT_OWNED and PORT_UNOWNED can be produced.

Calling port=ComportIdentifier.open("/dev/tty.xxx") should open the  
port non-exclusively.
- Adding a SerialPortEventListener and reading from the port could be  
allowed while keeping it non-exclusive.
- When port.getOutputStream() is called, the state should be changed  
to an "exclusive" ownership. This may be configurable via a system  
property.
- To return to the non-exclusive state the port must be closed and  
reopened.
- While non-exclusively opened, opening the corresponding /dev/cu.xxx  
produces a PORT_OWNERSHIP_REQUESTED event. Which should be responded  
by closing the port from within the callback (as described in  
java.comm.PortOwnershipListener). If there is a pending read, it will  
return after the listener finishes (with -1 or "0 bytes read").
- Calling write() on the /dev/tty.xxx after somebody opened /dev/ 
cu.xxx will fail with a descriptive IOException.
- Calling read() on the /dev/tty.xxx after somebody opened /dev/ 
cu.xxx will fail with a descriptive IOException (or potentially  
block, see side notes below).

CommPortIdentifier.getCurrentOwner() can be implemented by an  
external call to lsof.

CommPortIdentifier.isCurrentlyOwned() can be implemented by trying an  
open on the /dev/tty.
- It returns true if the port is currently held "exclusively".
- Whether it should also return true on /dev/tty if /dev/tty is  
already opened non-exclusively might be a system property option. In  
general, having several applications waiting for incoming connections  
on the same port will require an application level "arbitration"  
protocol...

[[side note1: One interesting question is, what happens if the  
process holding /dev/tty non-exclusively ignores  
PORT_OWNERSHIP_REQUESTED. Ie after "loosing" a non-exclusively opened  
"dev/tty.xxx" port to another process. One possible implementation  
is, that the port is "regained" when the other process gives up the  
port. This would mean that in the meanwhile read() returns no data,  
and any changes to the configuration of the port are stored but not  
forwarded. I guess, the safe (and simple) way to do this is to make  
the close() mandatory (ie setting the port into an "awaiting_close"  
state which produces IOExceptions to any other call than close). ]]

[[side note2:  Another interesting question is, what should happen if  
several applications open the same /dev/tty.xxx port "non- 
exclusively" and start to change the settings of the device.]]

Regards,
Joachim



On 06.06.2006, at 10:40, Joachim Buechse wrote:

> Should the code work on 10.2?
> ----------
>
> Absolutely. The code should work on NextStep, in fact on any BSD
> unix. I would go as far as saying, this code should work on any
> POSSIX based unix. All that was added is the call "ioctl(fd,
> TIOCEXCL)" to request excusivity of the port:
>
> http://gemma.apple.com/documentation/DeviceDrivers/Conceptual/
> WorkingWSerial/WWSerial_SerialDevs/chapter_2_section_8.html
>
> It is not yet "the perfect solution". Normally an open /dev/tty
> (listen for incomming connection) should be "preemptable" by opening
> a /dev/cu (outgoing connection) for the same port. This is not yet
> implemented as it needs calls outside of POSSIX on OSX.
>
> On "classic" systems (like NextStep) this worked based on the
> "carried detect line". open() on /dev/tty.xxx would block until the
> carrier detect signal was raised. As the device was not "opened"
> opening /dev/cu.xxx worked without a hitch. When they ported to the
> Mac this broke. On Macs the "carier detect" is usually not wired.
> Furthermore FAX modems did no longer raise the line. So the OSX
> implementor defined a new call, which is documented here:
>
> http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00045.html
>
> Best regards,
> Joachim



From sds at dcs.gla.ac.uk  Tue Jun  6 11:22:45 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Tue, 06 Jun 2006 18:22:45 +0100
Subject: [Rxtx] Correct compile flag for HP iPAQ hx4700 running Familiar
	Linux?
Message-ID: <1149614565.19496.10.camel@addu>

Hi,

I'd like to use RXTX 2.1 on my HP iPAQ hx4700. The iPAQ is running
Familiar Linux 0.8.2 (as I recall), with Blackdown Java 1.3.1.

I can compile and run a test program which uses RXTX on my i686 machine,
and it works fine. But I can't seem to get things working quite right on
my PDA.

I compile the code on the laptop with the following commands:
	./configure --host=arm-gnu-linux && make
... as suggested in a post to this list, albeit some time ago. This
compiles, I transfer the files, set up LD_LIBRARY_PATH and CLASSPATH
variables, and get the following error on the PDA:

sds at ipaq-pxa-2:~# java Test
java.lang.UnsatisfiedLinkError: /usr/local/lib/ext/librxtxSerial.so: /usr/local/lib/ext/librxtxSerial.so: cannot open shared object file: No such file or directory thrown while loading gnu.io.RXTXCommDriver
Exception in thread "main"
java.lang.UnsatisfiedLinkError: /usr/local/lib/ext/librxtxSerial.so: /usr/local/lib/ext/librxtxSerial.so: cannot open shared object file: No such file or directory
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1382)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1290)
        at java.lang.Runtime.loadLibrary0(Runtime.java:749)
        at java.lang.System.loadLibrary(System.java:820)
        at
gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:83)
        at Test.<init>(Test.java:9)
        at Test.main(Test.java:32)
sds at ipaq-pxa-2:~# 

Note that I'm copying the files to /usr/local/lib/ext/ along with the
RXTXcomm.jar file, purely to keep things separate from the rest of the
system while testing. The location of the .so files doesn't seem to have
any bearing on whether "java Test" will succeed or not. The contents of
this directory are:

sds at ipaq-pxa-2:~$ ls /usr/local/lib/ext/
RXTXcomm.jar              librxtxParallel-2.1-7.so  librxtxRS485.so
librxtxSerial-2.1-7.so
librxtxI2C-2.1-7.so       librxtxParallel.so        librxtxRaw-2.1-7.so
librxtxSerial.so
librxtxI2C.so             librxtxRS485-2.1-7.so     librxtxRaw.so
sds at ipaq-pxa-2:~$

Test.java fails on the first real line of code I'm using to test that
things are working, prior to real development, and was carefully pinched
from the web:
Enumeration portIdentifiers = CommPortIdentifier.getPortIdentifiers();


I assume that I've gotten my --host flag wrong way back up there at
the ./configure step. But if that's the case, what should I set it to?
Or am I missing something more obvious?


Cheers,
Stephen Strowes,
University of Glasgow.




From tjarvi at qbang.org  Tue Jun  6 13:39:41 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 6 Jun 2006 13:39:41 -0600 (MDT)
Subject: [Rxtx] Serial port code for OS X, future steps
In-Reply-To: <8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
	<CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
	<8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>
Message-ID: <Pine.LNX.4.61.0606061315070.9856@www>


>>
There are some very intrusive changes that should be done. Ie proper
mapping of /dev/tty <-> /dev/cu handling to correct behaviour of
CommPortOwnershipListener (http://java.sun.com/products/javacomm/
reference/api/index.html). I dont think this can be done with
patches. Hence I think, RXTX should be rewritten from scratch de-
unifying the native code base (and implementing thread safe code on
the Java side).
<<

This appears to be a very small amount of functionality for a total 
rewrite.  The port ownership only needs maybe 3 native calls if it is done 
with native calls at all.

Those features which are not part of the Unix standard(s) can be special 
cased.  I'm not sure /dev/cu is standard.  We can look.  I know linux 
deprecated /dev/cua years ago.

Thread safe Java code is not a platform specific issue.

--
Trent Jarvi
tjarvi at qbang.org


From sds at dcs.gla.ac.uk  Wed Jun  7 12:36:43 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Wed, 07 Jun 2006 19:36:43 +0100
Subject: [Rxtx] Expected RXTX behaviour?
In-Reply-To: <1149703900.30891.19.camel@addu>
References: <1149703900.30891.19.camel@addu>
Message-ID: <1149705403.30891.25.camel@addu>

Apologies, caught the problem. Had to append '\r' to the end of the AT
string. A non obvious but stupid mistake... :-)

Final quick question though: How might I stop the echoing of
outputStream data back into the inputStream? I still see the ATI
commands on the inputStream, along with the output from the device.


Cheers,
S.



On Wed, 2006-06-07 at 19:11 +0100, Stephen Strowes wrote:
> Hi,
> 
> I managed to get RXTX to compile for my iPAQ following my previous post
> to this list. Quick query though:
> 
> I want to be able to issue AT commands to a device, and interpret the
> responses. For this, I assume I do the following, in psuedo-form:
> 
> 	CommPortIdentifier.getPortIdentifiers();
> 	// find the correct device id
> 	serialPort= (SerialPort)portID.open("Test");
> 	// Set parameters and flow control
> 	outputStream= serialPort.getOutputStream();
> 	inputStream=  serialPort.getInputStream();
> 
> ... following this, I spawn a thread to respond to DATA_AVAILABLE events
> on serialPort with inputStream, and occasionally write and flush an
> "ATI" onto the outputStream. Nothing complex, I just want to see it
> work.
> 
> I would have expected inputStream to give the same information back from
> an "ATI" command as minicom provides, but instead inputStream only sees
> the "ATI" I put onto the outputStream.
> 
> Have I missed something?
> 
> 
> Cheers,
> S.
> 



From sds at dcs.gla.ac.uk  Wed Jun  7 12:11:40 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Wed, 07 Jun 2006 19:11:40 +0100
Subject: [Rxtx] Expected RXTX behaviour?
Message-ID: <1149703900.30891.19.camel@addu>

Hi,

I managed to get RXTX to compile for my iPAQ following my previous post
to this list. Quick query though:

I want to be able to issue AT commands to a device, and interpret the
responses. For this, I assume I do the following, in psuedo-form:

	CommPortIdentifier.getPortIdentifiers();
	// find the correct device id
	serialPort= (SerialPort)portID.open("Test");
	// Set parameters and flow control
	outputStream= serialPort.getOutputStream();
	inputStream=  serialPort.getInputStream();

... following this, I spawn a thread to respond to DATA_AVAILABLE events
on serialPort with inputStream, and occasionally write and flush an
"ATI" onto the outputStream. Nothing complex, I just want to see it
work.

I would have expected inputStream to give the same information back from
an "ATI" command as minicom provides, but instead inputStream only sees
the "ATI" I put onto the outputStream.

Have I missed something?


Cheers,
S.




From joachim at buechse.de  Wed Jun  7 09:02:13 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 7 Jun 2006 17:02:13 +0200
Subject: [Rxtx] Update of build process for OSX (XCode project)
Message-ID: <62EC47B1-46BD-4ECA-B9EC-C4061D147CDA@buechse.de>

With the help of Dmitry Markman and Brian Schilling I have updated  
(and largely simplifed) the XCode project file for Mac OS X.

Changes:
- compiles a universal binary library with intel=OSX10.4+, ppc=OSX10.2 
+ support
- compiles the Java sources into a JRE1.1 compatible, compressed jar.

Please test on your configuration, especially if you have computers  
running 10.2/10.3 or intel.

Best regards,
Joachim


From joachim at buechse.de  Wed Jun  7 14:36:37 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 7 Jun 2006 22:36:37 +0200
Subject: [Rxtx] Expected RXTX behaviour?
In-Reply-To: <1149705403.30891.25.camel@addu>
References: <1149703900.30891.19.camel@addu> <1149705403.30891.25.camel@addu>
Message-ID: <D3AD6EAF-27BB-455E-9697-86C1121920C3@buechse.de>

Echoing is a feature of the modem. Try ATE0 which works with most  
"rockwell" compatible modems.

Regards,
Joachim


On 07.06.2006, at 20:36, Stephen Strowes wrote:

> Apologies, caught the problem. Had to append '\r' to the end of the AT
> string. A non obvious but stupid mistake... :-)
>
> Final quick question though: How might I stop the echoing of
> outputStream data back into the inputStream? I still see the ATI
> commands on the inputStream, along with the output from the device.
>
>
> Cheers,
> S.
>
>
>
> On Wed, 2006-06-07 at 19:11 +0100, Stephen Strowes wrote:
>> Hi,
>>
>> I managed to get RXTX to compile for my iPAQ following my previous  
>> post
>> to this list. Quick query though:
>>
>> I want to be able to issue AT commands to a device, and interpret the
>> responses. For this, I assume I do the following, in psuedo-form:
>>
>> 	CommPortIdentifier.getPortIdentifiers();
>> 	// find the correct device id
>> 	serialPort= (SerialPort)portID.open("Test");
>> 	// Set parameters and flow control
>> 	outputStream= serialPort.getOutputStream();
>> 	inputStream=  serialPort.getInputStream();
>>
>> ... following this, I spawn a thread to respond to DATA_AVAILABLE  
>> events
>> on serialPort with inputStream, and occasionally write and flush an
>> "ATI" onto the outputStream. Nothing complex, I just want to see it
>> work.
>>
>> I would have expected inputStream to give the same information  
>> back from
>> an "ATI" command as minicom provides, but instead inputStream only  
>> sees
>> the "ATI" I put onto the outputStream.
>>
>> Have I missed something?
>>
>>
>> Cheers,
>> S.
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From g_petrini at yahoo.it  Thu Jun  8 01:41:58 2006
From: g_petrini at yahoo.it (Giacomo Petrini)
Date: Thu, 8 Jun 2006 09:41:58 +0200 (CEST)
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from FieldTalk
Message-ID: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>

Hi,
I'm evaluating the library for the modbus protocol
from FieldTalk
(http://www.modbusdriver.com/fieldtalk/.
I'm using J2SE 5.0 and RXTX 2.1 on win XP.
The problem is that the modbus lib has a method (the
openProtocol method, but maybe there are others) tha
throws the
javax.comm.UnsupportedCommOperationException.
Now, in RXTX 2.1 the namespace has changed in gnu.io,
so the modbus library doesn't work anymore (it look
for things in javax.comm). I've already sent an email
to fieldtalk to see if they are aware of the problem.
The solution should be to use JavaComm + RXTX 2.0. But
I've read somewhere that JavaComm 2.0 does not work
with Java 5.0 and JavaComm 3.0 does not work with RXTX
2.0 so I don't know what to do.

Any ideas?

Thanks Jack

PS: can you make a CC to my personal email
(g_petrini at yahoo.it) too please?

Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 


From rxtx at tapastda.co.uk  Thu Jun  8 02:27:57 2006
From: rxtx at tapastda.co.uk (rxtx@tapastda.co.uk)
Date: Thu, 08 Jun 2006 09:27:57 +0100
Subject: [Rxtx] Win XP and Infrared based serial port
Message-ID: <4487DF8D.5050807@tapastda.co.uk>

I'm attempting to use RXTX 2.1.7 on Win XP with J2SE 5.0 to communicate with a
GSM mobile using a COM port. A peculiarity that I've seen is that whilst I can
communicate successfully with a mobile which uses an infrared based COM port
using the SUN provided javax.comm (v2.0) I cannot use RXTX because it fails to
read anything from the port (i.e. read timeout always occurs returning zero bytes).

I assumed that this could be the result of flow control problems and thus I've
tried setting either software or hardware based flow control on the port however
this has no affect.

Can you suggest any other port configuration changes which might be required to
make such a port work with RXTX.

Thanks
Stu
-- 
Stuart
Tapastda Limited


From tjarvi at qbang.org  Thu Jun  8 05:17:12 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 8 Jun 2006 05:17:12 -0600 (MDT)
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from
	FieldTalk
In-Reply-To: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
References: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606080504480.9856@www>

On Thu, 8 Jun 2006, Giacomo Petrini wrote:

> Hi,
> I'm evaluating the library for the modbus protocol
> from FieldTalk
> (http://www.modbusdriver.com/fieldtalk/.
> I'm using J2SE 5.0 and RXTX 2.1 on win XP.
> The problem is that the modbus lib has a method (the
> openProtocol method, but maybe there are others) tha
> throws the
> javax.comm.UnsupportedCommOperationException.
> Now, in RXTX 2.1 the namespace has changed in gnu.io,
> so the modbus library doesn't work anymore (it look
> for things in javax.comm). I've already sent an email
> to fieldtalk to see if they are aware of the problem.
> The solution should be to use JavaComm + RXTX 2.0. But
> I've read somewhere that JavaComm 2.0 does not work
> with Java 5.0 and JavaComm 3.0 does not work with RXTX
> 2.0 so I don't know what to do.
>
> Any ideas?
>
> Thanks Jack
>


Hi Jack

There are plans for Sun to rerelease JavaComm 2.0 mentioned in the rxtx 
mail-list archives.  When this happens rxtx will release a current rxtx 
2.0 library that works with it.

There are no dates promised by either side but rxtx will do it as soon as 
possible after Sun's rerelease.  Just to give you a feel for the time 
frame, this started last year and no significant progress has been made. 
There have been friendly talks pointing towards solutions (rerelease 2.0) 
but that does not get your application working today.  rxtx is preparing 
for its second release in gnu.io since then.

--
Trent Jarvi
tjarvi at qbang.org




From jredman at ergotech.com  Thu Jun  8 08:47:23 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 08 Jun 2006 08:47:23 -0600
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from
	FieldTalk
In-Reply-To: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
References: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
Message-ID: <4488387B.6040903@ergotech.com>

You could always try a different library, eg.

http://sourceforge.net/projects/jamod

I've only used the slave side since we have our own implementation of 
Modbus Client (and a host of other PLC protocols).  However the client 
side seems to be pretty well supported and fairly widely used.  Since 
the source is there you could change to gnu.io.

I think I should take more of an interest in this issue.  We generally 
run 1.4.2 on Linux, but also have some J9 and old platforms that we 
support that are basically Personal Java.  5.0 on Linux has some 
horrible MDI bugs, to the point of being unusable.   Sounds as though we 
are going to have code compatibility problems across these platforms.

Jim


Giacomo Petrini wrote:
> Hi,
> I'm evaluating the library for the modbus protocol
> from FieldTalk
> (http://www.modbusdriver.com/fieldtalk/.
> I'm using J2SE 5.0 and RXTX 2.1 on win XP.
> The problem is that the modbus lib has a method (the
> openProtocol method, but maybe there are others) tha
> throws the
> javax.comm.UnsupportedCommOperationException.
> Now, in RXTX 2.1 the namespace has changed in gnu.io,
> so the modbus library doesn't work anymore (it look
> for things in javax.comm). I've already sent an email
> to fieldtalk to see if they are aware of the problem.
> The solution should be to use JavaComm + RXTX 2.0. But
> I've read somewhere that JavaComm 2.0 does not work
> with Java 5.0 and JavaComm 3.0 does not work with RXTX
> 2.0 so I don't know what to do.
> 
> Any ideas?
> 
> Thanks Jack
> 
> PS: can you make a CC to my personal email
> (g_petrini at yahoo.it) too please?
> 
> Chiacchiera con i tuoi amici in tempo reale! 
>  http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  8 18:17:23 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 08 Jun 2006 17:17:23 -0700
Subject: [Rxtx] rxtx access is denied error
Message-ID: <4488BE13.2050706@dupreeinc.com>

Hello,

I have been trying to replace the commapi from sun with rxtx for a 
project that communicates with a serial port that is a USB-Serial 
interface.  To be exact, I am using the FTDI VCP driver with one of 
their modules connected to a windows XP system.

I have the RXTX package working pretty well as long as nothing goes wrong.

If a user disconnects the USB port while my java application is running, 
my application goes into an endless loop with lots of messages in the  
errors stream  like the ones below:

    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(481):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.


I believe when this happens the COM port completely disappears and the 
rxtx driver has a heart attack.  Obviously, the user should not do this, 
but my application needs to ideally, correct the situation or as a worse 
case, terminate with a little dignity.  Currently, I have not figured 
out how to catch this error.

The closest I have come is to trap an exception to my input stream read  
that says "No error in readByte"  This error appears to be outside of 
the endless loop of the errors listed above.

Does anybody have an idea of how to identify and trap this error?  Any 
suggestions on how to gracefully recover from it would be greatly 
appreciated!

Thank you for your time,

Doug Thistlethwaite




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060608/9cfca302/attachment-0007.html

From tjarvi at qbang.org  Thu Jun  8 20:54:17 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 8 Jun 2006 20:54:17 -0600 (MDT)
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <4488BE13.2050706@dupreeinc.com>
References: <4488BE13.2050706@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606082022580.1323@www>

On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I have been trying to replace the commapi from sun with rxtx for a project 
> that communicates with a serial port that is a USB-Serial interface.  To be 
> exact, I am using the FTDI VCP driver with one of their modules connected to 
> a windows XP system.
>
> I have the RXTX package working pretty well as long as nothing goes wrong.
>
> If a user disconnects the USB port while my java application is running, my 
> application goes into an endless loop with lots of messages in the  errors 
> stream  like the ones below:
>
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(481):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>
>
> I believe when this happens the COM port completely disappears and the rxtx 
> driver has a heart attack.  Obviously, the user should not do this, but my 
> application needs to ideally, correct the situation or as a worse case, 
> terminate with a little dignity.  Currently, I have not figured out how to 
> catch this error.
>
> The closest I have come is to trap an exception to my input stream read  that 
> says "No error in readByte"  This error appears to be outside of the endless 
> loop of the errors listed above.
>
> Does anybody have an idea of how to identify and trap this error?  Any 
> suggestions on how to gracefully recover from it would be greatly 
> appreciated!
>

Hi Doug

Sadly I don't have a quick solution for you.

Termios has no knowlage about the JVM so it wont be throwing exceptions 
you can catch.

We can return error and set the error number to something reasonable that 
results in an exception.  The No Error message simply means we did not set 
an error number in termios.c.  Those are the line numbers in the code you 
see.  SerialImp.c realizes it errored but does not know much more yet. 
Everything touching the file descriptor is going to error after the port 
is gone presumably.

We don't currently have a plan in place for vanishing (or appearing) com 
ports.

Another example of what we need to think about is what happens if you 
start your application and then plug in the dongle?  Or what if you unplug 
and then plug it in again?

So in each of these three cases, what would the behavior of the (yet to 
be) correct implementation do?

How will the enumerated ports be handled during these changes?

There can also be hints from the OS that could be taken into 
consideration.

We can probably get some exceptions thrown that make sense and null the 
file descriptor when it happens to prevent io attempts.  That would be a 
crude way to let applications know something strange has happened.

Is anyone else tinkering with this problem?

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  9 01:31:29 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 9 Jun 2006 09:31:29 +0200
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <Pine.LNX.4.61.0606082022580.1323@www>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
Message-ID: <AC6EDDDD-0A64-401F-B16B-E484788CDF4A@buechse.de>

Hello Trent,

I am not tinkering with this on the Source Level - but I think it  
should work pretty much the same way as it currently does in OSX.  
When the port goes away you get an IOException thrown for any read/ 
write. It will no longer be in the list of ports from  
CommPortIdentifier.getPortIdentifiers(). When a port (re-)appears it  
is added to the list. It's up to the application to re-check the list  
from time to time.

On Windows you can't do much better then that, because the ports  
don't have useful names. Which USB "virtual com port" is on which  
COMx depends on the order the devices were added. So reconnecting to  
the same device may mean connecting to another port.

Regarding the exception thrown: it would be nice to use an  
IOException subclass but the Exception message should definetly be  
informative also as most applications may want to keep compatibility  
with javax.comm.

Regards,
Joachim


On 09.06.2006, at 04:54, Trent Jarvi wrote:

> On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:
>
>> Hello,
>>
>> I have been trying to replace the commapi from sun with rxtx for a  
>> project
>> that communicates with a serial port that is a USB-Serial  
>> interface.  To be
>> exact, I am using the FTDI VCP driver with one of their modules  
>> connected to
>> a windows XP system.
>>
>> I have the RXTX package working pretty well as long as nothing  
>> goes wrong.
>>
>> If a user disconnects the USB port while my java application is  
>> running, my
>> application goes into an endless loop with lots of messages in  
>> the  errors
>> stream  like the ones below:
>>
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (481):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>
>>
>> I believe when this happens the COM port completely disappears and  
>> the rxtx
>> driver has a heart attack.  Obviously, the user should not do  
>> this, but my
>> application needs to ideally, correct the situation or as a worse  
>> case,
>> terminate with a little dignity.  Currently, I have not figured  
>> out how to
>> catch this error.
>>
>> The closest I have come is to trap an exception to my input stream  
>> read  that
>> says "No error in readByte"  This error appears to be outside of  
>> the endless
>> loop of the errors listed above.
>>
>> Does anybody have an idea of how to identify and trap this error?   
>> Any
>> suggestions on how to gracefully recover from it would be greatly
>> appreciated!
>>
>
> Hi Doug
>
> Sadly I don't have a quick solution for you.
>
> Termios has no knowlage about the JVM so it wont be throwing  
> exceptions
> you can catch.
>
> We can return error and set the error number to something  
> reasonable that
> results in an exception.  The No Error message simply means we did  
> not set
> an error number in termios.c.  Those are the line numbers in the  
> code you
> see.  SerialImp.c realizes it errored but does not know much more yet.
> Everything touching the file descriptor is going to error after the  
> port
> is gone presumably.
>
> We don't currently have a plan in place for vanishing (or  
> appearing) com
> ports.
>
> Another example of what we need to think about is what happens if you
> start your application and then plug in the dongle?  Or what if you  
> unplug
> and then plug it in again?
>
> So in each of these three cases, what would the behavior of the  
> (yet to
> be) correct implementation do?
>
> How will the enumerated ports be handled during these changes?
>
> There can also be hints from the OS that could be taken into
> consideration.
>
> We can probably get some exceptions thrown that make sense and null  
> the
> file descriptor when it happens to prevent io attempts.  That would  
> be a
> crude way to let applications know something strange has happened.
>
> Is anyone else tinkering with this problem?
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From doug at dupreeinc.com  Fri Jun  9 13:09:58 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 09 Jun 2006 12:09:58 -0700
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <Pine.LNX.4.61.0606082022580.1323@www>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
Message-ID: <4489C786.9050504@dupreeinc.com>


Ideally, it would be nice if it would throw an exception and terminate 
the loop.  I am still trying to figure out how to detect the condition 
and recover form it in some form...  I am getting the "No error in 
readByte" exception in my serialEvent() method after an input stream 
read.  It appears to me that the only graceful recovery is to close the 
port and then reopen it when it becomes available.  I can pass the event 
up to the update method in my main frame, but I still can't close the 
port from within that thread.  Any suggestions on how to pass this event 
to a location where the port can be safely closed?

Re: Slow startup in windows XP
I have been looking into this a little closer and have found out the 
following:
System Windows XP Pro 3GHz dual core with 1GB RAM and NO parallel port.
Starting the SerialDemo included with the commapi using the rxtx instead 
of javax.comm takes 60 seconds.
Starting the SerialDemo using rxrx with the rxtxParallel.dll file 
removed takes about 20 seconds.
Modify initialize in RXRXCommDriver.java to not test the parallel ports 
takes less than 1 second.

It would be nice if the initialize routine could detect the presence of 
rxtxParallel.dll file and just skip the whole process if not present.  
Is there an easy way to check for the presence of this file without 
running the parallel port test?

Doug


 

Trent Jarvi wrote:

>On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:
>...
>  
>
>
>Hi Doug
>
>Sadly I don't have a quick solution for you.
>
>Termios has no knowlage about the JVM so it wont be throwing exceptions 
>you can catch.
>
>We can return error and set the error number to something reasonable that 
>results in an exception.  The No Error message simply means we did not set 
>an error number in termios.c.  Those are the line numbers in the code you 
>see.  SerialImp.c realizes it errored but does not know much more yet. 
>Everything touching the file descriptor is going to error after the port 
>is gone presumably.
>
>We don't currently have a plan in place for vanishing (or appearing) com 
>ports.
>
>Another example of what we need to think about is what happens if you 
>start your application and then plug in the dongle?  Or what if you unplug 
>and then plug it in again?
>
>So in each of these three cases, what would the behavior of the (yet to 
>be) correct implementation do?
>
>How will the enumerated ports be handled during these changes?
>
>There can also be hints from the OS that could be taken into 
>consideration.
>
>We can probably get some exceptions thrown that make sense and null the 
>file descriptor when it happens to prevent io attempts.  That would be a 
>crude way to let applications know something strange has happened.
>
>Is anyone else tinkering with this problem?
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060609/911ed787/attachment-0007.html

From Ugo.Landini at Sun.COM  Fri Jun  2 14:23:47 2006
From: Ugo.Landini at Sun.COM (Ugo Landini)
Date: Fri, 02 Jun 2006 22:23:47 +0200
Subject: [Rxtx] OSX 10.4.7 and usb
Message-ID: <44809E53.2070905@sun.com>

Hi, I have installed the library and the native libraries on OSX 10.4.7. 
Then I have run this simple code:

...
while (portList.hasMoreElements()) {
             portId = (CommPortIdentifier) portList.nextElement();
             System.out.println("-> " + portId.getName() + " Port Type:" 
+ portId.getPortType());
...

and the output is:

Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7

Ports found:
-> /dev/tty.Bluetooth-PDA-Sync Port Type:1
-> /dev/cu.Bluetooth-PDA-Sync Port Type:1
-> /dev/tty.Bluetooth-Modem Port Type:1
-> /dev/cu.Bluetooth-Modem Port Type:1

I can't see any USB ports... with javax.comm on linux I could see the 
/dev/ttyUSB stuff, but that's not the case with OSX. Any idea?

tia

uL


From tod at todbot.com  Sun Jun 11 12:04:37 2006
From: tod at todbot.com (Tod E. Kurt)
Date: Sun, 11 Jun 2006 11:04:37 -0700
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <44809E53.2070905@sun.com>
References: <44809E53.2070905@sun.com>
Message-ID: <E2EB14A1-20A7-4611-8F1A-E3D2ABE41F48@todbot.com>

A dumb question, but: do you have the USB serial adapters plugged  
in?  They only show up in /dev when plugged in.  Also, you can verify  
they exist independent of RXTX by doing something like "ls -l /dev/ 
cu.*".

On Jun 2, 2006, at 1:23 PM, Ugo Landini wrote:

> Hi, I have installed the library and the native libraries on OSX  
> 10.4.7.
> Then I have run this simple code:
>
> ...
> while (portList.hasMoreElements()) {
>              portId = (CommPortIdentifier) portList.nextElement();
>              System.out.println("-> " + portId.getName() + " Port  
> Type:"
> + portId.getPortType());
> ...
>
> and the output is:
>
> Experimental:  JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
>
> Ports found:
> -> /dev/tty.Bluetooth-PDA-Sync Port Type:1
> -> /dev/cu.Bluetooth-PDA-Sync Port Type:1
> -> /dev/tty.Bluetooth-Modem Port Type:1
> -> /dev/cu.Bluetooth-Modem Port Type:1
>
> I can't see any USB ports... with javax.comm on linux I could see the
> /dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>
> tia
>
> uL
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>



From lyon at docjava.com  Sun Jun 11 12:14:50 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Sun, 11 Jun 2006 14:14:50 -0400
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <44809E53.2070905@sun.com>
References: <44809E53.2070905@sun.com>
Message-ID: <p06020444c0b20de7d248@[192.168.1.152]>

>Hi Ugo,

Do you have any USB serial ports (like the keyspan 19-HS) plugged
into the mac?
Thanks!
  - DL


>Hi, I have installed the library and the native libraries on OSX 10.4.7.
>Then I have run this simple code:
>
>...
>while (portList.hasMoreElements()) {
>              portId = (CommPortIdentifier) portList.nextElement();
>              System.out.println("-> " + portId.getName() + " Port Type:"
>+ portId.getPortType());
>...
>
>and the output is:
>
>Experimental:  JNI_OnLoad called.
>Stable Library
>=========================================
>Native lib Version = RXTX-2.1-7
>Java lib Version   = RXTX-2.1-7
>
>Ports found:
>-> /dev/tty.Bluetooth-PDA-Sync Port Type:1
>-> /dev/cu.Bluetooth-PDA-Sync Port Type:1
>-> /dev/tty.Bluetooth-Modem Port Type:1
>-> /dev/cu.Bluetooth-Modem Port Type:1
>
>I can't see any USB ports... with javax.comm on linux I could see the
>/dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>
>tia
>
>uL
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx



From dmarkman at mac.com  Sun Jun 11 14:30:27 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Sun, 11 Jun 2006 16:30:27 -0400
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <p06020444c0b20de7d248@[192.168.1.152]>
References: <44809E53.2070905@sun.com> <p06020444c0b20de7d248@[192.168.1.152]>
Message-ID: <B9C1606B-4339-4564-A175-FE83DFFA7D76@mac.com>

afaik
10.4.7 wasn't released yet
it will soon, no doubts


On Jun 11, 2006, at 2:14 PM, Dr. Douglas Lyon wrote:

>> Hi Ugo,
>
> Do you have any USB serial ports (like the keyspan 19-HS) plugged
> into the mac?
> Thanks!
>   - DL
>
>
>> Hi, I have installed the library and the native libraries on OSX  
>> 10.4.7.
>> Then I have run this simple code:
>>
>> ...
>> while (portList.hasMoreElements()) {
>>              portId = (CommPortIdentifier) portList.nextElement();
>>              System.out.println("-> " + portId.getName() + " Port  
>> Type:"
>> + portId.getPortType());
>> ...
>>
>> and the output is:
>>
>> Experimental:  JNI_OnLoad called.
>> Stable Library
>> =========================================
>> Native lib Version = RXTX-2.1-7
>> Java lib Version   = RXTX-2.1-7
>>
>> Ports found:
>> -> /dev/tty.Bluetooth-PDA-Sync Port Type:1
>> -> /dev/cu.Bluetooth-PDA-Sync Port Type:1
>> -> /dev/tty.Bluetooth-Modem Port Type:1
>> -> /dev/cu.Bluetooth-Modem Port Type:1
>>
>> I can't see any USB ports... with javax.comm on linux I could see the
>> /dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>>
>> tia
>>
>> uL
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman



From tjarvi at qbang.org  Sun Jun 11 18:52:59 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 11 Jun 2006 18:52:59 -0600 (MDT)
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <4489C786.9050504@dupreeinc.com>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
	<4489C786.9050504@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606111845430.7274@www>

On Fri, 9 Jun 2006, Doug Thistlethwaite wrote:

>
> Ideally, it would be nice if it would throw an exception and terminate the 
> loop.  I am still trying to figure out how to detect the condition and 
> recover form it in some form...  I am getting the "No error in readByte" 
> exception in my serialEvent() method after an input stream read.  It appears 
> to me that the only graceful recovery is to close the port and then reopen it 
> when it becomes available.  I can pass the event up to the update method in 
> my main frame, but I still can't close the port from within that thread.  Any 
> suggestions on how to pass this event to a location where the port can be 
> safely closed?
>

I've gone through and cleaned up the termios.c layer.  I need to get to a 
windows machine with a USB dongle and see where the ioctl() is being 
called.  Probably the eventLoop.  But all of the ioctls should probably 
result in an IOException during this condition.

I'll probably finish this up Monday night when I can borrow a USB 
dongle.

There is no point in putting the code into CVS yet.  If you are tinkering 
I can mail the patch.  I think we will want to make a couple fixes in 
SerialImp.c to handle errors before it's ready.

--
Trent Jarvi
tjarvi at qbang.org



From bob_tai2001 at yahoo.com  Mon Jun 12 09:42:14 2006
From: bob_tai2001 at yahoo.com (Bob Tai)
Date: Mon, 12 Jun 2006 08:42:14 -0700 (PDT)
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to RXTX
	again
Message-ID: <20060612154214.58219.qmail@web32804.mail.mud.yahoo.com>


thank you Paul, Joachim, Trent and everyone try to
workout the java comm and Rxtx situation.  At least
now I have something that is solid enough to make my
decision.  

thank you,
     Bob

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From Ralph.Buchfelder at gmx.net  Mon Jun 12 15:30:20 2006
From: Ralph.Buchfelder at gmx.net (Ralph Buchfelder)
Date: Mon, 12 Jun 2006 23:30:20 +0200
Subject: [Rxtx] rxtx binaries or porting to XSCALE Windows Mobile 2003 / 2005
Message-ID: <448DDCEC.7090506@gmx.net>

dear group,

i have been carefully reading your homepage, wiki and archives
but there seems to be no detailled information on porting to Windows 
Mobile/CE.

as far as i understood from the 'porting' section you can do porting to 
winCE. but how? do i only need to obtain the sourcecode (which one?) and 
compile this in Microsoft eMbedded Visual C++ for ARM/Xscale?
Any other ways?


unfortunately i must admit that i do have little linux skills but i have 
made my way through gcc and makefiles. right now i need to implement com 
  communication in a J2ME application and found your website as >the< 
solution.

best regards
Ralph Buchfelder

University of Regensburg
Department of Geography

PS: i dont care about Javacomm compliancy (ie. 2.0 or 2.1) - i just need 
a working serial port API in IBM J9 VM.


From paul.klissner at sun.com  Wed Jun 14 18:12:58 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Wed, 14 Jun 2006 17:12:58 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
Message-ID: <4490A60A.9090305@sun.com>

Hello RxTx community,

I finally think I have a compromise in place that will stand in the gap.

If you go to http://www.sun.com and search for javax.comm, you'll
get taken to a download page, where now users can get a copy of the
comm.jar file out of 2.0.3, along with just a license and a README.

I trust this will suffice until such time as RxTx decided to implement
their own java classes or we can get a JSR going to mitigate some
of the problems (the readme in the comm.jar 2.0.3 zip file
contains my thoughts on that).

Thanks,
Paul



From tjarvi at qbang.org  Wed Jun 14 21:15:35 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 14 Jun 2006 21:15:35 -0600 (MDT)
Subject: [Rxtx] rxtx-2.0-7 (final) src is in CVS
Message-ID: <Pine.LNX.4.61.0606142100500.2742@www>


I wasn't expecting to be working on rxtx 2.0 tonight :)

Thanks go out to Paul Klissner for his work in making the coming release 
of rxtx-2.0-7 possible for users that require package javax.comm on many 
platforms.

Most people know that rxtx 2.0 is for use with Sun's CommAPI 2.0 for 
Solaris or the Generic CommAPI 2.0-3 available for download at Sun.  If 
you need javax.comm packages on many platforms, you are probably 
interested.  If you use rxtx 2.1 in package gnu.io, then you are not going 
to care much.

I've tried to update the rxtx 2.0 src directory in preparation for 
rxtx-2.0-7 (final).  Linux should compile.  Windows will compile if you 
generate your own .def files (I'll generate these tomorrow).  If you have 
some time to do basic testing of the source, I'd appreciate it.  The 
source should be good but you may find classes not found.  This source is 
a backport from rxtx 2.1.

I wanted to get things started so anyone interested on Mac OS X could get 
a head start.

All of this is in CVS.  http://www.rxtx.org/cvs.html

I suspect we will have binaries for testing in a couple days if you are 
unable to compile.   Consider this a smoke test.

--
Trent Jarvi
tjarvi at qbang.org


From legolas.w at gmail.com  Wed Jun 14 22:04:28 2006
From: legolas.w at gmail.com (Legolas Woodland)
Date: Wed, 14 Jun 2006 21:04:28 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <4490A60A.9090305@sun.com>
References: <4490A60A.9090305@sun.com>
Message-ID: <87ee9b170606142104p745fcef0vea622fbc8f528bfc@mail.gmail.com>

is there anything new in this version of javax.comm ?
thanks


On 6/14/06, Paul Klissner <paul.klissner at sun.com> wrote:
>
> Hello RxTx community,
>
> I finally think I have a compromise in place that will stand in the gap.
>
> If you go to http://www.sun.com and search for javax.comm, you'll
> get taken to a download page, where now users can get a copy of the
> comm.jar file out of 2.0.3, along with just a license and a README.
>
> I trust this will suffice until such time as RxTx decided to implement
> their own java classes or we can get a JSR going to mitigate some
> of the problems (the readme in the comm.jar 2.0.3 zip file
> contains my thoughts on that).
>
> Thanks,
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060614/5ff4dfbc/attachment-0007.html

From joachim at buechse.de  Thu Jun 15 07:22:48 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 15 Jun 2006 15:22:48 +0200
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
Message-ID: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>

Good day!

Some of my users report problems using RXTX 2.1.7 on Windows98 to  
communicate with an FTDI FT245BM chip (using their latest VCP  
driver). Either no ports are being shown (ie returned form  
CommPortIdentifier.getPortIdentifiers()) or the transfers fail.

Did anyone run into similar Problems with Win98??

Best regards,
Joachim



From ajmas at sympatico.ca  Thu Jun 15 08:12:28 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Thu, 15 Jun 2006 10:12:28 -0400
Subject: [Rxtx] API change question
Message-ID: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

How closely do you follow the Java Communication API spec? The reason I ask is because I would be interested in augmenting the CommPortIdentifier class to include a getDisplayName() method. By default it would return the same value as getName(), but would provide the possibility of displaying a 'user friendly' name, for platforms where the display name is not the same as the device name. An example of this is on MacOS X, where currently the names seem to be of the form /dev/cu.* and /dev/tty.*, yet what the expects to see is simply the part after the full-stop. Although I could move this logic into the Java code, it would be nice to see it transparent to the Java code.

Andre




From ajmas at sympatico.ca  Thu Jun 15 08:16:22 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Thu, 15 Jun 2006 10:16:22 -0400
Subject: [Rxtx] Package to use
Message-ID: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

While the Java API spec refers to javax.comm, I see that only gnu.io is provide by the rxtx project. Should our projects refer to the gnu.io package or the javax.comm API?

Andre



From joachim at buechse.de  Thu Jun 15 08:45:05 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 15 Jun 2006 16:45:05 +0200
Subject: [Rxtx] API change question
In-Reply-To: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>

Hello Andre,

the /dev/cu and /dev/tty have different semantics on OS X. It is much  
more than a simply naming issue to unify them, see my recent mail to  
the list...

Best regards,
Joachim


On 15.06.2006, at 16:12, Andre-John Mas wrote:

> Hi,
>
> How closely do you follow the Java Communication API spec? The  
> reason I ask is because I would be interested in augmenting the  
> CommPortIdentifier class to include a getDisplayName() method. By  
> default it would return the same value as getName(), but would  
> provide the possibility of displaying a 'user friendly' name, for  
> platforms where the display name is not the same as the device  
> name. An example of this is on MacOS X, where currently the names  
> seem to be of the form /dev/cu.* and /dev/tty.*, yet what the  
> expects to see is simply the part after the full-stop. Although I  
> could move this logic into the Java code, it would be nice to see  
> it transparent to the Java code.
>
> Andre
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From lyon at docjava.com  Thu Jun 15 10:16:29 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Thu, 15 Jun 2006 12:16:29 -0400
Subject: [Rxtx] cu.modem != /dev/ttya on mac.
In-Reply-To: <763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
	<763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>
Message-ID: <p0602046cc0b7378a95b0@[192.168.1.152]>

>Hi All,

I think that Joachim is correct. For the longest time,
I have been trying to figure out how to direct dial using
the cu.modem on the mac under os x.

As a less-than-optimal approach to auto-dialing, I have used
a keyspan USB 19HS adapter, along with an external modem, to
obtain the dialing feature.

Ideally, it would be better to dial with the built-in modem...but that did not
always seem to work, for some reason. Have others had some experience with
using the built in modem for dialing on the mac?

Thanks!
  - Doug


>Hello Andre,
>
>the /dev/cu and /dev/tty have different semantics on OS X. It is much?
>more than a simply naming issue to unify them, see my recent mail to?
>the list...
>
>Best regards,
>Joachim
>



From doug at dupreeinc.com  Thu Jun 15 14:52:50 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 15 Jun 2006 13:52:50 -0700
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
In-Reply-To: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
References: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
Message-ID: <4491C8A2.8090108@dupreeinc.com>

Hi Joachim,

I have been doing a lot with the new FTDI driver with win XP and have 
not had that particular problem.  I did notice that the new driver 
(dated May19th, 2006) is only for XP, Server 2003, and 2000.  Are they 
trying to use the 2.00.00 drivers or the old 1.09.06 version.  I am 
using a FT232R based module, but it uses the same drivers and I assume 
it would have the same problems.  Let me know which driver they are 
using and I can load up a 98 system here and see if  I can duplicate the 
problem.

Doug

Joachim Buechse wrote:

>Good day!
>
>Some of my users report problems using RXTX 2.1.7 on Windows98 to  
>communicate with an FTDI FT245BM chip (using their latest VCP  
>driver). Either no ports are being shown (ie returned form  
>CommPortIdentifier.getPortIdentifiers()) or the transfers fail.
>
>Did anyone run into similar Problems with Win98??
>
>Best regards,
>Joachim
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From matthewhepp at yahoo.com  Thu Jun 15 17:34:47 2006
From: matthewhepp at yahoo.com (Matthew Hepp)
Date: Thu, 15 Jun 2006 16:34:47 -0700 (PDT)
Subject: [Rxtx] Wither the XCode project?
Message-ID: <20060615233447.48064.qmail@web50311.mail.yahoo.com>

Either I don't know how to properly use CVS (entirely possibl), or the XCode
project is not making through the update properly. Doing a "cvs update" against
2.1-7 creates an XCode folder in MACOSX_IDE, and therein a
LibSerialUniversal.xcodeproj, but trying to open it yields a "Unable to Open
Project - Project rxtx-devel/MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj
cannot be opened because it is missing its project.pbxproj file" error. Showing
package contents reveals just the cvs-related files. Perhaps this is why
previous xcode projects have been saved as an sit.hqx - to retain the resource
fork?

Can someone point me in the right direction?

Thanks,

Matt

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Thu Jun 15 19:53:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 19:53:06 -0600 (MDT)
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
In-Reply-To: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
References: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
Message-ID: <Pine.LNX.4.61.0606151944070.23137@www>

On Thu, 15 Jun 2006, Joachim Buechse wrote:

> Good day!
>
> Some of my users report problems using RXTX 2.1.7 on Windows98 to
> communicate with an FTDI FT245BM chip (using their latest VCP
> driver). Either no ports are being shown (ie returned form
> CommPortIdentifier.getPortIdentifiers()) or the transfers fail.
>
> Did anyone run into similar Problems with Win98??
>

Hi Joachim

It has been a long time since I've tested win98.  I know rxtx-2.1-7pre16 
did get testing on win98 with ~jdk 1.3 though.  I wonder if jdks are still 
tested on that platform.

With win98 you usually have older boxes.  They can be short on CPU and 
memory.  Enumeration should work but I could picture runtime performance 
issues on win98.

The enumeration problems could result from other copies of your 
application if various states of decay still holding onto the port.  When 
things go wrong, people also like to open other terminal software to see 
whats going on which can interfere.  You can't open a windows port with 
two apps.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Thu Jun 15 20:08:53 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 20:08:53 -0600 (MDT)
Subject: [Rxtx] API change question
In-Reply-To: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606151954270.23137@www>

On Thu, 15 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> How closely do you follow the Java Communication API spec?

I can explain how this worked in the past.  How we do it in the future is 
open for discussion.

In the past we have tried to follow it as close as possible in gnu.io 
(rxtx 2.1).  We have added extensions but try to discourage their use. 
The extensions are clearly marked as such in the source code and javadocs.

rxtx 2.0 was intended to be a strict implementation of part of the spec. 
We let Sun's interfaces decide what methods can be called. There are 
differences not covered by the spec such as default values.  Thats not 
intentional but rather hard to avoid.

--
Trent Jarvi
tjarvi at qbang.org





From tjarvi at qbang.org  Thu Jun 15 21:09:11 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 21:09:11 -0600 (MDT)
Subject: [Rxtx] Package to use
In-Reply-To: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606152026120.23137@www>

On Thu, 15 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> While the Java API spec refers to javax.comm, I see that only gnu.io is 
> provide by the rxtx project. Should our projects refer to the gnu.io 
> package or the javax.comm API?
>

Hi Andre

Lets see if I can give a fair and balanced answer to that.

If you are starting a new project and want to use RXTX, I would recommend 
using gnu.io.  The community support for gnu.io will not be going away 
anytime soon.  You can switch between gnu.io (2.1) and javax.comm (2.0) 
fairly easily.  They are not intended to be incompatible.  You just change 
package names and libs.

You can also consider the combination of rxtx 2.0 with Sun's commapi 
2.0-3.  This is considered a stop-gap measure by Sun for previous users of 
that combination.  Together rxtx 2.0 and Sun CommAPI 2.0 work in namespace 
javax.comm for programmers.

Finally, you can opt to just use Sun's oferrings in CommAPI 3.0 without 
rxtx.  That would be in namespace javax.comm also.  CommAPI 3.0 may be 
of more interest to you if you are looking at POS with Sun computers. 
Rxtx does not currently support the changes in CommAPI 3.0 or have firm 
plans to do so.  That does not mean we wouldn't implement them.  It just 
means nobody has contributed code yet.

You can't combine rxtx with CommAPI 3.0 for technical reasons that wont 
likely be fixed soon.

It's up to you as far as what you use.  We like to provide the freedom so 
you can choose.  Realistically, we will be supporting gnu.io mainly 
because we have some control over that name space and can support it.

Things may happen in the future that enable rxtx to provide more support 
in the javax namespace but that has not happened yet.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun 16 00:33:06 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 08:33:06 +0200
Subject: [Rxtx] Wither the XCode project?
In-Reply-To: <20060615233447.48064.qmail@web50311.mail.yahoo.com>
References: <20060615233447.48064.qmail@web50311.mail.yahoo.com>
Message-ID: <D30D660F-A49B-464E-AE4C-6B4563893682@buechse.de>

Hello Matthew,

could you please send me the contents of your

   rxtx-devel/CVS
   rxtx-devel/MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj/CVS

directories as a zip to my personal email address. This should  
indicate why the file is not checked out. I can see that it exists on  
the correct branch in the repository, so something must have gone  
wrong during the "cvs update"...

Best regards,
Joachim

On 16.06.2006, at 01:34, Matthew Hepp wrote:

> Either I don't know how to properly use CVS (entirely possibl), or  
> the XCode
> project is not making through the update properly. Doing a "cvs  
> update" against
> 2.1-7 creates an XCode folder in MACOSX_IDE, and therein a
> LibSerialUniversal.xcodeproj, but trying to open it yields a  
> "Unable to Open
> Project - Project rxtx-devel/MACOSX_IDE/XCode/ 
> LibSerialUniversal.xcodeproj
> cannot be opened because it is missing its project.pbxproj file"  
> error. Showing
> package contents reveals just the cvs-related files. Perhaps this  
> is why
> previous xcode projects have been saved as an sit.hqx - to retain  
> the resource
> fork?
>
> Can someone point me in the right direction?



From joachim at buechse.de  Fri Jun 16 10:41:20 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 18:41:20 +0200
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <p06230903c0b88613dca6@[10.0.1.7]>
References: <p06230903c0b88613dca6@[10.0.1.7]>
Message-ID: <03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>

Hello Bob,

until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was  
behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if  
Trent has migrated all recent changes from 2.1 to 2.0.

I have added the XCode project and updated documentation only to the  
gnu.io branch. Once the 2.0 implementation is up to date I will copy  
over the documentation/build files make them work.

Best regards,
Joachim

On 16.06.2006, at 18:07, Bob Jacobsen wrote:

> I'm one of the developers for the JMRI project, which provides  
> model railroad software in Java.  We've been using RXTX to provide  
> serial port access on MacOS X and Linux; we use the old javax.comm  
> 2.0 on Windows, OS/2 and Solaris.  Because of that, we need to stay  
> with RXTX 2.0, not 2.1
>
> We've been using the 2.0-pre17 installer for a long time, but it's  
> not compatible with Intel macs.
>
> Can you point me to where I can find the right files for RXTX 2.0  
> to package with the program?
>
> The current situation is confusing to me.  I've been pointed to  
> recent 2.1 versions (but we need the javax.comm names), to an even  
> older installer, etc.  I've been reading that some versions require  
> an installer, and others don't, but I haven't been able to figure  
> out which (if any) of those are where in CVS.
>
> I'd really appreciate a clear statement of what files to use and  
> what to do with them that I can pass on to our users.
>
> I'm more than happy to put files in the local classpath, have users  
> run an installer, or anything else.  Whatever is easiest for you.
>
> Thanks!  I really appreciate all that you do to keep RXTX working.
>
> Bob
> -- 
> Bob Jacobsen +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG



From joachim at buechse.de  Fri Jun 16 09:59:28 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 17:59:28 +0200
Subject: [Rxtx] Wither the XCode project?
In-Reply-To: <20060616150240.49464.qmail@web50309.mail.yahoo.com>
References: <20060616150240.49464.qmail@web50309.mail.yahoo.com>
Message-ID: <D9935E05-2B83-488D-86DD-42599E229052@buechse.de>

Hello Matthew,

you have checked out the trunk (which is the 2.0.7 javax.comm.xxx  
release). For rxtx-2.1.7 (gnu.io.xxx release) you need to check out  
the branch

      commapi-0-0-1

The easiest way to do this is to download the rxtx src archive,  
unpack it and then do a cvs up inside the decompressed tree.  
Optionally you could do a

      cvs co -r commapi-0-0-1

but this will take much longer!

Best regards,
Joachim

When you do a cvs status it will show the sticky tag.

41:~/jdevelop/rxtx-2.1-7r2 joachim$ cvs status README.OSX
===================================================================
File: README.OSX        Status: Up-to-date

    Working revision:    1.1.2.1
    Repository revision: 1.1.2.1 /usr/local/cvsroot/rxtx-devel/Attic/ 
README.OSX,v
    Sticky Tag:          commapi-0-0-1 (branch: 1.1.2)
    Sticky Date:         (none)
    Sticky Options:      (none)




On 16.06.2006, at 17:02, Matthew Hepp wrote:

> %cvs status README.MACOSX
> ===================================================================
> File: README.MACOSX     Status: Up-to-date
>
>    Working revision:    1.1
>    Repository revision: 1.1     /usr/local/cvsroot/rxtx-devel/ 
> README.MACOSX,v
>    Sticky Tag:          (none)
>    Sticky Date:         (none)
>    Sticky Options:      (none)



From tjarvi at qbang.org  Fri Jun 16 16:31:18 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Fri, 16 Jun 2006 16:31:18 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
Message-ID: <Pine.LNX.4.61.0606161630030.14139@www>

On Fri, 16 Jun 2006, Joachim Buechse wrote:

> Hello Bob,
>
> until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was
> behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if
> Trent has migrated all recent changes from 2.1 to 2.0.
>

The src/ directory and configure.in/configure files should be fine.  I 
have not touched the Mac OS X directories.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sat Jun 17 02:39:55 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sat, 17 Jun 2006 10:39:55 +0200
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <Pine.LNX.4.61.0606161630030.14139@www>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
Message-ID: <350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>

Hello Trent,

apparently the IOEXCL changes have not made it into 2.0. I will add  
them to achieve a minimal diff between 2.0 and 2.1.

One other thing that bugs me for a while...

Shouldn't we replace "if !defined(TIOCSERGETLSR) && !defined(WIN32)"  
by a definition of its own "if defined(DRAINTHREAD)"? I think this  
would make the code clearer for people starting to read it.

Regards,
Joachim


On 17.06.2006, at 00:31, Trent Jarvi wrote:

> On Fri, 16 Jun 2006, Joachim Buechse wrote:
>
>> Hello Bob,
>>
>> until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was
>> behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if
>> Trent has migrated all recent changes from 2.1 to 2.0.
>>
>
> The src/ directory and configure.in/configure files should be fine.  I
> have not touched the Mac OS X directories.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From tropicsu at hotmail.com  Sat Jun 17 09:32:48 2006
From: tropicsu at hotmail.com (Yoke K)
Date: Sat, 17 Jun 2006 15:32:48 +0000
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
Message-ID: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>

Hi,

I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to work with 
MAC OS X.
I am using iTegno 3000 - USB GPRS Modem.

Files in /dev and a symbolic link as follows:

crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 -> tty.usbserial

In my SendMessage.java, I have this line:
CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");

Appreciate any help ?

- Jon


Errors as follows:

>>INFO: SMSLib API for Java / v1.2.2
>>INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>INFO: JRE Version: 1.5.0_06
>>INFO: JRE Impl Version: 1.5.0_06-64
>>INFO: O/S: Mac OS X / ppc / 10.4.6
>>INFO: Using Wavecom (Generic) AT handler.

SendMessage(): Send a message.
  Using SMSLib API for Java v1.2.2

Connecting ..... :
>>INFO: CSerialDriver(): Connecting...
Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
>>INFO: CSerialDriver(): Disconnecting...
gnu.io.NoSuchPortException
        at 
gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:218)
        at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
        at org.smslib.CService.connect(CService.java:197)
        at SendMessage.main(SendMessage.java:38)

_________________________________________________________________
Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/



From tjarvi at qbang.org  Sat Jun 17 10:12:30 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 10:12:30 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
	<350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
Message-ID: <Pine.LNX.4.61.0606171010060.14139@www>

On Sat, 17 Jun 2006, Joachim Buechse wrote:

> Hello Trent,
>
> apparently the IOEXCL changes have not made it into 2.0. I will add
> them to achieve a minimal diff between 2.0 and 2.1.
>

Hi Joachim

As I recall the IOEXCL change was after 2.1-7.  I was just syncing with 
2.1-7.  We can release 2.1-8 and 2.0-8 with the same changes.

> One other thing that bugs me for a while...
>
> Shouldn't we replace "if !defined(TIOCSERGETLSR) && !defined(WIN32)"
> by a definition of its own "if defined(DRAINTHREAD)"? I think this
> would make the code clearer for people starting to read it.
>


Sure.  We can do that for -8.  The TIOCSERGETLSR code should be a special 
case not the expected.  I think only Linux uses it.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Sat Jun 17 10:48:21 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 10:48:21 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <Pine.LNX.4.61.0606171010060.14139@www>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
	<350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
	<Pine.LNX.4.61.0606171010060.14139@www>
Message-ID: <Pine.LNX.4.61.0606171047310.14139@www>

On Sat, 17 Jun 2006, Trent Jarvi wrote:

> On Sat, 17 Jun 2006, Joachim Buechse wrote:
>
>> Hello Trent,
>>
>> apparently the IOEXCL changes have not made it into 2.0. I will add
>> them to achieve a minimal diff between 2.0 and 2.1.
>>
>
> Hi Joachim
>
> As I recall the IOEXCL change was after 2.1-7.  I was just syncing with
> 2.1-7.  We can release 2.1-8 and 2.0-8 with the same changes.
>

We could just move to 2.1-8 and 2.0-8.

--
Trent Jarvi
tjarvi at qbang.org


From brian.t.lamb at gmail.com  Tue Jun 13 13:54:13 2006
From: brian.t.lamb at gmail.com (Brian Lamb)
Date: Tue, 13 Jun 2006 15:54:13 -0400
Subject: [Rxtx] Windows XP Installation
Message-ID: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>

I've not installed Java packages on Windows before and am unsure how to
proceed. All the documentation I've seen provides detailed instructions on
how to install on Linux or Solaris. I was wondering how to install rxtx on
Windows XP.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060613/6f68cd5c/attachment-0007.html

From tjarvi at qbang.org  Sat Jun 17 13:57:03 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 13:57:03 -0600 (MDT)
Subject: [Rxtx] Windows XP Installation
In-Reply-To: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>
References: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0606171356120.14139@www>

On Tue, 13 Jun 2006, Brian Lamb wrote:

> I've not installed Java packages on Windows before and am unsure how to
> proceed. All the documentation I've seen provides detailed instructions on
> how to install on Linux or Solaris. I was wondering how to install rxtx on
> Windows XP.
>

Hi Brian

Which rxtx version are you trying to install?

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sun Jun 18 10:41:44 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sun, 18 Jun 2006 18:41:44 +0200
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
References: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
Message-ID: <8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>

Hello Jon,

 From OSX's standpoint a symbolic link is not a device (as far as I  
know). What stops you from using tty.usbserial? Did you try hard- 
linking?

Regards,
Joachim

On 17.06.2006, at 17:32, Yoke K wrote:
> Hi,
>
> I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to  
> work with
> MAC OS X.
> I am using iTegno 3000 - USB GPRS Modem.
>
> Files in /dev and a symbolic link as follows:
>
> crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
> crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
> lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->  
> tty.usbserial
>
> In my SendMessage.java, I have this line:
> CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
>
> Appreciate any help ?
>
> - Jon
>
>
> Errors as follows:
>
>>> INFO: SMSLib API for Java / v1.2.2
>>> INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>> INFO: JRE Version: 1.5.0_06
>>> INFO: JRE Impl Version: 1.5.0_06-64
>>> INFO: O/S: Mac OS X / ppc / 10.4.6
>>> INFO: Using Wavecom (Generic) AT handler.
>
> SendMessage(): Send a message.
>   Using SMSLib API for Java v1.2.2
>
> Connecting ..... :
>>> INFO: CSerialDriver(): Connecting...
> Experimental:  JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
>>> INFO: CSerialDriver(): Disconnecting...
> gnu.io.NoSuchPortException
>         at
> gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java: 
> 218)
>         at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
>         at org.smslib.CService.connect(CService.java:197)
>         at SendMessage.main(SendMessage.java:38)
>
> _________________________________________________________________
> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Sun Jun 18 10:56:55 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 12:56:55 -0400
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>
References: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
	<8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>
Message-ID: <7B6834E3-F41D-46B6-B979-55466BC73859@sympatico.ca>

Have you been able to get any other software to talk with your
modem? What port is it using? Have tried using the cu.usbserial
instead?

Andre

On 18-Jun-06, at 12:41 , Joachim Buechse wrote:

> Hello Jon,
>
>  From OSX's standpoint a symbolic link is not a device (as far as I
> know). What stops you from using tty.usbserial? Did you try hard-
> linking?
>
> Regards,
> Joachim
>
> On 17.06.2006, at 17:32, Yoke K wrote:
>> Hi,
>>
>> I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to
>> work with
>> MAC OS X.
>> I am using iTegno 3000 - USB GPRS Modem.
>>
>> Files in /dev and a symbolic link as follows:
>>
>> crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
>> crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
>> lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->
>> tty.usbserial
>>
>> In my SendMessage.java, I have this line:
>> CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
>>
>> Appreciate any help ?
>>
>> - Jon
>>
>>
>> Errors as follows:
>>
>>>> INFO: SMSLib API for Java / v1.2.2
>>>> INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>>> INFO: JRE Version: 1.5.0_06
>>>> INFO: JRE Impl Version: 1.5.0_06-64
>>>> INFO: O/S: Mac OS X / ppc / 10.4.6
>>>> INFO: Using Wavecom (Generic) AT handler.
>>
>> SendMessage(): Send a message.
>>   Using SMSLib API for Java v1.2.2
>>
>> Connecting ..... :
>>>> INFO: CSerialDriver(): Connecting...
>> Experimental:  JNI_OnLoad called.
>> Stable Library
>> =========================================
>> Native lib Version = RXTX-2.1-7
>> Java lib Version   = RXTX-2.1-7
>>>> INFO: CSerialDriver(): Disconnecting...
>> gnu.io.NoSuchPortException
>>         at
>> gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:
>> 218)
>>         at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
>>         at org.smslib.CService.connect(CService.java:197)
>>         at SendMessage.main(SendMessage.java:38)
>>
>> _________________________________________________________________
>> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Sun Jun 18 17:33:08 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 19:33:08 -0400
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
Message-ID: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>

Hi,

I am have a program that I wrote in Java to communicate with a  
Bluetooth GPS device. I am
trying to get this working on my Mac, but I keep getting told that:

gnu.io.PortInUseException: Unknown Application

but

portIdentifier.isCurrentlyOwned()

returns false and when I do lsof on the device I am trying to connect  
to, I see no application
using it. As the same time if I go to the command line and use  
minicom I have no issues. The
exception happens with this call:

CommPort commPort = portIdentifier.open(null,0);

Any suggestions?

Andre


From ajmas at sympatico.ca  Sun Jun 18 17:45:11 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 19:45:11 -0400
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
Message-ID: <30245B30-682D-4EAE-8084-8227B719F10D@sympatico.ca>

BTW My code snippet is:

     private InputStream connectToSerial () throws IOException,  
Exception
     {
         InputStream in = null;

         Enumeration portEnum = CommPortIdentifier.getPortIdentifiers();
         while ( portEnum.hasMoreElements() )
         {
             CommPortIdentifier portIdentifier = (CommPortIdentifier)  
portEnum.nextElement();
             System.out.println(portIdentifier.getName() + " - " +  
portIdentifier.getPortType() );
         }

         CommPortIdentifier portIdentifier =  
CommPortIdentifier.getPortIdentifier("/dev/cu.BTGPS-SPPslave-1");
         System.out.println("current owner: " +  
portIdentifier.getCurrentOwner());
         if ( portIdentifier.isCurrentlyOwned() )
         {
             System.out.println("Error: Port is currently in use");
             return null;
         }
         else
         {
             CommPort commPort = portIdentifier.open(this.getClass 
().getName(),2000);

             if ( commPort instanceof SerialPort )
             {
                 SerialPort serialPort = (SerialPort) commPort;
                 serialPort.setSerialPortParams 
(4800,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE 
);
                 in = serialPort.getInputStream();

                 return in;
             }
             else
             {
                 System.out.println("Error: Only serial ports are  
handled.");
             }
         }


         return in;
     }


On 18-Jun-06, at 19:33 , Andr?-John Mas wrote:

> Hi,
>
> I am have a program that I wrote in Java to communicate with a
> Bluetooth GPS device. I am
> trying to get this working on my Mac, but I keep getting told that:
>
> gnu.io.PortInUseException: Unknown Application
>
> but
>
> portIdentifier.isCurrentlyOwned()
>
> returns false and when I do lsof on the device I am trying to connect
> to, I see no application
> using it. As the same time if I go to the command line and use
> minicom I have no issues. The
> exception happens with this call:
>
> CommPort commPort = portIdentifier.open(null,0);
>
> Any suggestions?
>
> Andre
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From joachim at buechse.de  Mon Jun 19 05:54:49 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 13:54:49 +0200
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de>

This is most likely due to a problem with lock files. If you have  
downloaded the binaries of 2.17 rxtx will try to create non-standard  
lock files on OSX. We have since changed the code to use OSX device  
locking - however the binaries have not been updated yet. The 2.18  
release fixing this issue is due shortly.

Regards,
Joachim

On 19.06.2006, at 01:33, Andr?-John Mas wrote:

> Hi,
>
> I am have a program that I wrote in Java to communicate with a
> Bluetooth GPS device. I am
> trying to get this working on my Mac, but I keep getting told that:
>
> gnu.io.PortInUseException: Unknown Application
>
> but
>
> portIdentifier.isCurrentlyOwned()
>
> returns false and when I do lsof on the device I am trying to connect
> to, I see no application
> using it. As the same time if I go to the command line and use
> minicom I have no issues. The
> exception happens with this call:
>
> CommPort commPort = portIdentifier.open(null,0);
>
> Any suggestions?
>
> Andre
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From joachim at buechse.de  Mon Jun 19 06:44:27 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 14:44:27 +0200
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <4490A60A.9090305@sun.com>
References: <4490A60A.9090305@sun.com>
Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>

Hello Paul,

I just downloaded the "generic" javax.comm version now available. A  
first check indicates, that it was compiled with a JDK 1.4 javac  
without setting the target classfile version. In other words in can  
not be loaded by 1.1-1.3 VMs (or PersonalJava).

Do you see any chance to provide a version compiled with classfile  
format 45.3 (ie JVM1.1).

---
52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose  
javax.comm.SerialPort | head -5
Compiled from "SerialPort.java"
public abstract class javax.comm.SerialPort extends javax.comm.CommPort
   SourceFile: "SerialPort.java"
   minor version: 0
   major version: 48
---

Best regards,
Joachim


On 15.06.2006, at 02:12, Paul Klissner wrote:

> Hello RxTx community,
>
> I finally think I have a compromise in place that will stand in the  
> gap.
>
> If you go to http://www.sun.com and search for javax.comm, you'll
> get taken to a download page, where now users can get a copy of the
> comm.jar file out of 2.0.3, along with just a license and a README.
>
> I trust this will suffice until such time as RxTx decided to implement
> their own java classes or we can get a JSR going to mitigate some
> of the problems (the readme in the comm.jar 2.0.3 zip file
> contains my thoughts on that).
>
> Thanks,
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Mon Jun 19 09:11:45 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Mon, 19 Jun 2006 11:11:45 -0400
Subject: [Rxtx] Examples added to Wiki
Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

I have added a couple of examples to the Wiki:

http://rxtx.qbang.org/wiki/index.php/Examples

If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :)

Andre



From paul.klissner at sun.com  Mon Jun 19 10:42:47 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Mon, 19 Jun 2006 09:42:47 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>
References: <4490A60A.9090305@sun.com>
	<03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>
Message-ID: <4496D407.1090609@sun.com>

Joachim Buechse wrote:
> Hello Paul,
> 
> I just downloaded the "generic" javax.comm version now available. A  
> first check indicates, that it was compiled with a JDK 1.4 javac  
> without setting the target classfile version. In other words in can  
> not be loaded by 1.1-1.3 VMs (or PersonalJava).
> 
> Do you see any chance to provide a version compiled with classfile  
> format 45.3 (ie JVM1.1).
> 
> ---
> 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose  
> javax.comm.SerialPort | head -5
> Compiled from "SerialPort.java"
> public abstract class javax.comm.SerialPort extends javax.comm.CommPort
>    SourceFile: "SerialPort.java"
>    minor version: 0
>    major version: 48
> ---

I cannot promise when I can do that. Since we thought we were done
with javax.comm, the build environment got moved around, and right
now it doesn't even compile in it's new home.  I tried and it was
not cooperative at all. I was never impressed with that workspace
(in fact far far from it, it is a mess, which is why I migrated 3.0
to ant and never looked back).  It will take some real determination
for me to rebuild it, and frankly, right now I'm swamped.  If I can
find a bit of time over the next few weeks to do it, and it isn't
too bad an ordeal, I will.

Posting that will give me an excuse to post javax.comm 3.0, Update 2 as
well, while I'm working with the people who put content up on our
download center.  The only reason for a new update to 3.0 is that
I've changed the distribution to provide ispt (Interactive Serial
Port Tool), such that it can be launched as soon as the zip file
is unpacked, via a provided script.  ISPT is a command line
interactive tool for  manipulating one or two serial port,
sending data, managing events, etc... I've found it to be so useful
for doing certain kinds of validation  that I assume others will
find it useful to.  ISPT is already in 3.0u1, but one has to set
up their own classpath and launch it and since few people ever read
the documentation most won't know about it.  I've added the ability
to set stop bits and parity since 3.0u1 too.  But I digress.

Paul


From joachim at buechse.de  Mon Jun 19 11:01:28 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 19:01:28 +0200
Subject: [Rxtx] load mechanism of 2.0x
Message-ID: <CFD1440C-21AA-4D3B-9EA6-270D0FF9D6FC@buechse.de>

Good day,

I am trying to figure out, how the 2.0x distribution interacts with  
Suns implementation of javax.comm.CommPortIdentifier.

1) Apparently one can put javax.comm.properties in {java.home}/lib
2) The javax.comm package also reacts to -Djavax.comm.properties="...."

Looking at the javap output it also seems like CommPortIdentifier  
tries to find it's jar file and load the properties from there??


What I'm really looking for is a solution that allows using  
javax.comm with RXTX without modifying the VM installation. So I  
would prefer not to use 1) but I can't figure out how to use 2).

Any hints are welcome,
Joachim



From bob_tai2001 at yahoo.com  Mon Jun 19 15:00:35 2006
From: bob_tai2001 at yahoo.com (Bob Tai)
Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT)
Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place
	to start?
Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>

Hi, 

I got  rxtx Windows 2000 installed.  I did not use the
"best" way ... I just follow the insturuction and dump
the necessary files into the jre... I know it's "best"
idea, I got lazy didn't want to change my setting to
my Eclipse and classpath.

I was able to modify SimpleWrite.java to print on my
AddMaster serial printer.  I think I am ready to code!
But I need to make sure I can handle exceptions and so
on.  I notice the \samples\NullDriver\  has two files
seems to have some of the require method done, should
I start coding from those file?  I like the idea it
has the "time out" and basic exceptions done.   I am
slowly digging into the samples, but if you think any
of the code from Sun is good to checkout please let me
know.

btw, http://rxtx.qbang.org/wiki/index.php/Examples/
was very helpful, wish there are more examples.

thank you,

    Bob


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Mon Jun 19 15:55:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT)
Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good
 place to start?
In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>
References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606191542260.14139@www>

> I am
> slowly digging into the samples, but if you think any
> of the code from Sun is good to checkout please let me
> know.
>

I think NullDriver.java was an example stub driver for implementing 
something like rxtx.  It has been a while.  Unless they have been updated, 
you will find the examples are very dated.  You can look at how they use 
the port but avoid the GUI and hard coded variables (number of ports for 
instance).

There was no Swing and nobody knew what requirements today's compilers 
would make on code.  The examples worked fine with jdk 1.1 but times have 
changed.

--
Trent Jarvi
tjarvi at qbang.org


From tropicsu at hotmail.com  Mon Jun 19 19:49:08 2006
From: tropicsu at hotmail.com (Yoke K)
Date: Tue, 20 Jun 2006 01:49:08 +0000
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
Message-ID: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>

An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0007.html

From ajmas at sympatico.ca  Mon Jun 19 21:14:37 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Mon, 19 Jun 2006 23:14:37 -0400
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>
References: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>
Message-ID: <CA22AB2A-5712-458B-9984-68477C6042AF@sympatico.ca>

Regarding the PortInUseException, I had a similar issue and got
this response from the mailing list:

   http://mailman.qbang.org/pipermail/rxtx/Week-of- 
Mon-20060619/062838.html

Andre
On 19-Jun-06, at 21:49 , Yoke K wrote:

> Hi Andre, Joachim
>
> I have tried using /dev/tty.usbserial and also /dev/cu.usbserial  
> and it also reported error as  "gnu.io.PortInUseException".
>
> The iTegno modem works in windows environment. As I moving around  
> using my ibook and I need to get it work on MAC OS as well.
>
> >> INFO: SMSLib API for Java / v1.2.2
> >> INFO: Using port: /dev/tty.usbserial @ 115200 baud.
> >> INFO: JRE Version: 1.5.0_06
> >> INFO: JRE Impl Version: 1.5.0_06-64
> >> INFO: O/S: Mac OS X / ppc / 10.4.6
> >> INFO: Using Wavecom (Generic) AT handler.
>
> SendMessage(): Send a message.
> Using SMSLib API for Java v1.2.2
>
> Connecting ..... :
> >> INFO: CSerialDriver(): Connecting...
> Experimental: JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version = RXTX-2.1-7
> >> INFO: CSerialDriver(): Disconnecting...
> gnu.io.PortInUseException: Unknown Application
> at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354)
> at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1)
> at org.smslib.CService.connect(CService.java:197)
> at SendMessage.main(SendMessage.java:38)
>
> Thanks.
>
> - Jon
>
>
>
>
> ====================
>
> Hello Jon,
>
> From OSX's standpoint a symbolic link is not a device (as far as I
> know). What stops you from using tty.usbserial? Did you try hard-
> linking?
>
> Regards,
> Joachim
>
>
>
> From:  "Yoke K" <tropicsu at hotmail.com>
> To:  rxtx at qbang.org
> Subject:  RXTX-2.1-7 / MAC OS X / NoSuchPortException
> Date:  Sat, 17 Jun 2006 15:32:48 +0000
> >Hi,
> >
> >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to
> >work with MAC OS X.
> >I am using iTegno 3000 - USB GPRS Modem.
> >
> >Files in /dev and a symbolic link as follows:
> >
> >crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
> >crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
> >lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->
> >tty.usbserial
> >
> >In my SendMessage.java, I have this line:
> >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
> >
> >Appreciate any help ?
> >
> >- Jon
> >
> >
> >Errors as follows:
> >
> >>>INFO: SMSLib API for Java / v1.2.2
> >>>INFO: Using port: /dev/ttyS1 @ 56000 baud.
> >>>INFO: JRE Version: 1.5.0_06
> >>>INFO: JRE Impl Version: 1.5.0_06-64
> >>>INFO: O/S: Mac OS X / ppc / 10.4.6
> >>>INFO: Using Wavecom (Generic) AT handler.
> >
> >SendMessage(): Send a message.
> >  Using SMSLib API for Java v1.2.2
> >
> >Connecting ..... :
> >>>INFO: CSerialDriver(): Connecting...
> >Experimental:  JNI_OnLoad called.
> >Stable Library
> >=========================================
> >Native lib Version = RXTX-2.1-7
> >Java lib Version   = RXTX-2.1-7
> >>>INFO: CSerialDriver(): Disconnecting...
> >gnu.io.NoSuchPortException
> >        at
> >gnu.io.CommPortIdentifier.getPortIdentifier 
> (CommPortIdentifier.java:218)
> >        at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
> >        at org.smslib.CService.connect(CService.java:197)
> >        at SendMessage.main(SendMessage.java:38)
> >
> >_________________________________________________________________
> >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
> >
>
> Find love online with MSN Personals
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Tue Jun 20 02:35:24 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 10:35:24 +0200
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>

Hello everybody,

I have been fighting a bit with the javax.comm version of RXTX the  
last days. I am working on the README .OSX now and try to figure out  
which should be the "suggested" installation.

The facts:
------

- the "generic" comm.jar version of javax.comm which has been made re- 
available tries to load com.sun.comm.SolarisDriver
- this classname can be overridden ONLY by putting a file  
javax.comm.properties in {java.home}/lib
- if it is not overridden and SolarisDriver.class is not found  
CommPortIdentifier will be disfunctional (in particual it is not  
possible to add CommPort's via CommPortIdentifier.add).
- the license distributed with comm.jar does not allow the  
modification/addition of classes in javax.comm (however no mention of  
com.sun...)


What really bothers me is to suggest putting this config file in the  
"global" vm installation. This is particularly ugly on the Mac as  
there are several VM installations and the file may be forgotten.  
Additionally it may create versioning problems. I prefer an  
installation where all files are local to the application (even  
comm.jar).

In my opinion the ideal situation would be:
------

1) The author of a program compiles against javax.comm.
2a) For platforms supported by Sun the user is free to use the 3.0  
comm.jar download from Sun
2b) For platforms not supported by Sun the user adds RXTXComm.jar to  
the classpath of the application (and librxtxSerial.jnilib to the  
application directory). Also he will need the 2.0.3 generic comm.jar  
from Sun.
3) Nobody messes with the global VM installation.

Of course 2a) and 2b) could be handled by the author of the program  
via an appropriate installer. The author could also decide to always  
use RXTX and include the generic javax.comm classes as well as the  
RXTX classes in his application jar. [If he further uses an explicit  
call to System.load() he may even include the jnilib(s) in the jar,  
extract it (based on the platform name) at runtime to a temp file and  
load it from there.]


Suggested solution:
------

We only need to put the following class in the classpath BEFORE Suns  
comm.jar

   package com.sun.comm;
   public class SolarisDriver extends gnu.io.RXTXCommDriver {
   }

This is not "the pure art" (TM). It depends on an implementation  
detail of the generic driver. However, so does the  
javax.comm.properties file - as we have seen when Sun released 3.0.  
It has the following advantages:

- The "generic" javax.comm implementation will happily load this  
class as its primary driver.
- No javax.comm.properties file is required.
- This does not violate the javax.comm license agreement as there is  
no mention of the "com.sun.comm" package in this license agreement at  
all.
- Authors packaging comm.jar with their application can strip out all  
com.sun.comm classes from comm.jar


Please comment!

Joachim



From joachim at buechse.de  Tue Jun 20 02:50:36 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 10:50:36 +0200
Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar
Message-ID: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>

There has been some discussions about the best way to install RXTX  
and where to place files.

I suggest that,

- we include the native libraries for the most common operating  
systems (in a special version of) RXTXcomm.jar
- we add loader code which tries to extract and load the platform  
specific binary at runtime
- on failure the current mechanism remains as a fallback

Wether the current mechanism should have priority (ie loadLibrary  
before load) remains to be discussed.


The advantages of this solution are
  - users of RXTX do not need to worry about java/platform specific  
file placement.
  - authors of applications may fully merge RXTX into their  
application jar (which provides a double-clickable application for  
Windows and OSX, Linux?).

Please comment,
Joachim

PS: Of course the suggested solution is already possible today,  
however relatively few programmers know how to correctly extract a  
binary resource file via the class loader and load it as a native  
library.


From tjarvi at qbang.org  Tue Jun 20 03:58:12 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT)
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
Message-ID: <Pine.LNX.4.61.0606200335190.14139@www>

> 2a) For platforms supported by Sun the user is free to use the 3.0
> comm.jar download from Sun
> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to
> the classpath of the application (and librxtxSerial.jnilib to the
> application directory). Also he will need the 2.0.3 generic comm.jar
> from Sun.

As there are no plans to support CommAPI 3.0 due to the limitations in its 
implementation mentioned before, I would not recommend projects use Sun's 
3.0 comm.jar.  They will lose the freedom to chose their low level 
implementation by being locked into vendor specific modifications.

Projects should chose between platform neutrality in CommAPI 2.0 and 
reduced platform neutrality in commapi 3.0.  Projects should also strongly 
consider the fact that the 2.0 comm.jar targets only a reduced number of 
JVMs.

Projects can go with rxtx 2.1 or other packages but should probably only 
consider using Sun CommAPI with rxtx if they did so in the past.  They 
should take steps to no longer depend upon this option being available.

> Suggested solution:
> ------
>
> We only need to put the following class in the classpath BEFORE Suns
> comm.jar
>
>   package com.sun.comm;
>   public class SolarisDriver extends gnu.io.RXTXCommDriver {
>   }
>
> This is not "the pure art" (TM). It depends on an implementation
> detail of the generic driver. However, so does the
> javax.comm.properties file - as we have seen when Sun released 3.0.
> It has the following advantages:
>
> - The "generic" javax.comm implementation will happily load this
> class as its primary driver.
> - No javax.comm.properties file is required.
> - This does not violate the javax.comm license agreement as there is
> no mention of the "com.sun.comm" package in this license agreement at
> all.
> - Authors packaging comm.jar with their application can strip out all
> com.sun.comm classes from comm.jar
>

I would not encourage people to place packages in the com.sun.comm 
namespace.  Authors using Sun's commapi 2.0 should just realize it is 
greatly limited in practical utility and consider moving to something that 
isn't being rescued from EOL.

The primary focus of this release is projects previously depending upon 
Sun CommAPI + RXTX.  There are no plans at this time to provide future 
support in this arrangement due to technical incompatabilities we have no 
control over in commapi 3.0 and limited utility of Sun's generic comm.jar 
in commapi 2.0 offered.  Projects should be aware of this so they can make 
appropriate plans.

--
Trent Jarvi
tjarvi at qbang.org


From paul.klissner at sun.com  Tue Jun 20 05:24:00 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Tue, 20 Jun 2006 04:24:00 -0700
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
In-Reply-To: <Pine.LNX.4.61.0606200335190.14139@www>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
	<Pine.LNX.4.61.0606200335190.14139@www>
Message-ID: <4497DAD0.10803@sun.com>

Trent Jarvi wrote:
>> 2a) For platforms supported by Sun the user is free to use the 3.0
>> comm.jar download from Sun
>> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to
>> the classpath of the application (and librxtxSerial.jnilib to the
>> application directory). Also he will need the 2.0.3 generic comm.jar
>> from Sun.
> 
> As there are no plans to support CommAPI 3.0 due to the limitations in its 
> implementation mentioned before, I would not recommend projects use Sun's 
> 3.0 comm.jar.  They will lose the freedom to chose their low level 
> implementation by being locked into vendor specific modifications.
> 
> Projects should chose between platform neutrality in CommAPI 2.0 and 
> reduced platform neutrality in commapi 3.0.  Projects should also strongly 
> consider the fact that the 2.0 comm.jar targets only a reduced number of 
> JVMs.

Well, that's a little ambiguous because the API is the same
either way.  We're talking about Sun's implementation vs.
other implementations.
> 
> Projects can go with rxtx 2.1 or other packages but should probably only 
> consider using Sun CommAPI with rxtx if they did so in the past.  They 
> should take steps to no longer depend upon this option being available.

3.0 is platform centric because there is a need to add some
platform awareness to Sun's implementation, and the choices
for how to do that are limited by the constraints of the API,
as mentioned in the javax.comm 2.0.3 comm.jar download's README.

I am really advocating getting a JSR open (http://www.jcp.org)
to push a new comm API that is more pluggable, platform neutral
and addresses some of the deficiencies of the current API. Then
we can achieve the optimal of platform neutrality while
simulataneously allowing the API to flexibly adapt to
heterogeneous environments.

This is not a question of attitude, this is an issue of resources,
time and commitment.  The current owners of javax.comm within
Sun would like nothing better than to see the ideal reached for
the API and a model that will extend well beyond the foreseeable
future and work for the industry overall.



> 
>> Suggested solution:
>> ------
>>
>> We only need to put the following class in the classpath BEFORE Suns
>> comm.jar
>>
>>   package com.sun.comm;
>>   public class SolarisDriver extends gnu.io.RXTXCommDriver {
>>   }
>>
>> This is not "the pure art" (TM). It depends on an implementation
>> detail of the generic driver. However, so does the
>> javax.comm.properties file - as we have seen when Sun released 3.0.
>> It has the following advantages:
>>
>> - The "generic" javax.comm implementation will happily load this
>> class as its primary driver.
>> - No javax.comm.properties file is required.
>> - This does not violate the javax.comm license agreement as there is
>> no mention of the "com.sun.comm" package in this license agreement at
>> all.
>> - Authors packaging comm.jar with their application can strip out all
>> com.sun.comm classes from comm.jar
>>
> 
> I would not encourage people to place packages in the com.sun.comm 
> namespace.  Authors using Sun's commapi 2.0 should just realize it is 
> greatly limited in practical utility and consider moving to something that 
> isn't being rescued from EOL.
> 
> The primary focus of this release is projects previously depending upon 
> Sun CommAPI + RXTX.  There are no plans at this time to provide future 
> support in this arrangement due to technical incompatabilities we have no 
> control over in commapi 3.0 and limited utility of Sun's generic comm.jar 
> in commapi 2.0 offered.  Projects should be aware of this so they can make 
> appropriate plans.

Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86,
or need the powerful portmapping features in javax.com 3.0, or would like to
acquire the Interactive Serial Port Test utility.

-Paul


From paul.klissner at sun.com  Tue Jun 20 05:33:44 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Tue, 20 Jun 2006 04:33:44 -0700
Subject: [Rxtx] Suggested installation RXTX 2.0x...
In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
Message-ID: <4497DD18.70207@sun.com>

Joachim Buechse wrote:
> Hello everybody,
> 
> I have been fighting a bit with the javax.comm version of RXTX the  
> last days. I am working on the README .OSX now and try to figure out  
> which should be the "suggested" installation.
> 
> The facts:
> ------
> 
> - the "generic" comm.jar version of javax.comm which has been made re- 
> available tries to load com.sun.comm.SolarisDriver
> - this classname can be overridden ONLY by putting a file  
> javax.comm.properties in {java.home}/lib
> - if it is not overridden and SolarisDriver.class is not found  
> CommPortIdentifier will be disfunctional (in particual it is not  
> possible to add CommPort's via CommPortIdentifier.add).
> - the license distributed with comm.jar does not allow the  
> modification/addition of classes in javax.comm (however no mention of  
> com.sun...)
> 
> 
> What really bothers me is to suggest putting this config file in the  
> "global" vm installation. This is particularly ugly on the Mac as  
> there are several VM installations and the file may be forgotten.  
> Additionally it may create versioning problems. I prefer an  
> installation where all files are local to the application (even  
> comm.jar).
> 
> In my opinion the ideal situation would be:
> ------
> 
> 1) The author of a program compiles against javax.comm.
> 2a) For platforms supported by Sun the user is free to use the 3.0  
> comm.jar download from Sun
> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to  
> the classpath of the application (and librxtxSerial.jnilib to the  
> application directory). Also he will need the 2.0.3 generic comm.jar  
> from Sun.
> 3) Nobody messes with the global VM installation.
> 
> Of course 2a) and 2b) could be handled by the author of the program  
> via an appropriate installer. The author could also decide to always  
> use RXTX and include the generic javax.comm classes as well as the  
> RXTX classes in his application jar. [If he further uses an explicit  
> call to System.load() he may even include the jnilib(s) in the jar,  
> extract it (based on the platform name) at runtime to a temp file and  
> load it from there.]
> 

This was how the Sun implementation originated (I did not write
that code).  I completely agree, and I fixed the whole conf file
locating mechanism in 3.0 to avoid the problems youmentioned.
However, I was unaware of how RxTx was using Sun's implementation,
so I didn't architect it in such a way as to avoid namespace pollution
in the native space in for the backend provider.  In retrospect,
I should have done that differently just as a design principle,
but at this point I don't have the spare cycles to get that all
re-factored.  Further, I'm loathe to do it, because the whole
thing will still be an under-the-hood hack due to the constraints
of the API itself.

Paul





From brian at mbari.org  Tue Jun 20 10:23:54 2006
From: brian at mbari.org (Brian Schlining)
Date: Tue, 20 Jun 2006 09:23:54 -0700
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>


Hi Joachim,

> There has been some discussions about the best way to install RXTX
> and where to place files.
>
> I suggest that,
>
> - we include the native libraries for the most common operating
> systems (in a special version of) RXTXcomm.jar
> - we add loader code which tries to extract and load the platform
> specific binary at runtime
> - on failure the current mechanism remains as a fallback

I like your suggestion. However, my understanding is that in general  
the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH  
(Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to  
be loaded by the JVM. The alternative is to point to your native lib  
directory using -Djava.library.path=/my/dir/with/native/libs when you  
launch the JVM. So, I'm very interested to know how you're planning  
to work around this.

> PS: Of course the suggested solution is already possible today,
> however relatively few programmers know how to correctly extract a
> binary resource file via the class loader and load it as a native
> library.

So how do you use it to dynamically load a native lib? I've read that  
you can't really modify the java.library.path after the JVM has been  
launched. (http://forum.java.sun.com/thread.jspa? 
threadID=627890&tstart=90)

Thanks

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0007.html

From joachim at buechse.de  Tue Jun 20 09:20:29 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 17:20:29 +0200
Subject: [Rxtx] 2.0x in sync with 2.1x
Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>

I have added most of the changes from the 2.1 branch to the 2.0 branch.

This includes
  - correction of illegal javadoc comments
  - implementation errors in handling of Thread.interrupt in  
RXTXPort.java
  - MacOS X locking without lock files/special user groups
  - XCode project which builds a universal binary library
  - updated documentation for OSX

I have done some minimal testing (only G4).
[Trent: there are still some changes you made for specific baud  
rates. I will not sync this, as I can not test them. From my  
perspective we are ready for 2.08/2.18]

The updated documentation can be found in the file README.OSX. Here  
it is:

------------------------ Required files -----------------------

To use or compile RXTX 2.0.x you need to downlad the "generic"  
version (2.0.3)
of the javax.comm implementation from Sun. The zip you download  
contains an
archive comm.jar which is required:

- To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar

- To run the app you will need comm.jar in the classpath or in  
{java.lib.path}


------------------------ Installation on MacOSX -----------------------

WARNING: Please read this section until the end.

---
Preparation
---

You may want to spare your users the burden of modifying the global VM
installation. OSX has several different VM versions installed by  
default and
regular users will be unable to figure out which version will load your
application.

If you provide the class

package com.sun.comm;
public class SolarisDriver extends gnu.io.RXTXCommDriver {
}

and make sure, that it is present in the classpath before Suns  
"generic" comm.jar
your users can skip the following step:

Create a file named
    javax.comm.properties
in the directory
    /System/Library/Frameworks/JavaVM.framework/Home/lib/
which contains (only) the following line (no leading space):
    Driver=gnu.io.RXTXCommDriver



----
The unsafe way of using RXTX on OS X:
----

RXTX can be installed by putting the files
   libSerial.jnilib
   RXTXcomm.jar
   comm.jar
into the folder
   /Library/Java/Extensions

This is NOT RECOMMENDED as it creates versioning conflicts among  
applications.
However you may be forced to install it this way if an application  
was written
for Windows or Linux, requires RXTX and you are not able to change  
its starter.


----
The safe way of using RXTX on OS X:
----

Make sure that you have no (older) version of RXTX installed in
   /Library/Java/Extensions
   /System/Library/Java/Extensions
   /usr/lib/java

Put
   libSerial.jnilib
in the directory of the application (the JavaVM will find it there). Add
   RXTXComm.jar
   comm.jar
to the application classpath or include the classes in the  
application jar.
(Some applications already include the RXTX classes in their  
application jar,
in which case only the file libSerial.jnilib is required).


----
History
----

Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation  
of lockfiles
required special permissions for the user executing an application  
based on RXTX.
To simplify the setup RXTX came with an installer modifying group  
permissions
and installing RXTX in the global location /Library/Java/Extensions.  
However
this was prune to versioning conflicts and is no longer recommended.

--------------------- Build instructions for OSX XCode  
-------------------

contributed by Joachim Buechse <joachim at buechse.de>
original version by Dmitry Markman <dmarkman at mac.com>

System requirements for building:
MacOSX 10.4
XCode 2.3

   open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj
   choose libSerial.jnilib target
   build

After the build you will find RXTXcomm.jar and libSerial.jnilib files  
in the
directory build/Development.

In case you can't find RXTXcomm.jar build the RXTXcomm target manually.
In case of (serious) problems feel free to contact joachim at buechse.de .



From tjarvi at qbang.org  Tue Jun 20 22:01:45 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT)
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
Message-ID: <Pine.LNX.4.61.0606202127270.14139@www>

> ---
> Preparation
> ---
>
> You may want to spare your users the burden of modifying the global VM
> installation. OSX has several different VM versions installed by
> default and
> regular users will be unable to figure out which version will load your
> application.
>
> If you provide the class
>
> package com.sun.comm;
> public class SolarisDriver extends gnu.io.RXTXCommDriver {
> }
>
> and make sure, that it is present in the classpath before Suns
> "generic" comm.jar
> your users can skip the following step:

Hi Joachim

With regards to the above, I have not seen that we have Sun's OK to 
promote that.  I'm not very comfortable with the distribution 
documentation advocating this without Sun agreeing.

I see your point but I'd rather not actively promote putting classes in 
Sun's namespace without permission if you don't mind.  This isn't about 
what is in a license.

I'll go through the code tomorrow night.  It was a late night at work 
today.  There is also a w32 fix comming for people opening and closing 
multiple ports.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Wed Jun 21 01:56:45 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 21 Jun 2006 09:56:45 +0200
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <Pine.LNX.4.61.0606202127270.14139@www>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
	<Pine.LNX.4.61.0606202127270.14139@www>
Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>

Hello Trent,

I guess we will not get an explicit OK from Sun for such a hack. I  
think Paul has made it pretty clear, that he does not have the  
resources to modify the 2.x or 3.x code for the needs of RXTX. I'm  
not thrilled but OK with the current API. Hence I dont agree with  
Paul's idea to start a new JSR to fix the implementation - but that's  
mainly because I dont have the time to push it. According to their  
Readme Sun sees no business case in having cross platform support for  
javax.comm - that is sad but it's none of my business. However I  
prefer to program versus javax.comm in my projects as this gives an  
advanced user the chance to exchange the provider without access to  
the code.

I interpret Pauls reponse to my original "Request for comment" as a  
quiet acceptance of the hack I propose (he did respond, but not at  
all to the sun.comm namespace suggestion). This is certainly not  
something we should put into RXTXcomm.jar but hinting a work around  
for implementation errors should be allowed. That's why I've choosen  
the wording "You may want to spare" and "If you provide". The company  
I worked for has choosen similar hacks for years to fix bugs in swing  
for JDK1.1 applications. Those hacks were usually included in their  
own swingpatch.jar.

Having said all that - I do not take it as an insult if you remove  
the paragraph from the Readme. I appreciate that you notified me  
before. It would be interesting to hear some more opinions from the  
list members...

Best regards,
Joachim


On 21.06.2006, at 06:01, Trent Jarvi wrote:

>> ---
>> Preparation
>> ---
>>
>> You may want to spare your users the burden of modifying the  
>> global VM
>> installation. OSX has several different VM versions installed by
>> default and
>> regular users will be unable to figure out which version will load  
>> your
>> application.
>>
>> If you provide the class
>>
>> package com.sun.comm;
>> public class SolarisDriver extends gnu.io.RXTXCommDriver {
>> }
>>
>> and make sure, that it is present in the classpath before Suns
>> "generic" comm.jar
>> your users can skip the following step:
>
> Hi Joachim
>
> With regards to the above, I have not seen that we have Sun's OK to
> promote that.  I'm not very comfortable with the distribution
> documentation advocating this without Sun agreeing.
>
> I see your point but I'd rather not actively promote putting  
> classes in
> Sun's namespace without permission if you don't mind.  This isn't  
> about
> what is in a license.
>
> I'll go through the code tomorrow night.  It was a late night at work
> today.  There is also a w32 fix comming for people opening and closing
> multiple ports.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Wed Jun 21 02:03:33 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 21 Jun 2006 10:03:33 +0200
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
	<6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
Message-ID: <BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>

See System.load(String) [it's also mentioned under the URL you posted].

Regards,
Joachim


On 20.06.2006, at 18:23, Brian Schlining wrote:

> So how do you use it to dynamically load a native lib? I've read  
> that you can't really modify the java.library.path after the JVM  
> has been launched. (http://forum.java.sun.com/thread.jspa? 
> threadID=627890&tstart=90)
>
> Thanks
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From baris.ozkan at elikasu.com.tr  Wed Jun 21 07:58:06 2006
From: baris.ozkan at elikasu.com.tr (Baris)
Date: Wed, 21 Jun 2006 16:58:06 +0300
Subject: [Rxtx] RS 232 ..additional parameters
Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>

Hi,
 
Currently i am developing an application that requires to connect to a
remote rs232 device through  a dialup connection.
 
My problem is that the communication needs several more connection
parameters (i extracted that information from the vendor's dll , listed at
the end of the message)
 
I explored rxtx API and src files and could not find methods to set a
majority  of the parameters.
Am i missing any point or does rxtx is limited to soem standard set of
functionality(e.g. commAPI)? How  is it possible ,if i want to put some
extensions(???) to current rxtx implementation?
 
I am not very good at rs232 programming so excuse me if this message  is
boring one.
 
Thanx
 
Baris Ozkan
 
 
A Listing of Parameters:
 
 
typedef struct _DCB {

DWORD DCBlength; /* sizeof(DCB) */

DWORD BaudRate; /* Baudrate at which running */

DWORD fBinary: 1; /* Binary Mode (skip EOF check) */

DWORD fParity: 1; /* Enable parity checking */

DWORD fOutxCtsFlow:1; /* CTS handshaking on output */

DWORD fOutxDsrFlow:1; /* DSR handshaking on output */

DWORD fDtrControl:2; /* DTR Flow control */

DWORD fDsrSensitivity:1; /* DSR Sensitivity */

DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */

DWORD fOutX: 1; /* Enable output X-ON/X-OFF */

DWORD fInX: 1; /* Enable input X-ON/X-OFF */

DWORD fErrorChar: 1; /* Enable Err Replacement */

DWORD fNull: 1; /* Enable Null stripping */

DWORD fRtsControl:2; /* Rts Flow control */

DWORD fAbortOnError:1; /* Abort all reads and writes on Error */

DWORD fDummy2:17; /* Reserved */

WORD wReserved; /* Not currently used */

WORD XonLim; /* Transmit X-ON threshold */

WORD XoffLim; /* Transmit X-OFF threshold */

BYTE ByteSize; /* Number of bits/byte, 4-8 */

BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */

BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */

char XonChar; /* Tx and Rx X-ON character */

char XoffChar; /* Tx and Rx X-OFF character */

char ErrorChar; /* Error replacement char */

char EofChar; /* End of Input character */

char EvtChar; /* Received Event character */

WORD wReserved1; /* Fill for now. */

} DCB, *LPDCB;

typedef struct _COMMTIMEOUTS {

DWORD ReadIntervalTimeout; /* Maximum time between read chars. */

DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */

DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */

DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */

DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */

} COMMTIMEOUTS,*LPCOMMTIMEOUTS;

dcb.fOutX = FALSE;

dcb.fInX = FALSE;

dcb.fOutxCtsFlow = FALSE;

dcb.fBinary = TRUE;

dcb.fRtsControl = RTS_CONTROL_ENABLE;

SetCommState(hComm , &dcb ); 

COMMTIMEOUTS commTimeOut;

GetCommTimeouts(hComm, &commTimeOut );

commTimeOut.WriteTotalTimeoutMultiplier = 1; 

commTimeOut.WriteTotalTimeoutConstant = 18; 

// commTimeOut.ReadIntervalTimeout = 28; 

commTimeOut.ReadIntervalTimeout = 0; 

// commTimeOut.ReadTotalTimeoutMultiplier = 184; 

commTimeOut.ReadTotalTimeoutMultiplier = 300; 

// commTimeOut.ReadTotalTimeoutConstant = 1200;

commTimeOut.ReadTotalTimeoutConstant = 1200;

SetCommTimeouts(hComm, &commTimeOut);

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0007.html

From ajmas at sympatico.ca  Wed Jun 21 08:14:26 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Wed, 21 Jun 2006 10:14:26 -0400
Subject: [Rxtx] When is 2.18 planned for?
Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

Just curious as to know if there is a target date for 2.18?

Andre



From brian at mbari.org  Wed Jun 21 09:36:00 2006
From: brian at mbari.org (Brian Schlining)
Date: Wed, 21 Jun 2006 08:36:00 -0700
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
	<6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
	<BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>
Message-ID: <A21C9BC0-7894-4B08-AC82-44E11AB3D461@mbari.org>

Ha!!

I suppose I should read my own postings. ;-)

Thanks
B

On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote:

> See System.load(String) [it's also mentioned under the URL you  
> posted].
>
> Regards,
> Joachim
>
>
> On 20.06.2006, at 18:23, Brian Schlining wrote:
>
>> So how do you use it to dynamically load a native lib? I've read
>> that you can't really modify the java.library.path after the JVM
>> has been launched. (http://forum.java.sun.com/thread.jspa?
>> threadID=627890&tstart=90)

Brian Schlining
Software Engineer
http://www.mbari.org




From ajmas at sympatico.ca  Wed Jun 21 16:41:28 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Wed, 21 Jun 2006 18:41:28 -0400
Subject: [Rxtx] CVS build question
Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X:

 The JCL extension to RxTx requires comm.jar
 If you intend to use RxTx for commapi support comm.jar
 needs to be located in  /System/Library/Frameworks/JavaVM.framework/
  Versions/1.5/Home/lib/ext/comm.jar

I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me.

On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native).

Andre






From tjarvi at qbang.org  Wed Jun 21 18:00:04 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT)
Subject: [Rxtx] CVS build question
In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606211756310.14139@www>

On Wed, 21 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> Is the CVS repository meant to build for gnu.io or javax.comm? I ask 
> this, because I see the following when calling ./configure from MacOS X:
>
> The JCL extension to RxTx requires comm.jar
> If you intend to use RxTx for commapi support comm.jar
> needs to be located in  /System/Library/Frameworks/JavaVM.framework/
>  Versions/1.5/Home/lib/ext/comm.jar
>
> I am wanting to build for the gnu.io package, since I want to jump ahead 
> and see if the changes, intended for 2.18 for MacOS X, work for me.
>
> On a side note /Library/Java/Extensions should be included as a valid 
> search path for the JAR, since this is where Apple recommends placing 
> third party extensions (both Java and native).
>

rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel"
rxtx 2.0 src is obtained with "cvs checkout rxtx-devel"

rxtx 2.1 is a complete package in namespace gnu.io
rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 18:02:23 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT)
Subject: [Rxtx] When is 2.18 planned for?
In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606211800180.14139@www>

On Wed, 21 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> Just curious as to know if there is a target date for 2.18?
>

Hi Andre

"When it is ready" :)

Probably this weekend.  Maybe sooner.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 18:10:18 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT)
Subject: [Rxtx] RS 232 ..additional parameters
In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>
References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>
Message-ID: <Pine.LNX.4.61.0606211805010.14139@www>

On Wed, 21 Jun 2006, Baris wrote:

> Hi,
>
> Currently i am developing an application that requires to connect to a
> remote rs232 device through  a dialup connection.
>
> My problem is that the communication needs several more connection
> parameters (i extracted that information from the vendor's dll , listed at
> the end of the message)
>
> I explored rxtx API and src files and could not find methods to set a
> majority  of the parameters.
> Am i missing any point or does rxtx is limited to soem standard set of
> functionality(e.g. commAPI)? How  is it possible ,if i want to put some
> extensions(???) to current rxtx implementation?
>
> I am not very good at rs232 programming so excuse me if this message  is
> boring one.
>
> Thanx
>

Hi Baris

> typedef struct _DCB {
> typedef struct _COMMTIMEOUTS {

These are all handled in termios.c.  It is possible to add extensions to 
rxtx 2.1.  It may well be that the defaults are the same for the variables 
not covered by the existing API.  You can dump the DCB and COMMTIMEOUTS 
from inside termios.c to compare.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 20:23:30 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT)
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
	<Pine.LNX.4.61.0606202127270.14139@www>
	<789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>
Message-ID: <Pine.LNX.4.61.0606212012210.14139@www>

> I'm
> not thrilled but OK with the current API. Hence I dont agree with
> Paul's idea to start a new JSR to fix the implementation - but that's
> mainly because I dont have the time to push it. According to their
> Readme Sun sees no business case in having cross platform support for
> javax.comm - that is sad but it's none of my business. However I
> prefer to program versus javax.comm in my projects as this gives an
> advanced user the chance to exchange the provider without access to
> the code.

Hi Joachim

With regards to the JSR, I think that would be Doug's call.  The effort I 
put in would have to be on my own time which would not be a great deal.  I 
could help things go smoothly but thats not the same as pushing something 
through.

--
Trent Jarvi
tjarvi at qbang.org



From vt at freehold.crocodile.org  Wed Jun 21 21:05:22 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Wed, 21 Jun 2006 20:05:22 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
Message-ID: <449A08F2.3020106@freehold.crocodile.org>

Hello all,

I know this question may belong to JSR lists, but since all interested 
parties are here, I thought I just ask this question here, again...

A while ago I run into a problem and wrote a rant, here: 
http://servomaster.sourceforge.net/dev/serial-usb.html
At the time of writing I didn't think of adding another possible 
solution - changing the CommAPI specs to support removable devices. 
Apparently, Serial/USB bridges are here to stay, and this issue has to 
be addressed.

Wonder if anything changed since, and any abstractions for supporting 
removable devices made it into current or future Java CommAPI drafts - 
Paul, any comments?

--vt



From joachim at buechse.de  Thu Jun 22 01:59:54 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 22 Jun 2006 09:59:54 +0200
Subject: [Rxtx] CVS build question
In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de>

Hello Andre,

I am not sure how well the configure/make mechanism will work on OSX.  
I know that a while ago some contributors tried to get configure/make  
working on OSX but from comments I found in the readmes this work was  
only partially successfull. For compilation on OSX we have used the  
ProjectBuilder/XCode projects you can find in MACOSX_IDE.

Regarding the  ./configure comment:
RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config  
file javax.comm.properties. The later MUST reside in {java.home}/lib.  
As the two only work together putting comm.jar into  /Library/Java/ 
Extensions  and hence making it available to all current and future  
VM installations will only add to confusion.

Regards,
Joachim

On 22.06.2006, at 00:41, Andre-John Mas wrote:

> Hi,
>
> Is the CVS repository meant to build for gnu.io or javax.comm? I  
> ask this, because I see the following when calling ./configure from  
> MacOS X:
>
>  The JCL extension to RxTx requires comm.jar
>  If you intend to use RxTx for commapi support comm.jar
>  needs to be located in  /System/Library/Frameworks/JavaVM.framework/
>   Versions/1.5/Home/lib/ext/comm.jar
>
> I am wanting to build for the gnu.io package, since I want to jump  
> ahead and see if the changes, intended for 2.18 for MacOS X, work  
> for me.
>
> On a side note /Library/Java/Extensions should be included as a  
> valid search path for the JAR, since this is where Apple recommends  
> placing third party extensions (both Java and native).
>
> Andre
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Thu Jun 22 02:51:05 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 22 Jun 2006 10:51:05 +0200
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449A08F2.3020106@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>

Hello Vadim,

I think that your rant is to the point. However it is a bit like  
saying that Windows is at the source of email degradation and the  
only solution is to have users switch to safer operating systems.

I don't see how javax.comm or RXTX can address the problems you  
mention. Of course it would be super cool if javax.comm could magicly  
find the "matching" usb-device and query it's configuration via the  
usb protocol - however this magic (mapping /dev/xyz to its underlying  
USB device) is not supported by any kernel APIs I am aware of. It  
could be supported via POSSIX ioctl calls but then you should address  
your rant to the POSSIX group...

So for the time beeing it's either up to the virtual comm port driver  
to provide a usefull name under /dev/ or to the user choosing the  
right port to use. One example of a smart(er) com port driver is the  
KDDI driver for OSX, which will create device names like "/dev/ 
cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- 
encoded into the bridge chip. The same driver for windows also has  
some options allowing it in theory to recreate the same COMx every  
time a device is plugged/unplugged.

For most industrial applications however it will be up to the user to  
choose the right port (without getting a lot of help doing so).

Probing serial ports can go wrong, that's right. However any serial  
device developper would be well adviced to implement a basic set of  
Hayes AT modem commands (be it a modem or not). Especially AT I0.  
Anyone failing to do so risks that the users favourite TCP/PPP/FAX  
application or stack will kill the device in short time.

Best regards,
Joachim


On 22.06.2006, at 05:05, Vadim Tkachenko wrote:

> Hello all,
>
> I know this question may belong to JSR lists, but since all interested
> parties are here, I thought I just ask this question here, again...
>
> A while ago I run into a problem and wrote a rant, here:
> http://servomaster.sourceforge.net/dev/serial-usb.html
> At the time of writing I didn't think of adding another possible
> solution - changing the CommAPI specs to support removable devices.
> Apparently, Serial/USB bridges are here to stay, and this issue has to
> be addressed.
>
> Wonder if anything changed since, and any abstractions for supporting
> removable devices made it into current or future Java CommAPI drafts -
> Paul, any comments?
>
> --vt
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From vt at freehold.crocodile.org  Thu Jun 22 13:16:03 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 12:16:03 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
Message-ID: <20060622191603.GA17487@freehold.crocodile.org>

Hello Joachim,

> I think that your rant is to the point. However it is a bit like  
> saying that Windows is at the source of email degradation and the  
> only solution is to have users switch to safer operating systems.

I guess the problem is that the rant itself is obsolete and has to be
updated according to latest developments. At the time of writing there
weren't that many bridges around, and the trend didn't manifest itself as it
does now.

> I don't see how javax.comm or RXTX can address the problems you  
> mention.

I would agree that javax.comm won't be able to address the problem, at least
in the short run. As for RxTx - well, nobody prevents it from being a
superset of CommAPI specification, right? RxTx being the de-facto standard
for quite a few platforms, I'd daresay the standard may follow.

> Of course it would be super cool if javax.comm could magicly find the
> "matching" usb-device and query it's configuration via the usb protocol -
> however this magic (mapping /dev/xyz to its underlying USB device) is not
> supported by any kernel APIs I am aware of. It could be supported via
> POSSIX ioctl calls but then you should address your rant to the POSSIX
> group...

As a matter of fact, my bigger concern is addressing the fact that a serial
device can now be removable. This hasn't been the case before, and it
clearly is now. Regarding the above, well, I guess if we accept this fact,
we also need to accept the fact that we need at least rudimentary means of
identification of a serial device. For the USB case, it would usually be the
vendor/product ID, plus possible serial number - but it is irrelevant what
exactly the identifying information is, as long as it allows to identify the
device.

A paradigm shift is required, this is what I wanted to say. Serial devices
can be removed and replaced, it's now our turn to learn to deal with it.

> Joachim

--vt


From jredman at ergotech.com  Thu Jun 22 13:41:44 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 13:41:44 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
Message-ID: <449AF278.6000903@ergotech.com>


Vadim Tkachenko wrote:
> A paradigm shift is required, this is what I wanted to say. Serial devices
> can be removed and replaced, it's now our turn to learn to deal with it.

The removal if the serial port hardly significantly different from the 
removal of the device attached to the serial port.   Different, 
slightly, but not a "paradigm shift".

And yes, someone could unplug a USB serial device and plug it into a 
different USB port so that it has a different name/number, but they 
could do that with the device itself, move it from com1 to com2.

Am I missing something?

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 13:57:27 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 12:57:27 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449AF278.6000903@ergotech.com>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
Message-ID: <20060622195727.GA20247@freehold.crocodile.org>

On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote:
> 
> Vadim Tkachenko wrote:
> > A paradigm shift is required, this is what I wanted to say. Serial devices
> > can be removed and replaced, it's now our turn to learn to deal with it.
> 
> The removal if the serial port hardly significantly different from the 
> removal of the device attached to the serial port.   Different, 
> slightly, but not a "paradigm shift".
> 
> And yes, someone could unplug a USB serial device and plug it into a 
> different USB port so that it has a different name/number, but they 
> could do that with the device itself, move it from com1 to com2.
> 
> Am I missing something?

Yes, the fact that they could unplug a device A and plug a device B. With
the introduction of the concept of removability, the notion of the serial
port itself is not as important anymore, but the notion of the unique device
identifier is.

Consider a situation: long running system (enterprise HVAC, tens of nodes,
tens of thousands square feet area, hundreds of thousand dollars worth of
equipment being conditioned, can't shut down), serial/usb device fails, is
replaced by an identical device with a different serial #.

A little bit farfetched, but hopefully highlighting the point I'm trying to
make.

> Jim

--vt


From jredman at ergotech.com  Thu Jun 22 14:37:38 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 14:37:38 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>	<20060622191603.GA17487@freehold.crocodile.org>	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
Message-ID: <449AFF92.8080003@ergotech.com>


Vadim Tkachenko wrote:
>>
>> Am I missing something?
> 
> Yes, the fact that they could unplug a device A and plug a device B. With
> the introduction of the concept of removability, the notion of the serial
> port itself is not as important anymore, but the notion of the unique device
> identifier is.

Serial devices are always removable.  I could unplug _serial_ device A 
and plug in _serial_ device B.  We have systems running with two RS485 
ports, one talks to a Modbus PLC network one to a number of drives on a 
proprietary protocol.  If you plug the wrong DB9 into the wrong port the 
application doesn't work.

If you dangle a USB 485 converter on the end of the DB9 you've just 
moved the problem from RS485 to USB, but the problem/effect is the same.

> 
> Consider a situation: long running system (enterprise HVAC, tens of nodes,
> tens of thousands square feet area, hundreds of thousand dollars worth of
> equipment being conditioned, can't shut down), serial/usb device fails, is
> replaced by an identical device with a different serial #.
> 
> A little bit farfetched, but hopefully highlighting the point I'm trying to
> make.

Nothing's changed.  If I had a 4 port ISA board and plugged it into my 
new shiny '386 machine.  I could have com ports 9-12.  If I took a board 
off the shelf and didn't set the jumpers, I would have com ports 3-6.

The problem's the same.  If you replace with identical product then the 
com ports  will be the same - no software changes required.  If you 
replace one piece of hardware with hardware from a different 
manufacturer, then the naming/numbering may change.  You're physically 
changing the system, so may reasonably expect to have to make a software 
change.  RXTX actually handles this situation quite well with the -D 
command line option.  (My experience has generally been that the port 
number depends more on the USB port used than the hardware - so the 
chances are even with a hardware change the port number/name will be the 
same.)

Slightly Off Topic - there is a reason why industrial users will pay a 
premium for continued availability of hardware.  Yes you can mail-order 
a $10 USB converter and it will work, but there's no guarantee that the 
next time you buy the same part number from the same vendor it will be 
the same.  The industrial vendors will charge you $100+ for the same 
item, but it will be the same every time you buy it for the next 5 to 10 
years.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 14:37:19 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 13:37:19 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
Message-ID: <20060622203719.GA22521@freehold.crocodile.org>

Hello again,

And while I'm at it, why don't just say this: give me one good reason to
write 3+ different ways of handling removable devices, one for USB, one for
FireWire, one for serial...

I understand very well that this goes way beyond the scope of RxTx and
CommAPI and will require cooperation between them and javax.usb and whatever
JSR is responsible for FireWire implementation - but the end result is well
worth it. Abstract out and generalize arrival/departure/monitoring/discovery
API, provide protocol specific extensions for each, live happily ever after.

--vt


On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote:
> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote:
> > 
> > Vadim Tkachenko wrote:
> > > A paradigm shift is required, this is what I wanted to say. Serial devices
> > > can be removed and replaced, it's now our turn to learn to deal with it.
> > 
> > The removal if the serial port hardly significantly different from the 
> > removal of the device attached to the serial port.   Different, 
> > slightly, but not a "paradigm shift".
> > 
> > And yes, someone could unplug a USB serial device and plug it into a 
> > different USB port so that it has a different name/number, but they 
> > could do that with the device itself, move it from com1 to com2.
> > 
> > Am I missing something?
> 
> Yes, the fact that they could unplug a device A and plug a device B. With
> the introduction of the concept of removability, the notion of the serial
> port itself is not as important anymore, but the notion of the unique device
> identifier is.
> 
> Consider a situation: long running system (enterprise HVAC, tens of nodes,
> tens of thousands square feet area, hundreds of thousand dollars worth of
> equipment being conditioned, can't shut down), serial/usb device fails, is
> replaced by an identical device with a different serial #.
> 
> A little bit farfetched, but hopefully highlighting the point I'm trying to
> make.
> 
> > Jim
> 
> --vt
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx


From jredman at ergotech.com  Thu Jun 22 15:13:49 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 15:13:49 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>	<20060622191603.GA17487@freehold.crocodile.org>	<449AF278.6000903@ergotech.com>	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
Message-ID: <449B080D.9080208@ergotech.com>


Vadim Tkachenko wrote:
> Hello again,
> 
> And while I'm at it, why don't just say this: give me one good reason to
> write 3+ different ways of handling removable devices, one for USB, one for
> FireWire, one for serial...

You don't, they're all the same "I have lost communication with my 
serial device".

The only thing you could really do is improve error reporting by knowing 
the exact sub-system.  ("Device X which is/was attached to USB port Y is 
no longer functioning, please check the USB ports, the device, the 
cables and anything else you can think of that may be a cause of 
failure.")  That just requires an intelligent description of the port.

> I understand very well that this goes way beyond the scope of RxTx and
> CommAPI and will require cooperation between them and javax.usb and whatever
> JSR is responsible for FireWire implementation - but the end result is well
> worth it. Abstract out and generalize arrival/departure/monitoring/discovery
> API, provide protocol specific extensions for each, live happily ever after.

There's a huge list of pseudo-serial devices each with a different set 
of requirements, Bluetooth, RFC 2217, a host of proprietary systems, 
etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I 
have no clue how you'd implement them in a general/cross platform sense.

You haven't convinced me (and only me, others may see something that I 
don't, I'm not speaking for them) that this mechanism can be implemented 
in any practical sense.  That is, that the implementation could be wide 
enough to be consider generally available in RXTX regardless of the 
serial port implementation, platform, etc..  However, if you can come up 
with a general design and a reference implementation for one subsystem, 
I'd like to see it and might get on board.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 15:40:55 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 14:40:55 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449B080D.9080208@ergotech.com>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
Message-ID: <20060622214055.GA25497@freehold.crocodile.org>

On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote:
> 
> Vadim Tkachenko wrote:
> > Hello again,
> > 
> > And while I'm at it, why don't just say this: give me one good reason to
> > write 3+ different ways of handling removable devices, one for USB, one for
> > FireWire, one for serial...
> 
> You don't, they're all the same "I have lost communication with my 
> serial device".

"I have lost communication with my ${protocol} device".

> The only thing you could really do is improve error reporting by knowing 
> the exact sub-system.  ("Device X which is/was attached to USB port Y is 
> no longer functioning, please check the USB ports, the device, the 
> cables and anything else you can think of that may be a cause of 
> failure.")

"Device ${id} which is/was attached to ${protocol} port ${port} is no longer
functioning, please check the ${protocol} ports, the device, the
${protocol_media} and anything else you can think of that may be a cause of
failure".

>  That just requires an intelligent description of the port.

Agree absolutely.

> > I understand very well that this goes way beyond the scope of RxTx and
> > CommAPI and will require cooperation between them and javax.usb and whatever
> > JSR is responsible for FireWire implementation - but the end result is well
> > worth it. Abstract out and generalize arrival/departure/monitoring/discovery
> > API, provide protocol specific extensions for each, live happily ever after.
> 
> There's a huge list of pseudo-serial devices each with a different set 
> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, 
> etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I 
> have no clue how you'd implement them in a general/cross platform sense.

That's because some of the protocols were created decades ago when
autoconfiguration wasn't even conceived, much less practical. RS232/RS485
don't have a clue about identity discovery, and even capabilities discovery
beyond obvious 8N1 etc.

I agree that today all these protocols have generally incompatible
strategies for handling the situations I'm trying to address, but there's
nothing that says it's not an oversight. Besides, we're dealing with the
devices at a level of abstraction that allows some simplifications and
generalizations, at least part of the time - unless it's the protocol
specific features we're dealing with.

> You haven't convinced me (and only me, others may see something that I 
> don't, I'm not speaking for them) that this mechanism can be implemented 
> in any practical sense.  That is, that the implementation could be wide 
> enough to be consider generally available in RXTX regardless of the 
> serial port implementation, platform, etc..  However, if you can come up 
> with a general design and a reference implementation for one subsystem, 
> I'd like to see it and might get on board.

Actually, I wasn't even thinking about all this stuff when I wrote the first
message on the subject :) Now that you mention it - well, I'm not sure I can
chew the piece I just tried to bite in reasonable amount of time.

How do you eat an elephant? One bite at a time. If we could agree that a
small step in the specification is acceptable at this time, and express
further intentions, things may start happening.

To put it succinctly:

- Concept of a "port" should be augmented with a concept of a "device". A
device may be attached to a port in an implicit or explicit way.
- Implicitly connected device is exactly what the current scope of the
specification covers. No new functionality is offered.
- Explicitly connected device supports detachable device semantics, just as
other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a
few).
- The input and output streams are not properties of a port now, but
properties of the device attached to the port.
- A mechanism to allow listening for device arrivals and departures must be
made available.

That's it, off the top of my head.

I understand that this goes completely against current javax.comm specs, but
an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be
difficult to implement without disrupting javax.comm compatibility.

One concern is how to deal with the device identity - but there's no general
way of dealing with this at this time, devices may or may not offer identity
discovery.

> Jim

--vt


From joachim at buechse.de  Fri Jun 23 02:12:43 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 23 Jun 2006 10:12:43 +0200
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
Message-ID: <CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>

Hello++ Vadim,

I would like to repeat that your request is best addressed to the  
POSSIX standardization group - or maybe the BSD/Linux maintainers. If  
you convince the BSD or Linux guys to add this kind of functionality  
(they can as most of there VCP drivers are open source), there is a  
certain chance that other vendors will pick it up. I assure you that  
RXTX will happily provide this functionality once it's possible - I'm  
sure there is more than one maintainer that would love to add it.  
Having this concept penetrate the market may take some years though.

SHORT: The solution you would like to see could be added to the API  
but it can not be implemented (at least not on the platforms I know).  
There are currently no hooks in the kernel that allow you to discover  
"the device" or even the "means of connection" based on an existing  
"device file descriptor" ie COM-port or /dev/... entry. The name  
mapping of the device is handled by the virtual com port driver of  
the device. Unless you are suggesting RXTX should reimplement virtual  
com port drivers for all usb/serial bridges out there your request is  
understandable from a users viewpoint but simply not realizable. It's  
like asking that the Socket api should identify the computer behind  
an IP address (ie by its Ethernet address). While this COULD be  
implemented in TCP/IP, it IS not, and hence there is no point adding  
such a function to the Socket API.

The current trend for USB/Bluetooth/Irda/etc connected devices is  
going away from serial port abstraction towards RPC (ie the drivers  
provide a device specific or device class specific driver that  
provides an application level api to the device functions). The line  
level protocol is often not even published.

Best regards,
Joachim

On 22.06.2006, at 23:40, Vadim Tkachenko wrote:

> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote:
>>
>> Vadim Tkachenko wrote:
>>> Hello again,
>>>
>>> And while I'm at it, why don't just say this: give me one good  
>>> reason to
>>> write 3+ different ways of handling removable devices, one for  
>>> USB, one for
>>> FireWire, one for serial...
>>
>> You don't, they're all the same "I have lost communication with my
>> serial device".
>
> "I have lost communication with my ${protocol} device".
>
>> The only thing you could really do is improve error reporting by  
>> knowing
>> the exact sub-system.  ("Device X which is/was attached to USB  
>> port Y is
>> no longer functioning, please check the USB ports, the device, the
>> cables and anything else you can think of that may be a cause of
>> failure.")
>
> "Device ${id} which is/was attached to ${protocol} port ${port} is  
> no longer
> functioning, please check the ${protocol} ports, the device, the
> ${protocol_media} and anything else you can think of that may be a  
> cause of
> failure".
>
>>  That just requires an intelligent description of the port.
>
> Agree absolutely.
>
>>> I understand very well that this goes way beyond the scope of  
>>> RxTx and
>>> CommAPI and will require cooperation between them and javax.usb  
>>> and whatever
>>> JSR is responsible for FireWire implementation - but the end  
>>> result is well
>>> worth it. Abstract out and generalize arrival/departure/ 
>>> monitoring/discovery
>>> API, provide protocol specific extensions for each, live happily  
>>> ever after.
>>
>> There's a huge list of pseudo-serial devices each with a different  
>> set
>> of requirements, Bluetooth, RFC 2217, a host of proprietary systems,
>> etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I
>> have no clue how you'd implement them in a general/cross platform  
>> sense.
>
> That's because some of the protocols were created decades ago when
> autoconfiguration wasn't even conceived, much less practical. RS232/ 
> RS485
> don't have a clue about identity discovery, and even capabilities  
> discovery
> beyond obvious 8N1 etc.
>
> I agree that today all these protocols have generally incompatible
> strategies for handling the situations I'm trying to address, but  
> there's
> nothing that says it's not an oversight. Besides, we're dealing  
> with the
> devices at a level of abstraction that allows some simplifications and
> generalizations, at least part of the time - unless it's the protocol
> specific features we're dealing with.
>
>> You haven't convinced me (and only me, others may see something  
>> that I
>> don't, I'm not speaking for them) that this mechanism can be  
>> implemented
>> in any practical sense.  That is, that the implementation could be  
>> wide
>> enough to be consider generally available in RXTX regardless of the
>> serial port implementation, platform, etc..  However, if you can  
>> come up
>> with a general design and a reference implementation for one  
>> subsystem,
>> I'd like to see it and might get on board.
>
> Actually, I wasn't even thinking about all this stuff when I wrote  
> the first
> message on the subject :) Now that you mention it - well, I'm not  
> sure I can
> chew the piece I just tried to bite in reasonable amount of time.
>
> How do you eat an elephant? One bite at a time. If we could agree  
> that a
> small step in the specification is acceptable at this time, and  
> express
> further intentions, things may start happening.
>
> To put it succinctly:
>
> - Concept of a "port" should be augmented with a concept of a  
> "device". A
> device may be attached to a port in an implicit or explicit way.
> - Implicitly connected device is exactly what the current scope of the
> specification covers. No new functionality is offered.
> - Explicitly connected device supports detachable device semantics,  
> just as
> other protocols do (USB, FireWire, Wireless USB, Bluetooth, to  
> mention a
> few).
> - The input and output streams are not properties of a port now, but
> properties of the device attached to the port.
> - A mechanism to allow listening for device arrivals and departures  
> must be
> made available.
>
> That's it, off the top of my head.
>
> I understand that this goes completely against current javax.comm  
> specs, but
> an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern )  
> won't be
> difficult to implement without disrupting javax.comm compatibility.
>
> One concern is how to deal with the device identity - but there's  
> no general
> way of dealing with this at this time, devices may or may not offer  
> identity
> discovery.
>
>> Jim
>
> --vt
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From vt at freehold.crocodile.org  Fri Jun 23 11:28:29 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Fri, 23 Jun 2006 10:28:29 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
	<CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
Message-ID: <20060623172829.GA5335@freehold.crocodile.org>

Hello Joachim,

> I would like to repeat that your request is best addressed to the POSSIX
> standardization group - or maybe the BSD/Linux maintainers. If you
> convince the BSD or Linux guys to add this kind of functionality (they can
> as most of there VCP drivers are open source), there is a certain chance
> that other vendors will pick it up. I assure you that RXTX will happily
> provide this functionality once it's possible - I'm sure there is more
> than one maintainer that would love to add it.

I realize this thing is bigger than RxTx itself, and I'm afraid it's too
global not to cause people to laugh before they think about it :)

> Having this concept penetrate the market may take some years though.

Well, I'm sure it'll get there, the only question is - when.

> SHORT: The solution you would like to see could be added to the API but it
> can not be implemented (at least not on the platforms I know).

I guess I'm concerned about the abstraction more than I'm concerned about
the implementation at this point.
  
> There are currently no hooks in the kernel that allow you to discover  
> "the device" or even the "means of connection" based on an existing  
> "device file descriptor" ie COM-port or /dev/... entry.

Well, I'm not so sure you need to keep the literal mapping from /dev
namespace to your device namespace. As long as you can consistently offer a
virtual serial device on top of a virtual serial port, it may be irrelevant
whether you can map it into /dev. The mapping is going be schitzofrenic
anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the
representation...

> The name mapping of the device is handled by the virtual com port driver
> of the device. Unless you are suggesting RXTX should reimplement virtual
> com port drivers for all usb/serial bridges out there your request is
> understandable from a users viewpoint but simply not realizable.

It's not so much a request but rather an offer of participation. I run a few
projects actively using serial communications, as well as USB device
drivers, in different degrees of readiness (Servomaster, Haywire, DIY
Zoning) - and it would be a perfect playground.

You mentioned above that this task is about two things: a) abstraction b)
implementation. I could start the abstraction part of it without changing
the current CommAPI, on top of it, as an adapter. Even if the removable
device semantics are not implemented, but offered, this is already a step
forward.

> It's like asking that the Socket api should identify the computer behind
> an IP address (ie by its Ethernet address). While this COULD be
> implemented in TCP/IP, it IS not, and hence there is no point adding such
> a function to the Socket API.

Thank you for bringing up this example - I guess this is just about the same
thing that I'd like to see. Socket transparently provides you with the
input/output streams, at the same time offering protocol level specifics to
you.

> The current trend for USB/Bluetooth/Irda/etc connected devices is going
> away from serial port abstraction towards RPC (ie the drivers provide a
> device specific or device class specific driver that provides an
> application level api to the device functions). The line level protocol is
> often not even published.

I can't say I'm that happy with it. The best (or, rather, worst) example is
suchlike support for the Phidget servo controller - zealous Linux developers
implemented kernel module support for it, completely hijacking a possibility
of using it on a different level (it's somewhat fixed by now, thankfully).

I believe that whenever an abstraction is offered, it must be made optional
and/or pluggable so it can be replaced by something more suited to the task.

The nature of Java applications is such that they'd probably care much more
about Java API offered, than about no matter how rich application level api
that is offered outside of Java. I've dealt with JNI adapters in the past,
and whereas they can be made reasonably stable, the very fact that you are
forced to deal with things that are not on the critical timing/memory path
and could've been done much easier in Java causes endless grief.

> Joachim

--vt


From lyon at docjava.com  Sat Jun 24 04:54:12 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Sat, 24 Jun 2006 06:54:12 -0400
Subject: [Rxtx] jsr
In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
	<CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
	<20060623172829.GA5335@freehold.crocodile.org>
Message-ID: <p060204a3c0c2c9dde4f8@[192.168.1.152]>

Hi All,
I have had some off-list discussion with Trent.
Opening up a JSR with Sun, as per Peters' suggestion
seems like a reasonable idea, to us.

Does anyone having any concerns about the JSR process
that they would like to raise?

Thanks!
  - Doug



From the.grey.lantern at gmail.com  Sat Jun 24 18:15:26 2006
From: the.grey.lantern at gmail.com (Craig Nicoll)
Date: Sun, 25 Jun 2006 01:15:26 +0100
Subject: [Rxtx] Cannot create virtual serial port
Message-ID: <a1221cc50606241715g2d1e2af6r747347dd4c20e997@mail.gmail.com>

Hello,

This is my first post on this mailing list and I hope someone can help me.

I am having great difficult establishing a virtual serial port for the
Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia
7600.

Every time I try to run the SendMessage program that comes with SMSLib, I
get the following exception: gnu.io.NoSuchPortException

The port names I have tried are:
rfcomm0
rfcomm
/dev/rfcomm0
/dev/rfcomm

This is what I have done so far:
Modified /etc/bluetooth/rfcomm.conf to include the address of my phone:

rfcomm0 {
# Automatically bind the device at startup
bind no;

# Bluetooth address of the device
device 00:0e:6d:7a:98:43;

# RFCOMM channel for the connection
channel 1;

# Description of the connection
comment "Example Bluetooth device";
}

I also tried running the following command: rfcomm bind /dev/rfcomm0

I have searched the mailing list archives and found this post where someone
had a very similar problem to me:
http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried
changing the system properties as suggested and it made no difference.

I have also been scouring Google all day to no avail.

I would be incredibly grateful if anyone could give me some tips.

Thank you,

Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0007.html

From tjarvi at qbang.org  Sun Jun 25 19:56:08 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT)
Subject: [Rxtx] Pending release
Message-ID: <Pine.LNX.4.61.0606251942460.15744@www>


With frustration, I was unable to get to the pending release this weekend.
The release should be comming this next week once things calm down.
The source is in CVS except for a fix for multiple ports in windows.

I had planned on doing the release this weekend but that was disrupted by 
my transportation failing in a spectacular fashion.

--
Trent Jarvi
tjarvi at qbang.org


From Pawan.Kharbanda at dot.state.co.us  Tue Jun 27 22:28:51 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 27 Jun 2006 22:28:51 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>

 Trent, 
   I have an application running in a cluster in linux environment and I
am using RXTX2.1.7 (final) with JDK1.5. The application opens and closes
serial comm ports every 30 seconds and exchanges datas. I have
experienced some of my Comm Ports are left hanging (I can see the
LCK..cufXX lock files under /var/lock folder). On putting the debugs I
found out that, it is stuck at a native call line 809 in RXTXPort.java
class (Please see the code snippet below). Can you help me explain what
this method does in the native code? Am I getting into some thread
deadlocks? Thanks in advance.

Pawan Kharbanda 


public void removeEventListener()
	{
		if (debug)
			z.reportln( "RXTXPort:removeEventListener()
called");
		waitForTheNativeCodeSilly();
		//if( monThread != null && monThread.isAlive() )
		if( monThreadisInterrupted == true )
		{
			z.reportln( "	RXTXPort:removeEventListener()
already interrupted");
			monThread = null;
			SPEventListener = null;
			return;
		}
		else if( monThread != null && monThread.isAlive() )
		{
			if (debug)
				z.reportln( "
RXTXPort:Interrupt=true");
			monThreadisInterrupted=true;
			/*
			   Notify all threads in this PID that something
is up
			   They will call back to see if its their
thread
			   using isInterrupted().
			*/
			if (debug)
				z.reportln( "	RXTXPort:calling
interruptEventLoop");
// LINE 809			interruptEventLoop( ); It never returns
out of this 
			
			if (debug)
				z.reportln( "	RXTXPort:calling
monThread.join()");
			try {
				monThread.join(1000);
			} catch (Exception ex) {
				/* yikes */
				ex.printStackTrace();
			}
			if (debug)
				z.reportln( "	RXTXPort:waiting on
isAlive()");
			while( monThread.isAlive() )
			{
				if ( debug )
					z.reportln( "	MonThread is
still alive!");
				try {
					monThread.join(1000);
					Thread.sleep( 1000 );
				} catch( Exception e ){} 
				//monThread.stop();
			}
			
		}
		if (debug)
			z.reportln( "	RXTXPort:calling gc()");
		monThread = null;
		SPEventListener = null;
		MonitorThreadLock = false;
		MonitorThreadAlive=false;
		monThreadisInterrupted=true;
		z.reportln( "RXTXPort:removeEventListener() returning");
	} 

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Sunday, June 25, 2006 7:56 PM
To: rxtx at qbang.org
Subject: [Rxtx] Pending release


With frustration, I was unable to get to the pending release this
weekend.
The release should be comming this next week once things calm down.
The source is in CVS except for a fix for multiple ports in windows.

I had planned on doing the release this weekend but that was disrupted
by my transportation failing in a spectacular fashion.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Wed Jun 28 04:17:29 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 28 Jun 2006 04:17:29 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606280406330.9561@www>



Hi Pawan

You may have found a deadlock but I've not seen on recently on linux.

If you can, please update from CVS.  This will have some close fixes. 
I'm running with the same code as is in CVS.  It is not perfect but I've 
not seen anything like you mention.  Be sure to set timeouts and 
thresholds on the port.  It may be that the port is waiting on pending io 
that never happens.  I think the CVS patches deal with this also but it 
looks like your in a better test environment to know for sure.

The exploded vehicle mentioned below is expected to be fixed today.  It 
was just a ninja small radiator hose.  The pressure test afterwards 
created its own set of problems.  Until this is resolved, I'm spending 
most of my free time commuting by bicycle.

On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>   I have an application running in a cluster in linux environment and I
> am using RXTX2.1.7 (final) with JDK1.5. The application opens and closes
> serial comm ports every 30 seconds and exchanges datas. I have
> experienced some of my Comm Ports are left hanging (I can see the
> LCK..cufXX lock files under /var/lock folder). On putting the debugs I
> found out that, it is stuck at a native call line 809 in RXTXPort.java
> class (Please see the code snippet below). Can you help me explain what
> this method does in the native code? Am I getting into some thread
> deadlocks? Thanks in advance.
>
> Pawan Kharbanda
>
>
> public void removeEventListener()
> 	{
> 		if (debug)
> 			z.reportln( "RXTXPort:removeEventListener()
> called");
> 		waitForTheNativeCodeSilly();
> 		//if( monThread != null && monThread.isAlive() )
> 		if( monThreadisInterrupted == true )
> 		{
> 			z.reportln( "	RXTXPort:removeEventListener()
> already interrupted");
> 			monThread = null;
> 			SPEventListener = null;
> 			return;
> 		}
> 		else if( monThread != null && monThread.isAlive() )
> 		{
> 			if (debug)
> 				z.reportln( "
> RXTXPort:Interrupt=true");
> 			monThreadisInterrupted=true;
> 			/*
> 			   Notify all threads in this PID that something
> is up
> 			   They will call back to see if its their
> thread
> 			   using isInterrupted().
> 			*/
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> interruptEventLoop");
> // LINE 809			interruptEventLoop( ); It never returns
> out of this
>
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> monThread.join()");
> 			try {
> 				monThread.join(1000);
> 			} catch (Exception ex) {
> 				/* yikes */
> 				ex.printStackTrace();
> 			}
> 			if (debug)
> 				z.reportln( "	RXTXPort:waiting on
> isAlive()");
> 			while( monThread.isAlive() )
> 			{
> 				if ( debug )
> 					z.reportln( "	MonThread is
> still alive!");
> 				try {
> 					monThread.join(1000);
> 					Thread.sleep( 1000 );
> 				} catch( Exception e ){}
> 				//monThread.stop();
> 			}
>
> 		}
> 		if (debug)
> 			z.reportln( "	RXTXPort:calling gc()");
> 		monThread = null;
> 		SPEventListener = null;
> 		MonitorThreadLock = false;
> 		MonitorThreadAlive=false;
> 		monThreadisInterrupted=true;
> 		z.reportln( "RXTXPort:removeEventListener() returning");
> 	}
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Sunday, June 25, 2006 7:56 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] Pending release
>
>
> With frustration, I was unable to get to the pending release this
> weekend.
> The release should be comming this next week once things calm down.
> The source is in CVS except for a fix for multiple ports in windows.
>
> I had planned on doing the release this weekend but that was disrupted
> by my transportation failing in a spectacular fashion.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From Pawan.Kharbanda at dot.state.co.us  Wed Jun 28 12:11:06 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Wed, 28 Jun 2006 12:11:06 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>

Trent,
    Again thanks for the reply. First of all I have Receive timeouts set
on all communications including Max no of bytes to expect during the
call. I have noticed the problem is during "closing the connection". I
am not sure if the RXTX is 100% thread-safe yet. There seems to be a
glitch in the native calls. I am sure I have the latest code I did the
update on the Version 2.1.7 from CVS, is this where the latest updates
are located, I have noticed another version in CVS "rxtx-devel".

Regards
Pawan Kharbanda

    

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Wednesday, June 28, 2006 4:17 AM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports



Hi Pawan

You may have found a deadlock but I've not seen on recently on linux.

If you can, please update from CVS.  This will have some close fixes. 
I'm running with the same code as is in CVS.  It is not perfect but I've
not seen anything like you mention.  Be sure to set timeouts and
thresholds on the port.  It may be that the port is waiting on pending
io that never happens.  I think the CVS patches deal with this also but
it looks like your in a better test environment to know for sure.

The exploded vehicle mentioned below is expected to be fixed today.  It
was just a ninja small radiator hose.  The pressure test afterwards
created its own set of problems.  Until this is resolved, I'm spending
most of my free time commuting by bicycle.

On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>   I have an application running in a cluster in linux environment and 
> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and 
> closes serial comm ports every 30 seconds and exchanges datas. I have 
> experienced some of my Comm Ports are left hanging (I can see the 
> LCK..cufXX lock files under /var/lock folder). On putting the debugs I

> found out that, it is stuck at a native call line 809 in RXTXPort.java

> class (Please see the code snippet below). Can you help me explain 
> what this method does in the native code? Am I getting into some 
> thread deadlocks? Thanks in advance.
>
> Pawan Kharbanda
>
>
> public void removeEventListener()
> 	{
> 		if (debug)
> 			z.reportln( "RXTXPort:removeEventListener()
called");
> 		waitForTheNativeCodeSilly();
> 		//if( monThread != null && monThread.isAlive() )
> 		if( monThreadisInterrupted == true )
> 		{
> 			z.reportln( "	RXTXPort:removeEventListener()
> already interrupted");
> 			monThread = null;
> 			SPEventListener = null;
> 			return;
> 		}
> 		else if( monThread != null && monThread.isAlive() )
> 		{
> 			if (debug)
> 				z.reportln( "
> RXTXPort:Interrupt=true");
> 			monThreadisInterrupted=true;
> 			/*
> 			   Notify all threads in this PID that something
is up
> 			   They will call back to see if its their
thread
> 			   using isInterrupted().
> 			*/
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> interruptEventLoop");
> // LINE 809			interruptEventLoop( ); It never returns
> out of this
>
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> monThread.join()");
> 			try {
> 				monThread.join(1000);
> 			} catch (Exception ex) {
> 				/* yikes */
> 				ex.printStackTrace();
> 			}
> 			if (debug)
> 				z.reportln( "	RXTXPort:waiting on
> isAlive()");
> 			while( monThread.isAlive() )
> 			{
> 				if ( debug )
> 					z.reportln( "	MonThread is
> still alive!");
> 				try {
> 					monThread.join(1000);
> 					Thread.sleep( 1000 );
> 				} catch( Exception e ){}
> 				//monThread.stop();
> 			}
>
> 		}
> 		if (debug)
> 			z.reportln( "	RXTXPort:calling gc()");
> 		monThread = null;
> 		SPEventListener = null;
> 		MonitorThreadLock = false;
> 		MonitorThreadAlive=false;
> 		monThreadisInterrupted=true;
> 		z.reportln( "RXTXPort:removeEventListener() returning");
> 	}
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf

> Of Trent Jarvi
> Sent: Sunday, June 25, 2006 7:56 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] Pending release
>
>
> With frustration, I was unable to get to the pending release this 
> weekend.
> The release should be comming this next week once things calm down.
> The source is in CVS except for a fix for multiple ports in windows.
>
> I had planned on doing the release this weekend but that was disrupted

> by my transportation failing in a spectacular fashion.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Wed Jun 28 12:26:21 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 28 Jun 2006 12:26:21 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606281222420.9561@www>


Hi Pawan

If you did a cvs update from the 2.1-7 tar ball, you have the current 
version.  All rxtx in CVS is under rxtx-devel.  The 2.1-7 just has -r
commapi-0-0-1.

You may well have found something.  I have seen win32 fail on closing 
ports but not linux that I can think of.  Your use is much different than 
I normally see too.

Could you give us more information on how we would reproduce this and the 
frequency?


On Wed, 28 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>    Again thanks for the reply. First of all I have Receive timeouts set
> on all communications including Max no of bytes to expect during the
> call. I have noticed the problem is during "closing the connection". I
> am not sure if the RXTX is 100% thread-safe yet. There seems to be a
> glitch in the native calls. I am sure I have the latest code I did the
> update on the Version 2.1.7 from CVS, is this where the latest updates
> are located, I have noticed another version in CVS "rxtx-devel".
>
> Regards
> Pawan Kharbanda
>
>
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Wednesday, June 28, 2006 4:17 AM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] Locked Ports
>
>
>
> Hi Pawan
>
> You may have found a deadlock but I've not seen on recently on linux.
>
> If you can, please update from CVS.  This will have some close fixes.
> I'm running with the same code as is in CVS.  It is not perfect but I've
> not seen anything like you mention.  Be sure to set timeouts and
> thresholds on the port.  It may be that the port is waiting on pending
> io that never happens.  I think the CVS patches deal with this also but
> it looks like your in a better test environment to know for sure.
>
> The exploded vehicle mentioned below is expected to be fixed today.  It
> was just a ninja small radiator hose.  The pressure test afterwards
> created its own set of problems.  Until this is resolved, I'm spending
> most of my free time commuting by bicycle.
>
> On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:
>
>> Trent,
>>   I have an application running in a cluster in linux environment and
>> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and
>> closes serial comm ports every 30 seconds and exchanges datas. I have
>> experienced some of my Comm Ports are left hanging (I can see the
>> LCK..cufXX lock files under /var/lock folder). On putting the debugs I
>
>> found out that, it is stuck at a native call line 809 in RXTXPort.java
>
>> class (Please see the code snippet below). Can you help me explain
>> what this method does in the native code? Am I getting into some
>> thread deadlocks? Thanks in advance.
>>
>> Pawan Kharbanda
>>
>>
>> public void removeEventListener()
>> 	{
>> 		if (debug)
>> 			z.reportln( "RXTXPort:removeEventListener()
> called");
>> 		waitForTheNativeCodeSilly();
>> 		//if( monThread != null && monThread.isAlive() )
>> 		if( monThreadisInterrupted == true )
>> 		{
>> 			z.reportln( "	RXTXPort:removeEventListener()
>> already interrupted");
>> 			monThread = null;
>> 			SPEventListener = null;
>> 			return;
>> 		}
>> 		else if( monThread != null && monThread.isAlive() )
>> 		{
>> 			if (debug)
>> 				z.reportln( "
>> RXTXPort:Interrupt=true");
>> 			monThreadisInterrupted=true;
>> 			/*
>> 			   Notify all threads in this PID that something
> is up
>> 			   They will call back to see if its their
> thread
>> 			   using isInterrupted().
>> 			*/
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> interruptEventLoop");
>> // LINE 809			interruptEventLoop( ); It never returns
>> out of this
>>
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> monThread.join()");
>> 			try {
>> 				monThread.join(1000);
>> 			} catch (Exception ex) {
>> 				/* yikes */
>> 				ex.printStackTrace();
>> 			}
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:waiting on
>> isAlive()");
>> 			while( monThread.isAlive() )
>> 			{
>> 				if ( debug )
>> 					z.reportln( "	MonThread is
>> still alive!");
>> 				try {
>> 					monThread.join(1000);
>> 					Thread.sleep( 1000 );
>> 				} catch( Exception e ){}
>> 				//monThread.stop();
>> 			}
>>
>> 		}
>> 		if (debug)
>> 			z.reportln( "	RXTXPort:calling gc()");
>> 		monThread = null;
>> 		SPEventListener = null;
>> 		MonitorThreadLock = false;
>> 		MonitorThreadAlive=false;
>> 		monThreadisInterrupted=true;
>> 		z.reportln( "RXTXPort:removeEventListener() returning");
>> 	}
>>
>> -----Original Message-----
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
>
>> Of Trent Jarvi
>> Sent: Sunday, June 25, 2006 7:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] Pending release
>>
>>
>> With frustration, I was unable to get to the pending release this
>> weekend.
>> The release should be comming this next week once things calm down.
>> The source is in CVS except for a fix for multiple ports in windows.
>>
>> I had planned on doing the release this weekend but that was disrupted
>
>> by my transportation failing in a spectacular fashion.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From Pawan.Kharbanda at dot.state.co.us  Wed Jun 28 15:42:49 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Wed, 28 Jun 2006 15:42:49 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>

Trent,
    I will try to explain how I am setup and will try to write you a
Sample code little later to reproduce this. On our system we have
DigiBoxes installed on the 2 Linux servers. Both of them have RXTX2.1-7
version installed with the JRE(1.5) and both the machines have the same
port mappings in gnu.io.rxtx.properties (Currently in the production
system I have 64 ports). This is how the system works:

1) A thick Map based client initiates a Action on the Device on the
field. One of the Thread Workers(Asynchronous Call) in the Cluster picks
up the request. 
2) Once the worker gets the request it locks the Device and
Communication port in the DB's(These are our persistent locks, because
most of the devices do one to one communication with the serial ports).
After that the worker (or Comm Server) opens up the connection and after
exchanging the information calls the "Close" and returns.
3) Once the connection is closed , the DB lock is removed on the comm
port and is made available to accept future calls. Here is where the
glitch is the Serial Comm Close method never returns due to the
deadlock. 

I have noticed that the deadlocks are very inconsistent, sometime it
happens right away as soon as Application server starts and sometimes I
don't see any deadlocks for days, but it happens for sure. 

Here is how you can test if you have resources/ test environment. Write
a program and try to open/close  different ports(I will say have a
minimum of four) randomly and very frequently(may be 30 seconds), I am
pretty sure you will see the deadlocks and it happens in the native call
to interrptEventLoop in RXTXPort.java in removeEventListener() method
call.

Also I have noticed that the JVM carshes (without any memrory errors or
JVM errors. Its just not there) when native call is made to eventLoop()
in run() method in MonitorThread inner class. I am still investigating
why this is happening, but at this point I can just tell you the
location. You might have a question How I am so sure about the location?
My application is configured with Log4J and I have enabled the debugs on
the RXTXPort.java, so every time my JVM dies I see these logs at the end
of the file.

"2006-06-28 15:27:15,183 INFO  [STDOUT] RXTXPort:RXTXPort(/dev/cub01)
called
2006-06-28 15:27:15,218 INFO  [STDOUT]
RXTXPort:MontitorThread:MonitorThread()
2006-06-28 15:27:15,219 INFO  [STDOUT] RXTXPort:MontitorThread:run()"

I surely do have a luxury of a testing environment(ports, devices etc.)
and can help you fix these problems? Please advise me how we can resolve
these issues.

Thanks 
Pawan Kharbanda
303-478-2991





-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Wednesday, June 28, 2006 12:26 PM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports


Hi Pawan

If you did a cvs update from the 2.1-7 tar ball, you have the current
version.  All rxtx in CVS is under rxtx-devel.  The 2.1-7 just has -r
commapi-0-0-1.

You may well have found something.  I have seen win32 fail on closing
ports but not linux that I can think of.  Your use is much different
than I normally see too.

Could you give us more information on how we would reproduce this and
the frequency?


On Wed, 28 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>    Again thanks for the reply. First of all I have Receive timeouts
set
> on all communications including Max no of bytes to expect during the
> call. I have noticed the problem is during "closing the connection". I
> am not sure if the RXTX is 100% thread-safe yet. There seems to be a
> glitch in the native calls. I am sure I have the latest code I did the
> update on the Version 2.1.7 from CVS, is this where the latest updates
> are located, I have noticed another version in CVS "rxtx-devel".
>
> Regards
> Pawan Kharbanda
>
>
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Wednesday, June 28, 2006 4:17 AM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] Locked Ports
>
>
>
> Hi Pawan
>
> You may have found a deadlock but I've not seen on recently on linux.
>
> If you can, please update from CVS.  This will have some close fixes.
> I'm running with the same code as is in CVS.  It is not perfect but
I've
> not seen anything like you mention.  Be sure to set timeouts and
> thresholds on the port.  It may be that the port is waiting on pending
> io that never happens.  I think the CVS patches deal with this also
but
> it looks like your in a better test environment to know for sure.
>
> The exploded vehicle mentioned below is expected to be fixed today.
It
> was just a ninja small radiator hose.  The pressure test afterwards
> created its own set of problems.  Until this is resolved, I'm spending
> most of my free time commuting by bicycle.
>
> On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:
>
>> Trent,
>>   I have an application running in a cluster in linux environment and
>> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and
>> closes serial comm ports every 30 seconds and exchanges datas. I have
>> experienced some of my Comm Ports are left hanging (I can see the
>> LCK..cufXX lock files under /var/lock folder). On putting the debugs
I
>
>> found out that, it is stuck at a native call line 809 in
RXTXPort.java
>
>> class (Please see the code snippet below). Can you help me explain
>> what this method does in the native code? Am I getting into some
>> thread deadlocks? Thanks in advance.
>>
>> Pawan Kharbanda
>>
>>
>> public void removeEventListener()
>> 	{
>> 		if (debug)
>> 			z.reportln( "RXTXPort:removeEventListener()
> called");
>> 		waitForTheNativeCodeSilly();
>> 		//if( monThread != null && monThread.isAlive() )
>> 		if( monThreadisInterrupted == true )
>> 		{
>> 			z.reportln( "	RXTXPort:removeEventListener()
>> already interrupted");
>> 			monThread = null;
>> 			SPEventListener = null;
>> 			return;
>> 		}
>> 		else if( monThread != null && monThread.isAlive() )
>> 		{
>> 			if (debug)
>> 				z.reportln( "
>> RXTXPort:Interrupt=true");
>> 			monThreadisInterrupted=true;
>> 			/*
>> 			   Notify all threads in this PID that something
> is up
>> 			   They will call back to see if its their
> thread
>> 			   using isInterrupted().
>> 			*/
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> interruptEventLoop");
>> // LINE 809			interruptEventLoop( ); It never returns
>> out of this
>>
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> monThread.join()");
>> 			try {
>> 				monThread.join(1000);
>> 			} catch (Exception ex) {
>> 				/* yikes */
>> 				ex.printStackTrace();
>> 			}
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:waiting on
>> isAlive()");
>> 			while( monThread.isAlive() )
>> 			{
>> 				if ( debug )
>> 					z.reportln( "	MonThread is
>> still alive!");
>> 				try {
>> 					monThread.join(1000);
>> 					Thread.sleep( 1000 );
>> 				} catch( Exception e ){}
>> 				//monThread.stop();
>> 			}
>>
>> 		}
>> 		if (debug)
>> 			z.reportln( "	RXTXPort:calling gc()");
>> 		monThread = null;
>> 		SPEventListener = null;
>> 		MonitorThreadLock = false;
>> 		MonitorThreadAlive=false;
>> 		monThreadisInterrupted=true;
>> 		z.reportln( "RXTXPort:removeEventListener() returning");
>> 	}
>>
>> -----Original Message-----
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On
Behalf
>
>> Of Trent Jarvi
>> Sent: Sunday, June 25, 2006 7:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] Pending release
>>
>>
>> With frustration, I was unable to get to the pending release this
>> weekend.
>> The release should be comming this next week once things calm down.
>> The source is in CVS except for a fix for multiple ports in windows.
>>
>> I had planned on doing the release this weekend but that was
disrupted
>
>> by my transportation failing in a spectacular fashion.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx 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 khattar31 at yahoo.com  Wed Jun 28 22:04:59 2006
From: khattar31 at yahoo.com (rahul khattar)
Date: Wed, 28 Jun 2006 21:04:59 -0700 (PDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
Message-ID: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>

Hi All,

I was looking at the src file on the last release.
I did notice a missing header file while trying to
compile the parallelport.dll. Would somebody be kind
enoughf to share the missing header file:
gnu_io_LPRPort.h

I am using MinGw to compile the same from Parinya
(which is an execellent tool)


Regards,
Rahul Khattar

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Thu Jun 29 03:43:53 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 03:43:53 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>
References: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606290341210.9561@www>

On Wed, 28 Jun 2006, rahul khattar wrote:

> Hi All,
>
> I was looking at the src file on the last release.
> I did notice a missing header file while trying to
> compile the parallelport.dll. Would somebody be kind
> enoughf to share the missing header file:
> gnu_io_LPRPort.h
>
> I am using MinGw to compile the same from Parinya
> (which is an execellent tool)
>

Hi Rahul

The gnu.io_LPRPort.h file is generated with javah.  You can see the 
command in the Makefile I presume.  You do not need rxtxParallel.dll to 
use w32 serial btw.

--
Trent Jarvi
tjarvi at qbang.org


From khattar31 at yahoo.com  Thu Jun 29 04:47:01 2006
From: khattar31 at yahoo.com (rahul khattar)
Date: Thu, 29 Jun 2006 03:47:01 -0700 (PDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606290341210.9561@www>
Message-ID: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>

Hi Trent 
I did notice this file is required in the source file
ParallelImp.c
on line 38

Attached the O/P 

Regards,
Rahul Khattar




--- Trent Jarvi <tjarvi at qbang.org> wrote:

> On Wed, 28 Jun 2006, rahul khattar wrote:
> 
> > Hi All,
> >
> > I was looking at the src file on the last release.
> > I did notice a missing header file while trying to
> > compile the parallelport.dll. Would somebody be
> kind
> > enoughf to share the missing header file:
> > gnu_io_LPRPort.h
> >
> > I am using MinGw to compile the same from Parinya
> > (which is an execellent tool)
> >
> 
> Hi Rahul
> 
> The gnu.io_LPRPort.h file is generated with javah. 
> You can see the 
> command in the Makefile I presume.  You do not need
> rxtxParallel.dll to 
> use w32 serial btw.
> 
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Error.zip
Type: application/x-zip-compressed
Size: 1746 bytes
Desc: 2948039066-Error.zip
Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060629/a5b6f783/Error-0007.bin

From tjarvi at qbang.org  Thu Jun 29 06:16:24 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 06:16:24 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606290614530.9561@www>

On Thu, 29 Jun 2006, rahul khattar wrote:

> Hi Trent
> I did notice this file is required in the source file
> ParallelImp.c
> on line 38
>
> Attached the O/P
>

The command to generate the .h file will be something like:

javah -classpath . -jni gnu.io.LPRPort

The makefile should have this.  There are several approaches to creating 
or using makefiles so I have no idea which one you used if any.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Thu Jun 29 06:20:51 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 06:20:51 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606290616420.9561@www>

> Here is how you can test if you have resources/ test environment. Write
> a program and try to open/close  different ports(I will say have a
> minimum of four) randomly and very frequently(may be 30 seconds), I am
> pretty sure you will see the deadlocks and it happens in the native call
> to interrptEventLoop in RXTXPort.java in removeEventListener() method
> call.

Hi Pawan

I'll try to find a way to reproduce this.  One thing to note is that you 
are using different kernel drivers (digi) to perform this task.  So I 
probably will not be able to reproduce the exact same environment.

In general, multiport kernel drivers have been tested far less than 
typical serial drivers.  This may or may not be an issue.

--
Trent Jarvi
tjarvi at qbang.org



From jhaysonn at gmail.com  Thu Jun 29 12:29:13 2006
From: jhaysonn at gmail.com (jhaysonn pathak)
Date: Thu, 29 Jun 2006 14:29:13 -0400
Subject: [Rxtx] RXTX install
Message-ID: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>

Hi Guys,

I'm doing trying to write a generative piece of Sonic Art using an EEG
plugged into a mac runnning Max/MSP.  I just recently discovered RXTX
drivers in my search for a piece of software that might give me more
output options for my EEG (I'm using the CEO from MindPeak).  I found
Bioera which uses RXTX drivers.  Thing is - I can't figure out how to
install RXTX correctly.

After I build the 'libSerial.jnilib' target inside of
'LibSerial.pbproj' I can't find the libSerial.jnilib file that
accompanies the RXTXcomm.jar nor do I know where to put them.

I also don't understand this part at the bottom of the OS X instructions at all:

"AFTER INSTALLATION VERY IMPORTANT
	check existence of the folder /var/spool/uucp
	if you don't have it create it with command
	sudo mkdir /var/spool/uucp
	permissions should be: drwxrwxr-x
	if they are not do command
	sudo chmod 775 /var/spool/uucp

	YOU should be a member of the uucp group
	you can check it with command
		niutil -readprop / /groups/uucp users
	you should see your name in output of the niutil command
	if you don't do following:
		sudo niutil -appendprop / /groups/uucp users <yourname>
			substitute  <yourname> with your user's name
			for example if your user name is peter:
				sudo niutil -appendprop / /groups/uucp users peter

	NOTES: RXTX.pkg should create uucp folder and insert your name  in
uucp group automatically"



I really appreciate any help that you guys can offer.  I've been
struggling with this for a while now as part of a research grant that
I was awarded.  Thanks again for the help.

Jhaysonn Pathak


From naranjo.manuel at gmail.com  Thu Jun 29 07:19:15 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 10:19:15 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606290614530.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www>
Message-ID: <44A3D353.6010605@gmail.com>

Speaking about Windows Support, I had seen that inside the 
rxtx-2.1-7-bins-r2 package inside Windows directory it says:
"i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will 
not make harm to anyone, and i'm almost sure that someone has noticed it 
before.
Cheers,
Manuel


From joachim at buechse.de  Thu Jun 29 13:25:16 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 29 Jun 2006 21:25:16 +0200
Subject: [Rxtx] RXTX install
In-Reply-To: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>
References: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>
Message-ID: <2A003E42-97E1-4237-8438-646BDE2E3961@buechse.de>

Hello Jhaysonn,

I assume you are trying to use the javax.comm version of RXTX.

Please use "cvs up" to update your download to the latest version of  
the repository. The latest version does not use lock files, so the  
mentioned process is no longer needed. Updating with CVS will also  
provide you with a new README.OSX file that should be simpler to  
understand.

You will find LibSerialUniversal.xcodeproj in MACOSX_IDE/Xcode. Put  
comm.jar (downloaded from Sun) into MACOSX_IDE/Xcode. Compile the  
library. You will find RXTXcomm.jar and librxtxSerial.jnilib in  
MACOSX_IDE/Xcode/build/Default

Best regards,
Joachim
---
Joachim B?chse
Softwarel?sungen und Beratung
Hadlaubsteig 2
CH-8006 Z?rich


On 29.06.2006, at 20:29, jhaysonn pathak wrote:

> Hi Guys,
>
> I'm doing trying to write a generative piece of Sonic Art using an EEG
> plugged into a mac runnning Max/MSP.  I just recently discovered RXTX
> drivers in my search for a piece of software that might give me more
> output options for my EEG (I'm using the CEO from MindPeak).  I found
> Bioera which uses RXTX drivers.  Thing is - I can't figure out how to
> install RXTX correctly.
>
> After I build the 'libSerial.jnilib' target inside of
> 'LibSerial.pbproj' I can't find the libSerial.jnilib file that
> accompanies the RXTXcomm.jar nor do I know where to put them.
>
> I also don't understand this part at the bottom of the OS X  
> instructions at all:
>
> "AFTER INSTALLATION VERY IMPORTANT
> 	check existence of the folder /var/spool/uucp
> 	if you don't have it create it with command
> 	sudo mkdir /var/spool/uucp
> 	permissions should be: drwxrwxr-x
> 	if they are not do command
> 	sudo chmod 775 /var/spool/uucp
>
> 	YOU should be a member of the uucp group
> 	you can check it with command
> 		niutil -readprop / /groups/uucp users
> 	you should see your name in output of the niutil command
> 	if you don't do following:
> 		sudo niutil -appendprop / /groups/uucp users <yourname>
> 			substitute  <yourname> with your user's name
> 			for example if your user name is peter:
> 				sudo niutil -appendprop / /groups/uucp users peter
>
> 	NOTES: RXTX.pkg should create uucp folder and insert your name  in
> uucp group automatically"
>
>
>
> I really appreciate any help that you guys can offer.  I've been
> struggling with this for a while now as part of a research grant that
> I was awarded.  Thanks again for the help.
>
> Jhaysonn Pathak
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From tjarvi at qbang.org  Thu Jun 29 19:30:00 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 19:30:00 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A3D353.6010605@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
Message-ID: <Pine.LNX.4.61.0606291923000.9561@www>

On Thu, 29 Jun 2006, Manuel Naranjo wrote:

> Speaking about Windows Support, I had seen that inside the
> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
> not make harm to anyone, and i'm almost sure that someone has noticed it
> before.

Hi Manuel

         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
     47421  01-30-06 00:23 
rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
     77759  03-01-06 12:01 
rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README


It looks normal to me.  There are no fancy tools used there :)

--
Trent Jarvi
tjarvi at qbang.org

From naranjo.manuel at gmail.com  Thu Jun 29 19:38:16 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 22:38:16 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606291923000.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com> <Pine.LNX.4.61.0606291923000.9561@www>
Message-ID: <44A48088.2040407@gmail.com>

> On Thu, 29 Jun 2006, Manuel Naranjo wrote:
> 
>> Speaking about Windows Support, I had seen that inside the
>> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
>> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
>> not make harm to anyone, and i'm almost sure that someone has noticed it
>> before.
> 
> Hi Manuel
> 
>         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
>         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
>     47421  01-30-06 00:23 
> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
>     77759  03-01-06 12:01 
> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
>       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README
> 
> 
> It looks normal to me.  There are no fancy tools used there :)
> 
Hi Trent:
Is not the i368 representing the name of the Architecture?? If so the 
name should start with i386 it will not break any system, is simply miss
written, I saw that and wanted to report it. It a silly thing.
Ohh I forgoten I must congratulate you for your GREAT libray, I was able 
to make an .exe with JSmooth that launches an application that uses RXTX 
with out the need to install RXTX on users system :). The .exe tells JVM 
where to find the RXTX Library and Binaries. I tried with Sun's Java 
Comm but it was imposible.
Regards,
Manuel


From tjarvi at qbang.org  Thu Jun 29 19:52:45 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 19:52:45 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A48088.2040407@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
	<Pine.LNX.4.61.0606291923000.9561@www> <44A48088.2040407@gmail.com>
Message-ID: <Pine.LNX.4.61.0606291945060.9561@www>

On Thu, 29 Jun 2006, Manuel Naranjo wrote:

>> On Thu, 29 Jun 2006, Manuel Naranjo wrote:
>>
>>> Speaking about Windows Support, I had seen that inside the
>>> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
>>> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
>>> not make harm to anyone, and i'm almost sure that someone has noticed it
>>> before.
>>
>> Hi Manuel
>>
>>         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
>>         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
>>     47421  01-30-06 00:23
>> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
>>     77759  03-01-06 12:01
>> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
>>       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README
>>
>>
>> It looks normal to me.  There are no fancy tools used there :)
>>
> Hi Trent:
> Is not the i368 representing the name of the Architecture?? If so the
> name should start with i386 it will not break any system, is simply miss
> written, I saw that and wanted to report it. It a silly thing.
> Ohh I forgoten I must congratulate you for your GREAT libray, I was able
> to make an .exe with JSmooth that launches an application that uses RXTX
> with out the need to install RXTX on users system :). The .exe tells JVM
> where to find the RXTX Library and Binaries. I tried with Sun's Java
> Comm but it was imposible.

Hi Manuel

The compiler uses only the i386 instruction set for windows.  I doubt 
there will be any measurable advantages with going to later instruction 
sets.  In theory rxtx would run on a 386 but I doubt anyone does that.

So it looks odd but is not a typo.

We could compile to i686 but don't.  The compiler used does not appear to 
be a problem yet so I don't see any point in changing it.  Right now, we 
could not compile 64 bit windows binaries.  gcc/mingw/... do not support 
them that I know of.  People will have to compile those with closed source 
tools on their own until an option is available.

--
Trent Jarvi
tjarvi at qbang.org

From naranjo.manuel at gmail.com  Thu Jun 29 20:00:48 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 23:00:48 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606291945060.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com>	<Pine.LNX.4.61.0606291923000.9561@www>
	<44A48088.2040407@gmail.com> <Pine.LNX.4.61.0606291945060.9561@www>
Message-ID: <44A485D0.7050202@gmail.com>

Trent you did not get my point
The folder says 368 three hundred sixty eight, when
it should say 386 three hundred eighty six. Is simply a miss writting.
Regards,
Manuel


From tjarvi at qbang.org  Thu Jun 29 20:12:15 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 20:12:15 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A485D0.7050202@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
	<Pine.LNX.4.61.0606291923000.9561@www> <44A48088.2040407@gmail.com>
	<Pine.LNX.4.61.0606291945060.9561@www> <44A485D0.7050202@gmail.com>
Message-ID: <Pine.LNX.4.61.0606292008061.9561@www>


On Thu, 29 Jun 2006, Manuel Naranjo wrote:

> Trent you did not get my point
> The folder says 368 three hundred sixty eight, when
> it should say 386 three hundred eighty six. Is simply a miss writting.

hehe..  OK.  My bad.  It's been a long day.

Nevermind :)

--
Trent Jarvi
tjarvi at qbang.org




From naranjo.manuel at gmail.com  Thu Jun 29 20:18:44 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 23:18:44 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606292008061.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com>	<Pine.LNX.4.61.0606291923000.9561@www>
	<44A48088.2040407@gmail.com>	<Pine.LNX.4.61.0606291945060.9561@www>
	<44A485D0.7050202@gmail.com> <Pine.LNX.4.61.0606292008061.9561@www>
Message-ID: <44A48A04.9040401@gmail.com>

Don't worry Trent.
About 64 bits compilation, I would like to colaborate, I have a Pc with 
64 bits, the only problem is that i do not have windows 64 bits 
installed :(.




From Pawan.Kharbanda at dot.state.co.us  Fri Jun 30 08:49:52 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 30 Jun 2006 08:49:52 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E996@hqexchange3.dot.state.co.us>

Trent,  
    Can you explain what the interruptedEventLoop() native method is
doing is there a possibility that method is somehow getting into the
infinite loop(there are 2 while loops without any break statements).
This might be a very basic question how can I debug the native code(or
print the debug statements).  Again thanks for the help. 

Pawan Kharbanda

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Thursday, June 29, 2006 6:21 AM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports

> Here is how you can test if you have resources/ test environment. 
> Write a program and try to open/close  different ports(I will say have

> a minimum of four) randomly and very frequently(may be 30 seconds), I 
> am pretty sure you will see the deadlocks and it happens in the native

> call to interrptEventLoop in RXTXPort.java in removeEventListener() 
> method call.

Hi Pawan

I'll try to find a way to reproduce this.  One thing to note is that you
are using different kernel drivers (digi) to perform this task.  So I
probably will not be able to reproduce the exact same environment.

In general, multiport kernel drivers have been tested far less than
typical serial drivers.  This may or may not be an issue.

--
Trent Jarvi
tjarvi at qbang.org

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From cpine at wrsystems.com  Thu Jun 29 15:17:12 2006
From: cpine at wrsystems.com (Chris Pine)
Date: Thu, 29 Jun 2006 17:17:12 -0400
Subject: [Rxtx]  Controlling Individual Signals DTR and RTS
Message-ID: <MAIL4FJo0S8ACLEBajJ000005cf@mail4.wrsystems.com>

Dear Moussa Ba,
	I hope I am not being too forward, but we are having the exact same
issue with needing to control DTR from RXTX in Linux.  Did you ever have any
luck figuring it out?

Thank you very much for your time,

Chris Pine




From tjarvi at qbang.org  Thu Jun  1 11:13:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 11:13:40 -0600 (MDT)
Subject: [Rxtx] custom baud rate win32
In-Reply-To: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606011107210.30220@www>


Hi Daren

I can't imagine that 1953 is possibly the actual value on the UART.  Maybe 
if your baud base is very high with a custom serial board.  More likely, 
the driver just remembers that what you asked for and did something else.

I'll have more to say on the dcb->BaudRate after I try some things here. 
I have managed to do something like that in the past as a quick hack but 
it was for 14400.  I may have used the CBR_14400.

If we can't access this through the win32 API with protected mode, there 
is another layer of complication.  With real mode, it would be easy.
With protected mode, I assume there would have to be some kernel driver or 
a hook I'm not aware of to access the MCR directly (bang a memory 
addresss).



On Thu, 1 Jun 2006, Daren wrote:

> Trent,
> I have managed to successfully open the port at this speed using Realterm
> (available on sourceforge). From memory this uses DLPortIO.
>
> Using portmon.exe with realterm, even there it says that the port has opened
> at 1953.
>
> I changed termios.c:560 to
> dcb->BaudRate        = 1953 ;
>
> and it still opens the port at 9600.
>
> Daren
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Trent Jarvi
> Sent: Thursday, 1 June 2006 1:44 PM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] custom baud rate win32
>
> On Thu, 1 Jun 2006, Daren wrote:
>
>> Hi all,
>>
>> I downloaded 2.1.7-pre16 and managed to build it and get it going. I made
>> the changes as suggested by Peter Smith in an old post, by adding his code
>> to SerialImpl.c, uncommenting the TIOCGSERIAL and TIOCSSERIAL, and
> defining
>> ASYNC_SPD_CUST which is equal to 0x0030 (according to linus header
> files)..
>>
>>
>> Still not working, it opens the port at 9600 according to portmon.exe .
> Has
>> anyone managed to get this going at a custom rate?
>>
>> Here is the post I'm referring to:
>> http://marc.theaimsgroup.com/?l=rxtx&m=106270038110713&w=2
>>
>>
>> Thanks,
>> Daren
>>
>> ________________________________________
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
>> Daren
>> Sent: Wednesday, 31 May 2006 10:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] (no subject)
>>
>> Hi All,
>> I have been using rxtx for a little while and needed to get it working at
>> 1953, like a past user in the mailing list, who seemed to have got it
>> working by changing some C code.
>>
>> I wanted to build rxtx myself with these changes but don't know where to
>> start. I have windows here and FC4 at home. I downloaded cygwin and
> mingw32,
>> each build works by building a rxtxSerial.dll file that is ~11k smaller
> than
>> the original, and I always get the following error when testing the dll:
>>
>> Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at
>> PC=0x8077655
>> Function=[Unknown.]
>> Library=C:\opt\java\j2sdk1.4.2\jre\bin\client\jvm.dll
>>
>> NOTE: We are unable to locate the function name symbol for the error
>>      just occurred. Please refer to release documentation for possible
>>      reason and solutions.
>>
>>
>> Current Java thread:
>> 	at gnu.io.RXTXPort.open(Native Method)
>> 	- locked <0x1002c800> (a gnu.io.RXTXPort)
>> 	at gnu.io.RXTXPort.<init>(RXTXPort.java:84)
>>
>> Anyone know what im doing wrong?
>>
>>
>>
>>
>
> Hi Daren
>
> You are running into the same rats nest I'm looking at now.
>
> With win32 and specific custom baud rates, I'm not sure how this will go.
> I've got the Linux custom baud rates working very nicely.  I did much like
> the post you linked.  In fact I had forgot about that post.  You probably
> noticed that it becomes a bunch of dirt roads going noplace fast in
> termios.c for w32.
>
> I'm probably only going to get 14400, 28800, 128000 and 256000 working
> with the next release on w32.  I'll look a little further.  If you have an
> example w32 that works at 1953 I'd really like to hear.  Thats an unusual
> baud rate.
>
> Assuming a baud_base of 128000, your divisor will be 65 or 66.
>
> 128000/66=1939 -14
> 128000/65=1969 +13
>
> One thing I've been wondering about with linux is which would be the right
> answer in cases like this.  Right now it would just go with a baud base of
> 65 and ignore the modulus details.
>
> It appears to be a general trend for kernel developers to hide these
> details thinking that they can come up with a general solution.  Then they
> run out of time.  Perahps the solution is to help out but there are
> ultiple OS's rxtx supports making that nontrivial.
>
> If you look at current linux kernels, the 'tricks' above have been marked
> deprecated with no replacement.  Windows has some hard defines and then
> ancient near magic.  I've not looked at Solaris via Open Solaris yet but
> doubt there is a solution at all.
>
> What I'd try since you have the equipment and the monitor software is to
> hardcode the dcb->Baud in termios.c to 1953 (no define) and see what the
> w32 kernel does with it.  I think if you toss a baud rate at the driver it
> will try to come close.  You may try comming closer to a real baudrate
> based upon the 128000 baud base as shown above.
>
> If it works, it is worth looking at the rest of the ping/pong logic then.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
>
>
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From doug at dupreeinc.com  Thu Jun  1 13:22:13 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 12:22:13 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011107210.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
Message-ID: <447F3E65.1020809@dupreeinc.com>

Hello,

I am still trying to get this startup a little faster so I turned on the 
debug of a few of the classes.  The COM ports are scanned really fast 
and the delay occurs during the LPT scan.  The console output looks like 
this:

    ...
      LPT1
      LPT2
      LPT3
     valid port prefixes:
      LPT
    LPT1 LPT
    1 1
    LPT2 LPT
    2 2                                                                 
      * <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
    CommPortIdentifier:addPortName(LPT2)
    CommPortIdentifier:AddIdentifierToList()
    LPT3 LPT
    3 3
    CommPortIdentifier:addPortName(LPT3)
    CommPortIdentifier:AddIdentifierToList()
    CommPortIdentifier:AddIdentifierToList() index.next
    Leaving registerValidPorts()
    Have not implemented native_psmisc_report_owner(PortName)); in
    CommPortIdentifier
    CommPortIdentifier:getPortIdentifier(COM3)
    CommPortIdentifier:open(densConnect, 30000)
    RXTXCommDriver:getCommPort(COM3,1)
    ...

It would seem to me that if I removed the code for port scanning of LPT 
ports I could solve this problem. I would much prefer to use unmodified 
code if at all possible.  Do any of you have alternate suggestions?

Thank you for your time.

Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/cf433ee7/attachment-0008.html

From tjarvi at qbang.org  Thu Jun  1 13:52:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 13:52:06 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F3E65.1020809@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011348380.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I am still trying to get this startup a little faster so I turned on the 
> debug of a few of the classes.  The COM ports are scanned really fast and the 
> delay occurs during the LPT scan.  The console output looks like this:
>
>   ...
>     LPT1
>     LPT2
>     LPT3
>    valid port prefixes:
>     LPT
>   LPT1 LPT
>   1 1
>   LPT2 LPT
>   2 2                                                                      * 
> <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>   CommPortIdentifier:addPortName(LPT2)
>   CommPortIdentifier:AddIdentifierToList()
>   LPT3 LPT
>   3 3
>   CommPortIdentifier:addPortName(LPT3)
>   CommPortIdentifier:AddIdentifierToList()
>   CommPortIdentifier:AddIdentifierToList() index.next
>   Leaving registerValidPorts()
>   Have not implemented native_psmisc_report_owner(PortName)); in
>   CommPortIdentifier
>   CommPortIdentifier:getPortIdentifier(COM3)
>   CommPortIdentifier:open(densConnect, 30000)
>   RXTXCommDriver:getCommPort(COM3,1)
>   ...
>
> It would seem to me that if I removed the code for port scanning of LPT ports 
> I could solve this problem. I would much prefer to use unmodified code if at 
> all possible.  Do any of you have alternate suggestions?
>
> Thank you for your time.
>
> Doug
>


Does commenting out the LPT enumeration actually help?  There can often be 
differences between debug information printed and whats really going on. 
When you combine various environments the debug info can even come out in 
the wrong order.

I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
I do not think this problem is universal.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Thu Jun  1 14:29:44 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:29:44 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4E38.2060004@dupreeinc.com>

I will give it a try.  One thing to note on this PC is it has no LPT 
Parallel ports.

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
>>Hello,
>>
>>I am still trying to get this startup a little faster so I turned on the 
>>debug of a few of the classes.  The COM ports are scanned really fast and the 
>>delay occurs during the LPT scan.  The console output looks like this:
>>
>>  ...
>>    LPT1
>>    LPT2
>>    LPT3
>>   valid port prefixes:
>>    LPT
>>  LPT1 LPT
>>  1 1
>>  LPT2 LPT
>>  2 2                                                                      * 
>><<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>>  CommPortIdentifier:addPortName(LPT2)
>>  CommPortIdentifier:AddIdentifierToList()
>>  LPT3 LPT
>>  3 3
>>  CommPortIdentifier:addPortName(LPT3)
>>  CommPortIdentifier:AddIdentifierToList()
>>  CommPortIdentifier:AddIdentifierToList() index.next
>>  Leaving registerValidPorts()
>>  Have not implemented native_psmisc_report_owner(PortName)); in
>>  CommPortIdentifier
>>  CommPortIdentifier:getPortIdentifier(COM3)
>>  CommPortIdentifier:open(densConnect, 30000)
>>  RXTXCommDriver:getCommPort(COM3,1)
>>  ...
>>
>>It would seem to me that if I removed the code for port scanning of LPT ports 
>>I could solve this problem. I would much prefer to use unmodified code if at 
>>all possible.  Do any of you have alternate suggestions?
>>
>>Thank you for your time.
>>
>>Doug
>>
>>    
>>
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/dd31fed5/attachment-0008.html

From doug at dupreeinc.com  Thu Jun  1 14:36:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:36:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4FC8.9080106@dupreeinc.com>

Trent,

I commented out the section in RegisterScannedPorts() that adds the 
three LPT ports to the CandidateDeviceNames string array.  The 
application started immediately.  This is probably not the way to do 
this, but it was quick ,dirty, and worked.

It would be nice if there was a way to pole the OS to see if there is 
even a port there, though I guess this is what this code is suppose to do...

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
> ...
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From lynn at swcp.com  Thu Jun  1 14:49:34 2006
From: lynn at swcp.com (lynn@swcp.com)
Date: Thu, 1 Jun 2006 20:49:34 -0000
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>,
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <twig.1149194974.97617@swcp.com>

Perhaps we could add an argument to port enumeration where if not specified,
you get the default behavior that looks for everything.  With a new
constructor that has an argument(or more) you could optionally declare it to
not inspect printer ports.

Existing code would work as it always has.  New code could be smarter.

Lynn



Doug Thistlethwaite <doug at dupreeinc.com> said:

> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
> >On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
> >
> >  
> >
> > ...
> >
> >
> >Does commenting out the LPT enumeration actually help?  There can often be 
> >differences between debug information printed and whats really going on. 
> >When you combine various environments the debug info can even come out in 
> >the wrong order.
> >
> >I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
> >I do not think this problem is universal.
> >
> >--
> >Trent Jarvi
> >tjarvi at qbang.org
> >_______________________________________________
> >Rxtx mailing list
> >Rxtx at qbang.org
> >http://mailman.qbang.org/mailman/listinfo/rxtx
> >
> >
> >  
> >
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



-- 





From jredman at ergotech.com  Thu Jun  1 15:20:20 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 01 Jun 2006 15:20:20 -0600
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
Message-ID: <447F5A14.6010803@ergotech.com>

Doug,

If you specifically request ports, eg:

-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

or
 
-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

Depending upon the version  (Windows is COM1:COM2, etc. I assume).

Does it still enumerate the parallel ports?

Jim

Doug Thistlethwaite wrote:
> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
>> On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>
>>  
>>
>> ...
>>
>>
>> Does commenting out the LPT enumeration actually help?  There can often be 
>> differences between debug information printed and whats really going on. 
>> When you combine various environments the debug info can even come out in 
>> the wrong order.
>>
>> I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>> I do not think this problem is universal.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>>
>>  
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  1 16:49:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:49:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6EF4.7080709@dupreeinc.com>

I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
folder.  I created this file and added the following to the file:

gnu.io.rxtx.SerialPorts=COM3

and I get the following error on the console:
CommPortIdentifier:static initialization()
RXTXCommDriver {}
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
RXTXCommDriver:
    Jar version = RXTX-2.1-7
    native lib Version = RXTX-2.1-7
RXTXCommDriver:initialize()
checking for system-known ports of type 1
checking registry for ports of type 1

RXTXCommDriver:addSpecifiedPorts()
Exception in thread "main" java.lang.ExceptionInInitializerError
    at 
densconnect.SerialConnection.openConnection(SerialConnection.java:136)
    at densconnect.DensTalk.<init>(DensTalk.java:165)
    at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
    at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
    at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
    at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
Caused by: java.lang.NullPointerException
    at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
CommPortIdentifier:addPortName(COM3)
CommPortIdentifier:AddIdentifierToList()
CommPortIdentifier:AddIdentifierToList() null
...


It looks like it  read COM3 from the file, but it had the above 
exception that killed it.  The strange this is this error is from 
RXTXCommDriver initialize function (if statement line):

        OS = System.getProperty("os.name");
                System.out.println("OS NAME: " + OS);
        if(OS.toLowerCase().indexOf("linux") == -1)

OS is returning null, thus the error.

If the file is not present, it scans the ports and reads the OS.

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>Doug Thistlethwaite wrote:
>  
>
>>Trent,
>>
>>I commented out the section in RegisterScannedPorts() that adds the 
>>three LPT ports to the CandidateDeviceNames string array.  The 
>>application started immediately.  This is probably not the way to do 
>>this, but it was quick ,dirty, and worked.
>>
>>It would be nice if there was a way to pole the OS to see if there is 
>>even a port there, though I guess this is what this code is suppose to do...
>>
>>Doug
>>
>>Trent Jarvi wrote:
>>
>>    
>>
>>>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>>
>>> 
>>>
>>>...
>>>
>>>
>>>Does commenting out the LPT enumeration actually help?  There can often be 
>>>differences between debug information printed and whats really going on. 
>>>When you combine various environments the debug info can even come out in 
>>>the wrong order.
>>>
>>>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>>>I do not think this problem is universal.
>>>
>>>--
>>>Trent Jarvi
>>>tjarvi at qbang.org
>>>_______________________________________________
>>>Rxtx mailing list
>>>Rxtx at qbang.org
>>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>>
>>>
>>> 
>>>
>>>      
>>>
>>_______________________________________________
>>Rxtx mailing list
>>Rxtx at qbang.org
>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>    
>>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/bf4cca0e/attachment-0008.html

From doug at dupreeinc.com  Thu Jun  1 16:51:26 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:51:26 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6F6E.5060603@dupreeinc.com>

Jim,

I did not try your suggestion as I do not understand where I would put 
these command line parameters (it that is what they are).  It appears 
that using the properties file should do that same thing...

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>
>  
>


From doug at dupreeinc.com  Thu Jun  1 17:56:19 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 16:56:19 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
Message-ID: <447F7EA3.6050400@dupreeinc.com>

I think there is an error in the registerSpecifiedPorts() method.  When 
I have a gnu.io.rxtx.properties file in the ext directory, this function 
kills the System class  IF I call System.getProperty("os.name") before 
the call  to registerSpecifiedPorts(), it returns the os name, after the 
call, it returns null.  I have not played much with properties, except 
for reading them, so I don't really understand the code.

Doug



From doug at dupreeinc.com  Thu Jun  1 18:11:14 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 17:11:14 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F7EA3.6050400@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com>
Message-ID: <447F8222.3060402@dupreeinc.com>

Ok, I just hacked this thing up and got it to read the 
gnu.io.rxtx.properties file.

I commented out the line:
System.setProperties(p); in the method registerSpecifiedPorts() in 
RXTXCommDriver class.  I really don't understand that much about 
properties, but this call kills the System class.

I used the following in the gnu.io.rxtx.properties file:

gnu.io.rxtx.SerialPorts=COM3
gnu.io.rxtx.ParallelPorts=null

This allows the application to open very quickly without any errors.  
Whomever coded this class or somebody who understands properties should 
look at this method and make sure it is doing what they expect.

Doug




Doug Thistlethwaite wrote:

>I think there is an error in the registerSpecifiedPorts() method.  When 
>I have a gnu.io.rxtx.properties file in the ext directory, this function 
>kills the System class  IF I call System.getProperty("os.name") before 
>the call  to registerSpecifiedPorts(), it returns the os name, after the 
>call, it returns null.  I have not played much with properties, except 
>for reading them, so I don't really understand the code.
>
>Doug
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From tjarvi at qbang.org  Thu Jun  1 18:32:50 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 18:32:50 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F6EF4.7080709@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com> <447F6EF4.7080709@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011831510.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
> folder.  I created this file and added the following to the file:
>
> gnu.io.rxtx.SerialPorts=COM3
>
> and I get the following error on the console:
> CommPortIdentifier:static initialization()
> RXTXCommDriver {}
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
> RXTXCommDriver:
>   Jar version = RXTX-2.1-7
>   native lib Version = RXTX-2.1-7
> RXTXCommDriver:initialize()
> checking for system-known ports of type 1
> checking registry for ports of type 1
>
> RXTXCommDriver:addSpecifiedPorts()
> Exception in thread "main" java.lang.ExceptionInInitializerError
>   at densconnect.SerialConnection.openConnection(SerialConnection.java:136)
>   at densconnect.DensTalk.<init>(DensTalk.java:165)
>   at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
>   at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
>   at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
>   at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
> Caused by: java.lang.NullPointerException
>   at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
> CommPortIdentifier:addPortName(COM3)
> CommPortIdentifier:AddIdentifierToList()
> CommPortIdentifier:AddIdentifierToList() null
> ...
>
>

There is a solution for this bug.

http://bugzilla.qbang.org/show_bug.cgi?id=54

We have been horribly slow at getting the next round of patches in but 
they are comming.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  2 00:58:02 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 08:58:02 +0200
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F8222.3060402@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
Message-ID: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>

Hi Doug,

you wrote in an earlier message, that you would prefer an unchanged  
version. What about simply removing the RXTX parallel lib from the  
ext directory. This does not fix the bug, but it should fix your  
problem.

In general I think it is not a good idea to put the RXTX files in a  
system wide location. Putting the libs in the application folder and  
including the .jar in the application classpath (or application jar)  
is all that is required.

Regards,
Joachim

On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:

> Ok, I just hacked this thing up and got it to read the
> gnu.io.rxtx.properties file.
>
> I commented out the line:
> System.setProperties(p); in the method registerSpecifiedPorts() in
> RXTXCommDriver class.  I really don't understand that much about
> properties, but this call kills the System class.
>
> I used the following in the gnu.io.rxtx.properties file:
>
> gnu.io.rxtx.SerialPorts=COM3
> gnu.io.rxtx.ParallelPorts=null
>
> This allows the application to open very quickly without any errors.
> Whomever coded this class or somebody who understands properties  
> should
> look at this method and make sure it is doing what they expect.
>
> Doug
>
>
>
>
> Doug Thistlethwaite wrote:
>
>> I think there is an error in the registerSpecifiedPorts() method.   
>> When
>> I have a gnu.io.rxtx.properties file in the ext directory, this  
>> function
>> kills the System class  IF I call System.getProperty("os.name")  
>> before
>> the call  to registerSpecifiedPorts(), it returns the os name,  
>> after the
>> call, it returns null.  I have not played much with properties,  
>> except
>> for reading them, so I don't really understand the code.
>>
>> 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 antonio.luis at iscte.pt  Fri Jun  2 02:42:28 2006
From: antonio.luis at iscte.pt (=?ISO-8859-1?Q?Ant=F3nio_Lopes?=)
Date: Fri, 02 Jun 2006 09:42:28 +0100
Subject: [Rxtx] Exception when closing serial port
Message-ID: <447FF9F4.7060209@iscte.pt>

Hello everyone,
I've been using RXTX in a Java application in my Pocket PC.
The communication through the (bluetooth) serial port is working perfectly.

However, when I disconnect the app and close the serial port, sometimes I get 
the following error:

"1149237595000: RXTXPort:close detected bad File Descriptor"

The problem is that after this error occurs, the app is no longer able to 
connect to the serial port and I have to soft-reset the device in order to be 
able to connect to it again.

Any ideas on how to solve this issue?

Any help is appreciated.
Thanks,
regards,
-- 
Ant?nio Lopes

@contact: antonio.luis at iscte.pt
@work: ADETTI - ISCTE
@web: http://antonio.lopes.googlepages.com


From paul.klissner at sun.com  Fri Jun  2 02:44:34 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 01:44:34 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to RXTX
	again
Message-ID: <447FFA72.6040807@sun.com>

After looking into javax.comm 3.1 and what it would take to re-engineer it
to be compatible with RXTX platform libraries, I've decided, due my group's
priorities, complexity of the effort vs. benefit, and limited resources, 
to re-post
javax.comm 2.0 binaries on Sun's software download server, unsupported,
with disclaimers, as it was previously.

I don't think there will be any snags doing this from the standpoint of Sun
management or legality.  I will try to have it  posted there in the next 
week
or two, depending on how fast we can get it pushed through the process.

I'd like to think of this as a stop gap measure... ie. a compromise, 
where, at some
point in the not too distant future RXTX implements their own version of the
Java side of the API, as is normally done by javax.extension porters. 
That way
we avoid uncomfortable dependencies in the future.  And that really is 
the Java
development model.

Since RXTX already has the back-end code, porting the java code shouldn't
be a gargantuan effort at all, and RXTX will be in full control of the 
code top
to bottom. I think RXTX can do at least as good a job as the original 
coder.
Prepping 2.0 to be open sourced is more trouble than it is worth. ie. I 
don't
think the current implementation warrants it.

Ultimately, it would be nice to see someone open up a JSR and re-architect
the comm. API to overcome some of it's current design flaws (ie. be more
adaptable to modern platforms, more pluggable, better defined SPI, better
port ownership handling, etc...). A superior architecture would allow for
better collaboration in the future and better interchangeability of 
components
among projects.

Sun's 3.1 version of javax.comm, which is Sun's currently supported version,
has changes pertaining mostly to Sun platform-specific portmapping and has
some minor additional interactions with our back end code, but generally
has little bearing on RXTX. 

Paul



From joachim at buechse.de  Fri Jun  2 04:00:19 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 12:00:19 +0200
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
	RXTX again
In-Reply-To: <447FFA72.6040807@sun.com>
References: <447FFA72.6040807@sun.com>
Message-ID: <1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>

Good day Paul!

A clean architecture with loadable drivers and reusable code would be  
very beneficial for the future, I think everybody agrees. However  
this could be several years into the future. In the meantime, there  
is a real existing problem with IO support on Java. I have the strong  
feeling that most programmers want to code against one specification  
(javax.comm) and be able to replace the underlying implementation via  
a "plugin" on platforms where the SUN implementation is not  
sufficient. RXTX could be just this plugin (reusing very close to 0%  
of the javax.comm implementation but 100% of its API).

I want to propose an API addition and implementation change that will  
take less then 2 hours of manpower to implement and create a solution  
that can bridge the years until javax.comm has been based on a new  
architecture.

Looking at the javax.comm api at http://java.sun.com/products/ 
javacomm/reference/api/index.html I would like to propose the following:

The only entry point to javax.comm is CommPortIdentifier. It has 3  
static methods plus the constructor.

1) define one additional Interface

public interface CommProvider {
    CommPortIdentifier getPortIdentifier(CommPort port);
    CommPortIdentifier getPortIdentifier(String portName);
    Enumeration getPortIdentifiers ();
}

2) add one method to CommPortIdentifier

   public static setCustomCommProvider (CommProvider);

3) change the three static methods of CommPortIdentifier to dispatch  
to the CommProvider if it is set

4) change the constructor of CommPortIdentifier to

   public CommPortIdentifier(...) {
      if (isProviderSet && this.getClass() ==  
javax.comm.CommPortIdentifier) {
          throw new RuntimeException("illegal creation of  
CommPortIndentifier, custom CommProvider is in use");
      }

5) (this is optional, but would be very nice) automatically set a  
custom CommProvider if it is found on the classpath or defined via a  
system property.


The above 1) - 4) can be implemented in less than 1hour. 5) may take  
another hour. I agree that this is not the most elegant design, but  
it would solve a lot of problems with very little effort. It would  
certainly allow RXTX to move forward. If the javax.comm API needs to  
be redesigned completely this addition will not hurt, as people will  
move to the new API anyway and javax.comm 3.0 was so far never  
included in the main distribution.

Best regards,
Joachim

On 02.06.2006, at 10:44, Paul Klissner wrote:

> After looking into javax.comm 3.1 and what it would take to re- 
> engineer it
> to be compatible with RXTX platform libraries, I've decided, due my  
> group's
> priorities, complexity of the effort vs. benefit, and limited  
> resources,
> to re-post
> javax.comm 2.0 binaries on Sun's software download server,  
> unsupported,
> with disclaimers, as it was previously.
>
> I don't think there will be any snags doing this from the  
> standpoint of Sun
> management or legality.  I will try to have it  posted there in the  
> next
> week
> or two, depending on how fast we can get it pushed through the  
> process.
>
> I'd like to think of this as a stop gap measure... ie. a compromise,
> where, at some
> point in the not too distant future RXTX implements their own  
> version of the
> Java side of the API, as is normally done by javax.extension porters.
> That way
> we avoid uncomfortable dependencies in the future.  And that really is
> the Java
> development model.
>
> Since RXTX already has the back-end code, porting the java code  
> shouldn't
> be a gargantuan effort at all, and RXTX will be in full control of the
> code top
> to bottom. I think RXTX can do at least as good a job as the original
> coder.
> Prepping 2.0 to be open sourced is more trouble than it is worth.  
> ie. I
> don't
> think the current implementation warrants it.
>
> Ultimately, it would be nice to see someone open up a JSR and re- 
> architect
> the comm. API to overcome some of it's current design flaws (ie. be  
> more
> adaptable to modern platforms, more pluggable, better defined SPI,  
> better
> port ownership handling, etc...). A superior architecture would  
> allow for
> better collaboration in the future and better interchangeability of
> components
> among projects.
>
> Sun's 3.1 version of javax.comm, which is Sun's currently supported  
> version,
> has changes pertaining mostly to Sun platform-specific portmapping  
> and has
> some minor additional interactions with our back end code, but  
> generally
> has little bearing on RXTX.
>
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Fri Jun  2 09:10:13 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Fri, 2 Jun 2006 09:10:13 -0600 (MDT)
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <447FFA72.6040807@sun.com>
References: <447FFA72.6040807@sun.com>
Message-ID: <Pine.LNX.4.61.0606020906400.15971@www>

On Fri, 2 Jun 2006, Paul Klissner wrote:

> After looking into javax.comm 3.1 and what it would take to re-engineer it
> to be compatible with RXTX platform libraries, I've decided, due my group's
> priorities, complexity of the effort vs. benefit, and limited resources,
> to re-post
> javax.comm 2.0 binaries on Sun's software download server, unsupported,
> with disclaimers, as it was previously.
>

Hi Paul

To address users' immediate needs, we can release rxtx 2.0-7 (final) to 
match the 2.0 binaries from Sun when they are offered for download.

We can discuss potential long term solutions after that.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Fri Jun  2 10:20:09 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 02 Jun 2006 09:20:09 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
	<9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
Message-ID: <44806539.8080902@dupreeinc.com>

Thanks for the suggestion, I will give it a try.

Doug

Joachim Buechse wrote:

>Hi Doug,
>
>you wrote in an earlier message, that you would prefer an unchanged  
>version. What about simply removing the RXTX parallel lib from the  
>ext directory. This does not fix the bug, but it should fix your  
>problem.
>
>In general I think it is not a good idea to put the RXTX files in a  
>system wide location. Putting the libs in the application folder and  
>including the .jar in the application classpath (or application jar)  
>is all that is required.
>
>Regards,
>Joachim
>
>On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:
>
>  
>
>>Ok, I just hacked this thing up and got it to read the
>>gnu.io.rxtx.properties file.
>>
>>I commented out the line:
>>System.setProperties(p); in the method registerSpecifiedPorts() in
>>RXTXCommDriver class.  I really don't understand that much about
>>properties, but this call kills the System class.
>>
>>I used the following in the gnu.io.rxtx.properties file:
>>
>>gnu.io.rxtx.SerialPorts=COM3
>>gnu.io.rxtx.ParallelPorts=null
>>
>>This allows the application to open very quickly without any errors.
>>Whomever coded this class or somebody who understands properties  
>>should
>>look at this method and make sure it is doing what they expect.
>>
>>Doug
>>
>>
>>
>>
>>Doug Thistlethwaite wrote:
>>
>>    
>>
>>>I think there is an error in the registerSpecifiedPorts() method.   
>>>When
>>>I have a gnu.io.rxtx.properties file in the ext directory, this  
>>>function
>>>kills the System class  IF I call System.getProperty("os.name")  
>>>before
>>>the call  to registerSpecifiedPorts(), it returns the os name,  
>>>after the
>>>call, it returns null.  I have not played much with properties,  
>>>except
>>>for reading them, so I don't really understand the code.
>>>
>>>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
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060602/c8892a46/attachment-0008.html

From paul.klissner at sun.com  Fri Jun  2 12:09:26 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 11:09:26 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
Message-ID: <44807ED6.8000903@sun.com>

Joachim Buechse wrote:
> Good day Paul!
>
> A clean architecture with loadable drivers and reusable code would be  
> very beneficial for the future, I think everybody agrees. However  
> this could be several years into the future. In the meantime, there  
> is a real existing problem with IO support on Java. I have the strong  
> feeling that most programmers want to code against one specification  
> (javax.comm) and be able to replace the underlying implementation via  
> a "plugin" on platforms where the SUN implementation is not  
> sufficient. RXTX could be just this plugin (reusing very close to 0%  
> of the javax.comm implementation but 100% of its API).
>
> I want to propose an API addition and implementation change that will  
> take less then 2 hours of manpower to implement and create a solution  
> that can bridge the years until javax.comm has been based on a new  
> architecture.
>
> Looking at the javax.comm api at http://java.sun.com/products/ 
> javacomm/reference/api/index.html I would like to propose the following:
>
> The only entry point to javax.comm is CommPortIdentifier. It has 3  
> static methods plus the constructor.
>
> 1) define one additional Interface
>
> public interface CommProvider {
>     CommPortIdentifier getPortIdentifier(CommPort port);
>     CommPortIdentifier getPortIdentifier(String portName);
>     Enumeration getPortIdentifiers ();
> }
>
> 2) add one method to CommPortIdentifier
>
>    public static setCustomCommProvider (CommProvider);
>
> 3) change the three static methods of CommPortIdentifier to dispatch  
> to the CommProvider if it is set
>
> 4) change the constructor of CommPortIdentifier to
>
>    public CommPortIdentifier(...) {
>       if (isProviderSet && this.getClass() ==  
> javax.comm.CommPortIdentifier) {
>           throw new RuntimeException("illegal creation of  
> CommPortIndentifier, custom CommProvider is in use");
>       }
>
> 5) (this is optional, but would be very nice) automatically set a  
> custom CommProvider if it is found on the classpath or defined via a  
> system property.
>
>
> The above 1) - 4) can be implemented in less than 1hour. 5) may take  
> another hour. I agree that this is not the most elegant design, but  
> it would solve a lot of problems with very little effort. It would  
> certainly allow RXTX to move forward. If the javax.comm API needs to  
> be redesigned completely this addition will not hurt, as people will  
> move to the new API anyway and javax.comm 3.0 was so far never  
> included in the main distribution.
>
> Best regards,
> Joachi
I'm afraid modifying the interface classes isn't my call.  There was 
actually
a TCK written and one of the tests was to ensure that the interface classes
match the spec.  Thus my hands have already been tied since this project
was essentially grandfathered into the JCP.

That's why we need to open a new JSR and find someone who wants
to be the spec lead, and go in with a new reference implementation.
I'm not sure why it would have to take years, since this isn't bleeding edge
technology and there are only so many things that can be done with it,
and we already have practical experience about many functional aspects
that we could cite precedence on.

As it becomes clear that the specification is being accepted completely
or by-and-large by the community, nothing would stop people from
starting adapting to the new API (using the reference implementation or
porting it) and using it in their projects prior to it's final community and
JCP approval, since approval is required only to make it official and
get the "100% pure java" certification for platform ports.

You have one idea already.  Why don't you implement it, solicit some
design feedback from Sun and the RXTX, and create a functional
implementation that addresses the needs of the community, then
we can document it and open a JSR.  That's it.  It should march through
the approval stages reasonably quickly I would imagine, and meantime
RXTX could start using it.

Paul




From doug at dupreeinc.com  Fri Jun  2 12:45:01 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 02 Jun 2006 11:45:01 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
	<9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
Message-ID: <4480872D.6000605@dupreeinc.com>

Joachim,

Thank you for the suggestion.  I restored the jar file to the one I 
downloaded, moved the dll files into the project directory, and added 
the jar to the classpath.  The SerialDemo program that was included with 
the Sun commapi started in 12 seconds instead of the 58 seconds when the 
parallel dll is present.  I did get the startup time to about a second 
by modifying the java code and adding the properties file but this is 
probably not a good idea.

Doug

Joachim Buechse wrote:

>Hi Doug,
>
>you wrote in an earlier message, that you would prefer an unchanged  
>version. What about simply removing the RXTX parallel lib from the  
>ext directory. This does not fix the bug, but it should fix your  
>problem.
>
>In general I think it is not a good idea to put the RXTX files in a  
>system wide location. Putting the libs in the application folder and  
>including the .jar in the application classpath (or application jar)  
>is all that is required.
>
>Regards,
>Joachim
>
>On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:
>
>  
>
>>Ok, I just hacked this thing up and got it to read the
>>gnu.io.rxtx.properties file.
>>
>>I commented out the line:
>>System.setProperties(p); in the method registerSpecifiedPorts() in
>>RXTXCommDriver class.  I really don't understand that much about
>>properties, but this call kills the System class.
>>
>>I used the following in the gnu.io.rxtx.properties file:
>>
>>gnu.io.rxtx.SerialPorts=COM3
>>gnu.io.rxtx.ParallelPorts=null
>>
>>This allows the application to open very quickly without any errors.
>>Whomever coded this class or somebody who understands properties  
>>should
>>look at this method and make sure it is doing what they expect.
>>
>>Doug
>>
>>
>>
>>
>>Doug Thistlethwaite wrote:
>>
>>    
>>
>>>I think there is an error in the registerSpecifiedPorts() method.   
>>>When
>>>I have a gnu.io.rxtx.properties file in the ext directory, this  
>>>function
>>>kills the System class  IF I call System.getProperty("os.name")  
>>>before
>>>the call  to registerSpecifiedPorts(), it returns the os name,  
>>>after the
>>>call, it returns null.  I have not played much with properties,  
>>>except
>>>for reading them, so I don't really understand the code.
>>>
>>>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
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060602/3c0e420f/attachment-0008.html

From joachim at buechse.de  Fri Jun  2 13:46:36 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 21:46:36 +0200
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
	RXTX again
In-Reply-To: <44807ED6.8000903@sun.com>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
	<44807ED6.8000903@sun.com>
Message-ID: <6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>

Hello Paul,

of course, the basic change I suggested could be done "hidden".  The  
CommProvider interface could live somewhere in sun.xyz.*
The setCustomCommProvider method would not be in CommPortIdentifier  
but also somewhere in sun.xyz.* This would be an unofficial feature,  
the official interface stays exactly the same. However RXTX (and  
others) could access the hidden interface.

Don't get me wrong, I don't want to harass you into making changes  
you don't like (which probably wouldn't work anyway;-). But I'm a  
long time Java programmer and seeing the state of cross platform  
serial support for Java makes me feel really sad. In fact, when I  
started to look into Java serial port programming some months ago I  
was very surprised that javax.comm never made it into the JDK.

I'm sorry that I did not contribute my feedback to the JSR for  
javax.comm 3.0. However at the time I didn't do serial port  
programming in Java. I agree that a new JSR should be opened - I'm  
not an expert on JSRs or the JCP process, but from looking quickly  
over the progress of some JSRs I would be very surprised if we can  
have a new version in less then a year. In the meanwhile some people  
will start using javax.comm 3.0 (which can not be supported by RXTX),  
some will use javax.comm 2.0 (which means the 2.0.7 release of RXTX  
still needs to be maintained). This may get even worse if eg Apple  
decides to port and include javax.comm 3.0 at which point it may get  
very tricky to write a cross platform Java application.

All of this simply means, that we are loosing a lot of man-power that  
could otherwise be invested in building a clean solution and/or to  
add features that are becoming more and more important (USB events...).

In the automation / machine control universe Java makes a lot of  
sense. Right now many people are migrating to Linux or from  
propietary systems (even DOS) to Windows. Writing the control/ 
configuration applications in Java is the kings way to unify the code  
base.

Best regards,
Joachim


On 02.06.2006, at 20:09, Paul Klissner wrote:

> Joachim Buechse wrote:
>> Good day Paul!
>>
>> A clean architecture with loadable drivers and reusable code would be
>> very beneficial for the future, I think everybody agrees. However
>> this could be several years into the future. In the meantime, there
>> is a real existing problem with IO support on Java. I have the strong
>> feeling that most programmers want to code against one specification
>> (javax.comm) and be able to replace the underlying implementation via
>> a "plugin" on platforms where the SUN implementation is not
>> sufficient. RXTX could be just this plugin (reusing very close to 0%
>> of the javax.comm implementation but 100% of its API).
>>
>> I want to propose an API addition and implementation change that will
>> take less then 2 hours of manpower to implement and create a solution
>> that can bridge the years until javax.comm has been based on a new
>> architecture.
>>
>> Looking at the javax.comm api at http://java.sun.com/products/
>> javacomm/reference/api/index.html I would like to propose the  
>> following:
>>
>> The only entry point to javax.comm is CommPortIdentifier. It has 3
>> static methods plus the constructor.
>>
>> 1) define one additional Interface
>>
>> public interface CommProvider {
>>     CommPortIdentifier getPortIdentifier(CommPort port);
>>     CommPortIdentifier getPortIdentifier(String portName);
>>     Enumeration getPortIdentifiers ();
>> }
>>
>> 2) add one method to CommPortIdentifier
>>
>>    public static setCustomCommProvider (CommProvider);
>>
>> 3) change the three static methods of CommPortIdentifier to dispatch
>> to the CommProvider if it is set
>>
>> 4) change the constructor of CommPortIdentifier to
>>
>>    public CommPortIdentifier(...) {
>>       if (isProviderSet && this.getClass() ==
>> javax.comm.CommPortIdentifier) {
>>           throw new RuntimeException("illegal creation of
>> CommPortIndentifier, custom CommProvider is in use");
>>       }
>>
>> 5) (this is optional, but would be very nice) automatically set a
>> custom CommProvider if it is found on the classpath or defined via a
>> system property.
>>
>>
>> The above 1) - 4) can be implemented in less than 1hour. 5) may take
>> another hour. I agree that this is not the most elegant design, but
>> it would solve a lot of problems with very little effort. It would
>> certainly allow RXTX to move forward. If the javax.comm API needs to
>> be redesigned completely this addition will not hurt, as people will
>> move to the new API anyway and javax.comm 3.0 was so far never
>> included in the main distribution.
>>
>> Best regards,
>> Joachi
> I'm afraid modifying the interface classes isn't my call.  There was
> actually
> a TCK written and one of the tests was to ensure that the interface  
> classes
> match the spec.  Thus my hands have already been tied since this  
> project
> was essentially grandfathered into the JCP.
>
> That's why we need to open a new JSR and find someone who wants
> to be the spec lead, and go in with a new reference implementation.
> I'm not sure why it would have to take years, since this isn't  
> bleeding edge
> technology and there are only so many things that can be done with it,
> and we already have practical experience about many functional aspects
> that we could cite precedence on.
>
> As it becomes clear that the specification is being accepted  
> completely
> or by-and-large by the community, nothing would stop people from
> starting adapting to the new API (using the reference  
> implementation or
> porting it) and using it in their projects prior to it's final  
> community and
> JCP approval, since approval is required only to make it official and
> get the "100% pure java" certification for platform ports.
>
> You have one idea already.  Why don't you implement it, solicit some
> design feedback from Sun and the RXTX, and create a functional
> implementation that addresses the needs of the community, then
> we can document it and open a JSR.  That's it.  It should march  
> through
> the approval stages reasonably quickly I would imagine, and meantime
> RXTX could start using it.
>
> Paul
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From paul.klissner at sun.com  Fri Jun  2 14:38:49 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 13:38:49 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
	<44807ED6.8000903@sun.com>
	<6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>
Message-ID: <4480A1D9.5060106@sun.com>

Joachim Buechse wrote:
> Hello Paul,
>
> of course, the basic change I suggested could be done "hidden".  The  
> CommProvider interface could live somewhere in sun.xyz.*
> The setCustomCommProvider method would not be in CommPortIdentifier  
> but also somewhere in sun.xyz.* This would be an unofficial feature,  
> the official interface stays exactly the same. However RXTX (and  
> others) could access the hidden interface.
>
> Don't get me wrong, I don't want to harass you into making changes  
> you don't like (which probably wouldn't work anyway;-). But I'm a  
> long time Java programmer and seeing the state of cross platform  
> serial support for Java makes me feel really sad. In fact, when I  
> started to look into Java serial port programming some months ago I  
> was very surprised that javax.comm never made it into the JDK.
>
> I'm sorry that I did not contribute my feedback to the JSR for  
> javax.comm 3.0. 
There was no JSR for 3.0, because we didn't have the resources to make 
the commitment.
Yet Sun needed to add support for platform-dependent port name mapping, 
which had to
be done 'under the hood', since the API isn't designed to handle that in 
a pluggable way.
But these quick fixes aren't the right approach, they just kick the dog 
down the road,
setting bad precedent, inviting confusion and more intractable problems 
(such as the
one plaguing us now).

My changes could have been layered better, it was a trade off between 
achieving an
ideal architecture, trying to find internal reviewers, and meet the 
needs of big customers
in a timely way.  Thus my namespace changes collided with RXTX's 
dependencies.
I was unaware of Jagane's rogue agreement made with the RXTX community 7 
years ago,
before Jagane left Sun.  I think this was a wag-the-dog situation.

Now it is time to do it right, and I don't think it is going to be as 
much trouble as people
some people fear. If RXTX wants to sponsor the JSR and seed a new spec, 
Sun can join
the Expert Group.  And we'd be largely in agreement, since we're not 
talking about
humongous changes, and looking for mutually beneficial changes. The core 
API is already
largely proved and tested.
> However at the time I didn't do serial port  
> programming in Java. I agree that a new JSR should be opened - I'm  
> not an expert on JSRs or the JCP process, but from looking quickly  
> over the progress of some JSRs I would be very surprised if we can  
> have a new version in less then a year. 
*Approved*  But that doesn't mean the spec couldn't be 99.9% stable 
before that.  Once
the delta rate declines and changes approach nil, people could start 
adapting to the API in
advance of formal approval.   It isn't going to be drawn out like 
javax.usb, which was new
technology, a very complex API, and involved precedent setting corporate 
disputes and
policy issues to resolve.

> In the meanwhile some people  
> will start using javax.comm 3.0 (which can not be supported by RXTX),  
> some will use javax.comm 2.0 (which means the 2.0.7 release of RXTX  
> still needs to be maintained). This may get even worse if eg Apple  
> decides to port and include javax.comm 3.0 at which point it may get  
> very tricky to write a cross platform Java application.
>   
The interfaces haven't changed since 1.0.  If we open a JSR ,we can 
contact Apple and
allow them to be on the E.G., if they want.  That might make the JSR a 
bit more drawn out,
but then we'd arrive ultimately arrive at a best-of-all-worlds API that 
most people would
accept, perhaps forever, and arrive at a respectable set of compromises.

-Paul

> All of this simply means, that we are loosing a lot of man-power that  
> could otherwise be invested in building a clean solution and/or to  
> add features that are becoming more and more important (USB events...).
>
> In the automation / machine control universe Java makes a lot of  
> sense. Right now many people are migrating to Linux or from  
> propietary systems (even DOS) to Windows. Writing the control/ 
> configuration applications in Java is the kings way to unify the code  
> base.
>
> Best regards,
> Joachim
>
>
> On 02.06.2006, at 20:09, Paul Klissner wrote:
>
>   
>> Joachim Buechse wrote:
>>     
>>> Good day Paul!
>>>
>>> A clean architecture with loadable drivers and reusable code would be
>>> very beneficial for the future, I think everybody agrees. However
>>> this could be several years into the future. In the meantime, there
>>> is a real existing problem with IO support on Java. I have the strong
>>> feeling that most programmers want to code against one specification
>>> (javax.comm) and be able to replace the underlying implementation via
>>> a "plugin" on platforms where the SUN implementation is not
>>> sufficient. RXTX could be just this plugin (reusing very close to 0%
>>> of the javax.comm implementation but 100% of its API).
>>>
>>> I want to propose an API addition and implementation change that will
>>> take less then 2 hours of manpower to implement and create a solution
>>> that can bridge the years until javax.comm has been based on a new
>>> architecture.
>>>
>>> Looking at the javax.comm api at http://java.sun.com/products/
>>> javacomm/reference/api/index.html I would like to propose the  
>>> following:
>>>
>>> The only entry point to javax.comm is CommPortIdentifier. It has 3
>>> static methods plus the constructor.
>>>
>>> 1) define one additional Interface
>>>
>>> public interface CommProvider {
>>>     CommPortIdentifier getPortIdentifier(CommPort port);
>>>     CommPortIdentifier getPortIdentifier(String portName);
>>>     Enumeration getPortIdentifiers ();
>>> }
>>>
>>> 2) add one method to CommPortIdentifier
>>>
>>>    public static setCustomCommProvider (CommProvider);
>>>
>>> 3) change the three static methods of CommPortIdentifier to dispatch
>>> to the CommProvider if it is set
>>>
>>> 4) change the constructor of CommPortIdentifier to
>>>
>>>    public CommPortIdentifier(...) {
>>>       if (isProviderSet && this.getClass() ==
>>> javax.comm.CommPortIdentifier) {
>>>           throw new RuntimeException("illegal creation of
>>> CommPortIndentifier, custom CommProvider is in use");
>>>       }
>>>
>>> 5) (this is optional, but would be very nice) automatically set a
>>> custom CommProvider if it is found on the classpath or defined via a
>>> system property.
>>>
>>>
>>> The above 1) - 4) can be implemented in less than 1hour. 5) may take
>>> another hour. I agree that this is not the most elegant design, but
>>> it would solve a lot of problems with very little effort. It would
>>> certainly allow RXTX to move forward. If the javax.comm API needs to
>>> be redesigned completely this addition will not hurt, as people will
>>> move to the new API anyway and javax.comm 3.0 was so far never
>>> included in the main distribution.
>>>
>>> Best regards,
>>> Joachi
>>>       
>> I'm afraid modifying the interface classes isn't my call.  There was
>> actually
>> a TCK written and one of the tests was to ensure that the interface  
>> classes
>> match the spec.  Thus my hands have already been tied since this  
>> project
>> was essentially grandfathered into the JCP.
>>
>> That's why we need to open a new JSR and find someone who wants
>> to be the spec lead, and go in with a new reference implementation.
>> I'm not sure why it would have to take years, since this isn't  
>> bleeding edge
>> technology and there are only so many things that can be done with it,
>> and we already have practical experience about many functional aspects
>> that we could cite precedence on.
>>
>> As it becomes clear that the specification is being accepted  
>> completely
>> or by-and-large by the community, nothing would stop people from
>> starting adapting to the new API (using the reference  
>> implementation or
>> porting it) and using it in their projects prior to it's final  
>> community and
>> JCP approval, since approval is required only to make it official and
>> get the "100% pure java" certification for platform ports.
>>
>> You have one idea already.  Why don't you implement it, solicit some
>> design feedback from Sun and the RXTX, and create a functional
>> implementation that addresses the needs of the community, then
>> we can document it and open a JSR.  That's it.  It should march  
>> through
>> the approval stages reasonably quickly I would imagine, and meantime
>> RXTX could start using it.
>>
>> Paul
>>
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at 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  Sat Jun  3 18:15:24 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 18:15:24 -0600 (MDT)
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
Message-ID: <Pine.LNX.4.61.0606031715100.10890@www>


The attached patch allows baud rates of 14400, 28800, 128000 and 256000.

That was my goal.

[import standard disclaimer]

But I took some time to look a little further.  I got custom baud rates 
working enough that someone (perhaps me) can properly fix them in the 
future.  Proof of concept.

As an undocumented bonus, you can toss random baudrates (say 1953), at the 
API and it will set it to something close to that on windows and linux. 
Solaris should say the baud rate is not supported but I have not tested it 
yet.  Mac OS X behavior is unknown at this point.  Just dont expect 
correct behavior at ~8192-9009 baudrates or baudrates less than 20 on 
windows; these baud rates overlap with defines in win32termios.h.  I 
conveniently closed my eyes there.  Try another value close.  On Linux, a 
baud base and divisor are guestimated and set.  On windows, we wave pixie 
dust over the kernel driver and hope.  Do not expect pixie dust and 
guestimates to be the same on windows and linux.  They may well round to 
different values in yet to be tested ways.  There are only so many 
divisors.  If it isn't working, try a little higher or lower.

In the example of 1953 for instance, there is no divisor for commodity 
hardware that comes to that baudrate.  We just come close on one side or 
the other.  If tools tell you they got 1953 exactly, the tools may be 
questionable and just reading values not directly related to the actual 
hardware settings.

These fixes have been tested on Linux and Windows while using an 
oscilloscope to confirm they change relative to known baudrates at 9600, 
14400*, 19200, 28800* (and 1800, 1953** and 2400).

* = previously unsupported.
** = still not supported but probably works from what I saw.

There could be future discussion in this area.  For now this is working 
for almost all unusual baud rate demands.  Cleaning up the custom baud 
rate should be easier with a working starting point.  Baud bases other 
than 128000 have not been characterized.  Yes.. this overlapps with two of 
the baud rates enabled.

Feedback and ideas are welcome.

--
Trent Jarvi
tjarvi at qbang.org
-------------- next part --------------
Index: SerialImp.c
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v
retrieving revision 1.46.2.187
diff -u -r1.46.2.187 SerialImp.c
--- SerialImp.c	29 Jan 2006 22:19:04 -0000	1.46.2.187
+++ SerialImp.c	3 Jun 2006 23:12:40 -0000
@@ -793,6 +793,19 @@
 		result &= ~TIOCM_DTR;
 		ioctl( fd, TIOCMSET, &result );
 	}
+	/*
+	   B38400 is a special case in Linux for custom baud rates.
+
+	   We just treat this as a custom speed for now.  If you take this ifdef
+	   out and select baud rates 38400 then 28800 then 38400, you will get
+	   a final baud rate of 28800 because you did not update the divisor.
+
+	   See the next ifdef below for the divisor.
+	*/
+#if defined(TIOCGSERIAL)
+	if ( cspeed == B38400 )
+		cspeed = 38400;
+#endif /* TIOCGSERIAL */
 	if(     cfsetispeed( &ttyset, cspeed ) < 0 ||
 		cfsetospeed( &ttyset, cspeed ) < 0 )
 	{
@@ -814,6 +827,7 @@
 		*/
 
 #if defined(TIOCGSERIAL)
+		ioctl( fd, TIOCGSERIAL, &sstruct );
 		sstruct.custom_divisor = ( sstruct.baud_base/cspeed );
 		cspeed = B38400;
 #endif /* TIOCGSERIAL */
@@ -827,7 +841,7 @@
 #if defined(TIOCSSERIAL)
 		/*  It is assumed Win32 does this for us */
 		if (	sstruct.baud_base < 1 ||
-			ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
+		ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
 		{
 			return( 1 );
 		}
Index: termios.c
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v
retrieving revision 1.9.2.56
diff -u -r1.9.2.56 termios.c
--- termios.c	16 Jan 2006 02:50:32 -0000	1.9.2.56
+++ termios.c	3 Jun 2006 23:12:40 -0000
@@ -323,8 +323,8 @@
 		case CBR_3500000:	return( B3500000 );
 		case CBR_4000000:	return( B4000000 );
 		default:
-			set_errno(EINVAL );
-			return -1;
+			/* assume custom baudrate */
+			return( Baud );
 	}
 }
 
@@ -361,12 +361,13 @@
 		case B9600:	ret = CBR_9600;		break;
 		case B14400:	ret = CBR_14400;	break;
 		case B19200:	ret = CBR_19200;	break;
+		case B28800:	ret = CBR_28800;	break;
 		case B38400:	ret = CBR_38400;	break;
 		case B57600:	ret = CBR_57600;	break;
 		case B115200:	ret = CBR_115200;	break;
 		case B128000:	ret = CBR_128000;	break;
-		case B256000: 	ret = CBR_256000;	break;
 		case B230400:	ret = CBR_230400;	break;
+		case B256000: 	ret = CBR_256000;	break;
 		case B460800:	ret = CBR_460800;	break;
 		case B500000:	ret = CBR_500000;	break;
 		case B576000:	ret = CBR_576000;	break;
@@ -381,10 +382,8 @@
 		case B4000000:	ret = CBR_4000000;	break;
 	
 		default:
-			fprintf( stderr, "B_to_CBR: invalid baudrate: %#o\n",
-				Baud );
-			set_errno( EINVAL );
-			return -1;
+			/* assume custom baudrate */
+			return Baud;
 	}
 	LEAVE( "B_to_CBR" );
 	return ret;
@@ -708,12 +707,9 @@
 	ENTER( "init_serial_struct" );
 
 	/*
-	FIXME
-
-	This needs to use inb() to read the actual baud_base
-	and divisor from the UART registers.  Question is how
-	far do we take this?
-
+	use of custom_divisor and baud_base requires access to
+	kernel space.  The kernel does try its best if you just
+	toss a baud rate at it though.
 	*/
 
 	sstruct->custom_divisor = 0;
@@ -1678,16 +1674,17 @@
 {
 	char message[80];
 	ENTER( "cfsetospeed" );
+	/* clear baudrate */
+	s_termios->c_cflag &= ~CBAUD;
 	if ( speed & ~CBAUD )
 	{
 		sprintf( message, "cfsetospeed: not speed: %#o\n", speed );
 		report( message );
-		return 0;
+		/* continue assuming its a custom baudrate */
+		s_termios->c_cflag |= B38400;  /* use 38400 during custom */
+		s_termios->c_cflag |= CBAUDEX; /* use CBAUDEX for custom */
 	}
-	s_termios->c_ispeed = s_termios->c_ospeed = speed;
-	/* clear baudrate */
-	s_termios->c_cflag &= ~CBAUD;
-	if( speed )
+	else if( speed )
 	{
 		s_termios->c_cflag |= speed;
 	}
@@ -1696,6 +1693,7 @@
 		/* PC blows up with speed 0 handled in Java */
 		s_termios->c_cflag |= B9600;
 	}
+	s_termios->c_ispeed = s_termios->c_ospeed = speed;
 	LEAVE( "cfsetospeed" );
 	return 1;
 }
@@ -1767,25 +1765,6 @@
 }
 
 /*----------------------------------------------------------
-serial_struct_to_DCB()
-
-   accept:      
-   perform:     
-   return:      
-   exceptions:  
-   win32api:     None
-   comments:    
-----------------------------------------------------------*/
-int serial_struct_to_DCB( struct serial_struct *sstruct, DCB *dcb )
-{
-	/* 5 Baud rate fix
-	sstruct.baud_base
-	sstruct.custom_divisor = ( sstruct.baud_base/cspeed );
-	*/
-	return(0);
-}
-
-/*----------------------------------------------------------
 termios_to_DCB()
 
    accept:      
@@ -1798,7 +1777,8 @@
 int termios_to_DCB( struct termios *s_termios, DCB *dcb )
 {
 	ENTER( "termios_to_DCB" );
-	s_termios->c_ispeed = s_termios->c_ospeed = s_termios->c_cflag & CBAUD;
+	if ( !(s_termios->c_cflag & CBAUDEX) )
+		s_termios->c_ispeed = s_termios->c_ospeed = s_termios->c_cflag & CBAUD;
 	dcb->BaudRate        = B_to_CBR( s_termios->c_ispeed );
 	dcb->ByteSize = termios_to_bytesize( s_termios->c_cflag );
 
@@ -2863,11 +2843,6 @@
 			GetCommState( index->hComm, dcb );
 
 			index->sstruct = va_arg( ap, struct serial_struct * );
-			if ( serial_struct_to_DCB( index->sstruct, dcb ) < 0 )
-			{
-				va_end( ap );
-				return -1;
-			}
 
 			report( "TIOCSSERIAL\n" );
 			free(dcb);
Index: win32termios.h
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v
retrieving revision 1.5.2.28
diff -u -r1.5.2.28 win32termios.h
--- win32termios.h	30 Jun 2005 20:23:26 -0000	1.5.2.28
+++ win32termios.h	3 Jun 2006 23:12:40 -0000
@@ -279,7 +279,7 @@
 #define XTABS	01000000 /* Hmm.. Linux/i386 considers this part of TABDLY.. */
 
 /* c_cflag bit meaning */
-# define CBAUD	0010017
+#define  CBAUD  0030017
 #define  B0	0000000		/* hang up */
 #define  B50	0000001
 #define  B75	0000002
@@ -312,13 +312,16 @@
 #define  B3500000 0010016
 #define  B4000000 0010017
 
-/* glue for unsupported linux speeds see also SerialImp.h */
-/* hosed */
-
-#define B14400		1010001
-#define B28800		1010002
-#define B128000		1010003
-#define B256000		1010004
+/*
+	glue for unsupported linux speeds see also SerialImp.h 
+	custom baud rates around 8192-9000 will not work because
+	of these.
+*/
+
+#define B14400		0020001
+#define B28800		0020002
+#define B128000		0020003
+#define B256000		0020004
 
 #define EXTA B19200
 #define EXTB B38400
@@ -356,8 +359,10 @@
 
 /* glue for unsupported windows speeds */
 
-#define CBR_230400	230400
 #define CBR_28800	28800
+#define CBR_128000	128000
+#define CBR_230400	230400
+#define CBR_256000	256000
 #define CBR_460800	460800
 #define CBR_500000	500000
 #define CBR_576000	576000

From impakt01 at optusnet.com.au  Sat Jun  3 18:30:37 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 10:30:37 +1000
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
In-Reply-To: <Pine.LNX.4.61.0606031715100.10890@www>
Message-ID: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>

Hi Trent,
I'd love to try the patch but I can't get the latest build compiling, only
pre16. 

Can you attach the rxtxSerial.dll file with this patch?

Also, I hardcoded 1953 in a couple more places last night on pre16 and it
managed to open the port at the right speed, but stopped receiving anything
after 100-150 bytes, even though more data was getting sent to the port.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 10:15 AM
To: rxtx at qbang.org
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.


The attached patch allows baud rates of 14400, 28800, 128000 and 256000.

That was my goal.

[import standard disclaimer]

But I took some time to look a little further.  I got custom baud rates 
working enough that someone (perhaps me) can properly fix them in the 
future.  Proof of concept.

As an undocumented bonus, you can toss random baudrates (say 1953), at the 
API and it will set it to something close to that on windows and linux. 
Solaris should say the baud rate is not supported but I have not tested it 
yet.  Mac OS X behavior is unknown at this point.  Just dont expect 
correct behavior at ~8192-9009 baudrates or baudrates less than 20 on 
windows; these baud rates overlap with defines in win32termios.h.  I 
conveniently closed my eyes there.  Try another value close.  On Linux, a 
baud base and divisor are guestimated and set.  On windows, we wave pixie 
dust over the kernel driver and hope.  Do not expect pixie dust and 
guestimates to be the same on windows and linux.  They may well round to 
different values in yet to be tested ways.  There are only so many 
divisors.  If it isn't working, try a little higher or lower.

In the example of 1953 for instance, there is no divisor for commodity 
hardware that comes to that baudrate.  We just come close on one side or 
the other.  If tools tell you they got 1953 exactly, the tools may be 
questionable and just reading values not directly related to the actual 
hardware settings.

These fixes have been tested on Linux and Windows while using an 
oscilloscope to confirm they change relative to known baudrates at 9600, 
14400*, 19200, 28800* (and 1800, 1953** and 2400).

* = previously unsupported.
** = still not supported but probably works from what I saw.

There could be future discussion in this area.  For now this is working 
for almost all unusual baud rate demands.  Cleaning up the custom baud 
rate should be easier with a working starting point.  Baud bases other 
than 128000 have not been characterized.  Yes.. this overlapps with two of 
the baud rates enabled.

Feedback and ideas are welcome.

--
Trent Jarvi
tjarvi at qbang.org



From tjarvi at qbang.org  Sat Jun  3 19:05:11 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 19:05:11 -0600 (MDT)
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
In-Reply-To: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>
References: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606031840400.10890@www>

On Sun, 4 Jun 2006, Daren wrote:

> Hi Trent,
> I'd love to try the patch but I can't get the latest build compiling, only
> pre16.
>
> Can you attach the rxtxSerial.dll file with this patch?
>
> Also, I hardcoded 1953 in a couple more places last night on pre16 and it
> managed to open the port at the right speed, but stopped receiving anything
> after 100-150 bytes, even though more data was getting sent to the port.
>


ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing

I dont think they will hang.  But I was just testing via loopback/break 
out box/scope.

I'll be putting about 10 patches and another set of binaries in that 
directory shortly.  For now the binaries should just have the baud_rate 
fix.

I'll announce all the patches at once.  but wont be releasing 2.1-8 right 
away.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Sat Jun  3 21:00:01 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 21:00:01 -0600 (MDT)
Subject: [Rxtx] CVS for 2.1 should have everything
Message-ID: <Pine.LNX.4.61.0606032056190.10890@www>


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org


From impakt01 at optusnet.com.au  Sat Jun  3 21:08:14 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 13:08:14 +1000
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <Pine.LNX.4.61.0606032056190.10890@www>
Message-ID: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>

Hi Trent,
I tried the latest dll and it opens the port, receives 100-200 bytes and
then stops receiving anything else..

I'll keep playing with it.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 1:00 PM
To: rxtx at qbang.org
Subject: [Rxtx] CVS for 2.1 should have everything


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From impakt01 at optusnet.com.au  Sat Jun  3 21:22:41 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 13:22:41 +1000
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
Message-ID: <200606040322.k543MqW1008455@mail12.syd.optusnet.com.au>

Played with it, problem, with a while loop in my code, working great now

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Daren
Sent: Sunday, 4 June 2006 1:08 PM
To: 'RXTX Developers and Users'
Subject: Re: [Rxtx] CVS for 2.1 should have everything

Hi Trent,
I tried the latest dll and it opens the port, receives 100-200 bytes and
then stops receiving anything else..

I'll keep playing with it.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 1:00 PM
To: rxtx at qbang.org
Subject: [Rxtx] CVS for 2.1 should have everything


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Sat Jun  3 21:35:41 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 21:35:41 -0600 (MDT)
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
References: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606032131140.10890@www>

On Sun, 4 Jun 2006, Daren wrote:

> Hi Trent,
> I tried the latest dll and it opens the port, receives 100-200 bytes and
> then stops receiving anything else..
>
> I'll keep playing with it.
>
> Daren

The difference may be that I'm talking to something at the exact same baud 
rate (loopback).

You may also try setting the baudrate to ~1933 and ~1973 to force the 
guesses one way or the other.  If you are on windows, we are not doing 
anything fancy in the end.  Thats the kernel guessing.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sun Jun  4 04:12:09 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sun, 4 Jun 2006 12:12:09 +0200
Subject: [Rxtx] Update of OSX installer, Readme, etc
Message-ID: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>

Good day,

after the latest changes a lot of OS X specific files should be  
updated. Especially the installer!

- The "MaxOSX" readme file on the root level is outdated (ie  
CodeWarrior information). Maybe we could even rename it to README.OSX  
to be in line with README.IPAQ, README.SCO (Trent do you mind copying/ 
renaming ,v files in the repository?).

- The lock files are no longer used and hence the user group magic  
and lock folder creation should be removed from the installer.

- MACOSX_IDE/ForPackageMaker/Resources/ReadMe.rtf and Welcome.rtf  
need to be updated.

- I suggest to replace the current installation instruction for OS X:  
Installation should occur into the application directory, not in the  
Java-VM directory. This simplifies things a lot, as the Mac Installer  
can be removed completely.

- The xcodeproject's build settings need to be updated to generate  
JAVA 1.1 format class files.


Dimitry: do you have time to tackle this? I could do it, but as this  
is "your baby" I thought you may prefer to do it yourself.

Regards,
Joachim



From dmarkman at mac.com  Sun Jun  4 11:27:53 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Sun, 4 Jun 2006 13:27:53 -0400
Subject: [Rxtx] Update of OSX installer, Readme, etc
In-Reply-To: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
References: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
Message-ID: <26E7A202-962B-4C19-93B6-29426C467249@mac.com>

Joachim,
unfortunately I don't have time right now to do that
so if you can do that, please do

it's not only my baby
it's yours too :-)

thanks


On Jun 4, 2006, at 6:12 AM, Joachim Buechse wrote:

> Good day,
>
> after the latest changes a lot of OS X specific files should be
> updated. Especially the installer!
>
> - The "MaxOSX" readme file on the root level is outdated (ie
> CodeWarrior information). Maybe we could even rename it to README.OSX
> to be in line with README.IPAQ, README.SCO (Trent do you mind copying/
> renaming ,v files in the repository?).
>
> - The lock files are no longer used and hence the user group magic
> and lock folder creation should be removed from the installer.
>
> - MACOSX_IDE/ForPackageMaker/Resources/ReadMe.rtf and Welcome.rtf
> need to be updated.
>
> - I suggest to replace the current installation instruction for OS X:
> Installation should occur into the application directory, not in the
> Java-VM directory. This simplifies things a lot, as the Mac Installer
> can be removed completely.
>
> - The xcodeproject's build settings need to be updated to generate
> JAVA 1.1 format class files.
>
>
> Dimitry: do you have time to tackle this? I could do it, but as this
> is "your baby" I thought you may prefer to do it yourself.
>
> Regards,
> Joachim
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman



From tjarvi at qbang.org  Sun Jun  4 13:54:02 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 4 Jun 2006 13:54:02 -0600 (MDT)
Subject: [Rxtx] Update of OSX installer, Readme, etc
In-Reply-To: <26E7A202-962B-4C19-93B6-29426C467249@mac.com>
References: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
	<26E7A202-962B-4C19-93B6-29426C467249@mac.com>
Message-ID: <Pine.LNX.4.61.0606041353040.22522@www>

On Sun, 4 Jun 2006, Dmitry Markman wrote:

> Joachim,
> unfortunately I don't have time right now to do that
> so if you can do that, please do
>
> it's not only my baby
> it's yours too :-)
>

I've given Joachim cvs access.  He has shown good work in bugzilla.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Mon Jun  5 10:08:32 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 5 Jun 2006 18:08:32 +0200
Subject: [Rxtx] Build process changes for Mac OS X
Message-ID: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>

Good day,

I have cleaned up some outdated Mac OSX specific build files in the  
repository.

There was not a lot left of the readme file "MacOSX" after cleaning  
it up, so I decided to rename it README.OSX to be in harmony with the  
other files in the directory (ie README.IPAQ, README.SCO, ...)

I added an (uncompressed) XCode 2.3 project file/structure  
with .cvsignore files that will ignore the user specific settings.  
This should work "out of the box" for OSX10.4. Users of 10.2/10.3 may  
have to switch the build settings.

[It's kind of tricky to choose "the right" setting. Afaik there is no  
way to compile a universal binary that will work on 10.3 or before.  
So it's either UniversalBinary OR Legacy. Maybe we should have  
different build targets for these different targets?? I would like to  
get some feedback from the Mac developers on this list regarding the  
subject].

Besides other things the OSX installer is no longer required. Since  
the next version (2.1.8) will no longer use lockfiles on OSX, the  
group/permission magic is no longer required and hence there remains  
basicly no work for the installer - other than copying 2 files to the  
VM extension directory. Then again, this is not the best way to  
install RXTX. So I removed the installer completely without modifying  
it, this should simplify a "resurrection" should it ever get necessary.

I had problems with the (compressed, ie sit.hqx) legacy project files  
on the latest installation of OSX (javac 1.5 creating non JDK1.1  
class files and some minor problems). To reduce potential confusion  
for newcomers I decided to remove them. This means that there is no  
longer a simple way to build RXTX for OSX 10.0 and 10.1 (I deeply  
apologize if anyone still relied on this ... well the files are in  
the Attiq).

Best regards,
Joachim


From joachim at buechse.de  Mon Jun  5 10:16:37 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 5 Jun 2006 18:16:37 +0200
Subject: [Rxtx] RXTX and lockfiles on OSX [it is fixed now]
Message-ID: <7D2C4418-9397-4B59-8091-9FDE4ED67836@buechse.de>

Quite a number of people contacted me in the last couple of weeks  
because of problems installing RXTX on OSX. I told you to wait for  
the "official" fix. Well, it has been fixed.

So if you were among the people waiting for the solution, you can now  
download the source rxtx-2.1-7r2.zip from the website. Once unpacked  
dont forget to use "cvs up" to update the files to the latest  
version. You can then open MACOSX_IDE/XCode/ 
LibSerialUniversal.xcodeproj with XCode 2.3 and build the libraries  
that no longer try to create lock files.

Regards,
Joachim


From brian at mbari.org  Mon Jun  5 10:52:43 2006
From: brian at mbari.org (Brian Schlining)
Date: Mon, 5 Jun 2006 09:52:43 -0700
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
Message-ID: <78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>

Hi Joachim,

> [It's kind of tricky to choose "the right" setting. Afaik there is no
> way to compile a universal binary that will work on 10.3 or before.
> So it's either UniversalBinary OR Legacy. Maybe we should have
> different build targets for these different targets?? I would like to
> get some feedback from the Mac developers on this list regarding the
> subject].

I imagine most developers will be compiling on 10.4 (It's the nature  
of the coder...gotta have the latest and greatest) and deploying to  
both 10.3 and 10.4; both of which will run Universal Binaries (see  
http://forums.macrumors.com/showthread.php?t=205348). So it sounds  
like you've covered the majority of users. Still, you know someone's  
going to pipe up about needing RXTX on 10.2 so it would be nice to  
have a target to make a PPC only build.

Just my 2 cents

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/1cac8c39/attachment-0008.html

From dmarkman at mac.com  Mon Jun  5 13:47:50 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Mon, 5 Jun 2006 15:47:50 -0400
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
Message-ID: <686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>

I don't think it will be a problem to run universal binary
on 10.2
however if binary has some calls that aren't implemented in 10.2
then you'll have a problem


On Jun 5, 2006, at 12:52 PM, Brian Schlining wrote:

> Hi Joachim,
>
>> [It's kind of tricky to choose "the right" setting. Afaik there is no
>> way to compile a universal binary that will work on 10.3 or before.
>> So it's either UniversalBinary OR Legacy. Maybe we should have
>> different build targets for these different targets?? I would like to
>> get some feedback from the Mac developers on this list regarding the
>> subject].
>
> I imagine most developers will be compiling on 10.4 (It's the  
> nature of the coder...gotta have the latest and greatest) and  
> deploying to both 10.3 and 10.4; both of which will run Universal  
> Binaries (see http://forums.macrumors.com/showthread.php?t=205348).  
> So it sounds like you've covered the majority of users. Still, you  
> know someone's going to pipe up about needing RXTX on 10.2 so it  
> would be nice to have a target to make a PPC only build.
>
> Just my 2 cents
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/9fafc878/attachment-0008.html

From brian at mbari.org  Mon Jun  5 14:52:41 2006
From: brian at mbari.org (Brian Schlining)
Date: Mon, 5 Jun 2006 13:52:41 -0700
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
Message-ID: <E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>

Hi Dmitry,

> I don't think it will be a problem to run universal binary
> on 10.2
> however if binary has some calls that aren't implemented in 10.2
> then you'll have a problem

You're right...I stand corrected.

Note however, to deploy a universal binary to 10.2 RXTX will need to  
use the 10.2 SDK to build the PPC side. (see http:// 
developer.apple.com/documentation/DeveloperTools/Conceptual/ 
cross_development/UniversalBinaries/chapter_4_section_1.html). I  
haven't been paying close attention to the new locking mechanism used  
by RXTX on the Mac...does 10.2 support it?

Joachim, which SDK will you be using by default for building the Mac  
PPC binaries?

>> Hi Joachim,
>>
>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>> is no
>>> way to compile a universal binary that will work on 10.3 or before.
>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>> different build targets for these different targets?? I would  
>>> like to
>>> get some feedback from the Mac developers on this list regarding the
>>> subject].
>>
>> I imagine most developers will be compiling on 10.4 (It's the  
>> nature of the coder...gotta have the latest and greatest) and  
>> deploying to both 10.3 and 10.4; both of which will run Universal  
>> Binaries (see http://forums.macrumors.com/showthread.php? 
>> t=205348). So it sounds like you've covered the majority of users.  
>> Still, you know someone's going to pipe up about needing RXTX on  
>> 10.2 so it would be nice to have a target to make a PPC only build.

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/153bf50e/attachment-0008.html

From dmarkman at mac.com  Mon Jun  5 19:02:04 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Mon, 5 Jun 2006 21:02:04 -0400
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
Message-ID: <7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>

if Joachim didn't change xcode project setting

/Developer/SDKs/MacOSX10.4u.sdk is used to build universal binary

so it's quite possible that it won't run properly on 10.2

so we have to change the building process, so ppc part will be built
with
/Developer/SDKs/MacOSX10.2.8.sdk

and finally to use lipo utility to build universal binaries

Joachim, did you use some specific locking API that wasn't implemented

in MacOSX10.2.8.sdk?

thanks


On Jun 5, 2006, at 4:52 PM, Brian Schlining wrote:

> Hi Dmitry,
>
>> I don't think it will be a problem to run universal binary
>> on 10.2
>> however if binary has some calls that aren't implemented in 10.2
>> then you'll have a problem
>
> You're right...I stand corrected.
>
> Note however, to deploy a universal binary to 10.2 RXTX will need  
> to use the 10.2 SDK to build the PPC side. (see http:// 
> developer.apple.com/documentation/DeveloperTools/Conceptual/ 
> cross_development/UniversalBinaries/chapter_4_section_1.html). I  
> haven't been paying close attention to the new locking mechanism  
> used by RXTX on the Mac...does 10.2 support it?
>
> Joachim, which SDK will you be using by default for building the  
> Mac PPC binaries?
>
>>> Hi Joachim,
>>>
>>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>>> is no
>>>> way to compile a universal binary that will work on 10.3 or before.
>>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>>> different build targets for these different targets?? I would  
>>>> like to
>>>> get some feedback from the Mac developers on this list regarding  
>>>> the
>>>> subject].
>>>
>>> I imagine most developers will be compiling on 10.4 (It's the  
>>> nature of the coder...gotta have the latest and greatest) and  
>>> deploying to both 10.3 and 10.4; both of which will run Universal  
>>> Binaries (see http://forums.macrumors.com/showthread.php? 
>>> t=205348). So it sounds like you've covered the majority of  
>>> users. Still, you know someone's going to pipe up about needing  
>>> RXTX on 10.2 so it would be nice to have a target to make a PPC  
>>> only build.
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/84790f80/attachment-0008.html

From joachim at buechse.de  Tue Jun  6 02:40:47 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 6 Jun 2006 10:40:47 +0200
Subject: [Rxtx] Building on OS X, Impl Changes
In-Reply-To: <7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
Message-ID: <CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>

Good day!

What's in the XCode project setting?
----------

The xcode project remained pretty much the same as before. I excluded  
the user specific files from CVS and changed some settings. I kept  
all the built targets (you shouldn't change what you don't understand;-)

Currently we the following build targets:
    RXTXComm (java files)
    librxtxParallel.jnilib (usefull on the Mac???)
    libI2C.jnilib (not yet working in RXTX)
    libRS485.jnilib (not yet working in RXTX)
    librxtxSerial.jnilib (1)
    librxtxSerial.jnilib Dynamic (2)
    rxtxSerial (3)
We also have the following build configurations for each target:
    Development
    Default
    Deployment

What was changed in the xcode project from previous versions:
- java.souce=1.3 and java.target=1.1 in RXTXComm settings
- removed copying of build products into installer directory
- removed "(Upgraded)" from build target names

What remains to be changed:
- choosing a "non-debug" Build-configuration as default
- potentially removing "Default"/"Development" Build-configurations
- reducing the number of build targets
- creating 10.2 compatible universal binaries

I suggest, that the build configurations should be reduced to 2  
(Debug/Deployment), possibly even 1 (Debug).
I have not yet found the deeper meaning of the build targets(1)(2) 
(3), it seems to me like they should be reduced into one "doing the  
right thing" or maybe into two "rxtxSerial.jnilib Legacy" (back to  
10.2, universal if possible) and "rxtxSerial.jnilib 10.4 
+" (universal, 10.4+).

Should the code work on 10.2?
----------

Absolutely. The code should work on NextStep, in fact on any BSD  
unix. I would go as far as saying, this code should work on any  
POSSIX based unix. All that was added is the call "ioctl(fd,  
TIOCEXCL)" to request excusivity of the port:

http://gemma.apple.com/documentation/DeviceDrivers/Conceptual/ 
WorkingWSerial/WWSerial_SerialDevs/chapter_2_section_8.html

It is not yet "the perfect solution". Normally an open /dev/tty  
(listen for incomming connection) should be "preemptable" by opening  
a /dev/cu (outgoing connection) for the same port. This is not yet  
implemented as it needs calls outside of POSSIX on OSX.

On "classic" systems (like NextStep) this worked based on the  
"carried detect line". open() on /dev/tty.xxx would block until the  
carrier detect signal was raised. As the device was not "opened"  
opening /dev/cu.xxx worked without a hitch. When they ported to the  
Mac this broke. On Macs the "carier detect" is usually not wired.  
Furthermore FAX modems did no longer raise the line. So the OSX  
implementor defined a new call, which is documented here:

http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00045.html

Best regards,
Joachim




On 06.06.2006, at 03:02, Dmitry Markman wrote:

> if Joachim didn't change xcode project setting
>
> /Developer/SDKs/MacOSX10.4u.sdk is used to build universal binary
>
> so it's quite possible that it won't run properly on 10.2
>
> so we have to change the building process, so ppc part will be built
> with
> /Developer/SDKs/MacOSX10.2.8.sdk
>
> and finally to use lipo utility to build universal binaries
>
> Joachim, did you use some specific locking API that wasn't implemented
>
> in MacOSX10.2.8.sdk?
>
> thanks
>
>
> On Jun 5, 2006, at 4:52 PM, Brian Schlining wrote:
>
>> Hi Dmitry,
>>
>>> I don't think it will be a problem to run universal binary
>>> on 10.2
>>> however if binary has some calls that aren't implemented in 10.2
>>> then you'll have a problem
>>
>> You're right...I stand corrected.
>>
>> Note however, to deploy a universal binary to 10.2 RXTX will need  
>> to use the 10.2 SDK to build the PPC side. (see http:// 
>> developer.apple.com/documentation/DeveloperTools/Conceptual/ 
>> cross_development/UniversalBinaries/chapter_4_section_1.html). I  
>> haven't been paying close attention to the new locking mechanism  
>> used by RXTX on the Mac...does 10.2 support it?
>>
>> Joachim, which SDK will you be using by default for building the  
>> Mac PPC binaries?
>>
>>>> Hi Joachim,
>>>>
>>>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>>>> is no
>>>>> way to compile a universal binary that will work on 10.3 or  
>>>>> before.
>>>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>>>> different build targets for these different targets?? I would  
>>>>> like to
>>>>> get some feedback from the Mac developers on this list  
>>>>> regarding the
>>>>> subject].
>>>>
>>>> I imagine most developers will be compiling on 10.4 (It's the  
>>>> nature of the coder...gotta have the latest and greatest) and  
>>>> deploying to both 10.3 and 10.4; both of which will run  
>>>> Universal Binaries (see http://forums.macrumors.com/ 
>>>> showthread.php?t=205348). So it sounds like you've covered the  
>>>> majority of users. Still, you know someone's going to pipe up  
>>>> about needing RXTX on 10.2 so it would be nice to have a target  
>>>> to make a PPC only build.
>>
>> Brian Schlining
>> Software Engineer
>> http://www.mbari.org
>>
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> Dmitry Markman
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Tue Jun  6 07:01:06 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 6 Jun 2006 15:01:06 +0200
Subject: [Rxtx] Serial port code for OS X, future steps
In-Reply-To: <CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
	<CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
Message-ID: <8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>

I posted the "wrong link". There is a correction here:

    http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00059.html

In fact, the 2.1.7 implementation of RXTX has quite some deficiencies  
on OSX. I have tried to supply some patches that don't interfere to  
much with the existing RXTX code base, but there are limits to what  
can be done with local patches.

There are some very intrusive changes that should be done. Ie proper  
mapping of /dev/tty <-> /dev/cu handling to correct behaviour of  
CommPortOwnershipListener (http://java.sun.com/products/javacomm/ 
reference/api/index.html). I dont think this can be done with  
patches. Hence I think, RXTX should be rewritten from scratch de- 
unifying the native code base (and implementing thread safe code on  
the Java side).


How "should" /dev/tty vs /dev/cu be implemented?

=====
The Unix contract is this: An open /dev/tty.xxx port (incomming)  
should be interrupted/auto-closed when opening /dev/cu.xxx (outgoing)  
[if /dev/tty.xxx is not currently handling a communication].  /dev/ 
cu.xxx and /dev/tty.xxx refer to the same device, so owning  
"exclusively" should block both. This should be respected across all  
applications native or Java.

This contract is realizable on OSX with the existing javax.comm  
interface while also respecting (to the biggest part) the contract  
defined by javax.comm.PortOwnershipListener.

The one point where the suggested implementation "breaks" the  
javax.comm contract, is by the fact that one can loose a /dev/tty  
port without calling close. However, the only option I see is to  
always open serial ports "non-exclusively" which would outrule Java  
as a platform for (dormant) applications waiting for incoming  
connections/faxes/etc. There could be a system property to choose the  
intended behavior.
=====

Here is how it could be done on OSX:

Calling port=ComportIdentifier.open("/dev/cu.xxx") opens and owns the  
port exclusively until port.close() is called.
- Java applications listening with a PortOwnershipListener should get  
a PORT_OWNED event reasonably soon.
- Any further attempt by a Java or native application to open "/dev/ 
cu.xxx" or "/dev/tty.xxx" fails.
- /dev/cu.xxx is for "outgoing" connections, so receiving  
PORT_OWNERSHIP_REQUESTED makes little to no sense. With native  
applications it can not be implemented. For Java applications it  
could be implemented (by a hidden communication channel). I think  
it's not worth bothering. If anyone is willing to give up a port to  
others he should use /dev/tty.xxx instead of /dev/cu.xxx.

Registering a PortOwnershipListener on "/dev/cu.xxx" without opening  
it, uses /dev/tty.xxx (native open()) non-exclusively and polls its  
state. PORT_OWNED and PORT_UNOWNED can be produced.

Calling port=ComportIdentifier.open("/dev/tty.xxx") should open the  
port non-exclusively.
- Adding a SerialPortEventListener and reading from the port could be  
allowed while keeping it non-exclusive.
- When port.getOutputStream() is called, the state should be changed  
to an "exclusive" ownership. This may be configurable via a system  
property.
- To return to the non-exclusive state the port must be closed and  
reopened.
- While non-exclusively opened, opening the corresponding /dev/cu.xxx  
produces a PORT_OWNERSHIP_REQUESTED event. Which should be responded  
by closing the port from within the callback (as described in  
java.comm.PortOwnershipListener). If there is a pending read, it will  
return after the listener finishes (with -1 or "0 bytes read").
- Calling write() on the /dev/tty.xxx after somebody opened /dev/ 
cu.xxx will fail with a descriptive IOException.
- Calling read() on the /dev/tty.xxx after somebody opened /dev/ 
cu.xxx will fail with a descriptive IOException (or potentially  
block, see side notes below).

CommPortIdentifier.getCurrentOwner() can be implemented by an  
external call to lsof.

CommPortIdentifier.isCurrentlyOwned() can be implemented by trying an  
open on the /dev/tty.
- It returns true if the port is currently held "exclusively".
- Whether it should also return true on /dev/tty if /dev/tty is  
already opened non-exclusively might be a system property option. In  
general, having several applications waiting for incoming connections  
on the same port will require an application level "arbitration"  
protocol...

[[side note1: One interesting question is, what happens if the  
process holding /dev/tty non-exclusively ignores  
PORT_OWNERSHIP_REQUESTED. Ie after "loosing" a non-exclusively opened  
"dev/tty.xxx" port to another process. One possible implementation  
is, that the port is "regained" when the other process gives up the  
port. This would mean that in the meanwhile read() returns no data,  
and any changes to the configuration of the port are stored but not  
forwarded. I guess, the safe (and simple) way to do this is to make  
the close() mandatory (ie setting the port into an "awaiting_close"  
state which produces IOExceptions to any other call than close). ]]

[[side note2:  Another interesting question is, what should happen if  
several applications open the same /dev/tty.xxx port "non- 
exclusively" and start to change the settings of the device.]]

Regards,
Joachim



On 06.06.2006, at 10:40, Joachim Buechse wrote:

> Should the code work on 10.2?
> ----------
>
> Absolutely. The code should work on NextStep, in fact on any BSD
> unix. I would go as far as saying, this code should work on any
> POSSIX based unix. All that was added is the call "ioctl(fd,
> TIOCEXCL)" to request excusivity of the port:
>
> http://gemma.apple.com/documentation/DeviceDrivers/Conceptual/
> WorkingWSerial/WWSerial_SerialDevs/chapter_2_section_8.html
>
> It is not yet "the perfect solution". Normally an open /dev/tty
> (listen for incomming connection) should be "preemptable" by opening
> a /dev/cu (outgoing connection) for the same port. This is not yet
> implemented as it needs calls outside of POSSIX on OSX.
>
> On "classic" systems (like NextStep) this worked based on the
> "carried detect line". open() on /dev/tty.xxx would block until the
> carrier detect signal was raised. As the device was not "opened"
> opening /dev/cu.xxx worked without a hitch. When they ported to the
> Mac this broke. On Macs the "carier detect" is usually not wired.
> Furthermore FAX modems did no longer raise the line. So the OSX
> implementor defined a new call, which is documented here:
>
> http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00045.html
>
> Best regards,
> Joachim



From sds at dcs.gla.ac.uk  Tue Jun  6 11:22:45 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Tue, 06 Jun 2006 18:22:45 +0100
Subject: [Rxtx] Correct compile flag for HP iPAQ hx4700 running Familiar
	Linux?
Message-ID: <1149614565.19496.10.camel@addu>

Hi,

I'd like to use RXTX 2.1 on my HP iPAQ hx4700. The iPAQ is running
Familiar Linux 0.8.2 (as I recall), with Blackdown Java 1.3.1.

I can compile and run a test program which uses RXTX on my i686 machine,
and it works fine. But I can't seem to get things working quite right on
my PDA.

I compile the code on the laptop with the following commands:
	./configure --host=arm-gnu-linux && make
... as suggested in a post to this list, albeit some time ago. This
compiles, I transfer the files, set up LD_LIBRARY_PATH and CLASSPATH
variables, and get the following error on the PDA:

sds at ipaq-pxa-2:~# java Test
java.lang.UnsatisfiedLinkError: /usr/local/lib/ext/librxtxSerial.so: /usr/local/lib/ext/librxtxSerial.so: cannot open shared object file: No such file or directory thrown while loading gnu.io.RXTXCommDriver
Exception in thread "main"
java.lang.UnsatisfiedLinkError: /usr/local/lib/ext/librxtxSerial.so: /usr/local/lib/ext/librxtxSerial.so: cannot open shared object file: No such file or directory
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1382)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1290)
        at java.lang.Runtime.loadLibrary0(Runtime.java:749)
        at java.lang.System.loadLibrary(System.java:820)
        at
gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:83)
        at Test.<init>(Test.java:9)
        at Test.main(Test.java:32)
sds at ipaq-pxa-2:~# 

Note that I'm copying the files to /usr/local/lib/ext/ along with the
RXTXcomm.jar file, purely to keep things separate from the rest of the
system while testing. The location of the .so files doesn't seem to have
any bearing on whether "java Test" will succeed or not. The contents of
this directory are:

sds at ipaq-pxa-2:~$ ls /usr/local/lib/ext/
RXTXcomm.jar              librxtxParallel-2.1-7.so  librxtxRS485.so
librxtxSerial-2.1-7.so
librxtxI2C-2.1-7.so       librxtxParallel.so        librxtxRaw-2.1-7.so
librxtxSerial.so
librxtxI2C.so             librxtxRS485-2.1-7.so     librxtxRaw.so
sds at ipaq-pxa-2:~$

Test.java fails on the first real line of code I'm using to test that
things are working, prior to real development, and was carefully pinched
from the web:
Enumeration portIdentifiers = CommPortIdentifier.getPortIdentifiers();


I assume that I've gotten my --host flag wrong way back up there at
the ./configure step. But if that's the case, what should I set it to?
Or am I missing something more obvious?


Cheers,
Stephen Strowes,
University of Glasgow.




From tjarvi at qbang.org  Tue Jun  6 13:39:41 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 6 Jun 2006 13:39:41 -0600 (MDT)
Subject: [Rxtx] Serial port code for OS X, future steps
In-Reply-To: <8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
	<CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
	<8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>
Message-ID: <Pine.LNX.4.61.0606061315070.9856@www>


>>
There are some very intrusive changes that should be done. Ie proper
mapping of /dev/tty <-> /dev/cu handling to correct behaviour of
CommPortOwnershipListener (http://java.sun.com/products/javacomm/
reference/api/index.html). I dont think this can be done with
patches. Hence I think, RXTX should be rewritten from scratch de-
unifying the native code base (and implementing thread safe code on
the Java side).
<<

This appears to be a very small amount of functionality for a total 
rewrite.  The port ownership only needs maybe 3 native calls if it is done 
with native calls at all.

Those features which are not part of the Unix standard(s) can be special 
cased.  I'm not sure /dev/cu is standard.  We can look.  I know linux 
deprecated /dev/cua years ago.

Thread safe Java code is not a platform specific issue.

--
Trent Jarvi
tjarvi at qbang.org


From sds at dcs.gla.ac.uk  Wed Jun  7 12:36:43 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Wed, 07 Jun 2006 19:36:43 +0100
Subject: [Rxtx] Expected RXTX behaviour?
In-Reply-To: <1149703900.30891.19.camel@addu>
References: <1149703900.30891.19.camel@addu>
Message-ID: <1149705403.30891.25.camel@addu>

Apologies, caught the problem. Had to append '\r' to the end of the AT
string. A non obvious but stupid mistake... :-)

Final quick question though: How might I stop the echoing of
outputStream data back into the inputStream? I still see the ATI
commands on the inputStream, along with the output from the device.


Cheers,
S.



On Wed, 2006-06-07 at 19:11 +0100, Stephen Strowes wrote:
> Hi,
> 
> I managed to get RXTX to compile for my iPAQ following my previous post
> to this list. Quick query though:
> 
> I want to be able to issue AT commands to a device, and interpret the
> responses. For this, I assume I do the following, in psuedo-form:
> 
> 	CommPortIdentifier.getPortIdentifiers();
> 	// find the correct device id
> 	serialPort= (SerialPort)portID.open("Test");
> 	// Set parameters and flow control
> 	outputStream= serialPort.getOutputStream();
> 	inputStream=  serialPort.getInputStream();
> 
> ... following this, I spawn a thread to respond to DATA_AVAILABLE events
> on serialPort with inputStream, and occasionally write and flush an
> "ATI" onto the outputStream. Nothing complex, I just want to see it
> work.
> 
> I would have expected inputStream to give the same information back from
> an "ATI" command as minicom provides, but instead inputStream only sees
> the "ATI" I put onto the outputStream.
> 
> Have I missed something?
> 
> 
> Cheers,
> S.
> 



From sds at dcs.gla.ac.uk  Wed Jun  7 12:11:40 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Wed, 07 Jun 2006 19:11:40 +0100
Subject: [Rxtx] Expected RXTX behaviour?
Message-ID: <1149703900.30891.19.camel@addu>

Hi,

I managed to get RXTX to compile for my iPAQ following my previous post
to this list. Quick query though:

I want to be able to issue AT commands to a device, and interpret the
responses. For this, I assume I do the following, in psuedo-form:

	CommPortIdentifier.getPortIdentifiers();
	// find the correct device id
	serialPort= (SerialPort)portID.open("Test");
	// Set parameters and flow control
	outputStream= serialPort.getOutputStream();
	inputStream=  serialPort.getInputStream();

... following this, I spawn a thread to respond to DATA_AVAILABLE events
on serialPort with inputStream, and occasionally write and flush an
"ATI" onto the outputStream. Nothing complex, I just want to see it
work.

I would have expected inputStream to give the same information back from
an "ATI" command as minicom provides, but instead inputStream only sees
the "ATI" I put onto the outputStream.

Have I missed something?


Cheers,
S.




From joachim at buechse.de  Wed Jun  7 09:02:13 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 7 Jun 2006 17:02:13 +0200
Subject: [Rxtx] Update of build process for OSX (XCode project)
Message-ID: <62EC47B1-46BD-4ECA-B9EC-C4061D147CDA@buechse.de>

With the help of Dmitry Markman and Brian Schilling I have updated  
(and largely simplifed) the XCode project file for Mac OS X.

Changes:
- compiles a universal binary library with intel=OSX10.4+, ppc=OSX10.2 
+ support
- compiles the Java sources into a JRE1.1 compatible, compressed jar.

Please test on your configuration, especially if you have computers  
running 10.2/10.3 or intel.

Best regards,
Joachim


From joachim at buechse.de  Wed Jun  7 14:36:37 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 7 Jun 2006 22:36:37 +0200
Subject: [Rxtx] Expected RXTX behaviour?
In-Reply-To: <1149705403.30891.25.camel@addu>
References: <1149703900.30891.19.camel@addu> <1149705403.30891.25.camel@addu>
Message-ID: <D3AD6EAF-27BB-455E-9697-86C1121920C3@buechse.de>

Echoing is a feature of the modem. Try ATE0 which works with most  
"rockwell" compatible modems.

Regards,
Joachim


On 07.06.2006, at 20:36, Stephen Strowes wrote:

> Apologies, caught the problem. Had to append '\r' to the end of the AT
> string. A non obvious but stupid mistake... :-)
>
> Final quick question though: How might I stop the echoing of
> outputStream data back into the inputStream? I still see the ATI
> commands on the inputStream, along with the output from the device.
>
>
> Cheers,
> S.
>
>
>
> On Wed, 2006-06-07 at 19:11 +0100, Stephen Strowes wrote:
>> Hi,
>>
>> I managed to get RXTX to compile for my iPAQ following my previous  
>> post
>> to this list. Quick query though:
>>
>> I want to be able to issue AT commands to a device, and interpret the
>> responses. For this, I assume I do the following, in psuedo-form:
>>
>> 	CommPortIdentifier.getPortIdentifiers();
>> 	// find the correct device id
>> 	serialPort= (SerialPort)portID.open("Test");
>> 	// Set parameters and flow control
>> 	outputStream= serialPort.getOutputStream();
>> 	inputStream=  serialPort.getInputStream();
>>
>> ... following this, I spawn a thread to respond to DATA_AVAILABLE  
>> events
>> on serialPort with inputStream, and occasionally write and flush an
>> "ATI" onto the outputStream. Nothing complex, I just want to see it
>> work.
>>
>> I would have expected inputStream to give the same information  
>> back from
>> an "ATI" command as minicom provides, but instead inputStream only  
>> sees
>> the "ATI" I put onto the outputStream.
>>
>> Have I missed something?
>>
>>
>> Cheers,
>> S.
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From g_petrini at yahoo.it  Thu Jun  8 01:41:58 2006
From: g_petrini at yahoo.it (Giacomo Petrini)
Date: Thu, 8 Jun 2006 09:41:58 +0200 (CEST)
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from FieldTalk
Message-ID: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>

Hi,
I'm evaluating the library for the modbus protocol
from FieldTalk
(http://www.modbusdriver.com/fieldtalk/.
I'm using J2SE 5.0 and RXTX 2.1 on win XP.
The problem is that the modbus lib has a method (the
openProtocol method, but maybe there are others) tha
throws the
javax.comm.UnsupportedCommOperationException.
Now, in RXTX 2.1 the namespace has changed in gnu.io,
so the modbus library doesn't work anymore (it look
for things in javax.comm). I've already sent an email
to fieldtalk to see if they are aware of the problem.
The solution should be to use JavaComm + RXTX 2.0. But
I've read somewhere that JavaComm 2.0 does not work
with Java 5.0 and JavaComm 3.0 does not work with RXTX
2.0 so I don't know what to do.

Any ideas?

Thanks Jack

PS: can you make a CC to my personal email
(g_petrini at yahoo.it) too please?

Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 


From rxtx at tapastda.co.uk  Thu Jun  8 02:27:57 2006
From: rxtx at tapastda.co.uk (rxtx@tapastda.co.uk)
Date: Thu, 08 Jun 2006 09:27:57 +0100
Subject: [Rxtx] Win XP and Infrared based serial port
Message-ID: <4487DF8D.5050807@tapastda.co.uk>

I'm attempting to use RXTX 2.1.7 on Win XP with J2SE 5.0 to communicate with a
GSM mobile using a COM port. A peculiarity that I've seen is that whilst I can
communicate successfully with a mobile which uses an infrared based COM port
using the SUN provided javax.comm (v2.0) I cannot use RXTX because it fails to
read anything from the port (i.e. read timeout always occurs returning zero bytes).

I assumed that this could be the result of flow control problems and thus I've
tried setting either software or hardware based flow control on the port however
this has no affect.

Can you suggest any other port configuration changes which might be required to
make such a port work with RXTX.

Thanks
Stu
-- 
Stuart
Tapastda Limited


From tjarvi at qbang.org  Thu Jun  8 05:17:12 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 8 Jun 2006 05:17:12 -0600 (MDT)
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from
	FieldTalk
In-Reply-To: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
References: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606080504480.9856@www>

On Thu, 8 Jun 2006, Giacomo Petrini wrote:

> Hi,
> I'm evaluating the library for the modbus protocol
> from FieldTalk
> (http://www.modbusdriver.com/fieldtalk/.
> I'm using J2SE 5.0 and RXTX 2.1 on win XP.
> The problem is that the modbus lib has a method (the
> openProtocol method, but maybe there are others) tha
> throws the
> javax.comm.UnsupportedCommOperationException.
> Now, in RXTX 2.1 the namespace has changed in gnu.io,
> so the modbus library doesn't work anymore (it look
> for things in javax.comm). I've already sent an email
> to fieldtalk to see if they are aware of the problem.
> The solution should be to use JavaComm + RXTX 2.0. But
> I've read somewhere that JavaComm 2.0 does not work
> with Java 5.0 and JavaComm 3.0 does not work with RXTX
> 2.0 so I don't know what to do.
>
> Any ideas?
>
> Thanks Jack
>


Hi Jack

There are plans for Sun to rerelease JavaComm 2.0 mentioned in the rxtx 
mail-list archives.  When this happens rxtx will release a current rxtx 
2.0 library that works with it.

There are no dates promised by either side but rxtx will do it as soon as 
possible after Sun's rerelease.  Just to give you a feel for the time 
frame, this started last year and no significant progress has been made. 
There have been friendly talks pointing towards solutions (rerelease 2.0) 
but that does not get your application working today.  rxtx is preparing 
for its second release in gnu.io since then.

--
Trent Jarvi
tjarvi at qbang.org




From jredman at ergotech.com  Thu Jun  8 08:47:23 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 08 Jun 2006 08:47:23 -0600
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from
	FieldTalk
In-Reply-To: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
References: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
Message-ID: <4488387B.6040903@ergotech.com>

You could always try a different library, eg.

http://sourceforge.net/projects/jamod

I've only used the slave side since we have our own implementation of 
Modbus Client (and a host of other PLC protocols).  However the client 
side seems to be pretty well supported and fairly widely used.  Since 
the source is there you could change to gnu.io.

I think I should take more of an interest in this issue.  We generally 
run 1.4.2 on Linux, but also have some J9 and old platforms that we 
support that are basically Personal Java.  5.0 on Linux has some 
horrible MDI bugs, to the point of being unusable.   Sounds as though we 
are going to have code compatibility problems across these platforms.

Jim


Giacomo Petrini wrote:
> Hi,
> I'm evaluating the library for the modbus protocol
> from FieldTalk
> (http://www.modbusdriver.com/fieldtalk/.
> I'm using J2SE 5.0 and RXTX 2.1 on win XP.
> The problem is that the modbus lib has a method (the
> openProtocol method, but maybe there are others) tha
> throws the
> javax.comm.UnsupportedCommOperationException.
> Now, in RXTX 2.1 the namespace has changed in gnu.io,
> so the modbus library doesn't work anymore (it look
> for things in javax.comm). I've already sent an email
> to fieldtalk to see if they are aware of the problem.
> The solution should be to use JavaComm + RXTX 2.0. But
> I've read somewhere that JavaComm 2.0 does not work
> with Java 5.0 and JavaComm 3.0 does not work with RXTX
> 2.0 so I don't know what to do.
> 
> Any ideas?
> 
> Thanks Jack
> 
> PS: can you make a CC to my personal email
> (g_petrini at yahoo.it) too please?
> 
> Chiacchiera con i tuoi amici in tempo reale! 
>  http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  8 18:17:23 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 08 Jun 2006 17:17:23 -0700
Subject: [Rxtx] rxtx access is denied error
Message-ID: <4488BE13.2050706@dupreeinc.com>

Hello,

I have been trying to replace the commapi from sun with rxtx for a 
project that communicates with a serial port that is a USB-Serial 
interface.  To be exact, I am using the FTDI VCP driver with one of 
their modules connected to a windows XP system.

I have the RXTX package working pretty well as long as nothing goes wrong.

If a user disconnects the USB port while my java application is running, 
my application goes into an endless loop with lots of messages in the  
errors stream  like the ones below:

    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(481):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.


I believe when this happens the COM port completely disappears and the 
rxtx driver has a heart attack.  Obviously, the user should not do this, 
but my application needs to ideally, correct the situation or as a worse 
case, terminate with a little dignity.  Currently, I have not figured 
out how to catch this error.

The closest I have come is to trap an exception to my input stream read  
that says "No error in readByte"  This error appears to be outside of 
the endless loop of the errors listed above.

Does anybody have an idea of how to identify and trap this error?  Any 
suggestions on how to gracefully recover from it would be greatly 
appreciated!

Thank you for your time,

Doug Thistlethwaite




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060608/9cfca302/attachment-0008.html

From tjarvi at qbang.org  Thu Jun  8 20:54:17 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 8 Jun 2006 20:54:17 -0600 (MDT)
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <4488BE13.2050706@dupreeinc.com>
References: <4488BE13.2050706@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606082022580.1323@www>

On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I have been trying to replace the commapi from sun with rxtx for a project 
> that communicates with a serial port that is a USB-Serial interface.  To be 
> exact, I am using the FTDI VCP driver with one of their modules connected to 
> a windows XP system.
>
> I have the RXTX package working pretty well as long as nothing goes wrong.
>
> If a user disconnects the USB port while my java application is running, my 
> application goes into an endless loop with lots of messages in the  errors 
> stream  like the ones below:
>
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(481):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>
>
> I believe when this happens the COM port completely disappears and the rxtx 
> driver has a heart attack.  Obviously, the user should not do this, but my 
> application needs to ideally, correct the situation or as a worse case, 
> terminate with a little dignity.  Currently, I have not figured out how to 
> catch this error.
>
> The closest I have come is to trap an exception to my input stream read  that 
> says "No error in readByte"  This error appears to be outside of the endless 
> loop of the errors listed above.
>
> Does anybody have an idea of how to identify and trap this error?  Any 
> suggestions on how to gracefully recover from it would be greatly 
> appreciated!
>

Hi Doug

Sadly I don't have a quick solution for you.

Termios has no knowlage about the JVM so it wont be throwing exceptions 
you can catch.

We can return error and set the error number to something reasonable that 
results in an exception.  The No Error message simply means we did not set 
an error number in termios.c.  Those are the line numbers in the code you 
see.  SerialImp.c realizes it errored but does not know much more yet. 
Everything touching the file descriptor is going to error after the port 
is gone presumably.

We don't currently have a plan in place for vanishing (or appearing) com 
ports.

Another example of what we need to think about is what happens if you 
start your application and then plug in the dongle?  Or what if you unplug 
and then plug it in again?

So in each of these three cases, what would the behavior of the (yet to 
be) correct implementation do?

How will the enumerated ports be handled during these changes?

There can also be hints from the OS that could be taken into 
consideration.

We can probably get some exceptions thrown that make sense and null the 
file descriptor when it happens to prevent io attempts.  That would be a 
crude way to let applications know something strange has happened.

Is anyone else tinkering with this problem?

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  9 01:31:29 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 9 Jun 2006 09:31:29 +0200
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <Pine.LNX.4.61.0606082022580.1323@www>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
Message-ID: <AC6EDDDD-0A64-401F-B16B-E484788CDF4A@buechse.de>

Hello Trent,

I am not tinkering with this on the Source Level - but I think it  
should work pretty much the same way as it currently does in OSX.  
When the port goes away you get an IOException thrown for any read/ 
write. It will no longer be in the list of ports from  
CommPortIdentifier.getPortIdentifiers(). When a port (re-)appears it  
is added to the list. It's up to the application to re-check the list  
from time to time.

On Windows you can't do much better then that, because the ports  
don't have useful names. Which USB "virtual com port" is on which  
COMx depends on the order the devices were added. So reconnecting to  
the same device may mean connecting to another port.

Regarding the exception thrown: it would be nice to use an  
IOException subclass but the Exception message should definetly be  
informative also as most applications may want to keep compatibility  
with javax.comm.

Regards,
Joachim


On 09.06.2006, at 04:54, Trent Jarvi wrote:

> On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:
>
>> Hello,
>>
>> I have been trying to replace the commapi from sun with rxtx for a  
>> project
>> that communicates with a serial port that is a USB-Serial  
>> interface.  To be
>> exact, I am using the FTDI VCP driver with one of their modules  
>> connected to
>> a windows XP system.
>>
>> I have the RXTX package working pretty well as long as nothing  
>> goes wrong.
>>
>> If a user disconnects the USB port while my java application is  
>> running, my
>> application goes into an endless loop with lots of messages in  
>> the  errors
>> stream  like the ones below:
>>
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (481):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>
>>
>> I believe when this happens the COM port completely disappears and  
>> the rxtx
>> driver has a heart attack.  Obviously, the user should not do  
>> this, but my
>> application needs to ideally, correct the situation or as a worse  
>> case,
>> terminate with a little dignity.  Currently, I have not figured  
>> out how to
>> catch this error.
>>
>> The closest I have come is to trap an exception to my input stream  
>> read  that
>> says "No error in readByte"  This error appears to be outside of  
>> the endless
>> loop of the errors listed above.
>>
>> Does anybody have an idea of how to identify and trap this error?   
>> Any
>> suggestions on how to gracefully recover from it would be greatly
>> appreciated!
>>
>
> Hi Doug
>
> Sadly I don't have a quick solution for you.
>
> Termios has no knowlage about the JVM so it wont be throwing  
> exceptions
> you can catch.
>
> We can return error and set the error number to something  
> reasonable that
> results in an exception.  The No Error message simply means we did  
> not set
> an error number in termios.c.  Those are the line numbers in the  
> code you
> see.  SerialImp.c realizes it errored but does not know much more yet.
> Everything touching the file descriptor is going to error after the  
> port
> is gone presumably.
>
> We don't currently have a plan in place for vanishing (or  
> appearing) com
> ports.
>
> Another example of what we need to think about is what happens if you
> start your application and then plug in the dongle?  Or what if you  
> unplug
> and then plug it in again?
>
> So in each of these three cases, what would the behavior of the  
> (yet to
> be) correct implementation do?
>
> How will the enumerated ports be handled during these changes?
>
> There can also be hints from the OS that could be taken into
> consideration.
>
> We can probably get some exceptions thrown that make sense and null  
> the
> file descriptor when it happens to prevent io attempts.  That would  
> be a
> crude way to let applications know something strange has happened.
>
> Is anyone else tinkering with this problem?
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From doug at dupreeinc.com  Fri Jun  9 13:09:58 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 09 Jun 2006 12:09:58 -0700
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <Pine.LNX.4.61.0606082022580.1323@www>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
Message-ID: <4489C786.9050504@dupreeinc.com>


Ideally, it would be nice if it would throw an exception and terminate 
the loop.  I am still trying to figure out how to detect the condition 
and recover form it in some form...  I am getting the "No error in 
readByte" exception in my serialEvent() method after an input stream 
read.  It appears to me that the only graceful recovery is to close the 
port and then reopen it when it becomes available.  I can pass the event 
up to the update method in my main frame, but I still can't close the 
port from within that thread.  Any suggestions on how to pass this event 
to a location where the port can be safely closed?

Re: Slow startup in windows XP
I have been looking into this a little closer and have found out the 
following:
System Windows XP Pro 3GHz dual core with 1GB RAM and NO parallel port.
Starting the SerialDemo included with the commapi using the rxtx instead 
of javax.comm takes 60 seconds.
Starting the SerialDemo using rxrx with the rxtxParallel.dll file 
removed takes about 20 seconds.
Modify initialize in RXRXCommDriver.java to not test the parallel ports 
takes less than 1 second.

It would be nice if the initialize routine could detect the presence of 
rxtxParallel.dll file and just skip the whole process if not present.  
Is there an easy way to check for the presence of this file without 
running the parallel port test?

Doug


 

Trent Jarvi wrote:

>On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:
>...
>  
>
>
>Hi Doug
>
>Sadly I don't have a quick solution for you.
>
>Termios has no knowlage about the JVM so it wont be throwing exceptions 
>you can catch.
>
>We can return error and set the error number to something reasonable that 
>results in an exception.  The No Error message simply means we did not set 
>an error number in termios.c.  Those are the line numbers in the code you 
>see.  SerialImp.c realizes it errored but does not know much more yet. 
>Everything touching the file descriptor is going to error after the port 
>is gone presumably.
>
>We don't currently have a plan in place for vanishing (or appearing) com 
>ports.
>
>Another example of what we need to think about is what happens if you 
>start your application and then plug in the dongle?  Or what if you unplug 
>and then plug it in again?
>
>So in each of these three cases, what would the behavior of the (yet to 
>be) correct implementation do?
>
>How will the enumerated ports be handled during these changes?
>
>There can also be hints from the OS that could be taken into 
>consideration.
>
>We can probably get some exceptions thrown that make sense and null the 
>file descriptor when it happens to prevent io attempts.  That would be a 
>crude way to let applications know something strange has happened.
>
>Is anyone else tinkering with this problem?
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060609/911ed787/attachment-0008.html

From Ugo.Landini at Sun.COM  Fri Jun  2 14:23:47 2006
From: Ugo.Landini at Sun.COM (Ugo Landini)
Date: Fri, 02 Jun 2006 22:23:47 +0200
Subject: [Rxtx] OSX 10.4.7 and usb
Message-ID: <44809E53.2070905@sun.com>

Hi, I have installed the library and the native libraries on OSX 10.4.7. 
Then I have run this simple code:

...
while (portList.hasMoreElements()) {
             portId = (CommPortIdentifier) portList.nextElement();
             System.out.println("-> " + portId.getName() + " Port Type:" 
+ portId.getPortType());
...

and the output is:

Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7

Ports found:
-> /dev/tty.Bluetooth-PDA-Sync Port Type:1
-> /dev/cu.Bluetooth-PDA-Sync Port Type:1
-> /dev/tty.Bluetooth-Modem Port Type:1
-> /dev/cu.Bluetooth-Modem Port Type:1

I can't see any USB ports... with javax.comm on linux I could see the 
/dev/ttyUSB stuff, but that's not the case with OSX. Any idea?

tia

uL


From tod at todbot.com  Sun Jun 11 12:04:37 2006
From: tod at todbot.com (Tod E. Kurt)
Date: Sun, 11 Jun 2006 11:04:37 -0700
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <44809E53.2070905@sun.com>
References: <44809E53.2070905@sun.com>
Message-ID: <E2EB14A1-20A7-4611-8F1A-E3D2ABE41F48@todbot.com>

A dumb question, but: do you have the USB serial adapters plugged  
in?  They only show up in /dev when plugged in.  Also, you can verify  
they exist independent of RXTX by doing something like "ls -l /dev/ 
cu.*".

On Jun 2, 2006, at 1:23 PM, Ugo Landini wrote:

> Hi, I have installed the library and the native libraries on OSX  
> 10.4.7.
> Then I have run this simple code:
>
> ...
> while (portList.hasMoreElements()) {
>              portId = (CommPortIdentifier) portList.nextElement();
>              System.out.println("-> " + portId.getName() + " Port  
> Type:"
> + portId.getPortType());
> ...
>
> and the output is:
>
> Experimental:  JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
>
> Ports found:
> -> /dev/tty.Bluetooth-PDA-Sync Port Type:1
> -> /dev/cu.Bluetooth-PDA-Sync Port Type:1
> -> /dev/tty.Bluetooth-Modem Port Type:1
> -> /dev/cu.Bluetooth-Modem Port Type:1
>
> I can't see any USB ports... with javax.comm on linux I could see the
> /dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>
> tia
>
> uL
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>



From lyon at docjava.com  Sun Jun 11 12:14:50 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Sun, 11 Jun 2006 14:14:50 -0400
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <44809E53.2070905@sun.com>
References: <44809E53.2070905@sun.com>
Message-ID: <p06020444c0b20de7d248@[192.168.1.152]>

>Hi Ugo,

Do you have any USB serial ports (like the keyspan 19-HS) plugged
into the mac?
Thanks!
  - DL


>Hi, I have installed the library and the native libraries on OSX 10.4.7.
>Then I have run this simple code:
>
>...
>while (portList.hasMoreElements()) {
>              portId = (CommPortIdentifier) portList.nextElement();
>              System.out.println("-> " + portId.getName() + " Port Type:"
>+ portId.getPortType());
>...
>
>and the output is:
>
>Experimental:  JNI_OnLoad called.
>Stable Library
>=========================================
>Native lib Version = RXTX-2.1-7
>Java lib Version   = RXTX-2.1-7
>
>Ports found:
>-> /dev/tty.Bluetooth-PDA-Sync Port Type:1
>-> /dev/cu.Bluetooth-PDA-Sync Port Type:1
>-> /dev/tty.Bluetooth-Modem Port Type:1
>-> /dev/cu.Bluetooth-Modem Port Type:1
>
>I can't see any USB ports... with javax.comm on linux I could see the
>/dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>
>tia
>
>uL
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx



From dmarkman at mac.com  Sun Jun 11 14:30:27 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Sun, 11 Jun 2006 16:30:27 -0400
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <p06020444c0b20de7d248@[192.168.1.152]>
References: <44809E53.2070905@sun.com> <p06020444c0b20de7d248@[192.168.1.152]>
Message-ID: <B9C1606B-4339-4564-A175-FE83DFFA7D76@mac.com>

afaik
10.4.7 wasn't released yet
it will soon, no doubts


On Jun 11, 2006, at 2:14 PM, Dr. Douglas Lyon wrote:

>> Hi Ugo,
>
> Do you have any USB serial ports (like the keyspan 19-HS) plugged
> into the mac?
> Thanks!
>   - DL
>
>
>> Hi, I have installed the library and the native libraries on OSX  
>> 10.4.7.
>> Then I have run this simple code:
>>
>> ...
>> while (portList.hasMoreElements()) {
>>              portId = (CommPortIdentifier) portList.nextElement();
>>              System.out.println("-> " + portId.getName() + " Port  
>> Type:"
>> + portId.getPortType());
>> ...
>>
>> and the output is:
>>
>> Experimental:  JNI_OnLoad called.
>> Stable Library
>> =========================================
>> Native lib Version = RXTX-2.1-7
>> Java lib Version   = RXTX-2.1-7
>>
>> Ports found:
>> -> /dev/tty.Bluetooth-PDA-Sync Port Type:1
>> -> /dev/cu.Bluetooth-PDA-Sync Port Type:1
>> -> /dev/tty.Bluetooth-Modem Port Type:1
>> -> /dev/cu.Bluetooth-Modem Port Type:1
>>
>> I can't see any USB ports... with javax.comm on linux I could see the
>> /dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>>
>> tia
>>
>> uL
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman



From tjarvi at qbang.org  Sun Jun 11 18:52:59 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 11 Jun 2006 18:52:59 -0600 (MDT)
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <4489C786.9050504@dupreeinc.com>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
	<4489C786.9050504@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606111845430.7274@www>

On Fri, 9 Jun 2006, Doug Thistlethwaite wrote:

>
> Ideally, it would be nice if it would throw an exception and terminate the 
> loop.  I am still trying to figure out how to detect the condition and 
> recover form it in some form...  I am getting the "No error in readByte" 
> exception in my serialEvent() method after an input stream read.  It appears 
> to me that the only graceful recovery is to close the port and then reopen it 
> when it becomes available.  I can pass the event up to the update method in 
> my main frame, but I still can't close the port from within that thread.  Any 
> suggestions on how to pass this event to a location where the port can be 
> safely closed?
>

I've gone through and cleaned up the termios.c layer.  I need to get to a 
windows machine with a USB dongle and see where the ioctl() is being 
called.  Probably the eventLoop.  But all of the ioctls should probably 
result in an IOException during this condition.

I'll probably finish this up Monday night when I can borrow a USB 
dongle.

There is no point in putting the code into CVS yet.  If you are tinkering 
I can mail the patch.  I think we will want to make a couple fixes in 
SerialImp.c to handle errors before it's ready.

--
Trent Jarvi
tjarvi at qbang.org



From bob_tai2001 at yahoo.com  Mon Jun 12 09:42:14 2006
From: bob_tai2001 at yahoo.com (Bob Tai)
Date: Mon, 12 Jun 2006 08:42:14 -0700 (PDT)
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to RXTX
	again
Message-ID: <20060612154214.58219.qmail@web32804.mail.mud.yahoo.com>


thank you Paul, Joachim, Trent and everyone try to
workout the java comm and Rxtx situation.  At least
now I have something that is solid enough to make my
decision.  

thank you,
     Bob

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From Ralph.Buchfelder at gmx.net  Mon Jun 12 15:30:20 2006
From: Ralph.Buchfelder at gmx.net (Ralph Buchfelder)
Date: Mon, 12 Jun 2006 23:30:20 +0200
Subject: [Rxtx] rxtx binaries or porting to XSCALE Windows Mobile 2003 / 2005
Message-ID: <448DDCEC.7090506@gmx.net>

dear group,

i have been carefully reading your homepage, wiki and archives
but there seems to be no detailled information on porting to Windows 
Mobile/CE.

as far as i understood from the 'porting' section you can do porting to 
winCE. but how? do i only need to obtain the sourcecode (which one?) and 
compile this in Microsoft eMbedded Visual C++ for ARM/Xscale?
Any other ways?


unfortunately i must admit that i do have little linux skills but i have 
made my way through gcc and makefiles. right now i need to implement com 
  communication in a J2ME application and found your website as >the< 
solution.

best regards
Ralph Buchfelder

University of Regensburg
Department of Geography

PS: i dont care about Javacomm compliancy (ie. 2.0 or 2.1) - i just need 
a working serial port API in IBM J9 VM.


From paul.klissner at sun.com  Wed Jun 14 18:12:58 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Wed, 14 Jun 2006 17:12:58 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
Message-ID: <4490A60A.9090305@sun.com>

Hello RxTx community,

I finally think I have a compromise in place that will stand in the gap.

If you go to http://www.sun.com and search for javax.comm, you'll
get taken to a download page, where now users can get a copy of the
comm.jar file out of 2.0.3, along with just a license and a README.

I trust this will suffice until such time as RxTx decided to implement
their own java classes or we can get a JSR going to mitigate some
of the problems (the readme in the comm.jar 2.0.3 zip file
contains my thoughts on that).

Thanks,
Paul



From tjarvi at qbang.org  Wed Jun 14 21:15:35 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 14 Jun 2006 21:15:35 -0600 (MDT)
Subject: [Rxtx] rxtx-2.0-7 (final) src is in CVS
Message-ID: <Pine.LNX.4.61.0606142100500.2742@www>


I wasn't expecting to be working on rxtx 2.0 tonight :)

Thanks go out to Paul Klissner for his work in making the coming release 
of rxtx-2.0-7 possible for users that require package javax.comm on many 
platforms.

Most people know that rxtx 2.0 is for use with Sun's CommAPI 2.0 for 
Solaris or the Generic CommAPI 2.0-3 available for download at Sun.  If 
you need javax.comm packages on many platforms, you are probably 
interested.  If you use rxtx 2.1 in package gnu.io, then you are not going 
to care much.

I've tried to update the rxtx 2.0 src directory in preparation for 
rxtx-2.0-7 (final).  Linux should compile.  Windows will compile if you 
generate your own .def files (I'll generate these tomorrow).  If you have 
some time to do basic testing of the source, I'd appreciate it.  The 
source should be good but you may find classes not found.  This source is 
a backport from rxtx 2.1.

I wanted to get things started so anyone interested on Mac OS X could get 
a head start.

All of this is in CVS.  http://www.rxtx.org/cvs.html

I suspect we will have binaries for testing in a couple days if you are 
unable to compile.   Consider this a smoke test.

--
Trent Jarvi
tjarvi at qbang.org


From legolas.w at gmail.com  Wed Jun 14 22:04:28 2006
From: legolas.w at gmail.com (Legolas Woodland)
Date: Wed, 14 Jun 2006 21:04:28 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <4490A60A.9090305@sun.com>
References: <4490A60A.9090305@sun.com>
Message-ID: <87ee9b170606142104p745fcef0vea622fbc8f528bfc@mail.gmail.com>

is there anything new in this version of javax.comm ?
thanks


On 6/14/06, Paul Klissner <paul.klissner at sun.com> wrote:
>
> Hello RxTx community,
>
> I finally think I have a compromise in place that will stand in the gap.
>
> If you go to http://www.sun.com and search for javax.comm, you'll
> get taken to a download page, where now users can get a copy of the
> comm.jar file out of 2.0.3, along with just a license and a README.
>
> I trust this will suffice until such time as RxTx decided to implement
> their own java classes or we can get a JSR going to mitigate some
> of the problems (the readme in the comm.jar 2.0.3 zip file
> contains my thoughts on that).
>
> Thanks,
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060614/5ff4dfbc/attachment-0008.html

From joachim at buechse.de  Thu Jun 15 07:22:48 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 15 Jun 2006 15:22:48 +0200
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
Message-ID: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>

Good day!

Some of my users report problems using RXTX 2.1.7 on Windows98 to  
communicate with an FTDI FT245BM chip (using their latest VCP  
driver). Either no ports are being shown (ie returned form  
CommPortIdentifier.getPortIdentifiers()) or the transfers fail.

Did anyone run into similar Problems with Win98??

Best regards,
Joachim



From ajmas at sympatico.ca  Thu Jun 15 08:12:28 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Thu, 15 Jun 2006 10:12:28 -0400
Subject: [Rxtx] API change question
Message-ID: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

How closely do you follow the Java Communication API spec? The reason I ask is because I would be interested in augmenting the CommPortIdentifier class to include a getDisplayName() method. By default it would return the same value as getName(), but would provide the possibility of displaying a 'user friendly' name, for platforms where the display name is not the same as the device name. An example of this is on MacOS X, where currently the names seem to be of the form /dev/cu.* and /dev/tty.*, yet what the expects to see is simply the part after the full-stop. Although I could move this logic into the Java code, it would be nice to see it transparent to the Java code.

Andre




From ajmas at sympatico.ca  Thu Jun 15 08:16:22 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Thu, 15 Jun 2006 10:16:22 -0400
Subject: [Rxtx] Package to use
Message-ID: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

While the Java API spec refers to javax.comm, I see that only gnu.io is provide by the rxtx project. Should our projects refer to the gnu.io package or the javax.comm API?

Andre



From joachim at buechse.de  Thu Jun 15 08:45:05 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 15 Jun 2006 16:45:05 +0200
Subject: [Rxtx] API change question
In-Reply-To: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>

Hello Andre,

the /dev/cu and /dev/tty have different semantics on OS X. It is much  
more than a simply naming issue to unify them, see my recent mail to  
the list...

Best regards,
Joachim


On 15.06.2006, at 16:12, Andre-John Mas wrote:

> Hi,
>
> How closely do you follow the Java Communication API spec? The  
> reason I ask is because I would be interested in augmenting the  
> CommPortIdentifier class to include a getDisplayName() method. By  
> default it would return the same value as getName(), but would  
> provide the possibility of displaying a 'user friendly' name, for  
> platforms where the display name is not the same as the device  
> name. An example of this is on MacOS X, where currently the names  
> seem to be of the form /dev/cu.* and /dev/tty.*, yet what the  
> expects to see is simply the part after the full-stop. Although I  
> could move this logic into the Java code, it would be nice to see  
> it transparent to the Java code.
>
> Andre
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From lyon at docjava.com  Thu Jun 15 10:16:29 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Thu, 15 Jun 2006 12:16:29 -0400
Subject: [Rxtx] cu.modem != /dev/ttya on mac.
In-Reply-To: <763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
	<763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>
Message-ID: <p0602046cc0b7378a95b0@[192.168.1.152]>

>Hi All,

I think that Joachim is correct. For the longest time,
I have been trying to figure out how to direct dial using
the cu.modem on the mac under os x.

As a less-than-optimal approach to auto-dialing, I have used
a keyspan USB 19HS adapter, along with an external modem, to
obtain the dialing feature.

Ideally, it would be better to dial with the built-in modem...but that did not
always seem to work, for some reason. Have others had some experience with
using the built in modem for dialing on the mac?

Thanks!
  - Doug


>Hello Andre,
>
>the /dev/cu and /dev/tty have different semantics on OS X. It is much?
>more than a simply naming issue to unify them, see my recent mail to?
>the list...
>
>Best regards,
>Joachim
>



From doug at dupreeinc.com  Thu Jun 15 14:52:50 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 15 Jun 2006 13:52:50 -0700
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
In-Reply-To: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
References: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
Message-ID: <4491C8A2.8090108@dupreeinc.com>

Hi Joachim,

I have been doing a lot with the new FTDI driver with win XP and have 
not had that particular problem.  I did notice that the new driver 
(dated May19th, 2006) is only for XP, Server 2003, and 2000.  Are they 
trying to use the 2.00.00 drivers or the old 1.09.06 version.  I am 
using a FT232R based module, but it uses the same drivers and I assume 
it would have the same problems.  Let me know which driver they are 
using and I can load up a 98 system here and see if  I can duplicate the 
problem.

Doug

Joachim Buechse wrote:

>Good day!
>
>Some of my users report problems using RXTX 2.1.7 on Windows98 to  
>communicate with an FTDI FT245BM chip (using their latest VCP  
>driver). Either no ports are being shown (ie returned form  
>CommPortIdentifier.getPortIdentifiers()) or the transfers fail.
>
>Did anyone run into similar Problems with Win98??
>
>Best regards,
>Joachim
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From matthewhepp at yahoo.com  Thu Jun 15 17:34:47 2006
From: matthewhepp at yahoo.com (Matthew Hepp)
Date: Thu, 15 Jun 2006 16:34:47 -0700 (PDT)
Subject: [Rxtx] Wither the XCode project?
Message-ID: <20060615233447.48064.qmail@web50311.mail.yahoo.com>

Either I don't know how to properly use CVS (entirely possibl), or the XCode
project is not making through the update properly. Doing a "cvs update" against
2.1-7 creates an XCode folder in MACOSX_IDE, and therein a
LibSerialUniversal.xcodeproj, but trying to open it yields a "Unable to Open
Project - Project rxtx-devel/MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj
cannot be opened because it is missing its project.pbxproj file" error. Showing
package contents reveals just the cvs-related files. Perhaps this is why
previous xcode projects have been saved as an sit.hqx - to retain the resource
fork?

Can someone point me in the right direction?

Thanks,

Matt

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Thu Jun 15 19:53:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 19:53:06 -0600 (MDT)
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
In-Reply-To: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
References: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
Message-ID: <Pine.LNX.4.61.0606151944070.23137@www>

On Thu, 15 Jun 2006, Joachim Buechse wrote:

> Good day!
>
> Some of my users report problems using RXTX 2.1.7 on Windows98 to
> communicate with an FTDI FT245BM chip (using their latest VCP
> driver). Either no ports are being shown (ie returned form
> CommPortIdentifier.getPortIdentifiers()) or the transfers fail.
>
> Did anyone run into similar Problems with Win98??
>

Hi Joachim

It has been a long time since I've tested win98.  I know rxtx-2.1-7pre16 
did get testing on win98 with ~jdk 1.3 though.  I wonder if jdks are still 
tested on that platform.

With win98 you usually have older boxes.  They can be short on CPU and 
memory.  Enumeration should work but I could picture runtime performance 
issues on win98.

The enumeration problems could result from other copies of your 
application if various states of decay still holding onto the port.  When 
things go wrong, people also like to open other terminal software to see 
whats going on which can interfere.  You can't open a windows port with 
two apps.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Thu Jun 15 20:08:53 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 20:08:53 -0600 (MDT)
Subject: [Rxtx] API change question
In-Reply-To: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606151954270.23137@www>

On Thu, 15 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> How closely do you follow the Java Communication API spec?

I can explain how this worked in the past.  How we do it in the future is 
open for discussion.

In the past we have tried to follow it as close as possible in gnu.io 
(rxtx 2.1).  We have added extensions but try to discourage their use. 
The extensions are clearly marked as such in the source code and javadocs.

rxtx 2.0 was intended to be a strict implementation of part of the spec. 
We let Sun's interfaces decide what methods can be called. There are 
differences not covered by the spec such as default values.  Thats not 
intentional but rather hard to avoid.

--
Trent Jarvi
tjarvi at qbang.org





From tjarvi at qbang.org  Thu Jun 15 21:09:11 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 21:09:11 -0600 (MDT)
Subject: [Rxtx] Package to use
In-Reply-To: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606152026120.23137@www>

On Thu, 15 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> While the Java API spec refers to javax.comm, I see that only gnu.io is 
> provide by the rxtx project. Should our projects refer to the gnu.io 
> package or the javax.comm API?
>

Hi Andre

Lets see if I can give a fair and balanced answer to that.

If you are starting a new project and want to use RXTX, I would recommend 
using gnu.io.  The community support for gnu.io will not be going away 
anytime soon.  You can switch between gnu.io (2.1) and javax.comm (2.0) 
fairly easily.  They are not intended to be incompatible.  You just change 
package names and libs.

You can also consider the combination of rxtx 2.0 with Sun's commapi 
2.0-3.  This is considered a stop-gap measure by Sun for previous users of 
that combination.  Together rxtx 2.0 and Sun CommAPI 2.0 work in namespace 
javax.comm for programmers.

Finally, you can opt to just use Sun's oferrings in CommAPI 3.0 without 
rxtx.  That would be in namespace javax.comm also.  CommAPI 3.0 may be 
of more interest to you if you are looking at POS with Sun computers. 
Rxtx does not currently support the changes in CommAPI 3.0 or have firm 
plans to do so.  That does not mean we wouldn't implement them.  It just 
means nobody has contributed code yet.

You can't combine rxtx with CommAPI 3.0 for technical reasons that wont 
likely be fixed soon.

It's up to you as far as what you use.  We like to provide the freedom so 
you can choose.  Realistically, we will be supporting gnu.io mainly 
because we have some control over that name space and can support it.

Things may happen in the future that enable rxtx to provide more support 
in the javax namespace but that has not happened yet.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun 16 00:33:06 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 08:33:06 +0200
Subject: [Rxtx] Wither the XCode project?
In-Reply-To: <20060615233447.48064.qmail@web50311.mail.yahoo.com>
References: <20060615233447.48064.qmail@web50311.mail.yahoo.com>
Message-ID: <D30D660F-A49B-464E-AE4C-6B4563893682@buechse.de>

Hello Matthew,

could you please send me the contents of your

   rxtx-devel/CVS
   rxtx-devel/MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj/CVS

directories as a zip to my personal email address. This should  
indicate why the file is not checked out. I can see that it exists on  
the correct branch in the repository, so something must have gone  
wrong during the "cvs update"...

Best regards,
Joachim

On 16.06.2006, at 01:34, Matthew Hepp wrote:

> Either I don't know how to properly use CVS (entirely possibl), or  
> the XCode
> project is not making through the update properly. Doing a "cvs  
> update" against
> 2.1-7 creates an XCode folder in MACOSX_IDE, and therein a
> LibSerialUniversal.xcodeproj, but trying to open it yields a  
> "Unable to Open
> Project - Project rxtx-devel/MACOSX_IDE/XCode/ 
> LibSerialUniversal.xcodeproj
> cannot be opened because it is missing its project.pbxproj file"  
> error. Showing
> package contents reveals just the cvs-related files. Perhaps this  
> is why
> previous xcode projects have been saved as an sit.hqx - to retain  
> the resource
> fork?
>
> Can someone point me in the right direction?



From joachim at buechse.de  Fri Jun 16 10:41:20 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 18:41:20 +0200
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <p06230903c0b88613dca6@[10.0.1.7]>
References: <p06230903c0b88613dca6@[10.0.1.7]>
Message-ID: <03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>

Hello Bob,

until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was  
behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if  
Trent has migrated all recent changes from 2.1 to 2.0.

I have added the XCode project and updated documentation only to the  
gnu.io branch. Once the 2.0 implementation is up to date I will copy  
over the documentation/build files make them work.

Best regards,
Joachim

On 16.06.2006, at 18:07, Bob Jacobsen wrote:

> I'm one of the developers for the JMRI project, which provides  
> model railroad software in Java.  We've been using RXTX to provide  
> serial port access on MacOS X and Linux; we use the old javax.comm  
> 2.0 on Windows, OS/2 and Solaris.  Because of that, we need to stay  
> with RXTX 2.0, not 2.1
>
> We've been using the 2.0-pre17 installer for a long time, but it's  
> not compatible with Intel macs.
>
> Can you point me to where I can find the right files for RXTX 2.0  
> to package with the program?
>
> The current situation is confusing to me.  I've been pointed to  
> recent 2.1 versions (but we need the javax.comm names), to an even  
> older installer, etc.  I've been reading that some versions require  
> an installer, and others don't, but I haven't been able to figure  
> out which (if any) of those are where in CVS.
>
> I'd really appreciate a clear statement of what files to use and  
> what to do with them that I can pass on to our users.
>
> I'm more than happy to put files in the local classpath, have users  
> run an installer, or anything else.  Whatever is easiest for you.
>
> Thanks!  I really appreciate all that you do to keep RXTX working.
>
> Bob
> -- 
> Bob Jacobsen +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG



From joachim at buechse.de  Fri Jun 16 09:59:28 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 17:59:28 +0200
Subject: [Rxtx] Wither the XCode project?
In-Reply-To: <20060616150240.49464.qmail@web50309.mail.yahoo.com>
References: <20060616150240.49464.qmail@web50309.mail.yahoo.com>
Message-ID: <D9935E05-2B83-488D-86DD-42599E229052@buechse.de>

Hello Matthew,

you have checked out the trunk (which is the 2.0.7 javax.comm.xxx  
release). For rxtx-2.1.7 (gnu.io.xxx release) you need to check out  
the branch

      commapi-0-0-1

The easiest way to do this is to download the rxtx src archive,  
unpack it and then do a cvs up inside the decompressed tree.  
Optionally you could do a

      cvs co -r commapi-0-0-1

but this will take much longer!

Best regards,
Joachim

When you do a cvs status it will show the sticky tag.

41:~/jdevelop/rxtx-2.1-7r2 joachim$ cvs status README.OSX
===================================================================
File: README.OSX        Status: Up-to-date

    Working revision:    1.1.2.1
    Repository revision: 1.1.2.1 /usr/local/cvsroot/rxtx-devel/Attic/ 
README.OSX,v
    Sticky Tag:          commapi-0-0-1 (branch: 1.1.2)
    Sticky Date:         (none)
    Sticky Options:      (none)




On 16.06.2006, at 17:02, Matthew Hepp wrote:

> %cvs status README.MACOSX
> ===================================================================
> File: README.MACOSX     Status: Up-to-date
>
>    Working revision:    1.1
>    Repository revision: 1.1     /usr/local/cvsroot/rxtx-devel/ 
> README.MACOSX,v
>    Sticky Tag:          (none)
>    Sticky Date:         (none)
>    Sticky Options:      (none)



From tjarvi at qbang.org  Fri Jun 16 16:31:18 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Fri, 16 Jun 2006 16:31:18 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
Message-ID: <Pine.LNX.4.61.0606161630030.14139@www>

On Fri, 16 Jun 2006, Joachim Buechse wrote:

> Hello Bob,
>
> until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was
> behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if
> Trent has migrated all recent changes from 2.1 to 2.0.
>

The src/ directory and configure.in/configure files should be fine.  I 
have not touched the Mac OS X directories.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sat Jun 17 02:39:55 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sat, 17 Jun 2006 10:39:55 +0200
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <Pine.LNX.4.61.0606161630030.14139@www>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
Message-ID: <350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>

Hello Trent,

apparently the IOEXCL changes have not made it into 2.0. I will add  
them to achieve a minimal diff between 2.0 and 2.1.

One other thing that bugs me for a while...

Shouldn't we replace "if !defined(TIOCSERGETLSR) && !defined(WIN32)"  
by a definition of its own "if defined(DRAINTHREAD)"? I think this  
would make the code clearer for people starting to read it.

Regards,
Joachim


On 17.06.2006, at 00:31, Trent Jarvi wrote:

> On Fri, 16 Jun 2006, Joachim Buechse wrote:
>
>> Hello Bob,
>>
>> until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was
>> behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if
>> Trent has migrated all recent changes from 2.1 to 2.0.
>>
>
> The src/ directory and configure.in/configure files should be fine.  I
> have not touched the Mac OS X directories.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From tropicsu at hotmail.com  Sat Jun 17 09:32:48 2006
From: tropicsu at hotmail.com (Yoke K)
Date: Sat, 17 Jun 2006 15:32:48 +0000
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
Message-ID: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>

Hi,

I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to work with 
MAC OS X.
I am using iTegno 3000 - USB GPRS Modem.

Files in /dev and a symbolic link as follows:

crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 -> tty.usbserial

In my SendMessage.java, I have this line:
CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");

Appreciate any help ?

- Jon


Errors as follows:

>>INFO: SMSLib API for Java / v1.2.2
>>INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>INFO: JRE Version: 1.5.0_06
>>INFO: JRE Impl Version: 1.5.0_06-64
>>INFO: O/S: Mac OS X / ppc / 10.4.6
>>INFO: Using Wavecom (Generic) AT handler.

SendMessage(): Send a message.
  Using SMSLib API for Java v1.2.2

Connecting ..... :
>>INFO: CSerialDriver(): Connecting...
Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
>>INFO: CSerialDriver(): Disconnecting...
gnu.io.NoSuchPortException
        at 
gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:218)
        at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
        at org.smslib.CService.connect(CService.java:197)
        at SendMessage.main(SendMessage.java:38)

_________________________________________________________________
Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/



From tjarvi at qbang.org  Sat Jun 17 10:12:30 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 10:12:30 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
	<350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
Message-ID: <Pine.LNX.4.61.0606171010060.14139@www>

On Sat, 17 Jun 2006, Joachim Buechse wrote:

> Hello Trent,
>
> apparently the IOEXCL changes have not made it into 2.0. I will add
> them to achieve a minimal diff between 2.0 and 2.1.
>

Hi Joachim

As I recall the IOEXCL change was after 2.1-7.  I was just syncing with 
2.1-7.  We can release 2.1-8 and 2.0-8 with the same changes.

> One other thing that bugs me for a while...
>
> Shouldn't we replace "if !defined(TIOCSERGETLSR) && !defined(WIN32)"
> by a definition of its own "if defined(DRAINTHREAD)"? I think this
> would make the code clearer for people starting to read it.
>


Sure.  We can do that for -8.  The TIOCSERGETLSR code should be a special 
case not the expected.  I think only Linux uses it.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Sat Jun 17 10:48:21 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 10:48:21 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <Pine.LNX.4.61.0606171010060.14139@www>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
	<350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
	<Pine.LNX.4.61.0606171010060.14139@www>
Message-ID: <Pine.LNX.4.61.0606171047310.14139@www>

On Sat, 17 Jun 2006, Trent Jarvi wrote:

> On Sat, 17 Jun 2006, Joachim Buechse wrote:
>
>> Hello Trent,
>>
>> apparently the IOEXCL changes have not made it into 2.0. I will add
>> them to achieve a minimal diff between 2.0 and 2.1.
>>
>
> Hi Joachim
>
> As I recall the IOEXCL change was after 2.1-7.  I was just syncing with
> 2.1-7.  We can release 2.1-8 and 2.0-8 with the same changes.
>

We could just move to 2.1-8 and 2.0-8.

--
Trent Jarvi
tjarvi at qbang.org


From brian.t.lamb at gmail.com  Tue Jun 13 13:54:13 2006
From: brian.t.lamb at gmail.com (Brian Lamb)
Date: Tue, 13 Jun 2006 15:54:13 -0400
Subject: [Rxtx] Windows XP Installation
Message-ID: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>

I've not installed Java packages on Windows before and am unsure how to
proceed. All the documentation I've seen provides detailed instructions on
how to install on Linux or Solaris. I was wondering how to install rxtx on
Windows XP.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060613/6f68cd5c/attachment-0008.html

From tjarvi at qbang.org  Sat Jun 17 13:57:03 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 13:57:03 -0600 (MDT)
Subject: [Rxtx] Windows XP Installation
In-Reply-To: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>
References: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0606171356120.14139@www>

On Tue, 13 Jun 2006, Brian Lamb wrote:

> I've not installed Java packages on Windows before and am unsure how to
> proceed. All the documentation I've seen provides detailed instructions on
> how to install on Linux or Solaris. I was wondering how to install rxtx on
> Windows XP.
>

Hi Brian

Which rxtx version are you trying to install?

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sun Jun 18 10:41:44 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sun, 18 Jun 2006 18:41:44 +0200
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
References: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
Message-ID: <8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>

Hello Jon,

 From OSX's standpoint a symbolic link is not a device (as far as I  
know). What stops you from using tty.usbserial? Did you try hard- 
linking?

Regards,
Joachim

On 17.06.2006, at 17:32, Yoke K wrote:
> Hi,
>
> I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to  
> work with
> MAC OS X.
> I am using iTegno 3000 - USB GPRS Modem.
>
> Files in /dev and a symbolic link as follows:
>
> crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
> crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
> lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->  
> tty.usbserial
>
> In my SendMessage.java, I have this line:
> CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
>
> Appreciate any help ?
>
> - Jon
>
>
> Errors as follows:
>
>>> INFO: SMSLib API for Java / v1.2.2
>>> INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>> INFO: JRE Version: 1.5.0_06
>>> INFO: JRE Impl Version: 1.5.0_06-64
>>> INFO: O/S: Mac OS X / ppc / 10.4.6
>>> INFO: Using Wavecom (Generic) AT handler.
>
> SendMessage(): Send a message.
>   Using SMSLib API for Java v1.2.2
>
> Connecting ..... :
>>> INFO: CSerialDriver(): Connecting...
> Experimental:  JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
>>> INFO: CSerialDriver(): Disconnecting...
> gnu.io.NoSuchPortException
>         at
> gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java: 
> 218)
>         at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
>         at org.smslib.CService.connect(CService.java:197)
>         at SendMessage.main(SendMessage.java:38)
>
> _________________________________________________________________
> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Sun Jun 18 10:56:55 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 12:56:55 -0400
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>
References: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
	<8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>
Message-ID: <7B6834E3-F41D-46B6-B979-55466BC73859@sympatico.ca>

Have you been able to get any other software to talk with your
modem? What port is it using? Have tried using the cu.usbserial
instead?

Andre

On 18-Jun-06, at 12:41 , Joachim Buechse wrote:

> Hello Jon,
>
>  From OSX's standpoint a symbolic link is not a device (as far as I
> know). What stops you from using tty.usbserial? Did you try hard-
> linking?
>
> Regards,
> Joachim
>
> On 17.06.2006, at 17:32, Yoke K wrote:
>> Hi,
>>
>> I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to
>> work with
>> MAC OS X.
>> I am using iTegno 3000 - USB GPRS Modem.
>>
>> Files in /dev and a symbolic link as follows:
>>
>> crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
>> crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
>> lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->
>> tty.usbserial
>>
>> In my SendMessage.java, I have this line:
>> CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
>>
>> Appreciate any help ?
>>
>> - Jon
>>
>>
>> Errors as follows:
>>
>>>> INFO: SMSLib API for Java / v1.2.2
>>>> INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>>> INFO: JRE Version: 1.5.0_06
>>>> INFO: JRE Impl Version: 1.5.0_06-64
>>>> INFO: O/S: Mac OS X / ppc / 10.4.6
>>>> INFO: Using Wavecom (Generic) AT handler.
>>
>> SendMessage(): Send a message.
>>   Using SMSLib API for Java v1.2.2
>>
>> Connecting ..... :
>>>> INFO: CSerialDriver(): Connecting...
>> Experimental:  JNI_OnLoad called.
>> Stable Library
>> =========================================
>> Native lib Version = RXTX-2.1-7
>> Java lib Version   = RXTX-2.1-7
>>>> INFO: CSerialDriver(): Disconnecting...
>> gnu.io.NoSuchPortException
>>         at
>> gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:
>> 218)
>>         at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
>>         at org.smslib.CService.connect(CService.java:197)
>>         at SendMessage.main(SendMessage.java:38)
>>
>> _________________________________________________________________
>> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Sun Jun 18 17:33:08 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 19:33:08 -0400
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
Message-ID: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>

Hi,

I am have a program that I wrote in Java to communicate with a  
Bluetooth GPS device. I am
trying to get this working on my Mac, but I keep getting told that:

gnu.io.PortInUseException: Unknown Application

but

portIdentifier.isCurrentlyOwned()

returns false and when I do lsof on the device I am trying to connect  
to, I see no application
using it. As the same time if I go to the command line and use  
minicom I have no issues. The
exception happens with this call:

CommPort commPort = portIdentifier.open(null,0);

Any suggestions?

Andre


From ajmas at sympatico.ca  Sun Jun 18 17:45:11 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 19:45:11 -0400
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
Message-ID: <30245B30-682D-4EAE-8084-8227B719F10D@sympatico.ca>

BTW My code snippet is:

     private InputStream connectToSerial () throws IOException,  
Exception
     {
         InputStream in = null;

         Enumeration portEnum = CommPortIdentifier.getPortIdentifiers();
         while ( portEnum.hasMoreElements() )
         {
             CommPortIdentifier portIdentifier = (CommPortIdentifier)  
portEnum.nextElement();
             System.out.println(portIdentifier.getName() + " - " +  
portIdentifier.getPortType() );
         }

         CommPortIdentifier portIdentifier =  
CommPortIdentifier.getPortIdentifier("/dev/cu.BTGPS-SPPslave-1");
         System.out.println("current owner: " +  
portIdentifier.getCurrentOwner());
         if ( portIdentifier.isCurrentlyOwned() )
         {
             System.out.println("Error: Port is currently in use");
             return null;
         }
         else
         {
             CommPort commPort = portIdentifier.open(this.getClass 
().getName(),2000);

             if ( commPort instanceof SerialPort )
             {
                 SerialPort serialPort = (SerialPort) commPort;
                 serialPort.setSerialPortParams 
(4800,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE 
);
                 in = serialPort.getInputStream();

                 return in;
             }
             else
             {
                 System.out.println("Error: Only serial ports are  
handled.");
             }
         }


         return in;
     }


On 18-Jun-06, at 19:33 , Andr?-John Mas wrote:

> Hi,
>
> I am have a program that I wrote in Java to communicate with a
> Bluetooth GPS device. I am
> trying to get this working on my Mac, but I keep getting told that:
>
> gnu.io.PortInUseException: Unknown Application
>
> but
>
> portIdentifier.isCurrentlyOwned()
>
> returns false and when I do lsof on the device I am trying to connect
> to, I see no application
> using it. As the same time if I go to the command line and use
> minicom I have no issues. The
> exception happens with this call:
>
> CommPort commPort = portIdentifier.open(null,0);
>
> Any suggestions?
>
> Andre
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From joachim at buechse.de  Mon Jun 19 05:54:49 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 13:54:49 +0200
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de>

This is most likely due to a problem with lock files. If you have  
downloaded the binaries of 2.17 rxtx will try to create non-standard  
lock files on OSX. We have since changed the code to use OSX device  
locking - however the binaries have not been updated yet. The 2.18  
release fixing this issue is due shortly.

Regards,
Joachim

On 19.06.2006, at 01:33, Andr?-John Mas wrote:

> Hi,
>
> I am have a program that I wrote in Java to communicate with a
> Bluetooth GPS device. I am
> trying to get this working on my Mac, but I keep getting told that:
>
> gnu.io.PortInUseException: Unknown Application
>
> but
>
> portIdentifier.isCurrentlyOwned()
>
> returns false and when I do lsof on the device I am trying to connect
> to, I see no application
> using it. As the same time if I go to the command line and use
> minicom I have no issues. The
> exception happens with this call:
>
> CommPort commPort = portIdentifier.open(null,0);
>
> Any suggestions?
>
> Andre
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From joachim at buechse.de  Mon Jun 19 06:44:27 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 14:44:27 +0200
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <4490A60A.9090305@sun.com>
References: <4490A60A.9090305@sun.com>
Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>

Hello Paul,

I just downloaded the "generic" javax.comm version now available. A  
first check indicates, that it was compiled with a JDK 1.4 javac  
without setting the target classfile version. In other words in can  
not be loaded by 1.1-1.3 VMs (or PersonalJava).

Do you see any chance to provide a version compiled with classfile  
format 45.3 (ie JVM1.1).

---
52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose  
javax.comm.SerialPort | head -5
Compiled from "SerialPort.java"
public abstract class javax.comm.SerialPort extends javax.comm.CommPort
   SourceFile: "SerialPort.java"
   minor version: 0
   major version: 48
---

Best regards,
Joachim


On 15.06.2006, at 02:12, Paul Klissner wrote:

> Hello RxTx community,
>
> I finally think I have a compromise in place that will stand in the  
> gap.
>
> If you go to http://www.sun.com and search for javax.comm, you'll
> get taken to a download page, where now users can get a copy of the
> comm.jar file out of 2.0.3, along with just a license and a README.
>
> I trust this will suffice until such time as RxTx decided to implement
> their own java classes or we can get a JSR going to mitigate some
> of the problems (the readme in the comm.jar 2.0.3 zip file
> contains my thoughts on that).
>
> Thanks,
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Mon Jun 19 09:11:45 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Mon, 19 Jun 2006 11:11:45 -0400
Subject: [Rxtx] Examples added to Wiki
Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

I have added a couple of examples to the Wiki:

http://rxtx.qbang.org/wiki/index.php/Examples

If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :)

Andre



From paul.klissner at sun.com  Mon Jun 19 10:42:47 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Mon, 19 Jun 2006 09:42:47 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>
References: <4490A60A.9090305@sun.com>
	<03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>
Message-ID: <4496D407.1090609@sun.com>

Joachim Buechse wrote:
> Hello Paul,
> 
> I just downloaded the "generic" javax.comm version now available. A  
> first check indicates, that it was compiled with a JDK 1.4 javac  
> without setting the target classfile version. In other words in can  
> not be loaded by 1.1-1.3 VMs (or PersonalJava).
> 
> Do you see any chance to provide a version compiled with classfile  
> format 45.3 (ie JVM1.1).
> 
> ---
> 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose  
> javax.comm.SerialPort | head -5
> Compiled from "SerialPort.java"
> public abstract class javax.comm.SerialPort extends javax.comm.CommPort
>    SourceFile: "SerialPort.java"
>    minor version: 0
>    major version: 48
> ---

I cannot promise when I can do that. Since we thought we were done
with javax.comm, the build environment got moved around, and right
now it doesn't even compile in it's new home.  I tried and it was
not cooperative at all. I was never impressed with that workspace
(in fact far far from it, it is a mess, which is why I migrated 3.0
to ant and never looked back).  It will take some real determination
for me to rebuild it, and frankly, right now I'm swamped.  If I can
find a bit of time over the next few weeks to do it, and it isn't
too bad an ordeal, I will.

Posting that will give me an excuse to post javax.comm 3.0, Update 2 as
well, while I'm working with the people who put content up on our
download center.  The only reason for a new update to 3.0 is that
I've changed the distribution to provide ispt (Interactive Serial
Port Tool), such that it can be launched as soon as the zip file
is unpacked, via a provided script.  ISPT is a command line
interactive tool for  manipulating one or two serial port,
sending data, managing events, etc... I've found it to be so useful
for doing certain kinds of validation  that I assume others will
find it useful to.  ISPT is already in 3.0u1, but one has to set
up their own classpath and launch it and since few people ever read
the documentation most won't know about it.  I've added the ability
to set stop bits and parity since 3.0u1 too.  But I digress.

Paul


From joachim at buechse.de  Mon Jun 19 11:01:28 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 19:01:28 +0200
Subject: [Rxtx] load mechanism of 2.0x
Message-ID: <CFD1440C-21AA-4D3B-9EA6-270D0FF9D6FC@buechse.de>

Good day,

I am trying to figure out, how the 2.0x distribution interacts with  
Suns implementation of javax.comm.CommPortIdentifier.

1) Apparently one can put javax.comm.properties in {java.home}/lib
2) The javax.comm package also reacts to -Djavax.comm.properties="...."

Looking at the javap output it also seems like CommPortIdentifier  
tries to find it's jar file and load the properties from there??


What I'm really looking for is a solution that allows using  
javax.comm with RXTX without modifying the VM installation. So I  
would prefer not to use 1) but I can't figure out how to use 2).

Any hints are welcome,
Joachim



From bob_tai2001 at yahoo.com  Mon Jun 19 15:00:35 2006
From: bob_tai2001 at yahoo.com (Bob Tai)
Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT)
Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place
	to start?
Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>

Hi, 

I got  rxtx Windows 2000 installed.  I did not use the
"best" way ... I just follow the insturuction and dump
the necessary files into the jre... I know it's "best"
idea, I got lazy didn't want to change my setting to
my Eclipse and classpath.

I was able to modify SimpleWrite.java to print on my
AddMaster serial printer.  I think I am ready to code!
But I need to make sure I can handle exceptions and so
on.  I notice the \samples\NullDriver\  has two files
seems to have some of the require method done, should
I start coding from those file?  I like the idea it
has the "time out" and basic exceptions done.   I am
slowly digging into the samples, but if you think any
of the code from Sun is good to checkout please let me
know.

btw, http://rxtx.qbang.org/wiki/index.php/Examples/
was very helpful, wish there are more examples.

thank you,

    Bob


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Mon Jun 19 15:55:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT)
Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good
 place to start?
In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>
References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606191542260.14139@www>

> I am
> slowly digging into the samples, but if you think any
> of the code from Sun is good to checkout please let me
> know.
>

I think NullDriver.java was an example stub driver for implementing 
something like rxtx.  It has been a while.  Unless they have been updated, 
you will find the examples are very dated.  You can look at how they use 
the port but avoid the GUI and hard coded variables (number of ports for 
instance).

There was no Swing and nobody knew what requirements today's compilers 
would make on code.  The examples worked fine with jdk 1.1 but times have 
changed.

--
Trent Jarvi
tjarvi at qbang.org


From tropicsu at hotmail.com  Mon Jun 19 19:49:08 2006
From: tropicsu at hotmail.com (Yoke K)
Date: Tue, 20 Jun 2006 01:49:08 +0000
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
Message-ID: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>

An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0008.html

From ajmas at sympatico.ca  Mon Jun 19 21:14:37 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Mon, 19 Jun 2006 23:14:37 -0400
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>
References: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>
Message-ID: <CA22AB2A-5712-458B-9984-68477C6042AF@sympatico.ca>

Regarding the PortInUseException, I had a similar issue and got
this response from the mailing list:

   http://mailman.qbang.org/pipermail/rxtx/Week-of- 
Mon-20060619/062838.html

Andre
On 19-Jun-06, at 21:49 , Yoke K wrote:

> Hi Andre, Joachim
>
> I have tried using /dev/tty.usbserial and also /dev/cu.usbserial  
> and it also reported error as  "gnu.io.PortInUseException".
>
> The iTegno modem works in windows environment. As I moving around  
> using my ibook and I need to get it work on MAC OS as well.
>
> >> INFO: SMSLib API for Java / v1.2.2
> >> INFO: Using port: /dev/tty.usbserial @ 115200 baud.
> >> INFO: JRE Version: 1.5.0_06
> >> INFO: JRE Impl Version: 1.5.0_06-64
> >> INFO: O/S: Mac OS X / ppc / 10.4.6
> >> INFO: Using Wavecom (Generic) AT handler.
>
> SendMessage(): Send a message.
> Using SMSLib API for Java v1.2.2
>
> Connecting ..... :
> >> INFO: CSerialDriver(): Connecting...
> Experimental: JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version = RXTX-2.1-7
> >> INFO: CSerialDriver(): Disconnecting...
> gnu.io.PortInUseException: Unknown Application
> at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354)
> at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1)
> at org.smslib.CService.connect(CService.java:197)
> at SendMessage.main(SendMessage.java:38)
>
> Thanks.
>
> - Jon
>
>
>
>
> ====================
>
> Hello Jon,
>
> From OSX's standpoint a symbolic link is not a device (as far as I
> know). What stops you from using tty.usbserial? Did you try hard-
> linking?
>
> Regards,
> Joachim
>
>
>
> From:  "Yoke K" <tropicsu at hotmail.com>
> To:  rxtx at qbang.org
> Subject:  RXTX-2.1-7 / MAC OS X / NoSuchPortException
> Date:  Sat, 17 Jun 2006 15:32:48 +0000
> >Hi,
> >
> >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to
> >work with MAC OS X.
> >I am using iTegno 3000 - USB GPRS Modem.
> >
> >Files in /dev and a symbolic link as follows:
> >
> >crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
> >crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
> >lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->
> >tty.usbserial
> >
> >In my SendMessage.java, I have this line:
> >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
> >
> >Appreciate any help ?
> >
> >- Jon
> >
> >
> >Errors as follows:
> >
> >>>INFO: SMSLib API for Java / v1.2.2
> >>>INFO: Using port: /dev/ttyS1 @ 56000 baud.
> >>>INFO: JRE Version: 1.5.0_06
> >>>INFO: JRE Impl Version: 1.5.0_06-64
> >>>INFO: O/S: Mac OS X / ppc / 10.4.6
> >>>INFO: Using Wavecom (Generic) AT handler.
> >
> >SendMessage(): Send a message.
> >  Using SMSLib API for Java v1.2.2
> >
> >Connecting ..... :
> >>>INFO: CSerialDriver(): Connecting...
> >Experimental:  JNI_OnLoad called.
> >Stable Library
> >=========================================
> >Native lib Version = RXTX-2.1-7
> >Java lib Version   = RXTX-2.1-7
> >>>INFO: CSerialDriver(): Disconnecting...
> >gnu.io.NoSuchPortException
> >        at
> >gnu.io.CommPortIdentifier.getPortIdentifier 
> (CommPortIdentifier.java:218)
> >        at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
> >        at org.smslib.CService.connect(CService.java:197)
> >        at SendMessage.main(SendMessage.java:38)
> >
> >_________________________________________________________________
> >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
> >
>
> Find love online with MSN Personals
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Tue Jun 20 02:35:24 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 10:35:24 +0200
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>

Hello everybody,

I have been fighting a bit with the javax.comm version of RXTX the  
last days. I am working on the README .OSX now and try to figure out  
which should be the "suggested" installation.

The facts:
------

- the "generic" comm.jar version of javax.comm which has been made re- 
available tries to load com.sun.comm.SolarisDriver
- this classname can be overridden ONLY by putting a file  
javax.comm.properties in {java.home}/lib
- if it is not overridden and SolarisDriver.class is not found  
CommPortIdentifier will be disfunctional (in particual it is not  
possible to add CommPort's via CommPortIdentifier.add).
- the license distributed with comm.jar does not allow the  
modification/addition of classes in javax.comm (however no mention of  
com.sun...)


What really bothers me is to suggest putting this config file in the  
"global" vm installation. This is particularly ugly on the Mac as  
there are several VM installations and the file may be forgotten.  
Additionally it may create versioning problems. I prefer an  
installation where all files are local to the application (even  
comm.jar).

In my opinion the ideal situation would be:
------

1) The author of a program compiles against javax.comm.
2a) For platforms supported by Sun the user is free to use the 3.0  
comm.jar download from Sun
2b) For platforms not supported by Sun the user adds RXTXComm.jar to  
the classpath of the application (and librxtxSerial.jnilib to the  
application directory). Also he will need the 2.0.3 generic comm.jar  
from Sun.
3) Nobody messes with the global VM installation.

Of course 2a) and 2b) could be handled by the author of the program  
via an appropriate installer. The author could also decide to always  
use RXTX and include the generic javax.comm classes as well as the  
RXTX classes in his application jar. [If he further uses an explicit  
call to System.load() he may even include the jnilib(s) in the jar,  
extract it (based on the platform name) at runtime to a temp file and  
load it from there.]


Suggested solution:
------

We only need to put the following class in the classpath BEFORE Suns  
comm.jar

   package com.sun.comm;
   public class SolarisDriver extends gnu.io.RXTXCommDriver {
   }

This is not "the pure art" (TM). It depends on an implementation  
detail of the generic driver. However, so does the  
javax.comm.properties file - as we have seen when Sun released 3.0.  
It has the following advantages:

- The "generic" javax.comm implementation will happily load this  
class as its primary driver.
- No javax.comm.properties file is required.
- This does not violate the javax.comm license agreement as there is  
no mention of the "com.sun.comm" package in this license agreement at  
all.
- Authors packaging comm.jar with their application can strip out all  
com.sun.comm classes from comm.jar


Please comment!

Joachim



From joachim at buechse.de  Tue Jun 20 02:50:36 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 10:50:36 +0200
Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar
Message-ID: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>

There has been some discussions about the best way to install RXTX  
and where to place files.

I suggest that,

- we include the native libraries for the most common operating  
systems (in a special version of) RXTXcomm.jar
- we add loader code which tries to extract and load the platform  
specific binary at runtime
- on failure the current mechanism remains as a fallback

Wether the current mechanism should have priority (ie loadLibrary  
before load) remains to be discussed.


The advantages of this solution are
  - users of RXTX do not need to worry about java/platform specific  
file placement.
  - authors of applications may fully merge RXTX into their  
application jar (which provides a double-clickable application for  
Windows and OSX, Linux?).

Please comment,
Joachim

PS: Of course the suggested solution is already possible today,  
however relatively few programmers know how to correctly extract a  
binary resource file via the class loader and load it as a native  
library.


From tjarvi at qbang.org  Tue Jun 20 03:58:12 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT)
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
Message-ID: <Pine.LNX.4.61.0606200335190.14139@www>

> 2a) For platforms supported by Sun the user is free to use the 3.0
> comm.jar download from Sun
> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to
> the classpath of the application (and librxtxSerial.jnilib to the
> application directory). Also he will need the 2.0.3 generic comm.jar
> from Sun.

As there are no plans to support CommAPI 3.0 due to the limitations in its 
implementation mentioned before, I would not recommend projects use Sun's 
3.0 comm.jar.  They will lose the freedom to chose their low level 
implementation by being locked into vendor specific modifications.

Projects should chose between platform neutrality in CommAPI 2.0 and 
reduced platform neutrality in commapi 3.0.  Projects should also strongly 
consider the fact that the 2.0 comm.jar targets only a reduced number of 
JVMs.

Projects can go with rxtx 2.1 or other packages but should probably only 
consider using Sun CommAPI with rxtx if they did so in the past.  They 
should take steps to no longer depend upon this option being available.

> Suggested solution:
> ------
>
> We only need to put the following class in the classpath BEFORE Suns
> comm.jar
>
>   package com.sun.comm;
>   public class SolarisDriver extends gnu.io.RXTXCommDriver {
>   }
>
> This is not "the pure art" (TM). It depends on an implementation
> detail of the generic driver. However, so does the
> javax.comm.properties file - as we have seen when Sun released 3.0.
> It has the following advantages:
>
> - The "generic" javax.comm implementation will happily load this
> class as its primary driver.
> - No javax.comm.properties file is required.
> - This does not violate the javax.comm license agreement as there is
> no mention of the "com.sun.comm" package in this license agreement at
> all.
> - Authors packaging comm.jar with their application can strip out all
> com.sun.comm classes from comm.jar
>

I would not encourage people to place packages in the com.sun.comm 
namespace.  Authors using Sun's commapi 2.0 should just realize it is 
greatly limited in practical utility and consider moving to something that 
isn't being rescued from EOL.

The primary focus of this release is projects previously depending upon 
Sun CommAPI + RXTX.  There are no plans at this time to provide future 
support in this arrangement due to technical incompatabilities we have no 
control over in commapi 3.0 and limited utility of Sun's generic comm.jar 
in commapi 2.0 offered.  Projects should be aware of this so they can make 
appropriate plans.

--
Trent Jarvi
tjarvi at qbang.org


From paul.klissner at sun.com  Tue Jun 20 05:24:00 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Tue, 20 Jun 2006 04:24:00 -0700
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
In-Reply-To: <Pine.LNX.4.61.0606200335190.14139@www>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
	<Pine.LNX.4.61.0606200335190.14139@www>
Message-ID: <4497DAD0.10803@sun.com>

Trent Jarvi wrote:
>> 2a) For platforms supported by Sun the user is free to use the 3.0
>> comm.jar download from Sun
>> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to
>> the classpath of the application (and librxtxSerial.jnilib to the
>> application directory). Also he will need the 2.0.3 generic comm.jar
>> from Sun.
> 
> As there are no plans to support CommAPI 3.0 due to the limitations in its 
> implementation mentioned before, I would not recommend projects use Sun's 
> 3.0 comm.jar.  They will lose the freedom to chose their low level 
> implementation by being locked into vendor specific modifications.
> 
> Projects should chose between platform neutrality in CommAPI 2.0 and 
> reduced platform neutrality in commapi 3.0.  Projects should also strongly 
> consider the fact that the 2.0 comm.jar targets only a reduced number of 
> JVMs.

Well, that's a little ambiguous because the API is the same
either way.  We're talking about Sun's implementation vs.
other implementations.
> 
> Projects can go with rxtx 2.1 or other packages but should probably only 
> consider using Sun CommAPI with rxtx if they did so in the past.  They 
> should take steps to no longer depend upon this option being available.

3.0 is platform centric because there is a need to add some
platform awareness to Sun's implementation, and the choices
for how to do that are limited by the constraints of the API,
as mentioned in the javax.comm 2.0.3 comm.jar download's README.

I am really advocating getting a JSR open (http://www.jcp.org)
to push a new comm API that is more pluggable, platform neutral
and addresses some of the deficiencies of the current API. Then
we can achieve the optimal of platform neutrality while
simulataneously allowing the API to flexibly adapt to
heterogeneous environments.

This is not a question of attitude, this is an issue of resources,
time and commitment.  The current owners of javax.comm within
Sun would like nothing better than to see the ideal reached for
the API and a model that will extend well beyond the foreseeable
future and work for the industry overall.



> 
>> Suggested solution:
>> ------
>>
>> We only need to put the following class in the classpath BEFORE Suns
>> comm.jar
>>
>>   package com.sun.comm;
>>   public class SolarisDriver extends gnu.io.RXTXCommDriver {
>>   }
>>
>> This is not "the pure art" (TM). It depends on an implementation
>> detail of the generic driver. However, so does the
>> javax.comm.properties file - as we have seen when Sun released 3.0.
>> It has the following advantages:
>>
>> - The "generic" javax.comm implementation will happily load this
>> class as its primary driver.
>> - No javax.comm.properties file is required.
>> - This does not violate the javax.comm license agreement as there is
>> no mention of the "com.sun.comm" package in this license agreement at
>> all.
>> - Authors packaging comm.jar with their application can strip out all
>> com.sun.comm classes from comm.jar
>>
> 
> I would not encourage people to place packages in the com.sun.comm 
> namespace.  Authors using Sun's commapi 2.0 should just realize it is 
> greatly limited in practical utility and consider moving to something that 
> isn't being rescued from EOL.
> 
> The primary focus of this release is projects previously depending upon 
> Sun CommAPI + RXTX.  There are no plans at this time to provide future 
> support in this arrangement due to technical incompatabilities we have no 
> control over in commapi 3.0 and limited utility of Sun's generic comm.jar 
> in commapi 2.0 offered.  Projects should be aware of this so they can make 
> appropriate plans.

Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86,
or need the powerful portmapping features in javax.com 3.0, or would like to
acquire the Interactive Serial Port Test utility.

-Paul


From paul.klissner at sun.com  Tue Jun 20 05:33:44 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Tue, 20 Jun 2006 04:33:44 -0700
Subject: [Rxtx] Suggested installation RXTX 2.0x...
In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
Message-ID: <4497DD18.70207@sun.com>

Joachim Buechse wrote:
> Hello everybody,
> 
> I have been fighting a bit with the javax.comm version of RXTX the  
> last days. I am working on the README .OSX now and try to figure out  
> which should be the "suggested" installation.
> 
> The facts:
> ------
> 
> - the "generic" comm.jar version of javax.comm which has been made re- 
> available tries to load com.sun.comm.SolarisDriver
> - this classname can be overridden ONLY by putting a file  
> javax.comm.properties in {java.home}/lib
> - if it is not overridden and SolarisDriver.class is not found  
> CommPortIdentifier will be disfunctional (in particual it is not  
> possible to add CommPort's via CommPortIdentifier.add).
> - the license distributed with comm.jar does not allow the  
> modification/addition of classes in javax.comm (however no mention of  
> com.sun...)
> 
> 
> What really bothers me is to suggest putting this config file in the  
> "global" vm installation. This is particularly ugly on the Mac as  
> there are several VM installations and the file may be forgotten.  
> Additionally it may create versioning problems. I prefer an  
> installation where all files are local to the application (even  
> comm.jar).
> 
> In my opinion the ideal situation would be:
> ------
> 
> 1) The author of a program compiles against javax.comm.
> 2a) For platforms supported by Sun the user is free to use the 3.0  
> comm.jar download from Sun
> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to  
> the classpath of the application (and librxtxSerial.jnilib to the  
> application directory). Also he will need the 2.0.3 generic comm.jar  
> from Sun.
> 3) Nobody messes with the global VM installation.
> 
> Of course 2a) and 2b) could be handled by the author of the program  
> via an appropriate installer. The author could also decide to always  
> use RXTX and include the generic javax.comm classes as well as the  
> RXTX classes in his application jar. [If he further uses an explicit  
> call to System.load() he may even include the jnilib(s) in the jar,  
> extract it (based on the platform name) at runtime to a temp file and  
> load it from there.]
> 

This was how the Sun implementation originated (I did not write
that code).  I completely agree, and I fixed the whole conf file
locating mechanism in 3.0 to avoid the problems youmentioned.
However, I was unaware of how RxTx was using Sun's implementation,
so I didn't architect it in such a way as to avoid namespace pollution
in the native space in for the backend provider.  In retrospect,
I should have done that differently just as a design principle,
but at this point I don't have the spare cycles to get that all
re-factored.  Further, I'm loathe to do it, because the whole
thing will still be an under-the-hood hack due to the constraints
of the API itself.

Paul





From brian at mbari.org  Tue Jun 20 10:23:54 2006
From: brian at mbari.org (Brian Schlining)
Date: Tue, 20 Jun 2006 09:23:54 -0700
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>


Hi Joachim,

> There has been some discussions about the best way to install RXTX
> and where to place files.
>
> I suggest that,
>
> - we include the native libraries for the most common operating
> systems (in a special version of) RXTXcomm.jar
> - we add loader code which tries to extract and load the platform
> specific binary at runtime
> - on failure the current mechanism remains as a fallback

I like your suggestion. However, my understanding is that in general  
the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH  
(Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to  
be loaded by the JVM. The alternative is to point to your native lib  
directory using -Djava.library.path=/my/dir/with/native/libs when you  
launch the JVM. So, I'm very interested to know how you're planning  
to work around this.

> PS: Of course the suggested solution is already possible today,
> however relatively few programmers know how to correctly extract a
> binary resource file via the class loader and load it as a native
> library.

So how do you use it to dynamically load a native lib? I've read that  
you can't really modify the java.library.path after the JVM has been  
launched. (http://forum.java.sun.com/thread.jspa? 
threadID=627890&tstart=90)

Thanks

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0008.html

From joachim at buechse.de  Tue Jun 20 09:20:29 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 17:20:29 +0200
Subject: [Rxtx] 2.0x in sync with 2.1x
Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>

I have added most of the changes from the 2.1 branch to the 2.0 branch.

This includes
  - correction of illegal javadoc comments
  - implementation errors in handling of Thread.interrupt in  
RXTXPort.java
  - MacOS X locking without lock files/special user groups
  - XCode project which builds a universal binary library
  - updated documentation for OSX

I have done some minimal testing (only G4).
[Trent: there are still some changes you made for specific baud  
rates. I will not sync this, as I can not test them. From my  
perspective we are ready for 2.08/2.18]

The updated documentation can be found in the file README.OSX. Here  
it is:

------------------------ Required files -----------------------

To use or compile RXTX 2.0.x you need to downlad the "generic"  
version (2.0.3)
of the javax.comm implementation from Sun. The zip you download  
contains an
archive comm.jar which is required:

- To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar

- To run the app you will need comm.jar in the classpath or in  
{java.lib.path}


------------------------ Installation on MacOSX -----------------------

WARNING: Please read this section until the end.

---
Preparation
---

You may want to spare your users the burden of modifying the global VM
installation. OSX has several different VM versions installed by  
default and
regular users will be unable to figure out which version will load your
application.

If you provide the class

package com.sun.comm;
public class SolarisDriver extends gnu.io.RXTXCommDriver {
}

and make sure, that it is present in the classpath before Suns  
"generic" comm.jar
your users can skip the following step:

Create a file named
    javax.comm.properties
in the directory
    /System/Library/Frameworks/JavaVM.framework/Home/lib/
which contains (only) the following line (no leading space):
    Driver=gnu.io.RXTXCommDriver



----
The unsafe way of using RXTX on OS X:
----

RXTX can be installed by putting the files
   libSerial.jnilib
   RXTXcomm.jar
   comm.jar
into the folder
   /Library/Java/Extensions

This is NOT RECOMMENDED as it creates versioning conflicts among  
applications.
However you may be forced to install it this way if an application  
was written
for Windows or Linux, requires RXTX and you are not able to change  
its starter.


----
The safe way of using RXTX on OS X:
----

Make sure that you have no (older) version of RXTX installed in
   /Library/Java/Extensions
   /System/Library/Java/Extensions
   /usr/lib/java

Put
   libSerial.jnilib
in the directory of the application (the JavaVM will find it there). Add
   RXTXComm.jar
   comm.jar
to the application classpath or include the classes in the  
application jar.
(Some applications already include the RXTX classes in their  
application jar,
in which case only the file libSerial.jnilib is required).


----
History
----

Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation  
of lockfiles
required special permissions for the user executing an application  
based on RXTX.
To simplify the setup RXTX came with an installer modifying group  
permissions
and installing RXTX in the global location /Library/Java/Extensions.  
However
this was prune to versioning conflicts and is no longer recommended.

--------------------- Build instructions for OSX XCode  
-------------------

contributed by Joachim Buechse <joachim at buechse.de>
original version by Dmitry Markman <dmarkman at mac.com>

System requirements for building:
MacOSX 10.4
XCode 2.3

   open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj
   choose libSerial.jnilib target
   build

After the build you will find RXTXcomm.jar and libSerial.jnilib files  
in the
directory build/Development.

In case you can't find RXTXcomm.jar build the RXTXcomm target manually.
In case of (serious) problems feel free to contact joachim at buechse.de .



From tjarvi at qbang.org  Tue Jun 20 22:01:45 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT)
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
Message-ID: <Pine.LNX.4.61.0606202127270.14139@www>

> ---
> Preparation
> ---
>
> You may want to spare your users the burden of modifying the global VM
> installation. OSX has several different VM versions installed by
> default and
> regular users will be unable to figure out which version will load your
> application.
>
> If you provide the class
>
> package com.sun.comm;
> public class SolarisDriver extends gnu.io.RXTXCommDriver {
> }
>
> and make sure, that it is present in the classpath before Suns
> "generic" comm.jar
> your users can skip the following step:

Hi Joachim

With regards to the above, I have not seen that we have Sun's OK to 
promote that.  I'm not very comfortable with the distribution 
documentation advocating this without Sun agreeing.

I see your point but I'd rather not actively promote putting classes in 
Sun's namespace without permission if you don't mind.  This isn't about 
what is in a license.

I'll go through the code tomorrow night.  It was a late night at work 
today.  There is also a w32 fix comming for people opening and closing 
multiple ports.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Wed Jun 21 01:56:45 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 21 Jun 2006 09:56:45 +0200
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <Pine.LNX.4.61.0606202127270.14139@www>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
	<Pine.LNX.4.61.0606202127270.14139@www>
Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>

Hello Trent,

I guess we will not get an explicit OK from Sun for such a hack. I  
think Paul has made it pretty clear, that he does not have the  
resources to modify the 2.x or 3.x code for the needs of RXTX. I'm  
not thrilled but OK with the current API. Hence I dont agree with  
Paul's idea to start a new JSR to fix the implementation - but that's  
mainly because I dont have the time to push it. According to their  
Readme Sun sees no business case in having cross platform support for  
javax.comm - that is sad but it's none of my business. However I  
prefer to program versus javax.comm in my projects as this gives an  
advanced user the chance to exchange the provider without access to  
the code.

I interpret Pauls reponse to my original "Request for comment" as a  
quiet acceptance of the hack I propose (he did respond, but not at  
all to the sun.comm namespace suggestion). This is certainly not  
something we should put into RXTXcomm.jar but hinting a work around  
for implementation errors should be allowed. That's why I've choosen  
the wording "You may want to spare" and "If you provide". The company  
I worked for has choosen similar hacks for years to fix bugs in swing  
for JDK1.1 applications. Those hacks were usually included in their  
own swingpatch.jar.

Having said all that - I do not take it as an insult if you remove  
the paragraph from the Readme. I appreciate that you notified me  
before. It would be interesting to hear some more opinions from the  
list members...

Best regards,
Joachim


On 21.06.2006, at 06:01, Trent Jarvi wrote:

>> ---
>> Preparation
>> ---
>>
>> You may want to spare your users the burden of modifying the  
>> global VM
>> installation. OSX has several different VM versions installed by
>> default and
>> regular users will be unable to figure out which version will load  
>> your
>> application.
>>
>> If you provide the class
>>
>> package com.sun.comm;
>> public class SolarisDriver extends gnu.io.RXTXCommDriver {
>> }
>>
>> and make sure, that it is present in the classpath before Suns
>> "generic" comm.jar
>> your users can skip the following step:
>
> Hi Joachim
>
> With regards to the above, I have not seen that we have Sun's OK to
> promote that.  I'm not very comfortable with the distribution
> documentation advocating this without Sun agreeing.
>
> I see your point but I'd rather not actively promote putting  
> classes in
> Sun's namespace without permission if you don't mind.  This isn't  
> about
> what is in a license.
>
> I'll go through the code tomorrow night.  It was a late night at work
> today.  There is also a w32 fix comming for people opening and closing
> multiple ports.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Wed Jun 21 02:03:33 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 21 Jun 2006 10:03:33 +0200
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
	<6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
Message-ID: <BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>

See System.load(String) [it's also mentioned under the URL you posted].

Regards,
Joachim


On 20.06.2006, at 18:23, Brian Schlining wrote:

> So how do you use it to dynamically load a native lib? I've read  
> that you can't really modify the java.library.path after the JVM  
> has been launched. (http://forum.java.sun.com/thread.jspa? 
> threadID=627890&tstart=90)
>
> Thanks
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From baris.ozkan at elikasu.com.tr  Wed Jun 21 07:58:06 2006
From: baris.ozkan at elikasu.com.tr (Baris)
Date: Wed, 21 Jun 2006 16:58:06 +0300
Subject: [Rxtx] RS 232 ..additional parameters
Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>

Hi,
 
Currently i am developing an application that requires to connect to a
remote rs232 device through  a dialup connection.
 
My problem is that the communication needs several more connection
parameters (i extracted that information from the vendor's dll , listed at
the end of the message)
 
I explored rxtx API and src files and could not find methods to set a
majority  of the parameters.
Am i missing any point or does rxtx is limited to soem standard set of
functionality(e.g. commAPI)? How  is it possible ,if i want to put some
extensions(???) to current rxtx implementation?
 
I am not very good at rs232 programming so excuse me if this message  is
boring one.
 
Thanx
 
Baris Ozkan
 
 
A Listing of Parameters:
 
 
typedef struct _DCB {

DWORD DCBlength; /* sizeof(DCB) */

DWORD BaudRate; /* Baudrate at which running */

DWORD fBinary: 1; /* Binary Mode (skip EOF check) */

DWORD fParity: 1; /* Enable parity checking */

DWORD fOutxCtsFlow:1; /* CTS handshaking on output */

DWORD fOutxDsrFlow:1; /* DSR handshaking on output */

DWORD fDtrControl:2; /* DTR Flow control */

DWORD fDsrSensitivity:1; /* DSR Sensitivity */

DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */

DWORD fOutX: 1; /* Enable output X-ON/X-OFF */

DWORD fInX: 1; /* Enable input X-ON/X-OFF */

DWORD fErrorChar: 1; /* Enable Err Replacement */

DWORD fNull: 1; /* Enable Null stripping */

DWORD fRtsControl:2; /* Rts Flow control */

DWORD fAbortOnError:1; /* Abort all reads and writes on Error */

DWORD fDummy2:17; /* Reserved */

WORD wReserved; /* Not currently used */

WORD XonLim; /* Transmit X-ON threshold */

WORD XoffLim; /* Transmit X-OFF threshold */

BYTE ByteSize; /* Number of bits/byte, 4-8 */

BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */

BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */

char XonChar; /* Tx and Rx X-ON character */

char XoffChar; /* Tx and Rx X-OFF character */

char ErrorChar; /* Error replacement char */

char EofChar; /* End of Input character */

char EvtChar; /* Received Event character */

WORD wReserved1; /* Fill for now. */

} DCB, *LPDCB;

typedef struct _COMMTIMEOUTS {

DWORD ReadIntervalTimeout; /* Maximum time between read chars. */

DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */

DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */

DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */

DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */

} COMMTIMEOUTS,*LPCOMMTIMEOUTS;

dcb.fOutX = FALSE;

dcb.fInX = FALSE;

dcb.fOutxCtsFlow = FALSE;

dcb.fBinary = TRUE;

dcb.fRtsControl = RTS_CONTROL_ENABLE;

SetCommState(hComm , &dcb ); 

COMMTIMEOUTS commTimeOut;

GetCommTimeouts(hComm, &commTimeOut );

commTimeOut.WriteTotalTimeoutMultiplier = 1; 

commTimeOut.WriteTotalTimeoutConstant = 18; 

// commTimeOut.ReadIntervalTimeout = 28; 

commTimeOut.ReadIntervalTimeout = 0; 

// commTimeOut.ReadTotalTimeoutMultiplier = 184; 

commTimeOut.ReadTotalTimeoutMultiplier = 300; 

// commTimeOut.ReadTotalTimeoutConstant = 1200;

commTimeOut.ReadTotalTimeoutConstant = 1200;

SetCommTimeouts(hComm, &commTimeOut);

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0008.html

From ajmas at sympatico.ca  Wed Jun 21 08:14:26 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Wed, 21 Jun 2006 10:14:26 -0400
Subject: [Rxtx] When is 2.18 planned for?
Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

Just curious as to know if there is a target date for 2.18?

Andre



From brian at mbari.org  Wed Jun 21 09:36:00 2006
From: brian at mbari.org (Brian Schlining)
Date: Wed, 21 Jun 2006 08:36:00 -0700
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
	<6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
	<BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>
Message-ID: <A21C9BC0-7894-4B08-AC82-44E11AB3D461@mbari.org>

Ha!!

I suppose I should read my own postings. ;-)

Thanks
B

On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote:

> See System.load(String) [it's also mentioned under the URL you  
> posted].
>
> Regards,
> Joachim
>
>
> On 20.06.2006, at 18:23, Brian Schlining wrote:
>
>> So how do you use it to dynamically load a native lib? I've read
>> that you can't really modify the java.library.path after the JVM
>> has been launched. (http://forum.java.sun.com/thread.jspa?
>> threadID=627890&tstart=90)

Brian Schlining
Software Engineer
http://www.mbari.org




From ajmas at sympatico.ca  Wed Jun 21 16:41:28 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Wed, 21 Jun 2006 18:41:28 -0400
Subject: [Rxtx] CVS build question
Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X:

 The JCL extension to RxTx requires comm.jar
 If you intend to use RxTx for commapi support comm.jar
 needs to be located in  /System/Library/Frameworks/JavaVM.framework/
  Versions/1.5/Home/lib/ext/comm.jar

I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me.

On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native).

Andre






From tjarvi at qbang.org  Wed Jun 21 18:00:04 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT)
Subject: [Rxtx] CVS build question
In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606211756310.14139@www>

On Wed, 21 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> Is the CVS repository meant to build for gnu.io or javax.comm? I ask 
> this, because I see the following when calling ./configure from MacOS X:
>
> The JCL extension to RxTx requires comm.jar
> If you intend to use RxTx for commapi support comm.jar
> needs to be located in  /System/Library/Frameworks/JavaVM.framework/
>  Versions/1.5/Home/lib/ext/comm.jar
>
> I am wanting to build for the gnu.io package, since I want to jump ahead 
> and see if the changes, intended for 2.18 for MacOS X, work for me.
>
> On a side note /Library/Java/Extensions should be included as a valid 
> search path for the JAR, since this is where Apple recommends placing 
> third party extensions (both Java and native).
>

rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel"
rxtx 2.0 src is obtained with "cvs checkout rxtx-devel"

rxtx 2.1 is a complete package in namespace gnu.io
rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 18:02:23 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT)
Subject: [Rxtx] When is 2.18 planned for?
In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606211800180.14139@www>

On Wed, 21 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> Just curious as to know if there is a target date for 2.18?
>

Hi Andre

"When it is ready" :)

Probably this weekend.  Maybe sooner.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 18:10:18 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT)
Subject: [Rxtx] RS 232 ..additional parameters
In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>
References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>
Message-ID: <Pine.LNX.4.61.0606211805010.14139@www>

On Wed, 21 Jun 2006, Baris wrote:

> Hi,
>
> Currently i am developing an application that requires to connect to a
> remote rs232 device through  a dialup connection.
>
> My problem is that the communication needs several more connection
> parameters (i extracted that information from the vendor's dll , listed at
> the end of the message)
>
> I explored rxtx API and src files and could not find methods to set a
> majority  of the parameters.
> Am i missing any point or does rxtx is limited to soem standard set of
> functionality(e.g. commAPI)? How  is it possible ,if i want to put some
> extensions(???) to current rxtx implementation?
>
> I am not very good at rs232 programming so excuse me if this message  is
> boring one.
>
> Thanx
>

Hi Baris

> typedef struct _DCB {
> typedef struct _COMMTIMEOUTS {

These are all handled in termios.c.  It is possible to add extensions to 
rxtx 2.1.  It may well be that the defaults are the same for the variables 
not covered by the existing API.  You can dump the DCB and COMMTIMEOUTS 
from inside termios.c to compare.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 20:23:30 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT)
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
	<Pine.LNX.4.61.0606202127270.14139@www>
	<789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>
Message-ID: <Pine.LNX.4.61.0606212012210.14139@www>

> I'm
> not thrilled but OK with the current API. Hence I dont agree with
> Paul's idea to start a new JSR to fix the implementation - but that's
> mainly because I dont have the time to push it. According to their
> Readme Sun sees no business case in having cross platform support for
> javax.comm - that is sad but it's none of my business. However I
> prefer to program versus javax.comm in my projects as this gives an
> advanced user the chance to exchange the provider without access to
> the code.

Hi Joachim

With regards to the JSR, I think that would be Doug's call.  The effort I 
put in would have to be on my own time which would not be a great deal.  I 
could help things go smoothly but thats not the same as pushing something 
through.

--
Trent Jarvi
tjarvi at qbang.org



From vt at freehold.crocodile.org  Wed Jun 21 21:05:22 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Wed, 21 Jun 2006 20:05:22 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
Message-ID: <449A08F2.3020106@freehold.crocodile.org>

Hello all,

I know this question may belong to JSR lists, but since all interested 
parties are here, I thought I just ask this question here, again...

A while ago I run into a problem and wrote a rant, here: 
http://servomaster.sourceforge.net/dev/serial-usb.html
At the time of writing I didn't think of adding another possible 
solution - changing the CommAPI specs to support removable devices. 
Apparently, Serial/USB bridges are here to stay, and this issue has to 
be addressed.

Wonder if anything changed since, and any abstractions for supporting 
removable devices made it into current or future Java CommAPI drafts - 
Paul, any comments?

--vt



From joachim at buechse.de  Thu Jun 22 01:59:54 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 22 Jun 2006 09:59:54 +0200
Subject: [Rxtx] CVS build question
In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de>

Hello Andre,

I am not sure how well the configure/make mechanism will work on OSX.  
I know that a while ago some contributors tried to get configure/make  
working on OSX but from comments I found in the readmes this work was  
only partially successfull. For compilation on OSX we have used the  
ProjectBuilder/XCode projects you can find in MACOSX_IDE.

Regarding the  ./configure comment:
RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config  
file javax.comm.properties. The later MUST reside in {java.home}/lib.  
As the two only work together putting comm.jar into  /Library/Java/ 
Extensions  and hence making it available to all current and future  
VM installations will only add to confusion.

Regards,
Joachim

On 22.06.2006, at 00:41, Andre-John Mas wrote:

> Hi,
>
> Is the CVS repository meant to build for gnu.io or javax.comm? I  
> ask this, because I see the following when calling ./configure from  
> MacOS X:
>
>  The JCL extension to RxTx requires comm.jar
>  If you intend to use RxTx for commapi support comm.jar
>  needs to be located in  /System/Library/Frameworks/JavaVM.framework/
>   Versions/1.5/Home/lib/ext/comm.jar
>
> I am wanting to build for the gnu.io package, since I want to jump  
> ahead and see if the changes, intended for 2.18 for MacOS X, work  
> for me.
>
> On a side note /Library/Java/Extensions should be included as a  
> valid search path for the JAR, since this is where Apple recommends  
> placing third party extensions (both Java and native).
>
> Andre
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Thu Jun 22 02:51:05 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 22 Jun 2006 10:51:05 +0200
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449A08F2.3020106@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>

Hello Vadim,

I think that your rant is to the point. However it is a bit like  
saying that Windows is at the source of email degradation and the  
only solution is to have users switch to safer operating systems.

I don't see how javax.comm or RXTX can address the problems you  
mention. Of course it would be super cool if javax.comm could magicly  
find the "matching" usb-device and query it's configuration via the  
usb protocol - however this magic (mapping /dev/xyz to its underlying  
USB device) is not supported by any kernel APIs I am aware of. It  
could be supported via POSSIX ioctl calls but then you should address  
your rant to the POSSIX group...

So for the time beeing it's either up to the virtual comm port driver  
to provide a usefull name under /dev/ or to the user choosing the  
right port to use. One example of a smart(er) com port driver is the  
KDDI driver for OSX, which will create device names like "/dev/ 
cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- 
encoded into the bridge chip. The same driver for windows also has  
some options allowing it in theory to recreate the same COMx every  
time a device is plugged/unplugged.

For most industrial applications however it will be up to the user to  
choose the right port (without getting a lot of help doing so).

Probing serial ports can go wrong, that's right. However any serial  
device developper would be well adviced to implement a basic set of  
Hayes AT modem commands (be it a modem or not). Especially AT I0.  
Anyone failing to do so risks that the users favourite TCP/PPP/FAX  
application or stack will kill the device in short time.

Best regards,
Joachim


On 22.06.2006, at 05:05, Vadim Tkachenko wrote:

> Hello all,
>
> I know this question may belong to JSR lists, but since all interested
> parties are here, I thought I just ask this question here, again...
>
> A while ago I run into a problem and wrote a rant, here:
> http://servomaster.sourceforge.net/dev/serial-usb.html
> At the time of writing I didn't think of adding another possible
> solution - changing the CommAPI specs to support removable devices.
> Apparently, Serial/USB bridges are here to stay, and this issue has to
> be addressed.
>
> Wonder if anything changed since, and any abstractions for supporting
> removable devices made it into current or future Java CommAPI drafts -
> Paul, any comments?
>
> --vt
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From vt at freehold.crocodile.org  Thu Jun 22 13:16:03 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 12:16:03 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
Message-ID: <20060622191603.GA17487@freehold.crocodile.org>

Hello Joachim,

> I think that your rant is to the point. However it is a bit like  
> saying that Windows is at the source of email degradation and the  
> only solution is to have users switch to safer operating systems.

I guess the problem is that the rant itself is obsolete and has to be
updated according to latest developments. At the time of writing there
weren't that many bridges around, and the trend didn't manifest itself as it
does now.

> I don't see how javax.comm or RXTX can address the problems you  
> mention.

I would agree that javax.comm won't be able to address the problem, at least
in the short run. As for RxTx - well, nobody prevents it from being a
superset of CommAPI specification, right? RxTx being the de-facto standard
for quite a few platforms, I'd daresay the standard may follow.

> Of course it would be super cool if javax.comm could magicly find the
> "matching" usb-device and query it's configuration via the usb protocol -
> however this magic (mapping /dev/xyz to its underlying USB device) is not
> supported by any kernel APIs I am aware of. It could be supported via
> POSSIX ioctl calls but then you should address your rant to the POSSIX
> group...

As a matter of fact, my bigger concern is addressing the fact that a serial
device can now be removable. This hasn't been the case before, and it
clearly is now. Regarding the above, well, I guess if we accept this fact,
we also need to accept the fact that we need at least rudimentary means of
identification of a serial device. For the USB case, it would usually be the
vendor/product ID, plus possible serial number - but it is irrelevant what
exactly the identifying information is, as long as it allows to identify the
device.

A paradigm shift is required, this is what I wanted to say. Serial devices
can be removed and replaced, it's now our turn to learn to deal with it.

> Joachim

--vt


From jredman at ergotech.com  Thu Jun 22 13:41:44 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 13:41:44 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
Message-ID: <449AF278.6000903@ergotech.com>


Vadim Tkachenko wrote:
> A paradigm shift is required, this is what I wanted to say. Serial devices
> can be removed and replaced, it's now our turn to learn to deal with it.

The removal if the serial port hardly significantly different from the 
removal of the device attached to the serial port.   Different, 
slightly, but not a "paradigm shift".

And yes, someone could unplug a USB serial device and plug it into a 
different USB port so that it has a different name/number, but they 
could do that with the device itself, move it from com1 to com2.

Am I missing something?

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 13:57:27 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 12:57:27 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449AF278.6000903@ergotech.com>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
Message-ID: <20060622195727.GA20247@freehold.crocodile.org>

On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote:
> 
> Vadim Tkachenko wrote:
> > A paradigm shift is required, this is what I wanted to say. Serial devices
> > can be removed and replaced, it's now our turn to learn to deal with it.
> 
> The removal if the serial port hardly significantly different from the 
> removal of the device attached to the serial port.   Different, 
> slightly, but not a "paradigm shift".
> 
> And yes, someone could unplug a USB serial device and plug it into a 
> different USB port so that it has a different name/number, but they 
> could do that with the device itself, move it from com1 to com2.
> 
> Am I missing something?

Yes, the fact that they could unplug a device A and plug a device B. With
the introduction of the concept of removability, the notion of the serial
port itself is not as important anymore, but the notion of the unique device
identifier is.

Consider a situation: long running system (enterprise HVAC, tens of nodes,
tens of thousands square feet area, hundreds of thousand dollars worth of
equipment being conditioned, can't shut down), serial/usb device fails, is
replaced by an identical device with a different serial #.

A little bit farfetched, but hopefully highlighting the point I'm trying to
make.

> Jim

--vt


From jredman at ergotech.com  Thu Jun 22 14:37:38 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 14:37:38 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>	<20060622191603.GA17487@freehold.crocodile.org>	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
Message-ID: <449AFF92.8080003@ergotech.com>


Vadim Tkachenko wrote:
>>
>> Am I missing something?
> 
> Yes, the fact that they could unplug a device A and plug a device B. With
> the introduction of the concept of removability, the notion of the serial
> port itself is not as important anymore, but the notion of the unique device
> identifier is.

Serial devices are always removable.  I could unplug _serial_ device A 
and plug in _serial_ device B.  We have systems running with two RS485 
ports, one talks to a Modbus PLC network one to a number of drives on a 
proprietary protocol.  If you plug the wrong DB9 into the wrong port the 
application doesn't work.

If you dangle a USB 485 converter on the end of the DB9 you've just 
moved the problem from RS485 to USB, but the problem/effect is the same.

> 
> Consider a situation: long running system (enterprise HVAC, tens of nodes,
> tens of thousands square feet area, hundreds of thousand dollars worth of
> equipment being conditioned, can't shut down), serial/usb device fails, is
> replaced by an identical device with a different serial #.
> 
> A little bit farfetched, but hopefully highlighting the point I'm trying to
> make.

Nothing's changed.  If I had a 4 port ISA board and plugged it into my 
new shiny '386 machine.  I could have com ports 9-12.  If I took a board 
off the shelf and didn't set the jumpers, I would have com ports 3-6.

The problem's the same.  If you replace with identical product then the 
com ports  will be the same - no software changes required.  If you 
replace one piece of hardware with hardware from a different 
manufacturer, then the naming/numbering may change.  You're physically 
changing the system, so may reasonably expect to have to make a software 
change.  RXTX actually handles this situation quite well with the -D 
command line option.  (My experience has generally been that the port 
number depends more on the USB port used than the hardware - so the 
chances are even with a hardware change the port number/name will be the 
same.)

Slightly Off Topic - there is a reason why industrial users will pay a 
premium for continued availability of hardware.  Yes you can mail-order 
a $10 USB converter and it will work, but there's no guarantee that the 
next time you buy the same part number from the same vendor it will be 
the same.  The industrial vendors will charge you $100+ for the same 
item, but it will be the same every time you buy it for the next 5 to 10 
years.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 14:37:19 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 13:37:19 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
Message-ID: <20060622203719.GA22521@freehold.crocodile.org>

Hello again,

And while I'm at it, why don't just say this: give me one good reason to
write 3+ different ways of handling removable devices, one for USB, one for
FireWire, one for serial...

I understand very well that this goes way beyond the scope of RxTx and
CommAPI and will require cooperation between them and javax.usb and whatever
JSR is responsible for FireWire implementation - but the end result is well
worth it. Abstract out and generalize arrival/departure/monitoring/discovery
API, provide protocol specific extensions for each, live happily ever after.

--vt


On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote:
> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote:
> > 
> > Vadim Tkachenko wrote:
> > > A paradigm shift is required, this is what I wanted to say. Serial devices
> > > can be removed and replaced, it's now our turn to learn to deal with it.
> > 
> > The removal if the serial port hardly significantly different from the 
> > removal of the device attached to the serial port.   Different, 
> > slightly, but not a "paradigm shift".
> > 
> > And yes, someone could unplug a USB serial device and plug it into a 
> > different USB port so that it has a different name/number, but they 
> > could do that with the device itself, move it from com1 to com2.
> > 
> > Am I missing something?
> 
> Yes, the fact that they could unplug a device A and plug a device B. With
> the introduction of the concept of removability, the notion of the serial
> port itself is not as important anymore, but the notion of the unique device
> identifier is.
> 
> Consider a situation: long running system (enterprise HVAC, tens of nodes,
> tens of thousands square feet area, hundreds of thousand dollars worth of
> equipment being conditioned, can't shut down), serial/usb device fails, is
> replaced by an identical device with a different serial #.
> 
> A little bit farfetched, but hopefully highlighting the point I'm trying to
> make.
> 
> > Jim
> 
> --vt
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx


From jredman at ergotech.com  Thu Jun 22 15:13:49 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 15:13:49 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>	<20060622191603.GA17487@freehold.crocodile.org>	<449AF278.6000903@ergotech.com>	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
Message-ID: <449B080D.9080208@ergotech.com>


Vadim Tkachenko wrote:
> Hello again,
> 
> And while I'm at it, why don't just say this: give me one good reason to
> write 3+ different ways of handling removable devices, one for USB, one for
> FireWire, one for serial...

You don't, they're all the same "I have lost communication with my 
serial device".

The only thing you could really do is improve error reporting by knowing 
the exact sub-system.  ("Device X which is/was attached to USB port Y is 
no longer functioning, please check the USB ports, the device, the 
cables and anything else you can think of that may be a cause of 
failure.")  That just requires an intelligent description of the port.

> I understand very well that this goes way beyond the scope of RxTx and
> CommAPI and will require cooperation between them and javax.usb and whatever
> JSR is responsible for FireWire implementation - but the end result is well
> worth it. Abstract out and generalize arrival/departure/monitoring/discovery
> API, provide protocol specific extensions for each, live happily ever after.

There's a huge list of pseudo-serial devices each with a different set 
of requirements, Bluetooth, RFC 2217, a host of proprietary systems, 
etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I 
have no clue how you'd implement them in a general/cross platform sense.

You haven't convinced me (and only me, others may see something that I 
don't, I'm not speaking for them) that this mechanism can be implemented 
in any practical sense.  That is, that the implementation could be wide 
enough to be consider generally available in RXTX regardless of the 
serial port implementation, platform, etc..  However, if you can come up 
with a general design and a reference implementation for one subsystem, 
I'd like to see it and might get on board.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 15:40:55 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 14:40:55 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449B080D.9080208@ergotech.com>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
Message-ID: <20060622214055.GA25497@freehold.crocodile.org>

On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote:
> 
> Vadim Tkachenko wrote:
> > Hello again,
> > 
> > And while I'm at it, why don't just say this: give me one good reason to
> > write 3+ different ways of handling removable devices, one for USB, one for
> > FireWire, one for serial...
> 
> You don't, they're all the same "I have lost communication with my 
> serial device".

"I have lost communication with my ${protocol} device".

> The only thing you could really do is improve error reporting by knowing 
> the exact sub-system.  ("Device X which is/was attached to USB port Y is 
> no longer functioning, please check the USB ports, the device, the 
> cables and anything else you can think of that may be a cause of 
> failure.")

"Device ${id} which is/was attached to ${protocol} port ${port} is no longer
functioning, please check the ${protocol} ports, the device, the
${protocol_media} and anything else you can think of that may be a cause of
failure".

>  That just requires an intelligent description of the port.

Agree absolutely.

> > I understand very well that this goes way beyond the scope of RxTx and
> > CommAPI and will require cooperation between them and javax.usb and whatever
> > JSR is responsible for FireWire implementation - but the end result is well
> > worth it. Abstract out and generalize arrival/departure/monitoring/discovery
> > API, provide protocol specific extensions for each, live happily ever after.
> 
> There's a huge list of pseudo-serial devices each with a different set 
> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, 
> etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I 
> have no clue how you'd implement them in a general/cross platform sense.

That's because some of the protocols were created decades ago when
autoconfiguration wasn't even conceived, much less practical. RS232/RS485
don't have a clue about identity discovery, and even capabilities discovery
beyond obvious 8N1 etc.

I agree that today all these protocols have generally incompatible
strategies for handling the situations I'm trying to address, but there's
nothing that says it's not an oversight. Besides, we're dealing with the
devices at a level of abstraction that allows some simplifications and
generalizations, at least part of the time - unless it's the protocol
specific features we're dealing with.

> You haven't convinced me (and only me, others may see something that I 
> don't, I'm not speaking for them) that this mechanism can be implemented 
> in any practical sense.  That is, that the implementation could be wide 
> enough to be consider generally available in RXTX regardless of the 
> serial port implementation, platform, etc..  However, if you can come up 
> with a general design and a reference implementation for one subsystem, 
> I'd like to see it and might get on board.

Actually, I wasn't even thinking about all this stuff when I wrote the first
message on the subject :) Now that you mention it - well, I'm not sure I can
chew the piece I just tried to bite in reasonable amount of time.

How do you eat an elephant? One bite at a time. If we could agree that a
small step in the specification is acceptable at this time, and express
further intentions, things may start happening.

To put it succinctly:

- Concept of a "port" should be augmented with a concept of a "device". A
device may be attached to a port in an implicit or explicit way.
- Implicitly connected device is exactly what the current scope of the
specification covers. No new functionality is offered.
- Explicitly connected device supports detachable device semantics, just as
other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a
few).
- The input and output streams are not properties of a port now, but
properties of the device attached to the port.
- A mechanism to allow listening for device arrivals and departures must be
made available.

That's it, off the top of my head.

I understand that this goes completely against current javax.comm specs, but
an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be
difficult to implement without disrupting javax.comm compatibility.

One concern is how to deal with the device identity - but there's no general
way of dealing with this at this time, devices may or may not offer identity
discovery.

> Jim

--vt


From joachim at buechse.de  Fri Jun 23 02:12:43 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 23 Jun 2006 10:12:43 +0200
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
Message-ID: <CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>

Hello++ Vadim,

I would like to repeat that your request is best addressed to the  
POSSIX standardization group - or maybe the BSD/Linux maintainers. If  
you convince the BSD or Linux guys to add this kind of functionality  
(they can as most of there VCP drivers are open source), there is a  
certain chance that other vendors will pick it up. I assure you that  
RXTX will happily provide this functionality once it's possible - I'm  
sure there is more than one maintainer that would love to add it.  
Having this concept penetrate the market may take some years though.

SHORT: The solution you would like to see could be added to the API  
but it can not be implemented (at least not on the platforms I know).  
There are currently no hooks in the kernel that allow you to discover  
"the device" or even the "means of connection" based on an existing  
"device file descriptor" ie COM-port or /dev/... entry. The name  
mapping of the device is handled by the virtual com port driver of  
the device. Unless you are suggesting RXTX should reimplement virtual  
com port drivers for all usb/serial bridges out there your request is  
understandable from a users viewpoint but simply not realizable. It's  
like asking that the Socket api should identify the computer behind  
an IP address (ie by its Ethernet address). While this COULD be  
implemented in TCP/IP, it IS not, and hence there is no point adding  
such a function to the Socket API.

The current trend for USB/Bluetooth/Irda/etc connected devices is  
going away from serial port abstraction towards RPC (ie the drivers  
provide a device specific or device class specific driver that  
provides an application level api to the device functions). The line  
level protocol is often not even published.

Best regards,
Joachim

On 22.06.2006, at 23:40, Vadim Tkachenko wrote:

> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote:
>>
>> Vadim Tkachenko wrote:
>>> Hello again,
>>>
>>> And while I'm at it, why don't just say this: give me one good  
>>> reason to
>>> write 3+ different ways of handling removable devices, one for  
>>> USB, one for
>>> FireWire, one for serial...
>>
>> You don't, they're all the same "I have lost communication with my
>> serial device".
>
> "I have lost communication with my ${protocol} device".
>
>> The only thing you could really do is improve error reporting by  
>> knowing
>> the exact sub-system.  ("Device X which is/was attached to USB  
>> port Y is
>> no longer functioning, please check the USB ports, the device, the
>> cables and anything else you can think of that may be a cause of
>> failure.")
>
> "Device ${id} which is/was attached to ${protocol} port ${port} is  
> no longer
> functioning, please check the ${protocol} ports, the device, the
> ${protocol_media} and anything else you can think of that may be a  
> cause of
> failure".
>
>>  That just requires an intelligent description of the port.
>
> Agree absolutely.
>
>>> I understand very well that this goes way beyond the scope of  
>>> RxTx and
>>> CommAPI and will require cooperation between them and javax.usb  
>>> and whatever
>>> JSR is responsible for FireWire implementation - but the end  
>>> result is well
>>> worth it. Abstract out and generalize arrival/departure/ 
>>> monitoring/discovery
>>> API, provide protocol specific extensions for each, live happily  
>>> ever after.
>>
>> There's a huge list of pseudo-serial devices each with a different  
>> set
>> of requirements, Bluetooth, RFC 2217, a host of proprietary systems,
>> etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I
>> have no clue how you'd implement them in a general/cross platform  
>> sense.
>
> That's because some of the protocols were created decades ago when
> autoconfiguration wasn't even conceived, much less practical. RS232/ 
> RS485
> don't have a clue about identity discovery, and even capabilities  
> discovery
> beyond obvious 8N1 etc.
>
> I agree that today all these protocols have generally incompatible
> strategies for handling the situations I'm trying to address, but  
> there's
> nothing that says it's not an oversight. Besides, we're dealing  
> with the
> devices at a level of abstraction that allows some simplifications and
> generalizations, at least part of the time - unless it's the protocol
> specific features we're dealing with.
>
>> You haven't convinced me (and only me, others may see something  
>> that I
>> don't, I'm not speaking for them) that this mechanism can be  
>> implemented
>> in any practical sense.  That is, that the implementation could be  
>> wide
>> enough to be consider generally available in RXTX regardless of the
>> serial port implementation, platform, etc..  However, if you can  
>> come up
>> with a general design and a reference implementation for one  
>> subsystem,
>> I'd like to see it and might get on board.
>
> Actually, I wasn't even thinking about all this stuff when I wrote  
> the first
> message on the subject :) Now that you mention it - well, I'm not  
> sure I can
> chew the piece I just tried to bite in reasonable amount of time.
>
> How do you eat an elephant? One bite at a time. If we could agree  
> that a
> small step in the specification is acceptable at this time, and  
> express
> further intentions, things may start happening.
>
> To put it succinctly:
>
> - Concept of a "port" should be augmented with a concept of a  
> "device". A
> device may be attached to a port in an implicit or explicit way.
> - Implicitly connected device is exactly what the current scope of the
> specification covers. No new functionality is offered.
> - Explicitly connected device supports detachable device semantics,  
> just as
> other protocols do (USB, FireWire, Wireless USB, Bluetooth, to  
> mention a
> few).
> - The input and output streams are not properties of a port now, but
> properties of the device attached to the port.
> - A mechanism to allow listening for device arrivals and departures  
> must be
> made available.
>
> That's it, off the top of my head.
>
> I understand that this goes completely against current javax.comm  
> specs, but
> an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern )  
> won't be
> difficult to implement without disrupting javax.comm compatibility.
>
> One concern is how to deal with the device identity - but there's  
> no general
> way of dealing with this at this time, devices may or may not offer  
> identity
> discovery.
>
>> Jim
>
> --vt
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From vt at freehold.crocodile.org  Fri Jun 23 11:28:29 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Fri, 23 Jun 2006 10:28:29 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
	<CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
Message-ID: <20060623172829.GA5335@freehold.crocodile.org>

Hello Joachim,

> I would like to repeat that your request is best addressed to the POSSIX
> standardization group - or maybe the BSD/Linux maintainers. If you
> convince the BSD or Linux guys to add this kind of functionality (they can
> as most of there VCP drivers are open source), there is a certain chance
> that other vendors will pick it up. I assure you that RXTX will happily
> provide this functionality once it's possible - I'm sure there is more
> than one maintainer that would love to add it.

I realize this thing is bigger than RxTx itself, and I'm afraid it's too
global not to cause people to laugh before they think about it :)

> Having this concept penetrate the market may take some years though.

Well, I'm sure it'll get there, the only question is - when.

> SHORT: The solution you would like to see could be added to the API but it
> can not be implemented (at least not on the platforms I know).

I guess I'm concerned about the abstraction more than I'm concerned about
the implementation at this point.
  
> There are currently no hooks in the kernel that allow you to discover  
> "the device" or even the "means of connection" based on an existing  
> "device file descriptor" ie COM-port or /dev/... entry.

Well, I'm not so sure you need to keep the literal mapping from /dev
namespace to your device namespace. As long as you can consistently offer a
virtual serial device on top of a virtual serial port, it may be irrelevant
whether you can map it into /dev. The mapping is going be schitzofrenic
anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the
representation...

> The name mapping of the device is handled by the virtual com port driver
> of the device. Unless you are suggesting RXTX should reimplement virtual
> com port drivers for all usb/serial bridges out there your request is
> understandable from a users viewpoint but simply not realizable.

It's not so much a request but rather an offer of participation. I run a few
projects actively using serial communications, as well as USB device
drivers, in different degrees of readiness (Servomaster, Haywire, DIY
Zoning) - and it would be a perfect playground.

You mentioned above that this task is about two things: a) abstraction b)
implementation. I could start the abstraction part of it without changing
the current CommAPI, on top of it, as an adapter. Even if the removable
device semantics are not implemented, but offered, this is already a step
forward.

> It's like asking that the Socket api should identify the computer behind
> an IP address (ie by its Ethernet address). While this COULD be
> implemented in TCP/IP, it IS not, and hence there is no point adding such
> a function to the Socket API.

Thank you for bringing up this example - I guess this is just about the same
thing that I'd like to see. Socket transparently provides you with the
input/output streams, at the same time offering protocol level specifics to
you.

> The current trend for USB/Bluetooth/Irda/etc connected devices is going
> away from serial port abstraction towards RPC (ie the drivers provide a
> device specific or device class specific driver that provides an
> application level api to the device functions). The line level protocol is
> often not even published.

I can't say I'm that happy with it. The best (or, rather, worst) example is
suchlike support for the Phidget servo controller - zealous Linux developers
implemented kernel module support for it, completely hijacking a possibility
of using it on a different level (it's somewhat fixed by now, thankfully).

I believe that whenever an abstraction is offered, it must be made optional
and/or pluggable so it can be replaced by something more suited to the task.

The nature of Java applications is such that they'd probably care much more
about Java API offered, than about no matter how rich application level api
that is offered outside of Java. I've dealt with JNI adapters in the past,
and whereas they can be made reasonably stable, the very fact that you are
forced to deal with things that are not on the critical timing/memory path
and could've been done much easier in Java causes endless grief.

> Joachim

--vt


From lyon at docjava.com  Sat Jun 24 04:54:12 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Sat, 24 Jun 2006 06:54:12 -0400
Subject: [Rxtx] jsr
In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
	<CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
	<20060623172829.GA5335@freehold.crocodile.org>
Message-ID: <p060204a3c0c2c9dde4f8@[192.168.1.152]>

Hi All,
I have had some off-list discussion with Trent.
Opening up a JSR with Sun, as per Peters' suggestion
seems like a reasonable idea, to us.

Does anyone having any concerns about the JSR process
that they would like to raise?

Thanks!
  - Doug



From the.grey.lantern at gmail.com  Sat Jun 24 18:15:26 2006
From: the.grey.lantern at gmail.com (Craig Nicoll)
Date: Sun, 25 Jun 2006 01:15:26 +0100
Subject: [Rxtx] Cannot create virtual serial port
Message-ID: <a1221cc50606241715g2d1e2af6r747347dd4c20e997@mail.gmail.com>

Hello,

This is my first post on this mailing list and I hope someone can help me.

I am having great difficult establishing a virtual serial port for the
Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia
7600.

Every time I try to run the SendMessage program that comes with SMSLib, I
get the following exception: gnu.io.NoSuchPortException

The port names I have tried are:
rfcomm0
rfcomm
/dev/rfcomm0
/dev/rfcomm

This is what I have done so far:
Modified /etc/bluetooth/rfcomm.conf to include the address of my phone:

rfcomm0 {
# Automatically bind the device at startup
bind no;

# Bluetooth address of the device
device 00:0e:6d:7a:98:43;

# RFCOMM channel for the connection
channel 1;

# Description of the connection
comment "Example Bluetooth device";
}

I also tried running the following command: rfcomm bind /dev/rfcomm0

I have searched the mailing list archives and found this post where someone
had a very similar problem to me:
http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried
changing the system properties as suggested and it made no difference.

I have also been scouring Google all day to no avail.

I would be incredibly grateful if anyone could give me some tips.

Thank you,

Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0008.html

From tjarvi at qbang.org  Sun Jun 25 19:56:08 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT)
Subject: [Rxtx] Pending release
Message-ID: <Pine.LNX.4.61.0606251942460.15744@www>


With frustration, I was unable to get to the pending release this weekend.
The release should be comming this next week once things calm down.
The source is in CVS except for a fix for multiple ports in windows.

I had planned on doing the release this weekend but that was disrupted by 
my transportation failing in a spectacular fashion.

--
Trent Jarvi
tjarvi at qbang.org


From Pawan.Kharbanda at dot.state.co.us  Tue Jun 27 22:28:51 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 27 Jun 2006 22:28:51 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>

 Trent, 
   I have an application running in a cluster in linux environment and I
am using RXTX2.1.7 (final) with JDK1.5. The application opens and closes
serial comm ports every 30 seconds and exchanges datas. I have
experienced some of my Comm Ports are left hanging (I can see the
LCK..cufXX lock files under /var/lock folder). On putting the debugs I
found out that, it is stuck at a native call line 809 in RXTXPort.java
class (Please see the code snippet below). Can you help me explain what
this method does in the native code? Am I getting into some thread
deadlocks? Thanks in advance.

Pawan Kharbanda 


public void removeEventListener()
	{
		if (debug)
			z.reportln( "RXTXPort:removeEventListener()
called");
		waitForTheNativeCodeSilly();
		//if( monThread != null && monThread.isAlive() )
		if( monThreadisInterrupted == true )
		{
			z.reportln( "	RXTXPort:removeEventListener()
already interrupted");
			monThread = null;
			SPEventListener = null;
			return;
		}
		else if( monThread != null && monThread.isAlive() )
		{
			if (debug)
				z.reportln( "
RXTXPort:Interrupt=true");
			monThreadisInterrupted=true;
			/*
			   Notify all threads in this PID that something
is up
			   They will call back to see if its their
thread
			   using isInterrupted().
			*/
			if (debug)
				z.reportln( "	RXTXPort:calling
interruptEventLoop");
// LINE 809			interruptEventLoop( ); It never returns
out of this 
			
			if (debug)
				z.reportln( "	RXTXPort:calling
monThread.join()");
			try {
				monThread.join(1000);
			} catch (Exception ex) {
				/* yikes */
				ex.printStackTrace();
			}
			if (debug)
				z.reportln( "	RXTXPort:waiting on
isAlive()");
			while( monThread.isAlive() )
			{
				if ( debug )
					z.reportln( "	MonThread is
still alive!");
				try {
					monThread.join(1000);
					Thread.sleep( 1000 );
				} catch( Exception e ){} 
				//monThread.stop();
			}
			
		}
		if (debug)
			z.reportln( "	RXTXPort:calling gc()");
		monThread = null;
		SPEventListener = null;
		MonitorThreadLock = false;
		MonitorThreadAlive=false;
		monThreadisInterrupted=true;
		z.reportln( "RXTXPort:removeEventListener() returning");
	} 

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Sunday, June 25, 2006 7:56 PM
To: rxtx at qbang.org
Subject: [Rxtx] Pending release


With frustration, I was unable to get to the pending release this
weekend.
The release should be comming this next week once things calm down.
The source is in CVS except for a fix for multiple ports in windows.

I had planned on doing the release this weekend but that was disrupted
by my transportation failing in a spectacular fashion.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Wed Jun 28 04:17:29 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 28 Jun 2006 04:17:29 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606280406330.9561@www>



Hi Pawan

You may have found a deadlock but I've not seen on recently on linux.

If you can, please update from CVS.  This will have some close fixes. 
I'm running with the same code as is in CVS.  It is not perfect but I've 
not seen anything like you mention.  Be sure to set timeouts and 
thresholds on the port.  It may be that the port is waiting on pending io 
that never happens.  I think the CVS patches deal with this also but it 
looks like your in a better test environment to know for sure.

The exploded vehicle mentioned below is expected to be fixed today.  It 
was just a ninja small radiator hose.  The pressure test afterwards 
created its own set of problems.  Until this is resolved, I'm spending 
most of my free time commuting by bicycle.

On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>   I have an application running in a cluster in linux environment and I
> am using RXTX2.1.7 (final) with JDK1.5. The application opens and closes
> serial comm ports every 30 seconds and exchanges datas. I have
> experienced some of my Comm Ports are left hanging (I can see the
> LCK..cufXX lock files under /var/lock folder). On putting the debugs I
> found out that, it is stuck at a native call line 809 in RXTXPort.java
> class (Please see the code snippet below). Can you help me explain what
> this method does in the native code? Am I getting into some thread
> deadlocks? Thanks in advance.
>
> Pawan Kharbanda
>
>
> public void removeEventListener()
> 	{
> 		if (debug)
> 			z.reportln( "RXTXPort:removeEventListener()
> called");
> 		waitForTheNativeCodeSilly();
> 		//if( monThread != null && monThread.isAlive() )
> 		if( monThreadisInterrupted == true )
> 		{
> 			z.reportln( "	RXTXPort:removeEventListener()
> already interrupted");
> 			monThread = null;
> 			SPEventListener = null;
> 			return;
> 		}
> 		else if( monThread != null && monThread.isAlive() )
> 		{
> 			if (debug)
> 				z.reportln( "
> RXTXPort:Interrupt=true");
> 			monThreadisInterrupted=true;
> 			/*
> 			   Notify all threads in this PID that something
> is up
> 			   They will call back to see if its their
> thread
> 			   using isInterrupted().
> 			*/
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> interruptEventLoop");
> // LINE 809			interruptEventLoop( ); It never returns
> out of this
>
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> monThread.join()");
> 			try {
> 				monThread.join(1000);
> 			} catch (Exception ex) {
> 				/* yikes */
> 				ex.printStackTrace();
> 			}
> 			if (debug)
> 				z.reportln( "	RXTXPort:waiting on
> isAlive()");
> 			while( monThread.isAlive() )
> 			{
> 				if ( debug )
> 					z.reportln( "	MonThread is
> still alive!");
> 				try {
> 					monThread.join(1000);
> 					Thread.sleep( 1000 );
> 				} catch( Exception e ){}
> 				//monThread.stop();
> 			}
>
> 		}
> 		if (debug)
> 			z.reportln( "	RXTXPort:calling gc()");
> 		monThread = null;
> 		SPEventListener = null;
> 		MonitorThreadLock = false;
> 		MonitorThreadAlive=false;
> 		monThreadisInterrupted=true;
> 		z.reportln( "RXTXPort:removeEventListener() returning");
> 	}
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Sunday, June 25, 2006 7:56 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] Pending release
>
>
> With frustration, I was unable to get to the pending release this
> weekend.
> The release should be comming this next week once things calm down.
> The source is in CVS except for a fix for multiple ports in windows.
>
> I had planned on doing the release this weekend but that was disrupted
> by my transportation failing in a spectacular fashion.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From Pawan.Kharbanda at dot.state.co.us  Wed Jun 28 12:11:06 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Wed, 28 Jun 2006 12:11:06 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>

Trent,
    Again thanks for the reply. First of all I have Receive timeouts set
on all communications including Max no of bytes to expect during the
call. I have noticed the problem is during "closing the connection". I
am not sure if the RXTX is 100% thread-safe yet. There seems to be a
glitch in the native calls. I am sure I have the latest code I did the
update on the Version 2.1.7 from CVS, is this where the latest updates
are located, I have noticed another version in CVS "rxtx-devel".

Regards
Pawan Kharbanda

    

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Wednesday, June 28, 2006 4:17 AM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports



Hi Pawan

You may have found a deadlock but I've not seen on recently on linux.

If you can, please update from CVS.  This will have some close fixes. 
I'm running with the same code as is in CVS.  It is not perfect but I've
not seen anything like you mention.  Be sure to set timeouts and
thresholds on the port.  It may be that the port is waiting on pending
io that never happens.  I think the CVS patches deal with this also but
it looks like your in a better test environment to know for sure.

The exploded vehicle mentioned below is expected to be fixed today.  It
was just a ninja small radiator hose.  The pressure test afterwards
created its own set of problems.  Until this is resolved, I'm spending
most of my free time commuting by bicycle.

On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>   I have an application running in a cluster in linux environment and 
> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and 
> closes serial comm ports every 30 seconds and exchanges datas. I have 
> experienced some of my Comm Ports are left hanging (I can see the 
> LCK..cufXX lock files under /var/lock folder). On putting the debugs I

> found out that, it is stuck at a native call line 809 in RXTXPort.java

> class (Please see the code snippet below). Can you help me explain 
> what this method does in the native code? Am I getting into some 
> thread deadlocks? Thanks in advance.
>
> Pawan Kharbanda
>
>
> public void removeEventListener()
> 	{
> 		if (debug)
> 			z.reportln( "RXTXPort:removeEventListener()
called");
> 		waitForTheNativeCodeSilly();
> 		//if( monThread != null && monThread.isAlive() )
> 		if( monThreadisInterrupted == true )
> 		{
> 			z.reportln( "	RXTXPort:removeEventListener()
> already interrupted");
> 			monThread = null;
> 			SPEventListener = null;
> 			return;
> 		}
> 		else if( monThread != null && monThread.isAlive() )
> 		{
> 			if (debug)
> 				z.reportln( "
> RXTXPort:Interrupt=true");
> 			monThreadisInterrupted=true;
> 			/*
> 			   Notify all threads in this PID that something
is up
> 			   They will call back to see if its their
thread
> 			   using isInterrupted().
> 			*/
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> interruptEventLoop");
> // LINE 809			interruptEventLoop( ); It never returns
> out of this
>
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> monThread.join()");
> 			try {
> 				monThread.join(1000);
> 			} catch (Exception ex) {
> 				/* yikes */
> 				ex.printStackTrace();
> 			}
> 			if (debug)
> 				z.reportln( "	RXTXPort:waiting on
> isAlive()");
> 			while( monThread.isAlive() )
> 			{
> 				if ( debug )
> 					z.reportln( "	MonThread is
> still alive!");
> 				try {
> 					monThread.join(1000);
> 					Thread.sleep( 1000 );
> 				} catch( Exception e ){}
> 				//monThread.stop();
> 			}
>
> 		}
> 		if (debug)
> 			z.reportln( "	RXTXPort:calling gc()");
> 		monThread = null;
> 		SPEventListener = null;
> 		MonitorThreadLock = false;
> 		MonitorThreadAlive=false;
> 		monThreadisInterrupted=true;
> 		z.reportln( "RXTXPort:removeEventListener() returning");
> 	}
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf

> Of Trent Jarvi
> Sent: Sunday, June 25, 2006 7:56 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] Pending release
>
>
> With frustration, I was unable to get to the pending release this 
> weekend.
> The release should be comming this next week once things calm down.
> The source is in CVS except for a fix for multiple ports in windows.
>
> I had planned on doing the release this weekend but that was disrupted

> by my transportation failing in a spectacular fashion.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Wed Jun 28 12:26:21 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 28 Jun 2006 12:26:21 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606281222420.9561@www>


Hi Pawan

If you did a cvs update from the 2.1-7 tar ball, you have the current 
version.  All rxtx in CVS is under rxtx-devel.  The 2.1-7 just has -r
commapi-0-0-1.

You may well have found something.  I have seen win32 fail on closing 
ports but not linux that I can think of.  Your use is much different than 
I normally see too.

Could you give us more information on how we would reproduce this and the 
frequency?


On Wed, 28 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>    Again thanks for the reply. First of all I have Receive timeouts set
> on all communications including Max no of bytes to expect during the
> call. I have noticed the problem is during "closing the connection". I
> am not sure if the RXTX is 100% thread-safe yet. There seems to be a
> glitch in the native calls. I am sure I have the latest code I did the
> update on the Version 2.1.7 from CVS, is this where the latest updates
> are located, I have noticed another version in CVS "rxtx-devel".
>
> Regards
> Pawan Kharbanda
>
>
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Wednesday, June 28, 2006 4:17 AM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] Locked Ports
>
>
>
> Hi Pawan
>
> You may have found a deadlock but I've not seen on recently on linux.
>
> If you can, please update from CVS.  This will have some close fixes.
> I'm running with the same code as is in CVS.  It is not perfect but I've
> not seen anything like you mention.  Be sure to set timeouts and
> thresholds on the port.  It may be that the port is waiting on pending
> io that never happens.  I think the CVS patches deal with this also but
> it looks like your in a better test environment to know for sure.
>
> The exploded vehicle mentioned below is expected to be fixed today.  It
> was just a ninja small radiator hose.  The pressure test afterwards
> created its own set of problems.  Until this is resolved, I'm spending
> most of my free time commuting by bicycle.
>
> On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:
>
>> Trent,
>>   I have an application running in a cluster in linux environment and
>> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and
>> closes serial comm ports every 30 seconds and exchanges datas. I have
>> experienced some of my Comm Ports are left hanging (I can see the
>> LCK..cufXX lock files under /var/lock folder). On putting the debugs I
>
>> found out that, it is stuck at a native call line 809 in RXTXPort.java
>
>> class (Please see the code snippet below). Can you help me explain
>> what this method does in the native code? Am I getting into some
>> thread deadlocks? Thanks in advance.
>>
>> Pawan Kharbanda
>>
>>
>> public void removeEventListener()
>> 	{
>> 		if (debug)
>> 			z.reportln( "RXTXPort:removeEventListener()
> called");
>> 		waitForTheNativeCodeSilly();
>> 		//if( monThread != null && monThread.isAlive() )
>> 		if( monThreadisInterrupted == true )
>> 		{
>> 			z.reportln( "	RXTXPort:removeEventListener()
>> already interrupted");
>> 			monThread = null;
>> 			SPEventListener = null;
>> 			return;
>> 		}
>> 		else if( monThread != null && monThread.isAlive() )
>> 		{
>> 			if (debug)
>> 				z.reportln( "
>> RXTXPort:Interrupt=true");
>> 			monThreadisInterrupted=true;
>> 			/*
>> 			   Notify all threads in this PID that something
> is up
>> 			   They will call back to see if its their
> thread
>> 			   using isInterrupted().
>> 			*/
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> interruptEventLoop");
>> // LINE 809			interruptEventLoop( ); It never returns
>> out of this
>>
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> monThread.join()");
>> 			try {
>> 				monThread.join(1000);
>> 			} catch (Exception ex) {
>> 				/* yikes */
>> 				ex.printStackTrace();
>> 			}
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:waiting on
>> isAlive()");
>> 			while( monThread.isAlive() )
>> 			{
>> 				if ( debug )
>> 					z.reportln( "	MonThread is
>> still alive!");
>> 				try {
>> 					monThread.join(1000);
>> 					Thread.sleep( 1000 );
>> 				} catch( Exception e ){}
>> 				//monThread.stop();
>> 			}
>>
>> 		}
>> 		if (debug)
>> 			z.reportln( "	RXTXPort:calling gc()");
>> 		monThread = null;
>> 		SPEventListener = null;
>> 		MonitorThreadLock = false;
>> 		MonitorThreadAlive=false;
>> 		monThreadisInterrupted=true;
>> 		z.reportln( "RXTXPort:removeEventListener() returning");
>> 	}
>>
>> -----Original Message-----
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
>
>> Of Trent Jarvi
>> Sent: Sunday, June 25, 2006 7:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] Pending release
>>
>>
>> With frustration, I was unable to get to the pending release this
>> weekend.
>> The release should be comming this next week once things calm down.
>> The source is in CVS except for a fix for multiple ports in windows.
>>
>> I had planned on doing the release this weekend but that was disrupted
>
>> by my transportation failing in a spectacular fashion.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From Pawan.Kharbanda at dot.state.co.us  Wed Jun 28 15:42:49 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Wed, 28 Jun 2006 15:42:49 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>

Trent,
    I will try to explain how I am setup and will try to write you a
Sample code little later to reproduce this. On our system we have
DigiBoxes installed on the 2 Linux servers. Both of them have RXTX2.1-7
version installed with the JRE(1.5) and both the machines have the same
port mappings in gnu.io.rxtx.properties (Currently in the production
system I have 64 ports). This is how the system works:

1) A thick Map based client initiates a Action on the Device on the
field. One of the Thread Workers(Asynchronous Call) in the Cluster picks
up the request. 
2) Once the worker gets the request it locks the Device and
Communication port in the DB's(These are our persistent locks, because
most of the devices do one to one communication with the serial ports).
After that the worker (or Comm Server) opens up the connection and after
exchanging the information calls the "Close" and returns.
3) Once the connection is closed , the DB lock is removed on the comm
port and is made available to accept future calls. Here is where the
glitch is the Serial Comm Close method never returns due to the
deadlock. 

I have noticed that the deadlocks are very inconsistent, sometime it
happens right away as soon as Application server starts and sometimes I
don't see any deadlocks for days, but it happens for sure. 

Here is how you can test if you have resources/ test environment. Write
a program and try to open/close  different ports(I will say have a
minimum of four) randomly and very frequently(may be 30 seconds), I am
pretty sure you will see the deadlocks and it happens in the native call
to interrptEventLoop in RXTXPort.java in removeEventListener() method
call.

Also I have noticed that the JVM carshes (without any memrory errors or
JVM errors. Its just not there) when native call is made to eventLoop()
in run() method in MonitorThread inner class. I am still investigating
why this is happening, but at this point I can just tell you the
location. You might have a question How I am so sure about the location?
My application is configured with Log4J and I have enabled the debugs on
the RXTXPort.java, so every time my JVM dies I see these logs at the end
of the file.

"2006-06-28 15:27:15,183 INFO  [STDOUT] RXTXPort:RXTXPort(/dev/cub01)
called
2006-06-28 15:27:15,218 INFO  [STDOUT]
RXTXPort:MontitorThread:MonitorThread()
2006-06-28 15:27:15,219 INFO  [STDOUT] RXTXPort:MontitorThread:run()"

I surely do have a luxury of a testing environment(ports, devices etc.)
and can help you fix these problems? Please advise me how we can resolve
these issues.

Thanks 
Pawan Kharbanda
303-478-2991





-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Wednesday, June 28, 2006 12:26 PM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports


Hi Pawan

If you did a cvs update from the 2.1-7 tar ball, you have the current
version.  All rxtx in CVS is under rxtx-devel.  The 2.1-7 just has -r
commapi-0-0-1.

You may well have found something.  I have seen win32 fail on closing
ports but not linux that I can think of.  Your use is much different
than I normally see too.

Could you give us more information on how we would reproduce this and
the frequency?


On Wed, 28 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>    Again thanks for the reply. First of all I have Receive timeouts
set
> on all communications including Max no of bytes to expect during the
> call. I have noticed the problem is during "closing the connection". I
> am not sure if the RXTX is 100% thread-safe yet. There seems to be a
> glitch in the native calls. I am sure I have the latest code I did the
> update on the Version 2.1.7 from CVS, is this where the latest updates
> are located, I have noticed another version in CVS "rxtx-devel".
>
> Regards
> Pawan Kharbanda
>
>
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Wednesday, June 28, 2006 4:17 AM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] Locked Ports
>
>
>
> Hi Pawan
>
> You may have found a deadlock but I've not seen on recently on linux.
>
> If you can, please update from CVS.  This will have some close fixes.
> I'm running with the same code as is in CVS.  It is not perfect but
I've
> not seen anything like you mention.  Be sure to set timeouts and
> thresholds on the port.  It may be that the port is waiting on pending
> io that never happens.  I think the CVS patches deal with this also
but
> it looks like your in a better test environment to know for sure.
>
> The exploded vehicle mentioned below is expected to be fixed today.
It
> was just a ninja small radiator hose.  The pressure test afterwards
> created its own set of problems.  Until this is resolved, I'm spending
> most of my free time commuting by bicycle.
>
> On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:
>
>> Trent,
>>   I have an application running in a cluster in linux environment and
>> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and
>> closes serial comm ports every 30 seconds and exchanges datas. I have
>> experienced some of my Comm Ports are left hanging (I can see the
>> LCK..cufXX lock files under /var/lock folder). On putting the debugs
I
>
>> found out that, it is stuck at a native call line 809 in
RXTXPort.java
>
>> class (Please see the code snippet below). Can you help me explain
>> what this method does in the native code? Am I getting into some
>> thread deadlocks? Thanks in advance.
>>
>> Pawan Kharbanda
>>
>>
>> public void removeEventListener()
>> 	{
>> 		if (debug)
>> 			z.reportln( "RXTXPort:removeEventListener()
> called");
>> 		waitForTheNativeCodeSilly();
>> 		//if( monThread != null && monThread.isAlive() )
>> 		if( monThreadisInterrupted == true )
>> 		{
>> 			z.reportln( "	RXTXPort:removeEventListener()
>> already interrupted");
>> 			monThread = null;
>> 			SPEventListener = null;
>> 			return;
>> 		}
>> 		else if( monThread != null && monThread.isAlive() )
>> 		{
>> 			if (debug)
>> 				z.reportln( "
>> RXTXPort:Interrupt=true");
>> 			monThreadisInterrupted=true;
>> 			/*
>> 			   Notify all threads in this PID that something
> is up
>> 			   They will call back to see if its their
> thread
>> 			   using isInterrupted().
>> 			*/
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> interruptEventLoop");
>> // LINE 809			interruptEventLoop( ); It never returns
>> out of this
>>
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> monThread.join()");
>> 			try {
>> 				monThread.join(1000);
>> 			} catch (Exception ex) {
>> 				/* yikes */
>> 				ex.printStackTrace();
>> 			}
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:waiting on
>> isAlive()");
>> 			while( monThread.isAlive() )
>> 			{
>> 				if ( debug )
>> 					z.reportln( "	MonThread is
>> still alive!");
>> 				try {
>> 					monThread.join(1000);
>> 					Thread.sleep( 1000 );
>> 				} catch( Exception e ){}
>> 				//monThread.stop();
>> 			}
>>
>> 		}
>> 		if (debug)
>> 			z.reportln( "	RXTXPort:calling gc()");
>> 		monThread = null;
>> 		SPEventListener = null;
>> 		MonitorThreadLock = false;
>> 		MonitorThreadAlive=false;
>> 		monThreadisInterrupted=true;
>> 		z.reportln( "RXTXPort:removeEventListener() returning");
>> 	}
>>
>> -----Original Message-----
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On
Behalf
>
>> Of Trent Jarvi
>> Sent: Sunday, June 25, 2006 7:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] Pending release
>>
>>
>> With frustration, I was unable to get to the pending release this
>> weekend.
>> The release should be comming this next week once things calm down.
>> The source is in CVS except for a fix for multiple ports in windows.
>>
>> I had planned on doing the release this weekend but that was
disrupted
>
>> by my transportation failing in a spectacular fashion.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx 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 khattar31 at yahoo.com  Wed Jun 28 22:04:59 2006
From: khattar31 at yahoo.com (rahul khattar)
Date: Wed, 28 Jun 2006 21:04:59 -0700 (PDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
Message-ID: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>

Hi All,

I was looking at the src file on the last release.
I did notice a missing header file while trying to
compile the parallelport.dll. Would somebody be kind
enoughf to share the missing header file:
gnu_io_LPRPort.h

I am using MinGw to compile the same from Parinya
(which is an execellent tool)


Regards,
Rahul Khattar

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Thu Jun 29 03:43:53 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 03:43:53 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>
References: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606290341210.9561@www>

On Wed, 28 Jun 2006, rahul khattar wrote:

> Hi All,
>
> I was looking at the src file on the last release.
> I did notice a missing header file while trying to
> compile the parallelport.dll. Would somebody be kind
> enoughf to share the missing header file:
> gnu_io_LPRPort.h
>
> I am using MinGw to compile the same from Parinya
> (which is an execellent tool)
>

Hi Rahul

The gnu.io_LPRPort.h file is generated with javah.  You can see the 
command in the Makefile I presume.  You do not need rxtxParallel.dll to 
use w32 serial btw.

--
Trent Jarvi
tjarvi at qbang.org


From khattar31 at yahoo.com  Thu Jun 29 04:47:01 2006
From: khattar31 at yahoo.com (rahul khattar)
Date: Thu, 29 Jun 2006 03:47:01 -0700 (PDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606290341210.9561@www>
Message-ID: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>

Hi Trent 
I did notice this file is required in the source file
ParallelImp.c
on line 38

Attached the O/P 

Regards,
Rahul Khattar




--- Trent Jarvi <tjarvi at qbang.org> wrote:

> On Wed, 28 Jun 2006, rahul khattar wrote:
> 
> > Hi All,
> >
> > I was looking at the src file on the last release.
> > I did notice a missing header file while trying to
> > compile the parallelport.dll. Would somebody be
> kind
> > enoughf to share the missing header file:
> > gnu_io_LPRPort.h
> >
> > I am using MinGw to compile the same from Parinya
> > (which is an execellent tool)
> >
> 
> Hi Rahul
> 
> The gnu.io_LPRPort.h file is generated with javah. 
> You can see the 
> command in the Makefile I presume.  You do not need
> rxtxParallel.dll to 
> use w32 serial btw.
> 
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Error.zip
Type: application/x-zip-compressed
Size: 1746 bytes
Desc: 2948039066-Error.zip
Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060629/a5b6f783/Error-0008.bin

From tjarvi at qbang.org  Thu Jun 29 06:16:24 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 06:16:24 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606290614530.9561@www>

On Thu, 29 Jun 2006, rahul khattar wrote:

> Hi Trent
> I did notice this file is required in the source file
> ParallelImp.c
> on line 38
>
> Attached the O/P
>

The command to generate the .h file will be something like:

javah -classpath . -jni gnu.io.LPRPort

The makefile should have this.  There are several approaches to creating 
or using makefiles so I have no idea which one you used if any.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Thu Jun 29 06:20:51 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 06:20:51 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606290616420.9561@www>

> Here is how you can test if you have resources/ test environment. Write
> a program and try to open/close  different ports(I will say have a
> minimum of four) randomly and very frequently(may be 30 seconds), I am
> pretty sure you will see the deadlocks and it happens in the native call
> to interrptEventLoop in RXTXPort.java in removeEventListener() method
> call.

Hi Pawan

I'll try to find a way to reproduce this.  One thing to note is that you 
are using different kernel drivers (digi) to perform this task.  So I 
probably will not be able to reproduce the exact same environment.

In general, multiport kernel drivers have been tested far less than 
typical serial drivers.  This may or may not be an issue.

--
Trent Jarvi
tjarvi at qbang.org



From jhaysonn at gmail.com  Thu Jun 29 12:29:13 2006
From: jhaysonn at gmail.com (jhaysonn pathak)
Date: Thu, 29 Jun 2006 14:29:13 -0400
Subject: [Rxtx] RXTX install
Message-ID: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>

Hi Guys,

I'm doing trying to write a generative piece of Sonic Art using an EEG
plugged into a mac runnning Max/MSP.  I just recently discovered RXTX
drivers in my search for a piece of software that might give me more
output options for my EEG (I'm using the CEO from MindPeak).  I found
Bioera which uses RXTX drivers.  Thing is - I can't figure out how to
install RXTX correctly.

After I build the 'libSerial.jnilib' target inside of
'LibSerial.pbproj' I can't find the libSerial.jnilib file that
accompanies the RXTXcomm.jar nor do I know where to put them.

I also don't understand this part at the bottom of the OS X instructions at all:

"AFTER INSTALLATION VERY IMPORTANT
	check existence of the folder /var/spool/uucp
	if you don't have it create it with command
	sudo mkdir /var/spool/uucp
	permissions should be: drwxrwxr-x
	if they are not do command
	sudo chmod 775 /var/spool/uucp

	YOU should be a member of the uucp group
	you can check it with command
		niutil -readprop / /groups/uucp users
	you should see your name in output of the niutil command
	if you don't do following:
		sudo niutil -appendprop / /groups/uucp users <yourname>
			substitute  <yourname> with your user's name
			for example if your user name is peter:
				sudo niutil -appendprop / /groups/uucp users peter

	NOTES: RXTX.pkg should create uucp folder and insert your name  in
uucp group automatically"



I really appreciate any help that you guys can offer.  I've been
struggling with this for a while now as part of a research grant that
I was awarded.  Thanks again for the help.

Jhaysonn Pathak


From naranjo.manuel at gmail.com  Thu Jun 29 07:19:15 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 10:19:15 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606290614530.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www>
Message-ID: <44A3D353.6010605@gmail.com>

Speaking about Windows Support, I had seen that inside the 
rxtx-2.1-7-bins-r2 package inside Windows directory it says:
"i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will 
not make harm to anyone, and i'm almost sure that someone has noticed it 
before.
Cheers,
Manuel


From joachim at buechse.de  Thu Jun 29 13:25:16 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 29 Jun 2006 21:25:16 +0200
Subject: [Rxtx] RXTX install
In-Reply-To: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>
References: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>
Message-ID: <2A003E42-97E1-4237-8438-646BDE2E3961@buechse.de>

Hello Jhaysonn,

I assume you are trying to use the javax.comm version of RXTX.

Please use "cvs up" to update your download to the latest version of  
the repository. The latest version does not use lock files, so the  
mentioned process is no longer needed. Updating with CVS will also  
provide you with a new README.OSX file that should be simpler to  
understand.

You will find LibSerialUniversal.xcodeproj in MACOSX_IDE/Xcode. Put  
comm.jar (downloaded from Sun) into MACOSX_IDE/Xcode. Compile the  
library. You will find RXTXcomm.jar and librxtxSerial.jnilib in  
MACOSX_IDE/Xcode/build/Default

Best regards,
Joachim
---
Joachim B?chse
Softwarel?sungen und Beratung
Hadlaubsteig 2
CH-8006 Z?rich


On 29.06.2006, at 20:29, jhaysonn pathak wrote:

> Hi Guys,
>
> I'm doing trying to write a generative piece of Sonic Art using an EEG
> plugged into a mac runnning Max/MSP.  I just recently discovered RXTX
> drivers in my search for a piece of software that might give me more
> output options for my EEG (I'm using the CEO from MindPeak).  I found
> Bioera which uses RXTX drivers.  Thing is - I can't figure out how to
> install RXTX correctly.
>
> After I build the 'libSerial.jnilib' target inside of
> 'LibSerial.pbproj' I can't find the libSerial.jnilib file that
> accompanies the RXTXcomm.jar nor do I know where to put them.
>
> I also don't understand this part at the bottom of the OS X  
> instructions at all:
>
> "AFTER INSTALLATION VERY IMPORTANT
> 	check existence of the folder /var/spool/uucp
> 	if you don't have it create it with command
> 	sudo mkdir /var/spool/uucp
> 	permissions should be: drwxrwxr-x
> 	if they are not do command
> 	sudo chmod 775 /var/spool/uucp
>
> 	YOU should be a member of the uucp group
> 	you can check it with command
> 		niutil -readprop / /groups/uucp users
> 	you should see your name in output of the niutil command
> 	if you don't do following:
> 		sudo niutil -appendprop / /groups/uucp users <yourname>
> 			substitute  <yourname> with your user's name
> 			for example if your user name is peter:
> 				sudo niutil -appendprop / /groups/uucp users peter
>
> 	NOTES: RXTX.pkg should create uucp folder and insert your name  in
> uucp group automatically"
>
>
>
> I really appreciate any help that you guys can offer.  I've been
> struggling with this for a while now as part of a research grant that
> I was awarded.  Thanks again for the help.
>
> Jhaysonn Pathak
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From tjarvi at qbang.org  Thu Jun 29 19:30:00 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 19:30:00 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A3D353.6010605@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
Message-ID: <Pine.LNX.4.61.0606291923000.9561@www>

On Thu, 29 Jun 2006, Manuel Naranjo wrote:

> Speaking about Windows Support, I had seen that inside the
> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
> not make harm to anyone, and i'm almost sure that someone has noticed it
> before.

Hi Manuel

         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
     47421  01-30-06 00:23 
rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
     77759  03-01-06 12:01 
rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README


It looks normal to me.  There are no fancy tools used there :)

--
Trent Jarvi
tjarvi at qbang.org

From naranjo.manuel at gmail.com  Thu Jun 29 19:38:16 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 22:38:16 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606291923000.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com> <Pine.LNX.4.61.0606291923000.9561@www>
Message-ID: <44A48088.2040407@gmail.com>

> On Thu, 29 Jun 2006, Manuel Naranjo wrote:
> 
>> Speaking about Windows Support, I had seen that inside the
>> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
>> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
>> not make harm to anyone, and i'm almost sure that someone has noticed it
>> before.
> 
> Hi Manuel
> 
>         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
>         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
>     47421  01-30-06 00:23 
> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
>     77759  03-01-06 12:01 
> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
>       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README
> 
> 
> It looks normal to me.  There are no fancy tools used there :)
> 
Hi Trent:
Is not the i368 representing the name of the Architecture?? If so the 
name should start with i386 it will not break any system, is simply miss
written, I saw that and wanted to report it. It a silly thing.
Ohh I forgoten I must congratulate you for your GREAT libray, I was able 
to make an .exe with JSmooth that launches an application that uses RXTX 
with out the need to install RXTX on users system :). The .exe tells JVM 
where to find the RXTX Library and Binaries. I tried with Sun's Java 
Comm but it was imposible.
Regards,
Manuel


From tjarvi at qbang.org  Thu Jun 29 19:52:45 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 19:52:45 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A48088.2040407@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
	<Pine.LNX.4.61.0606291923000.9561@www> <44A48088.2040407@gmail.com>
Message-ID: <Pine.LNX.4.61.0606291945060.9561@www>

On Thu, 29 Jun 2006, Manuel Naranjo wrote:

>> On Thu, 29 Jun 2006, Manuel Naranjo wrote:
>>
>>> Speaking about Windows Support, I had seen that inside the
>>> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
>>> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
>>> not make harm to anyone, and i'm almost sure that someone has noticed it
>>> before.
>>
>> Hi Manuel
>>
>>         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
>>         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
>>     47421  01-30-06 00:23
>> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
>>     77759  03-01-06 12:01
>> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
>>       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README
>>
>>
>> It looks normal to me.  There are no fancy tools used there :)
>>
> Hi Trent:
> Is not the i368 representing the name of the Architecture?? If so the
> name should start with i386 it will not break any system, is simply miss
> written, I saw that and wanted to report it. It a silly thing.
> Ohh I forgoten I must congratulate you for your GREAT libray, I was able
> to make an .exe with JSmooth that launches an application that uses RXTX
> with out the need to install RXTX on users system :). The .exe tells JVM
> where to find the RXTX Library and Binaries. I tried with Sun's Java
> Comm but it was imposible.

Hi Manuel

The compiler uses only the i386 instruction set for windows.  I doubt 
there will be any measurable advantages with going to later instruction 
sets.  In theory rxtx would run on a 386 but I doubt anyone does that.

So it looks odd but is not a typo.

We could compile to i686 but don't.  The compiler used does not appear to 
be a problem yet so I don't see any point in changing it.  Right now, we 
could not compile 64 bit windows binaries.  gcc/mingw/... do not support 
them that I know of.  People will have to compile those with closed source 
tools on their own until an option is available.

--
Trent Jarvi
tjarvi at qbang.org

From naranjo.manuel at gmail.com  Thu Jun 29 20:00:48 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 23:00:48 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606291945060.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com>	<Pine.LNX.4.61.0606291923000.9561@www>
	<44A48088.2040407@gmail.com> <Pine.LNX.4.61.0606291945060.9561@www>
Message-ID: <44A485D0.7050202@gmail.com>

Trent you did not get my point
The folder says 368 three hundred sixty eight, when
it should say 386 three hundred eighty six. Is simply a miss writting.
Regards,
Manuel


From tjarvi at qbang.org  Thu Jun 29 20:12:15 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 20:12:15 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A485D0.7050202@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
	<Pine.LNX.4.61.0606291923000.9561@www> <44A48088.2040407@gmail.com>
	<Pine.LNX.4.61.0606291945060.9561@www> <44A485D0.7050202@gmail.com>
Message-ID: <Pine.LNX.4.61.0606292008061.9561@www>


On Thu, 29 Jun 2006, Manuel Naranjo wrote:

> Trent you did not get my point
> The folder says 368 three hundred sixty eight, when
> it should say 386 three hundred eighty six. Is simply a miss writting.

hehe..  OK.  My bad.  It's been a long day.

Nevermind :)

--
Trent Jarvi
tjarvi at qbang.org




From naranjo.manuel at gmail.com  Thu Jun 29 20:18:44 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 23:18:44 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606292008061.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com>	<Pine.LNX.4.61.0606291923000.9561@www>
	<44A48088.2040407@gmail.com>	<Pine.LNX.4.61.0606291945060.9561@www>
	<44A485D0.7050202@gmail.com> <Pine.LNX.4.61.0606292008061.9561@www>
Message-ID: <44A48A04.9040401@gmail.com>

Don't worry Trent.
About 64 bits compilation, I would like to colaborate, I have a Pc with 
64 bits, the only problem is that i do not have windows 64 bits 
installed :(.




From Pawan.Kharbanda at dot.state.co.us  Fri Jun 30 08:49:52 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 30 Jun 2006 08:49:52 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E996@hqexchange3.dot.state.co.us>

Trent,  
    Can you explain what the interruptedEventLoop() native method is
doing is there a possibility that method is somehow getting into the
infinite loop(there are 2 while loops without any break statements).
This might be a very basic question how can I debug the native code(or
print the debug statements).  Again thanks for the help. 

Pawan Kharbanda

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Thursday, June 29, 2006 6:21 AM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports

> Here is how you can test if you have resources/ test environment. 
> Write a program and try to open/close  different ports(I will say have

> a minimum of four) randomly and very frequently(may be 30 seconds), I 
> am pretty sure you will see the deadlocks and it happens in the native

> call to interrptEventLoop in RXTXPort.java in removeEventListener() 
> method call.

Hi Pawan

I'll try to find a way to reproduce this.  One thing to note is that you
are using different kernel drivers (digi) to perform this task.  So I
probably will not be able to reproduce the exact same environment.

In general, multiport kernel drivers have been tested far less than
typical serial drivers.  This may or may not be an issue.

--
Trent Jarvi
tjarvi at qbang.org

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From cpine at wrsystems.com  Thu Jun 29 15:17:12 2006
From: cpine at wrsystems.com (Chris Pine)
Date: Thu, 29 Jun 2006 17:17:12 -0400
Subject: [Rxtx]  Controlling Individual Signals DTR and RTS
Message-ID: <MAIL4FJo0S8ACLEBajJ000005cf@mail4.wrsystems.com>

Dear Moussa Ba,
	I hope I am not being too forward, but we are having the exact same
issue with needing to control DTR from RXTX in Linux.  Did you ever have any
luck figuring it out?

Thank you very much for your time,

Chris Pine




From tjarvi at qbang.org  Thu Jun  1 11:13:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 11:13:40 -0600 (MDT)
Subject: [Rxtx] custom baud rate win32
In-Reply-To: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606011107210.30220@www>


Hi Daren

I can't imagine that 1953 is possibly the actual value on the UART.  Maybe 
if your baud base is very high with a custom serial board.  More likely, 
the driver just remembers that what you asked for and did something else.

I'll have more to say on the dcb->BaudRate after I try some things here. 
I have managed to do something like that in the past as a quick hack but 
it was for 14400.  I may have used the CBR_14400.

If we can't access this through the win32 API with protected mode, there 
is another layer of complication.  With real mode, it would be easy.
With protected mode, I assume there would have to be some kernel driver or 
a hook I'm not aware of to access the MCR directly (bang a memory 
addresss).



On Thu, 1 Jun 2006, Daren wrote:

> Trent,
> I have managed to successfully open the port at this speed using Realterm
> (available on sourceforge). From memory this uses DLPortIO.
>
> Using portmon.exe with realterm, even there it says that the port has opened
> at 1953.
>
> I changed termios.c:560 to
> dcb->BaudRate        = 1953 ;
>
> and it still opens the port at 9600.
>
> Daren
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Trent Jarvi
> Sent: Thursday, 1 June 2006 1:44 PM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] custom baud rate win32
>
> On Thu, 1 Jun 2006, Daren wrote:
>
>> Hi all,
>>
>> I downloaded 2.1.7-pre16 and managed to build it and get it going. I made
>> the changes as suggested by Peter Smith in an old post, by adding his code
>> to SerialImpl.c, uncommenting the TIOCGSERIAL and TIOCSSERIAL, and
> defining
>> ASYNC_SPD_CUST which is equal to 0x0030 (according to linus header
> files)..
>>
>>
>> Still not working, it opens the port at 9600 according to portmon.exe .
> Has
>> anyone managed to get this going at a custom rate?
>>
>> Here is the post I'm referring to:
>> http://marc.theaimsgroup.com/?l=rxtx&m=106270038110713&w=2
>>
>>
>> Thanks,
>> Daren
>>
>> ________________________________________
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
>> Daren
>> Sent: Wednesday, 31 May 2006 10:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] (no subject)
>>
>> Hi All,
>> I have been using rxtx for a little while and needed to get it working at
>> 1953, like a past user in the mailing list, who seemed to have got it
>> working by changing some C code.
>>
>> I wanted to build rxtx myself with these changes but don't know where to
>> start. I have windows here and FC4 at home. I downloaded cygwin and
> mingw32,
>> each build works by building a rxtxSerial.dll file that is ~11k smaller
> than
>> the original, and I always get the following error when testing the dll:
>>
>> Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at
>> PC=0x8077655
>> Function=[Unknown.]
>> Library=C:\opt\java\j2sdk1.4.2\jre\bin\client\jvm.dll
>>
>> NOTE: We are unable to locate the function name symbol for the error
>>      just occurred. Please refer to release documentation for possible
>>      reason and solutions.
>>
>>
>> Current Java thread:
>> 	at gnu.io.RXTXPort.open(Native Method)
>> 	- locked <0x1002c800> (a gnu.io.RXTXPort)
>> 	at gnu.io.RXTXPort.<init>(RXTXPort.java:84)
>>
>> Anyone know what im doing wrong?
>>
>>
>>
>>
>
> Hi Daren
>
> You are running into the same rats nest I'm looking at now.
>
> With win32 and specific custom baud rates, I'm not sure how this will go.
> I've got the Linux custom baud rates working very nicely.  I did much like
> the post you linked.  In fact I had forgot about that post.  You probably
> noticed that it becomes a bunch of dirt roads going noplace fast in
> termios.c for w32.
>
> I'm probably only going to get 14400, 28800, 128000 and 256000 working
> with the next release on w32.  I'll look a little further.  If you have an
> example w32 that works at 1953 I'd really like to hear.  Thats an unusual
> baud rate.
>
> Assuming a baud_base of 128000, your divisor will be 65 or 66.
>
> 128000/66=1939 -14
> 128000/65=1969 +13
>
> One thing I've been wondering about with linux is which would be the right
> answer in cases like this.  Right now it would just go with a baud base of
> 65 and ignore the modulus details.
>
> It appears to be a general trend for kernel developers to hide these
> details thinking that they can come up with a general solution.  Then they
> run out of time.  Perahps the solution is to help out but there are
> ultiple OS's rxtx supports making that nontrivial.
>
> If you look at current linux kernels, the 'tricks' above have been marked
> deprecated with no replacement.  Windows has some hard defines and then
> ancient near magic.  I've not looked at Solaris via Open Solaris yet but
> doubt there is a solution at all.
>
> What I'd try since you have the equipment and the monitor software is to
> hardcode the dcb->Baud in termios.c to 1953 (no define) and see what the
> w32 kernel does with it.  I think if you toss a baud rate at the driver it
> will try to come close.  You may try comming closer to a real baudrate
> based upon the 128000 baud base as shown above.
>
> If it works, it is worth looking at the rest of the ping/pong logic then.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
>
>
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From doug at dupreeinc.com  Thu Jun  1 13:22:13 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 12:22:13 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011107210.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
Message-ID: <447F3E65.1020809@dupreeinc.com>

Hello,

I am still trying to get this startup a little faster so I turned on the 
debug of a few of the classes.  The COM ports are scanned really fast 
and the delay occurs during the LPT scan.  The console output looks like 
this:

    ...
      LPT1
      LPT2
      LPT3
     valid port prefixes:
      LPT
    LPT1 LPT
    1 1
    LPT2 LPT
    2 2                                                                 
      * <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
    CommPortIdentifier:addPortName(LPT2)
    CommPortIdentifier:AddIdentifierToList()
    LPT3 LPT
    3 3
    CommPortIdentifier:addPortName(LPT3)
    CommPortIdentifier:AddIdentifierToList()
    CommPortIdentifier:AddIdentifierToList() index.next
    Leaving registerValidPorts()
    Have not implemented native_psmisc_report_owner(PortName)); in
    CommPortIdentifier
    CommPortIdentifier:getPortIdentifier(COM3)
    CommPortIdentifier:open(densConnect, 30000)
    RXTXCommDriver:getCommPort(COM3,1)
    ...

It would seem to me that if I removed the code for port scanning of LPT 
ports I could solve this problem. I would much prefer to use unmodified 
code if at all possible.  Do any of you have alternate suggestions?

Thank you for your time.

Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/cf433ee7/attachment-0009.html

From tjarvi at qbang.org  Thu Jun  1 13:52:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 13:52:06 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F3E65.1020809@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011348380.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I am still trying to get this startup a little faster so I turned on the 
> debug of a few of the classes.  The COM ports are scanned really fast and the 
> delay occurs during the LPT scan.  The console output looks like this:
>
>   ...
>     LPT1
>     LPT2
>     LPT3
>    valid port prefixes:
>     LPT
>   LPT1 LPT
>   1 1
>   LPT2 LPT
>   2 2                                                                      * 
> <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>   CommPortIdentifier:addPortName(LPT2)
>   CommPortIdentifier:AddIdentifierToList()
>   LPT3 LPT
>   3 3
>   CommPortIdentifier:addPortName(LPT3)
>   CommPortIdentifier:AddIdentifierToList()
>   CommPortIdentifier:AddIdentifierToList() index.next
>   Leaving registerValidPorts()
>   Have not implemented native_psmisc_report_owner(PortName)); in
>   CommPortIdentifier
>   CommPortIdentifier:getPortIdentifier(COM3)
>   CommPortIdentifier:open(densConnect, 30000)
>   RXTXCommDriver:getCommPort(COM3,1)
>   ...
>
> It would seem to me that if I removed the code for port scanning of LPT ports 
> I could solve this problem. I would much prefer to use unmodified code if at 
> all possible.  Do any of you have alternate suggestions?
>
> Thank you for your time.
>
> Doug
>


Does commenting out the LPT enumeration actually help?  There can often be 
differences between debug information printed and whats really going on. 
When you combine various environments the debug info can even come out in 
the wrong order.

I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
I do not think this problem is universal.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Thu Jun  1 14:29:44 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:29:44 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4E38.2060004@dupreeinc.com>

I will give it a try.  One thing to note on this PC is it has no LPT 
Parallel ports.

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
>>Hello,
>>
>>I am still trying to get this startup a little faster so I turned on the 
>>debug of a few of the classes.  The COM ports are scanned really fast and the 
>>delay occurs during the LPT scan.  The console output looks like this:
>>
>>  ...
>>    LPT1
>>    LPT2
>>    LPT3
>>   valid port prefixes:
>>    LPT
>>  LPT1 LPT
>>  1 1
>>  LPT2 LPT
>>  2 2                                                                      * 
>><<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>>  CommPortIdentifier:addPortName(LPT2)
>>  CommPortIdentifier:AddIdentifierToList()
>>  LPT3 LPT
>>  3 3
>>  CommPortIdentifier:addPortName(LPT3)
>>  CommPortIdentifier:AddIdentifierToList()
>>  CommPortIdentifier:AddIdentifierToList() index.next
>>  Leaving registerValidPorts()
>>  Have not implemented native_psmisc_report_owner(PortName)); in
>>  CommPortIdentifier
>>  CommPortIdentifier:getPortIdentifier(COM3)
>>  CommPortIdentifier:open(densConnect, 30000)
>>  RXTXCommDriver:getCommPort(COM3,1)
>>  ...
>>
>>It would seem to me that if I removed the code for port scanning of LPT ports 
>>I could solve this problem. I would much prefer to use unmodified code if at 
>>all possible.  Do any of you have alternate suggestions?
>>
>>Thank you for your time.
>>
>>Doug
>>
>>    
>>
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/dd31fed5/attachment-0009.html

From doug at dupreeinc.com  Thu Jun  1 14:36:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:36:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4FC8.9080106@dupreeinc.com>

Trent,

I commented out the section in RegisterScannedPorts() that adds the 
three LPT ports to the CandidateDeviceNames string array.  The 
application started immediately.  This is probably not the way to do 
this, but it was quick ,dirty, and worked.

It would be nice if there was a way to pole the OS to see if there is 
even a port there, though I guess this is what this code is suppose to do...

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
> ...
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From lynn at swcp.com  Thu Jun  1 14:49:34 2006
From: lynn at swcp.com (lynn@swcp.com)
Date: Thu, 1 Jun 2006 20:49:34 -0000
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>,
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <twig.1149194974.97617@swcp.com>

Perhaps we could add an argument to port enumeration where if not specified,
you get the default behavior that looks for everything.  With a new
constructor that has an argument(or more) you could optionally declare it to
not inspect printer ports.

Existing code would work as it always has.  New code could be smarter.

Lynn



Doug Thistlethwaite <doug at dupreeinc.com> said:

> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
> >On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
> >
> >  
> >
> > ...
> >
> >
> >Does commenting out the LPT enumeration actually help?  There can often be 
> >differences between debug information printed and whats really going on. 
> >When you combine various environments the debug info can even come out in 
> >the wrong order.
> >
> >I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
> >I do not think this problem is universal.
> >
> >--
> >Trent Jarvi
> >tjarvi at qbang.org
> >_______________________________________________
> >Rxtx mailing list
> >Rxtx at qbang.org
> >http://mailman.qbang.org/mailman/listinfo/rxtx
> >
> >
> >  
> >
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



-- 





From jredman at ergotech.com  Thu Jun  1 15:20:20 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 01 Jun 2006 15:20:20 -0600
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
Message-ID: <447F5A14.6010803@ergotech.com>

Doug,

If you specifically request ports, eg:

-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

or
 
-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

Depending upon the version  (Windows is COM1:COM2, etc. I assume).

Does it still enumerate the parallel ports?

Jim

Doug Thistlethwaite wrote:
> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
>> On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>
>>  
>>
>> ...
>>
>>
>> Does commenting out the LPT enumeration actually help?  There can often be 
>> differences between debug information printed and whats really going on. 
>> When you combine various environments the debug info can even come out in 
>> the wrong order.
>>
>> I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>> I do not think this problem is universal.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>>
>>  
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  1 16:49:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:49:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6EF4.7080709@dupreeinc.com>

I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
folder.  I created this file and added the following to the file:

gnu.io.rxtx.SerialPorts=COM3

and I get the following error on the console:
CommPortIdentifier:static initialization()
RXTXCommDriver {}
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
RXTXCommDriver:
    Jar version = RXTX-2.1-7
    native lib Version = RXTX-2.1-7
RXTXCommDriver:initialize()
checking for system-known ports of type 1
checking registry for ports of type 1

RXTXCommDriver:addSpecifiedPorts()
Exception in thread "main" java.lang.ExceptionInInitializerError
    at 
densconnect.SerialConnection.openConnection(SerialConnection.java:136)
    at densconnect.DensTalk.<init>(DensTalk.java:165)
    at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
    at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
    at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
    at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
Caused by: java.lang.NullPointerException
    at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
CommPortIdentifier:addPortName(COM3)
CommPortIdentifier:AddIdentifierToList()
CommPortIdentifier:AddIdentifierToList() null
...


It looks like it  read COM3 from the file, but it had the above 
exception that killed it.  The strange this is this error is from 
RXTXCommDriver initialize function (if statement line):

        OS = System.getProperty("os.name");
                System.out.println("OS NAME: " + OS);
        if(OS.toLowerCase().indexOf("linux") == -1)

OS is returning null, thus the error.

If the file is not present, it scans the ports and reads the OS.

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>Doug Thistlethwaite wrote:
>  
>
>>Trent,
>>
>>I commented out the section in RegisterScannedPorts() that adds the 
>>three LPT ports to the CandidateDeviceNames string array.  The 
>>application started immediately.  This is probably not the way to do 
>>this, but it was quick ,dirty, and worked.
>>
>>It would be nice if there was a way to pole the OS to see if there is 
>>even a port there, though I guess this is what this code is suppose to do...
>>
>>Doug
>>
>>Trent Jarvi wrote:
>>
>>    
>>
>>>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>>
>>> 
>>>
>>>...
>>>
>>>
>>>Does commenting out the LPT enumeration actually help?  There can often be 
>>>differences between debug information printed and whats really going on. 
>>>When you combine various environments the debug info can even come out in 
>>>the wrong order.
>>>
>>>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>>>I do not think this problem is universal.
>>>
>>>--
>>>Trent Jarvi
>>>tjarvi at qbang.org
>>>_______________________________________________
>>>Rxtx mailing list
>>>Rxtx at qbang.org
>>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>>
>>>
>>> 
>>>
>>>      
>>>
>>_______________________________________________
>>Rxtx mailing list
>>Rxtx at qbang.org
>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>    
>>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/bf4cca0e/attachment-0009.html

From doug at dupreeinc.com  Thu Jun  1 16:51:26 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:51:26 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6F6E.5060603@dupreeinc.com>

Jim,

I did not try your suggestion as I do not understand where I would put 
these command line parameters (it that is what they are).  It appears 
that using the properties file should do that same thing...

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>
>  
>


From doug at dupreeinc.com  Thu Jun  1 17:56:19 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 16:56:19 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
Message-ID: <447F7EA3.6050400@dupreeinc.com>

I think there is an error in the registerSpecifiedPorts() method.  When 
I have a gnu.io.rxtx.properties file in the ext directory, this function 
kills the System class  IF I call System.getProperty("os.name") before 
the call  to registerSpecifiedPorts(), it returns the os name, after the 
call, it returns null.  I have not played much with properties, except 
for reading them, so I don't really understand the code.

Doug



From doug at dupreeinc.com  Thu Jun  1 18:11:14 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 17:11:14 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F7EA3.6050400@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com>
Message-ID: <447F8222.3060402@dupreeinc.com>

Ok, I just hacked this thing up and got it to read the 
gnu.io.rxtx.properties file.

I commented out the line:
System.setProperties(p); in the method registerSpecifiedPorts() in 
RXTXCommDriver class.  I really don't understand that much about 
properties, but this call kills the System class.

I used the following in the gnu.io.rxtx.properties file:

gnu.io.rxtx.SerialPorts=COM3
gnu.io.rxtx.ParallelPorts=null

This allows the application to open very quickly without any errors.  
Whomever coded this class or somebody who understands properties should 
look at this method and make sure it is doing what they expect.

Doug




Doug Thistlethwaite wrote:

>I think there is an error in the registerSpecifiedPorts() method.  When 
>I have a gnu.io.rxtx.properties file in the ext directory, this function 
>kills the System class  IF I call System.getProperty("os.name") before 
>the call  to registerSpecifiedPorts(), it returns the os name, after the 
>call, it returns null.  I have not played much with properties, except 
>for reading them, so I don't really understand the code.
>
>Doug
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From tjarvi at qbang.org  Thu Jun  1 18:32:50 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 18:32:50 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F6EF4.7080709@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com> <447F6EF4.7080709@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011831510.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
> folder.  I created this file and added the following to the file:
>
> gnu.io.rxtx.SerialPorts=COM3
>
> and I get the following error on the console:
> CommPortIdentifier:static initialization()
> RXTXCommDriver {}
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
> RXTXCommDriver:
>   Jar version = RXTX-2.1-7
>   native lib Version = RXTX-2.1-7
> RXTXCommDriver:initialize()
> checking for system-known ports of type 1
> checking registry for ports of type 1
>
> RXTXCommDriver:addSpecifiedPorts()
> Exception in thread "main" java.lang.ExceptionInInitializerError
>   at densconnect.SerialConnection.openConnection(SerialConnection.java:136)
>   at densconnect.DensTalk.<init>(DensTalk.java:165)
>   at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
>   at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
>   at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
>   at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
> Caused by: java.lang.NullPointerException
>   at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
> CommPortIdentifier:addPortName(COM3)
> CommPortIdentifier:AddIdentifierToList()
> CommPortIdentifier:AddIdentifierToList() null
> ...
>
>

There is a solution for this bug.

http://bugzilla.qbang.org/show_bug.cgi?id=54

We have been horribly slow at getting the next round of patches in but 
they are comming.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  2 00:58:02 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 08:58:02 +0200
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F8222.3060402@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
Message-ID: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>

Hi Doug,

you wrote in an earlier message, that you would prefer an unchanged  
version. What about simply removing the RXTX parallel lib from the  
ext directory. This does not fix the bug, but it should fix your  
problem.

In general I think it is not a good idea to put the RXTX files in a  
system wide location. Putting the libs in the application folder and  
including the .jar in the application classpath (or application jar)  
is all that is required.

Regards,
Joachim

On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:

> Ok, I just hacked this thing up and got it to read the
> gnu.io.rxtx.properties file.
>
> I commented out the line:
> System.setProperties(p); in the method registerSpecifiedPorts() in
> RXTXCommDriver class.  I really don't understand that much about
> properties, but this call kills the System class.
>
> I used the following in the gnu.io.rxtx.properties file:
>
> gnu.io.rxtx.SerialPorts=COM3
> gnu.io.rxtx.ParallelPorts=null
>
> This allows the application to open very quickly without any errors.
> Whomever coded this class or somebody who understands properties  
> should
> look at this method and make sure it is doing what they expect.
>
> Doug
>
>
>
>
> Doug Thistlethwaite wrote:
>
>> I think there is an error in the registerSpecifiedPorts() method.   
>> When
>> I have a gnu.io.rxtx.properties file in the ext directory, this  
>> function
>> kills the System class  IF I call System.getProperty("os.name")  
>> before
>> the call  to registerSpecifiedPorts(), it returns the os name,  
>> after the
>> call, it returns null.  I have not played much with properties,  
>> except
>> for reading them, so I don't really understand the code.
>>
>> 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 antonio.luis at iscte.pt  Fri Jun  2 02:42:28 2006
From: antonio.luis at iscte.pt (=?ISO-8859-1?Q?Ant=F3nio_Lopes?=)
Date: Fri, 02 Jun 2006 09:42:28 +0100
Subject: [Rxtx] Exception when closing serial port
Message-ID: <447FF9F4.7060209@iscte.pt>

Hello everyone,
I've been using RXTX in a Java application in my Pocket PC.
The communication through the (bluetooth) serial port is working perfectly.

However, when I disconnect the app and close the serial port, sometimes I get 
the following error:

"1149237595000: RXTXPort:close detected bad File Descriptor"

The problem is that after this error occurs, the app is no longer able to 
connect to the serial port and I have to soft-reset the device in order to be 
able to connect to it again.

Any ideas on how to solve this issue?

Any help is appreciated.
Thanks,
regards,
-- 
Ant?nio Lopes

@contact: antonio.luis at iscte.pt
@work: ADETTI - ISCTE
@web: http://antonio.lopes.googlepages.com


From paul.klissner at sun.com  Fri Jun  2 02:44:34 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 01:44:34 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to RXTX
	again
Message-ID: <447FFA72.6040807@sun.com>

After looking into javax.comm 3.1 and what it would take to re-engineer it
to be compatible with RXTX platform libraries, I've decided, due my group's
priorities, complexity of the effort vs. benefit, and limited resources, 
to re-post
javax.comm 2.0 binaries on Sun's software download server, unsupported,
with disclaimers, as it was previously.

I don't think there will be any snags doing this from the standpoint of Sun
management or legality.  I will try to have it  posted there in the next 
week
or two, depending on how fast we can get it pushed through the process.

I'd like to think of this as a stop gap measure... ie. a compromise, 
where, at some
point in the not too distant future RXTX implements their own version of the
Java side of the API, as is normally done by javax.extension porters. 
That way
we avoid uncomfortable dependencies in the future.  And that really is 
the Java
development model.

Since RXTX already has the back-end code, porting the java code shouldn't
be a gargantuan effort at all, and RXTX will be in full control of the 
code top
to bottom. I think RXTX can do at least as good a job as the original 
coder.
Prepping 2.0 to be open sourced is more trouble than it is worth. ie. I 
don't
think the current implementation warrants it.

Ultimately, it would be nice to see someone open up a JSR and re-architect
the comm. API to overcome some of it's current design flaws (ie. be more
adaptable to modern platforms, more pluggable, better defined SPI, better
port ownership handling, etc...). A superior architecture would allow for
better collaboration in the future and better interchangeability of 
components
among projects.

Sun's 3.1 version of javax.comm, which is Sun's currently supported version,
has changes pertaining mostly to Sun platform-specific portmapping and has
some minor additional interactions with our back end code, but generally
has little bearing on RXTX. 

Paul



From joachim at buechse.de  Fri Jun  2 04:00:19 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 12:00:19 +0200
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
	RXTX again
In-Reply-To: <447FFA72.6040807@sun.com>
References: <447FFA72.6040807@sun.com>
Message-ID: <1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>

Good day Paul!

A clean architecture with loadable drivers and reusable code would be  
very beneficial for the future, I think everybody agrees. However  
this could be several years into the future. In the meantime, there  
is a real existing problem with IO support on Java. I have the strong  
feeling that most programmers want to code against one specification  
(javax.comm) and be able to replace the underlying implementation via  
a "plugin" on platforms where the SUN implementation is not  
sufficient. RXTX could be just this plugin (reusing very close to 0%  
of the javax.comm implementation but 100% of its API).

I want to propose an API addition and implementation change that will  
take less then 2 hours of manpower to implement and create a solution  
that can bridge the years until javax.comm has been based on a new  
architecture.

Looking at the javax.comm api at http://java.sun.com/products/ 
javacomm/reference/api/index.html I would like to propose the following:

The only entry point to javax.comm is CommPortIdentifier. It has 3  
static methods plus the constructor.

1) define one additional Interface

public interface CommProvider {
    CommPortIdentifier getPortIdentifier(CommPort port);
    CommPortIdentifier getPortIdentifier(String portName);
    Enumeration getPortIdentifiers ();
}

2) add one method to CommPortIdentifier

   public static setCustomCommProvider (CommProvider);

3) change the three static methods of CommPortIdentifier to dispatch  
to the CommProvider if it is set

4) change the constructor of CommPortIdentifier to

   public CommPortIdentifier(...) {
      if (isProviderSet && this.getClass() ==  
javax.comm.CommPortIdentifier) {
          throw new RuntimeException("illegal creation of  
CommPortIndentifier, custom CommProvider is in use");
      }

5) (this is optional, but would be very nice) automatically set a  
custom CommProvider if it is found on the classpath or defined via a  
system property.


The above 1) - 4) can be implemented in less than 1hour. 5) may take  
another hour. I agree that this is not the most elegant design, but  
it would solve a lot of problems with very little effort. It would  
certainly allow RXTX to move forward. If the javax.comm API needs to  
be redesigned completely this addition will not hurt, as people will  
move to the new API anyway and javax.comm 3.0 was so far never  
included in the main distribution.

Best regards,
Joachim

On 02.06.2006, at 10:44, Paul Klissner wrote:

> After looking into javax.comm 3.1 and what it would take to re- 
> engineer it
> to be compatible with RXTX platform libraries, I've decided, due my  
> group's
> priorities, complexity of the effort vs. benefit, and limited  
> resources,
> to re-post
> javax.comm 2.0 binaries on Sun's software download server,  
> unsupported,
> with disclaimers, as it was previously.
>
> I don't think there will be any snags doing this from the  
> standpoint of Sun
> management or legality.  I will try to have it  posted there in the  
> next
> week
> or two, depending on how fast we can get it pushed through the  
> process.
>
> I'd like to think of this as a stop gap measure... ie. a compromise,
> where, at some
> point in the not too distant future RXTX implements their own  
> version of the
> Java side of the API, as is normally done by javax.extension porters.
> That way
> we avoid uncomfortable dependencies in the future.  And that really is
> the Java
> development model.
>
> Since RXTX already has the back-end code, porting the java code  
> shouldn't
> be a gargantuan effort at all, and RXTX will be in full control of the
> code top
> to bottom. I think RXTX can do at least as good a job as the original
> coder.
> Prepping 2.0 to be open sourced is more trouble than it is worth.  
> ie. I
> don't
> think the current implementation warrants it.
>
> Ultimately, it would be nice to see someone open up a JSR and re- 
> architect
> the comm. API to overcome some of it's current design flaws (ie. be  
> more
> adaptable to modern platforms, more pluggable, better defined SPI,  
> better
> port ownership handling, etc...). A superior architecture would  
> allow for
> better collaboration in the future and better interchangeability of
> components
> among projects.
>
> Sun's 3.1 version of javax.comm, which is Sun's currently supported  
> version,
> has changes pertaining mostly to Sun platform-specific portmapping  
> and has
> some minor additional interactions with our back end code, but  
> generally
> has little bearing on RXTX.
>
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Fri Jun  2 09:10:13 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Fri, 2 Jun 2006 09:10:13 -0600 (MDT)
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <447FFA72.6040807@sun.com>
References: <447FFA72.6040807@sun.com>
Message-ID: <Pine.LNX.4.61.0606020906400.15971@www>

On Fri, 2 Jun 2006, Paul Klissner wrote:

> After looking into javax.comm 3.1 and what it would take to re-engineer it
> to be compatible with RXTX platform libraries, I've decided, due my group's
> priorities, complexity of the effort vs. benefit, and limited resources,
> to re-post
> javax.comm 2.0 binaries on Sun's software download server, unsupported,
> with disclaimers, as it was previously.
>

Hi Paul

To address users' immediate needs, we can release rxtx 2.0-7 (final) to 
match the 2.0 binaries from Sun when they are offered for download.

We can discuss potential long term solutions after that.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Fri Jun  2 10:20:09 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 02 Jun 2006 09:20:09 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
	<9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
Message-ID: <44806539.8080902@dupreeinc.com>

Thanks for the suggestion, I will give it a try.

Doug

Joachim Buechse wrote:

>Hi Doug,
>
>you wrote in an earlier message, that you would prefer an unchanged  
>version. What about simply removing the RXTX parallel lib from the  
>ext directory. This does not fix the bug, but it should fix your  
>problem.
>
>In general I think it is not a good idea to put the RXTX files in a  
>system wide location. Putting the libs in the application folder and  
>including the .jar in the application classpath (or application jar)  
>is all that is required.
>
>Regards,
>Joachim
>
>On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:
>
>  
>
>>Ok, I just hacked this thing up and got it to read the
>>gnu.io.rxtx.properties file.
>>
>>I commented out the line:
>>System.setProperties(p); in the method registerSpecifiedPorts() in
>>RXTXCommDriver class.  I really don't understand that much about
>>properties, but this call kills the System class.
>>
>>I used the following in the gnu.io.rxtx.properties file:
>>
>>gnu.io.rxtx.SerialPorts=COM3
>>gnu.io.rxtx.ParallelPorts=null
>>
>>This allows the application to open very quickly without any errors.
>>Whomever coded this class or somebody who understands properties  
>>should
>>look at this method and make sure it is doing what they expect.
>>
>>Doug
>>
>>
>>
>>
>>Doug Thistlethwaite wrote:
>>
>>    
>>
>>>I think there is an error in the registerSpecifiedPorts() method.   
>>>When
>>>I have a gnu.io.rxtx.properties file in the ext directory, this  
>>>function
>>>kills the System class  IF I call System.getProperty("os.name")  
>>>before
>>>the call  to registerSpecifiedPorts(), it returns the os name,  
>>>after the
>>>call, it returns null.  I have not played much with properties,  
>>>except
>>>for reading them, so I don't really understand the code.
>>>
>>>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
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060602/c8892a46/attachment-0009.html

From paul.klissner at sun.com  Fri Jun  2 12:09:26 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 11:09:26 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
Message-ID: <44807ED6.8000903@sun.com>

Joachim Buechse wrote:
> Good day Paul!
>
> A clean architecture with loadable drivers and reusable code would be  
> very beneficial for the future, I think everybody agrees. However  
> this could be several years into the future. In the meantime, there  
> is a real existing problem with IO support on Java. I have the strong  
> feeling that most programmers want to code against one specification  
> (javax.comm) and be able to replace the underlying implementation via  
> a "plugin" on platforms where the SUN implementation is not  
> sufficient. RXTX could be just this plugin (reusing very close to 0%  
> of the javax.comm implementation but 100% of its API).
>
> I want to propose an API addition and implementation change that will  
> take less then 2 hours of manpower to implement and create a solution  
> that can bridge the years until javax.comm has been based on a new  
> architecture.
>
> Looking at the javax.comm api at http://java.sun.com/products/ 
> javacomm/reference/api/index.html I would like to propose the following:
>
> The only entry point to javax.comm is CommPortIdentifier. It has 3  
> static methods plus the constructor.
>
> 1) define one additional Interface
>
> public interface CommProvider {
>     CommPortIdentifier getPortIdentifier(CommPort port);
>     CommPortIdentifier getPortIdentifier(String portName);
>     Enumeration getPortIdentifiers ();
> }
>
> 2) add one method to CommPortIdentifier
>
>    public static setCustomCommProvider (CommProvider);
>
> 3) change the three static methods of CommPortIdentifier to dispatch  
> to the CommProvider if it is set
>
> 4) change the constructor of CommPortIdentifier to
>
>    public CommPortIdentifier(...) {
>       if (isProviderSet && this.getClass() ==  
> javax.comm.CommPortIdentifier) {
>           throw new RuntimeException("illegal creation of  
> CommPortIndentifier, custom CommProvider is in use");
>       }
>
> 5) (this is optional, but would be very nice) automatically set a  
> custom CommProvider if it is found on the classpath or defined via a  
> system property.
>
>
> The above 1) - 4) can be implemented in less than 1hour. 5) may take  
> another hour. I agree that this is not the most elegant design, but  
> it would solve a lot of problems with very little effort. It would  
> certainly allow RXTX to move forward. If the javax.comm API needs to  
> be redesigned completely this addition will not hurt, as people will  
> move to the new API anyway and javax.comm 3.0 was so far never  
> included in the main distribution.
>
> Best regards,
> Joachi
I'm afraid modifying the interface classes isn't my call.  There was 
actually
a TCK written and one of the tests was to ensure that the interface classes
match the spec.  Thus my hands have already been tied since this project
was essentially grandfathered into the JCP.

That's why we need to open a new JSR and find someone who wants
to be the spec lead, and go in with a new reference implementation.
I'm not sure why it would have to take years, since this isn't bleeding edge
technology and there are only so many things that can be done with it,
and we already have practical experience about many functional aspects
that we could cite precedence on.

As it becomes clear that the specification is being accepted completely
or by-and-large by the community, nothing would stop people from
starting adapting to the new API (using the reference implementation or
porting it) and using it in their projects prior to it's final community and
JCP approval, since approval is required only to make it official and
get the "100% pure java" certification for platform ports.

You have one idea already.  Why don't you implement it, solicit some
design feedback from Sun and the RXTX, and create a functional
implementation that addresses the needs of the community, then
we can document it and open a JSR.  That's it.  It should march through
the approval stages reasonably quickly I would imagine, and meantime
RXTX could start using it.

Paul




From doug at dupreeinc.com  Fri Jun  2 12:45:01 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 02 Jun 2006 11:45:01 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
	<9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
Message-ID: <4480872D.6000605@dupreeinc.com>

Joachim,

Thank you for the suggestion.  I restored the jar file to the one I 
downloaded, moved the dll files into the project directory, and added 
the jar to the classpath.  The SerialDemo program that was included with 
the Sun commapi started in 12 seconds instead of the 58 seconds when the 
parallel dll is present.  I did get the startup time to about a second 
by modifying the java code and adding the properties file but this is 
probably not a good idea.

Doug

Joachim Buechse wrote:

>Hi Doug,
>
>you wrote in an earlier message, that you would prefer an unchanged  
>version. What about simply removing the RXTX parallel lib from the  
>ext directory. This does not fix the bug, but it should fix your  
>problem.
>
>In general I think it is not a good idea to put the RXTX files in a  
>system wide location. Putting the libs in the application folder and  
>including the .jar in the application classpath (or application jar)  
>is all that is required.
>
>Regards,
>Joachim
>
>On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:
>
>  
>
>>Ok, I just hacked this thing up and got it to read the
>>gnu.io.rxtx.properties file.
>>
>>I commented out the line:
>>System.setProperties(p); in the method registerSpecifiedPorts() in
>>RXTXCommDriver class.  I really don't understand that much about
>>properties, but this call kills the System class.
>>
>>I used the following in the gnu.io.rxtx.properties file:
>>
>>gnu.io.rxtx.SerialPorts=COM3
>>gnu.io.rxtx.ParallelPorts=null
>>
>>This allows the application to open very quickly without any errors.
>>Whomever coded this class or somebody who understands properties  
>>should
>>look at this method and make sure it is doing what they expect.
>>
>>Doug
>>
>>
>>
>>
>>Doug Thistlethwaite wrote:
>>
>>    
>>
>>>I think there is an error in the registerSpecifiedPorts() method.   
>>>When
>>>I have a gnu.io.rxtx.properties file in the ext directory, this  
>>>function
>>>kills the System class  IF I call System.getProperty("os.name")  
>>>before
>>>the call  to registerSpecifiedPorts(), it returns the os name,  
>>>after the
>>>call, it returns null.  I have not played much with properties,  
>>>except
>>>for reading them, so I don't really understand the code.
>>>
>>>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
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060602/3c0e420f/attachment-0009.html

From joachim at buechse.de  Fri Jun  2 13:46:36 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 21:46:36 +0200
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
	RXTX again
In-Reply-To: <44807ED6.8000903@sun.com>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
	<44807ED6.8000903@sun.com>
Message-ID: <6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>

Hello Paul,

of course, the basic change I suggested could be done "hidden".  The  
CommProvider interface could live somewhere in sun.xyz.*
The setCustomCommProvider method would not be in CommPortIdentifier  
but also somewhere in sun.xyz.* This would be an unofficial feature,  
the official interface stays exactly the same. However RXTX (and  
others) could access the hidden interface.

Don't get me wrong, I don't want to harass you into making changes  
you don't like (which probably wouldn't work anyway;-). But I'm a  
long time Java programmer and seeing the state of cross platform  
serial support for Java makes me feel really sad. In fact, when I  
started to look into Java serial port programming some months ago I  
was very surprised that javax.comm never made it into the JDK.

I'm sorry that I did not contribute my feedback to the JSR for  
javax.comm 3.0. However at the time I didn't do serial port  
programming in Java. I agree that a new JSR should be opened - I'm  
not an expert on JSRs or the JCP process, but from looking quickly  
over the progress of some JSRs I would be very surprised if we can  
have a new version in less then a year. In the meanwhile some people  
will start using javax.comm 3.0 (which can not be supported by RXTX),  
some will use javax.comm 2.0 (which means the 2.0.7 release of RXTX  
still needs to be maintained). This may get even worse if eg Apple  
decides to port and include javax.comm 3.0 at which point it may get  
very tricky to write a cross platform Java application.

All of this simply means, that we are loosing a lot of man-power that  
could otherwise be invested in building a clean solution and/or to  
add features that are becoming more and more important (USB events...).

In the automation / machine control universe Java makes a lot of  
sense. Right now many people are migrating to Linux or from  
propietary systems (even DOS) to Windows. Writing the control/ 
configuration applications in Java is the kings way to unify the code  
base.

Best regards,
Joachim


On 02.06.2006, at 20:09, Paul Klissner wrote:

> Joachim Buechse wrote:
>> Good day Paul!
>>
>> A clean architecture with loadable drivers and reusable code would be
>> very beneficial for the future, I think everybody agrees. However
>> this could be several years into the future. In the meantime, there
>> is a real existing problem with IO support on Java. I have the strong
>> feeling that most programmers want to code against one specification
>> (javax.comm) and be able to replace the underlying implementation via
>> a "plugin" on platforms where the SUN implementation is not
>> sufficient. RXTX could be just this plugin (reusing very close to 0%
>> of the javax.comm implementation but 100% of its API).
>>
>> I want to propose an API addition and implementation change that will
>> take less then 2 hours of manpower to implement and create a solution
>> that can bridge the years until javax.comm has been based on a new
>> architecture.
>>
>> Looking at the javax.comm api at http://java.sun.com/products/
>> javacomm/reference/api/index.html I would like to propose the  
>> following:
>>
>> The only entry point to javax.comm is CommPortIdentifier. It has 3
>> static methods plus the constructor.
>>
>> 1) define one additional Interface
>>
>> public interface CommProvider {
>>     CommPortIdentifier getPortIdentifier(CommPort port);
>>     CommPortIdentifier getPortIdentifier(String portName);
>>     Enumeration getPortIdentifiers ();
>> }
>>
>> 2) add one method to CommPortIdentifier
>>
>>    public static setCustomCommProvider (CommProvider);
>>
>> 3) change the three static methods of CommPortIdentifier to dispatch
>> to the CommProvider if it is set
>>
>> 4) change the constructor of CommPortIdentifier to
>>
>>    public CommPortIdentifier(...) {
>>       if (isProviderSet && this.getClass() ==
>> javax.comm.CommPortIdentifier) {
>>           throw new RuntimeException("illegal creation of
>> CommPortIndentifier, custom CommProvider is in use");
>>       }
>>
>> 5) (this is optional, but would be very nice) automatically set a
>> custom CommProvider if it is found on the classpath or defined via a
>> system property.
>>
>>
>> The above 1) - 4) can be implemented in less than 1hour. 5) may take
>> another hour. I agree that this is not the most elegant design, but
>> it would solve a lot of problems with very little effort. It would
>> certainly allow RXTX to move forward. If the javax.comm API needs to
>> be redesigned completely this addition will not hurt, as people will
>> move to the new API anyway and javax.comm 3.0 was so far never
>> included in the main distribution.
>>
>> Best regards,
>> Joachi
> I'm afraid modifying the interface classes isn't my call.  There was
> actually
> a TCK written and one of the tests was to ensure that the interface  
> classes
> match the spec.  Thus my hands have already been tied since this  
> project
> was essentially grandfathered into the JCP.
>
> That's why we need to open a new JSR and find someone who wants
> to be the spec lead, and go in with a new reference implementation.
> I'm not sure why it would have to take years, since this isn't  
> bleeding edge
> technology and there are only so many things that can be done with it,
> and we already have practical experience about many functional aspects
> that we could cite precedence on.
>
> As it becomes clear that the specification is being accepted  
> completely
> or by-and-large by the community, nothing would stop people from
> starting adapting to the new API (using the reference  
> implementation or
> porting it) and using it in their projects prior to it's final  
> community and
> JCP approval, since approval is required only to make it official and
> get the "100% pure java" certification for platform ports.
>
> You have one idea already.  Why don't you implement it, solicit some
> design feedback from Sun and the RXTX, and create a functional
> implementation that addresses the needs of the community, then
> we can document it and open a JSR.  That's it.  It should march  
> through
> the approval stages reasonably quickly I would imagine, and meantime
> RXTX could start using it.
>
> Paul
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From paul.klissner at sun.com  Fri Jun  2 14:38:49 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 13:38:49 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
	<44807ED6.8000903@sun.com>
	<6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>
Message-ID: <4480A1D9.5060106@sun.com>

Joachim Buechse wrote:
> Hello Paul,
>
> of course, the basic change I suggested could be done "hidden".  The  
> CommProvider interface could live somewhere in sun.xyz.*
> The setCustomCommProvider method would not be in CommPortIdentifier  
> but also somewhere in sun.xyz.* This would be an unofficial feature,  
> the official interface stays exactly the same. However RXTX (and  
> others) could access the hidden interface.
>
> Don't get me wrong, I don't want to harass you into making changes  
> you don't like (which probably wouldn't work anyway;-). But I'm a  
> long time Java programmer and seeing the state of cross platform  
> serial support for Java makes me feel really sad. In fact, when I  
> started to look into Java serial port programming some months ago I  
> was very surprised that javax.comm never made it into the JDK.
>
> I'm sorry that I did not contribute my feedback to the JSR for  
> javax.comm 3.0. 
There was no JSR for 3.0, because we didn't have the resources to make 
the commitment.
Yet Sun needed to add support for platform-dependent port name mapping, 
which had to
be done 'under the hood', since the API isn't designed to handle that in 
a pluggable way.
But these quick fixes aren't the right approach, they just kick the dog 
down the road,
setting bad precedent, inviting confusion and more intractable problems 
(such as the
one plaguing us now).

My changes could have been layered better, it was a trade off between 
achieving an
ideal architecture, trying to find internal reviewers, and meet the 
needs of big customers
in a timely way.  Thus my namespace changes collided with RXTX's 
dependencies.
I was unaware of Jagane's rogue agreement made with the RXTX community 7 
years ago,
before Jagane left Sun.  I think this was a wag-the-dog situation.

Now it is time to do it right, and I don't think it is going to be as 
much trouble as people
some people fear. If RXTX wants to sponsor the JSR and seed a new spec, 
Sun can join
the Expert Group.  And we'd be largely in agreement, since we're not 
talking about
humongous changes, and looking for mutually beneficial changes. The core 
API is already
largely proved and tested.
> However at the time I didn't do serial port  
> programming in Java. I agree that a new JSR should be opened - I'm  
> not an expert on JSRs or the JCP process, but from looking quickly  
> over the progress of some JSRs I would be very surprised if we can  
> have a new version in less then a year. 
*Approved*  But that doesn't mean the spec couldn't be 99.9% stable 
before that.  Once
the delta rate declines and changes approach nil, people could start 
adapting to the API in
advance of formal approval.   It isn't going to be drawn out like 
javax.usb, which was new
technology, a very complex API, and involved precedent setting corporate 
disputes and
policy issues to resolve.

> In the meanwhile some people  
> will start using javax.comm 3.0 (which can not be supported by RXTX),  
> some will use javax.comm 2.0 (which means the 2.0.7 release of RXTX  
> still needs to be maintained). This may get even worse if eg Apple  
> decides to port and include javax.comm 3.0 at which point it may get  
> very tricky to write a cross platform Java application.
>   
The interfaces haven't changed since 1.0.  If we open a JSR ,we can 
contact Apple and
allow them to be on the E.G., if they want.  That might make the JSR a 
bit more drawn out,
but then we'd arrive ultimately arrive at a best-of-all-worlds API that 
most people would
accept, perhaps forever, and arrive at a respectable set of compromises.

-Paul

> All of this simply means, that we are loosing a lot of man-power that  
> could otherwise be invested in building a clean solution and/or to  
> add features that are becoming more and more important (USB events...).
>
> In the automation / machine control universe Java makes a lot of  
> sense. Right now many people are migrating to Linux or from  
> propietary systems (even DOS) to Windows. Writing the control/ 
> configuration applications in Java is the kings way to unify the code  
> base.
>
> Best regards,
> Joachim
>
>
> On 02.06.2006, at 20:09, Paul Klissner wrote:
>
>   
>> Joachim Buechse wrote:
>>     
>>> Good day Paul!
>>>
>>> A clean architecture with loadable drivers and reusable code would be
>>> very beneficial for the future, I think everybody agrees. However
>>> this could be several years into the future. In the meantime, there
>>> is a real existing problem with IO support on Java. I have the strong
>>> feeling that most programmers want to code against one specification
>>> (javax.comm) and be able to replace the underlying implementation via
>>> a "plugin" on platforms where the SUN implementation is not
>>> sufficient. RXTX could be just this plugin (reusing very close to 0%
>>> of the javax.comm implementation but 100% of its API).
>>>
>>> I want to propose an API addition and implementation change that will
>>> take less then 2 hours of manpower to implement and create a solution
>>> that can bridge the years until javax.comm has been based on a new
>>> architecture.
>>>
>>> Looking at the javax.comm api at http://java.sun.com/products/
>>> javacomm/reference/api/index.html I would like to propose the  
>>> following:
>>>
>>> The only entry point to javax.comm is CommPortIdentifier. It has 3
>>> static methods plus the constructor.
>>>
>>> 1) define one additional Interface
>>>
>>> public interface CommProvider {
>>>     CommPortIdentifier getPortIdentifier(CommPort port);
>>>     CommPortIdentifier getPortIdentifier(String portName);
>>>     Enumeration getPortIdentifiers ();
>>> }
>>>
>>> 2) add one method to CommPortIdentifier
>>>
>>>    public static setCustomCommProvider (CommProvider);
>>>
>>> 3) change the three static methods of CommPortIdentifier to dispatch
>>> to the CommProvider if it is set
>>>
>>> 4) change the constructor of CommPortIdentifier to
>>>
>>>    public CommPortIdentifier(...) {
>>>       if (isProviderSet && this.getClass() ==
>>> javax.comm.CommPortIdentifier) {
>>>           throw new RuntimeException("illegal creation of
>>> CommPortIndentifier, custom CommProvider is in use");
>>>       }
>>>
>>> 5) (this is optional, but would be very nice) automatically set a
>>> custom CommProvider if it is found on the classpath or defined via a
>>> system property.
>>>
>>>
>>> The above 1) - 4) can be implemented in less than 1hour. 5) may take
>>> another hour. I agree that this is not the most elegant design, but
>>> it would solve a lot of problems with very little effort. It would
>>> certainly allow RXTX to move forward. If the javax.comm API needs to
>>> be redesigned completely this addition will not hurt, as people will
>>> move to the new API anyway and javax.comm 3.0 was so far never
>>> included in the main distribution.
>>>
>>> Best regards,
>>> Joachi
>>>       
>> I'm afraid modifying the interface classes isn't my call.  There was
>> actually
>> a TCK written and one of the tests was to ensure that the interface  
>> classes
>> match the spec.  Thus my hands have already been tied since this  
>> project
>> was essentially grandfathered into the JCP.
>>
>> That's why we need to open a new JSR and find someone who wants
>> to be the spec lead, and go in with a new reference implementation.
>> I'm not sure why it would have to take years, since this isn't  
>> bleeding edge
>> technology and there are only so many things that can be done with it,
>> and we already have practical experience about many functional aspects
>> that we could cite precedence on.
>>
>> As it becomes clear that the specification is being accepted  
>> completely
>> or by-and-large by the community, nothing would stop people from
>> starting adapting to the new API (using the reference  
>> implementation or
>> porting it) and using it in their projects prior to it's final  
>> community and
>> JCP approval, since approval is required only to make it official and
>> get the "100% pure java" certification for platform ports.
>>
>> You have one idea already.  Why don't you implement it, solicit some
>> design feedback from Sun and the RXTX, and create a functional
>> implementation that addresses the needs of the community, then
>> we can document it and open a JSR.  That's it.  It should march  
>> through
>> the approval stages reasonably quickly I would imagine, and meantime
>> RXTX could start using it.
>>
>> Paul
>>
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at 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  Sat Jun  3 18:15:24 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 18:15:24 -0600 (MDT)
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
Message-ID: <Pine.LNX.4.61.0606031715100.10890@www>


The attached patch allows baud rates of 14400, 28800, 128000 and 256000.

That was my goal.

[import standard disclaimer]

But I took some time to look a little further.  I got custom baud rates 
working enough that someone (perhaps me) can properly fix them in the 
future.  Proof of concept.

As an undocumented bonus, you can toss random baudrates (say 1953), at the 
API and it will set it to something close to that on windows and linux. 
Solaris should say the baud rate is not supported but I have not tested it 
yet.  Mac OS X behavior is unknown at this point.  Just dont expect 
correct behavior at ~8192-9009 baudrates or baudrates less than 20 on 
windows; these baud rates overlap with defines in win32termios.h.  I 
conveniently closed my eyes there.  Try another value close.  On Linux, a 
baud base and divisor are guestimated and set.  On windows, we wave pixie 
dust over the kernel driver and hope.  Do not expect pixie dust and 
guestimates to be the same on windows and linux.  They may well round to 
different values in yet to be tested ways.  There are only so many 
divisors.  If it isn't working, try a little higher or lower.

In the example of 1953 for instance, there is no divisor for commodity 
hardware that comes to that baudrate.  We just come close on one side or 
the other.  If tools tell you they got 1953 exactly, the tools may be 
questionable and just reading values not directly related to the actual 
hardware settings.

These fixes have been tested on Linux and Windows while using an 
oscilloscope to confirm they change relative to known baudrates at 9600, 
14400*, 19200, 28800* (and 1800, 1953** and 2400).

* = previously unsupported.
** = still not supported but probably works from what I saw.

There could be future discussion in this area.  For now this is working 
for almost all unusual baud rate demands.  Cleaning up the custom baud 
rate should be easier with a working starting point.  Baud bases other 
than 128000 have not been characterized.  Yes.. this overlapps with two of 
the baud rates enabled.

Feedback and ideas are welcome.

--
Trent Jarvi
tjarvi at qbang.org
-------------- next part --------------
Index: SerialImp.c
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v
retrieving revision 1.46.2.187
diff -u -r1.46.2.187 SerialImp.c
--- SerialImp.c	29 Jan 2006 22:19:04 -0000	1.46.2.187
+++ SerialImp.c	3 Jun 2006 23:12:40 -0000
@@ -793,6 +793,19 @@
 		result &= ~TIOCM_DTR;
 		ioctl( fd, TIOCMSET, &result );
 	}
+	/*
+	   B38400 is a special case in Linux for custom baud rates.
+
+	   We just treat this as a custom speed for now.  If you take this ifdef
+	   out and select baud rates 38400 then 28800 then 38400, you will get
+	   a final baud rate of 28800 because you did not update the divisor.
+
+	   See the next ifdef below for the divisor.
+	*/
+#if defined(TIOCGSERIAL)
+	if ( cspeed == B38400 )
+		cspeed = 38400;
+#endif /* TIOCGSERIAL */
 	if(     cfsetispeed( &ttyset, cspeed ) < 0 ||
 		cfsetospeed( &ttyset, cspeed ) < 0 )
 	{
@@ -814,6 +827,7 @@
 		*/
 
 #if defined(TIOCGSERIAL)
+		ioctl( fd, TIOCGSERIAL, &sstruct );
 		sstruct.custom_divisor = ( sstruct.baud_base/cspeed );
 		cspeed = B38400;
 #endif /* TIOCGSERIAL */
@@ -827,7 +841,7 @@
 #if defined(TIOCSSERIAL)
 		/*  It is assumed Win32 does this for us */
 		if (	sstruct.baud_base < 1 ||
-			ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
+		ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
 		{
 			return( 1 );
 		}
Index: termios.c
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v
retrieving revision 1.9.2.56
diff -u -r1.9.2.56 termios.c
--- termios.c	16 Jan 2006 02:50:32 -0000	1.9.2.56
+++ termios.c	3 Jun 2006 23:12:40 -0000
@@ -323,8 +323,8 @@
 		case CBR_3500000:	return( B3500000 );
 		case CBR_4000000:	return( B4000000 );
 		default:
-			set_errno(EINVAL );
-			return -1;
+			/* assume custom baudrate */
+			return( Baud );
 	}
 }
 
@@ -361,12 +361,13 @@
 		case B9600:	ret = CBR_9600;		break;
 		case B14400:	ret = CBR_14400;	break;
 		case B19200:	ret = CBR_19200;	break;
+		case B28800:	ret = CBR_28800;	break;
 		case B38400:	ret = CBR_38400;	break;
 		case B57600:	ret = CBR_57600;	break;
 		case B115200:	ret = CBR_115200;	break;
 		case B128000:	ret = CBR_128000;	break;
-		case B256000: 	ret = CBR_256000;	break;
 		case B230400:	ret = CBR_230400;	break;
+		case B256000: 	ret = CBR_256000;	break;
 		case B460800:	ret = CBR_460800;	break;
 		case B500000:	ret = CBR_500000;	break;
 		case B576000:	ret = CBR_576000;	break;
@@ -381,10 +382,8 @@
 		case B4000000:	ret = CBR_4000000;	break;
 	
 		default:
-			fprintf( stderr, "B_to_CBR: invalid baudrate: %#o\n",
-				Baud );
-			set_errno( EINVAL );
-			return -1;
+			/* assume custom baudrate */
+			return Baud;
 	}
 	LEAVE( "B_to_CBR" );
 	return ret;
@@ -708,12 +707,9 @@
 	ENTER( "init_serial_struct" );
 
 	/*
-	FIXME
-
-	This needs to use inb() to read the actual baud_base
-	and divisor from the UART registers.  Question is how
-	far do we take this?
-
+	use of custom_divisor and baud_base requires access to
+	kernel space.  The kernel does try its best if you just
+	toss a baud rate at it though.
 	*/
 
 	sstruct->custom_divisor = 0;
@@ -1678,16 +1674,17 @@
 {
 	char message[80];
 	ENTER( "cfsetospeed" );
+	/* clear baudrate */
+	s_termios->c_cflag &= ~CBAUD;
 	if ( speed & ~CBAUD )
 	{
 		sprintf( message, "cfsetospeed: not speed: %#o\n", speed );
 		report( message );
-		return 0;
+		/* continue assuming its a custom baudrate */
+		s_termios->c_cflag |= B38400;  /* use 38400 during custom */
+		s_termios->c_cflag |= CBAUDEX; /* use CBAUDEX for custom */
 	}
-	s_termios->c_ispeed = s_termios->c_ospeed = speed;
-	/* clear baudrate */
-	s_termios->c_cflag &= ~CBAUD;
-	if( speed )
+	else if( speed )
 	{
 		s_termios->c_cflag |= speed;
 	}
@@ -1696,6 +1693,7 @@
 		/* PC blows up with speed 0 handled in Java */
 		s_termios->c_cflag |= B9600;
 	}
+	s_termios->c_ispeed = s_termios->c_ospeed = speed;
 	LEAVE( "cfsetospeed" );
 	return 1;
 }
@@ -1767,25 +1765,6 @@
 }
 
 /*----------------------------------------------------------
-serial_struct_to_DCB()
-
-   accept:      
-   perform:     
-   return:      
-   exceptions:  
-   win32api:     None
-   comments:    
-----------------------------------------------------------*/
-int serial_struct_to_DCB( struct serial_struct *sstruct, DCB *dcb )
-{
-	/* 5 Baud rate fix
-	sstruct.baud_base
-	sstruct.custom_divisor = ( sstruct.baud_base/cspeed );
-	*/
-	return(0);
-}
-
-/*----------------------------------------------------------
 termios_to_DCB()
 
    accept:      
@@ -1798,7 +1777,8 @@
 int termios_to_DCB( struct termios *s_termios, DCB *dcb )
 {
 	ENTER( "termios_to_DCB" );
-	s_termios->c_ispeed = s_termios->c_ospeed = s_termios->c_cflag & CBAUD;
+	if ( !(s_termios->c_cflag & CBAUDEX) )
+		s_termios->c_ispeed = s_termios->c_ospeed = s_termios->c_cflag & CBAUD;
 	dcb->BaudRate        = B_to_CBR( s_termios->c_ispeed );
 	dcb->ByteSize = termios_to_bytesize( s_termios->c_cflag );
 
@@ -2863,11 +2843,6 @@
 			GetCommState( index->hComm, dcb );
 
 			index->sstruct = va_arg( ap, struct serial_struct * );
-			if ( serial_struct_to_DCB( index->sstruct, dcb ) < 0 )
-			{
-				va_end( ap );
-				return -1;
-			}
 
 			report( "TIOCSSERIAL\n" );
 			free(dcb);
Index: win32termios.h
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v
retrieving revision 1.5.2.28
diff -u -r1.5.2.28 win32termios.h
--- win32termios.h	30 Jun 2005 20:23:26 -0000	1.5.2.28
+++ win32termios.h	3 Jun 2006 23:12:40 -0000
@@ -279,7 +279,7 @@
 #define XTABS	01000000 /* Hmm.. Linux/i386 considers this part of TABDLY.. */
 
 /* c_cflag bit meaning */
-# define CBAUD	0010017
+#define  CBAUD  0030017
 #define  B0	0000000		/* hang up */
 #define  B50	0000001
 #define  B75	0000002
@@ -312,13 +312,16 @@
 #define  B3500000 0010016
 #define  B4000000 0010017
 
-/* glue for unsupported linux speeds see also SerialImp.h */
-/* hosed */
-
-#define B14400		1010001
-#define B28800		1010002
-#define B128000		1010003
-#define B256000		1010004
+/*
+	glue for unsupported linux speeds see also SerialImp.h 
+	custom baud rates around 8192-9000 will not work because
+	of these.
+*/
+
+#define B14400		0020001
+#define B28800		0020002
+#define B128000		0020003
+#define B256000		0020004
 
 #define EXTA B19200
 #define EXTB B38400
@@ -356,8 +359,10 @@
 
 /* glue for unsupported windows speeds */
 
-#define CBR_230400	230400
 #define CBR_28800	28800
+#define CBR_128000	128000
+#define CBR_230400	230400
+#define CBR_256000	256000
 #define CBR_460800	460800
 #define CBR_500000	500000
 #define CBR_576000	576000

From impakt01 at optusnet.com.au  Sat Jun  3 18:30:37 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 10:30:37 +1000
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
In-Reply-To: <Pine.LNX.4.61.0606031715100.10890@www>
Message-ID: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>

Hi Trent,
I'd love to try the patch but I can't get the latest build compiling, only
pre16. 

Can you attach the rxtxSerial.dll file with this patch?

Also, I hardcoded 1953 in a couple more places last night on pre16 and it
managed to open the port at the right speed, but stopped receiving anything
after 100-150 bytes, even though more data was getting sent to the port.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 10:15 AM
To: rxtx at qbang.org
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.


The attached patch allows baud rates of 14400, 28800, 128000 and 256000.

That was my goal.

[import standard disclaimer]

But I took some time to look a little further.  I got custom baud rates 
working enough that someone (perhaps me) can properly fix them in the 
future.  Proof of concept.

As an undocumented bonus, you can toss random baudrates (say 1953), at the 
API and it will set it to something close to that on windows and linux. 
Solaris should say the baud rate is not supported but I have not tested it 
yet.  Mac OS X behavior is unknown at this point.  Just dont expect 
correct behavior at ~8192-9009 baudrates or baudrates less than 20 on 
windows; these baud rates overlap with defines in win32termios.h.  I 
conveniently closed my eyes there.  Try another value close.  On Linux, a 
baud base and divisor are guestimated and set.  On windows, we wave pixie 
dust over the kernel driver and hope.  Do not expect pixie dust and 
guestimates to be the same on windows and linux.  They may well round to 
different values in yet to be tested ways.  There are only so many 
divisors.  If it isn't working, try a little higher or lower.

In the example of 1953 for instance, there is no divisor for commodity 
hardware that comes to that baudrate.  We just come close on one side or 
the other.  If tools tell you they got 1953 exactly, the tools may be 
questionable and just reading values not directly related to the actual 
hardware settings.

These fixes have been tested on Linux and Windows while using an 
oscilloscope to confirm they change relative to known baudrates at 9600, 
14400*, 19200, 28800* (and 1800, 1953** and 2400).

* = previously unsupported.
** = still not supported but probably works from what I saw.

There could be future discussion in this area.  For now this is working 
for almost all unusual baud rate demands.  Cleaning up the custom baud 
rate should be easier with a working starting point.  Baud bases other 
than 128000 have not been characterized.  Yes.. this overlapps with two of 
the baud rates enabled.

Feedback and ideas are welcome.

--
Trent Jarvi
tjarvi at qbang.org



From tjarvi at qbang.org  Sat Jun  3 19:05:11 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 19:05:11 -0600 (MDT)
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
In-Reply-To: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>
References: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606031840400.10890@www>

On Sun, 4 Jun 2006, Daren wrote:

> Hi Trent,
> I'd love to try the patch but I can't get the latest build compiling, only
> pre16.
>
> Can you attach the rxtxSerial.dll file with this patch?
>
> Also, I hardcoded 1953 in a couple more places last night on pre16 and it
> managed to open the port at the right speed, but stopped receiving anything
> after 100-150 bytes, even though more data was getting sent to the port.
>


ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing

I dont think they will hang.  But I was just testing via loopback/break 
out box/scope.

I'll be putting about 10 patches and another set of binaries in that 
directory shortly.  For now the binaries should just have the baud_rate 
fix.

I'll announce all the patches at once.  but wont be releasing 2.1-8 right 
away.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Sat Jun  3 21:00:01 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 21:00:01 -0600 (MDT)
Subject: [Rxtx] CVS for 2.1 should have everything
Message-ID: <Pine.LNX.4.61.0606032056190.10890@www>


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org


From impakt01 at optusnet.com.au  Sat Jun  3 21:08:14 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 13:08:14 +1000
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <Pine.LNX.4.61.0606032056190.10890@www>
Message-ID: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>

Hi Trent,
I tried the latest dll and it opens the port, receives 100-200 bytes and
then stops receiving anything else..

I'll keep playing with it.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 1:00 PM
To: rxtx at qbang.org
Subject: [Rxtx] CVS for 2.1 should have everything


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From impakt01 at optusnet.com.au  Sat Jun  3 21:22:41 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 13:22:41 +1000
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
Message-ID: <200606040322.k543MqW1008455@mail12.syd.optusnet.com.au>

Played with it, problem, with a while loop in my code, working great now

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Daren
Sent: Sunday, 4 June 2006 1:08 PM
To: 'RXTX Developers and Users'
Subject: Re: [Rxtx] CVS for 2.1 should have everything

Hi Trent,
I tried the latest dll and it opens the port, receives 100-200 bytes and
then stops receiving anything else..

I'll keep playing with it.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 1:00 PM
To: rxtx at qbang.org
Subject: [Rxtx] CVS for 2.1 should have everything


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Sat Jun  3 21:35:41 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 21:35:41 -0600 (MDT)
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
References: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606032131140.10890@www>

On Sun, 4 Jun 2006, Daren wrote:

> Hi Trent,
> I tried the latest dll and it opens the port, receives 100-200 bytes and
> then stops receiving anything else..
>
> I'll keep playing with it.
>
> Daren

The difference may be that I'm talking to something at the exact same baud 
rate (loopback).

You may also try setting the baudrate to ~1933 and ~1973 to force the 
guesses one way or the other.  If you are on windows, we are not doing 
anything fancy in the end.  Thats the kernel guessing.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sun Jun  4 04:12:09 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sun, 4 Jun 2006 12:12:09 +0200
Subject: [Rxtx] Update of OSX installer, Readme, etc
Message-ID: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>

Good day,

after the latest changes a lot of OS X specific files should be  
updated. Especially the installer!

- The "MaxOSX" readme file on the root level is outdated (ie  
CodeWarrior information). Maybe we could even rename it to README.OSX  
to be in line with README.IPAQ, README.SCO (Trent do you mind copying/ 
renaming ,v files in the repository?).

- The lock files are no longer used and hence the user group magic  
and lock folder creation should be removed from the installer.

- MACOSX_IDE/ForPackageMaker/Resources/ReadMe.rtf and Welcome.rtf  
need to be updated.

- I suggest to replace the current installation instruction for OS X:  
Installation should occur into the application directory, not in the  
Java-VM directory. This simplifies things a lot, as the Mac Installer  
can be removed completely.

- The xcodeproject's build settings need to be updated to generate  
JAVA 1.1 format class files.


Dimitry: do you have time to tackle this? I could do it, but as this  
is "your baby" I thought you may prefer to do it yourself.

Regards,
Joachim



From dmarkman at mac.com  Sun Jun  4 11:27:53 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Sun, 4 Jun 2006 13:27:53 -0400
Subject: [Rxtx] Update of OSX installer, Readme, etc
In-Reply-To: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
References: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
Message-ID: <26E7A202-962B-4C19-93B6-29426C467249@mac.com>

Joachim,
unfortunately I don't have time right now to do that
so if you can do that, please do

it's not only my baby
it's yours too :-)

thanks


On Jun 4, 2006, at 6:12 AM, Joachim Buechse wrote:

> Good day,
>
> after the latest changes a lot of OS X specific files should be
> updated. Especially the installer!
>
> - The "MaxOSX" readme file on the root level is outdated (ie
> CodeWarrior information). Maybe we could even rename it to README.OSX
> to be in line with README.IPAQ, README.SCO (Trent do you mind copying/
> renaming ,v files in the repository?).
>
> - The lock files are no longer used and hence the user group magic
> and lock folder creation should be removed from the installer.
>
> - MACOSX_IDE/ForPackageMaker/Resources/ReadMe.rtf and Welcome.rtf
> need to be updated.
>
> - I suggest to replace the current installation instruction for OS X:
> Installation should occur into the application directory, not in the
> Java-VM directory. This simplifies things a lot, as the Mac Installer
> can be removed completely.
>
> - The xcodeproject's build settings need to be updated to generate
> JAVA 1.1 format class files.
>
>
> Dimitry: do you have time to tackle this? I could do it, but as this
> is "your baby" I thought you may prefer to do it yourself.
>
> Regards,
> Joachim
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman



From tjarvi at qbang.org  Sun Jun  4 13:54:02 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 4 Jun 2006 13:54:02 -0600 (MDT)
Subject: [Rxtx] Update of OSX installer, Readme, etc
In-Reply-To: <26E7A202-962B-4C19-93B6-29426C467249@mac.com>
References: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
	<26E7A202-962B-4C19-93B6-29426C467249@mac.com>
Message-ID: <Pine.LNX.4.61.0606041353040.22522@www>

On Sun, 4 Jun 2006, Dmitry Markman wrote:

> Joachim,
> unfortunately I don't have time right now to do that
> so if you can do that, please do
>
> it's not only my baby
> it's yours too :-)
>

I've given Joachim cvs access.  He has shown good work in bugzilla.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Mon Jun  5 10:08:32 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 5 Jun 2006 18:08:32 +0200
Subject: [Rxtx] Build process changes for Mac OS X
Message-ID: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>

Good day,

I have cleaned up some outdated Mac OSX specific build files in the  
repository.

There was not a lot left of the readme file "MacOSX" after cleaning  
it up, so I decided to rename it README.OSX to be in harmony with the  
other files in the directory (ie README.IPAQ, README.SCO, ...)

I added an (uncompressed) XCode 2.3 project file/structure  
with .cvsignore files that will ignore the user specific settings.  
This should work "out of the box" for OSX10.4. Users of 10.2/10.3 may  
have to switch the build settings.

[It's kind of tricky to choose "the right" setting. Afaik there is no  
way to compile a universal binary that will work on 10.3 or before.  
So it's either UniversalBinary OR Legacy. Maybe we should have  
different build targets for these different targets?? I would like to  
get some feedback from the Mac developers on this list regarding the  
subject].

Besides other things the OSX installer is no longer required. Since  
the next version (2.1.8) will no longer use lockfiles on OSX, the  
group/permission magic is no longer required and hence there remains  
basicly no work for the installer - other than copying 2 files to the  
VM extension directory. Then again, this is not the best way to  
install RXTX. So I removed the installer completely without modifying  
it, this should simplify a "resurrection" should it ever get necessary.

I had problems with the (compressed, ie sit.hqx) legacy project files  
on the latest installation of OSX (javac 1.5 creating non JDK1.1  
class files and some minor problems). To reduce potential confusion  
for newcomers I decided to remove them. This means that there is no  
longer a simple way to build RXTX for OSX 10.0 and 10.1 (I deeply  
apologize if anyone still relied on this ... well the files are in  
the Attiq).

Best regards,
Joachim


From joachim at buechse.de  Mon Jun  5 10:16:37 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 5 Jun 2006 18:16:37 +0200
Subject: [Rxtx] RXTX and lockfiles on OSX [it is fixed now]
Message-ID: <7D2C4418-9397-4B59-8091-9FDE4ED67836@buechse.de>

Quite a number of people contacted me in the last couple of weeks  
because of problems installing RXTX on OSX. I told you to wait for  
the "official" fix. Well, it has been fixed.

So if you were among the people waiting for the solution, you can now  
download the source rxtx-2.1-7r2.zip from the website. Once unpacked  
dont forget to use "cvs up" to update the files to the latest  
version. You can then open MACOSX_IDE/XCode/ 
LibSerialUniversal.xcodeproj with XCode 2.3 and build the libraries  
that no longer try to create lock files.

Regards,
Joachim


From brian at mbari.org  Mon Jun  5 10:52:43 2006
From: brian at mbari.org (Brian Schlining)
Date: Mon, 5 Jun 2006 09:52:43 -0700
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
Message-ID: <78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>

Hi Joachim,

> [It's kind of tricky to choose "the right" setting. Afaik there is no
> way to compile a universal binary that will work on 10.3 or before.
> So it's either UniversalBinary OR Legacy. Maybe we should have
> different build targets for these different targets?? I would like to
> get some feedback from the Mac developers on this list regarding the
> subject].

I imagine most developers will be compiling on 10.4 (It's the nature  
of the coder...gotta have the latest and greatest) and deploying to  
both 10.3 and 10.4; both of which will run Universal Binaries (see  
http://forums.macrumors.com/showthread.php?t=205348). So it sounds  
like you've covered the majority of users. Still, you know someone's  
going to pipe up about needing RXTX on 10.2 so it would be nice to  
have a target to make a PPC only build.

Just my 2 cents

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/1cac8c39/attachment-0009.html

From dmarkman at mac.com  Mon Jun  5 13:47:50 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Mon, 5 Jun 2006 15:47:50 -0400
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
Message-ID: <686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>

I don't think it will be a problem to run universal binary
on 10.2
however if binary has some calls that aren't implemented in 10.2
then you'll have a problem


On Jun 5, 2006, at 12:52 PM, Brian Schlining wrote:

> Hi Joachim,
>
>> [It's kind of tricky to choose "the right" setting. Afaik there is no
>> way to compile a universal binary that will work on 10.3 or before.
>> So it's either UniversalBinary OR Legacy. Maybe we should have
>> different build targets for these different targets?? I would like to
>> get some feedback from the Mac developers on this list regarding the
>> subject].
>
> I imagine most developers will be compiling on 10.4 (It's the  
> nature of the coder...gotta have the latest and greatest) and  
> deploying to both 10.3 and 10.4; both of which will run Universal  
> Binaries (see http://forums.macrumors.com/showthread.php?t=205348).  
> So it sounds like you've covered the majority of users. Still, you  
> know someone's going to pipe up about needing RXTX on 10.2 so it  
> would be nice to have a target to make a PPC only build.
>
> Just my 2 cents
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/9fafc878/attachment-0009.html

From brian at mbari.org  Mon Jun  5 14:52:41 2006
From: brian at mbari.org (Brian Schlining)
Date: Mon, 5 Jun 2006 13:52:41 -0700
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
Message-ID: <E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>

Hi Dmitry,

> I don't think it will be a problem to run universal binary
> on 10.2
> however if binary has some calls that aren't implemented in 10.2
> then you'll have a problem

You're right...I stand corrected.

Note however, to deploy a universal binary to 10.2 RXTX will need to  
use the 10.2 SDK to build the PPC side. (see http:// 
developer.apple.com/documentation/DeveloperTools/Conceptual/ 
cross_development/UniversalBinaries/chapter_4_section_1.html). I  
haven't been paying close attention to the new locking mechanism used  
by RXTX on the Mac...does 10.2 support it?

Joachim, which SDK will you be using by default for building the Mac  
PPC binaries?

>> Hi Joachim,
>>
>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>> is no
>>> way to compile a universal binary that will work on 10.3 or before.
>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>> different build targets for these different targets?? I would  
>>> like to
>>> get some feedback from the Mac developers on this list regarding the
>>> subject].
>>
>> I imagine most developers will be compiling on 10.4 (It's the  
>> nature of the coder...gotta have the latest and greatest) and  
>> deploying to both 10.3 and 10.4; both of which will run Universal  
>> Binaries (see http://forums.macrumors.com/showthread.php? 
>> t=205348). So it sounds like you've covered the majority of users.  
>> Still, you know someone's going to pipe up about needing RXTX on  
>> 10.2 so it would be nice to have a target to make a PPC only build.

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/153bf50e/attachment-0009.html

From dmarkman at mac.com  Mon Jun  5 19:02:04 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Mon, 5 Jun 2006 21:02:04 -0400
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
Message-ID: <7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>

if Joachim didn't change xcode project setting

/Developer/SDKs/MacOSX10.4u.sdk is used to build universal binary

so it's quite possible that it won't run properly on 10.2

so we have to change the building process, so ppc part will be built
with
/Developer/SDKs/MacOSX10.2.8.sdk

and finally to use lipo utility to build universal binaries

Joachim, did you use some specific locking API that wasn't implemented

in MacOSX10.2.8.sdk?

thanks


On Jun 5, 2006, at 4:52 PM, Brian Schlining wrote:

> Hi Dmitry,
>
>> I don't think it will be a problem to run universal binary
>> on 10.2
>> however if binary has some calls that aren't implemented in 10.2
>> then you'll have a problem
>
> You're right...I stand corrected.
>
> Note however, to deploy a universal binary to 10.2 RXTX will need  
> to use the 10.2 SDK to build the PPC side. (see http:// 
> developer.apple.com/documentation/DeveloperTools/Conceptual/ 
> cross_development/UniversalBinaries/chapter_4_section_1.html). I  
> haven't been paying close attention to the new locking mechanism  
> used by RXTX on the Mac...does 10.2 support it?
>
> Joachim, which SDK will you be using by default for building the  
> Mac PPC binaries?
>
>>> Hi Joachim,
>>>
>>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>>> is no
>>>> way to compile a universal binary that will work on 10.3 or before.
>>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>>> different build targets for these different targets?? I would  
>>>> like to
>>>> get some feedback from the Mac developers on this list regarding  
>>>> the
>>>> subject].
>>>
>>> I imagine most developers will be compiling on 10.4 (It's the  
>>> nature of the coder...gotta have the latest and greatest) and  
>>> deploying to both 10.3 and 10.4; both of which will run Universal  
>>> Binaries (see http://forums.macrumors.com/showthread.php? 
>>> t=205348). So it sounds like you've covered the majority of  
>>> users. Still, you know someone's going to pipe up about needing  
>>> RXTX on 10.2 so it would be nice to have a target to make a PPC  
>>> only build.
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/84790f80/attachment-0009.html

From joachim at buechse.de  Tue Jun  6 02:40:47 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 6 Jun 2006 10:40:47 +0200
Subject: [Rxtx] Building on OS X, Impl Changes
In-Reply-To: <7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
Message-ID: <CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>

Good day!

What's in the XCode project setting?
----------

The xcode project remained pretty much the same as before. I excluded  
the user specific files from CVS and changed some settings. I kept  
all the built targets (you shouldn't change what you don't understand;-)

Currently we the following build targets:
    RXTXComm (java files)
    librxtxParallel.jnilib (usefull on the Mac???)
    libI2C.jnilib (not yet working in RXTX)
    libRS485.jnilib (not yet working in RXTX)
    librxtxSerial.jnilib (1)
    librxtxSerial.jnilib Dynamic (2)
    rxtxSerial (3)
We also have the following build configurations for each target:
    Development
    Default
    Deployment

What was changed in the xcode project from previous versions:
- java.souce=1.3 and java.target=1.1 in RXTXComm settings
- removed copying of build products into installer directory
- removed "(Upgraded)" from build target names

What remains to be changed:
- choosing a "non-debug" Build-configuration as default
- potentially removing "Default"/"Development" Build-configurations
- reducing the number of build targets
- creating 10.2 compatible universal binaries

I suggest, that the build configurations should be reduced to 2  
(Debug/Deployment), possibly even 1 (Debug).
I have not yet found the deeper meaning of the build targets(1)(2) 
(3), it seems to me like they should be reduced into one "doing the  
right thing" or maybe into two "rxtxSerial.jnilib Legacy" (back to  
10.2, universal if possible) and "rxtxSerial.jnilib 10.4 
+" (universal, 10.4+).

Should the code work on 10.2?
----------

Absolutely. The code should work on NextStep, in fact on any BSD  
unix. I would go as far as saying, this code should work on any  
POSSIX based unix. All that was added is the call "ioctl(fd,  
TIOCEXCL)" to request excusivity of the port:

http://gemma.apple.com/documentation/DeviceDrivers/Conceptual/ 
WorkingWSerial/WWSerial_SerialDevs/chapter_2_section_8.html

It is not yet "the perfect solution". Normally an open /dev/tty  
(listen for incomming connection) should be "preemptable" by opening  
a /dev/cu (outgoing connection) for the same port. This is not yet  
implemented as it needs calls outside of POSSIX on OSX.

On "classic" systems (like NextStep) this worked based on the  
"carried detect line". open() on /dev/tty.xxx would block until the  
carrier detect signal was raised. As the device was not "opened"  
opening /dev/cu.xxx worked without a hitch. When they ported to the  
Mac this broke. On Macs the "carier detect" is usually not wired.  
Furthermore FAX modems did no longer raise the line. So the OSX  
implementor defined a new call, which is documented here:

http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00045.html

Best regards,
Joachim




On 06.06.2006, at 03:02, Dmitry Markman wrote:

> if Joachim didn't change xcode project setting
>
> /Developer/SDKs/MacOSX10.4u.sdk is used to build universal binary
>
> so it's quite possible that it won't run properly on 10.2
>
> so we have to change the building process, so ppc part will be built
> with
> /Developer/SDKs/MacOSX10.2.8.sdk
>
> and finally to use lipo utility to build universal binaries
>
> Joachim, did you use some specific locking API that wasn't implemented
>
> in MacOSX10.2.8.sdk?
>
> thanks
>
>
> On Jun 5, 2006, at 4:52 PM, Brian Schlining wrote:
>
>> Hi Dmitry,
>>
>>> I don't think it will be a problem to run universal binary
>>> on 10.2
>>> however if binary has some calls that aren't implemented in 10.2
>>> then you'll have a problem
>>
>> You're right...I stand corrected.
>>
>> Note however, to deploy a universal binary to 10.2 RXTX will need  
>> to use the 10.2 SDK to build the PPC side. (see http:// 
>> developer.apple.com/documentation/DeveloperTools/Conceptual/ 
>> cross_development/UniversalBinaries/chapter_4_section_1.html). I  
>> haven't been paying close attention to the new locking mechanism  
>> used by RXTX on the Mac...does 10.2 support it?
>>
>> Joachim, which SDK will you be using by default for building the  
>> Mac PPC binaries?
>>
>>>> Hi Joachim,
>>>>
>>>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>>>> is no
>>>>> way to compile a universal binary that will work on 10.3 or  
>>>>> before.
>>>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>>>> different build targets for these different targets?? I would  
>>>>> like to
>>>>> get some feedback from the Mac developers on this list  
>>>>> regarding the
>>>>> subject].
>>>>
>>>> I imagine most developers will be compiling on 10.4 (It's the  
>>>> nature of the coder...gotta have the latest and greatest) and  
>>>> deploying to both 10.3 and 10.4; both of which will run  
>>>> Universal Binaries (see http://forums.macrumors.com/ 
>>>> showthread.php?t=205348). So it sounds like you've covered the  
>>>> majority of users. Still, you know someone's going to pipe up  
>>>> about needing RXTX on 10.2 so it would be nice to have a target  
>>>> to make a PPC only build.
>>
>> Brian Schlining
>> Software Engineer
>> http://www.mbari.org
>>
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> Dmitry Markman
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Tue Jun  6 07:01:06 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 6 Jun 2006 15:01:06 +0200
Subject: [Rxtx] Serial port code for OS X, future steps
In-Reply-To: <CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
	<CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
Message-ID: <8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>

I posted the "wrong link". There is a correction here:

    http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00059.html

In fact, the 2.1.7 implementation of RXTX has quite some deficiencies  
on OSX. I have tried to supply some patches that don't interfere to  
much with the existing RXTX code base, but there are limits to what  
can be done with local patches.

There are some very intrusive changes that should be done. Ie proper  
mapping of /dev/tty <-> /dev/cu handling to correct behaviour of  
CommPortOwnershipListener (http://java.sun.com/products/javacomm/ 
reference/api/index.html). I dont think this can be done with  
patches. Hence I think, RXTX should be rewritten from scratch de- 
unifying the native code base (and implementing thread safe code on  
the Java side).


How "should" /dev/tty vs /dev/cu be implemented?

=====
The Unix contract is this: An open /dev/tty.xxx port (incomming)  
should be interrupted/auto-closed when opening /dev/cu.xxx (outgoing)  
[if /dev/tty.xxx is not currently handling a communication].  /dev/ 
cu.xxx and /dev/tty.xxx refer to the same device, so owning  
"exclusively" should block both. This should be respected across all  
applications native or Java.

This contract is realizable on OSX with the existing javax.comm  
interface while also respecting (to the biggest part) the contract  
defined by javax.comm.PortOwnershipListener.

The one point where the suggested implementation "breaks" the  
javax.comm contract, is by the fact that one can loose a /dev/tty  
port without calling close. However, the only option I see is to  
always open serial ports "non-exclusively" which would outrule Java  
as a platform for (dormant) applications waiting for incoming  
connections/faxes/etc. There could be a system property to choose the  
intended behavior.
=====

Here is how it could be done on OSX:

Calling port=ComportIdentifier.open("/dev/cu.xxx") opens and owns the  
port exclusively until port.close() is called.
- Java applications listening with a PortOwnershipListener should get  
a PORT_OWNED event reasonably soon.
- Any further attempt by a Java or native application to open "/dev/ 
cu.xxx" or "/dev/tty.xxx" fails.
- /dev/cu.xxx is for "outgoing" connections, so receiving  
PORT_OWNERSHIP_REQUESTED makes little to no sense. With native  
applications it can not be implemented. For Java applications it  
could be implemented (by a hidden communication channel). I think  
it's not worth bothering. If anyone is willing to give up a port to  
others he should use /dev/tty.xxx instead of /dev/cu.xxx.

Registering a PortOwnershipListener on "/dev/cu.xxx" without opening  
it, uses /dev/tty.xxx (native open()) non-exclusively and polls its  
state. PORT_OWNED and PORT_UNOWNED can be produced.

Calling port=ComportIdentifier.open("/dev/tty.xxx") should open the  
port non-exclusively.
- Adding a SerialPortEventListener and reading from the port could be  
allowed while keeping it non-exclusive.
- When port.getOutputStream() is called, the state should be changed  
to an "exclusive" ownership. This may be configurable via a system  
property.
- To return to the non-exclusive state the port must be closed and  
reopened.
- While non-exclusively opened, opening the corresponding /dev/cu.xxx  
produces a PORT_OWNERSHIP_REQUESTED event. Which should be responded  
by closing the port from within the callback (as described in  
java.comm.PortOwnershipListener). If there is a pending read, it will  
return after the listener finishes (with -1 or "0 bytes read").
- Calling write() on the /dev/tty.xxx after somebody opened /dev/ 
cu.xxx will fail with a descriptive IOException.
- Calling read() on the /dev/tty.xxx after somebody opened /dev/ 
cu.xxx will fail with a descriptive IOException (or potentially  
block, see side notes below).

CommPortIdentifier.getCurrentOwner() can be implemented by an  
external call to lsof.

CommPortIdentifier.isCurrentlyOwned() can be implemented by trying an  
open on the /dev/tty.
- It returns true if the port is currently held "exclusively".
- Whether it should also return true on /dev/tty if /dev/tty is  
already opened non-exclusively might be a system property option. In  
general, having several applications waiting for incoming connections  
on the same port will require an application level "arbitration"  
protocol...

[[side note1: One interesting question is, what happens if the  
process holding /dev/tty non-exclusively ignores  
PORT_OWNERSHIP_REQUESTED. Ie after "loosing" a non-exclusively opened  
"dev/tty.xxx" port to another process. One possible implementation  
is, that the port is "regained" when the other process gives up the  
port. This would mean that in the meanwhile read() returns no data,  
and any changes to the configuration of the port are stored but not  
forwarded. I guess, the safe (and simple) way to do this is to make  
the close() mandatory (ie setting the port into an "awaiting_close"  
state which produces IOExceptions to any other call than close). ]]

[[side note2:  Another interesting question is, what should happen if  
several applications open the same /dev/tty.xxx port "non- 
exclusively" and start to change the settings of the device.]]

Regards,
Joachim



On 06.06.2006, at 10:40, Joachim Buechse wrote:

> Should the code work on 10.2?
> ----------
>
> Absolutely. The code should work on NextStep, in fact on any BSD
> unix. I would go as far as saying, this code should work on any
> POSSIX based unix. All that was added is the call "ioctl(fd,
> TIOCEXCL)" to request excusivity of the port:
>
> http://gemma.apple.com/documentation/DeviceDrivers/Conceptual/
> WorkingWSerial/WWSerial_SerialDevs/chapter_2_section_8.html
>
> It is not yet "the perfect solution". Normally an open /dev/tty
> (listen for incomming connection) should be "preemptable" by opening
> a /dev/cu (outgoing connection) for the same port. This is not yet
> implemented as it needs calls outside of POSSIX on OSX.
>
> On "classic" systems (like NextStep) this worked based on the
> "carried detect line". open() on /dev/tty.xxx would block until the
> carrier detect signal was raised. As the device was not "opened"
> opening /dev/cu.xxx worked without a hitch. When they ported to the
> Mac this broke. On Macs the "carier detect" is usually not wired.
> Furthermore FAX modems did no longer raise the line. So the OSX
> implementor defined a new call, which is documented here:
>
> http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00045.html
>
> Best regards,
> Joachim



From sds at dcs.gla.ac.uk  Tue Jun  6 11:22:45 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Tue, 06 Jun 2006 18:22:45 +0100
Subject: [Rxtx] Correct compile flag for HP iPAQ hx4700 running Familiar
	Linux?
Message-ID: <1149614565.19496.10.camel@addu>

Hi,

I'd like to use RXTX 2.1 on my HP iPAQ hx4700. The iPAQ is running
Familiar Linux 0.8.2 (as I recall), with Blackdown Java 1.3.1.

I can compile and run a test program which uses RXTX on my i686 machine,
and it works fine. But I can't seem to get things working quite right on
my PDA.

I compile the code on the laptop with the following commands:
	./configure --host=arm-gnu-linux && make
... as suggested in a post to this list, albeit some time ago. This
compiles, I transfer the files, set up LD_LIBRARY_PATH and CLASSPATH
variables, and get the following error on the PDA:

sds at ipaq-pxa-2:~# java Test
java.lang.UnsatisfiedLinkError: /usr/local/lib/ext/librxtxSerial.so: /usr/local/lib/ext/librxtxSerial.so: cannot open shared object file: No such file or directory thrown while loading gnu.io.RXTXCommDriver
Exception in thread "main"
java.lang.UnsatisfiedLinkError: /usr/local/lib/ext/librxtxSerial.so: /usr/local/lib/ext/librxtxSerial.so: cannot open shared object file: No such file or directory
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1382)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1290)
        at java.lang.Runtime.loadLibrary0(Runtime.java:749)
        at java.lang.System.loadLibrary(System.java:820)
        at
gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:83)
        at Test.<init>(Test.java:9)
        at Test.main(Test.java:32)
sds at ipaq-pxa-2:~# 

Note that I'm copying the files to /usr/local/lib/ext/ along with the
RXTXcomm.jar file, purely to keep things separate from the rest of the
system while testing. The location of the .so files doesn't seem to have
any bearing on whether "java Test" will succeed or not. The contents of
this directory are:

sds at ipaq-pxa-2:~$ ls /usr/local/lib/ext/
RXTXcomm.jar              librxtxParallel-2.1-7.so  librxtxRS485.so
librxtxSerial-2.1-7.so
librxtxI2C-2.1-7.so       librxtxParallel.so        librxtxRaw-2.1-7.so
librxtxSerial.so
librxtxI2C.so             librxtxRS485-2.1-7.so     librxtxRaw.so
sds at ipaq-pxa-2:~$

Test.java fails on the first real line of code I'm using to test that
things are working, prior to real development, and was carefully pinched
from the web:
Enumeration portIdentifiers = CommPortIdentifier.getPortIdentifiers();


I assume that I've gotten my --host flag wrong way back up there at
the ./configure step. But if that's the case, what should I set it to?
Or am I missing something more obvious?


Cheers,
Stephen Strowes,
University of Glasgow.




From tjarvi at qbang.org  Tue Jun  6 13:39:41 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 6 Jun 2006 13:39:41 -0600 (MDT)
Subject: [Rxtx] Serial port code for OS X, future steps
In-Reply-To: <8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
	<CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
	<8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>
Message-ID: <Pine.LNX.4.61.0606061315070.9856@www>


>>
There are some very intrusive changes that should be done. Ie proper
mapping of /dev/tty <-> /dev/cu handling to correct behaviour of
CommPortOwnershipListener (http://java.sun.com/products/javacomm/
reference/api/index.html). I dont think this can be done with
patches. Hence I think, RXTX should be rewritten from scratch de-
unifying the native code base (and implementing thread safe code on
the Java side).
<<

This appears to be a very small amount of functionality for a total 
rewrite.  The port ownership only needs maybe 3 native calls if it is done 
with native calls at all.

Those features which are not part of the Unix standard(s) can be special 
cased.  I'm not sure /dev/cu is standard.  We can look.  I know linux 
deprecated /dev/cua years ago.

Thread safe Java code is not a platform specific issue.

--
Trent Jarvi
tjarvi at qbang.org


From sds at dcs.gla.ac.uk  Wed Jun  7 12:36:43 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Wed, 07 Jun 2006 19:36:43 +0100
Subject: [Rxtx] Expected RXTX behaviour?
In-Reply-To: <1149703900.30891.19.camel@addu>
References: <1149703900.30891.19.camel@addu>
Message-ID: <1149705403.30891.25.camel@addu>

Apologies, caught the problem. Had to append '\r' to the end of the AT
string. A non obvious but stupid mistake... :-)

Final quick question though: How might I stop the echoing of
outputStream data back into the inputStream? I still see the ATI
commands on the inputStream, along with the output from the device.


Cheers,
S.



On Wed, 2006-06-07 at 19:11 +0100, Stephen Strowes wrote:
> Hi,
> 
> I managed to get RXTX to compile for my iPAQ following my previous post
> to this list. Quick query though:
> 
> I want to be able to issue AT commands to a device, and interpret the
> responses. For this, I assume I do the following, in psuedo-form:
> 
> 	CommPortIdentifier.getPortIdentifiers();
> 	// find the correct device id
> 	serialPort= (SerialPort)portID.open("Test");
> 	// Set parameters and flow control
> 	outputStream= serialPort.getOutputStream();
> 	inputStream=  serialPort.getInputStream();
> 
> ... following this, I spawn a thread to respond to DATA_AVAILABLE events
> on serialPort with inputStream, and occasionally write and flush an
> "ATI" onto the outputStream. Nothing complex, I just want to see it
> work.
> 
> I would have expected inputStream to give the same information back from
> an "ATI" command as minicom provides, but instead inputStream only sees
> the "ATI" I put onto the outputStream.
> 
> Have I missed something?
> 
> 
> Cheers,
> S.
> 



From sds at dcs.gla.ac.uk  Wed Jun  7 12:11:40 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Wed, 07 Jun 2006 19:11:40 +0100
Subject: [Rxtx] Expected RXTX behaviour?
Message-ID: <1149703900.30891.19.camel@addu>

Hi,

I managed to get RXTX to compile for my iPAQ following my previous post
to this list. Quick query though:

I want to be able to issue AT commands to a device, and interpret the
responses. For this, I assume I do the following, in psuedo-form:

	CommPortIdentifier.getPortIdentifiers();
	// find the correct device id
	serialPort= (SerialPort)portID.open("Test");
	// Set parameters and flow control
	outputStream= serialPort.getOutputStream();
	inputStream=  serialPort.getInputStream();

... following this, I spawn a thread to respond to DATA_AVAILABLE events
on serialPort with inputStream, and occasionally write and flush an
"ATI" onto the outputStream. Nothing complex, I just want to see it
work.

I would have expected inputStream to give the same information back from
an "ATI" command as minicom provides, but instead inputStream only sees
the "ATI" I put onto the outputStream.

Have I missed something?


Cheers,
S.




From joachim at buechse.de  Wed Jun  7 09:02:13 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 7 Jun 2006 17:02:13 +0200
Subject: [Rxtx] Update of build process for OSX (XCode project)
Message-ID: <62EC47B1-46BD-4ECA-B9EC-C4061D147CDA@buechse.de>

With the help of Dmitry Markman and Brian Schilling I have updated  
(and largely simplifed) the XCode project file for Mac OS X.

Changes:
- compiles a universal binary library with intel=OSX10.4+, ppc=OSX10.2 
+ support
- compiles the Java sources into a JRE1.1 compatible, compressed jar.

Please test on your configuration, especially if you have computers  
running 10.2/10.3 or intel.

Best regards,
Joachim


From joachim at buechse.de  Wed Jun  7 14:36:37 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 7 Jun 2006 22:36:37 +0200
Subject: [Rxtx] Expected RXTX behaviour?
In-Reply-To: <1149705403.30891.25.camel@addu>
References: <1149703900.30891.19.camel@addu> <1149705403.30891.25.camel@addu>
Message-ID: <D3AD6EAF-27BB-455E-9697-86C1121920C3@buechse.de>

Echoing is a feature of the modem. Try ATE0 which works with most  
"rockwell" compatible modems.

Regards,
Joachim


On 07.06.2006, at 20:36, Stephen Strowes wrote:

> Apologies, caught the problem. Had to append '\r' to the end of the AT
> string. A non obvious but stupid mistake... :-)
>
> Final quick question though: How might I stop the echoing of
> outputStream data back into the inputStream? I still see the ATI
> commands on the inputStream, along with the output from the device.
>
>
> Cheers,
> S.
>
>
>
> On Wed, 2006-06-07 at 19:11 +0100, Stephen Strowes wrote:
>> Hi,
>>
>> I managed to get RXTX to compile for my iPAQ following my previous  
>> post
>> to this list. Quick query though:
>>
>> I want to be able to issue AT commands to a device, and interpret the
>> responses. For this, I assume I do the following, in psuedo-form:
>>
>> 	CommPortIdentifier.getPortIdentifiers();
>> 	// find the correct device id
>> 	serialPort= (SerialPort)portID.open("Test");
>> 	// Set parameters and flow control
>> 	outputStream= serialPort.getOutputStream();
>> 	inputStream=  serialPort.getInputStream();
>>
>> ... following this, I spawn a thread to respond to DATA_AVAILABLE  
>> events
>> on serialPort with inputStream, and occasionally write and flush an
>> "ATI" onto the outputStream. Nothing complex, I just want to see it
>> work.
>>
>> I would have expected inputStream to give the same information  
>> back from
>> an "ATI" command as minicom provides, but instead inputStream only  
>> sees
>> the "ATI" I put onto the outputStream.
>>
>> Have I missed something?
>>
>>
>> Cheers,
>> S.
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From g_petrini at yahoo.it  Thu Jun  8 01:41:58 2006
From: g_petrini at yahoo.it (Giacomo Petrini)
Date: Thu, 8 Jun 2006 09:41:58 +0200 (CEST)
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from FieldTalk
Message-ID: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>

Hi,
I'm evaluating the library for the modbus protocol
from FieldTalk
(http://www.modbusdriver.com/fieldtalk/.
I'm using J2SE 5.0 and RXTX 2.1 on win XP.
The problem is that the modbus lib has a method (the
openProtocol method, but maybe there are others) tha
throws the
javax.comm.UnsupportedCommOperationException.
Now, in RXTX 2.1 the namespace has changed in gnu.io,
so the modbus library doesn't work anymore (it look
for things in javax.comm). I've already sent an email
to fieldtalk to see if they are aware of the problem.
The solution should be to use JavaComm + RXTX 2.0. But
I've read somewhere that JavaComm 2.0 does not work
with Java 5.0 and JavaComm 3.0 does not work with RXTX
2.0 so I don't know what to do.

Any ideas?

Thanks Jack

PS: can you make a CC to my personal email
(g_petrini at yahoo.it) too please?

Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 


From rxtx at tapastda.co.uk  Thu Jun  8 02:27:57 2006
From: rxtx at tapastda.co.uk (rxtx@tapastda.co.uk)
Date: Thu, 08 Jun 2006 09:27:57 +0100
Subject: [Rxtx] Win XP and Infrared based serial port
Message-ID: <4487DF8D.5050807@tapastda.co.uk>

I'm attempting to use RXTX 2.1.7 on Win XP with J2SE 5.0 to communicate with a
GSM mobile using a COM port. A peculiarity that I've seen is that whilst I can
communicate successfully with a mobile which uses an infrared based COM port
using the SUN provided javax.comm (v2.0) I cannot use RXTX because it fails to
read anything from the port (i.e. read timeout always occurs returning zero bytes).

I assumed that this could be the result of flow control problems and thus I've
tried setting either software or hardware based flow control on the port however
this has no affect.

Can you suggest any other port configuration changes which might be required to
make such a port work with RXTX.

Thanks
Stu
-- 
Stuart
Tapastda Limited


From tjarvi at qbang.org  Thu Jun  8 05:17:12 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 8 Jun 2006 05:17:12 -0600 (MDT)
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from
	FieldTalk
In-Reply-To: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
References: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606080504480.9856@www>

On Thu, 8 Jun 2006, Giacomo Petrini wrote:

> Hi,
> I'm evaluating the library for the modbus protocol
> from FieldTalk
> (http://www.modbusdriver.com/fieldtalk/.
> I'm using J2SE 5.0 and RXTX 2.1 on win XP.
> The problem is that the modbus lib has a method (the
> openProtocol method, but maybe there are others) tha
> throws the
> javax.comm.UnsupportedCommOperationException.
> Now, in RXTX 2.1 the namespace has changed in gnu.io,
> so the modbus library doesn't work anymore (it look
> for things in javax.comm). I've already sent an email
> to fieldtalk to see if they are aware of the problem.
> The solution should be to use JavaComm + RXTX 2.0. But
> I've read somewhere that JavaComm 2.0 does not work
> with Java 5.0 and JavaComm 3.0 does not work with RXTX
> 2.0 so I don't know what to do.
>
> Any ideas?
>
> Thanks Jack
>


Hi Jack

There are plans for Sun to rerelease JavaComm 2.0 mentioned in the rxtx 
mail-list archives.  When this happens rxtx will release a current rxtx 
2.0 library that works with it.

There are no dates promised by either side but rxtx will do it as soon as 
possible after Sun's rerelease.  Just to give you a feel for the time 
frame, this started last year and no significant progress has been made. 
There have been friendly talks pointing towards solutions (rerelease 2.0) 
but that does not get your application working today.  rxtx is preparing 
for its second release in gnu.io since then.

--
Trent Jarvi
tjarvi at qbang.org




From jredman at ergotech.com  Thu Jun  8 08:47:23 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 08 Jun 2006 08:47:23 -0600
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from
	FieldTalk
In-Reply-To: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
References: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
Message-ID: <4488387B.6040903@ergotech.com>

You could always try a different library, eg.

http://sourceforge.net/projects/jamod

I've only used the slave side since we have our own implementation of 
Modbus Client (and a host of other PLC protocols).  However the client 
side seems to be pretty well supported and fairly widely used.  Since 
the source is there you could change to gnu.io.

I think I should take more of an interest in this issue.  We generally 
run 1.4.2 on Linux, but also have some J9 and old platforms that we 
support that are basically Personal Java.  5.0 on Linux has some 
horrible MDI bugs, to the point of being unusable.   Sounds as though we 
are going to have code compatibility problems across these platforms.

Jim


Giacomo Petrini wrote:
> Hi,
> I'm evaluating the library for the modbus protocol
> from FieldTalk
> (http://www.modbusdriver.com/fieldtalk/.
> I'm using J2SE 5.0 and RXTX 2.1 on win XP.
> The problem is that the modbus lib has a method (the
> openProtocol method, but maybe there are others) tha
> throws the
> javax.comm.UnsupportedCommOperationException.
> Now, in RXTX 2.1 the namespace has changed in gnu.io,
> so the modbus library doesn't work anymore (it look
> for things in javax.comm). I've already sent an email
> to fieldtalk to see if they are aware of the problem.
> The solution should be to use JavaComm + RXTX 2.0. But
> I've read somewhere that JavaComm 2.0 does not work
> with Java 5.0 and JavaComm 3.0 does not work with RXTX
> 2.0 so I don't know what to do.
> 
> Any ideas?
> 
> Thanks Jack
> 
> PS: can you make a CC to my personal email
> (g_petrini at yahoo.it) too please?
> 
> Chiacchiera con i tuoi amici in tempo reale! 
>  http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  8 18:17:23 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 08 Jun 2006 17:17:23 -0700
Subject: [Rxtx] rxtx access is denied error
Message-ID: <4488BE13.2050706@dupreeinc.com>

Hello,

I have been trying to replace the commapi from sun with rxtx for a 
project that communicates with a serial port that is a USB-Serial 
interface.  To be exact, I am using the FTDI VCP driver with one of 
their modules connected to a windows XP system.

I have the RXTX package working pretty well as long as nothing goes wrong.

If a user disconnects the USB port while my java application is running, 
my application goes into an endless loop with lots of messages in the  
errors stream  like the ones below:

    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(481):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.


I believe when this happens the COM port completely disappears and the 
rxtx driver has a heart attack.  Obviously, the user should not do this, 
but my application needs to ideally, correct the situation or as a worse 
case, terminate with a little dignity.  Currently, I have not figured 
out how to catch this error.

The closest I have come is to trap an exception to my input stream read  
that says "No error in readByte"  This error appears to be outside of 
the endless loop of the errors listed above.

Does anybody have an idea of how to identify and trap this error?  Any 
suggestions on how to gracefully recover from it would be greatly 
appreciated!

Thank you for your time,

Doug Thistlethwaite




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060608/9cfca302/attachment-0009.html

From tjarvi at qbang.org  Thu Jun  8 20:54:17 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 8 Jun 2006 20:54:17 -0600 (MDT)
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <4488BE13.2050706@dupreeinc.com>
References: <4488BE13.2050706@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606082022580.1323@www>

On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I have been trying to replace the commapi from sun with rxtx for a project 
> that communicates with a serial port that is a USB-Serial interface.  To be 
> exact, I am using the FTDI VCP driver with one of their modules connected to 
> a windows XP system.
>
> I have the RXTX package working pretty well as long as nothing goes wrong.
>
> If a user disconnects the USB port while my java application is running, my 
> application goes into an endless loop with lots of messages in the  errors 
> stream  like the ones below:
>
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(481):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>
>
> I believe when this happens the COM port completely disappears and the rxtx 
> driver has a heart attack.  Obviously, the user should not do this, but my 
> application needs to ideally, correct the situation or as a worse case, 
> terminate with a little dignity.  Currently, I have not figured out how to 
> catch this error.
>
> The closest I have come is to trap an exception to my input stream read  that 
> says "No error in readByte"  This error appears to be outside of the endless 
> loop of the errors listed above.
>
> Does anybody have an idea of how to identify and trap this error?  Any 
> suggestions on how to gracefully recover from it would be greatly 
> appreciated!
>

Hi Doug

Sadly I don't have a quick solution for you.

Termios has no knowlage about the JVM so it wont be throwing exceptions 
you can catch.

We can return error and set the error number to something reasonable that 
results in an exception.  The No Error message simply means we did not set 
an error number in termios.c.  Those are the line numbers in the code you 
see.  SerialImp.c realizes it errored but does not know much more yet. 
Everything touching the file descriptor is going to error after the port 
is gone presumably.

We don't currently have a plan in place for vanishing (or appearing) com 
ports.

Another example of what we need to think about is what happens if you 
start your application and then plug in the dongle?  Or what if you unplug 
and then plug it in again?

So in each of these three cases, what would the behavior of the (yet to 
be) correct implementation do?

How will the enumerated ports be handled during these changes?

There can also be hints from the OS that could be taken into 
consideration.

We can probably get some exceptions thrown that make sense and null the 
file descriptor when it happens to prevent io attempts.  That would be a 
crude way to let applications know something strange has happened.

Is anyone else tinkering with this problem?

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  9 01:31:29 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 9 Jun 2006 09:31:29 +0200
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <Pine.LNX.4.61.0606082022580.1323@www>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
Message-ID: <AC6EDDDD-0A64-401F-B16B-E484788CDF4A@buechse.de>

Hello Trent,

I am not tinkering with this on the Source Level - but I think it  
should work pretty much the same way as it currently does in OSX.  
When the port goes away you get an IOException thrown for any read/ 
write. It will no longer be in the list of ports from  
CommPortIdentifier.getPortIdentifiers(). When a port (re-)appears it  
is added to the list. It's up to the application to re-check the list  
from time to time.

On Windows you can't do much better then that, because the ports  
don't have useful names. Which USB "virtual com port" is on which  
COMx depends on the order the devices were added. So reconnecting to  
the same device may mean connecting to another port.

Regarding the exception thrown: it would be nice to use an  
IOException subclass but the Exception message should definetly be  
informative also as most applications may want to keep compatibility  
with javax.comm.

Regards,
Joachim


On 09.06.2006, at 04:54, Trent Jarvi wrote:

> On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:
>
>> Hello,
>>
>> I have been trying to replace the commapi from sun with rxtx for a  
>> project
>> that communicates with a serial port that is a USB-Serial  
>> interface.  To be
>> exact, I am using the FTDI VCP driver with one of their modules  
>> connected to
>> a windows XP system.
>>
>> I have the RXTX package working pretty well as long as nothing  
>> goes wrong.
>>
>> If a user disconnects the USB port while my java application is  
>> running, my
>> application goes into an endless loop with lots of messages in  
>> the  errors
>> stream  like the ones below:
>>
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (481):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>
>>
>> I believe when this happens the COM port completely disappears and  
>> the rxtx
>> driver has a heart attack.  Obviously, the user should not do  
>> this, but my
>> application needs to ideally, correct the situation or as a worse  
>> case,
>> terminate with a little dignity.  Currently, I have not figured  
>> out how to
>> catch this error.
>>
>> The closest I have come is to trap an exception to my input stream  
>> read  that
>> says "No error in readByte"  This error appears to be outside of  
>> the endless
>> loop of the errors listed above.
>>
>> Does anybody have an idea of how to identify and trap this error?   
>> Any
>> suggestions on how to gracefully recover from it would be greatly
>> appreciated!
>>
>
> Hi Doug
>
> Sadly I don't have a quick solution for you.
>
> Termios has no knowlage about the JVM so it wont be throwing  
> exceptions
> you can catch.
>
> We can return error and set the error number to something  
> reasonable that
> results in an exception.  The No Error message simply means we did  
> not set
> an error number in termios.c.  Those are the line numbers in the  
> code you
> see.  SerialImp.c realizes it errored but does not know much more yet.
> Everything touching the file descriptor is going to error after the  
> port
> is gone presumably.
>
> We don't currently have a plan in place for vanishing (or  
> appearing) com
> ports.
>
> Another example of what we need to think about is what happens if you
> start your application and then plug in the dongle?  Or what if you  
> unplug
> and then plug it in again?
>
> So in each of these three cases, what would the behavior of the  
> (yet to
> be) correct implementation do?
>
> How will the enumerated ports be handled during these changes?
>
> There can also be hints from the OS that could be taken into
> consideration.
>
> We can probably get some exceptions thrown that make sense and null  
> the
> file descriptor when it happens to prevent io attempts.  That would  
> be a
> crude way to let applications know something strange has happened.
>
> Is anyone else tinkering with this problem?
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From doug at dupreeinc.com  Fri Jun  9 13:09:58 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 09 Jun 2006 12:09:58 -0700
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <Pine.LNX.4.61.0606082022580.1323@www>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
Message-ID: <4489C786.9050504@dupreeinc.com>


Ideally, it would be nice if it would throw an exception and terminate 
the loop.  I am still trying to figure out how to detect the condition 
and recover form it in some form...  I am getting the "No error in 
readByte" exception in my serialEvent() method after an input stream 
read.  It appears to me that the only graceful recovery is to close the 
port and then reopen it when it becomes available.  I can pass the event 
up to the update method in my main frame, but I still can't close the 
port from within that thread.  Any suggestions on how to pass this event 
to a location where the port can be safely closed?

Re: Slow startup in windows XP
I have been looking into this a little closer and have found out the 
following:
System Windows XP Pro 3GHz dual core with 1GB RAM and NO parallel port.
Starting the SerialDemo included with the commapi using the rxtx instead 
of javax.comm takes 60 seconds.
Starting the SerialDemo using rxrx with the rxtxParallel.dll file 
removed takes about 20 seconds.
Modify initialize in RXRXCommDriver.java to not test the parallel ports 
takes less than 1 second.

It would be nice if the initialize routine could detect the presence of 
rxtxParallel.dll file and just skip the whole process if not present.  
Is there an easy way to check for the presence of this file without 
running the parallel port test?

Doug


 

Trent Jarvi wrote:

>On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:
>...
>  
>
>
>Hi Doug
>
>Sadly I don't have a quick solution for you.
>
>Termios has no knowlage about the JVM so it wont be throwing exceptions 
>you can catch.
>
>We can return error and set the error number to something reasonable that 
>results in an exception.  The No Error message simply means we did not set 
>an error number in termios.c.  Those are the line numbers in the code you 
>see.  SerialImp.c realizes it errored but does not know much more yet. 
>Everything touching the file descriptor is going to error after the port 
>is gone presumably.
>
>We don't currently have a plan in place for vanishing (or appearing) com 
>ports.
>
>Another example of what we need to think about is what happens if you 
>start your application and then plug in the dongle?  Or what if you unplug 
>and then plug it in again?
>
>So in each of these three cases, what would the behavior of the (yet to 
>be) correct implementation do?
>
>How will the enumerated ports be handled during these changes?
>
>There can also be hints from the OS that could be taken into 
>consideration.
>
>We can probably get some exceptions thrown that make sense and null the 
>file descriptor when it happens to prevent io attempts.  That would be a 
>crude way to let applications know something strange has happened.
>
>Is anyone else tinkering with this problem?
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060609/911ed787/attachment-0009.html

From Ugo.Landini at Sun.COM  Fri Jun  2 14:23:47 2006
From: Ugo.Landini at Sun.COM (Ugo Landini)
Date: Fri, 02 Jun 2006 22:23:47 +0200
Subject: [Rxtx] OSX 10.4.7 and usb
Message-ID: <44809E53.2070905@sun.com>

Hi, I have installed the library and the native libraries on OSX 10.4.7. 
Then I have run this simple code:

...
while (portList.hasMoreElements()) {
             portId = (CommPortIdentifier) portList.nextElement();
             System.out.println("-> " + portId.getName() + " Port Type:" 
+ portId.getPortType());
...

and the output is:

Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7

Ports found:
-> /dev/tty.Bluetooth-PDA-Sync Port Type:1
-> /dev/cu.Bluetooth-PDA-Sync Port Type:1
-> /dev/tty.Bluetooth-Modem Port Type:1
-> /dev/cu.Bluetooth-Modem Port Type:1

I can't see any USB ports... with javax.comm on linux I could see the 
/dev/ttyUSB stuff, but that's not the case with OSX. Any idea?

tia

uL


From tod at todbot.com  Sun Jun 11 12:04:37 2006
From: tod at todbot.com (Tod E. Kurt)
Date: Sun, 11 Jun 2006 11:04:37 -0700
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <44809E53.2070905@sun.com>
References: <44809E53.2070905@sun.com>
Message-ID: <E2EB14A1-20A7-4611-8F1A-E3D2ABE41F48@todbot.com>

A dumb question, but: do you have the USB serial adapters plugged  
in?  They only show up in /dev when plugged in.  Also, you can verify  
they exist independent of RXTX by doing something like "ls -l /dev/ 
cu.*".

On Jun 2, 2006, at 1:23 PM, Ugo Landini wrote:

> Hi, I have installed the library and the native libraries on OSX  
> 10.4.7.
> Then I have run this simple code:
>
> ...
> while (portList.hasMoreElements()) {
>              portId = (CommPortIdentifier) portList.nextElement();
>              System.out.println("-> " + portId.getName() + " Port  
> Type:"
> + portId.getPortType());
> ...
>
> and the output is:
>
> Experimental:  JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
>
> Ports found:
> -> /dev/tty.Bluetooth-PDA-Sync Port Type:1
> -> /dev/cu.Bluetooth-PDA-Sync Port Type:1
> -> /dev/tty.Bluetooth-Modem Port Type:1
> -> /dev/cu.Bluetooth-Modem Port Type:1
>
> I can't see any USB ports... with javax.comm on linux I could see the
> /dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>
> tia
>
> uL
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>



From lyon at docjava.com  Sun Jun 11 12:14:50 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Sun, 11 Jun 2006 14:14:50 -0400
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <44809E53.2070905@sun.com>
References: <44809E53.2070905@sun.com>
Message-ID: <p06020444c0b20de7d248@[192.168.1.152]>

>Hi Ugo,

Do you have any USB serial ports (like the keyspan 19-HS) plugged
into the mac?
Thanks!
  - DL


>Hi, I have installed the library and the native libraries on OSX 10.4.7.
>Then I have run this simple code:
>
>...
>while (portList.hasMoreElements()) {
>              portId = (CommPortIdentifier) portList.nextElement();
>              System.out.println("-> " + portId.getName() + " Port Type:"
>+ portId.getPortType());
>...
>
>and the output is:
>
>Experimental:  JNI_OnLoad called.
>Stable Library
>=========================================
>Native lib Version = RXTX-2.1-7
>Java lib Version   = RXTX-2.1-7
>
>Ports found:
>-> /dev/tty.Bluetooth-PDA-Sync Port Type:1
>-> /dev/cu.Bluetooth-PDA-Sync Port Type:1
>-> /dev/tty.Bluetooth-Modem Port Type:1
>-> /dev/cu.Bluetooth-Modem Port Type:1
>
>I can't see any USB ports... with javax.comm on linux I could see the
>/dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>
>tia
>
>uL
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx



From dmarkman at mac.com  Sun Jun 11 14:30:27 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Sun, 11 Jun 2006 16:30:27 -0400
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <p06020444c0b20de7d248@[192.168.1.152]>
References: <44809E53.2070905@sun.com> <p06020444c0b20de7d248@[192.168.1.152]>
Message-ID: <B9C1606B-4339-4564-A175-FE83DFFA7D76@mac.com>

afaik
10.4.7 wasn't released yet
it will soon, no doubts


On Jun 11, 2006, at 2:14 PM, Dr. Douglas Lyon wrote:

>> Hi Ugo,
>
> Do you have any USB serial ports (like the keyspan 19-HS) plugged
> into the mac?
> Thanks!
>   - DL
>
>
>> Hi, I have installed the library and the native libraries on OSX  
>> 10.4.7.
>> Then I have run this simple code:
>>
>> ...
>> while (portList.hasMoreElements()) {
>>              portId = (CommPortIdentifier) portList.nextElement();
>>              System.out.println("-> " + portId.getName() + " Port  
>> Type:"
>> + portId.getPortType());
>> ...
>>
>> and the output is:
>>
>> Experimental:  JNI_OnLoad called.
>> Stable Library
>> =========================================
>> Native lib Version = RXTX-2.1-7
>> Java lib Version   = RXTX-2.1-7
>>
>> Ports found:
>> -> /dev/tty.Bluetooth-PDA-Sync Port Type:1
>> -> /dev/cu.Bluetooth-PDA-Sync Port Type:1
>> -> /dev/tty.Bluetooth-Modem Port Type:1
>> -> /dev/cu.Bluetooth-Modem Port Type:1
>>
>> I can't see any USB ports... with javax.comm on linux I could see the
>> /dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>>
>> tia
>>
>> uL
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman



From tjarvi at qbang.org  Sun Jun 11 18:52:59 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 11 Jun 2006 18:52:59 -0600 (MDT)
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <4489C786.9050504@dupreeinc.com>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
	<4489C786.9050504@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606111845430.7274@www>

On Fri, 9 Jun 2006, Doug Thistlethwaite wrote:

>
> Ideally, it would be nice if it would throw an exception and terminate the 
> loop.  I am still trying to figure out how to detect the condition and 
> recover form it in some form...  I am getting the "No error in readByte" 
> exception in my serialEvent() method after an input stream read.  It appears 
> to me that the only graceful recovery is to close the port and then reopen it 
> when it becomes available.  I can pass the event up to the update method in 
> my main frame, but I still can't close the port from within that thread.  Any 
> suggestions on how to pass this event to a location where the port can be 
> safely closed?
>

I've gone through and cleaned up the termios.c layer.  I need to get to a 
windows machine with a USB dongle and see where the ioctl() is being 
called.  Probably the eventLoop.  But all of the ioctls should probably 
result in an IOException during this condition.

I'll probably finish this up Monday night when I can borrow a USB 
dongle.

There is no point in putting the code into CVS yet.  If you are tinkering 
I can mail the patch.  I think we will want to make a couple fixes in 
SerialImp.c to handle errors before it's ready.

--
Trent Jarvi
tjarvi at qbang.org



From bob_tai2001 at yahoo.com  Mon Jun 12 09:42:14 2006
From: bob_tai2001 at yahoo.com (Bob Tai)
Date: Mon, 12 Jun 2006 08:42:14 -0700 (PDT)
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to RXTX
	again
Message-ID: <20060612154214.58219.qmail@web32804.mail.mud.yahoo.com>


thank you Paul, Joachim, Trent and everyone try to
workout the java comm and Rxtx situation.  At least
now I have something that is solid enough to make my
decision.  

thank you,
     Bob

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From Ralph.Buchfelder at gmx.net  Mon Jun 12 15:30:20 2006
From: Ralph.Buchfelder at gmx.net (Ralph Buchfelder)
Date: Mon, 12 Jun 2006 23:30:20 +0200
Subject: [Rxtx] rxtx binaries or porting to XSCALE Windows Mobile 2003 / 2005
Message-ID: <448DDCEC.7090506@gmx.net>

dear group,

i have been carefully reading your homepage, wiki and archives
but there seems to be no detailled information on porting to Windows 
Mobile/CE.

as far as i understood from the 'porting' section you can do porting to 
winCE. but how? do i only need to obtain the sourcecode (which one?) and 
compile this in Microsoft eMbedded Visual C++ for ARM/Xscale?
Any other ways?


unfortunately i must admit that i do have little linux skills but i have 
made my way through gcc and makefiles. right now i need to implement com 
  communication in a J2ME application and found your website as >the< 
solution.

best regards
Ralph Buchfelder

University of Regensburg
Department of Geography

PS: i dont care about Javacomm compliancy (ie. 2.0 or 2.1) - i just need 
a working serial port API in IBM J9 VM.


From paul.klissner at sun.com  Wed Jun 14 18:12:58 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Wed, 14 Jun 2006 17:12:58 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
Message-ID: <4490A60A.9090305@sun.com>

Hello RxTx community,

I finally think I have a compromise in place that will stand in the gap.

If you go to http://www.sun.com and search for javax.comm, you'll
get taken to a download page, where now users can get a copy of the
comm.jar file out of 2.0.3, along with just a license and a README.

I trust this will suffice until such time as RxTx decided to implement
their own java classes or we can get a JSR going to mitigate some
of the problems (the readme in the comm.jar 2.0.3 zip file
contains my thoughts on that).

Thanks,
Paul



From tjarvi at qbang.org  Wed Jun 14 21:15:35 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 14 Jun 2006 21:15:35 -0600 (MDT)
Subject: [Rxtx] rxtx-2.0-7 (final) src is in CVS
Message-ID: <Pine.LNX.4.61.0606142100500.2742@www>


I wasn't expecting to be working on rxtx 2.0 tonight :)

Thanks go out to Paul Klissner for his work in making the coming release 
of rxtx-2.0-7 possible for users that require package javax.comm on many 
platforms.

Most people know that rxtx 2.0 is for use with Sun's CommAPI 2.0 for 
Solaris or the Generic CommAPI 2.0-3 available for download at Sun.  If 
you need javax.comm packages on many platforms, you are probably 
interested.  If you use rxtx 2.1 in package gnu.io, then you are not going 
to care much.

I've tried to update the rxtx 2.0 src directory in preparation for 
rxtx-2.0-7 (final).  Linux should compile.  Windows will compile if you 
generate your own .def files (I'll generate these tomorrow).  If you have 
some time to do basic testing of the source, I'd appreciate it.  The 
source should be good but you may find classes not found.  This source is 
a backport from rxtx 2.1.

I wanted to get things started so anyone interested on Mac OS X could get 
a head start.

All of this is in CVS.  http://www.rxtx.org/cvs.html

I suspect we will have binaries for testing in a couple days if you are 
unable to compile.   Consider this a smoke test.

--
Trent Jarvi
tjarvi at qbang.org


From legolas.w at gmail.com  Wed Jun 14 22:04:28 2006
From: legolas.w at gmail.com (Legolas Woodland)
Date: Wed, 14 Jun 2006 21:04:28 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <4490A60A.9090305@sun.com>
References: <4490A60A.9090305@sun.com>
Message-ID: <87ee9b170606142104p745fcef0vea622fbc8f528bfc@mail.gmail.com>

is there anything new in this version of javax.comm ?
thanks


On 6/14/06, Paul Klissner <paul.klissner at sun.com> wrote:
>
> Hello RxTx community,
>
> I finally think I have a compromise in place that will stand in the gap.
>
> If you go to http://www.sun.com and search for javax.comm, you'll
> get taken to a download page, where now users can get a copy of the
> comm.jar file out of 2.0.3, along with just a license and a README.
>
> I trust this will suffice until such time as RxTx decided to implement
> their own java classes or we can get a JSR going to mitigate some
> of the problems (the readme in the comm.jar 2.0.3 zip file
> contains my thoughts on that).
>
> Thanks,
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060614/5ff4dfbc/attachment-0009.html

From joachim at buechse.de  Thu Jun 15 07:22:48 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 15 Jun 2006 15:22:48 +0200
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
Message-ID: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>

Good day!

Some of my users report problems using RXTX 2.1.7 on Windows98 to  
communicate with an FTDI FT245BM chip (using their latest VCP  
driver). Either no ports are being shown (ie returned form  
CommPortIdentifier.getPortIdentifiers()) or the transfers fail.

Did anyone run into similar Problems with Win98??

Best regards,
Joachim



From ajmas at sympatico.ca  Thu Jun 15 08:12:28 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Thu, 15 Jun 2006 10:12:28 -0400
Subject: [Rxtx] API change question
Message-ID: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

How closely do you follow the Java Communication API spec? The reason I ask is because I would be interested in augmenting the CommPortIdentifier class to include a getDisplayName() method. By default it would return the same value as getName(), but would provide the possibility of displaying a 'user friendly' name, for platforms where the display name is not the same as the device name. An example of this is on MacOS X, where currently the names seem to be of the form /dev/cu.* and /dev/tty.*, yet what the expects to see is simply the part after the full-stop. Although I could move this logic into the Java code, it would be nice to see it transparent to the Java code.

Andre




From ajmas at sympatico.ca  Thu Jun 15 08:16:22 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Thu, 15 Jun 2006 10:16:22 -0400
Subject: [Rxtx] Package to use
Message-ID: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

While the Java API spec refers to javax.comm, I see that only gnu.io is provide by the rxtx project. Should our projects refer to the gnu.io package or the javax.comm API?

Andre



From joachim at buechse.de  Thu Jun 15 08:45:05 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 15 Jun 2006 16:45:05 +0200
Subject: [Rxtx] API change question
In-Reply-To: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>

Hello Andre,

the /dev/cu and /dev/tty have different semantics on OS X. It is much  
more than a simply naming issue to unify them, see my recent mail to  
the list...

Best regards,
Joachim


On 15.06.2006, at 16:12, Andre-John Mas wrote:

> Hi,
>
> How closely do you follow the Java Communication API spec? The  
> reason I ask is because I would be interested in augmenting the  
> CommPortIdentifier class to include a getDisplayName() method. By  
> default it would return the same value as getName(), but would  
> provide the possibility of displaying a 'user friendly' name, for  
> platforms where the display name is not the same as the device  
> name. An example of this is on MacOS X, where currently the names  
> seem to be of the form /dev/cu.* and /dev/tty.*, yet what the  
> expects to see is simply the part after the full-stop. Although I  
> could move this logic into the Java code, it would be nice to see  
> it transparent to the Java code.
>
> Andre
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From lyon at docjava.com  Thu Jun 15 10:16:29 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Thu, 15 Jun 2006 12:16:29 -0400
Subject: [Rxtx] cu.modem != /dev/ttya on mac.
In-Reply-To: <763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
	<763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>
Message-ID: <p0602046cc0b7378a95b0@[192.168.1.152]>

>Hi All,

I think that Joachim is correct. For the longest time,
I have been trying to figure out how to direct dial using
the cu.modem on the mac under os x.

As a less-than-optimal approach to auto-dialing, I have used
a keyspan USB 19HS adapter, along with an external modem, to
obtain the dialing feature.

Ideally, it would be better to dial with the built-in modem...but that did not
always seem to work, for some reason. Have others had some experience with
using the built in modem for dialing on the mac?

Thanks!
  - Doug


>Hello Andre,
>
>the /dev/cu and /dev/tty have different semantics on OS X. It is much?
>more than a simply naming issue to unify them, see my recent mail to?
>the list...
>
>Best regards,
>Joachim
>



From doug at dupreeinc.com  Thu Jun 15 14:52:50 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 15 Jun 2006 13:52:50 -0700
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
In-Reply-To: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
References: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
Message-ID: <4491C8A2.8090108@dupreeinc.com>

Hi Joachim,

I have been doing a lot with the new FTDI driver with win XP and have 
not had that particular problem.  I did notice that the new driver 
(dated May19th, 2006) is only for XP, Server 2003, and 2000.  Are they 
trying to use the 2.00.00 drivers or the old 1.09.06 version.  I am 
using a FT232R based module, but it uses the same drivers and I assume 
it would have the same problems.  Let me know which driver they are 
using and I can load up a 98 system here and see if  I can duplicate the 
problem.

Doug

Joachim Buechse wrote:

>Good day!
>
>Some of my users report problems using RXTX 2.1.7 on Windows98 to  
>communicate with an FTDI FT245BM chip (using their latest VCP  
>driver). Either no ports are being shown (ie returned form  
>CommPortIdentifier.getPortIdentifiers()) or the transfers fail.
>
>Did anyone run into similar Problems with Win98??
>
>Best regards,
>Joachim
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From matthewhepp at yahoo.com  Thu Jun 15 17:34:47 2006
From: matthewhepp at yahoo.com (Matthew Hepp)
Date: Thu, 15 Jun 2006 16:34:47 -0700 (PDT)
Subject: [Rxtx] Wither the XCode project?
Message-ID: <20060615233447.48064.qmail@web50311.mail.yahoo.com>

Either I don't know how to properly use CVS (entirely possibl), or the XCode
project is not making through the update properly. Doing a "cvs update" against
2.1-7 creates an XCode folder in MACOSX_IDE, and therein a
LibSerialUniversal.xcodeproj, but trying to open it yields a "Unable to Open
Project - Project rxtx-devel/MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj
cannot be opened because it is missing its project.pbxproj file" error. Showing
package contents reveals just the cvs-related files. Perhaps this is why
previous xcode projects have been saved as an sit.hqx - to retain the resource
fork?

Can someone point me in the right direction?

Thanks,

Matt

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Thu Jun 15 19:53:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 19:53:06 -0600 (MDT)
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
In-Reply-To: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
References: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
Message-ID: <Pine.LNX.4.61.0606151944070.23137@www>

On Thu, 15 Jun 2006, Joachim Buechse wrote:

> Good day!
>
> Some of my users report problems using RXTX 2.1.7 on Windows98 to
> communicate with an FTDI FT245BM chip (using their latest VCP
> driver). Either no ports are being shown (ie returned form
> CommPortIdentifier.getPortIdentifiers()) or the transfers fail.
>
> Did anyone run into similar Problems with Win98??
>

Hi Joachim

It has been a long time since I've tested win98.  I know rxtx-2.1-7pre16 
did get testing on win98 with ~jdk 1.3 though.  I wonder if jdks are still 
tested on that platform.

With win98 you usually have older boxes.  They can be short on CPU and 
memory.  Enumeration should work but I could picture runtime performance 
issues on win98.

The enumeration problems could result from other copies of your 
application if various states of decay still holding onto the port.  When 
things go wrong, people also like to open other terminal software to see 
whats going on which can interfere.  You can't open a windows port with 
two apps.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Thu Jun 15 20:08:53 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 20:08:53 -0600 (MDT)
Subject: [Rxtx] API change question
In-Reply-To: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606151954270.23137@www>

On Thu, 15 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> How closely do you follow the Java Communication API spec?

I can explain how this worked in the past.  How we do it in the future is 
open for discussion.

In the past we have tried to follow it as close as possible in gnu.io 
(rxtx 2.1).  We have added extensions but try to discourage their use. 
The extensions are clearly marked as such in the source code and javadocs.

rxtx 2.0 was intended to be a strict implementation of part of the spec. 
We let Sun's interfaces decide what methods can be called. There are 
differences not covered by the spec such as default values.  Thats not 
intentional but rather hard to avoid.

--
Trent Jarvi
tjarvi at qbang.org





From tjarvi at qbang.org  Thu Jun 15 21:09:11 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 21:09:11 -0600 (MDT)
Subject: [Rxtx] Package to use
In-Reply-To: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606152026120.23137@www>

On Thu, 15 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> While the Java API spec refers to javax.comm, I see that only gnu.io is 
> provide by the rxtx project. Should our projects refer to the gnu.io 
> package or the javax.comm API?
>

Hi Andre

Lets see if I can give a fair and balanced answer to that.

If you are starting a new project and want to use RXTX, I would recommend 
using gnu.io.  The community support for gnu.io will not be going away 
anytime soon.  You can switch between gnu.io (2.1) and javax.comm (2.0) 
fairly easily.  They are not intended to be incompatible.  You just change 
package names and libs.

You can also consider the combination of rxtx 2.0 with Sun's commapi 
2.0-3.  This is considered a stop-gap measure by Sun for previous users of 
that combination.  Together rxtx 2.0 and Sun CommAPI 2.0 work in namespace 
javax.comm for programmers.

Finally, you can opt to just use Sun's oferrings in CommAPI 3.0 without 
rxtx.  That would be in namespace javax.comm also.  CommAPI 3.0 may be 
of more interest to you if you are looking at POS with Sun computers. 
Rxtx does not currently support the changes in CommAPI 3.0 or have firm 
plans to do so.  That does not mean we wouldn't implement them.  It just 
means nobody has contributed code yet.

You can't combine rxtx with CommAPI 3.0 for technical reasons that wont 
likely be fixed soon.

It's up to you as far as what you use.  We like to provide the freedom so 
you can choose.  Realistically, we will be supporting gnu.io mainly 
because we have some control over that name space and can support it.

Things may happen in the future that enable rxtx to provide more support 
in the javax namespace but that has not happened yet.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun 16 00:33:06 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 08:33:06 +0200
Subject: [Rxtx] Wither the XCode project?
In-Reply-To: <20060615233447.48064.qmail@web50311.mail.yahoo.com>
References: <20060615233447.48064.qmail@web50311.mail.yahoo.com>
Message-ID: <D30D660F-A49B-464E-AE4C-6B4563893682@buechse.de>

Hello Matthew,

could you please send me the contents of your

   rxtx-devel/CVS
   rxtx-devel/MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj/CVS

directories as a zip to my personal email address. This should  
indicate why the file is not checked out. I can see that it exists on  
the correct branch in the repository, so something must have gone  
wrong during the "cvs update"...

Best regards,
Joachim

On 16.06.2006, at 01:34, Matthew Hepp wrote:

> Either I don't know how to properly use CVS (entirely possibl), or  
> the XCode
> project is not making through the update properly. Doing a "cvs  
> update" against
> 2.1-7 creates an XCode folder in MACOSX_IDE, and therein a
> LibSerialUniversal.xcodeproj, but trying to open it yields a  
> "Unable to Open
> Project - Project rxtx-devel/MACOSX_IDE/XCode/ 
> LibSerialUniversal.xcodeproj
> cannot be opened because it is missing its project.pbxproj file"  
> error. Showing
> package contents reveals just the cvs-related files. Perhaps this  
> is why
> previous xcode projects have been saved as an sit.hqx - to retain  
> the resource
> fork?
>
> Can someone point me in the right direction?



From joachim at buechse.de  Fri Jun 16 10:41:20 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 18:41:20 +0200
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <p06230903c0b88613dca6@[10.0.1.7]>
References: <p06230903c0b88613dca6@[10.0.1.7]>
Message-ID: <03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>

Hello Bob,

until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was  
behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if  
Trent has migrated all recent changes from 2.1 to 2.0.

I have added the XCode project and updated documentation only to the  
gnu.io branch. Once the 2.0 implementation is up to date I will copy  
over the documentation/build files make them work.

Best regards,
Joachim

On 16.06.2006, at 18:07, Bob Jacobsen wrote:

> I'm one of the developers for the JMRI project, which provides  
> model railroad software in Java.  We've been using RXTX to provide  
> serial port access on MacOS X and Linux; we use the old javax.comm  
> 2.0 on Windows, OS/2 and Solaris.  Because of that, we need to stay  
> with RXTX 2.0, not 2.1
>
> We've been using the 2.0-pre17 installer for a long time, but it's  
> not compatible with Intel macs.
>
> Can you point me to where I can find the right files for RXTX 2.0  
> to package with the program?
>
> The current situation is confusing to me.  I've been pointed to  
> recent 2.1 versions (but we need the javax.comm names), to an even  
> older installer, etc.  I've been reading that some versions require  
> an installer, and others don't, but I haven't been able to figure  
> out which (if any) of those are where in CVS.
>
> I'd really appreciate a clear statement of what files to use and  
> what to do with them that I can pass on to our users.
>
> I'm more than happy to put files in the local classpath, have users  
> run an installer, or anything else.  Whatever is easiest for you.
>
> Thanks!  I really appreciate all that you do to keep RXTX working.
>
> Bob
> -- 
> Bob Jacobsen +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG



From joachim at buechse.de  Fri Jun 16 09:59:28 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 17:59:28 +0200
Subject: [Rxtx] Wither the XCode project?
In-Reply-To: <20060616150240.49464.qmail@web50309.mail.yahoo.com>
References: <20060616150240.49464.qmail@web50309.mail.yahoo.com>
Message-ID: <D9935E05-2B83-488D-86DD-42599E229052@buechse.de>

Hello Matthew,

you have checked out the trunk (which is the 2.0.7 javax.comm.xxx  
release). For rxtx-2.1.7 (gnu.io.xxx release) you need to check out  
the branch

      commapi-0-0-1

The easiest way to do this is to download the rxtx src archive,  
unpack it and then do a cvs up inside the decompressed tree.  
Optionally you could do a

      cvs co -r commapi-0-0-1

but this will take much longer!

Best regards,
Joachim

When you do a cvs status it will show the sticky tag.

41:~/jdevelop/rxtx-2.1-7r2 joachim$ cvs status README.OSX
===================================================================
File: README.OSX        Status: Up-to-date

    Working revision:    1.1.2.1
    Repository revision: 1.1.2.1 /usr/local/cvsroot/rxtx-devel/Attic/ 
README.OSX,v
    Sticky Tag:          commapi-0-0-1 (branch: 1.1.2)
    Sticky Date:         (none)
    Sticky Options:      (none)




On 16.06.2006, at 17:02, Matthew Hepp wrote:

> %cvs status README.MACOSX
> ===================================================================
> File: README.MACOSX     Status: Up-to-date
>
>    Working revision:    1.1
>    Repository revision: 1.1     /usr/local/cvsroot/rxtx-devel/ 
> README.MACOSX,v
>    Sticky Tag:          (none)
>    Sticky Date:         (none)
>    Sticky Options:      (none)



From tjarvi at qbang.org  Fri Jun 16 16:31:18 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Fri, 16 Jun 2006 16:31:18 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
Message-ID: <Pine.LNX.4.61.0606161630030.14139@www>

On Fri, 16 Jun 2006, Joachim Buechse wrote:

> Hello Bob,
>
> until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was
> behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if
> Trent has migrated all recent changes from 2.1 to 2.0.
>

The src/ directory and configure.in/configure files should be fine.  I 
have not touched the Mac OS X directories.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sat Jun 17 02:39:55 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sat, 17 Jun 2006 10:39:55 +0200
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <Pine.LNX.4.61.0606161630030.14139@www>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
Message-ID: <350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>

Hello Trent,

apparently the IOEXCL changes have not made it into 2.0. I will add  
them to achieve a minimal diff between 2.0 and 2.1.

One other thing that bugs me for a while...

Shouldn't we replace "if !defined(TIOCSERGETLSR) && !defined(WIN32)"  
by a definition of its own "if defined(DRAINTHREAD)"? I think this  
would make the code clearer for people starting to read it.

Regards,
Joachim


On 17.06.2006, at 00:31, Trent Jarvi wrote:

> On Fri, 16 Jun 2006, Joachim Buechse wrote:
>
>> Hello Bob,
>>
>> until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was
>> behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if
>> Trent has migrated all recent changes from 2.1 to 2.0.
>>
>
> The src/ directory and configure.in/configure files should be fine.  I
> have not touched the Mac OS X directories.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From tropicsu at hotmail.com  Sat Jun 17 09:32:48 2006
From: tropicsu at hotmail.com (Yoke K)
Date: Sat, 17 Jun 2006 15:32:48 +0000
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
Message-ID: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>

Hi,

I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to work with 
MAC OS X.
I am using iTegno 3000 - USB GPRS Modem.

Files in /dev and a symbolic link as follows:

crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 -> tty.usbserial

In my SendMessage.java, I have this line:
CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");

Appreciate any help ?

- Jon


Errors as follows:

>>INFO: SMSLib API for Java / v1.2.2
>>INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>INFO: JRE Version: 1.5.0_06
>>INFO: JRE Impl Version: 1.5.0_06-64
>>INFO: O/S: Mac OS X / ppc / 10.4.6
>>INFO: Using Wavecom (Generic) AT handler.

SendMessage(): Send a message.
  Using SMSLib API for Java v1.2.2

Connecting ..... :
>>INFO: CSerialDriver(): Connecting...
Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
>>INFO: CSerialDriver(): Disconnecting...
gnu.io.NoSuchPortException
        at 
gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:218)
        at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
        at org.smslib.CService.connect(CService.java:197)
        at SendMessage.main(SendMessage.java:38)

_________________________________________________________________
Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/



From tjarvi at qbang.org  Sat Jun 17 10:12:30 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 10:12:30 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
	<350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
Message-ID: <Pine.LNX.4.61.0606171010060.14139@www>

On Sat, 17 Jun 2006, Joachim Buechse wrote:

> Hello Trent,
>
> apparently the IOEXCL changes have not made it into 2.0. I will add
> them to achieve a minimal diff between 2.0 and 2.1.
>

Hi Joachim

As I recall the IOEXCL change was after 2.1-7.  I was just syncing with 
2.1-7.  We can release 2.1-8 and 2.0-8 with the same changes.

> One other thing that bugs me for a while...
>
> Shouldn't we replace "if !defined(TIOCSERGETLSR) && !defined(WIN32)"
> by a definition of its own "if defined(DRAINTHREAD)"? I think this
> would make the code clearer for people starting to read it.
>


Sure.  We can do that for -8.  The TIOCSERGETLSR code should be a special 
case not the expected.  I think only Linux uses it.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Sat Jun 17 10:48:21 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 10:48:21 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <Pine.LNX.4.61.0606171010060.14139@www>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
	<350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
	<Pine.LNX.4.61.0606171010060.14139@www>
Message-ID: <Pine.LNX.4.61.0606171047310.14139@www>

On Sat, 17 Jun 2006, Trent Jarvi wrote:

> On Sat, 17 Jun 2006, Joachim Buechse wrote:
>
>> Hello Trent,
>>
>> apparently the IOEXCL changes have not made it into 2.0. I will add
>> them to achieve a minimal diff between 2.0 and 2.1.
>>
>
> Hi Joachim
>
> As I recall the IOEXCL change was after 2.1-7.  I was just syncing with
> 2.1-7.  We can release 2.1-8 and 2.0-8 with the same changes.
>

We could just move to 2.1-8 and 2.0-8.

--
Trent Jarvi
tjarvi at qbang.org


From brian.t.lamb at gmail.com  Tue Jun 13 13:54:13 2006
From: brian.t.lamb at gmail.com (Brian Lamb)
Date: Tue, 13 Jun 2006 15:54:13 -0400
Subject: [Rxtx] Windows XP Installation
Message-ID: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>

I've not installed Java packages on Windows before and am unsure how to
proceed. All the documentation I've seen provides detailed instructions on
how to install on Linux or Solaris. I was wondering how to install rxtx on
Windows XP.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060613/6f68cd5c/attachment-0009.html

From tjarvi at qbang.org  Sat Jun 17 13:57:03 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 13:57:03 -0600 (MDT)
Subject: [Rxtx] Windows XP Installation
In-Reply-To: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>
References: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0606171356120.14139@www>

On Tue, 13 Jun 2006, Brian Lamb wrote:

> I've not installed Java packages on Windows before and am unsure how to
> proceed. All the documentation I've seen provides detailed instructions on
> how to install on Linux or Solaris. I was wondering how to install rxtx on
> Windows XP.
>

Hi Brian

Which rxtx version are you trying to install?

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sun Jun 18 10:41:44 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sun, 18 Jun 2006 18:41:44 +0200
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
References: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
Message-ID: <8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>

Hello Jon,

 From OSX's standpoint a symbolic link is not a device (as far as I  
know). What stops you from using tty.usbserial? Did you try hard- 
linking?

Regards,
Joachim

On 17.06.2006, at 17:32, Yoke K wrote:
> Hi,
>
> I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to  
> work with
> MAC OS X.
> I am using iTegno 3000 - USB GPRS Modem.
>
> Files in /dev and a symbolic link as follows:
>
> crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
> crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
> lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->  
> tty.usbserial
>
> In my SendMessage.java, I have this line:
> CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
>
> Appreciate any help ?
>
> - Jon
>
>
> Errors as follows:
>
>>> INFO: SMSLib API for Java / v1.2.2
>>> INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>> INFO: JRE Version: 1.5.0_06
>>> INFO: JRE Impl Version: 1.5.0_06-64
>>> INFO: O/S: Mac OS X / ppc / 10.4.6
>>> INFO: Using Wavecom (Generic) AT handler.
>
> SendMessage(): Send a message.
>   Using SMSLib API for Java v1.2.2
>
> Connecting ..... :
>>> INFO: CSerialDriver(): Connecting...
> Experimental:  JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
>>> INFO: CSerialDriver(): Disconnecting...
> gnu.io.NoSuchPortException
>         at
> gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java: 
> 218)
>         at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
>         at org.smslib.CService.connect(CService.java:197)
>         at SendMessage.main(SendMessage.java:38)
>
> _________________________________________________________________
> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Sun Jun 18 10:56:55 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 12:56:55 -0400
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>
References: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
	<8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>
Message-ID: <7B6834E3-F41D-46B6-B979-55466BC73859@sympatico.ca>

Have you been able to get any other software to talk with your
modem? What port is it using? Have tried using the cu.usbserial
instead?

Andre

On 18-Jun-06, at 12:41 , Joachim Buechse wrote:

> Hello Jon,
>
>  From OSX's standpoint a symbolic link is not a device (as far as I
> know). What stops you from using tty.usbserial? Did you try hard-
> linking?
>
> Regards,
> Joachim
>
> On 17.06.2006, at 17:32, Yoke K wrote:
>> Hi,
>>
>> I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to
>> work with
>> MAC OS X.
>> I am using iTegno 3000 - USB GPRS Modem.
>>
>> Files in /dev and a symbolic link as follows:
>>
>> crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
>> crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
>> lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->
>> tty.usbserial
>>
>> In my SendMessage.java, I have this line:
>> CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
>>
>> Appreciate any help ?
>>
>> - Jon
>>
>>
>> Errors as follows:
>>
>>>> INFO: SMSLib API for Java / v1.2.2
>>>> INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>>> INFO: JRE Version: 1.5.0_06
>>>> INFO: JRE Impl Version: 1.5.0_06-64
>>>> INFO: O/S: Mac OS X / ppc / 10.4.6
>>>> INFO: Using Wavecom (Generic) AT handler.
>>
>> SendMessage(): Send a message.
>>   Using SMSLib API for Java v1.2.2
>>
>> Connecting ..... :
>>>> INFO: CSerialDriver(): Connecting...
>> Experimental:  JNI_OnLoad called.
>> Stable Library
>> =========================================
>> Native lib Version = RXTX-2.1-7
>> Java lib Version   = RXTX-2.1-7
>>>> INFO: CSerialDriver(): Disconnecting...
>> gnu.io.NoSuchPortException
>>         at
>> gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:
>> 218)
>>         at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
>>         at org.smslib.CService.connect(CService.java:197)
>>         at SendMessage.main(SendMessage.java:38)
>>
>> _________________________________________________________________
>> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Sun Jun 18 17:33:08 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 19:33:08 -0400
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
Message-ID: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>

Hi,

I am have a program that I wrote in Java to communicate with a  
Bluetooth GPS device. I am
trying to get this working on my Mac, but I keep getting told that:

gnu.io.PortInUseException: Unknown Application

but

portIdentifier.isCurrentlyOwned()

returns false and when I do lsof on the device I am trying to connect  
to, I see no application
using it. As the same time if I go to the command line and use  
minicom I have no issues. The
exception happens with this call:

CommPort commPort = portIdentifier.open(null,0);

Any suggestions?

Andre


From ajmas at sympatico.ca  Sun Jun 18 17:45:11 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 19:45:11 -0400
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
Message-ID: <30245B30-682D-4EAE-8084-8227B719F10D@sympatico.ca>

BTW My code snippet is:

     private InputStream connectToSerial () throws IOException,  
Exception
     {
         InputStream in = null;

         Enumeration portEnum = CommPortIdentifier.getPortIdentifiers();
         while ( portEnum.hasMoreElements() )
         {
             CommPortIdentifier portIdentifier = (CommPortIdentifier)  
portEnum.nextElement();
             System.out.println(portIdentifier.getName() + " - " +  
portIdentifier.getPortType() );
         }

         CommPortIdentifier portIdentifier =  
CommPortIdentifier.getPortIdentifier("/dev/cu.BTGPS-SPPslave-1");
         System.out.println("current owner: " +  
portIdentifier.getCurrentOwner());
         if ( portIdentifier.isCurrentlyOwned() )
         {
             System.out.println("Error: Port is currently in use");
             return null;
         }
         else
         {
             CommPort commPort = portIdentifier.open(this.getClass 
().getName(),2000);

             if ( commPort instanceof SerialPort )
             {
                 SerialPort serialPort = (SerialPort) commPort;
                 serialPort.setSerialPortParams 
(4800,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE 
);
                 in = serialPort.getInputStream();

                 return in;
             }
             else
             {
                 System.out.println("Error: Only serial ports are  
handled.");
             }
         }


         return in;
     }


On 18-Jun-06, at 19:33 , Andr?-John Mas wrote:

> Hi,
>
> I am have a program that I wrote in Java to communicate with a
> Bluetooth GPS device. I am
> trying to get this working on my Mac, but I keep getting told that:
>
> gnu.io.PortInUseException: Unknown Application
>
> but
>
> portIdentifier.isCurrentlyOwned()
>
> returns false and when I do lsof on the device I am trying to connect
> to, I see no application
> using it. As the same time if I go to the command line and use
> minicom I have no issues. The
> exception happens with this call:
>
> CommPort commPort = portIdentifier.open(null,0);
>
> Any suggestions?
>
> Andre
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From joachim at buechse.de  Mon Jun 19 05:54:49 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 13:54:49 +0200
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de>

This is most likely due to a problem with lock files. If you have  
downloaded the binaries of 2.17 rxtx will try to create non-standard  
lock files on OSX. We have since changed the code to use OSX device  
locking - however the binaries have not been updated yet. The 2.18  
release fixing this issue is due shortly.

Regards,
Joachim

On 19.06.2006, at 01:33, Andr?-John Mas wrote:

> Hi,
>
> I am have a program that I wrote in Java to communicate with a
> Bluetooth GPS device. I am
> trying to get this working on my Mac, but I keep getting told that:
>
> gnu.io.PortInUseException: Unknown Application
>
> but
>
> portIdentifier.isCurrentlyOwned()
>
> returns false and when I do lsof on the device I am trying to connect
> to, I see no application
> using it. As the same time if I go to the command line and use
> minicom I have no issues. The
> exception happens with this call:
>
> CommPort commPort = portIdentifier.open(null,0);
>
> Any suggestions?
>
> Andre
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From joachim at buechse.de  Mon Jun 19 06:44:27 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 14:44:27 +0200
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <4490A60A.9090305@sun.com>
References: <4490A60A.9090305@sun.com>
Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>

Hello Paul,

I just downloaded the "generic" javax.comm version now available. A  
first check indicates, that it was compiled with a JDK 1.4 javac  
without setting the target classfile version. In other words in can  
not be loaded by 1.1-1.3 VMs (or PersonalJava).

Do you see any chance to provide a version compiled with classfile  
format 45.3 (ie JVM1.1).

---
52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose  
javax.comm.SerialPort | head -5
Compiled from "SerialPort.java"
public abstract class javax.comm.SerialPort extends javax.comm.CommPort
   SourceFile: "SerialPort.java"
   minor version: 0
   major version: 48
---

Best regards,
Joachim


On 15.06.2006, at 02:12, Paul Klissner wrote:

> Hello RxTx community,
>
> I finally think I have a compromise in place that will stand in the  
> gap.
>
> If you go to http://www.sun.com and search for javax.comm, you'll
> get taken to a download page, where now users can get a copy of the
> comm.jar file out of 2.0.3, along with just a license and a README.
>
> I trust this will suffice until such time as RxTx decided to implement
> their own java classes or we can get a JSR going to mitigate some
> of the problems (the readme in the comm.jar 2.0.3 zip file
> contains my thoughts on that).
>
> Thanks,
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Mon Jun 19 09:11:45 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Mon, 19 Jun 2006 11:11:45 -0400
Subject: [Rxtx] Examples added to Wiki
Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

I have added a couple of examples to the Wiki:

http://rxtx.qbang.org/wiki/index.php/Examples

If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :)

Andre



From paul.klissner at sun.com  Mon Jun 19 10:42:47 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Mon, 19 Jun 2006 09:42:47 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>
References: <4490A60A.9090305@sun.com>
	<03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>
Message-ID: <4496D407.1090609@sun.com>

Joachim Buechse wrote:
> Hello Paul,
> 
> I just downloaded the "generic" javax.comm version now available. A  
> first check indicates, that it was compiled with a JDK 1.4 javac  
> without setting the target classfile version. In other words in can  
> not be loaded by 1.1-1.3 VMs (or PersonalJava).
> 
> Do you see any chance to provide a version compiled with classfile  
> format 45.3 (ie JVM1.1).
> 
> ---
> 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose  
> javax.comm.SerialPort | head -5
> Compiled from "SerialPort.java"
> public abstract class javax.comm.SerialPort extends javax.comm.CommPort
>    SourceFile: "SerialPort.java"
>    minor version: 0
>    major version: 48
> ---

I cannot promise when I can do that. Since we thought we were done
with javax.comm, the build environment got moved around, and right
now it doesn't even compile in it's new home.  I tried and it was
not cooperative at all. I was never impressed with that workspace
(in fact far far from it, it is a mess, which is why I migrated 3.0
to ant and never looked back).  It will take some real determination
for me to rebuild it, and frankly, right now I'm swamped.  If I can
find a bit of time over the next few weeks to do it, and it isn't
too bad an ordeal, I will.

Posting that will give me an excuse to post javax.comm 3.0, Update 2 as
well, while I'm working with the people who put content up on our
download center.  The only reason for a new update to 3.0 is that
I've changed the distribution to provide ispt (Interactive Serial
Port Tool), such that it can be launched as soon as the zip file
is unpacked, via a provided script.  ISPT is a command line
interactive tool for  manipulating one or two serial port,
sending data, managing events, etc... I've found it to be so useful
for doing certain kinds of validation  that I assume others will
find it useful to.  ISPT is already in 3.0u1, but one has to set
up their own classpath and launch it and since few people ever read
the documentation most won't know about it.  I've added the ability
to set stop bits and parity since 3.0u1 too.  But I digress.

Paul


From joachim at buechse.de  Mon Jun 19 11:01:28 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 19:01:28 +0200
Subject: [Rxtx] load mechanism of 2.0x
Message-ID: <CFD1440C-21AA-4D3B-9EA6-270D0FF9D6FC@buechse.de>

Good day,

I am trying to figure out, how the 2.0x distribution interacts with  
Suns implementation of javax.comm.CommPortIdentifier.

1) Apparently one can put javax.comm.properties in {java.home}/lib
2) The javax.comm package also reacts to -Djavax.comm.properties="...."

Looking at the javap output it also seems like CommPortIdentifier  
tries to find it's jar file and load the properties from there??


What I'm really looking for is a solution that allows using  
javax.comm with RXTX without modifying the VM installation. So I  
would prefer not to use 1) but I can't figure out how to use 2).

Any hints are welcome,
Joachim



From bob_tai2001 at yahoo.com  Mon Jun 19 15:00:35 2006
From: bob_tai2001 at yahoo.com (Bob Tai)
Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT)
Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place
	to start?
Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>

Hi, 

I got  rxtx Windows 2000 installed.  I did not use the
"best" way ... I just follow the insturuction and dump
the necessary files into the jre... I know it's "best"
idea, I got lazy didn't want to change my setting to
my Eclipse and classpath.

I was able to modify SimpleWrite.java to print on my
AddMaster serial printer.  I think I am ready to code!
But I need to make sure I can handle exceptions and so
on.  I notice the \samples\NullDriver\  has two files
seems to have some of the require method done, should
I start coding from those file?  I like the idea it
has the "time out" and basic exceptions done.   I am
slowly digging into the samples, but if you think any
of the code from Sun is good to checkout please let me
know.

btw, http://rxtx.qbang.org/wiki/index.php/Examples/
was very helpful, wish there are more examples.

thank you,

    Bob


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Mon Jun 19 15:55:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT)
Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good
 place to start?
In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>
References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606191542260.14139@www>

> I am
> slowly digging into the samples, but if you think any
> of the code from Sun is good to checkout please let me
> know.
>

I think NullDriver.java was an example stub driver for implementing 
something like rxtx.  It has been a while.  Unless they have been updated, 
you will find the examples are very dated.  You can look at how they use 
the port but avoid the GUI and hard coded variables (number of ports for 
instance).

There was no Swing and nobody knew what requirements today's compilers 
would make on code.  The examples worked fine with jdk 1.1 but times have 
changed.

--
Trent Jarvi
tjarvi at qbang.org


From tropicsu at hotmail.com  Mon Jun 19 19:49:08 2006
From: tropicsu at hotmail.com (Yoke K)
Date: Tue, 20 Jun 2006 01:49:08 +0000
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
Message-ID: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>

An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/fa588f00/attachment.html

From ajmas at sympatico.ca  Mon Jun 19 21:14:37 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Mon, 19 Jun 2006 23:14:37 -0400
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>
References: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>
Message-ID: <CA22AB2A-5712-458B-9984-68477C6042AF@sympatico.ca>

Regarding the PortInUseException, I had a similar issue and got
this response from the mailing list:

   http://mailman.qbang.org/pipermail/rxtx/Week-of- 
Mon-20060619/062838.html

Andre
On 19-Jun-06, at 21:49 , Yoke K wrote:

> Hi Andre, Joachim
>
> I have tried using /dev/tty.usbserial and also /dev/cu.usbserial  
> and it also reported error as  "gnu.io.PortInUseException".
>
> The iTegno modem works in windows environment. As I moving around  
> using my ibook and I need to get it work on MAC OS as well.
>
> >> INFO: SMSLib API for Java / v1.2.2
> >> INFO: Using port: /dev/tty.usbserial @ 115200 baud.
> >> INFO: JRE Version: 1.5.0_06
> >> INFO: JRE Impl Version: 1.5.0_06-64
> >> INFO: O/S: Mac OS X / ppc / 10.4.6
> >> INFO: Using Wavecom (Generic) AT handler.
>
> SendMessage(): Send a message.
> Using SMSLib API for Java v1.2.2
>
> Connecting ..... :
> >> INFO: CSerialDriver(): Connecting...
> Experimental: JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version = RXTX-2.1-7
> >> INFO: CSerialDriver(): Disconnecting...
> gnu.io.PortInUseException: Unknown Application
> at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354)
> at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1)
> at org.smslib.CService.connect(CService.java:197)
> at SendMessage.main(SendMessage.java:38)
>
> Thanks.
>
> - Jon
>
>
>
>
> ====================
>
> Hello Jon,
>
> From OSX's standpoint a symbolic link is not a device (as far as I
> know). What stops you from using tty.usbserial? Did you try hard-
> linking?
>
> Regards,
> Joachim
>
>
>
> From:  "Yoke K" <tropicsu at hotmail.com>
> To:  rxtx at qbang.org
> Subject:  RXTX-2.1-7 / MAC OS X / NoSuchPortException
> Date:  Sat, 17 Jun 2006 15:32:48 +0000
> >Hi,
> >
> >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to
> >work with MAC OS X.
> >I am using iTegno 3000 - USB GPRS Modem.
> >
> >Files in /dev and a symbolic link as follows:
> >
> >crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
> >crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
> >lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->
> >tty.usbserial
> >
> >In my SendMessage.java, I have this line:
> >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
> >
> >Appreciate any help ?
> >
> >- Jon
> >
> >
> >Errors as follows:
> >
> >>>INFO: SMSLib API for Java / v1.2.2
> >>>INFO: Using port: /dev/ttyS1 @ 56000 baud.
> >>>INFO: JRE Version: 1.5.0_06
> >>>INFO: JRE Impl Version: 1.5.0_06-64
> >>>INFO: O/S: Mac OS X / ppc / 10.4.6
> >>>INFO: Using Wavecom (Generic) AT handler.
> >
> >SendMessage(): Send a message.
> >  Using SMSLib API for Java v1.2.2
> >
> >Connecting ..... :
> >>>INFO: CSerialDriver(): Connecting...
> >Experimental:  JNI_OnLoad called.
> >Stable Library
> >=========================================
> >Native lib Version = RXTX-2.1-7
> >Java lib Version   = RXTX-2.1-7
> >>>INFO: CSerialDriver(): Disconnecting...
> >gnu.io.NoSuchPortException
> >        at
> >gnu.io.CommPortIdentifier.getPortIdentifier 
> (CommPortIdentifier.java:218)
> >        at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
> >        at org.smslib.CService.connect(CService.java:197)
> >        at SendMessage.main(SendMessage.java:38)
> >
> >_________________________________________________________________
> >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
> >
>
> Find love online with MSN Personals
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Tue Jun 20 02:35:24 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 10:35:24 +0200
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>

Hello everybody,

I have been fighting a bit with the javax.comm version of RXTX the  
last days. I am working on the README .OSX now and try to figure out  
which should be the "suggested" installation.

The facts:
------

- the "generic" comm.jar version of javax.comm which has been made re- 
available tries to load com.sun.comm.SolarisDriver
- this classname can be overridden ONLY by putting a file  
javax.comm.properties in {java.home}/lib
- if it is not overridden and SolarisDriver.class is not found  
CommPortIdentifier will be disfunctional (in particual it is not  
possible to add CommPort's via CommPortIdentifier.add).
- the license distributed with comm.jar does not allow the  
modification/addition of classes in javax.comm (however no mention of  
com.sun...)


What really bothers me is to suggest putting this config file in the  
"global" vm installation. This is particularly ugly on the Mac as  
there are several VM installations and the file may be forgotten.  
Additionally it may create versioning problems. I prefer an  
installation where all files are local to the application (even  
comm.jar).

In my opinion the ideal situation would be:
------

1) The author of a program compiles against javax.comm.
2a) For platforms supported by Sun the user is free to use the 3.0  
comm.jar download from Sun
2b) For platforms not supported by Sun the user adds RXTXComm.jar to  
the classpath of the application (and librxtxSerial.jnilib to the  
application directory). Also he will need the 2.0.3 generic comm.jar  
from Sun.
3) Nobody messes with the global VM installation.

Of course 2a) and 2b) could be handled by the author of the program  
via an appropriate installer. The author could also decide to always  
use RXTX and include the generic javax.comm classes as well as the  
RXTX classes in his application jar. [If he further uses an explicit  
call to System.load() he may even include the jnilib(s) in the jar,  
extract it (based on the platform name) at runtime to a temp file and  
load it from there.]


Suggested solution:
------

We only need to put the following class in the classpath BEFORE Suns  
comm.jar

   package com.sun.comm;
   public class SolarisDriver extends gnu.io.RXTXCommDriver {
   }

This is not "the pure art" (TM). It depends on an implementation  
detail of the generic driver. However, so does the  
javax.comm.properties file - as we have seen when Sun released 3.0.  
It has the following advantages:

- The "generic" javax.comm implementation will happily load this  
class as its primary driver.
- No javax.comm.properties file is required.
- This does not violate the javax.comm license agreement as there is  
no mention of the "com.sun.comm" package in this license agreement at  
all.
- Authors packaging comm.jar with their application can strip out all  
com.sun.comm classes from comm.jar


Please comment!

Joachim



From joachim at buechse.de  Tue Jun 20 02:50:36 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 10:50:36 +0200
Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar
Message-ID: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>

There has been some discussions about the best way to install RXTX  
and where to place files.

I suggest that,

- we include the native libraries for the most common operating  
systems (in a special version of) RXTXcomm.jar
- we add loader code which tries to extract and load the platform  
specific binary at runtime
- on failure the current mechanism remains as a fallback

Wether the current mechanism should have priority (ie loadLibrary  
before load) remains to be discussed.


The advantages of this solution are
  - users of RXTX do not need to worry about java/platform specific  
file placement.
  - authors of applications may fully merge RXTX into their  
application jar (which provides a double-clickable application for  
Windows and OSX, Linux?).

Please comment,
Joachim

PS: Of course the suggested solution is already possible today,  
however relatively few programmers know how to correctly extract a  
binary resource file via the class loader and load it as a native  
library.


From tjarvi at qbang.org  Tue Jun 20 03:58:12 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT)
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
Message-ID: <Pine.LNX.4.61.0606200335190.14139@www>

> 2a) For platforms supported by Sun the user is free to use the 3.0
> comm.jar download from Sun
> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to
> the classpath of the application (and librxtxSerial.jnilib to the
> application directory). Also he will need the 2.0.3 generic comm.jar
> from Sun.

As there are no plans to support CommAPI 3.0 due to the limitations in its 
implementation mentioned before, I would not recommend projects use Sun's 
3.0 comm.jar.  They will lose the freedom to chose their low level 
implementation by being locked into vendor specific modifications.

Projects should chose between platform neutrality in CommAPI 2.0 and 
reduced platform neutrality in commapi 3.0.  Projects should also strongly 
consider the fact that the 2.0 comm.jar targets only a reduced number of 
JVMs.

Projects can go with rxtx 2.1 or other packages but should probably only 
consider using Sun CommAPI with rxtx if they did so in the past.  They 
should take steps to no longer depend upon this option being available.

> Suggested solution:
> ------
>
> We only need to put the following class in the classpath BEFORE Suns
> comm.jar
>
>   package com.sun.comm;
>   public class SolarisDriver extends gnu.io.RXTXCommDriver {
>   }
>
> This is not "the pure art" (TM). It depends on an implementation
> detail of the generic driver. However, so does the
> javax.comm.properties file - as we have seen when Sun released 3.0.
> It has the following advantages:
>
> - The "generic" javax.comm implementation will happily load this
> class as its primary driver.
> - No javax.comm.properties file is required.
> - This does not violate the javax.comm license agreement as there is
> no mention of the "com.sun.comm" package in this license agreement at
> all.
> - Authors packaging comm.jar with their application can strip out all
> com.sun.comm classes from comm.jar
>

I would not encourage people to place packages in the com.sun.comm 
namespace.  Authors using Sun's commapi 2.0 should just realize it is 
greatly limited in practical utility and consider moving to something that 
isn't being rescued from EOL.

The primary focus of this release is projects previously depending upon 
Sun CommAPI + RXTX.  There are no plans at this time to provide future 
support in this arrangement due to technical incompatabilities we have no 
control over in commapi 3.0 and limited utility of Sun's generic comm.jar 
in commapi 2.0 offered.  Projects should be aware of this so they can make 
appropriate plans.

--
Trent Jarvi
tjarvi at qbang.org


From paul.klissner at sun.com  Tue Jun 20 05:24:00 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Tue, 20 Jun 2006 04:24:00 -0700
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
In-Reply-To: <Pine.LNX.4.61.0606200335190.14139@www>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
	<Pine.LNX.4.61.0606200335190.14139@www>
Message-ID: <4497DAD0.10803@sun.com>

Trent Jarvi wrote:
>> 2a) For platforms supported by Sun the user is free to use the 3.0
>> comm.jar download from Sun
>> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to
>> the classpath of the application (and librxtxSerial.jnilib to the
>> application directory). Also he will need the 2.0.3 generic comm.jar
>> from Sun.
> 
> As there are no plans to support CommAPI 3.0 due to the limitations in its 
> implementation mentioned before, I would not recommend projects use Sun's 
> 3.0 comm.jar.  They will lose the freedom to chose their low level 
> implementation by being locked into vendor specific modifications.
> 
> Projects should chose between platform neutrality in CommAPI 2.0 and 
> reduced platform neutrality in commapi 3.0.  Projects should also strongly 
> consider the fact that the 2.0 comm.jar targets only a reduced number of 
> JVMs.

Well, that's a little ambiguous because the API is the same
either way.  We're talking about Sun's implementation vs.
other implementations.
> 
> Projects can go with rxtx 2.1 or other packages but should probably only 
> consider using Sun CommAPI with rxtx if they did so in the past.  They 
> should take steps to no longer depend upon this option being available.

3.0 is platform centric because there is a need to add some
platform awareness to Sun's implementation, and the choices
for how to do that are limited by the constraints of the API,
as mentioned in the javax.comm 2.0.3 comm.jar download's README.

I am really advocating getting a JSR open (http://www.jcp.org)
to push a new comm API that is more pluggable, platform neutral
and addresses some of the deficiencies of the current API. Then
we can achieve the optimal of platform neutrality while
simulataneously allowing the API to flexibly adapt to
heterogeneous environments.

This is not a question of attitude, this is an issue of resources,
time and commitment.  The current owners of javax.comm within
Sun would like nothing better than to see the ideal reached for
the API and a model that will extend well beyond the foreseeable
future and work for the industry overall.



> 
>> Suggested solution:
>> ------
>>
>> We only need to put the following class in the classpath BEFORE Suns
>> comm.jar
>>
>>   package com.sun.comm;
>>   public class SolarisDriver extends gnu.io.RXTXCommDriver {
>>   }
>>
>> This is not "the pure art" (TM). It depends on an implementation
>> detail of the generic driver. However, so does the
>> javax.comm.properties file - as we have seen when Sun released 3.0.
>> It has the following advantages:
>>
>> - The "generic" javax.comm implementation will happily load this
>> class as its primary driver.
>> - No javax.comm.properties file is required.
>> - This does not violate the javax.comm license agreement as there is
>> no mention of the "com.sun.comm" package in this license agreement at
>> all.
>> - Authors packaging comm.jar with their application can strip out all
>> com.sun.comm classes from comm.jar
>>
> 
> I would not encourage people to place packages in the com.sun.comm 
> namespace.  Authors using Sun's commapi 2.0 should just realize it is 
> greatly limited in practical utility and consider moving to something that 
> isn't being rescued from EOL.
> 
> The primary focus of this release is projects previously depending upon 
> Sun CommAPI + RXTX.  There are no plans at this time to provide future 
> support in this arrangement due to technical incompatabilities we have no 
> control over in commapi 3.0 and limited utility of Sun's generic comm.jar 
> in commapi 2.0 offered.  Projects should be aware of this so they can make 
> appropriate plans.

Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86,
or need the powerful portmapping features in javax.com 3.0, or would like to
acquire the Interactive Serial Port Test utility.

-Paul


From paul.klissner at sun.com  Tue Jun 20 05:33:44 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Tue, 20 Jun 2006 04:33:44 -0700
Subject: [Rxtx] Suggested installation RXTX 2.0x...
In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
Message-ID: <4497DD18.70207@sun.com>

Joachim Buechse wrote:
> Hello everybody,
> 
> I have been fighting a bit with the javax.comm version of RXTX the  
> last days. I am working on the README .OSX now and try to figure out  
> which should be the "suggested" installation.
> 
> The facts:
> ------
> 
> - the "generic" comm.jar version of javax.comm which has been made re- 
> available tries to load com.sun.comm.SolarisDriver
> - this classname can be overridden ONLY by putting a file  
> javax.comm.properties in {java.home}/lib
> - if it is not overridden and SolarisDriver.class is not found  
> CommPortIdentifier will be disfunctional (in particual it is not  
> possible to add CommPort's via CommPortIdentifier.add).
> - the license distributed with comm.jar does not allow the  
> modification/addition of classes in javax.comm (however no mention of  
> com.sun...)
> 
> 
> What really bothers me is to suggest putting this config file in the  
> "global" vm installation. This is particularly ugly on the Mac as  
> there are several VM installations and the file may be forgotten.  
> Additionally it may create versioning problems. I prefer an  
> installation where all files are local to the application (even  
> comm.jar).
> 
> In my opinion the ideal situation would be:
> ------
> 
> 1) The author of a program compiles against javax.comm.
> 2a) For platforms supported by Sun the user is free to use the 3.0  
> comm.jar download from Sun
> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to  
> the classpath of the application (and librxtxSerial.jnilib to the  
> application directory). Also he will need the 2.0.3 generic comm.jar  
> from Sun.
> 3) Nobody messes with the global VM installation.
> 
> Of course 2a) and 2b) could be handled by the author of the program  
> via an appropriate installer. The author could also decide to always  
> use RXTX and include the generic javax.comm classes as well as the  
> RXTX classes in his application jar. [If he further uses an explicit  
> call to System.load() he may even include the jnilib(s) in the jar,  
> extract it (based on the platform name) at runtime to a temp file and  
> load it from there.]
> 

This was how the Sun implementation originated (I did not write
that code).  I completely agree, and I fixed the whole conf file
locating mechanism in 3.0 to avoid the problems youmentioned.
However, I was unaware of how RxTx was using Sun's implementation,
so I didn't architect it in such a way as to avoid namespace pollution
in the native space in for the backend provider.  In retrospect,
I should have done that differently just as a design principle,
but at this point I don't have the spare cycles to get that all
re-factored.  Further, I'm loathe to do it, because the whole
thing will still be an under-the-hood hack due to the constraints
of the API itself.

Paul





From brian at mbari.org  Tue Jun 20 10:23:54 2006
From: brian at mbari.org (Brian Schlining)
Date: Tue, 20 Jun 2006 09:23:54 -0700
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>


Hi Joachim,

> There has been some discussions about the best way to install RXTX
> and where to place files.
>
> I suggest that,
>
> - we include the native libraries for the most common operating
> systems (in a special version of) RXTXcomm.jar
> - we add loader code which tries to extract and load the platform
> specific binary at runtime
> - on failure the current mechanism remains as a fallback

I like your suggestion. However, my understanding is that in general  
the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH  
(Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to  
be loaded by the JVM. The alternative is to point to your native lib  
directory using -Djava.library.path=/my/dir/with/native/libs when you  
launch the JVM. So, I'm very interested to know how you're planning  
to work around this.

> PS: Of course the suggested solution is already possible today,
> however relatively few programmers know how to correctly extract a
> binary resource file via the class loader and load it as a native
> library.

So how do you use it to dynamically load a native lib? I've read that  
you can't really modify the java.library.path after the JVM has been  
launched. (http://forum.java.sun.com/thread.jspa? 
threadID=627890&tstart=90)

Thanks

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0009.html

From joachim at buechse.de  Tue Jun 20 09:20:29 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 17:20:29 +0200
Subject: [Rxtx] 2.0x in sync with 2.1x
Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>

I have added most of the changes from the 2.1 branch to the 2.0 branch.

This includes
  - correction of illegal javadoc comments
  - implementation errors in handling of Thread.interrupt in  
RXTXPort.java
  - MacOS X locking without lock files/special user groups
  - XCode project which builds a universal binary library
  - updated documentation for OSX

I have done some minimal testing (only G4).
[Trent: there are still some changes you made for specific baud  
rates. I will not sync this, as I can not test them. From my  
perspective we are ready for 2.08/2.18]

The updated documentation can be found in the file README.OSX. Here  
it is:

------------------------ Required files -----------------------

To use or compile RXTX 2.0.x you need to downlad the "generic"  
version (2.0.3)
of the javax.comm implementation from Sun. The zip you download  
contains an
archive comm.jar which is required:

- To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar

- To run the app you will need comm.jar in the classpath or in  
{java.lib.path}


------------------------ Installation on MacOSX -----------------------

WARNING: Please read this section until the end.

---
Preparation
---

You may want to spare your users the burden of modifying the global VM
installation. OSX has several different VM versions installed by  
default and
regular users will be unable to figure out which version will load your
application.

If you provide the class

package com.sun.comm;
public class SolarisDriver extends gnu.io.RXTXCommDriver {
}

and make sure, that it is present in the classpath before Suns  
"generic" comm.jar
your users can skip the following step:

Create a file named
    javax.comm.properties
in the directory
    /System/Library/Frameworks/JavaVM.framework/Home/lib/
which contains (only) the following line (no leading space):
    Driver=gnu.io.RXTXCommDriver



----
The unsafe way of using RXTX on OS X:
----

RXTX can be installed by putting the files
   libSerial.jnilib
   RXTXcomm.jar
   comm.jar
into the folder
   /Library/Java/Extensions

This is NOT RECOMMENDED as it creates versioning conflicts among  
applications.
However you may be forced to install it this way if an application  
was written
for Windows or Linux, requires RXTX and you are not able to change  
its starter.


----
The safe way of using RXTX on OS X:
----

Make sure that you have no (older) version of RXTX installed in
   /Library/Java/Extensions
   /System/Library/Java/Extensions
   /usr/lib/java

Put
   libSerial.jnilib
in the directory of the application (the JavaVM will find it there). Add
   RXTXComm.jar
   comm.jar
to the application classpath or include the classes in the  
application jar.
(Some applications already include the RXTX classes in their  
application jar,
in which case only the file libSerial.jnilib is required).


----
History
----

Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation  
of lockfiles
required special permissions for the user executing an application  
based on RXTX.
To simplify the setup RXTX came with an installer modifying group  
permissions
and installing RXTX in the global location /Library/Java/Extensions.  
However
this was prune to versioning conflicts and is no longer recommended.

--------------------- Build instructions for OSX XCode  
-------------------

contributed by Joachim Buechse <joachim at buechse.de>
original version by Dmitry Markman <dmarkman at mac.com>

System requirements for building:
MacOSX 10.4
XCode 2.3

   open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj
   choose libSerial.jnilib target
   build

After the build you will find RXTXcomm.jar and libSerial.jnilib files  
in the
directory build/Development.

In case you can't find RXTXcomm.jar build the RXTXcomm target manually.
In case of (serious) problems feel free to contact joachim at buechse.de .



From tjarvi at qbang.org  Tue Jun 20 22:01:45 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT)
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
Message-ID: <Pine.LNX.4.61.0606202127270.14139@www>

> ---
> Preparation
> ---
>
> You may want to spare your users the burden of modifying the global VM
> installation. OSX has several different VM versions installed by
> default and
> regular users will be unable to figure out which version will load your
> application.
>
> If you provide the class
>
> package com.sun.comm;
> public class SolarisDriver extends gnu.io.RXTXCommDriver {
> }
>
> and make sure, that it is present in the classpath before Suns
> "generic" comm.jar
> your users can skip the following step:

Hi Joachim

With regards to the above, I have not seen that we have Sun's OK to 
promote that.  I'm not very comfortable with the distribution 
documentation advocating this without Sun agreeing.

I see your point but I'd rather not actively promote putting classes in 
Sun's namespace without permission if you don't mind.  This isn't about 
what is in a license.

I'll go through the code tomorrow night.  It was a late night at work 
today.  There is also a w32 fix comming for people opening and closing 
multiple ports.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Wed Jun 21 01:56:45 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 21 Jun 2006 09:56:45 +0200
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <Pine.LNX.4.61.0606202127270.14139@www>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
	<Pine.LNX.4.61.0606202127270.14139@www>
Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>

Hello Trent,

I guess we will not get an explicit OK from Sun for such a hack. I  
think Paul has made it pretty clear, that he does not have the  
resources to modify the 2.x or 3.x code for the needs of RXTX. I'm  
not thrilled but OK with the current API. Hence I dont agree with  
Paul's idea to start a new JSR to fix the implementation - but that's  
mainly because I dont have the time to push it. According to their  
Readme Sun sees no business case in having cross platform support for  
javax.comm - that is sad but it's none of my business. However I  
prefer to program versus javax.comm in my projects as this gives an  
advanced user the chance to exchange the provider without access to  
the code.

I interpret Pauls reponse to my original "Request for comment" as a  
quiet acceptance of the hack I propose (he did respond, but not at  
all to the sun.comm namespace suggestion). This is certainly not  
something we should put into RXTXcomm.jar but hinting a work around  
for implementation errors should be allowed. That's why I've choosen  
the wording "You may want to spare" and "If you provide". The company  
I worked for has choosen similar hacks for years to fix bugs in swing  
for JDK1.1 applications. Those hacks were usually included in their  
own swingpatch.jar.

Having said all that - I do not take it as an insult if you remove  
the paragraph from the Readme. I appreciate that you notified me  
before. It would be interesting to hear some more opinions from the  
list members...

Best regards,
Joachim


On 21.06.2006, at 06:01, Trent Jarvi wrote:

>> ---
>> Preparation
>> ---
>>
>> You may want to spare your users the burden of modifying the  
>> global VM
>> installation. OSX has several different VM versions installed by
>> default and
>> regular users will be unable to figure out which version will load  
>> your
>> application.
>>
>> If you provide the class
>>
>> package com.sun.comm;
>> public class SolarisDriver extends gnu.io.RXTXCommDriver {
>> }
>>
>> and make sure, that it is present in the classpath before Suns
>> "generic" comm.jar
>> your users can skip the following step:
>
> Hi Joachim
>
> With regards to the above, I have not seen that we have Sun's OK to
> promote that.  I'm not very comfortable with the distribution
> documentation advocating this without Sun agreeing.
>
> I see your point but I'd rather not actively promote putting  
> classes in
> Sun's namespace without permission if you don't mind.  This isn't  
> about
> what is in a license.
>
> I'll go through the code tomorrow night.  It was a late night at work
> today.  There is also a w32 fix comming for people opening and closing
> multiple ports.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Wed Jun 21 02:03:33 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 21 Jun 2006 10:03:33 +0200
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
	<6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
Message-ID: <BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>

See System.load(String) [it's also mentioned under the URL you posted].

Regards,
Joachim


On 20.06.2006, at 18:23, Brian Schlining wrote:

> So how do you use it to dynamically load a native lib? I've read  
> that you can't really modify the java.library.path after the JVM  
> has been launched. (http://forum.java.sun.com/thread.jspa? 
> threadID=627890&tstart=90)
>
> Thanks
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From baris.ozkan at elikasu.com.tr  Wed Jun 21 07:58:06 2006
From: baris.ozkan at elikasu.com.tr (Baris)
Date: Wed, 21 Jun 2006 16:58:06 +0300
Subject: [Rxtx] RS 232 ..additional parameters
Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>

Hi,
 
Currently i am developing an application that requires to connect to a
remote rs232 device through  a dialup connection.
 
My problem is that the communication needs several more connection
parameters (i extracted that information from the vendor's dll , listed at
the end of the message)
 
I explored rxtx API and src files and could not find methods to set a
majority  of the parameters.
Am i missing any point or does rxtx is limited to soem standard set of
functionality(e.g. commAPI)? How  is it possible ,if i want to put some
extensions(???) to current rxtx implementation?
 
I am not very good at rs232 programming so excuse me if this message  is
boring one.
 
Thanx
 
Baris Ozkan
 
 
A Listing of Parameters:
 
 
typedef struct _DCB {

DWORD DCBlength; /* sizeof(DCB) */

DWORD BaudRate; /* Baudrate at which running */

DWORD fBinary: 1; /* Binary Mode (skip EOF check) */

DWORD fParity: 1; /* Enable parity checking */

DWORD fOutxCtsFlow:1; /* CTS handshaking on output */

DWORD fOutxDsrFlow:1; /* DSR handshaking on output */

DWORD fDtrControl:2; /* DTR Flow control */

DWORD fDsrSensitivity:1; /* DSR Sensitivity */

DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */

DWORD fOutX: 1; /* Enable output X-ON/X-OFF */

DWORD fInX: 1; /* Enable input X-ON/X-OFF */

DWORD fErrorChar: 1; /* Enable Err Replacement */

DWORD fNull: 1; /* Enable Null stripping */

DWORD fRtsControl:2; /* Rts Flow control */

DWORD fAbortOnError:1; /* Abort all reads and writes on Error */

DWORD fDummy2:17; /* Reserved */

WORD wReserved; /* Not currently used */

WORD XonLim; /* Transmit X-ON threshold */

WORD XoffLim; /* Transmit X-OFF threshold */

BYTE ByteSize; /* Number of bits/byte, 4-8 */

BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */

BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */

char XonChar; /* Tx and Rx X-ON character */

char XoffChar; /* Tx and Rx X-OFF character */

char ErrorChar; /* Error replacement char */

char EofChar; /* End of Input character */

char EvtChar; /* Received Event character */

WORD wReserved1; /* Fill for now. */

} DCB, *LPDCB;

typedef struct _COMMTIMEOUTS {

DWORD ReadIntervalTimeout; /* Maximum time between read chars. */

DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */

DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */

DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */

DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */

} COMMTIMEOUTS,*LPCOMMTIMEOUTS;

dcb.fOutX = FALSE;

dcb.fInX = FALSE;

dcb.fOutxCtsFlow = FALSE;

dcb.fBinary = TRUE;

dcb.fRtsControl = RTS_CONTROL_ENABLE;

SetCommState(hComm , &dcb ); 

COMMTIMEOUTS commTimeOut;

GetCommTimeouts(hComm, &commTimeOut );

commTimeOut.WriteTotalTimeoutMultiplier = 1; 

commTimeOut.WriteTotalTimeoutConstant = 18; 

// commTimeOut.ReadIntervalTimeout = 28; 

commTimeOut.ReadIntervalTimeout = 0; 

// commTimeOut.ReadTotalTimeoutMultiplier = 184; 

commTimeOut.ReadTotalTimeoutMultiplier = 300; 

// commTimeOut.ReadTotalTimeoutConstant = 1200;

commTimeOut.ReadTotalTimeoutConstant = 1200;

SetCommTimeouts(hComm, &commTimeOut);

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0009.html

From ajmas at sympatico.ca  Wed Jun 21 08:14:26 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Wed, 21 Jun 2006 10:14:26 -0400
Subject: [Rxtx] When is 2.18 planned for?
Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

Just curious as to know if there is a target date for 2.18?

Andre



From brian at mbari.org  Wed Jun 21 09:36:00 2006
From: brian at mbari.org (Brian Schlining)
Date: Wed, 21 Jun 2006 08:36:00 -0700
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
	<6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
	<BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>
Message-ID: <A21C9BC0-7894-4B08-AC82-44E11AB3D461@mbari.org>

Ha!!

I suppose I should read my own postings. ;-)

Thanks
B

On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote:

> See System.load(String) [it's also mentioned under the URL you  
> posted].
>
> Regards,
> Joachim
>
>
> On 20.06.2006, at 18:23, Brian Schlining wrote:
>
>> So how do you use it to dynamically load a native lib? I've read
>> that you can't really modify the java.library.path after the JVM
>> has been launched. (http://forum.java.sun.com/thread.jspa?
>> threadID=627890&tstart=90)

Brian Schlining
Software Engineer
http://www.mbari.org




From ajmas at sympatico.ca  Wed Jun 21 16:41:28 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Wed, 21 Jun 2006 18:41:28 -0400
Subject: [Rxtx] CVS build question
Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X:

 The JCL extension to RxTx requires comm.jar
 If you intend to use RxTx for commapi support comm.jar
 needs to be located in  /System/Library/Frameworks/JavaVM.framework/
  Versions/1.5/Home/lib/ext/comm.jar

I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me.

On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native).

Andre






From tjarvi at qbang.org  Wed Jun 21 18:00:04 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT)
Subject: [Rxtx] CVS build question
In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606211756310.14139@www>

On Wed, 21 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> Is the CVS repository meant to build for gnu.io or javax.comm? I ask 
> this, because I see the following when calling ./configure from MacOS X:
>
> The JCL extension to RxTx requires comm.jar
> If you intend to use RxTx for commapi support comm.jar
> needs to be located in  /System/Library/Frameworks/JavaVM.framework/
>  Versions/1.5/Home/lib/ext/comm.jar
>
> I am wanting to build for the gnu.io package, since I want to jump ahead 
> and see if the changes, intended for 2.18 for MacOS X, work for me.
>
> On a side note /Library/Java/Extensions should be included as a valid 
> search path for the JAR, since this is where Apple recommends placing 
> third party extensions (both Java and native).
>

rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel"
rxtx 2.0 src is obtained with "cvs checkout rxtx-devel"

rxtx 2.1 is a complete package in namespace gnu.io
rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 18:02:23 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT)
Subject: [Rxtx] When is 2.18 planned for?
In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606211800180.14139@www>

On Wed, 21 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> Just curious as to know if there is a target date for 2.18?
>

Hi Andre

"When it is ready" :)

Probably this weekend.  Maybe sooner.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 18:10:18 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT)
Subject: [Rxtx] RS 232 ..additional parameters
In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>
References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>
Message-ID: <Pine.LNX.4.61.0606211805010.14139@www>

On Wed, 21 Jun 2006, Baris wrote:

> Hi,
>
> Currently i am developing an application that requires to connect to a
> remote rs232 device through  a dialup connection.
>
> My problem is that the communication needs several more connection
> parameters (i extracted that information from the vendor's dll , listed at
> the end of the message)
>
> I explored rxtx API and src files and could not find methods to set a
> majority  of the parameters.
> Am i missing any point or does rxtx is limited to soem standard set of
> functionality(e.g. commAPI)? How  is it possible ,if i want to put some
> extensions(???) to current rxtx implementation?
>
> I am not very good at rs232 programming so excuse me if this message  is
> boring one.
>
> Thanx
>

Hi Baris

> typedef struct _DCB {
> typedef struct _COMMTIMEOUTS {

These are all handled in termios.c.  It is possible to add extensions to 
rxtx 2.1.  It may well be that the defaults are the same for the variables 
not covered by the existing API.  You can dump the DCB and COMMTIMEOUTS 
from inside termios.c to compare.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 20:23:30 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT)
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
	<Pine.LNX.4.61.0606202127270.14139@www>
	<789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>
Message-ID: <Pine.LNX.4.61.0606212012210.14139@www>

> I'm
> not thrilled but OK with the current API. Hence I dont agree with
> Paul's idea to start a new JSR to fix the implementation - but that's
> mainly because I dont have the time to push it. According to their
> Readme Sun sees no business case in having cross platform support for
> javax.comm - that is sad but it's none of my business. However I
> prefer to program versus javax.comm in my projects as this gives an
> advanced user the chance to exchange the provider without access to
> the code.

Hi Joachim

With regards to the JSR, I think that would be Doug's call.  The effort I 
put in would have to be on my own time which would not be a great deal.  I 
could help things go smoothly but thats not the same as pushing something 
through.

--
Trent Jarvi
tjarvi at qbang.org



From vt at freehold.crocodile.org  Wed Jun 21 21:05:22 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Wed, 21 Jun 2006 20:05:22 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
Message-ID: <449A08F2.3020106@freehold.crocodile.org>

Hello all,

I know this question may belong to JSR lists, but since all interested 
parties are here, I thought I just ask this question here, again...

A while ago I run into a problem and wrote a rant, here: 
http://servomaster.sourceforge.net/dev/serial-usb.html
At the time of writing I didn't think of adding another possible 
solution - changing the CommAPI specs to support removable devices. 
Apparently, Serial/USB bridges are here to stay, and this issue has to 
be addressed.

Wonder if anything changed since, and any abstractions for supporting 
removable devices made it into current or future Java CommAPI drafts - 
Paul, any comments?

--vt



From joachim at buechse.de  Thu Jun 22 01:59:54 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 22 Jun 2006 09:59:54 +0200
Subject: [Rxtx] CVS build question
In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de>

Hello Andre,

I am not sure how well the configure/make mechanism will work on OSX.  
I know that a while ago some contributors tried to get configure/make  
working on OSX but from comments I found in the readmes this work was  
only partially successfull. For compilation on OSX we have used the  
ProjectBuilder/XCode projects you can find in MACOSX_IDE.

Regarding the  ./configure comment:
RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config  
file javax.comm.properties. The later MUST reside in {java.home}/lib.  
As the two only work together putting comm.jar into  /Library/Java/ 
Extensions  and hence making it available to all current and future  
VM installations will only add to confusion.

Regards,
Joachim

On 22.06.2006, at 00:41, Andre-John Mas wrote:

> Hi,
>
> Is the CVS repository meant to build for gnu.io or javax.comm? I  
> ask this, because I see the following when calling ./configure from  
> MacOS X:
>
>  The JCL extension to RxTx requires comm.jar
>  If you intend to use RxTx for commapi support comm.jar
>  needs to be located in  /System/Library/Frameworks/JavaVM.framework/
>   Versions/1.5/Home/lib/ext/comm.jar
>
> I am wanting to build for the gnu.io package, since I want to jump  
> ahead and see if the changes, intended for 2.18 for MacOS X, work  
> for me.
>
> On a side note /Library/Java/Extensions should be included as a  
> valid search path for the JAR, since this is where Apple recommends  
> placing third party extensions (both Java and native).
>
> Andre
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Thu Jun 22 02:51:05 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 22 Jun 2006 10:51:05 +0200
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449A08F2.3020106@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>

Hello Vadim,

I think that your rant is to the point. However it is a bit like  
saying that Windows is at the source of email degradation and the  
only solution is to have users switch to safer operating systems.

I don't see how javax.comm or RXTX can address the problems you  
mention. Of course it would be super cool if javax.comm could magicly  
find the "matching" usb-device and query it's configuration via the  
usb protocol - however this magic (mapping /dev/xyz to its underlying  
USB device) is not supported by any kernel APIs I am aware of. It  
could be supported via POSSIX ioctl calls but then you should address  
your rant to the POSSIX group...

So for the time beeing it's either up to the virtual comm port driver  
to provide a usefull name under /dev/ or to the user choosing the  
right port to use. One example of a smart(er) com port driver is the  
KDDI driver for OSX, which will create device names like "/dev/ 
cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- 
encoded into the bridge chip. The same driver for windows also has  
some options allowing it in theory to recreate the same COMx every  
time a device is plugged/unplugged.

For most industrial applications however it will be up to the user to  
choose the right port (without getting a lot of help doing so).

Probing serial ports can go wrong, that's right. However any serial  
device developper would be well adviced to implement a basic set of  
Hayes AT modem commands (be it a modem or not). Especially AT I0.  
Anyone failing to do so risks that the users favourite TCP/PPP/FAX  
application or stack will kill the device in short time.

Best regards,
Joachim


On 22.06.2006, at 05:05, Vadim Tkachenko wrote:

> Hello all,
>
> I know this question may belong to JSR lists, but since all interested
> parties are here, I thought I just ask this question here, again...
>
> A while ago I run into a problem and wrote a rant, here:
> http://servomaster.sourceforge.net/dev/serial-usb.html
> At the time of writing I didn't think of adding another possible
> solution - changing the CommAPI specs to support removable devices.
> Apparently, Serial/USB bridges are here to stay, and this issue has to
> be addressed.
>
> Wonder if anything changed since, and any abstractions for supporting
> removable devices made it into current or future Java CommAPI drafts -
> Paul, any comments?
>
> --vt
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From vt at freehold.crocodile.org  Thu Jun 22 13:16:03 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 12:16:03 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
Message-ID: <20060622191603.GA17487@freehold.crocodile.org>

Hello Joachim,

> I think that your rant is to the point. However it is a bit like  
> saying that Windows is at the source of email degradation and the  
> only solution is to have users switch to safer operating systems.

I guess the problem is that the rant itself is obsolete and has to be
updated according to latest developments. At the time of writing there
weren't that many bridges around, and the trend didn't manifest itself as it
does now.

> I don't see how javax.comm or RXTX can address the problems you  
> mention.

I would agree that javax.comm won't be able to address the problem, at least
in the short run. As for RxTx - well, nobody prevents it from being a
superset of CommAPI specification, right? RxTx being the de-facto standard
for quite a few platforms, I'd daresay the standard may follow.

> Of course it would be super cool if javax.comm could magicly find the
> "matching" usb-device and query it's configuration via the usb protocol -
> however this magic (mapping /dev/xyz to its underlying USB device) is not
> supported by any kernel APIs I am aware of. It could be supported via
> POSSIX ioctl calls but then you should address your rant to the POSSIX
> group...

As a matter of fact, my bigger concern is addressing the fact that a serial
device can now be removable. This hasn't been the case before, and it
clearly is now. Regarding the above, well, I guess if we accept this fact,
we also need to accept the fact that we need at least rudimentary means of
identification of a serial device. For the USB case, it would usually be the
vendor/product ID, plus possible serial number - but it is irrelevant what
exactly the identifying information is, as long as it allows to identify the
device.

A paradigm shift is required, this is what I wanted to say. Serial devices
can be removed and replaced, it's now our turn to learn to deal with it.

> Joachim

--vt


From jredman at ergotech.com  Thu Jun 22 13:41:44 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 13:41:44 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
Message-ID: <449AF278.6000903@ergotech.com>


Vadim Tkachenko wrote:
> A paradigm shift is required, this is what I wanted to say. Serial devices
> can be removed and replaced, it's now our turn to learn to deal with it.

The removal if the serial port hardly significantly different from the 
removal of the device attached to the serial port.   Different, 
slightly, but not a "paradigm shift".

And yes, someone could unplug a USB serial device and plug it into a 
different USB port so that it has a different name/number, but they 
could do that with the device itself, move it from com1 to com2.

Am I missing something?

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 13:57:27 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 12:57:27 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449AF278.6000903@ergotech.com>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
Message-ID: <20060622195727.GA20247@freehold.crocodile.org>

On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote:
> 
> Vadim Tkachenko wrote:
> > A paradigm shift is required, this is what I wanted to say. Serial devices
> > can be removed and replaced, it's now our turn to learn to deal with it.
> 
> The removal if the serial port hardly significantly different from the 
> removal of the device attached to the serial port.   Different, 
> slightly, but not a "paradigm shift".
> 
> And yes, someone could unplug a USB serial device and plug it into a 
> different USB port so that it has a different name/number, but they 
> could do that with the device itself, move it from com1 to com2.
> 
> Am I missing something?

Yes, the fact that they could unplug a device A and plug a device B. With
the introduction of the concept of removability, the notion of the serial
port itself is not as important anymore, but the notion of the unique device
identifier is.

Consider a situation: long running system (enterprise HVAC, tens of nodes,
tens of thousands square feet area, hundreds of thousand dollars worth of
equipment being conditioned, can't shut down), serial/usb device fails, is
replaced by an identical device with a different serial #.

A little bit farfetched, but hopefully highlighting the point I'm trying to
make.

> Jim

--vt


From jredman at ergotech.com  Thu Jun 22 14:37:38 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 14:37:38 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>	<20060622191603.GA17487@freehold.crocodile.org>	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
Message-ID: <449AFF92.8080003@ergotech.com>


Vadim Tkachenko wrote:
>>
>> Am I missing something?
> 
> Yes, the fact that they could unplug a device A and plug a device B. With
> the introduction of the concept of removability, the notion of the serial
> port itself is not as important anymore, but the notion of the unique device
> identifier is.

Serial devices are always removable.  I could unplug _serial_ device A 
and plug in _serial_ device B.  We have systems running with two RS485 
ports, one talks to a Modbus PLC network one to a number of drives on a 
proprietary protocol.  If you plug the wrong DB9 into the wrong port the 
application doesn't work.

If you dangle a USB 485 converter on the end of the DB9 you've just 
moved the problem from RS485 to USB, but the problem/effect is the same.

> 
> Consider a situation: long running system (enterprise HVAC, tens of nodes,
> tens of thousands square feet area, hundreds of thousand dollars worth of
> equipment being conditioned, can't shut down), serial/usb device fails, is
> replaced by an identical device with a different serial #.
> 
> A little bit farfetched, but hopefully highlighting the point I'm trying to
> make.

Nothing's changed.  If I had a 4 port ISA board and plugged it into my 
new shiny '386 machine.  I could have com ports 9-12.  If I took a board 
off the shelf and didn't set the jumpers, I would have com ports 3-6.

The problem's the same.  If you replace with identical product then the 
com ports  will be the same - no software changes required.  If you 
replace one piece of hardware with hardware from a different 
manufacturer, then the naming/numbering may change.  You're physically 
changing the system, so may reasonably expect to have to make a software 
change.  RXTX actually handles this situation quite well with the -D 
command line option.  (My experience has generally been that the port 
number depends more on the USB port used than the hardware - so the 
chances are even with a hardware change the port number/name will be the 
same.)

Slightly Off Topic - there is a reason why industrial users will pay a 
premium for continued availability of hardware.  Yes you can mail-order 
a $10 USB converter and it will work, but there's no guarantee that the 
next time you buy the same part number from the same vendor it will be 
the same.  The industrial vendors will charge you $100+ for the same 
item, but it will be the same every time you buy it for the next 5 to 10 
years.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 14:37:19 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 13:37:19 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
Message-ID: <20060622203719.GA22521@freehold.crocodile.org>

Hello again,

And while I'm at it, why don't just say this: give me one good reason to
write 3+ different ways of handling removable devices, one for USB, one for
FireWire, one for serial...

I understand very well that this goes way beyond the scope of RxTx and
CommAPI and will require cooperation between them and javax.usb and whatever
JSR is responsible for FireWire implementation - but the end result is well
worth it. Abstract out and generalize arrival/departure/monitoring/discovery
API, provide protocol specific extensions for each, live happily ever after.

--vt


On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote:
> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote:
> > 
> > Vadim Tkachenko wrote:
> > > A paradigm shift is required, this is what I wanted to say. Serial devices
> > > can be removed and replaced, it's now our turn to learn to deal with it.
> > 
> > The removal if the serial port hardly significantly different from the 
> > removal of the device attached to the serial port.   Different, 
> > slightly, but not a "paradigm shift".
> > 
> > And yes, someone could unplug a USB serial device and plug it into a 
> > different USB port so that it has a different name/number, but they 
> > could do that with the device itself, move it from com1 to com2.
> > 
> > Am I missing something?
> 
> Yes, the fact that they could unplug a device A and plug a device B. With
> the introduction of the concept of removability, the notion of the serial
> port itself is not as important anymore, but the notion of the unique device
> identifier is.
> 
> Consider a situation: long running system (enterprise HVAC, tens of nodes,
> tens of thousands square feet area, hundreds of thousand dollars worth of
> equipment being conditioned, can't shut down), serial/usb device fails, is
> replaced by an identical device with a different serial #.
> 
> A little bit farfetched, but hopefully highlighting the point I'm trying to
> make.
> 
> > Jim
> 
> --vt
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx


From jredman at ergotech.com  Thu Jun 22 15:13:49 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 15:13:49 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>	<20060622191603.GA17487@freehold.crocodile.org>	<449AF278.6000903@ergotech.com>	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
Message-ID: <449B080D.9080208@ergotech.com>


Vadim Tkachenko wrote:
> Hello again,
> 
> And while I'm at it, why don't just say this: give me one good reason to
> write 3+ different ways of handling removable devices, one for USB, one for
> FireWire, one for serial...

You don't, they're all the same "I have lost communication with my 
serial device".

The only thing you could really do is improve error reporting by knowing 
the exact sub-system.  ("Device X which is/was attached to USB port Y is 
no longer functioning, please check the USB ports, the device, the 
cables and anything else you can think of that may be a cause of 
failure.")  That just requires an intelligent description of the port.

> I understand very well that this goes way beyond the scope of RxTx and
> CommAPI and will require cooperation between them and javax.usb and whatever
> JSR is responsible for FireWire implementation - but the end result is well
> worth it. Abstract out and generalize arrival/departure/monitoring/discovery
> API, provide protocol specific extensions for each, live happily ever after.

There's a huge list of pseudo-serial devices each with a different set 
of requirements, Bluetooth, RFC 2217, a host of proprietary systems, 
etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I 
have no clue how you'd implement them in a general/cross platform sense.

You haven't convinced me (and only me, others may see something that I 
don't, I'm not speaking for them) that this mechanism can be implemented 
in any practical sense.  That is, that the implementation could be wide 
enough to be consider generally available in RXTX regardless of the 
serial port implementation, platform, etc..  However, if you can come up 
with a general design and a reference implementation for one subsystem, 
I'd like to see it and might get on board.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 15:40:55 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 14:40:55 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449B080D.9080208@ergotech.com>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
Message-ID: <20060622214055.GA25497@freehold.crocodile.org>

On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote:
> 
> Vadim Tkachenko wrote:
> > Hello again,
> > 
> > And while I'm at it, why don't just say this: give me one good reason to
> > write 3+ different ways of handling removable devices, one for USB, one for
> > FireWire, one for serial...
> 
> You don't, they're all the same "I have lost communication with my 
> serial device".

"I have lost communication with my ${protocol} device".

> The only thing you could really do is improve error reporting by knowing 
> the exact sub-system.  ("Device X which is/was attached to USB port Y is 
> no longer functioning, please check the USB ports, the device, the 
> cables and anything else you can think of that may be a cause of 
> failure.")

"Device ${id} which is/was attached to ${protocol} port ${port} is no longer
functioning, please check the ${protocol} ports, the device, the
${protocol_media} and anything else you can think of that may be a cause of
failure".

>  That just requires an intelligent description of the port.

Agree absolutely.

> > I understand very well that this goes way beyond the scope of RxTx and
> > CommAPI and will require cooperation between them and javax.usb and whatever
> > JSR is responsible for FireWire implementation - but the end result is well
> > worth it. Abstract out and generalize arrival/departure/monitoring/discovery
> > API, provide protocol specific extensions for each, live happily ever after.
> 
> There's a huge list of pseudo-serial devices each with a different set 
> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, 
> etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I 
> have no clue how you'd implement them in a general/cross platform sense.

That's because some of the protocols were created decades ago when
autoconfiguration wasn't even conceived, much less practical. RS232/RS485
don't have a clue about identity discovery, and even capabilities discovery
beyond obvious 8N1 etc.

I agree that today all these protocols have generally incompatible
strategies for handling the situations I'm trying to address, but there's
nothing that says it's not an oversight. Besides, we're dealing with the
devices at a level of abstraction that allows some simplifications and
generalizations, at least part of the time - unless it's the protocol
specific features we're dealing with.

> You haven't convinced me (and only me, others may see something that I 
> don't, I'm not speaking for them) that this mechanism can be implemented 
> in any practical sense.  That is, that the implementation could be wide 
> enough to be consider generally available in RXTX regardless of the 
> serial port implementation, platform, etc..  However, if you can come up 
> with a general design and a reference implementation for one subsystem, 
> I'd like to see it and might get on board.

Actually, I wasn't even thinking about all this stuff when I wrote the first
message on the subject :) Now that you mention it - well, I'm not sure I can
chew the piece I just tried to bite in reasonable amount of time.

How do you eat an elephant? One bite at a time. If we could agree that a
small step in the specification is acceptable at this time, and express
further intentions, things may start happening.

To put it succinctly:

- Concept of a "port" should be augmented with a concept of a "device". A
device may be attached to a port in an implicit or explicit way.
- Implicitly connected device is exactly what the current scope of the
specification covers. No new functionality is offered.
- Explicitly connected device supports detachable device semantics, just as
other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a
few).
- The input and output streams are not properties of a port now, but
properties of the device attached to the port.
- A mechanism to allow listening for device arrivals and departures must be
made available.

That's it, off the top of my head.

I understand that this goes completely against current javax.comm specs, but
an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be
difficult to implement without disrupting javax.comm compatibility.

One concern is how to deal with the device identity - but there's no general
way of dealing with this at this time, devices may or may not offer identity
discovery.

> Jim

--vt


From joachim at buechse.de  Fri Jun 23 02:12:43 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 23 Jun 2006 10:12:43 +0200
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
Message-ID: <CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>

Hello++ Vadim,

I would like to repeat that your request is best addressed to the  
POSSIX standardization group - or maybe the BSD/Linux maintainers. If  
you convince the BSD or Linux guys to add this kind of functionality  
(they can as most of there VCP drivers are open source), there is a  
certain chance that other vendors will pick it up. I assure you that  
RXTX will happily provide this functionality once it's possible - I'm  
sure there is more than one maintainer that would love to add it.  
Having this concept penetrate the market may take some years though.

SHORT: The solution you would like to see could be added to the API  
but it can not be implemented (at least not on the platforms I know).  
There are currently no hooks in the kernel that allow you to discover  
"the device" or even the "means of connection" based on an existing  
"device file descriptor" ie COM-port or /dev/... entry. The name  
mapping of the device is handled by the virtual com port driver of  
the device. Unless you are suggesting RXTX should reimplement virtual  
com port drivers for all usb/serial bridges out there your request is  
understandable from a users viewpoint but simply not realizable. It's  
like asking that the Socket api should identify the computer behind  
an IP address (ie by its Ethernet address). While this COULD be  
implemented in TCP/IP, it IS not, and hence there is no point adding  
such a function to the Socket API.

The current trend for USB/Bluetooth/Irda/etc connected devices is  
going away from serial port abstraction towards RPC (ie the drivers  
provide a device specific or device class specific driver that  
provides an application level api to the device functions). The line  
level protocol is often not even published.

Best regards,
Joachim

On 22.06.2006, at 23:40, Vadim Tkachenko wrote:

> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote:
>>
>> Vadim Tkachenko wrote:
>>> Hello again,
>>>
>>> And while I'm at it, why don't just say this: give me one good  
>>> reason to
>>> write 3+ different ways of handling removable devices, one for  
>>> USB, one for
>>> FireWire, one for serial...
>>
>> You don't, they're all the same "I have lost communication with my
>> serial device".
>
> "I have lost communication with my ${protocol} device".
>
>> The only thing you could really do is improve error reporting by  
>> knowing
>> the exact sub-system.  ("Device X which is/was attached to USB  
>> port Y is
>> no longer functioning, please check the USB ports, the device, the
>> cables and anything else you can think of that may be a cause of
>> failure.")
>
> "Device ${id} which is/was attached to ${protocol} port ${port} is  
> no longer
> functioning, please check the ${protocol} ports, the device, the
> ${protocol_media} and anything else you can think of that may be a  
> cause of
> failure".
>
>>  That just requires an intelligent description of the port.
>
> Agree absolutely.
>
>>> I understand very well that this goes way beyond the scope of  
>>> RxTx and
>>> CommAPI and will require cooperation between them and javax.usb  
>>> and whatever
>>> JSR is responsible for FireWire implementation - but the end  
>>> result is well
>>> worth it. Abstract out and generalize arrival/departure/ 
>>> monitoring/discovery
>>> API, provide protocol specific extensions for each, live happily  
>>> ever after.
>>
>> There's a huge list of pseudo-serial devices each with a different  
>> set
>> of requirements, Bluetooth, RFC 2217, a host of proprietary systems,
>> etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I
>> have no clue how you'd implement them in a general/cross platform  
>> sense.
>
> That's because some of the protocols were created decades ago when
> autoconfiguration wasn't even conceived, much less practical. RS232/ 
> RS485
> don't have a clue about identity discovery, and even capabilities  
> discovery
> beyond obvious 8N1 etc.
>
> I agree that today all these protocols have generally incompatible
> strategies for handling the situations I'm trying to address, but  
> there's
> nothing that says it's not an oversight. Besides, we're dealing  
> with the
> devices at a level of abstraction that allows some simplifications and
> generalizations, at least part of the time - unless it's the protocol
> specific features we're dealing with.
>
>> You haven't convinced me (and only me, others may see something  
>> that I
>> don't, I'm not speaking for them) that this mechanism can be  
>> implemented
>> in any practical sense.  That is, that the implementation could be  
>> wide
>> enough to be consider generally available in RXTX regardless of the
>> serial port implementation, platform, etc..  However, if you can  
>> come up
>> with a general design and a reference implementation for one  
>> subsystem,
>> I'd like to see it and might get on board.
>
> Actually, I wasn't even thinking about all this stuff when I wrote  
> the first
> message on the subject :) Now that you mention it - well, I'm not  
> sure I can
> chew the piece I just tried to bite in reasonable amount of time.
>
> How do you eat an elephant? One bite at a time. If we could agree  
> that a
> small step in the specification is acceptable at this time, and  
> express
> further intentions, things may start happening.
>
> To put it succinctly:
>
> - Concept of a "port" should be augmented with a concept of a  
> "device". A
> device may be attached to a port in an implicit or explicit way.
> - Implicitly connected device is exactly what the current scope of the
> specification covers. No new functionality is offered.
> - Explicitly connected device supports detachable device semantics,  
> just as
> other protocols do (USB, FireWire, Wireless USB, Bluetooth, to  
> mention a
> few).
> - The input and output streams are not properties of a port now, but
> properties of the device attached to the port.
> - A mechanism to allow listening for device arrivals and departures  
> must be
> made available.
>
> That's it, off the top of my head.
>
> I understand that this goes completely against current javax.comm  
> specs, but
> an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern )  
> won't be
> difficult to implement without disrupting javax.comm compatibility.
>
> One concern is how to deal with the device identity - but there's  
> no general
> way of dealing with this at this time, devices may or may not offer  
> identity
> discovery.
>
>> Jim
>
> --vt
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From vt at freehold.crocodile.org  Fri Jun 23 11:28:29 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Fri, 23 Jun 2006 10:28:29 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
	<CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
Message-ID: <20060623172829.GA5335@freehold.crocodile.org>

Hello Joachim,

> I would like to repeat that your request is best addressed to the POSSIX
> standardization group - or maybe the BSD/Linux maintainers. If you
> convince the BSD or Linux guys to add this kind of functionality (they can
> as most of there VCP drivers are open source), there is a certain chance
> that other vendors will pick it up. I assure you that RXTX will happily
> provide this functionality once it's possible - I'm sure there is more
> than one maintainer that would love to add it.

I realize this thing is bigger than RxTx itself, and I'm afraid it's too
global not to cause people to laugh before they think about it :)

> Having this concept penetrate the market may take some years though.

Well, I'm sure it'll get there, the only question is - when.

> SHORT: The solution you would like to see could be added to the API but it
> can not be implemented (at least not on the platforms I know).

I guess I'm concerned about the abstraction more than I'm concerned about
the implementation at this point.
  
> There are currently no hooks in the kernel that allow you to discover  
> "the device" or even the "means of connection" based on an existing  
> "device file descriptor" ie COM-port or /dev/... entry.

Well, I'm not so sure you need to keep the literal mapping from /dev
namespace to your device namespace. As long as you can consistently offer a
virtual serial device on top of a virtual serial port, it may be irrelevant
whether you can map it into /dev. The mapping is going be schitzofrenic
anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the
representation...

> The name mapping of the device is handled by the virtual com port driver
> of the device. Unless you are suggesting RXTX should reimplement virtual
> com port drivers for all usb/serial bridges out there your request is
> understandable from a users viewpoint but simply not realizable.

It's not so much a request but rather an offer of participation. I run a few
projects actively using serial communications, as well as USB device
drivers, in different degrees of readiness (Servomaster, Haywire, DIY
Zoning) - and it would be a perfect playground.

You mentioned above that this task is about two things: a) abstraction b)
implementation. I could start the abstraction part of it without changing
the current CommAPI, on top of it, as an adapter. Even if the removable
device semantics are not implemented, but offered, this is already a step
forward.

> It's like asking that the Socket api should identify the computer behind
> an IP address (ie by its Ethernet address). While this COULD be
> implemented in TCP/IP, it IS not, and hence there is no point adding such
> a function to the Socket API.

Thank you for bringing up this example - I guess this is just about the same
thing that I'd like to see. Socket transparently provides you with the
input/output streams, at the same time offering protocol level specifics to
you.

> The current trend for USB/Bluetooth/Irda/etc connected devices is going
> away from serial port abstraction towards RPC (ie the drivers provide a
> device specific or device class specific driver that provides an
> application level api to the device functions). The line level protocol is
> often not even published.

I can't say I'm that happy with it. The best (or, rather, worst) example is
suchlike support for the Phidget servo controller - zealous Linux developers
implemented kernel module support for it, completely hijacking a possibility
of using it on a different level (it's somewhat fixed by now, thankfully).

I believe that whenever an abstraction is offered, it must be made optional
and/or pluggable so it can be replaced by something more suited to the task.

The nature of Java applications is such that they'd probably care much more
about Java API offered, than about no matter how rich application level api
that is offered outside of Java. I've dealt with JNI adapters in the past,
and whereas they can be made reasonably stable, the very fact that you are
forced to deal with things that are not on the critical timing/memory path
and could've been done much easier in Java causes endless grief.

> Joachim

--vt


From lyon at docjava.com  Sat Jun 24 04:54:12 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Sat, 24 Jun 2006 06:54:12 -0400
Subject: [Rxtx] jsr
In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
	<CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
	<20060623172829.GA5335@freehold.crocodile.org>
Message-ID: <p060204a3c0c2c9dde4f8@[192.168.1.152]>

Hi All,
I have had some off-list discussion with Trent.
Opening up a JSR with Sun, as per Peters' suggestion
seems like a reasonable idea, to us.

Does anyone having any concerns about the JSR process
that they would like to raise?

Thanks!
  - Doug



From the.grey.lantern at gmail.com  Sat Jun 24 18:15:26 2006
From: the.grey.lantern at gmail.com (Craig Nicoll)
Date: Sun, 25 Jun 2006 01:15:26 +0100
Subject: [Rxtx] Cannot create virtual serial port
Message-ID: <a1221cc50606241715g2d1e2af6r747347dd4c20e997@mail.gmail.com>

Hello,

This is my first post on this mailing list and I hope someone can help me.

I am having great difficult establishing a virtual serial port for the
Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia
7600.

Every time I try to run the SendMessage program that comes with SMSLib, I
get the following exception: gnu.io.NoSuchPortException

The port names I have tried are:
rfcomm0
rfcomm
/dev/rfcomm0
/dev/rfcomm

This is what I have done so far:
Modified /etc/bluetooth/rfcomm.conf to include the address of my phone:

rfcomm0 {
# Automatically bind the device at startup
bind no;

# Bluetooth address of the device
device 00:0e:6d:7a:98:43;

# RFCOMM channel for the connection
channel 1;

# Description of the connection
comment "Example Bluetooth device";
}

I also tried running the following command: rfcomm bind /dev/rfcomm0

I have searched the mailing list archives and found this post where someone
had a very similar problem to me:
http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried
changing the system properties as suggested and it made no difference.

I have also been scouring Google all day to no avail.

I would be incredibly grateful if anyone could give me some tips.

Thank you,

Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060625/cfa6df35/attachment.html

From tjarvi at qbang.org  Sun Jun 25 19:56:08 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT)
Subject: [Rxtx] Pending release
Message-ID: <Pine.LNX.4.61.0606251942460.15744@www>


With frustration, I was unable to get to the pending release this weekend.
The release should be comming this next week once things calm down.
The source is in CVS except for a fix for multiple ports in windows.

I had planned on doing the release this weekend but that was disrupted by 
my transportation failing in a spectacular fashion.

--
Trent Jarvi
tjarvi at qbang.org


From Pawan.Kharbanda at dot.state.co.us  Tue Jun 27 22:28:51 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 27 Jun 2006 22:28:51 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>

 Trent, 
   I have an application running in a cluster in linux environment and I
am using RXTX2.1.7 (final) with JDK1.5. The application opens and closes
serial comm ports every 30 seconds and exchanges datas. I have
experienced some of my Comm Ports are left hanging (I can see the
LCK..cufXX lock files under /var/lock folder). On putting the debugs I
found out that, it is stuck at a native call line 809 in RXTXPort.java
class (Please see the code snippet below). Can you help me explain what
this method does in the native code? Am I getting into some thread
deadlocks? Thanks in advance.

Pawan Kharbanda 


public void removeEventListener()
	{
		if (debug)
			z.reportln( "RXTXPort:removeEventListener()
called");
		waitForTheNativeCodeSilly();
		//if( monThread != null && monThread.isAlive() )
		if( monThreadisInterrupted == true )
		{
			z.reportln( "	RXTXPort:removeEventListener()
already interrupted");
			monThread = null;
			SPEventListener = null;
			return;
		}
		else if( monThread != null && monThread.isAlive() )
		{
			if (debug)
				z.reportln( "
RXTXPort:Interrupt=true");
			monThreadisInterrupted=true;
			/*
			   Notify all threads in this PID that something
is up
			   They will call back to see if its their
thread
			   using isInterrupted().
			*/
			if (debug)
				z.reportln( "	RXTXPort:calling
interruptEventLoop");
// LINE 809			interruptEventLoop( ); It never returns
out of this 
			
			if (debug)
				z.reportln( "	RXTXPort:calling
monThread.join()");
			try {
				monThread.join(1000);
			} catch (Exception ex) {
				/* yikes */
				ex.printStackTrace();
			}
			if (debug)
				z.reportln( "	RXTXPort:waiting on
isAlive()");
			while( monThread.isAlive() )
			{
				if ( debug )
					z.reportln( "	MonThread is
still alive!");
				try {
					monThread.join(1000);
					Thread.sleep( 1000 );
				} catch( Exception e ){} 
				//monThread.stop();
			}
			
		}
		if (debug)
			z.reportln( "	RXTXPort:calling gc()");
		monThread = null;
		SPEventListener = null;
		MonitorThreadLock = false;
		MonitorThreadAlive=false;
		monThreadisInterrupted=true;
		z.reportln( "RXTXPort:removeEventListener() returning");
	} 

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Sunday, June 25, 2006 7:56 PM
To: rxtx at qbang.org
Subject: [Rxtx] Pending release


With frustration, I was unable to get to the pending release this
weekend.
The release should be comming this next week once things calm down.
The source is in CVS except for a fix for multiple ports in windows.

I had planned on doing the release this weekend but that was disrupted
by my transportation failing in a spectacular fashion.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Wed Jun 28 04:17:29 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 28 Jun 2006 04:17:29 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606280406330.9561@www>



Hi Pawan

You may have found a deadlock but I've not seen on recently on linux.

If you can, please update from CVS.  This will have some close fixes. 
I'm running with the same code as is in CVS.  It is not perfect but I've 
not seen anything like you mention.  Be sure to set timeouts and 
thresholds on the port.  It may be that the port is waiting on pending io 
that never happens.  I think the CVS patches deal with this also but it 
looks like your in a better test environment to know for sure.

The exploded vehicle mentioned below is expected to be fixed today.  It 
was just a ninja small radiator hose.  The pressure test afterwards 
created its own set of problems.  Until this is resolved, I'm spending 
most of my free time commuting by bicycle.

On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>   I have an application running in a cluster in linux environment and I
> am using RXTX2.1.7 (final) with JDK1.5. The application opens and closes
> serial comm ports every 30 seconds and exchanges datas. I have
> experienced some of my Comm Ports are left hanging (I can see the
> LCK..cufXX lock files under /var/lock folder). On putting the debugs I
> found out that, it is stuck at a native call line 809 in RXTXPort.java
> class (Please see the code snippet below). Can you help me explain what
> this method does in the native code? Am I getting into some thread
> deadlocks? Thanks in advance.
>
> Pawan Kharbanda
>
>
> public void removeEventListener()
> 	{
> 		if (debug)
> 			z.reportln( "RXTXPort:removeEventListener()
> called");
> 		waitForTheNativeCodeSilly();
> 		//if( monThread != null && monThread.isAlive() )
> 		if( monThreadisInterrupted == true )
> 		{
> 			z.reportln( "	RXTXPort:removeEventListener()
> already interrupted");
> 			monThread = null;
> 			SPEventListener = null;
> 			return;
> 		}
> 		else if( monThread != null && monThread.isAlive() )
> 		{
> 			if (debug)
> 				z.reportln( "
> RXTXPort:Interrupt=true");
> 			monThreadisInterrupted=true;
> 			/*
> 			   Notify all threads in this PID that something
> is up
> 			   They will call back to see if its their
> thread
> 			   using isInterrupted().
> 			*/
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> interruptEventLoop");
> // LINE 809			interruptEventLoop( ); It never returns
> out of this
>
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> monThread.join()");
> 			try {
> 				monThread.join(1000);
> 			} catch (Exception ex) {
> 				/* yikes */
> 				ex.printStackTrace();
> 			}
> 			if (debug)
> 				z.reportln( "	RXTXPort:waiting on
> isAlive()");
> 			while( monThread.isAlive() )
> 			{
> 				if ( debug )
> 					z.reportln( "	MonThread is
> still alive!");
> 				try {
> 					monThread.join(1000);
> 					Thread.sleep( 1000 );
> 				} catch( Exception e ){}
> 				//monThread.stop();
> 			}
>
> 		}
> 		if (debug)
> 			z.reportln( "	RXTXPort:calling gc()");
> 		monThread = null;
> 		SPEventListener = null;
> 		MonitorThreadLock = false;
> 		MonitorThreadAlive=false;
> 		monThreadisInterrupted=true;
> 		z.reportln( "RXTXPort:removeEventListener() returning");
> 	}
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Sunday, June 25, 2006 7:56 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] Pending release
>
>
> With frustration, I was unable to get to the pending release this
> weekend.
> The release should be comming this next week once things calm down.
> The source is in CVS except for a fix for multiple ports in windows.
>
> I had planned on doing the release this weekend but that was disrupted
> by my transportation failing in a spectacular fashion.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From Pawan.Kharbanda at dot.state.co.us  Wed Jun 28 12:11:06 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Wed, 28 Jun 2006 12:11:06 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>

Trent,
    Again thanks for the reply. First of all I have Receive timeouts set
on all communications including Max no of bytes to expect during the
call. I have noticed the problem is during "closing the connection". I
am not sure if the RXTX is 100% thread-safe yet. There seems to be a
glitch in the native calls. I am sure I have the latest code I did the
update on the Version 2.1.7 from CVS, is this where the latest updates
are located, I have noticed another version in CVS "rxtx-devel".

Regards
Pawan Kharbanda

    

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Wednesday, June 28, 2006 4:17 AM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports



Hi Pawan

You may have found a deadlock but I've not seen on recently on linux.

If you can, please update from CVS.  This will have some close fixes. 
I'm running with the same code as is in CVS.  It is not perfect but I've
not seen anything like you mention.  Be sure to set timeouts and
thresholds on the port.  It may be that the port is waiting on pending
io that never happens.  I think the CVS patches deal with this also but
it looks like your in a better test environment to know for sure.

The exploded vehicle mentioned below is expected to be fixed today.  It
was just a ninja small radiator hose.  The pressure test afterwards
created its own set of problems.  Until this is resolved, I'm spending
most of my free time commuting by bicycle.

On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>   I have an application running in a cluster in linux environment and 
> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and 
> closes serial comm ports every 30 seconds and exchanges datas. I have 
> experienced some of my Comm Ports are left hanging (I can see the 
> LCK..cufXX lock files under /var/lock folder). On putting the debugs I

> found out that, it is stuck at a native call line 809 in RXTXPort.java

> class (Please see the code snippet below). Can you help me explain 
> what this method does in the native code? Am I getting into some 
> thread deadlocks? Thanks in advance.
>
> Pawan Kharbanda
>
>
> public void removeEventListener()
> 	{
> 		if (debug)
> 			z.reportln( "RXTXPort:removeEventListener()
called");
> 		waitForTheNativeCodeSilly();
> 		//if( monThread != null && monThread.isAlive() )
> 		if( monThreadisInterrupted == true )
> 		{
> 			z.reportln( "	RXTXPort:removeEventListener()
> already interrupted");
> 			monThread = null;
> 			SPEventListener = null;
> 			return;
> 		}
> 		else if( monThread != null && monThread.isAlive() )
> 		{
> 			if (debug)
> 				z.reportln( "
> RXTXPort:Interrupt=true");
> 			monThreadisInterrupted=true;
> 			/*
> 			   Notify all threads in this PID that something
is up
> 			   They will call back to see if its their
thread
> 			   using isInterrupted().
> 			*/
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> interruptEventLoop");
> // LINE 809			interruptEventLoop( ); It never returns
> out of this
>
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> monThread.join()");
> 			try {
> 				monThread.join(1000);
> 			} catch (Exception ex) {
> 				/* yikes */
> 				ex.printStackTrace();
> 			}
> 			if (debug)
> 				z.reportln( "	RXTXPort:waiting on
> isAlive()");
> 			while( monThread.isAlive() )
> 			{
> 				if ( debug )
> 					z.reportln( "	MonThread is
> still alive!");
> 				try {
> 					monThread.join(1000);
> 					Thread.sleep( 1000 );
> 				} catch( Exception e ){}
> 				//monThread.stop();
> 			}
>
> 		}
> 		if (debug)
> 			z.reportln( "	RXTXPort:calling gc()");
> 		monThread = null;
> 		SPEventListener = null;
> 		MonitorThreadLock = false;
> 		MonitorThreadAlive=false;
> 		monThreadisInterrupted=true;
> 		z.reportln( "RXTXPort:removeEventListener() returning");
> 	}
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf

> Of Trent Jarvi
> Sent: Sunday, June 25, 2006 7:56 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] Pending release
>
>
> With frustration, I was unable to get to the pending release this 
> weekend.
> The release should be comming this next week once things calm down.
> The source is in CVS except for a fix for multiple ports in windows.
>
> I had planned on doing the release this weekend but that was disrupted

> by my transportation failing in a spectacular fashion.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Wed Jun 28 12:26:21 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 28 Jun 2006 12:26:21 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606281222420.9561@www>


Hi Pawan

If you did a cvs update from the 2.1-7 tar ball, you have the current 
version.  All rxtx in CVS is under rxtx-devel.  The 2.1-7 just has -r
commapi-0-0-1.

You may well have found something.  I have seen win32 fail on closing 
ports but not linux that I can think of.  Your use is much different than 
I normally see too.

Could you give us more information on how we would reproduce this and the 
frequency?


On Wed, 28 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>    Again thanks for the reply. First of all I have Receive timeouts set
> on all communications including Max no of bytes to expect during the
> call. I have noticed the problem is during "closing the connection". I
> am not sure if the RXTX is 100% thread-safe yet. There seems to be a
> glitch in the native calls. I am sure I have the latest code I did the
> update on the Version 2.1.7 from CVS, is this where the latest updates
> are located, I have noticed another version in CVS "rxtx-devel".
>
> Regards
> Pawan Kharbanda
>
>
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Wednesday, June 28, 2006 4:17 AM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] Locked Ports
>
>
>
> Hi Pawan
>
> You may have found a deadlock but I've not seen on recently on linux.
>
> If you can, please update from CVS.  This will have some close fixes.
> I'm running with the same code as is in CVS.  It is not perfect but I've
> not seen anything like you mention.  Be sure to set timeouts and
> thresholds on the port.  It may be that the port is waiting on pending
> io that never happens.  I think the CVS patches deal with this also but
> it looks like your in a better test environment to know for sure.
>
> The exploded vehicle mentioned below is expected to be fixed today.  It
> was just a ninja small radiator hose.  The pressure test afterwards
> created its own set of problems.  Until this is resolved, I'm spending
> most of my free time commuting by bicycle.
>
> On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:
>
>> Trent,
>>   I have an application running in a cluster in linux environment and
>> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and
>> closes serial comm ports every 30 seconds and exchanges datas. I have
>> experienced some of my Comm Ports are left hanging (I can see the
>> LCK..cufXX lock files under /var/lock folder). On putting the debugs I
>
>> found out that, it is stuck at a native call line 809 in RXTXPort.java
>
>> class (Please see the code snippet below). Can you help me explain
>> what this method does in the native code? Am I getting into some
>> thread deadlocks? Thanks in advance.
>>
>> Pawan Kharbanda
>>
>>
>> public void removeEventListener()
>> 	{
>> 		if (debug)
>> 			z.reportln( "RXTXPort:removeEventListener()
> called");
>> 		waitForTheNativeCodeSilly();
>> 		//if( monThread != null && monThread.isAlive() )
>> 		if( monThreadisInterrupted == true )
>> 		{
>> 			z.reportln( "	RXTXPort:removeEventListener()
>> already interrupted");
>> 			monThread = null;
>> 			SPEventListener = null;
>> 			return;
>> 		}
>> 		else if( monThread != null && monThread.isAlive() )
>> 		{
>> 			if (debug)
>> 				z.reportln( "
>> RXTXPort:Interrupt=true");
>> 			monThreadisInterrupted=true;
>> 			/*
>> 			   Notify all threads in this PID that something
> is up
>> 			   They will call back to see if its their
> thread
>> 			   using isInterrupted().
>> 			*/
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> interruptEventLoop");
>> // LINE 809			interruptEventLoop( ); It never returns
>> out of this
>>
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> monThread.join()");
>> 			try {
>> 				monThread.join(1000);
>> 			} catch (Exception ex) {
>> 				/* yikes */
>> 				ex.printStackTrace();
>> 			}
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:waiting on
>> isAlive()");
>> 			while( monThread.isAlive() )
>> 			{
>> 				if ( debug )
>> 					z.reportln( "	MonThread is
>> still alive!");
>> 				try {
>> 					monThread.join(1000);
>> 					Thread.sleep( 1000 );
>> 				} catch( Exception e ){}
>> 				//monThread.stop();
>> 			}
>>
>> 		}
>> 		if (debug)
>> 			z.reportln( "	RXTXPort:calling gc()");
>> 		monThread = null;
>> 		SPEventListener = null;
>> 		MonitorThreadLock = false;
>> 		MonitorThreadAlive=false;
>> 		monThreadisInterrupted=true;
>> 		z.reportln( "RXTXPort:removeEventListener() returning");
>> 	}
>>
>> -----Original Message-----
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
>
>> Of Trent Jarvi
>> Sent: Sunday, June 25, 2006 7:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] Pending release
>>
>>
>> With frustration, I was unable to get to the pending release this
>> weekend.
>> The release should be comming this next week once things calm down.
>> The source is in CVS except for a fix for multiple ports in windows.
>>
>> I had planned on doing the release this weekend but that was disrupted
>
>> by my transportation failing in a spectacular fashion.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From Pawan.Kharbanda at dot.state.co.us  Wed Jun 28 15:42:49 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Wed, 28 Jun 2006 15:42:49 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>

Trent,
    I will try to explain how I am setup and will try to write you a
Sample code little later to reproduce this. On our system we have
DigiBoxes installed on the 2 Linux servers. Both of them have RXTX2.1-7
version installed with the JRE(1.5) and both the machines have the same
port mappings in gnu.io.rxtx.properties (Currently in the production
system I have 64 ports). This is how the system works:

1) A thick Map based client initiates a Action on the Device on the
field. One of the Thread Workers(Asynchronous Call) in the Cluster picks
up the request. 
2) Once the worker gets the request it locks the Device and
Communication port in the DB's(These are our persistent locks, because
most of the devices do one to one communication with the serial ports).
After that the worker (or Comm Server) opens up the connection and after
exchanging the information calls the "Close" and returns.
3) Once the connection is closed , the DB lock is removed on the comm
port and is made available to accept future calls. Here is where the
glitch is the Serial Comm Close method never returns due to the
deadlock. 

I have noticed that the deadlocks are very inconsistent, sometime it
happens right away as soon as Application server starts and sometimes I
don't see any deadlocks for days, but it happens for sure. 

Here is how you can test if you have resources/ test environment. Write
a program and try to open/close  different ports(I will say have a
minimum of four) randomly and very frequently(may be 30 seconds), I am
pretty sure you will see the deadlocks and it happens in the native call
to interrptEventLoop in RXTXPort.java in removeEventListener() method
call.

Also I have noticed that the JVM carshes (without any memrory errors or
JVM errors. Its just not there) when native call is made to eventLoop()
in run() method in MonitorThread inner class. I am still investigating
why this is happening, but at this point I can just tell you the
location. You might have a question How I am so sure about the location?
My application is configured with Log4J and I have enabled the debugs on
the RXTXPort.java, so every time my JVM dies I see these logs at the end
of the file.

"2006-06-28 15:27:15,183 INFO  [STDOUT] RXTXPort:RXTXPort(/dev/cub01)
called
2006-06-28 15:27:15,218 INFO  [STDOUT]
RXTXPort:MontitorThread:MonitorThread()
2006-06-28 15:27:15,219 INFO  [STDOUT] RXTXPort:MontitorThread:run()"

I surely do have a luxury of a testing environment(ports, devices etc.)
and can help you fix these problems? Please advise me how we can resolve
these issues.

Thanks 
Pawan Kharbanda
303-478-2991





-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Wednesday, June 28, 2006 12:26 PM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports


Hi Pawan

If you did a cvs update from the 2.1-7 tar ball, you have the current
version.  All rxtx in CVS is under rxtx-devel.  The 2.1-7 just has -r
commapi-0-0-1.

You may well have found something.  I have seen win32 fail on closing
ports but not linux that I can think of.  Your use is much different
than I normally see too.

Could you give us more information on how we would reproduce this and
the frequency?


On Wed, 28 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>    Again thanks for the reply. First of all I have Receive timeouts
set
> on all communications including Max no of bytes to expect during the
> call. I have noticed the problem is during "closing the connection". I
> am not sure if the RXTX is 100% thread-safe yet. There seems to be a
> glitch in the native calls. I am sure I have the latest code I did the
> update on the Version 2.1.7 from CVS, is this where the latest updates
> are located, I have noticed another version in CVS "rxtx-devel".
>
> Regards
> Pawan Kharbanda
>
>
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Wednesday, June 28, 2006 4:17 AM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] Locked Ports
>
>
>
> Hi Pawan
>
> You may have found a deadlock but I've not seen on recently on linux.
>
> If you can, please update from CVS.  This will have some close fixes.
> I'm running with the same code as is in CVS.  It is not perfect but
I've
> not seen anything like you mention.  Be sure to set timeouts and
> thresholds on the port.  It may be that the port is waiting on pending
> io that never happens.  I think the CVS patches deal with this also
but
> it looks like your in a better test environment to know for sure.
>
> The exploded vehicle mentioned below is expected to be fixed today.
It
> was just a ninja small radiator hose.  The pressure test afterwards
> created its own set of problems.  Until this is resolved, I'm spending
> most of my free time commuting by bicycle.
>
> On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:
>
>> Trent,
>>   I have an application running in a cluster in linux environment and
>> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and
>> closes serial comm ports every 30 seconds and exchanges datas. I have
>> experienced some of my Comm Ports are left hanging (I can see the
>> LCK..cufXX lock files under /var/lock folder). On putting the debugs
I
>
>> found out that, it is stuck at a native call line 809 in
RXTXPort.java
>
>> class (Please see the code snippet below). Can you help me explain
>> what this method does in the native code? Am I getting into some
>> thread deadlocks? Thanks in advance.
>>
>> Pawan Kharbanda
>>
>>
>> public void removeEventListener()
>> 	{
>> 		if (debug)
>> 			z.reportln( "RXTXPort:removeEventListener()
> called");
>> 		waitForTheNativeCodeSilly();
>> 		//if( monThread != null && monThread.isAlive() )
>> 		if( monThreadisInterrupted == true )
>> 		{
>> 			z.reportln( "	RXTXPort:removeEventListener()
>> already interrupted");
>> 			monThread = null;
>> 			SPEventListener = null;
>> 			return;
>> 		}
>> 		else if( monThread != null && monThread.isAlive() )
>> 		{
>> 			if (debug)
>> 				z.reportln( "
>> RXTXPort:Interrupt=true");
>> 			monThreadisInterrupted=true;
>> 			/*
>> 			   Notify all threads in this PID that something
> is up
>> 			   They will call back to see if its their
> thread
>> 			   using isInterrupted().
>> 			*/
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> interruptEventLoop");
>> // LINE 809			interruptEventLoop( ); It never returns
>> out of this
>>
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> monThread.join()");
>> 			try {
>> 				monThread.join(1000);
>> 			} catch (Exception ex) {
>> 				/* yikes */
>> 				ex.printStackTrace();
>> 			}
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:waiting on
>> isAlive()");
>> 			while( monThread.isAlive() )
>> 			{
>> 				if ( debug )
>> 					z.reportln( "	MonThread is
>> still alive!");
>> 				try {
>> 					monThread.join(1000);
>> 					Thread.sleep( 1000 );
>> 				} catch( Exception e ){}
>> 				//monThread.stop();
>> 			}
>>
>> 		}
>> 		if (debug)
>> 			z.reportln( "	RXTXPort:calling gc()");
>> 		monThread = null;
>> 		SPEventListener = null;
>> 		MonitorThreadLock = false;
>> 		MonitorThreadAlive=false;
>> 		monThreadisInterrupted=true;
>> 		z.reportln( "RXTXPort:removeEventListener() returning");
>> 	}
>>
>> -----Original Message-----
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On
Behalf
>
>> Of Trent Jarvi
>> Sent: Sunday, June 25, 2006 7:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] Pending release
>>
>>
>> With frustration, I was unable to get to the pending release this
>> weekend.
>> The release should be comming this next week once things calm down.
>> The source is in CVS except for a fix for multiple ports in windows.
>>
>> I had planned on doing the release this weekend but that was
disrupted
>
>> by my transportation failing in a spectacular fashion.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx 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 khattar31 at yahoo.com  Wed Jun 28 22:04:59 2006
From: khattar31 at yahoo.com (rahul khattar)
Date: Wed, 28 Jun 2006 21:04:59 -0700 (PDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
Message-ID: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>

Hi All,

I was looking at the src file on the last release.
I did notice a missing header file while trying to
compile the parallelport.dll. Would somebody be kind
enoughf to share the missing header file:
gnu_io_LPRPort.h

I am using MinGw to compile the same from Parinya
(which is an execellent tool)


Regards,
Rahul Khattar

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Thu Jun 29 03:43:53 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 03:43:53 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>
References: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606290341210.9561@www>

On Wed, 28 Jun 2006, rahul khattar wrote:

> Hi All,
>
> I was looking at the src file on the last release.
> I did notice a missing header file while trying to
> compile the parallelport.dll. Would somebody be kind
> enoughf to share the missing header file:
> gnu_io_LPRPort.h
>
> I am using MinGw to compile the same from Parinya
> (which is an execellent tool)
>

Hi Rahul

The gnu.io_LPRPort.h file is generated with javah.  You can see the 
command in the Makefile I presume.  You do not need rxtxParallel.dll to 
use w32 serial btw.

--
Trent Jarvi
tjarvi at qbang.org


From khattar31 at yahoo.com  Thu Jun 29 04:47:01 2006
From: khattar31 at yahoo.com (rahul khattar)
Date: Thu, 29 Jun 2006 03:47:01 -0700 (PDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606290341210.9561@www>
Message-ID: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>

Hi Trent 
I did notice this file is required in the source file
ParallelImp.c
on line 38

Attached the O/P 

Regards,
Rahul Khattar




--- Trent Jarvi <tjarvi at qbang.org> wrote:

> On Wed, 28 Jun 2006, rahul khattar wrote:
> 
> > Hi All,
> >
> > I was looking at the src file on the last release.
> > I did notice a missing header file while trying to
> > compile the parallelport.dll. Would somebody be
> kind
> > enoughf to share the missing header file:
> > gnu_io_LPRPort.h
> >
> > I am using MinGw to compile the same from Parinya
> > (which is an execellent tool)
> >
> 
> Hi Rahul
> 
> The gnu.io_LPRPort.h file is generated with javah. 
> You can see the 
> command in the Makefile I presume.  You do not need
> rxtxParallel.dll to 
> use w32 serial btw.
> 
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Error.zip
Type: application/x-zip-compressed
Size: 1746 bytes
Desc: 2948039066-Error.zip
Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060629/a5b6f783/Error-0009.bin

From tjarvi at qbang.org  Thu Jun 29 06:16:24 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 06:16:24 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606290614530.9561@www>

On Thu, 29 Jun 2006, rahul khattar wrote:

> Hi Trent
> I did notice this file is required in the source file
> ParallelImp.c
> on line 38
>
> Attached the O/P
>

The command to generate the .h file will be something like:

javah -classpath . -jni gnu.io.LPRPort

The makefile should have this.  There are several approaches to creating 
or using makefiles so I have no idea which one you used if any.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Thu Jun 29 06:20:51 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 06:20:51 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606290616420.9561@www>

> Here is how you can test if you have resources/ test environment. Write
> a program and try to open/close  different ports(I will say have a
> minimum of four) randomly and very frequently(may be 30 seconds), I am
> pretty sure you will see the deadlocks and it happens in the native call
> to interrptEventLoop in RXTXPort.java in removeEventListener() method
> call.

Hi Pawan

I'll try to find a way to reproduce this.  One thing to note is that you 
are using different kernel drivers (digi) to perform this task.  So I 
probably will not be able to reproduce the exact same environment.

In general, multiport kernel drivers have been tested far less than 
typical serial drivers.  This may or may not be an issue.

--
Trent Jarvi
tjarvi at qbang.org



From jhaysonn at gmail.com  Thu Jun 29 12:29:13 2006
From: jhaysonn at gmail.com (jhaysonn pathak)
Date: Thu, 29 Jun 2006 14:29:13 -0400
Subject: [Rxtx] RXTX install
Message-ID: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>

Hi Guys,

I'm doing trying to write a generative piece of Sonic Art using an EEG
plugged into a mac runnning Max/MSP.  I just recently discovered RXTX
drivers in my search for a piece of software that might give me more
output options for my EEG (I'm using the CEO from MindPeak).  I found
Bioera which uses RXTX drivers.  Thing is - I can't figure out how to
install RXTX correctly.

After I build the 'libSerial.jnilib' target inside of
'LibSerial.pbproj' I can't find the libSerial.jnilib file that
accompanies the RXTXcomm.jar nor do I know where to put them.

I also don't understand this part at the bottom of the OS X instructions at all:

"AFTER INSTALLATION VERY IMPORTANT
	check existence of the folder /var/spool/uucp
	if you don't have it create it with command
	sudo mkdir /var/spool/uucp
	permissions should be: drwxrwxr-x
	if they are not do command
	sudo chmod 775 /var/spool/uucp

	YOU should be a member of the uucp group
	you can check it with command
		niutil -readprop / /groups/uucp users
	you should see your name in output of the niutil command
	if you don't do following:
		sudo niutil -appendprop / /groups/uucp users <yourname>
			substitute  <yourname> with your user's name
			for example if your user name is peter:
				sudo niutil -appendprop / /groups/uucp users peter

	NOTES: RXTX.pkg should create uucp folder and insert your name  in
uucp group automatically"



I really appreciate any help that you guys can offer.  I've been
struggling with this for a while now as part of a research grant that
I was awarded.  Thanks again for the help.

Jhaysonn Pathak


From naranjo.manuel at gmail.com  Thu Jun 29 07:19:15 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 10:19:15 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606290614530.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www>
Message-ID: <44A3D353.6010605@gmail.com>

Speaking about Windows Support, I had seen that inside the 
rxtx-2.1-7-bins-r2 package inside Windows directory it says:
"i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will 
not make harm to anyone, and i'm almost sure that someone has noticed it 
before.
Cheers,
Manuel


From joachim at buechse.de  Thu Jun 29 13:25:16 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 29 Jun 2006 21:25:16 +0200
Subject: [Rxtx] RXTX install
In-Reply-To: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>
References: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>
Message-ID: <2A003E42-97E1-4237-8438-646BDE2E3961@buechse.de>

Hello Jhaysonn,

I assume you are trying to use the javax.comm version of RXTX.

Please use "cvs up" to update your download to the latest version of  
the repository. The latest version does not use lock files, so the  
mentioned process is no longer needed. Updating with CVS will also  
provide you with a new README.OSX file that should be simpler to  
understand.

You will find LibSerialUniversal.xcodeproj in MACOSX_IDE/Xcode. Put  
comm.jar (downloaded from Sun) into MACOSX_IDE/Xcode. Compile the  
library. You will find RXTXcomm.jar and librxtxSerial.jnilib in  
MACOSX_IDE/Xcode/build/Default

Best regards,
Joachim
---
Joachim B?chse
Softwarel?sungen und Beratung
Hadlaubsteig 2
CH-8006 Z?rich


On 29.06.2006, at 20:29, jhaysonn pathak wrote:

> Hi Guys,
>
> I'm doing trying to write a generative piece of Sonic Art using an EEG
> plugged into a mac runnning Max/MSP.  I just recently discovered RXTX
> drivers in my search for a piece of software that might give me more
> output options for my EEG (I'm using the CEO from MindPeak).  I found
> Bioera which uses RXTX drivers.  Thing is - I can't figure out how to
> install RXTX correctly.
>
> After I build the 'libSerial.jnilib' target inside of
> 'LibSerial.pbproj' I can't find the libSerial.jnilib file that
> accompanies the RXTXcomm.jar nor do I know where to put them.
>
> I also don't understand this part at the bottom of the OS X  
> instructions at all:
>
> "AFTER INSTALLATION VERY IMPORTANT
> 	check existence of the folder /var/spool/uucp
> 	if you don't have it create it with command
> 	sudo mkdir /var/spool/uucp
> 	permissions should be: drwxrwxr-x
> 	if they are not do command
> 	sudo chmod 775 /var/spool/uucp
>
> 	YOU should be a member of the uucp group
> 	you can check it with command
> 		niutil -readprop / /groups/uucp users
> 	you should see your name in output of the niutil command
> 	if you don't do following:
> 		sudo niutil -appendprop / /groups/uucp users <yourname>
> 			substitute  <yourname> with your user's name
> 			for example if your user name is peter:
> 				sudo niutil -appendprop / /groups/uucp users peter
>
> 	NOTES: RXTX.pkg should create uucp folder and insert your name  in
> uucp group automatically"
>
>
>
> I really appreciate any help that you guys can offer.  I've been
> struggling with this for a while now as part of a research grant that
> I was awarded.  Thanks again for the help.
>
> Jhaysonn Pathak
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From tjarvi at qbang.org  Thu Jun 29 19:30:00 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 19:30:00 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A3D353.6010605@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
Message-ID: <Pine.LNX.4.61.0606291923000.9561@www>

On Thu, 29 Jun 2006, Manuel Naranjo wrote:

> Speaking about Windows Support, I had seen that inside the
> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
> not make harm to anyone, and i'm almost sure that someone has noticed it
> before.

Hi Manuel

         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
     47421  01-30-06 00:23 
rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
     77759  03-01-06 12:01 
rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README


It looks normal to me.  There are no fancy tools used there :)

--
Trent Jarvi
tjarvi at qbang.org

From naranjo.manuel at gmail.com  Thu Jun 29 19:38:16 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 22:38:16 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606291923000.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com> <Pine.LNX.4.61.0606291923000.9561@www>
Message-ID: <44A48088.2040407@gmail.com>

> On Thu, 29 Jun 2006, Manuel Naranjo wrote:
> 
>> Speaking about Windows Support, I had seen that inside the
>> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
>> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
>> not make harm to anyone, and i'm almost sure that someone has noticed it
>> before.
> 
> Hi Manuel
> 
>         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
>         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
>     47421  01-30-06 00:23 
> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
>     77759  03-01-06 12:01 
> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
>       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README
> 
> 
> It looks normal to me.  There are no fancy tools used there :)
> 
Hi Trent:
Is not the i368 representing the name of the Architecture?? If so the 
name should start with i386 it will not break any system, is simply miss
written, I saw that and wanted to report it. It a silly thing.
Ohh I forgoten I must congratulate you for your GREAT libray, I was able 
to make an .exe with JSmooth that launches an application that uses RXTX 
with out the need to install RXTX on users system :). The .exe tells JVM 
where to find the RXTX Library and Binaries. I tried with Sun's Java 
Comm but it was imposible.
Regards,
Manuel


From tjarvi at qbang.org  Thu Jun 29 19:52:45 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 19:52:45 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A48088.2040407@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
	<Pine.LNX.4.61.0606291923000.9561@www> <44A48088.2040407@gmail.com>
Message-ID: <Pine.LNX.4.61.0606291945060.9561@www>

On Thu, 29 Jun 2006, Manuel Naranjo wrote:

>> On Thu, 29 Jun 2006, Manuel Naranjo wrote:
>>
>>> Speaking about Windows Support, I had seen that inside the
>>> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
>>> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
>>> not make harm to anyone, and i'm almost sure that someone has noticed it
>>> before.
>>
>> Hi Manuel
>>
>>         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
>>         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
>>     47421  01-30-06 00:23
>> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
>>     77759  03-01-06 12:01
>> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
>>       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README
>>
>>
>> It looks normal to me.  There are no fancy tools used there :)
>>
> Hi Trent:
> Is not the i368 representing the name of the Architecture?? If so the
> name should start with i386 it will not break any system, is simply miss
> written, I saw that and wanted to report it. It a silly thing.
> Ohh I forgoten I must congratulate you for your GREAT libray, I was able
> to make an .exe with JSmooth that launches an application that uses RXTX
> with out the need to install RXTX on users system :). The .exe tells JVM
> where to find the RXTX Library and Binaries. I tried with Sun's Java
> Comm but it was imposible.

Hi Manuel

The compiler uses only the i386 instruction set for windows.  I doubt 
there will be any measurable advantages with going to later instruction 
sets.  In theory rxtx would run on a 386 but I doubt anyone does that.

So it looks odd but is not a typo.

We could compile to i686 but don't.  The compiler used does not appear to 
be a problem yet so I don't see any point in changing it.  Right now, we 
could not compile 64 bit windows binaries.  gcc/mingw/... do not support 
them that I know of.  People will have to compile those with closed source 
tools on their own until an option is available.

--
Trent Jarvi
tjarvi at qbang.org

From naranjo.manuel at gmail.com  Thu Jun 29 20:00:48 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 23:00:48 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606291945060.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com>	<Pine.LNX.4.61.0606291923000.9561@www>
	<44A48088.2040407@gmail.com> <Pine.LNX.4.61.0606291945060.9561@www>
Message-ID: <44A485D0.7050202@gmail.com>

Trent you did not get my point
The folder says 368 three hundred sixty eight, when
it should say 386 three hundred eighty six. Is simply a miss writting.
Regards,
Manuel


From tjarvi at qbang.org  Thu Jun 29 20:12:15 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 20:12:15 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A485D0.7050202@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
	<Pine.LNX.4.61.0606291923000.9561@www> <44A48088.2040407@gmail.com>
	<Pine.LNX.4.61.0606291945060.9561@www> <44A485D0.7050202@gmail.com>
Message-ID: <Pine.LNX.4.61.0606292008061.9561@www>


On Thu, 29 Jun 2006, Manuel Naranjo wrote:

> Trent you did not get my point
> The folder says 368 three hundred sixty eight, when
> it should say 386 three hundred eighty six. Is simply a miss writting.

hehe..  OK.  My bad.  It's been a long day.

Nevermind :)

--
Trent Jarvi
tjarvi at qbang.org




From naranjo.manuel at gmail.com  Thu Jun 29 20:18:44 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 23:18:44 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606292008061.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com>	<Pine.LNX.4.61.0606291923000.9561@www>
	<44A48088.2040407@gmail.com>	<Pine.LNX.4.61.0606291945060.9561@www>
	<44A485D0.7050202@gmail.com> <Pine.LNX.4.61.0606292008061.9561@www>
Message-ID: <44A48A04.9040401@gmail.com>

Don't worry Trent.
About 64 bits compilation, I would like to colaborate, I have a Pc with 
64 bits, the only problem is that i do not have windows 64 bits 
installed :(.




From Pawan.Kharbanda at dot.state.co.us  Fri Jun 30 08:49:52 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 30 Jun 2006 08:49:52 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E996@hqexchange3.dot.state.co.us>

Trent,  
    Can you explain what the interruptedEventLoop() native method is
doing is there a possibility that method is somehow getting into the
infinite loop(there are 2 while loops without any break statements).
This might be a very basic question how can I debug the native code(or
print the debug statements).  Again thanks for the help. 

Pawan Kharbanda

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Thursday, June 29, 2006 6:21 AM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports

> Here is how you can test if you have resources/ test environment. 
> Write a program and try to open/close  different ports(I will say have

> a minimum of four) randomly and very frequently(may be 30 seconds), I 
> am pretty sure you will see the deadlocks and it happens in the native

> call to interrptEventLoop in RXTXPort.java in removeEventListener() 
> method call.

Hi Pawan

I'll try to find a way to reproduce this.  One thing to note is that you
are using different kernel drivers (digi) to perform this task.  So I
probably will not be able to reproduce the exact same environment.

In general, multiport kernel drivers have been tested far less than
typical serial drivers.  This may or may not be an issue.

--
Trent Jarvi
tjarvi at qbang.org

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From cpine at wrsystems.com  Thu Jun 29 15:17:12 2006
From: cpine at wrsystems.com (Chris Pine)
Date: Thu, 29 Jun 2006 17:17:12 -0400
Subject: [Rxtx]  Controlling Individual Signals DTR and RTS
Message-ID: <MAIL4FJo0S8ACLEBajJ000005cf@mail4.wrsystems.com>

Dear Moussa Ba,
	I hope I am not being too forward, but we are having the exact same
issue with needing to control DTR from RXTX in Linux.  Did you ever have any
luck figuring it out?

Thank you very much for your time,

Chris Pine




From tjarvi at qbang.org  Thu Jun  1 11:13:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 11:13:40 -0600 (MDT)
Subject: [Rxtx] custom baud rate win32
In-Reply-To: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606011107210.30220@www>


Hi Daren

I can't imagine that 1953 is possibly the actual value on the UART.  Maybe 
if your baud base is very high with a custom serial board.  More likely, 
the driver just remembers that what you asked for and did something else.

I'll have more to say on the dcb->BaudRate after I try some things here. 
I have managed to do something like that in the past as a quick hack but 
it was for 14400.  I may have used the CBR_14400.

If we can't access this through the win32 API with protected mode, there 
is another layer of complication.  With real mode, it would be easy.
With protected mode, I assume there would have to be some kernel driver or 
a hook I'm not aware of to access the MCR directly (bang a memory 
addresss).



On Thu, 1 Jun 2006, Daren wrote:

> Trent,
> I have managed to successfully open the port at this speed using Realterm
> (available on sourceforge). From memory this uses DLPortIO.
>
> Using portmon.exe with realterm, even there it says that the port has opened
> at 1953.
>
> I changed termios.c:560 to
> dcb->BaudRate        = 1953 ;
>
> and it still opens the port at 9600.
>
> Daren
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Trent Jarvi
> Sent: Thursday, 1 June 2006 1:44 PM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] custom baud rate win32
>
> On Thu, 1 Jun 2006, Daren wrote:
>
>> Hi all,
>>
>> I downloaded 2.1.7-pre16 and managed to build it and get it going. I made
>> the changes as suggested by Peter Smith in an old post, by adding his code
>> to SerialImpl.c, uncommenting the TIOCGSERIAL and TIOCSSERIAL, and
> defining
>> ASYNC_SPD_CUST which is equal to 0x0030 (according to linus header
> files)..
>>
>>
>> Still not working, it opens the port at 9600 according to portmon.exe .
> Has
>> anyone managed to get this going at a custom rate?
>>
>> Here is the post I'm referring to:
>> http://marc.theaimsgroup.com/?l=rxtx&m=106270038110713&w=2
>>
>>
>> Thanks,
>> Daren
>>
>> ________________________________________
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
>> Daren
>> Sent: Wednesday, 31 May 2006 10:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] (no subject)
>>
>> Hi All,
>> I have been using rxtx for a little while and needed to get it working at
>> 1953, like a past user in the mailing list, who seemed to have got it
>> working by changing some C code.
>>
>> I wanted to build rxtx myself with these changes but don't know where to
>> start. I have windows here and FC4 at home. I downloaded cygwin and
> mingw32,
>> each build works by building a rxtxSerial.dll file that is ~11k smaller
> than
>> the original, and I always get the following error when testing the dll:
>>
>> Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at
>> PC=0x8077655
>> Function=[Unknown.]
>> Library=C:\opt\java\j2sdk1.4.2\jre\bin\client\jvm.dll
>>
>> NOTE: We are unable to locate the function name symbol for the error
>>      just occurred. Please refer to release documentation for possible
>>      reason and solutions.
>>
>>
>> Current Java thread:
>> 	at gnu.io.RXTXPort.open(Native Method)
>> 	- locked <0x1002c800> (a gnu.io.RXTXPort)
>> 	at gnu.io.RXTXPort.<init>(RXTXPort.java:84)
>>
>> Anyone know what im doing wrong?
>>
>>
>>
>>
>
> Hi Daren
>
> You are running into the same rats nest I'm looking at now.
>
> With win32 and specific custom baud rates, I'm not sure how this will go.
> I've got the Linux custom baud rates working very nicely.  I did much like
> the post you linked.  In fact I had forgot about that post.  You probably
> noticed that it becomes a bunch of dirt roads going noplace fast in
> termios.c for w32.
>
> I'm probably only going to get 14400, 28800, 128000 and 256000 working
> with the next release on w32.  I'll look a little further.  If you have an
> example w32 that works at 1953 I'd really like to hear.  Thats an unusual
> baud rate.
>
> Assuming a baud_base of 128000, your divisor will be 65 or 66.
>
> 128000/66=1939 -14
> 128000/65=1969 +13
>
> One thing I've been wondering about with linux is which would be the right
> answer in cases like this.  Right now it would just go with a baud base of
> 65 and ignore the modulus details.
>
> It appears to be a general trend for kernel developers to hide these
> details thinking that they can come up with a general solution.  Then they
> run out of time.  Perahps the solution is to help out but there are
> ultiple OS's rxtx supports making that nontrivial.
>
> If you look at current linux kernels, the 'tricks' above have been marked
> deprecated with no replacement.  Windows has some hard defines and then
> ancient near magic.  I've not looked at Solaris via Open Solaris yet but
> doubt there is a solution at all.
>
> What I'd try since you have the equipment and the monitor software is to
> hardcode the dcb->Baud in termios.c to 1953 (no define) and see what the
> w32 kernel does with it.  I think if you toss a baud rate at the driver it
> will try to come close.  You may try comming closer to a real baudrate
> based upon the 128000 baud base as shown above.
>
> If it works, it is worth looking at the rest of the ping/pong logic then.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
>
>
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From doug at dupreeinc.com  Thu Jun  1 13:22:13 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 12:22:13 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011107210.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
Message-ID: <447F3E65.1020809@dupreeinc.com>

Hello,

I am still trying to get this startup a little faster so I turned on the 
debug of a few of the classes.  The COM ports are scanned really fast 
and the delay occurs during the LPT scan.  The console output looks like 
this:

    ...
      LPT1
      LPT2
      LPT3
     valid port prefixes:
      LPT
    LPT1 LPT
    1 1
    LPT2 LPT
    2 2                                                                 
      * <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
    CommPortIdentifier:addPortName(LPT2)
    CommPortIdentifier:AddIdentifierToList()
    LPT3 LPT
    3 3
    CommPortIdentifier:addPortName(LPT3)
    CommPortIdentifier:AddIdentifierToList()
    CommPortIdentifier:AddIdentifierToList() index.next
    Leaving registerValidPorts()
    Have not implemented native_psmisc_report_owner(PortName)); in
    CommPortIdentifier
    CommPortIdentifier:getPortIdentifier(COM3)
    CommPortIdentifier:open(densConnect, 30000)
    RXTXCommDriver:getCommPort(COM3,1)
    ...

It would seem to me that if I removed the code for port scanning of LPT 
ports I could solve this problem. I would much prefer to use unmodified 
code if at all possible.  Do any of you have alternate suggestions?

Thank you for your time.

Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/cf433ee7/attachment-0010.html

From tjarvi at qbang.org  Thu Jun  1 13:52:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 13:52:06 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F3E65.1020809@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011348380.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I am still trying to get this startup a little faster so I turned on the 
> debug of a few of the classes.  The COM ports are scanned really fast and the 
> delay occurs during the LPT scan.  The console output looks like this:
>
>   ...
>     LPT1
>     LPT2
>     LPT3
>    valid port prefixes:
>     LPT
>   LPT1 LPT
>   1 1
>   LPT2 LPT
>   2 2                                                                      * 
> <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>   CommPortIdentifier:addPortName(LPT2)
>   CommPortIdentifier:AddIdentifierToList()
>   LPT3 LPT
>   3 3
>   CommPortIdentifier:addPortName(LPT3)
>   CommPortIdentifier:AddIdentifierToList()
>   CommPortIdentifier:AddIdentifierToList() index.next
>   Leaving registerValidPorts()
>   Have not implemented native_psmisc_report_owner(PortName)); in
>   CommPortIdentifier
>   CommPortIdentifier:getPortIdentifier(COM3)
>   CommPortIdentifier:open(densConnect, 30000)
>   RXTXCommDriver:getCommPort(COM3,1)
>   ...
>
> It would seem to me that if I removed the code for port scanning of LPT ports 
> I could solve this problem. I would much prefer to use unmodified code if at 
> all possible.  Do any of you have alternate suggestions?
>
> Thank you for your time.
>
> Doug
>


Does commenting out the LPT enumeration actually help?  There can often be 
differences between debug information printed and whats really going on. 
When you combine various environments the debug info can even come out in 
the wrong order.

I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
I do not think this problem is universal.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Thu Jun  1 14:29:44 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:29:44 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4E38.2060004@dupreeinc.com>

I will give it a try.  One thing to note on this PC is it has no LPT 
Parallel ports.

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
>>Hello,
>>
>>I am still trying to get this startup a little faster so I turned on the 
>>debug of a few of the classes.  The COM ports are scanned really fast and the 
>>delay occurs during the LPT scan.  The console output looks like this:
>>
>>  ...
>>    LPT1
>>    LPT2
>>    LPT3
>>   valid port prefixes:
>>    LPT
>>  LPT1 LPT
>>  1 1
>>  LPT2 LPT
>>  2 2                                                                      * 
>><<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>>  CommPortIdentifier:addPortName(LPT2)
>>  CommPortIdentifier:AddIdentifierToList()
>>  LPT3 LPT
>>  3 3
>>  CommPortIdentifier:addPortName(LPT3)
>>  CommPortIdentifier:AddIdentifierToList()
>>  CommPortIdentifier:AddIdentifierToList() index.next
>>  Leaving registerValidPorts()
>>  Have not implemented native_psmisc_report_owner(PortName)); in
>>  CommPortIdentifier
>>  CommPortIdentifier:getPortIdentifier(COM3)
>>  CommPortIdentifier:open(densConnect, 30000)
>>  RXTXCommDriver:getCommPort(COM3,1)
>>  ...
>>
>>It would seem to me that if I removed the code for port scanning of LPT ports 
>>I could solve this problem. I would much prefer to use unmodified code if at 
>>all possible.  Do any of you have alternate suggestions?
>>
>>Thank you for your time.
>>
>>Doug
>>
>>    
>>
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/dd31fed5/attachment-0010.html

From doug at dupreeinc.com  Thu Jun  1 14:36:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:36:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4FC8.9080106@dupreeinc.com>

Trent,

I commented out the section in RegisterScannedPorts() that adds the 
three LPT ports to the CandidateDeviceNames string array.  The 
application started immediately.  This is probably not the way to do 
this, but it was quick ,dirty, and worked.

It would be nice if there was a way to pole the OS to see if there is 
even a port there, though I guess this is what this code is suppose to do...

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
> ...
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From lynn at swcp.com  Thu Jun  1 14:49:34 2006
From: lynn at swcp.com (lynn@swcp.com)
Date: Thu, 1 Jun 2006 20:49:34 -0000
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>,
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <twig.1149194974.97617@swcp.com>

Perhaps we could add an argument to port enumeration where if not specified,
you get the default behavior that looks for everything.  With a new
constructor that has an argument(or more) you could optionally declare it to
not inspect printer ports.

Existing code would work as it always has.  New code could be smarter.

Lynn



Doug Thistlethwaite <doug at dupreeinc.com> said:

> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
> >On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
> >
> >  
> >
> > ...
> >
> >
> >Does commenting out the LPT enumeration actually help?  There can often be 
> >differences between debug information printed and whats really going on. 
> >When you combine various environments the debug info can even come out in 
> >the wrong order.
> >
> >I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
> >I do not think this problem is universal.
> >
> >--
> >Trent Jarvi
> >tjarvi at qbang.org
> >_______________________________________________
> >Rxtx mailing list
> >Rxtx at qbang.org
> >http://mailman.qbang.org/mailman/listinfo/rxtx
> >
> >
> >  
> >
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



-- 





From jredman at ergotech.com  Thu Jun  1 15:20:20 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 01 Jun 2006 15:20:20 -0600
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
Message-ID: <447F5A14.6010803@ergotech.com>

Doug,

If you specifically request ports, eg:

-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

or
 
-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

Depending upon the version  (Windows is COM1:COM2, etc. I assume).

Does it still enumerate the parallel ports?

Jim

Doug Thistlethwaite wrote:
> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
>> On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>
>>  
>>
>> ...
>>
>>
>> Does commenting out the LPT enumeration actually help?  There can often be 
>> differences between debug information printed and whats really going on. 
>> When you combine various environments the debug info can even come out in 
>> the wrong order.
>>
>> I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>> I do not think this problem is universal.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>>
>>  
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  1 16:49:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:49:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6EF4.7080709@dupreeinc.com>

I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
folder.  I created this file and added the following to the file:

gnu.io.rxtx.SerialPorts=COM3

and I get the following error on the console:
CommPortIdentifier:static initialization()
RXTXCommDriver {}
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
RXTXCommDriver:
    Jar version = RXTX-2.1-7
    native lib Version = RXTX-2.1-7
RXTXCommDriver:initialize()
checking for system-known ports of type 1
checking registry for ports of type 1

RXTXCommDriver:addSpecifiedPorts()
Exception in thread "main" java.lang.ExceptionInInitializerError
    at 
densconnect.SerialConnection.openConnection(SerialConnection.java:136)
    at densconnect.DensTalk.<init>(DensTalk.java:165)
    at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
    at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
    at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
    at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
Caused by: java.lang.NullPointerException
    at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
CommPortIdentifier:addPortName(COM3)
CommPortIdentifier:AddIdentifierToList()
CommPortIdentifier:AddIdentifierToList() null
...


It looks like it  read COM3 from the file, but it had the above 
exception that killed it.  The strange this is this error is from 
RXTXCommDriver initialize function (if statement line):

        OS = System.getProperty("os.name");
                System.out.println("OS NAME: " + OS);
        if(OS.toLowerCase().indexOf("linux") == -1)

OS is returning null, thus the error.

If the file is not present, it scans the ports and reads the OS.

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>Doug Thistlethwaite wrote:
>  
>
>>Trent,
>>
>>I commented out the section in RegisterScannedPorts() that adds the 
>>three LPT ports to the CandidateDeviceNames string array.  The 
>>application started immediately.  This is probably not the way to do 
>>this, but it was quick ,dirty, and worked.
>>
>>It would be nice if there was a way to pole the OS to see if there is 
>>even a port there, though I guess this is what this code is suppose to do...
>>
>>Doug
>>
>>Trent Jarvi wrote:
>>
>>    
>>
>>>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>>
>>> 
>>>
>>>...
>>>
>>>
>>>Does commenting out the LPT enumeration actually help?  There can often be 
>>>differences between debug information printed and whats really going on. 
>>>When you combine various environments the debug info can even come out in 
>>>the wrong order.
>>>
>>>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>>>I do not think this problem is universal.
>>>
>>>--
>>>Trent Jarvi
>>>tjarvi at qbang.org
>>>_______________________________________________
>>>Rxtx mailing list
>>>Rxtx at qbang.org
>>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>>
>>>
>>> 
>>>
>>>      
>>>
>>_______________________________________________
>>Rxtx mailing list
>>Rxtx at qbang.org
>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>    
>>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/bf4cca0e/attachment-0010.html

From doug at dupreeinc.com  Thu Jun  1 16:51:26 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:51:26 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6F6E.5060603@dupreeinc.com>

Jim,

I did not try your suggestion as I do not understand where I would put 
these command line parameters (it that is what they are).  It appears 
that using the properties file should do that same thing...

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>
>  
>


From doug at dupreeinc.com  Thu Jun  1 17:56:19 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 16:56:19 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
Message-ID: <447F7EA3.6050400@dupreeinc.com>

I think there is an error in the registerSpecifiedPorts() method.  When 
I have a gnu.io.rxtx.properties file in the ext directory, this function 
kills the System class  IF I call System.getProperty("os.name") before 
the call  to registerSpecifiedPorts(), it returns the os name, after the 
call, it returns null.  I have not played much with properties, except 
for reading them, so I don't really understand the code.

Doug



From doug at dupreeinc.com  Thu Jun  1 18:11:14 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 17:11:14 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F7EA3.6050400@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com>
Message-ID: <447F8222.3060402@dupreeinc.com>

Ok, I just hacked this thing up and got it to read the 
gnu.io.rxtx.properties file.

I commented out the line:
System.setProperties(p); in the method registerSpecifiedPorts() in 
RXTXCommDriver class.  I really don't understand that much about 
properties, but this call kills the System class.

I used the following in the gnu.io.rxtx.properties file:

gnu.io.rxtx.SerialPorts=COM3
gnu.io.rxtx.ParallelPorts=null

This allows the application to open very quickly without any errors.  
Whomever coded this class or somebody who understands properties should 
look at this method and make sure it is doing what they expect.

Doug




Doug Thistlethwaite wrote:

>I think there is an error in the registerSpecifiedPorts() method.  When 
>I have a gnu.io.rxtx.properties file in the ext directory, this function 
>kills the System class  IF I call System.getProperty("os.name") before 
>the call  to registerSpecifiedPorts(), it returns the os name, after the 
>call, it returns null.  I have not played much with properties, except 
>for reading them, so I don't really understand the code.
>
>Doug
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From tjarvi at qbang.org  Thu Jun  1 18:32:50 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 18:32:50 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F6EF4.7080709@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com> <447F6EF4.7080709@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011831510.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
> folder.  I created this file and added the following to the file:
>
> gnu.io.rxtx.SerialPorts=COM3
>
> and I get the following error on the console:
> CommPortIdentifier:static initialization()
> RXTXCommDriver {}
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
> RXTXCommDriver:
>   Jar version = RXTX-2.1-7
>   native lib Version = RXTX-2.1-7
> RXTXCommDriver:initialize()
> checking for system-known ports of type 1
> checking registry for ports of type 1
>
> RXTXCommDriver:addSpecifiedPorts()
> Exception in thread "main" java.lang.ExceptionInInitializerError
>   at densconnect.SerialConnection.openConnection(SerialConnection.java:136)
>   at densconnect.DensTalk.<init>(DensTalk.java:165)
>   at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
>   at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
>   at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
>   at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
> Caused by: java.lang.NullPointerException
>   at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
> CommPortIdentifier:addPortName(COM3)
> CommPortIdentifier:AddIdentifierToList()
> CommPortIdentifier:AddIdentifierToList() null
> ...
>
>

There is a solution for this bug.

http://bugzilla.qbang.org/show_bug.cgi?id=54

We have been horribly slow at getting the next round of patches in but 
they are comming.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  2 00:58:02 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 08:58:02 +0200
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F8222.3060402@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
Message-ID: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>

Hi Doug,

you wrote in an earlier message, that you would prefer an unchanged  
version. What about simply removing the RXTX parallel lib from the  
ext directory. This does not fix the bug, but it should fix your  
problem.

In general I think it is not a good idea to put the RXTX files in a  
system wide location. Putting the libs in the application folder and  
including the .jar in the application classpath (or application jar)  
is all that is required.

Regards,
Joachim

On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:

> Ok, I just hacked this thing up and got it to read the
> gnu.io.rxtx.properties file.
>
> I commented out the line:
> System.setProperties(p); in the method registerSpecifiedPorts() in
> RXTXCommDriver class.  I really don't understand that much about
> properties, but this call kills the System class.
>
> I used the following in the gnu.io.rxtx.properties file:
>
> gnu.io.rxtx.SerialPorts=COM3
> gnu.io.rxtx.ParallelPorts=null
>
> This allows the application to open very quickly without any errors.
> Whomever coded this class or somebody who understands properties  
> should
> look at this method and make sure it is doing what they expect.
>
> Doug
>
>
>
>
> Doug Thistlethwaite wrote:
>
>> I think there is an error in the registerSpecifiedPorts() method.   
>> When
>> I have a gnu.io.rxtx.properties file in the ext directory, this  
>> function
>> kills the System class  IF I call System.getProperty("os.name")  
>> before
>> the call  to registerSpecifiedPorts(), it returns the os name,  
>> after the
>> call, it returns null.  I have not played much with properties,  
>> except
>> for reading them, so I don't really understand the code.
>>
>> 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 antonio.luis at iscte.pt  Fri Jun  2 02:42:28 2006
From: antonio.luis at iscte.pt (=?ISO-8859-1?Q?Ant=F3nio_Lopes?=)
Date: Fri, 02 Jun 2006 09:42:28 +0100
Subject: [Rxtx] Exception when closing serial port
Message-ID: <447FF9F4.7060209@iscte.pt>

Hello everyone,
I've been using RXTX in a Java application in my Pocket PC.
The communication through the (bluetooth) serial port is working perfectly.

However, when I disconnect the app and close the serial port, sometimes I get 
the following error:

"1149237595000: RXTXPort:close detected bad File Descriptor"

The problem is that after this error occurs, the app is no longer able to 
connect to the serial port and I have to soft-reset the device in order to be 
able to connect to it again.

Any ideas on how to solve this issue?

Any help is appreciated.
Thanks,
regards,
-- 
Ant?nio Lopes

@contact: antonio.luis at iscte.pt
@work: ADETTI - ISCTE
@web: http://antonio.lopes.googlepages.com


From paul.klissner at sun.com  Fri Jun  2 02:44:34 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 01:44:34 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to RXTX
	again
Message-ID: <447FFA72.6040807@sun.com>

After looking into javax.comm 3.1 and what it would take to re-engineer it
to be compatible with RXTX platform libraries, I've decided, due my group's
priorities, complexity of the effort vs. benefit, and limited resources, 
to re-post
javax.comm 2.0 binaries on Sun's software download server, unsupported,
with disclaimers, as it was previously.

I don't think there will be any snags doing this from the standpoint of Sun
management or legality.  I will try to have it  posted there in the next 
week
or two, depending on how fast we can get it pushed through the process.

I'd like to think of this as a stop gap measure... ie. a compromise, 
where, at some
point in the not too distant future RXTX implements their own version of the
Java side of the API, as is normally done by javax.extension porters. 
That way
we avoid uncomfortable dependencies in the future.  And that really is 
the Java
development model.

Since RXTX already has the back-end code, porting the java code shouldn't
be a gargantuan effort at all, and RXTX will be in full control of the 
code top
to bottom. I think RXTX can do at least as good a job as the original 
coder.
Prepping 2.0 to be open sourced is more trouble than it is worth. ie. I 
don't
think the current implementation warrants it.

Ultimately, it would be nice to see someone open up a JSR and re-architect
the comm. API to overcome some of it's current design flaws (ie. be more
adaptable to modern platforms, more pluggable, better defined SPI, better
port ownership handling, etc...). A superior architecture would allow for
better collaboration in the future and better interchangeability of 
components
among projects.

Sun's 3.1 version of javax.comm, which is Sun's currently supported version,
has changes pertaining mostly to Sun platform-specific portmapping and has
some minor additional interactions with our back end code, but generally
has little bearing on RXTX. 

Paul



From joachim at buechse.de  Fri Jun  2 04:00:19 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 12:00:19 +0200
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
	RXTX again
In-Reply-To: <447FFA72.6040807@sun.com>
References: <447FFA72.6040807@sun.com>
Message-ID: <1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>

Good day Paul!

A clean architecture with loadable drivers and reusable code would be  
very beneficial for the future, I think everybody agrees. However  
this could be several years into the future. In the meantime, there  
is a real existing problem with IO support on Java. I have the strong  
feeling that most programmers want to code against one specification  
(javax.comm) and be able to replace the underlying implementation via  
a "plugin" on platforms where the SUN implementation is not  
sufficient. RXTX could be just this plugin (reusing very close to 0%  
of the javax.comm implementation but 100% of its API).

I want to propose an API addition and implementation change that will  
take less then 2 hours of manpower to implement and create a solution  
that can bridge the years until javax.comm has been based on a new  
architecture.

Looking at the javax.comm api at http://java.sun.com/products/ 
javacomm/reference/api/index.html I would like to propose the following:

The only entry point to javax.comm is CommPortIdentifier. It has 3  
static methods plus the constructor.

1) define one additional Interface

public interface CommProvider {
    CommPortIdentifier getPortIdentifier(CommPort port);
    CommPortIdentifier getPortIdentifier(String portName);
    Enumeration getPortIdentifiers ();
}

2) add one method to CommPortIdentifier

   public static setCustomCommProvider (CommProvider);

3) change the three static methods of CommPortIdentifier to dispatch  
to the CommProvider if it is set

4) change the constructor of CommPortIdentifier to

   public CommPortIdentifier(...) {
      if (isProviderSet && this.getClass() ==  
javax.comm.CommPortIdentifier) {
          throw new RuntimeException("illegal creation of  
CommPortIndentifier, custom CommProvider is in use");
      }

5) (this is optional, but would be very nice) automatically set a  
custom CommProvider if it is found on the classpath or defined via a  
system property.


The above 1) - 4) can be implemented in less than 1hour. 5) may take  
another hour. I agree that this is not the most elegant design, but  
it would solve a lot of problems with very little effort. It would  
certainly allow RXTX to move forward. If the javax.comm API needs to  
be redesigned completely this addition will not hurt, as people will  
move to the new API anyway and javax.comm 3.0 was so far never  
included in the main distribution.

Best regards,
Joachim

On 02.06.2006, at 10:44, Paul Klissner wrote:

> After looking into javax.comm 3.1 and what it would take to re- 
> engineer it
> to be compatible with RXTX platform libraries, I've decided, due my  
> group's
> priorities, complexity of the effort vs. benefit, and limited  
> resources,
> to re-post
> javax.comm 2.0 binaries on Sun's software download server,  
> unsupported,
> with disclaimers, as it was previously.
>
> I don't think there will be any snags doing this from the  
> standpoint of Sun
> management or legality.  I will try to have it  posted there in the  
> next
> week
> or two, depending on how fast we can get it pushed through the  
> process.
>
> I'd like to think of this as a stop gap measure... ie. a compromise,
> where, at some
> point in the not too distant future RXTX implements their own  
> version of the
> Java side of the API, as is normally done by javax.extension porters.
> That way
> we avoid uncomfortable dependencies in the future.  And that really is
> the Java
> development model.
>
> Since RXTX already has the back-end code, porting the java code  
> shouldn't
> be a gargantuan effort at all, and RXTX will be in full control of the
> code top
> to bottom. I think RXTX can do at least as good a job as the original
> coder.
> Prepping 2.0 to be open sourced is more trouble than it is worth.  
> ie. I
> don't
> think the current implementation warrants it.
>
> Ultimately, it would be nice to see someone open up a JSR and re- 
> architect
> the comm. API to overcome some of it's current design flaws (ie. be  
> more
> adaptable to modern platforms, more pluggable, better defined SPI,  
> better
> port ownership handling, etc...). A superior architecture would  
> allow for
> better collaboration in the future and better interchangeability of
> components
> among projects.
>
> Sun's 3.1 version of javax.comm, which is Sun's currently supported  
> version,
> has changes pertaining mostly to Sun platform-specific portmapping  
> and has
> some minor additional interactions with our back end code, but  
> generally
> has little bearing on RXTX.
>
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Fri Jun  2 09:10:13 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Fri, 2 Jun 2006 09:10:13 -0600 (MDT)
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <447FFA72.6040807@sun.com>
References: <447FFA72.6040807@sun.com>
Message-ID: <Pine.LNX.4.61.0606020906400.15971@www>

On Fri, 2 Jun 2006, Paul Klissner wrote:

> After looking into javax.comm 3.1 and what it would take to re-engineer it
> to be compatible with RXTX platform libraries, I've decided, due my group's
> priorities, complexity of the effort vs. benefit, and limited resources,
> to re-post
> javax.comm 2.0 binaries on Sun's software download server, unsupported,
> with disclaimers, as it was previously.
>

Hi Paul

To address users' immediate needs, we can release rxtx 2.0-7 (final) to 
match the 2.0 binaries from Sun when they are offered for download.

We can discuss potential long term solutions after that.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Fri Jun  2 10:20:09 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 02 Jun 2006 09:20:09 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
	<9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
Message-ID: <44806539.8080902@dupreeinc.com>

Thanks for the suggestion, I will give it a try.

Doug

Joachim Buechse wrote:

>Hi Doug,
>
>you wrote in an earlier message, that you would prefer an unchanged  
>version. What about simply removing the RXTX parallel lib from the  
>ext directory. This does not fix the bug, but it should fix your  
>problem.
>
>In general I think it is not a good idea to put the RXTX files in a  
>system wide location. Putting the libs in the application folder and  
>including the .jar in the application classpath (or application jar)  
>is all that is required.
>
>Regards,
>Joachim
>
>On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:
>
>  
>
>>Ok, I just hacked this thing up and got it to read the
>>gnu.io.rxtx.properties file.
>>
>>I commented out the line:
>>System.setProperties(p); in the method registerSpecifiedPorts() in
>>RXTXCommDriver class.  I really don't understand that much about
>>properties, but this call kills the System class.
>>
>>I used the following in the gnu.io.rxtx.properties file:
>>
>>gnu.io.rxtx.SerialPorts=COM3
>>gnu.io.rxtx.ParallelPorts=null
>>
>>This allows the application to open very quickly without any errors.
>>Whomever coded this class or somebody who understands properties  
>>should
>>look at this method and make sure it is doing what they expect.
>>
>>Doug
>>
>>
>>
>>
>>Doug Thistlethwaite wrote:
>>
>>    
>>
>>>I think there is an error in the registerSpecifiedPorts() method.   
>>>When
>>>I have a gnu.io.rxtx.properties file in the ext directory, this  
>>>function
>>>kills the System class  IF I call System.getProperty("os.name")  
>>>before
>>>the call  to registerSpecifiedPorts(), it returns the os name,  
>>>after the
>>>call, it returns null.  I have not played much with properties,  
>>>except
>>>for reading them, so I don't really understand the code.
>>>
>>>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
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060602/c8892a46/attachment-0010.html

From paul.klissner at sun.com  Fri Jun  2 12:09:26 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 11:09:26 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
Message-ID: <44807ED6.8000903@sun.com>

Joachim Buechse wrote:
> Good day Paul!
>
> A clean architecture with loadable drivers and reusable code would be  
> very beneficial for the future, I think everybody agrees. However  
> this could be several years into the future. In the meantime, there  
> is a real existing problem with IO support on Java. I have the strong  
> feeling that most programmers want to code against one specification  
> (javax.comm) and be able to replace the underlying implementation via  
> a "plugin" on platforms where the SUN implementation is not  
> sufficient. RXTX could be just this plugin (reusing very close to 0%  
> of the javax.comm implementation but 100% of its API).
>
> I want to propose an API addition and implementation change that will  
> take less then 2 hours of manpower to implement and create a solution  
> that can bridge the years until javax.comm has been based on a new  
> architecture.
>
> Looking at the javax.comm api at http://java.sun.com/products/ 
> javacomm/reference/api/index.html I would like to propose the following:
>
> The only entry point to javax.comm is CommPortIdentifier. It has 3  
> static methods plus the constructor.
>
> 1) define one additional Interface
>
> public interface CommProvider {
>     CommPortIdentifier getPortIdentifier(CommPort port);
>     CommPortIdentifier getPortIdentifier(String portName);
>     Enumeration getPortIdentifiers ();
> }
>
> 2) add one method to CommPortIdentifier
>
>    public static setCustomCommProvider (CommProvider);
>
> 3) change the three static methods of CommPortIdentifier to dispatch  
> to the CommProvider if it is set
>
> 4) change the constructor of CommPortIdentifier to
>
>    public CommPortIdentifier(...) {
>       if (isProviderSet && this.getClass() ==  
> javax.comm.CommPortIdentifier) {
>           throw new RuntimeException("illegal creation of  
> CommPortIndentifier, custom CommProvider is in use");
>       }
>
> 5) (this is optional, but would be very nice) automatically set a  
> custom CommProvider if it is found on the classpath or defined via a  
> system property.
>
>
> The above 1) - 4) can be implemented in less than 1hour. 5) may take  
> another hour. I agree that this is not the most elegant design, but  
> it would solve a lot of problems with very little effort. It would  
> certainly allow RXTX to move forward. If the javax.comm API needs to  
> be redesigned completely this addition will not hurt, as people will  
> move to the new API anyway and javax.comm 3.0 was so far never  
> included in the main distribution.
>
> Best regards,
> Joachi
I'm afraid modifying the interface classes isn't my call.  There was 
actually
a TCK written and one of the tests was to ensure that the interface classes
match the spec.  Thus my hands have already been tied since this project
was essentially grandfathered into the JCP.

That's why we need to open a new JSR and find someone who wants
to be the spec lead, and go in with a new reference implementation.
I'm not sure why it would have to take years, since this isn't bleeding edge
technology and there are only so many things that can be done with it,
and we already have practical experience about many functional aspects
that we could cite precedence on.

As it becomes clear that the specification is being accepted completely
or by-and-large by the community, nothing would stop people from
starting adapting to the new API (using the reference implementation or
porting it) and using it in their projects prior to it's final community and
JCP approval, since approval is required only to make it official and
get the "100% pure java" certification for platform ports.

You have one idea already.  Why don't you implement it, solicit some
design feedback from Sun and the RXTX, and create a functional
implementation that addresses the needs of the community, then
we can document it and open a JSR.  That's it.  It should march through
the approval stages reasonably quickly I would imagine, and meantime
RXTX could start using it.

Paul




From doug at dupreeinc.com  Fri Jun  2 12:45:01 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 02 Jun 2006 11:45:01 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
	<9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
Message-ID: <4480872D.6000605@dupreeinc.com>

Joachim,

Thank you for the suggestion.  I restored the jar file to the one I 
downloaded, moved the dll files into the project directory, and added 
the jar to the classpath.  The SerialDemo program that was included with 
the Sun commapi started in 12 seconds instead of the 58 seconds when the 
parallel dll is present.  I did get the startup time to about a second 
by modifying the java code and adding the properties file but this is 
probably not a good idea.

Doug

Joachim Buechse wrote:

>Hi Doug,
>
>you wrote in an earlier message, that you would prefer an unchanged  
>version. What about simply removing the RXTX parallel lib from the  
>ext directory. This does not fix the bug, but it should fix your  
>problem.
>
>In general I think it is not a good idea to put the RXTX files in a  
>system wide location. Putting the libs in the application folder and  
>including the .jar in the application classpath (or application jar)  
>is all that is required.
>
>Regards,
>Joachim
>
>On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:
>
>  
>
>>Ok, I just hacked this thing up and got it to read the
>>gnu.io.rxtx.properties file.
>>
>>I commented out the line:
>>System.setProperties(p); in the method registerSpecifiedPorts() in
>>RXTXCommDriver class.  I really don't understand that much about
>>properties, but this call kills the System class.
>>
>>I used the following in the gnu.io.rxtx.properties file:
>>
>>gnu.io.rxtx.SerialPorts=COM3
>>gnu.io.rxtx.ParallelPorts=null
>>
>>This allows the application to open very quickly without any errors.
>>Whomever coded this class or somebody who understands properties  
>>should
>>look at this method and make sure it is doing what they expect.
>>
>>Doug
>>
>>
>>
>>
>>Doug Thistlethwaite wrote:
>>
>>    
>>
>>>I think there is an error in the registerSpecifiedPorts() method.   
>>>When
>>>I have a gnu.io.rxtx.properties file in the ext directory, this  
>>>function
>>>kills the System class  IF I call System.getProperty("os.name")  
>>>before
>>>the call  to registerSpecifiedPorts(), it returns the os name,  
>>>after the
>>>call, it returns null.  I have not played much with properties,  
>>>except
>>>for reading them, so I don't really understand the code.
>>>
>>>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
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060602/3c0e420f/attachment-0010.html

From joachim at buechse.de  Fri Jun  2 13:46:36 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 21:46:36 +0200
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
	RXTX again
In-Reply-To: <44807ED6.8000903@sun.com>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
	<44807ED6.8000903@sun.com>
Message-ID: <6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>

Hello Paul,

of course, the basic change I suggested could be done "hidden".  The  
CommProvider interface could live somewhere in sun.xyz.*
The setCustomCommProvider method would not be in CommPortIdentifier  
but also somewhere in sun.xyz.* This would be an unofficial feature,  
the official interface stays exactly the same. However RXTX (and  
others) could access the hidden interface.

Don't get me wrong, I don't want to harass you into making changes  
you don't like (which probably wouldn't work anyway;-). But I'm a  
long time Java programmer and seeing the state of cross platform  
serial support for Java makes me feel really sad. In fact, when I  
started to look into Java serial port programming some months ago I  
was very surprised that javax.comm never made it into the JDK.

I'm sorry that I did not contribute my feedback to the JSR for  
javax.comm 3.0. However at the time I didn't do serial port  
programming in Java. I agree that a new JSR should be opened - I'm  
not an expert on JSRs or the JCP process, but from looking quickly  
over the progress of some JSRs I would be very surprised if we can  
have a new version in less then a year. In the meanwhile some people  
will start using javax.comm 3.0 (which can not be supported by RXTX),  
some will use javax.comm 2.0 (which means the 2.0.7 release of RXTX  
still needs to be maintained). This may get even worse if eg Apple  
decides to port and include javax.comm 3.0 at which point it may get  
very tricky to write a cross platform Java application.

All of this simply means, that we are loosing a lot of man-power that  
could otherwise be invested in building a clean solution and/or to  
add features that are becoming more and more important (USB events...).

In the automation / machine control universe Java makes a lot of  
sense. Right now many people are migrating to Linux or from  
propietary systems (even DOS) to Windows. Writing the control/ 
configuration applications in Java is the kings way to unify the code  
base.

Best regards,
Joachim


On 02.06.2006, at 20:09, Paul Klissner wrote:

> Joachim Buechse wrote:
>> Good day Paul!
>>
>> A clean architecture with loadable drivers and reusable code would be
>> very beneficial for the future, I think everybody agrees. However
>> this could be several years into the future. In the meantime, there
>> is a real existing problem with IO support on Java. I have the strong
>> feeling that most programmers want to code against one specification
>> (javax.comm) and be able to replace the underlying implementation via
>> a "plugin" on platforms where the SUN implementation is not
>> sufficient. RXTX could be just this plugin (reusing very close to 0%
>> of the javax.comm implementation but 100% of its API).
>>
>> I want to propose an API addition and implementation change that will
>> take less then 2 hours of manpower to implement and create a solution
>> that can bridge the years until javax.comm has been based on a new
>> architecture.
>>
>> Looking at the javax.comm api at http://java.sun.com/products/
>> javacomm/reference/api/index.html I would like to propose the  
>> following:
>>
>> The only entry point to javax.comm is CommPortIdentifier. It has 3
>> static methods plus the constructor.
>>
>> 1) define one additional Interface
>>
>> public interface CommProvider {
>>     CommPortIdentifier getPortIdentifier(CommPort port);
>>     CommPortIdentifier getPortIdentifier(String portName);
>>     Enumeration getPortIdentifiers ();
>> }
>>
>> 2) add one method to CommPortIdentifier
>>
>>    public static setCustomCommProvider (CommProvider);
>>
>> 3) change the three static methods of CommPortIdentifier to dispatch
>> to the CommProvider if it is set
>>
>> 4) change the constructor of CommPortIdentifier to
>>
>>    public CommPortIdentifier(...) {
>>       if (isProviderSet && this.getClass() ==
>> javax.comm.CommPortIdentifier) {
>>           throw new RuntimeException("illegal creation of
>> CommPortIndentifier, custom CommProvider is in use");
>>       }
>>
>> 5) (this is optional, but would be very nice) automatically set a
>> custom CommProvider if it is found on the classpath or defined via a
>> system property.
>>
>>
>> The above 1) - 4) can be implemented in less than 1hour. 5) may take
>> another hour. I agree that this is not the most elegant design, but
>> it would solve a lot of problems with very little effort. It would
>> certainly allow RXTX to move forward. If the javax.comm API needs to
>> be redesigned completely this addition will not hurt, as people will
>> move to the new API anyway and javax.comm 3.0 was so far never
>> included in the main distribution.
>>
>> Best regards,
>> Joachi
> I'm afraid modifying the interface classes isn't my call.  There was
> actually
> a TCK written and one of the tests was to ensure that the interface  
> classes
> match the spec.  Thus my hands have already been tied since this  
> project
> was essentially grandfathered into the JCP.
>
> That's why we need to open a new JSR and find someone who wants
> to be the spec lead, and go in with a new reference implementation.
> I'm not sure why it would have to take years, since this isn't  
> bleeding edge
> technology and there are only so many things that can be done with it,
> and we already have practical experience about many functional aspects
> that we could cite precedence on.
>
> As it becomes clear that the specification is being accepted  
> completely
> or by-and-large by the community, nothing would stop people from
> starting adapting to the new API (using the reference  
> implementation or
> porting it) and using it in their projects prior to it's final  
> community and
> JCP approval, since approval is required only to make it official and
> get the "100% pure java" certification for platform ports.
>
> You have one idea already.  Why don't you implement it, solicit some
> design feedback from Sun and the RXTX, and create a functional
> implementation that addresses the needs of the community, then
> we can document it and open a JSR.  That's it.  It should march  
> through
> the approval stages reasonably quickly I would imagine, and meantime
> RXTX could start using it.
>
> Paul
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From paul.klissner at sun.com  Fri Jun  2 14:38:49 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 13:38:49 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
	<44807ED6.8000903@sun.com>
	<6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>
Message-ID: <4480A1D9.5060106@sun.com>

Joachim Buechse wrote:
> Hello Paul,
>
> of course, the basic change I suggested could be done "hidden".  The  
> CommProvider interface could live somewhere in sun.xyz.*
> The setCustomCommProvider method would not be in CommPortIdentifier  
> but also somewhere in sun.xyz.* This would be an unofficial feature,  
> the official interface stays exactly the same. However RXTX (and  
> others) could access the hidden interface.
>
> Don't get me wrong, I don't want to harass you into making changes  
> you don't like (which probably wouldn't work anyway;-). But I'm a  
> long time Java programmer and seeing the state of cross platform  
> serial support for Java makes me feel really sad. In fact, when I  
> started to look into Java serial port programming some months ago I  
> was very surprised that javax.comm never made it into the JDK.
>
> I'm sorry that I did not contribute my feedback to the JSR for  
> javax.comm 3.0. 
There was no JSR for 3.0, because we didn't have the resources to make 
the commitment.
Yet Sun needed to add support for platform-dependent port name mapping, 
which had to
be done 'under the hood', since the API isn't designed to handle that in 
a pluggable way.
But these quick fixes aren't the right approach, they just kick the dog 
down the road,
setting bad precedent, inviting confusion and more intractable problems 
(such as the
one plaguing us now).

My changes could have been layered better, it was a trade off between 
achieving an
ideal architecture, trying to find internal reviewers, and meet the 
needs of big customers
in a timely way.  Thus my namespace changes collided with RXTX's 
dependencies.
I was unaware of Jagane's rogue agreement made with the RXTX community 7 
years ago,
before Jagane left Sun.  I think this was a wag-the-dog situation.

Now it is time to do it right, and I don't think it is going to be as 
much trouble as people
some people fear. If RXTX wants to sponsor the JSR and seed a new spec, 
Sun can join
the Expert Group.  And we'd be largely in agreement, since we're not 
talking about
humongous changes, and looking for mutually beneficial changes. The core 
API is already
largely proved and tested.
> However at the time I didn't do serial port  
> programming in Java. I agree that a new JSR should be opened - I'm  
> not an expert on JSRs or the JCP process, but from looking quickly  
> over the progress of some JSRs I would be very surprised if we can  
> have a new version in less then a year. 
*Approved*  But that doesn't mean the spec couldn't be 99.9% stable 
before that.  Once
the delta rate declines and changes approach nil, people could start 
adapting to the API in
advance of formal approval.   It isn't going to be drawn out like 
javax.usb, which was new
technology, a very complex API, and involved precedent setting corporate 
disputes and
policy issues to resolve.

> In the meanwhile some people  
> will start using javax.comm 3.0 (which can not be supported by RXTX),  
> some will use javax.comm 2.0 (which means the 2.0.7 release of RXTX  
> still needs to be maintained). This may get even worse if eg Apple  
> decides to port and include javax.comm 3.0 at which point it may get  
> very tricky to write a cross platform Java application.
>   
The interfaces haven't changed since 1.0.  If we open a JSR ,we can 
contact Apple and
allow them to be on the E.G., if they want.  That might make the JSR a 
bit more drawn out,
but then we'd arrive ultimately arrive at a best-of-all-worlds API that 
most people would
accept, perhaps forever, and arrive at a respectable set of compromises.

-Paul

> All of this simply means, that we are loosing a lot of man-power that  
> could otherwise be invested in building a clean solution and/or to  
> add features that are becoming more and more important (USB events...).
>
> In the automation / machine control universe Java makes a lot of  
> sense. Right now many people are migrating to Linux or from  
> propietary systems (even DOS) to Windows. Writing the control/ 
> configuration applications in Java is the kings way to unify the code  
> base.
>
> Best regards,
> Joachim
>
>
> On 02.06.2006, at 20:09, Paul Klissner wrote:
>
>   
>> Joachim Buechse wrote:
>>     
>>> Good day Paul!
>>>
>>> A clean architecture with loadable drivers and reusable code would be
>>> very beneficial for the future, I think everybody agrees. However
>>> this could be several years into the future. In the meantime, there
>>> is a real existing problem with IO support on Java. I have the strong
>>> feeling that most programmers want to code against one specification
>>> (javax.comm) and be able to replace the underlying implementation via
>>> a "plugin" on platforms where the SUN implementation is not
>>> sufficient. RXTX could be just this plugin (reusing very close to 0%
>>> of the javax.comm implementation but 100% of its API).
>>>
>>> I want to propose an API addition and implementation change that will
>>> take less then 2 hours of manpower to implement and create a solution
>>> that can bridge the years until javax.comm has been based on a new
>>> architecture.
>>>
>>> Looking at the javax.comm api at http://java.sun.com/products/
>>> javacomm/reference/api/index.html I would like to propose the  
>>> following:
>>>
>>> The only entry point to javax.comm is CommPortIdentifier. It has 3
>>> static methods plus the constructor.
>>>
>>> 1) define one additional Interface
>>>
>>> public interface CommProvider {
>>>     CommPortIdentifier getPortIdentifier(CommPort port);
>>>     CommPortIdentifier getPortIdentifier(String portName);
>>>     Enumeration getPortIdentifiers ();
>>> }
>>>
>>> 2) add one method to CommPortIdentifier
>>>
>>>    public static setCustomCommProvider (CommProvider);
>>>
>>> 3) change the three static methods of CommPortIdentifier to dispatch
>>> to the CommProvider if it is set
>>>
>>> 4) change the constructor of CommPortIdentifier to
>>>
>>>    public CommPortIdentifier(...) {
>>>       if (isProviderSet && this.getClass() ==
>>> javax.comm.CommPortIdentifier) {
>>>           throw new RuntimeException("illegal creation of
>>> CommPortIndentifier, custom CommProvider is in use");
>>>       }
>>>
>>> 5) (this is optional, but would be very nice) automatically set a
>>> custom CommProvider if it is found on the classpath or defined via a
>>> system property.
>>>
>>>
>>> The above 1) - 4) can be implemented in less than 1hour. 5) may take
>>> another hour. I agree that this is not the most elegant design, but
>>> it would solve a lot of problems with very little effort. It would
>>> certainly allow RXTX to move forward. If the javax.comm API needs to
>>> be redesigned completely this addition will not hurt, as people will
>>> move to the new API anyway and javax.comm 3.0 was so far never
>>> included in the main distribution.
>>>
>>> Best regards,
>>> Joachi
>>>       
>> I'm afraid modifying the interface classes isn't my call.  There was
>> actually
>> a TCK written and one of the tests was to ensure that the interface  
>> classes
>> match the spec.  Thus my hands have already been tied since this  
>> project
>> was essentially grandfathered into the JCP.
>>
>> That's why we need to open a new JSR and find someone who wants
>> to be the spec lead, and go in with a new reference implementation.
>> I'm not sure why it would have to take years, since this isn't  
>> bleeding edge
>> technology and there are only so many things that can be done with it,
>> and we already have practical experience about many functional aspects
>> that we could cite precedence on.
>>
>> As it becomes clear that the specification is being accepted  
>> completely
>> or by-and-large by the community, nothing would stop people from
>> starting adapting to the new API (using the reference  
>> implementation or
>> porting it) and using it in their projects prior to it's final  
>> community and
>> JCP approval, since approval is required only to make it official and
>> get the "100% pure java" certification for platform ports.
>>
>> You have one idea already.  Why don't you implement it, solicit some
>> design feedback from Sun and the RXTX, and create a functional
>> implementation that addresses the needs of the community, then
>> we can document it and open a JSR.  That's it.  It should march  
>> through
>> the approval stages reasonably quickly I would imagine, and meantime
>> RXTX could start using it.
>>
>> Paul
>>
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at 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  Sat Jun  3 18:15:24 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 18:15:24 -0600 (MDT)
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
Message-ID: <Pine.LNX.4.61.0606031715100.10890@www>


The attached patch allows baud rates of 14400, 28800, 128000 and 256000.

That was my goal.

[import standard disclaimer]

But I took some time to look a little further.  I got custom baud rates 
working enough that someone (perhaps me) can properly fix them in the 
future.  Proof of concept.

As an undocumented bonus, you can toss random baudrates (say 1953), at the 
API and it will set it to something close to that on windows and linux. 
Solaris should say the baud rate is not supported but I have not tested it 
yet.  Mac OS X behavior is unknown at this point.  Just dont expect 
correct behavior at ~8192-9009 baudrates or baudrates less than 20 on 
windows; these baud rates overlap with defines in win32termios.h.  I 
conveniently closed my eyes there.  Try another value close.  On Linux, a 
baud base and divisor are guestimated and set.  On windows, we wave pixie 
dust over the kernel driver and hope.  Do not expect pixie dust and 
guestimates to be the same on windows and linux.  They may well round to 
different values in yet to be tested ways.  There are only so many 
divisors.  If it isn't working, try a little higher or lower.

In the example of 1953 for instance, there is no divisor for commodity 
hardware that comes to that baudrate.  We just come close on one side or 
the other.  If tools tell you they got 1953 exactly, the tools may be 
questionable and just reading values not directly related to the actual 
hardware settings.

These fixes have been tested on Linux and Windows while using an 
oscilloscope to confirm they change relative to known baudrates at 9600, 
14400*, 19200, 28800* (and 1800, 1953** and 2400).

* = previously unsupported.
** = still not supported but probably works from what I saw.

There could be future discussion in this area.  For now this is working 
for almost all unusual baud rate demands.  Cleaning up the custom baud 
rate should be easier with a working starting point.  Baud bases other 
than 128000 have not been characterized.  Yes.. this overlapps with two of 
the baud rates enabled.

Feedback and ideas are welcome.

--
Trent Jarvi
tjarvi at qbang.org
-------------- next part --------------
Index: SerialImp.c
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v
retrieving revision 1.46.2.187
diff -u -r1.46.2.187 SerialImp.c
--- SerialImp.c	29 Jan 2006 22:19:04 -0000	1.46.2.187
+++ SerialImp.c	3 Jun 2006 23:12:40 -0000
@@ -793,6 +793,19 @@
 		result &= ~TIOCM_DTR;
 		ioctl( fd, TIOCMSET, &result );
 	}
+	/*
+	   B38400 is a special case in Linux for custom baud rates.
+
+	   We just treat this as a custom speed for now.  If you take this ifdef
+	   out and select baud rates 38400 then 28800 then 38400, you will get
+	   a final baud rate of 28800 because you did not update the divisor.
+
+	   See the next ifdef below for the divisor.
+	*/
+#if defined(TIOCGSERIAL)
+	if ( cspeed == B38400 )
+		cspeed = 38400;
+#endif /* TIOCGSERIAL */
 	if(     cfsetispeed( &ttyset, cspeed ) < 0 ||
 		cfsetospeed( &ttyset, cspeed ) < 0 )
 	{
@@ -814,6 +827,7 @@
 		*/
 
 #if defined(TIOCGSERIAL)
+		ioctl( fd, TIOCGSERIAL, &sstruct );
 		sstruct.custom_divisor = ( sstruct.baud_base/cspeed );
 		cspeed = B38400;
 #endif /* TIOCGSERIAL */
@@ -827,7 +841,7 @@
 #if defined(TIOCSSERIAL)
 		/*  It is assumed Win32 does this for us */
 		if (	sstruct.baud_base < 1 ||
-			ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
+		ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
 		{
 			return( 1 );
 		}
Index: termios.c
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v
retrieving revision 1.9.2.56
diff -u -r1.9.2.56 termios.c
--- termios.c	16 Jan 2006 02:50:32 -0000	1.9.2.56
+++ termios.c	3 Jun 2006 23:12:40 -0000
@@ -323,8 +323,8 @@
 		case CBR_3500000:	return( B3500000 );
 		case CBR_4000000:	return( B4000000 );
 		default:
-			set_errno(EINVAL );
-			return -1;
+			/* assume custom baudrate */
+			return( Baud );
 	}
 }
 
@@ -361,12 +361,13 @@
 		case B9600:	ret = CBR_9600;		break;
 		case B14400:	ret = CBR_14400;	break;
 		case B19200:	ret = CBR_19200;	break;
+		case B28800:	ret = CBR_28800;	break;
 		case B38400:	ret = CBR_38400;	break;
 		case B57600:	ret = CBR_57600;	break;
 		case B115200:	ret = CBR_115200;	break;
 		case B128000:	ret = CBR_128000;	break;
-		case B256000: 	ret = CBR_256000;	break;
 		case B230400:	ret = CBR_230400;	break;
+		case B256000: 	ret = CBR_256000;	break;
 		case B460800:	ret = CBR_460800;	break;
 		case B500000:	ret = CBR_500000;	break;
 		case B576000:	ret = CBR_576000;	break;
@@ -381,10 +382,8 @@
 		case B4000000:	ret = CBR_4000000;	break;
 	
 		default:
-			fprintf( stderr, "B_to_CBR: invalid baudrate: %#o\n",
-				Baud );
-			set_errno( EINVAL );
-			return -1;
+			/* assume custom baudrate */
+			return Baud;
 	}
 	LEAVE( "B_to_CBR" );
 	return ret;
@@ -708,12 +707,9 @@
 	ENTER( "init_serial_struct" );
 
 	/*
-	FIXME
-
-	This needs to use inb() to read the actual baud_base
-	and divisor from the UART registers.  Question is how
-	far do we take this?
-
+	use of custom_divisor and baud_base requires access to
+	kernel space.  The kernel does try its best if you just
+	toss a baud rate at it though.
 	*/
 
 	sstruct->custom_divisor = 0;
@@ -1678,16 +1674,17 @@
 {
 	char message[80];
 	ENTER( "cfsetospeed" );
+	/* clear baudrate */
+	s_termios->c_cflag &= ~CBAUD;
 	if ( speed & ~CBAUD )
 	{
 		sprintf( message, "cfsetospeed: not speed: %#o\n", speed );
 		report( message );
-		return 0;
+		/* continue assuming its a custom baudrate */
+		s_termios->c_cflag |= B38400;  /* use 38400 during custom */
+		s_termios->c_cflag |= CBAUDEX; /* use CBAUDEX for custom */
 	}
-	s_termios->c_ispeed = s_termios->c_ospeed = speed;
-	/* clear baudrate */
-	s_termios->c_cflag &= ~CBAUD;
-	if( speed )
+	else if( speed )
 	{
 		s_termios->c_cflag |= speed;
 	}
@@ -1696,6 +1693,7 @@
 		/* PC blows up with speed 0 handled in Java */
 		s_termios->c_cflag |= B9600;
 	}
+	s_termios->c_ispeed = s_termios->c_ospeed = speed;
 	LEAVE( "cfsetospeed" );
 	return 1;
 }
@@ -1767,25 +1765,6 @@
 }
 
 /*----------------------------------------------------------
-serial_struct_to_DCB()
-
-   accept:      
-   perform:     
-   return:      
-   exceptions:  
-   win32api:     None
-   comments:    
-----------------------------------------------------------*/
-int serial_struct_to_DCB( struct serial_struct *sstruct, DCB *dcb )
-{
-	/* 5 Baud rate fix
-	sstruct.baud_base
-	sstruct.custom_divisor = ( sstruct.baud_base/cspeed );
-	*/
-	return(0);
-}
-
-/*----------------------------------------------------------
 termios_to_DCB()
 
    accept:      
@@ -1798,7 +1777,8 @@
 int termios_to_DCB( struct termios *s_termios, DCB *dcb )
 {
 	ENTER( "termios_to_DCB" );
-	s_termios->c_ispeed = s_termios->c_ospeed = s_termios->c_cflag & CBAUD;
+	if ( !(s_termios->c_cflag & CBAUDEX) )
+		s_termios->c_ispeed = s_termios->c_ospeed = s_termios->c_cflag & CBAUD;
 	dcb->BaudRate        = B_to_CBR( s_termios->c_ispeed );
 	dcb->ByteSize = termios_to_bytesize( s_termios->c_cflag );
 
@@ -2863,11 +2843,6 @@
 			GetCommState( index->hComm, dcb );
 
 			index->sstruct = va_arg( ap, struct serial_struct * );
-			if ( serial_struct_to_DCB( index->sstruct, dcb ) < 0 )
-			{
-				va_end( ap );
-				return -1;
-			}
 
 			report( "TIOCSSERIAL\n" );
 			free(dcb);
Index: win32termios.h
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v
retrieving revision 1.5.2.28
diff -u -r1.5.2.28 win32termios.h
--- win32termios.h	30 Jun 2005 20:23:26 -0000	1.5.2.28
+++ win32termios.h	3 Jun 2006 23:12:40 -0000
@@ -279,7 +279,7 @@
 #define XTABS	01000000 /* Hmm.. Linux/i386 considers this part of TABDLY.. */
 
 /* c_cflag bit meaning */
-# define CBAUD	0010017
+#define  CBAUD  0030017
 #define  B0	0000000		/* hang up */
 #define  B50	0000001
 #define  B75	0000002
@@ -312,13 +312,16 @@
 #define  B3500000 0010016
 #define  B4000000 0010017
 
-/* glue for unsupported linux speeds see also SerialImp.h */
-/* hosed */
-
-#define B14400		1010001
-#define B28800		1010002
-#define B128000		1010003
-#define B256000		1010004
+/*
+	glue for unsupported linux speeds see also SerialImp.h 
+	custom baud rates around 8192-9000 will not work because
+	of these.
+*/
+
+#define B14400		0020001
+#define B28800		0020002
+#define B128000		0020003
+#define B256000		0020004
 
 #define EXTA B19200
 #define EXTB B38400
@@ -356,8 +359,10 @@
 
 /* glue for unsupported windows speeds */
 
-#define CBR_230400	230400
 #define CBR_28800	28800
+#define CBR_128000	128000
+#define CBR_230400	230400
+#define CBR_256000	256000
 #define CBR_460800	460800
 #define CBR_500000	500000
 #define CBR_576000	576000

From impakt01 at optusnet.com.au  Sat Jun  3 18:30:37 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 10:30:37 +1000
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
In-Reply-To: <Pine.LNX.4.61.0606031715100.10890@www>
Message-ID: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>

Hi Trent,
I'd love to try the patch but I can't get the latest build compiling, only
pre16. 

Can you attach the rxtxSerial.dll file with this patch?

Also, I hardcoded 1953 in a couple more places last night on pre16 and it
managed to open the port at the right speed, but stopped receiving anything
after 100-150 bytes, even though more data was getting sent to the port.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 10:15 AM
To: rxtx at qbang.org
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.


The attached patch allows baud rates of 14400, 28800, 128000 and 256000.

That was my goal.

[import standard disclaimer]

But I took some time to look a little further.  I got custom baud rates 
working enough that someone (perhaps me) can properly fix them in the 
future.  Proof of concept.

As an undocumented bonus, you can toss random baudrates (say 1953), at the 
API and it will set it to something close to that on windows and linux. 
Solaris should say the baud rate is not supported but I have not tested it 
yet.  Mac OS X behavior is unknown at this point.  Just dont expect 
correct behavior at ~8192-9009 baudrates or baudrates less than 20 on 
windows; these baud rates overlap with defines in win32termios.h.  I 
conveniently closed my eyes there.  Try another value close.  On Linux, a 
baud base and divisor are guestimated and set.  On windows, we wave pixie 
dust over the kernel driver and hope.  Do not expect pixie dust and 
guestimates to be the same on windows and linux.  They may well round to 
different values in yet to be tested ways.  There are only so many 
divisors.  If it isn't working, try a little higher or lower.

In the example of 1953 for instance, there is no divisor for commodity 
hardware that comes to that baudrate.  We just come close on one side or 
the other.  If tools tell you they got 1953 exactly, the tools may be 
questionable and just reading values not directly related to the actual 
hardware settings.

These fixes have been tested on Linux and Windows while using an 
oscilloscope to confirm they change relative to known baudrates at 9600, 
14400*, 19200, 28800* (and 1800, 1953** and 2400).

* = previously unsupported.
** = still not supported but probably works from what I saw.

There could be future discussion in this area.  For now this is working 
for almost all unusual baud rate demands.  Cleaning up the custom baud 
rate should be easier with a working starting point.  Baud bases other 
than 128000 have not been characterized.  Yes.. this overlapps with two of 
the baud rates enabled.

Feedback and ideas are welcome.

--
Trent Jarvi
tjarvi at qbang.org



From tjarvi at qbang.org  Sat Jun  3 19:05:11 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 19:05:11 -0600 (MDT)
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
In-Reply-To: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>
References: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606031840400.10890@www>

On Sun, 4 Jun 2006, Daren wrote:

> Hi Trent,
> I'd love to try the patch but I can't get the latest build compiling, only
> pre16.
>
> Can you attach the rxtxSerial.dll file with this patch?
>
> Also, I hardcoded 1953 in a couple more places last night on pre16 and it
> managed to open the port at the right speed, but stopped receiving anything
> after 100-150 bytes, even though more data was getting sent to the port.
>


ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing

I dont think they will hang.  But I was just testing via loopback/break 
out box/scope.

I'll be putting about 10 patches and another set of binaries in that 
directory shortly.  For now the binaries should just have the baud_rate 
fix.

I'll announce all the patches at once.  but wont be releasing 2.1-8 right 
away.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Sat Jun  3 21:00:01 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 21:00:01 -0600 (MDT)
Subject: [Rxtx] CVS for 2.1 should have everything
Message-ID: <Pine.LNX.4.61.0606032056190.10890@www>


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org


From impakt01 at optusnet.com.au  Sat Jun  3 21:08:14 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 13:08:14 +1000
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <Pine.LNX.4.61.0606032056190.10890@www>
Message-ID: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>

Hi Trent,
I tried the latest dll and it opens the port, receives 100-200 bytes and
then stops receiving anything else..

I'll keep playing with it.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 1:00 PM
To: rxtx at qbang.org
Subject: [Rxtx] CVS for 2.1 should have everything


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From impakt01 at optusnet.com.au  Sat Jun  3 21:22:41 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 13:22:41 +1000
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
Message-ID: <200606040322.k543MqW1008455@mail12.syd.optusnet.com.au>

Played with it, problem, with a while loop in my code, working great now

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Daren
Sent: Sunday, 4 June 2006 1:08 PM
To: 'RXTX Developers and Users'
Subject: Re: [Rxtx] CVS for 2.1 should have everything

Hi Trent,
I tried the latest dll and it opens the port, receives 100-200 bytes and
then stops receiving anything else..

I'll keep playing with it.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 1:00 PM
To: rxtx at qbang.org
Subject: [Rxtx] CVS for 2.1 should have everything


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Sat Jun  3 21:35:41 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 21:35:41 -0600 (MDT)
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
References: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606032131140.10890@www>

On Sun, 4 Jun 2006, Daren wrote:

> Hi Trent,
> I tried the latest dll and it opens the port, receives 100-200 bytes and
> then stops receiving anything else..
>
> I'll keep playing with it.
>
> Daren

The difference may be that I'm talking to something at the exact same baud 
rate (loopback).

You may also try setting the baudrate to ~1933 and ~1973 to force the 
guesses one way or the other.  If you are on windows, we are not doing 
anything fancy in the end.  Thats the kernel guessing.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sun Jun  4 04:12:09 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sun, 4 Jun 2006 12:12:09 +0200
Subject: [Rxtx] Update of OSX installer, Readme, etc
Message-ID: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>

Good day,

after the latest changes a lot of OS X specific files should be  
updated. Especially the installer!

- The "MaxOSX" readme file on the root level is outdated (ie  
CodeWarrior information). Maybe we could even rename it to README.OSX  
to be in line with README.IPAQ, README.SCO (Trent do you mind copying/ 
renaming ,v files in the repository?).

- The lock files are no longer used and hence the user group magic  
and lock folder creation should be removed from the installer.

- MACOSX_IDE/ForPackageMaker/Resources/ReadMe.rtf and Welcome.rtf  
need to be updated.

- I suggest to replace the current installation instruction for OS X:  
Installation should occur into the application directory, not in the  
Java-VM directory. This simplifies things a lot, as the Mac Installer  
can be removed completely.

- The xcodeproject's build settings need to be updated to generate  
JAVA 1.1 format class files.


Dimitry: do you have time to tackle this? I could do it, but as this  
is "your baby" I thought you may prefer to do it yourself.

Regards,
Joachim



From dmarkman at mac.com  Sun Jun  4 11:27:53 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Sun, 4 Jun 2006 13:27:53 -0400
Subject: [Rxtx] Update of OSX installer, Readme, etc
In-Reply-To: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
References: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
Message-ID: <26E7A202-962B-4C19-93B6-29426C467249@mac.com>

Joachim,
unfortunately I don't have time right now to do that
so if you can do that, please do

it's not only my baby
it's yours too :-)

thanks


On Jun 4, 2006, at 6:12 AM, Joachim Buechse wrote:

> Good day,
>
> after the latest changes a lot of OS X specific files should be
> updated. Especially the installer!
>
> - The "MaxOSX" readme file on the root level is outdated (ie
> CodeWarrior information). Maybe we could even rename it to README.OSX
> to be in line with README.IPAQ, README.SCO (Trent do you mind copying/
> renaming ,v files in the repository?).
>
> - The lock files are no longer used and hence the user group magic
> and lock folder creation should be removed from the installer.
>
> - MACOSX_IDE/ForPackageMaker/Resources/ReadMe.rtf and Welcome.rtf
> need to be updated.
>
> - I suggest to replace the current installation instruction for OS X:
> Installation should occur into the application directory, not in the
> Java-VM directory. This simplifies things a lot, as the Mac Installer
> can be removed completely.
>
> - The xcodeproject's build settings need to be updated to generate
> JAVA 1.1 format class files.
>
>
> Dimitry: do you have time to tackle this? I could do it, but as this
> is "your baby" I thought you may prefer to do it yourself.
>
> Regards,
> Joachim
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman



From tjarvi at qbang.org  Sun Jun  4 13:54:02 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 4 Jun 2006 13:54:02 -0600 (MDT)
Subject: [Rxtx] Update of OSX installer, Readme, etc
In-Reply-To: <26E7A202-962B-4C19-93B6-29426C467249@mac.com>
References: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
	<26E7A202-962B-4C19-93B6-29426C467249@mac.com>
Message-ID: <Pine.LNX.4.61.0606041353040.22522@www>

On Sun, 4 Jun 2006, Dmitry Markman wrote:

> Joachim,
> unfortunately I don't have time right now to do that
> so if you can do that, please do
>
> it's not only my baby
> it's yours too :-)
>

I've given Joachim cvs access.  He has shown good work in bugzilla.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Mon Jun  5 10:08:32 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 5 Jun 2006 18:08:32 +0200
Subject: [Rxtx] Build process changes for Mac OS X
Message-ID: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>

Good day,

I have cleaned up some outdated Mac OSX specific build files in the  
repository.

There was not a lot left of the readme file "MacOSX" after cleaning  
it up, so I decided to rename it README.OSX to be in harmony with the  
other files in the directory (ie README.IPAQ, README.SCO, ...)

I added an (uncompressed) XCode 2.3 project file/structure  
with .cvsignore files that will ignore the user specific settings.  
This should work "out of the box" for OSX10.4. Users of 10.2/10.3 may  
have to switch the build settings.

[It's kind of tricky to choose "the right" setting. Afaik there is no  
way to compile a universal binary that will work on 10.3 or before.  
So it's either UniversalBinary OR Legacy. Maybe we should have  
different build targets for these different targets?? I would like to  
get some feedback from the Mac developers on this list regarding the  
subject].

Besides other things the OSX installer is no longer required. Since  
the next version (2.1.8) will no longer use lockfiles on OSX, the  
group/permission magic is no longer required and hence there remains  
basicly no work for the installer - other than copying 2 files to the  
VM extension directory. Then again, this is not the best way to  
install RXTX. So I removed the installer completely without modifying  
it, this should simplify a "resurrection" should it ever get necessary.

I had problems with the (compressed, ie sit.hqx) legacy project files  
on the latest installation of OSX (javac 1.5 creating non JDK1.1  
class files and some minor problems). To reduce potential confusion  
for newcomers I decided to remove them. This means that there is no  
longer a simple way to build RXTX for OSX 10.0 and 10.1 (I deeply  
apologize if anyone still relied on this ... well the files are in  
the Attiq).

Best regards,
Joachim


From joachim at buechse.de  Mon Jun  5 10:16:37 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 5 Jun 2006 18:16:37 +0200
Subject: [Rxtx] RXTX and lockfiles on OSX [it is fixed now]
Message-ID: <7D2C4418-9397-4B59-8091-9FDE4ED67836@buechse.de>

Quite a number of people contacted me in the last couple of weeks  
because of problems installing RXTX on OSX. I told you to wait for  
the "official" fix. Well, it has been fixed.

So if you were among the people waiting for the solution, you can now  
download the source rxtx-2.1-7r2.zip from the website. Once unpacked  
dont forget to use "cvs up" to update the files to the latest  
version. You can then open MACOSX_IDE/XCode/ 
LibSerialUniversal.xcodeproj with XCode 2.3 and build the libraries  
that no longer try to create lock files.

Regards,
Joachim


From brian at mbari.org  Mon Jun  5 10:52:43 2006
From: brian at mbari.org (Brian Schlining)
Date: Mon, 5 Jun 2006 09:52:43 -0700
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
Message-ID: <78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>

Hi Joachim,

> [It's kind of tricky to choose "the right" setting. Afaik there is no
> way to compile a universal binary that will work on 10.3 or before.
> So it's either UniversalBinary OR Legacy. Maybe we should have
> different build targets for these different targets?? I would like to
> get some feedback from the Mac developers on this list regarding the
> subject].

I imagine most developers will be compiling on 10.4 (It's the nature  
of the coder...gotta have the latest and greatest) and deploying to  
both 10.3 and 10.4; both of which will run Universal Binaries (see  
http://forums.macrumors.com/showthread.php?t=205348). So it sounds  
like you've covered the majority of users. Still, you know someone's  
going to pipe up about needing RXTX on 10.2 so it would be nice to  
have a target to make a PPC only build.

Just my 2 cents

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/1cac8c39/attachment-0010.html

From dmarkman at mac.com  Mon Jun  5 13:47:50 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Mon, 5 Jun 2006 15:47:50 -0400
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
Message-ID: <686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>

I don't think it will be a problem to run universal binary
on 10.2
however if binary has some calls that aren't implemented in 10.2
then you'll have a problem


On Jun 5, 2006, at 12:52 PM, Brian Schlining wrote:

> Hi Joachim,
>
>> [It's kind of tricky to choose "the right" setting. Afaik there is no
>> way to compile a universal binary that will work on 10.3 or before.
>> So it's either UniversalBinary OR Legacy. Maybe we should have
>> different build targets for these different targets?? I would like to
>> get some feedback from the Mac developers on this list regarding the
>> subject].
>
> I imagine most developers will be compiling on 10.4 (It's the  
> nature of the coder...gotta have the latest and greatest) and  
> deploying to both 10.3 and 10.4; both of which will run Universal  
> Binaries (see http://forums.macrumors.com/showthread.php?t=205348).  
> So it sounds like you've covered the majority of users. Still, you  
> know someone's going to pipe up about needing RXTX on 10.2 so it  
> would be nice to have a target to make a PPC only build.
>
> Just my 2 cents
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/9fafc878/attachment-0010.html

From brian at mbari.org  Mon Jun  5 14:52:41 2006
From: brian at mbari.org (Brian Schlining)
Date: Mon, 5 Jun 2006 13:52:41 -0700
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
Message-ID: <E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>

Hi Dmitry,

> I don't think it will be a problem to run universal binary
> on 10.2
> however if binary has some calls that aren't implemented in 10.2
> then you'll have a problem

You're right...I stand corrected.

Note however, to deploy a universal binary to 10.2 RXTX will need to  
use the 10.2 SDK to build the PPC side. (see http:// 
developer.apple.com/documentation/DeveloperTools/Conceptual/ 
cross_development/UniversalBinaries/chapter_4_section_1.html). I  
haven't been paying close attention to the new locking mechanism used  
by RXTX on the Mac...does 10.2 support it?

Joachim, which SDK will you be using by default for building the Mac  
PPC binaries?

>> Hi Joachim,
>>
>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>> is no
>>> way to compile a universal binary that will work on 10.3 or before.
>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>> different build targets for these different targets?? I would  
>>> like to
>>> get some feedback from the Mac developers on this list regarding the
>>> subject].
>>
>> I imagine most developers will be compiling on 10.4 (It's the  
>> nature of the coder...gotta have the latest and greatest) and  
>> deploying to both 10.3 and 10.4; both of which will run Universal  
>> Binaries (see http://forums.macrumors.com/showthread.php? 
>> t=205348). So it sounds like you've covered the majority of users.  
>> Still, you know someone's going to pipe up about needing RXTX on  
>> 10.2 so it would be nice to have a target to make a PPC only build.

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/153bf50e/attachment-0010.html

From dmarkman at mac.com  Mon Jun  5 19:02:04 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Mon, 5 Jun 2006 21:02:04 -0400
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
Message-ID: <7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>

if Joachim didn't change xcode project setting

/Developer/SDKs/MacOSX10.4u.sdk is used to build universal binary

so it's quite possible that it won't run properly on 10.2

so we have to change the building process, so ppc part will be built
with
/Developer/SDKs/MacOSX10.2.8.sdk

and finally to use lipo utility to build universal binaries

Joachim, did you use some specific locking API that wasn't implemented

in MacOSX10.2.8.sdk?

thanks


On Jun 5, 2006, at 4:52 PM, Brian Schlining wrote:

> Hi Dmitry,
>
>> I don't think it will be a problem to run universal binary
>> on 10.2
>> however if binary has some calls that aren't implemented in 10.2
>> then you'll have a problem
>
> You're right...I stand corrected.
>
> Note however, to deploy a universal binary to 10.2 RXTX will need  
> to use the 10.2 SDK to build the PPC side. (see http:// 
> developer.apple.com/documentation/DeveloperTools/Conceptual/ 
> cross_development/UniversalBinaries/chapter_4_section_1.html). I  
> haven't been paying close attention to the new locking mechanism  
> used by RXTX on the Mac...does 10.2 support it?
>
> Joachim, which SDK will you be using by default for building the  
> Mac PPC binaries?
>
>>> Hi Joachim,
>>>
>>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>>> is no
>>>> way to compile a universal binary that will work on 10.3 or before.
>>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>>> different build targets for these different targets?? I would  
>>>> like to
>>>> get some feedback from the Mac developers on this list regarding  
>>>> the
>>>> subject].
>>>
>>> I imagine most developers will be compiling on 10.4 (It's the  
>>> nature of the coder...gotta have the latest and greatest) and  
>>> deploying to both 10.3 and 10.4; both of which will run Universal  
>>> Binaries (see http://forums.macrumors.com/showthread.php? 
>>> t=205348). So it sounds like you've covered the majority of  
>>> users. Still, you know someone's going to pipe up about needing  
>>> RXTX on 10.2 so it would be nice to have a target to make a PPC  
>>> only build.
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/84790f80/attachment-0010.html

From joachim at buechse.de  Tue Jun  6 02:40:47 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 6 Jun 2006 10:40:47 +0200
Subject: [Rxtx] Building on OS X, Impl Changes
In-Reply-To: <7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
Message-ID: <CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>

Good day!

What's in the XCode project setting?
----------

The xcode project remained pretty much the same as before. I excluded  
the user specific files from CVS and changed some settings. I kept  
all the built targets (you shouldn't change what you don't understand;-)

Currently we the following build targets:
    RXTXComm (java files)
    librxtxParallel.jnilib (usefull on the Mac???)
    libI2C.jnilib (not yet working in RXTX)
    libRS485.jnilib (not yet working in RXTX)
    librxtxSerial.jnilib (1)
    librxtxSerial.jnilib Dynamic (2)
    rxtxSerial (3)
We also have the following build configurations for each target:
    Development
    Default
    Deployment

What was changed in the xcode project from previous versions:
- java.souce=1.3 and java.target=1.1 in RXTXComm settings
- removed copying of build products into installer directory
- removed "(Upgraded)" from build target names

What remains to be changed:
- choosing a "non-debug" Build-configuration as default
- potentially removing "Default"/"Development" Build-configurations
- reducing the number of build targets
- creating 10.2 compatible universal binaries

I suggest, that the build configurations should be reduced to 2  
(Debug/Deployment), possibly even 1 (Debug).
I have not yet found the deeper meaning of the build targets(1)(2) 
(3), it seems to me like they should be reduced into one "doing the  
right thing" or maybe into two "rxtxSerial.jnilib Legacy" (back to  
10.2, universal if possible) and "rxtxSerial.jnilib 10.4 
+" (universal, 10.4+).

Should the code work on 10.2?
----------

Absolutely. The code should work on NextStep, in fact on any BSD  
unix. I would go as far as saying, this code should work on any  
POSSIX based unix. All that was added is the call "ioctl(fd,  
TIOCEXCL)" to request excusivity of the port:

http://gemma.apple.com/documentation/DeviceDrivers/Conceptual/ 
WorkingWSerial/WWSerial_SerialDevs/chapter_2_section_8.html

It is not yet "the perfect solution". Normally an open /dev/tty  
(listen for incomming connection) should be "preemptable" by opening  
a /dev/cu (outgoing connection) for the same port. This is not yet  
implemented as it needs calls outside of POSSIX on OSX.

On "classic" systems (like NextStep) this worked based on the  
"carried detect line". open() on /dev/tty.xxx would block until the  
carrier detect signal was raised. As the device was not "opened"  
opening /dev/cu.xxx worked without a hitch. When they ported to the  
Mac this broke. On Macs the "carier detect" is usually not wired.  
Furthermore FAX modems did no longer raise the line. So the OSX  
implementor defined a new call, which is documented here:

http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00045.html

Best regards,
Joachim




On 06.06.2006, at 03:02, Dmitry Markman wrote:

> if Joachim didn't change xcode project setting
>
> /Developer/SDKs/MacOSX10.4u.sdk is used to build universal binary
>
> so it's quite possible that it won't run properly on 10.2
>
> so we have to change the building process, so ppc part will be built
> with
> /Developer/SDKs/MacOSX10.2.8.sdk
>
> and finally to use lipo utility to build universal binaries
>
> Joachim, did you use some specific locking API that wasn't implemented
>
> in MacOSX10.2.8.sdk?
>
> thanks
>
>
> On Jun 5, 2006, at 4:52 PM, Brian Schlining wrote:
>
>> Hi Dmitry,
>>
>>> I don't think it will be a problem to run universal binary
>>> on 10.2
>>> however if binary has some calls that aren't implemented in 10.2
>>> then you'll have a problem
>>
>> You're right...I stand corrected.
>>
>> Note however, to deploy a universal binary to 10.2 RXTX will need  
>> to use the 10.2 SDK to build the PPC side. (see http:// 
>> developer.apple.com/documentation/DeveloperTools/Conceptual/ 
>> cross_development/UniversalBinaries/chapter_4_section_1.html). I  
>> haven't been paying close attention to the new locking mechanism  
>> used by RXTX on the Mac...does 10.2 support it?
>>
>> Joachim, which SDK will you be using by default for building the  
>> Mac PPC binaries?
>>
>>>> Hi Joachim,
>>>>
>>>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>>>> is no
>>>>> way to compile a universal binary that will work on 10.3 or  
>>>>> before.
>>>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>>>> different build targets for these different targets?? I would  
>>>>> like to
>>>>> get some feedback from the Mac developers on this list  
>>>>> regarding the
>>>>> subject].
>>>>
>>>> I imagine most developers will be compiling on 10.4 (It's the  
>>>> nature of the coder...gotta have the latest and greatest) and  
>>>> deploying to both 10.3 and 10.4; both of which will run  
>>>> Universal Binaries (see http://forums.macrumors.com/ 
>>>> showthread.php?t=205348). So it sounds like you've covered the  
>>>> majority of users. Still, you know someone's going to pipe up  
>>>> about needing RXTX on 10.2 so it would be nice to have a target  
>>>> to make a PPC only build.
>>
>> Brian Schlining
>> Software Engineer
>> http://www.mbari.org
>>
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> Dmitry Markman
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Tue Jun  6 07:01:06 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 6 Jun 2006 15:01:06 +0200
Subject: [Rxtx] Serial port code for OS X, future steps
In-Reply-To: <CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
	<CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
Message-ID: <8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>

I posted the "wrong link". There is a correction here:

    http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00059.html

In fact, the 2.1.7 implementation of RXTX has quite some deficiencies  
on OSX. I have tried to supply some patches that don't interfere to  
much with the existing RXTX code base, but there are limits to what  
can be done with local patches.

There are some very intrusive changes that should be done. Ie proper  
mapping of /dev/tty <-> /dev/cu handling to correct behaviour of  
CommPortOwnershipListener (http://java.sun.com/products/javacomm/ 
reference/api/index.html). I dont think this can be done with  
patches. Hence I think, RXTX should be rewritten from scratch de- 
unifying the native code base (and implementing thread safe code on  
the Java side).


How "should" /dev/tty vs /dev/cu be implemented?

=====
The Unix contract is this: An open /dev/tty.xxx port (incomming)  
should be interrupted/auto-closed when opening /dev/cu.xxx (outgoing)  
[if /dev/tty.xxx is not currently handling a communication].  /dev/ 
cu.xxx and /dev/tty.xxx refer to the same device, so owning  
"exclusively" should block both. This should be respected across all  
applications native or Java.

This contract is realizable on OSX with the existing javax.comm  
interface while also respecting (to the biggest part) the contract  
defined by javax.comm.PortOwnershipListener.

The one point where the suggested implementation "breaks" the  
javax.comm contract, is by the fact that one can loose a /dev/tty  
port without calling close. However, the only option I see is to  
always open serial ports "non-exclusively" which would outrule Java  
as a platform for (dormant) applications waiting for incoming  
connections/faxes/etc. There could be a system property to choose the  
intended behavior.
=====

Here is how it could be done on OSX:

Calling port=ComportIdentifier.open("/dev/cu.xxx") opens and owns the  
port exclusively until port.close() is called.
- Java applications listening with a PortOwnershipListener should get  
a PORT_OWNED event reasonably soon.
- Any further attempt by a Java or native application to open "/dev/ 
cu.xxx" or "/dev/tty.xxx" fails.
- /dev/cu.xxx is for "outgoing" connections, so receiving  
PORT_OWNERSHIP_REQUESTED makes little to no sense. With native  
applications it can not be implemented. For Java applications it  
could be implemented (by a hidden communication channel). I think  
it's not worth bothering. If anyone is willing to give up a port to  
others he should use /dev/tty.xxx instead of /dev/cu.xxx.

Registering a PortOwnershipListener on "/dev/cu.xxx" without opening  
it, uses /dev/tty.xxx (native open()) non-exclusively and polls its  
state. PORT_OWNED and PORT_UNOWNED can be produced.

Calling port=ComportIdentifier.open("/dev/tty.xxx") should open the  
port non-exclusively.
- Adding a SerialPortEventListener and reading from the port could be  
allowed while keeping it non-exclusive.
- When port.getOutputStream() is called, the state should be changed  
to an "exclusive" ownership. This may be configurable via a system  
property.
- To return to the non-exclusive state the port must be closed and  
reopened.
- While non-exclusively opened, opening the corresponding /dev/cu.xxx  
produces a PORT_OWNERSHIP_REQUESTED event. Which should be responded  
by closing the port from within the callback (as described in  
java.comm.PortOwnershipListener). If there is a pending read, it will  
return after the listener finishes (with -1 or "0 bytes read").
- Calling write() on the /dev/tty.xxx after somebody opened /dev/ 
cu.xxx will fail with a descriptive IOException.
- Calling read() on the /dev/tty.xxx after somebody opened /dev/ 
cu.xxx will fail with a descriptive IOException (or potentially  
block, see side notes below).

CommPortIdentifier.getCurrentOwner() can be implemented by an  
external call to lsof.

CommPortIdentifier.isCurrentlyOwned() can be implemented by trying an  
open on the /dev/tty.
- It returns true if the port is currently held "exclusively".
- Whether it should also return true on /dev/tty if /dev/tty is  
already opened non-exclusively might be a system property option. In  
general, having several applications waiting for incoming connections  
on the same port will require an application level "arbitration"  
protocol...

[[side note1: One interesting question is, what happens if the  
process holding /dev/tty non-exclusively ignores  
PORT_OWNERSHIP_REQUESTED. Ie after "loosing" a non-exclusively opened  
"dev/tty.xxx" port to another process. One possible implementation  
is, that the port is "regained" when the other process gives up the  
port. This would mean that in the meanwhile read() returns no data,  
and any changes to the configuration of the port are stored but not  
forwarded. I guess, the safe (and simple) way to do this is to make  
the close() mandatory (ie setting the port into an "awaiting_close"  
state which produces IOExceptions to any other call than close). ]]

[[side note2:  Another interesting question is, what should happen if  
several applications open the same /dev/tty.xxx port "non- 
exclusively" and start to change the settings of the device.]]

Regards,
Joachim



On 06.06.2006, at 10:40, Joachim Buechse wrote:

> Should the code work on 10.2?
> ----------
>
> Absolutely. The code should work on NextStep, in fact on any BSD
> unix. I would go as far as saying, this code should work on any
> POSSIX based unix. All that was added is the call "ioctl(fd,
> TIOCEXCL)" to request excusivity of the port:
>
> http://gemma.apple.com/documentation/DeviceDrivers/Conceptual/
> WorkingWSerial/WWSerial_SerialDevs/chapter_2_section_8.html
>
> It is not yet "the perfect solution". Normally an open /dev/tty
> (listen for incomming connection) should be "preemptable" by opening
> a /dev/cu (outgoing connection) for the same port. This is not yet
> implemented as it needs calls outside of POSSIX on OSX.
>
> On "classic" systems (like NextStep) this worked based on the
> "carried detect line". open() on /dev/tty.xxx would block until the
> carrier detect signal was raised. As the device was not "opened"
> opening /dev/cu.xxx worked without a hitch. When they ported to the
> Mac this broke. On Macs the "carier detect" is usually not wired.
> Furthermore FAX modems did no longer raise the line. So the OSX
> implementor defined a new call, which is documented here:
>
> http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00045.html
>
> Best regards,
> Joachim



From sds at dcs.gla.ac.uk  Tue Jun  6 11:22:45 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Tue, 06 Jun 2006 18:22:45 +0100
Subject: [Rxtx] Correct compile flag for HP iPAQ hx4700 running Familiar
	Linux?
Message-ID: <1149614565.19496.10.camel@addu>

Hi,

I'd like to use RXTX 2.1 on my HP iPAQ hx4700. The iPAQ is running
Familiar Linux 0.8.2 (as I recall), with Blackdown Java 1.3.1.

I can compile and run a test program which uses RXTX on my i686 machine,
and it works fine. But I can't seem to get things working quite right on
my PDA.

I compile the code on the laptop with the following commands:
	./configure --host=arm-gnu-linux && make
... as suggested in a post to this list, albeit some time ago. This
compiles, I transfer the files, set up LD_LIBRARY_PATH and CLASSPATH
variables, and get the following error on the PDA:

sds at ipaq-pxa-2:~# java Test
java.lang.UnsatisfiedLinkError: /usr/local/lib/ext/librxtxSerial.so: /usr/local/lib/ext/librxtxSerial.so: cannot open shared object file: No such file or directory thrown while loading gnu.io.RXTXCommDriver
Exception in thread "main"
java.lang.UnsatisfiedLinkError: /usr/local/lib/ext/librxtxSerial.so: /usr/local/lib/ext/librxtxSerial.so: cannot open shared object file: No such file or directory
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1382)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1290)
        at java.lang.Runtime.loadLibrary0(Runtime.java:749)
        at java.lang.System.loadLibrary(System.java:820)
        at
gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:83)
        at Test.<init>(Test.java:9)
        at Test.main(Test.java:32)
sds at ipaq-pxa-2:~# 

Note that I'm copying the files to /usr/local/lib/ext/ along with the
RXTXcomm.jar file, purely to keep things separate from the rest of the
system while testing. The location of the .so files doesn't seem to have
any bearing on whether "java Test" will succeed or not. The contents of
this directory are:

sds at ipaq-pxa-2:~$ ls /usr/local/lib/ext/
RXTXcomm.jar              librxtxParallel-2.1-7.so  librxtxRS485.so
librxtxSerial-2.1-7.so
librxtxI2C-2.1-7.so       librxtxParallel.so        librxtxRaw-2.1-7.so
librxtxSerial.so
librxtxI2C.so             librxtxRS485-2.1-7.so     librxtxRaw.so
sds at ipaq-pxa-2:~$

Test.java fails on the first real line of code I'm using to test that
things are working, prior to real development, and was carefully pinched
from the web:
Enumeration portIdentifiers = CommPortIdentifier.getPortIdentifiers();


I assume that I've gotten my --host flag wrong way back up there at
the ./configure step. But if that's the case, what should I set it to?
Or am I missing something more obvious?


Cheers,
Stephen Strowes,
University of Glasgow.




From tjarvi at qbang.org  Tue Jun  6 13:39:41 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 6 Jun 2006 13:39:41 -0600 (MDT)
Subject: [Rxtx] Serial port code for OS X, future steps
In-Reply-To: <8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
	<CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
	<8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>
Message-ID: <Pine.LNX.4.61.0606061315070.9856@www>


>>
There are some very intrusive changes that should be done. Ie proper
mapping of /dev/tty <-> /dev/cu handling to correct behaviour of
CommPortOwnershipListener (http://java.sun.com/products/javacomm/
reference/api/index.html). I dont think this can be done with
patches. Hence I think, RXTX should be rewritten from scratch de-
unifying the native code base (and implementing thread safe code on
the Java side).
<<

This appears to be a very small amount of functionality for a total 
rewrite.  The port ownership only needs maybe 3 native calls if it is done 
with native calls at all.

Those features which are not part of the Unix standard(s) can be special 
cased.  I'm not sure /dev/cu is standard.  We can look.  I know linux 
deprecated /dev/cua years ago.

Thread safe Java code is not a platform specific issue.

--
Trent Jarvi
tjarvi at qbang.org


From sds at dcs.gla.ac.uk  Wed Jun  7 12:36:43 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Wed, 07 Jun 2006 19:36:43 +0100
Subject: [Rxtx] Expected RXTX behaviour?
In-Reply-To: <1149703900.30891.19.camel@addu>
References: <1149703900.30891.19.camel@addu>
Message-ID: <1149705403.30891.25.camel@addu>

Apologies, caught the problem. Had to append '\r' to the end of the AT
string. A non obvious but stupid mistake... :-)

Final quick question though: How might I stop the echoing of
outputStream data back into the inputStream? I still see the ATI
commands on the inputStream, along with the output from the device.


Cheers,
S.



On Wed, 2006-06-07 at 19:11 +0100, Stephen Strowes wrote:
> Hi,
> 
> I managed to get RXTX to compile for my iPAQ following my previous post
> to this list. Quick query though:
> 
> I want to be able to issue AT commands to a device, and interpret the
> responses. For this, I assume I do the following, in psuedo-form:
> 
> 	CommPortIdentifier.getPortIdentifiers();
> 	// find the correct device id
> 	serialPort= (SerialPort)portID.open("Test");
> 	// Set parameters and flow control
> 	outputStream= serialPort.getOutputStream();
> 	inputStream=  serialPort.getInputStream();
> 
> ... following this, I spawn a thread to respond to DATA_AVAILABLE events
> on serialPort with inputStream, and occasionally write and flush an
> "ATI" onto the outputStream. Nothing complex, I just want to see it
> work.
> 
> I would have expected inputStream to give the same information back from
> an "ATI" command as minicom provides, but instead inputStream only sees
> the "ATI" I put onto the outputStream.
> 
> Have I missed something?
> 
> 
> Cheers,
> S.
> 



From sds at dcs.gla.ac.uk  Wed Jun  7 12:11:40 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Wed, 07 Jun 2006 19:11:40 +0100
Subject: [Rxtx] Expected RXTX behaviour?
Message-ID: <1149703900.30891.19.camel@addu>

Hi,

I managed to get RXTX to compile for my iPAQ following my previous post
to this list. Quick query though:

I want to be able to issue AT commands to a device, and interpret the
responses. For this, I assume I do the following, in psuedo-form:

	CommPortIdentifier.getPortIdentifiers();
	// find the correct device id
	serialPort= (SerialPort)portID.open("Test");
	// Set parameters and flow control
	outputStream= serialPort.getOutputStream();
	inputStream=  serialPort.getInputStream();

... following this, I spawn a thread to respond to DATA_AVAILABLE events
on serialPort with inputStream, and occasionally write and flush an
"ATI" onto the outputStream. Nothing complex, I just want to see it
work.

I would have expected inputStream to give the same information back from
an "ATI" command as minicom provides, but instead inputStream only sees
the "ATI" I put onto the outputStream.

Have I missed something?


Cheers,
S.




From joachim at buechse.de  Wed Jun  7 09:02:13 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 7 Jun 2006 17:02:13 +0200
Subject: [Rxtx] Update of build process for OSX (XCode project)
Message-ID: <62EC47B1-46BD-4ECA-B9EC-C4061D147CDA@buechse.de>

With the help of Dmitry Markman and Brian Schilling I have updated  
(and largely simplifed) the XCode project file for Mac OS X.

Changes:
- compiles a universal binary library with intel=OSX10.4+, ppc=OSX10.2 
+ support
- compiles the Java sources into a JRE1.1 compatible, compressed jar.

Please test on your configuration, especially if you have computers  
running 10.2/10.3 or intel.

Best regards,
Joachim


From joachim at buechse.de  Wed Jun  7 14:36:37 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 7 Jun 2006 22:36:37 +0200
Subject: [Rxtx] Expected RXTX behaviour?
In-Reply-To: <1149705403.30891.25.camel@addu>
References: <1149703900.30891.19.camel@addu> <1149705403.30891.25.camel@addu>
Message-ID: <D3AD6EAF-27BB-455E-9697-86C1121920C3@buechse.de>

Echoing is a feature of the modem. Try ATE0 which works with most  
"rockwell" compatible modems.

Regards,
Joachim


On 07.06.2006, at 20:36, Stephen Strowes wrote:

> Apologies, caught the problem. Had to append '\r' to the end of the AT
> string. A non obvious but stupid mistake... :-)
>
> Final quick question though: How might I stop the echoing of
> outputStream data back into the inputStream? I still see the ATI
> commands on the inputStream, along with the output from the device.
>
>
> Cheers,
> S.
>
>
>
> On Wed, 2006-06-07 at 19:11 +0100, Stephen Strowes wrote:
>> Hi,
>>
>> I managed to get RXTX to compile for my iPAQ following my previous  
>> post
>> to this list. Quick query though:
>>
>> I want to be able to issue AT commands to a device, and interpret the
>> responses. For this, I assume I do the following, in psuedo-form:
>>
>> 	CommPortIdentifier.getPortIdentifiers();
>> 	// find the correct device id
>> 	serialPort= (SerialPort)portID.open("Test");
>> 	// Set parameters and flow control
>> 	outputStream= serialPort.getOutputStream();
>> 	inputStream=  serialPort.getInputStream();
>>
>> ... following this, I spawn a thread to respond to DATA_AVAILABLE  
>> events
>> on serialPort with inputStream, and occasionally write and flush an
>> "ATI" onto the outputStream. Nothing complex, I just want to see it
>> work.
>>
>> I would have expected inputStream to give the same information  
>> back from
>> an "ATI" command as minicom provides, but instead inputStream only  
>> sees
>> the "ATI" I put onto the outputStream.
>>
>> Have I missed something?
>>
>>
>> Cheers,
>> S.
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From g_petrini at yahoo.it  Thu Jun  8 01:41:58 2006
From: g_petrini at yahoo.it (Giacomo Petrini)
Date: Thu, 8 Jun 2006 09:41:58 +0200 (CEST)
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from FieldTalk
Message-ID: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>

Hi,
I'm evaluating the library for the modbus protocol
from FieldTalk
(http://www.modbusdriver.com/fieldtalk/.
I'm using J2SE 5.0 and RXTX 2.1 on win XP.
The problem is that the modbus lib has a method (the
openProtocol method, but maybe there are others) tha
throws the
javax.comm.UnsupportedCommOperationException.
Now, in RXTX 2.1 the namespace has changed in gnu.io,
so the modbus library doesn't work anymore (it look
for things in javax.comm). I've already sent an email
to fieldtalk to see if they are aware of the problem.
The solution should be to use JavaComm + RXTX 2.0. But
I've read somewhere that JavaComm 2.0 does not work
with Java 5.0 and JavaComm 3.0 does not work with RXTX
2.0 so I don't know what to do.

Any ideas?

Thanks Jack

PS: can you make a CC to my personal email
(g_petrini at yahoo.it) too please?

Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 


From rxtx at tapastda.co.uk  Thu Jun  8 02:27:57 2006
From: rxtx at tapastda.co.uk (rxtx@tapastda.co.uk)
Date: Thu, 08 Jun 2006 09:27:57 +0100
Subject: [Rxtx] Win XP and Infrared based serial port
Message-ID: <4487DF8D.5050807@tapastda.co.uk>

I'm attempting to use RXTX 2.1.7 on Win XP with J2SE 5.0 to communicate with a
GSM mobile using a COM port. A peculiarity that I've seen is that whilst I can
communicate successfully with a mobile which uses an infrared based COM port
using the SUN provided javax.comm (v2.0) I cannot use RXTX because it fails to
read anything from the port (i.e. read timeout always occurs returning zero bytes).

I assumed that this could be the result of flow control problems and thus I've
tried setting either software or hardware based flow control on the port however
this has no affect.

Can you suggest any other port configuration changes which might be required to
make such a port work with RXTX.

Thanks
Stu
-- 
Stuart
Tapastda Limited


From tjarvi at qbang.org  Thu Jun  8 05:17:12 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 8 Jun 2006 05:17:12 -0600 (MDT)
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from
	FieldTalk
In-Reply-To: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
References: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606080504480.9856@www>

On Thu, 8 Jun 2006, Giacomo Petrini wrote:

> Hi,
> I'm evaluating the library for the modbus protocol
> from FieldTalk
> (http://www.modbusdriver.com/fieldtalk/.
> I'm using J2SE 5.0 and RXTX 2.1 on win XP.
> The problem is that the modbus lib has a method (the
> openProtocol method, but maybe there are others) tha
> throws the
> javax.comm.UnsupportedCommOperationException.
> Now, in RXTX 2.1 the namespace has changed in gnu.io,
> so the modbus library doesn't work anymore (it look
> for things in javax.comm). I've already sent an email
> to fieldtalk to see if they are aware of the problem.
> The solution should be to use JavaComm + RXTX 2.0. But
> I've read somewhere that JavaComm 2.0 does not work
> with Java 5.0 and JavaComm 3.0 does not work with RXTX
> 2.0 so I don't know what to do.
>
> Any ideas?
>
> Thanks Jack
>


Hi Jack

There are plans for Sun to rerelease JavaComm 2.0 mentioned in the rxtx 
mail-list archives.  When this happens rxtx will release a current rxtx 
2.0 library that works with it.

There are no dates promised by either side but rxtx will do it as soon as 
possible after Sun's rerelease.  Just to give you a feel for the time 
frame, this started last year and no significant progress has been made. 
There have been friendly talks pointing towards solutions (rerelease 2.0) 
but that does not get your application working today.  rxtx is preparing 
for its second release in gnu.io since then.

--
Trent Jarvi
tjarvi at qbang.org




From jredman at ergotech.com  Thu Jun  8 08:47:23 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 08 Jun 2006 08:47:23 -0600
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from
	FieldTalk
In-Reply-To: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
References: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
Message-ID: <4488387B.6040903@ergotech.com>

You could always try a different library, eg.

http://sourceforge.net/projects/jamod

I've only used the slave side since we have our own implementation of 
Modbus Client (and a host of other PLC protocols).  However the client 
side seems to be pretty well supported and fairly widely used.  Since 
the source is there you could change to gnu.io.

I think I should take more of an interest in this issue.  We generally 
run 1.4.2 on Linux, but also have some J9 and old platforms that we 
support that are basically Personal Java.  5.0 on Linux has some 
horrible MDI bugs, to the point of being unusable.   Sounds as though we 
are going to have code compatibility problems across these platforms.

Jim


Giacomo Petrini wrote:
> Hi,
> I'm evaluating the library for the modbus protocol
> from FieldTalk
> (http://www.modbusdriver.com/fieldtalk/.
> I'm using J2SE 5.0 and RXTX 2.1 on win XP.
> The problem is that the modbus lib has a method (the
> openProtocol method, but maybe there are others) tha
> throws the
> javax.comm.UnsupportedCommOperationException.
> Now, in RXTX 2.1 the namespace has changed in gnu.io,
> so the modbus library doesn't work anymore (it look
> for things in javax.comm). I've already sent an email
> to fieldtalk to see if they are aware of the problem.
> The solution should be to use JavaComm + RXTX 2.0. But
> I've read somewhere that JavaComm 2.0 does not work
> with Java 5.0 and JavaComm 3.0 does not work with RXTX
> 2.0 so I don't know what to do.
> 
> Any ideas?
> 
> Thanks Jack
> 
> PS: can you make a CC to my personal email
> (g_petrini at yahoo.it) too please?
> 
> Chiacchiera con i tuoi amici in tempo reale! 
>  http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  8 18:17:23 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 08 Jun 2006 17:17:23 -0700
Subject: [Rxtx] rxtx access is denied error
Message-ID: <4488BE13.2050706@dupreeinc.com>

Hello,

I have been trying to replace the commapi from sun with rxtx for a 
project that communicates with a serial port that is a USB-Serial 
interface.  To be exact, I am using the FTDI VCP driver with one of 
their modules connected to a windows XP system.

I have the RXTX package working pretty well as long as nothing goes wrong.

If a user disconnects the USB port while my java application is running, 
my application goes into an endless loop with lots of messages in the  
errors stream  like the ones below:

    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(481):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.


I believe when this happens the COM port completely disappears and the 
rxtx driver has a heart attack.  Obviously, the user should not do this, 
but my application needs to ideally, correct the situation or as a worse 
case, terminate with a little dignity.  Currently, I have not figured 
out how to catch this error.

The closest I have come is to trap an exception to my input stream read  
that says "No error in readByte"  This error appears to be outside of 
the endless loop of the errors listed above.

Does anybody have an idea of how to identify and trap this error?  Any 
suggestions on how to gracefully recover from it would be greatly 
appreciated!

Thank you for your time,

Doug Thistlethwaite




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060608/9cfca302/attachment-0010.html

From tjarvi at qbang.org  Thu Jun  8 20:54:17 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 8 Jun 2006 20:54:17 -0600 (MDT)
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <4488BE13.2050706@dupreeinc.com>
References: <4488BE13.2050706@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606082022580.1323@www>

On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I have been trying to replace the commapi from sun with rxtx for a project 
> that communicates with a serial port that is a USB-Serial interface.  To be 
> exact, I am using the FTDI VCP driver with one of their modules connected to 
> a windows XP system.
>
> I have the RXTX package working pretty well as long as nothing goes wrong.
>
> If a user disconnects the USB port while my java application is running, my 
> application goes into an endless loop with lots of messages in the  errors 
> stream  like the ones below:
>
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(481):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>
>
> I believe when this happens the COM port completely disappears and the rxtx 
> driver has a heart attack.  Obviously, the user should not do this, but my 
> application needs to ideally, correct the situation or as a worse case, 
> terminate with a little dignity.  Currently, I have not figured out how to 
> catch this error.
>
> The closest I have come is to trap an exception to my input stream read  that 
> says "No error in readByte"  This error appears to be outside of the endless 
> loop of the errors listed above.
>
> Does anybody have an idea of how to identify and trap this error?  Any 
> suggestions on how to gracefully recover from it would be greatly 
> appreciated!
>

Hi Doug

Sadly I don't have a quick solution for you.

Termios has no knowlage about the JVM so it wont be throwing exceptions 
you can catch.

We can return error and set the error number to something reasonable that 
results in an exception.  The No Error message simply means we did not set 
an error number in termios.c.  Those are the line numbers in the code you 
see.  SerialImp.c realizes it errored but does not know much more yet. 
Everything touching the file descriptor is going to error after the port 
is gone presumably.

We don't currently have a plan in place for vanishing (or appearing) com 
ports.

Another example of what we need to think about is what happens if you 
start your application and then plug in the dongle?  Or what if you unplug 
and then plug it in again?

So in each of these three cases, what would the behavior of the (yet to 
be) correct implementation do?

How will the enumerated ports be handled during these changes?

There can also be hints from the OS that could be taken into 
consideration.

We can probably get some exceptions thrown that make sense and null the 
file descriptor when it happens to prevent io attempts.  That would be a 
crude way to let applications know something strange has happened.

Is anyone else tinkering with this problem?

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  9 01:31:29 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 9 Jun 2006 09:31:29 +0200
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <Pine.LNX.4.61.0606082022580.1323@www>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
Message-ID: <AC6EDDDD-0A64-401F-B16B-E484788CDF4A@buechse.de>

Hello Trent,

I am not tinkering with this on the Source Level - but I think it  
should work pretty much the same way as it currently does in OSX.  
When the port goes away you get an IOException thrown for any read/ 
write. It will no longer be in the list of ports from  
CommPortIdentifier.getPortIdentifiers(). When a port (re-)appears it  
is added to the list. It's up to the application to re-check the list  
from time to time.

On Windows you can't do much better then that, because the ports  
don't have useful names. Which USB "virtual com port" is on which  
COMx depends on the order the devices were added. So reconnecting to  
the same device may mean connecting to another port.

Regarding the exception thrown: it would be nice to use an  
IOException subclass but the Exception message should definetly be  
informative also as most applications may want to keep compatibility  
with javax.comm.

Regards,
Joachim


On 09.06.2006, at 04:54, Trent Jarvi wrote:

> On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:
>
>> Hello,
>>
>> I have been trying to replace the commapi from sun with rxtx for a  
>> project
>> that communicates with a serial port that is a USB-Serial  
>> interface.  To be
>> exact, I am using the FTDI VCP driver with one of their modules  
>> connected to
>> a windows XP system.
>>
>> I have the RXTX package working pretty well as long as nothing  
>> goes wrong.
>>
>> If a user disconnects the USB port while my java application is  
>> running, my
>> application goes into an endless loop with lots of messages in  
>> the  errors
>> stream  like the ones below:
>>
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (481):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>
>>
>> I believe when this happens the COM port completely disappears and  
>> the rxtx
>> driver has a heart attack.  Obviously, the user should not do  
>> this, but my
>> application needs to ideally, correct the situation or as a worse  
>> case,
>> terminate with a little dignity.  Currently, I have not figured  
>> out how to
>> catch this error.
>>
>> The closest I have come is to trap an exception to my input stream  
>> read  that
>> says "No error in readByte"  This error appears to be outside of  
>> the endless
>> loop of the errors listed above.
>>
>> Does anybody have an idea of how to identify and trap this error?   
>> Any
>> suggestions on how to gracefully recover from it would be greatly
>> appreciated!
>>
>
> Hi Doug
>
> Sadly I don't have a quick solution for you.
>
> Termios has no knowlage about the JVM so it wont be throwing  
> exceptions
> you can catch.
>
> We can return error and set the error number to something  
> reasonable that
> results in an exception.  The No Error message simply means we did  
> not set
> an error number in termios.c.  Those are the line numbers in the  
> code you
> see.  SerialImp.c realizes it errored but does not know much more yet.
> Everything touching the file descriptor is going to error after the  
> port
> is gone presumably.
>
> We don't currently have a plan in place for vanishing (or  
> appearing) com
> ports.
>
> Another example of what we need to think about is what happens if you
> start your application and then plug in the dongle?  Or what if you  
> unplug
> and then plug it in again?
>
> So in each of these three cases, what would the behavior of the  
> (yet to
> be) correct implementation do?
>
> How will the enumerated ports be handled during these changes?
>
> There can also be hints from the OS that could be taken into
> consideration.
>
> We can probably get some exceptions thrown that make sense and null  
> the
> file descriptor when it happens to prevent io attempts.  That would  
> be a
> crude way to let applications know something strange has happened.
>
> Is anyone else tinkering with this problem?
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From doug at dupreeinc.com  Fri Jun  9 13:09:58 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 09 Jun 2006 12:09:58 -0700
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <Pine.LNX.4.61.0606082022580.1323@www>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
Message-ID: <4489C786.9050504@dupreeinc.com>


Ideally, it would be nice if it would throw an exception and terminate 
the loop.  I am still trying to figure out how to detect the condition 
and recover form it in some form...  I am getting the "No error in 
readByte" exception in my serialEvent() method after an input stream 
read.  It appears to me that the only graceful recovery is to close the 
port and then reopen it when it becomes available.  I can pass the event 
up to the update method in my main frame, but I still can't close the 
port from within that thread.  Any suggestions on how to pass this event 
to a location where the port can be safely closed?

Re: Slow startup in windows XP
I have been looking into this a little closer and have found out the 
following:
System Windows XP Pro 3GHz dual core with 1GB RAM and NO parallel port.
Starting the SerialDemo included with the commapi using the rxtx instead 
of javax.comm takes 60 seconds.
Starting the SerialDemo using rxrx with the rxtxParallel.dll file 
removed takes about 20 seconds.
Modify initialize in RXRXCommDriver.java to not test the parallel ports 
takes less than 1 second.

It would be nice if the initialize routine could detect the presence of 
rxtxParallel.dll file and just skip the whole process if not present.  
Is there an easy way to check for the presence of this file without 
running the parallel port test?

Doug


 

Trent Jarvi wrote:

>On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:
>...
>  
>
>
>Hi Doug
>
>Sadly I don't have a quick solution for you.
>
>Termios has no knowlage about the JVM so it wont be throwing exceptions 
>you can catch.
>
>We can return error and set the error number to something reasonable that 
>results in an exception.  The No Error message simply means we did not set 
>an error number in termios.c.  Those are the line numbers in the code you 
>see.  SerialImp.c realizes it errored but does not know much more yet. 
>Everything touching the file descriptor is going to error after the port 
>is gone presumably.
>
>We don't currently have a plan in place for vanishing (or appearing) com 
>ports.
>
>Another example of what we need to think about is what happens if you 
>start your application and then plug in the dongle?  Or what if you unplug 
>and then plug it in again?
>
>So in each of these three cases, what would the behavior of the (yet to 
>be) correct implementation do?
>
>How will the enumerated ports be handled during these changes?
>
>There can also be hints from the OS that could be taken into 
>consideration.
>
>We can probably get some exceptions thrown that make sense and null the 
>file descriptor when it happens to prevent io attempts.  That would be a 
>crude way to let applications know something strange has happened.
>
>Is anyone else tinkering with this problem?
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060609/911ed787/attachment-0010.html

From Ugo.Landini at Sun.COM  Fri Jun  2 14:23:47 2006
From: Ugo.Landini at Sun.COM (Ugo Landini)
Date: Fri, 02 Jun 2006 22:23:47 +0200
Subject: [Rxtx] OSX 10.4.7 and usb
Message-ID: <44809E53.2070905@sun.com>

Hi, I have installed the library and the native libraries on OSX 10.4.7. 
Then I have run this simple code:

...
while (portList.hasMoreElements()) {
             portId = (CommPortIdentifier) portList.nextElement();
             System.out.println("-> " + portId.getName() + " Port Type:" 
+ portId.getPortType());
...

and the output is:

Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7

Ports found:
-> /dev/tty.Bluetooth-PDA-Sync Port Type:1
-> /dev/cu.Bluetooth-PDA-Sync Port Type:1
-> /dev/tty.Bluetooth-Modem Port Type:1
-> /dev/cu.Bluetooth-Modem Port Type:1

I can't see any USB ports... with javax.comm on linux I could see the 
/dev/ttyUSB stuff, but that's not the case with OSX. Any idea?

tia

uL


From tod at todbot.com  Sun Jun 11 12:04:37 2006
From: tod at todbot.com (Tod E. Kurt)
Date: Sun, 11 Jun 2006 11:04:37 -0700
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <44809E53.2070905@sun.com>
References: <44809E53.2070905@sun.com>
Message-ID: <E2EB14A1-20A7-4611-8F1A-E3D2ABE41F48@todbot.com>

A dumb question, but: do you have the USB serial adapters plugged  
in?  They only show up in /dev when plugged in.  Also, you can verify  
they exist independent of RXTX by doing something like "ls -l /dev/ 
cu.*".

On Jun 2, 2006, at 1:23 PM, Ugo Landini wrote:

> Hi, I have installed the library and the native libraries on OSX  
> 10.4.7.
> Then I have run this simple code:
>
> ...
> while (portList.hasMoreElements()) {
>              portId = (CommPortIdentifier) portList.nextElement();
>              System.out.println("-> " + portId.getName() + " Port  
> Type:"
> + portId.getPortType());
> ...
>
> and the output is:
>
> Experimental:  JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
>
> Ports found:
> -> /dev/tty.Bluetooth-PDA-Sync Port Type:1
> -> /dev/cu.Bluetooth-PDA-Sync Port Type:1
> -> /dev/tty.Bluetooth-Modem Port Type:1
> -> /dev/cu.Bluetooth-Modem Port Type:1
>
> I can't see any USB ports... with javax.comm on linux I could see the
> /dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>
> tia
>
> uL
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>



From lyon at docjava.com  Sun Jun 11 12:14:50 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Sun, 11 Jun 2006 14:14:50 -0400
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <44809E53.2070905@sun.com>
References: <44809E53.2070905@sun.com>
Message-ID: <p06020444c0b20de7d248@[192.168.1.152]>

>Hi Ugo,

Do you have any USB serial ports (like the keyspan 19-HS) plugged
into the mac?
Thanks!
  - DL


>Hi, I have installed the library and the native libraries on OSX 10.4.7.
>Then I have run this simple code:
>
>...
>while (portList.hasMoreElements()) {
>              portId = (CommPortIdentifier) portList.nextElement();
>              System.out.println("-> " + portId.getName() + " Port Type:"
>+ portId.getPortType());
>...
>
>and the output is:
>
>Experimental:  JNI_OnLoad called.
>Stable Library
>=========================================
>Native lib Version = RXTX-2.1-7
>Java lib Version   = RXTX-2.1-7
>
>Ports found:
>-> /dev/tty.Bluetooth-PDA-Sync Port Type:1
>-> /dev/cu.Bluetooth-PDA-Sync Port Type:1
>-> /dev/tty.Bluetooth-Modem Port Type:1
>-> /dev/cu.Bluetooth-Modem Port Type:1
>
>I can't see any USB ports... with javax.comm on linux I could see the
>/dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>
>tia
>
>uL
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx



From dmarkman at mac.com  Sun Jun 11 14:30:27 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Sun, 11 Jun 2006 16:30:27 -0400
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <p06020444c0b20de7d248@[192.168.1.152]>
References: <44809E53.2070905@sun.com> <p06020444c0b20de7d248@[192.168.1.152]>
Message-ID: <B9C1606B-4339-4564-A175-FE83DFFA7D76@mac.com>

afaik
10.4.7 wasn't released yet
it will soon, no doubts


On Jun 11, 2006, at 2:14 PM, Dr. Douglas Lyon wrote:

>> Hi Ugo,
>
> Do you have any USB serial ports (like the keyspan 19-HS) plugged
> into the mac?
> Thanks!
>   - DL
>
>
>> Hi, I have installed the library and the native libraries on OSX  
>> 10.4.7.
>> Then I have run this simple code:
>>
>> ...
>> while (portList.hasMoreElements()) {
>>              portId = (CommPortIdentifier) portList.nextElement();
>>              System.out.println("-> " + portId.getName() + " Port  
>> Type:"
>> + portId.getPortType());
>> ...
>>
>> and the output is:
>>
>> Experimental:  JNI_OnLoad called.
>> Stable Library
>> =========================================
>> Native lib Version = RXTX-2.1-7
>> Java lib Version   = RXTX-2.1-7
>>
>> Ports found:
>> -> /dev/tty.Bluetooth-PDA-Sync Port Type:1
>> -> /dev/cu.Bluetooth-PDA-Sync Port Type:1
>> -> /dev/tty.Bluetooth-Modem Port Type:1
>> -> /dev/cu.Bluetooth-Modem Port Type:1
>>
>> I can't see any USB ports... with javax.comm on linux I could see the
>> /dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>>
>> tia
>>
>> uL
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman



From tjarvi at qbang.org  Sun Jun 11 18:52:59 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 11 Jun 2006 18:52:59 -0600 (MDT)
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <4489C786.9050504@dupreeinc.com>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
	<4489C786.9050504@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606111845430.7274@www>

On Fri, 9 Jun 2006, Doug Thistlethwaite wrote:

>
> Ideally, it would be nice if it would throw an exception and terminate the 
> loop.  I am still trying to figure out how to detect the condition and 
> recover form it in some form...  I am getting the "No error in readByte" 
> exception in my serialEvent() method after an input stream read.  It appears 
> to me that the only graceful recovery is to close the port and then reopen it 
> when it becomes available.  I can pass the event up to the update method in 
> my main frame, but I still can't close the port from within that thread.  Any 
> suggestions on how to pass this event to a location where the port can be 
> safely closed?
>

I've gone through and cleaned up the termios.c layer.  I need to get to a 
windows machine with a USB dongle and see where the ioctl() is being 
called.  Probably the eventLoop.  But all of the ioctls should probably 
result in an IOException during this condition.

I'll probably finish this up Monday night when I can borrow a USB 
dongle.

There is no point in putting the code into CVS yet.  If you are tinkering 
I can mail the patch.  I think we will want to make a couple fixes in 
SerialImp.c to handle errors before it's ready.

--
Trent Jarvi
tjarvi at qbang.org



From bob_tai2001 at yahoo.com  Mon Jun 12 09:42:14 2006
From: bob_tai2001 at yahoo.com (Bob Tai)
Date: Mon, 12 Jun 2006 08:42:14 -0700 (PDT)
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to RXTX
	again
Message-ID: <20060612154214.58219.qmail@web32804.mail.mud.yahoo.com>


thank you Paul, Joachim, Trent and everyone try to
workout the java comm and Rxtx situation.  At least
now I have something that is solid enough to make my
decision.  

thank you,
     Bob

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From Ralph.Buchfelder at gmx.net  Mon Jun 12 15:30:20 2006
From: Ralph.Buchfelder at gmx.net (Ralph Buchfelder)
Date: Mon, 12 Jun 2006 23:30:20 +0200
Subject: [Rxtx] rxtx binaries or porting to XSCALE Windows Mobile 2003 / 2005
Message-ID: <448DDCEC.7090506@gmx.net>

dear group,

i have been carefully reading your homepage, wiki and archives
but there seems to be no detailled information on porting to Windows 
Mobile/CE.

as far as i understood from the 'porting' section you can do porting to 
winCE. but how? do i only need to obtain the sourcecode (which one?) and 
compile this in Microsoft eMbedded Visual C++ for ARM/Xscale?
Any other ways?


unfortunately i must admit that i do have little linux skills but i have 
made my way through gcc and makefiles. right now i need to implement com 
  communication in a J2ME application and found your website as >the< 
solution.

best regards
Ralph Buchfelder

University of Regensburg
Department of Geography

PS: i dont care about Javacomm compliancy (ie. 2.0 or 2.1) - i just need 
a working serial port API in IBM J9 VM.


From paul.klissner at sun.com  Wed Jun 14 18:12:58 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Wed, 14 Jun 2006 17:12:58 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
Message-ID: <4490A60A.9090305@sun.com>

Hello RxTx community,

I finally think I have a compromise in place that will stand in the gap.

If you go to http://www.sun.com and search for javax.comm, you'll
get taken to a download page, where now users can get a copy of the
comm.jar file out of 2.0.3, along with just a license and a README.

I trust this will suffice until such time as RxTx decided to implement
their own java classes or we can get a JSR going to mitigate some
of the problems (the readme in the comm.jar 2.0.3 zip file
contains my thoughts on that).

Thanks,
Paul



From tjarvi at qbang.org  Wed Jun 14 21:15:35 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 14 Jun 2006 21:15:35 -0600 (MDT)
Subject: [Rxtx] rxtx-2.0-7 (final) src is in CVS
Message-ID: <Pine.LNX.4.61.0606142100500.2742@www>


I wasn't expecting to be working on rxtx 2.0 tonight :)

Thanks go out to Paul Klissner for his work in making the coming release 
of rxtx-2.0-7 possible for users that require package javax.comm on many 
platforms.

Most people know that rxtx 2.0 is for use with Sun's CommAPI 2.0 for 
Solaris or the Generic CommAPI 2.0-3 available for download at Sun.  If 
you need javax.comm packages on many platforms, you are probably 
interested.  If you use rxtx 2.1 in package gnu.io, then you are not going 
to care much.

I've tried to update the rxtx 2.0 src directory in preparation for 
rxtx-2.0-7 (final).  Linux should compile.  Windows will compile if you 
generate your own .def files (I'll generate these tomorrow).  If you have 
some time to do basic testing of the source, I'd appreciate it.  The 
source should be good but you may find classes not found.  This source is 
a backport from rxtx 2.1.

I wanted to get things started so anyone interested on Mac OS X could get 
a head start.

All of this is in CVS.  http://www.rxtx.org/cvs.html

I suspect we will have binaries for testing in a couple days if you are 
unable to compile.   Consider this a smoke test.

--
Trent Jarvi
tjarvi at qbang.org


From legolas.w at gmail.com  Wed Jun 14 22:04:28 2006
From: legolas.w at gmail.com (Legolas Woodland)
Date: Wed, 14 Jun 2006 21:04:28 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <4490A60A.9090305@sun.com>
References: <4490A60A.9090305@sun.com>
Message-ID: <87ee9b170606142104p745fcef0vea622fbc8f528bfc@mail.gmail.com>

is there anything new in this version of javax.comm ?
thanks


On 6/14/06, Paul Klissner <paul.klissner at sun.com> wrote:
>
> Hello RxTx community,
>
> I finally think I have a compromise in place that will stand in the gap.
>
> If you go to http://www.sun.com and search for javax.comm, you'll
> get taken to a download page, where now users can get a copy of the
> comm.jar file out of 2.0.3, along with just a license and a README.
>
> I trust this will suffice until such time as RxTx decided to implement
> their own java classes or we can get a JSR going to mitigate some
> of the problems (the readme in the comm.jar 2.0.3 zip file
> contains my thoughts on that).
>
> Thanks,
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060614/5ff4dfbc/attachment-0010.html

From joachim at buechse.de  Thu Jun 15 07:22:48 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 15 Jun 2006 15:22:48 +0200
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
Message-ID: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>

Good day!

Some of my users report problems using RXTX 2.1.7 on Windows98 to  
communicate with an FTDI FT245BM chip (using their latest VCP  
driver). Either no ports are being shown (ie returned form  
CommPortIdentifier.getPortIdentifiers()) or the transfers fail.

Did anyone run into similar Problems with Win98??

Best regards,
Joachim



From ajmas at sympatico.ca  Thu Jun 15 08:12:28 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Thu, 15 Jun 2006 10:12:28 -0400
Subject: [Rxtx] API change question
Message-ID: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

How closely do you follow the Java Communication API spec? The reason I ask is because I would be interested in augmenting the CommPortIdentifier class to include a getDisplayName() method. By default it would return the same value as getName(), but would provide the possibility of displaying a 'user friendly' name, for platforms where the display name is not the same as the device name. An example of this is on MacOS X, where currently the names seem to be of the form /dev/cu.* and /dev/tty.*, yet what the expects to see is simply the part after the full-stop. Although I could move this logic into the Java code, it would be nice to see it transparent to the Java code.

Andre




From ajmas at sympatico.ca  Thu Jun 15 08:16:22 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Thu, 15 Jun 2006 10:16:22 -0400
Subject: [Rxtx] Package to use
Message-ID: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

While the Java API spec refers to javax.comm, I see that only gnu.io is provide by the rxtx project. Should our projects refer to the gnu.io package or the javax.comm API?

Andre



From joachim at buechse.de  Thu Jun 15 08:45:05 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 15 Jun 2006 16:45:05 +0200
Subject: [Rxtx] API change question
In-Reply-To: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>

Hello Andre,

the /dev/cu and /dev/tty have different semantics on OS X. It is much  
more than a simply naming issue to unify them, see my recent mail to  
the list...

Best regards,
Joachim


On 15.06.2006, at 16:12, Andre-John Mas wrote:

> Hi,
>
> How closely do you follow the Java Communication API spec? The  
> reason I ask is because I would be interested in augmenting the  
> CommPortIdentifier class to include a getDisplayName() method. By  
> default it would return the same value as getName(), but would  
> provide the possibility of displaying a 'user friendly' name, for  
> platforms where the display name is not the same as the device  
> name. An example of this is on MacOS X, where currently the names  
> seem to be of the form /dev/cu.* and /dev/tty.*, yet what the  
> expects to see is simply the part after the full-stop. Although I  
> could move this logic into the Java code, it would be nice to see  
> it transparent to the Java code.
>
> Andre
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From lyon at docjava.com  Thu Jun 15 10:16:29 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Thu, 15 Jun 2006 12:16:29 -0400
Subject: [Rxtx] cu.modem != /dev/ttya on mac.
In-Reply-To: <763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
	<763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>
Message-ID: <p0602046cc0b7378a95b0@[192.168.1.152]>

>Hi All,

I think that Joachim is correct. For the longest time,
I have been trying to figure out how to direct dial using
the cu.modem on the mac under os x.

As a less-than-optimal approach to auto-dialing, I have used
a keyspan USB 19HS adapter, along with an external modem, to
obtain the dialing feature.

Ideally, it would be better to dial with the built-in modem...but that did not
always seem to work, for some reason. Have others had some experience with
using the built in modem for dialing on the mac?

Thanks!
  - Doug


>Hello Andre,
>
>the /dev/cu and /dev/tty have different semantics on OS X. It is much?
>more than a simply naming issue to unify them, see my recent mail to?
>the list...
>
>Best regards,
>Joachim
>



From doug at dupreeinc.com  Thu Jun 15 14:52:50 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 15 Jun 2006 13:52:50 -0700
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
In-Reply-To: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
References: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
Message-ID: <4491C8A2.8090108@dupreeinc.com>

Hi Joachim,

I have been doing a lot with the new FTDI driver with win XP and have 
not had that particular problem.  I did notice that the new driver 
(dated May19th, 2006) is only for XP, Server 2003, and 2000.  Are they 
trying to use the 2.00.00 drivers or the old 1.09.06 version.  I am 
using a FT232R based module, but it uses the same drivers and I assume 
it would have the same problems.  Let me know which driver they are 
using and I can load up a 98 system here and see if  I can duplicate the 
problem.

Doug

Joachim Buechse wrote:

>Good day!
>
>Some of my users report problems using RXTX 2.1.7 on Windows98 to  
>communicate with an FTDI FT245BM chip (using their latest VCP  
>driver). Either no ports are being shown (ie returned form  
>CommPortIdentifier.getPortIdentifiers()) or the transfers fail.
>
>Did anyone run into similar Problems with Win98??
>
>Best regards,
>Joachim
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From matthewhepp at yahoo.com  Thu Jun 15 17:34:47 2006
From: matthewhepp at yahoo.com (Matthew Hepp)
Date: Thu, 15 Jun 2006 16:34:47 -0700 (PDT)
Subject: [Rxtx] Wither the XCode project?
Message-ID: <20060615233447.48064.qmail@web50311.mail.yahoo.com>

Either I don't know how to properly use CVS (entirely possibl), or the XCode
project is not making through the update properly. Doing a "cvs update" against
2.1-7 creates an XCode folder in MACOSX_IDE, and therein a
LibSerialUniversal.xcodeproj, but trying to open it yields a "Unable to Open
Project - Project rxtx-devel/MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj
cannot be opened because it is missing its project.pbxproj file" error. Showing
package contents reveals just the cvs-related files. Perhaps this is why
previous xcode projects have been saved as an sit.hqx - to retain the resource
fork?

Can someone point me in the right direction?

Thanks,

Matt

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Thu Jun 15 19:53:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 19:53:06 -0600 (MDT)
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
In-Reply-To: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
References: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
Message-ID: <Pine.LNX.4.61.0606151944070.23137@www>

On Thu, 15 Jun 2006, Joachim Buechse wrote:

> Good day!
>
> Some of my users report problems using RXTX 2.1.7 on Windows98 to
> communicate with an FTDI FT245BM chip (using their latest VCP
> driver). Either no ports are being shown (ie returned form
> CommPortIdentifier.getPortIdentifiers()) or the transfers fail.
>
> Did anyone run into similar Problems with Win98??
>

Hi Joachim

It has been a long time since I've tested win98.  I know rxtx-2.1-7pre16 
did get testing on win98 with ~jdk 1.3 though.  I wonder if jdks are still 
tested on that platform.

With win98 you usually have older boxes.  They can be short on CPU and 
memory.  Enumeration should work but I could picture runtime performance 
issues on win98.

The enumeration problems could result from other copies of your 
application if various states of decay still holding onto the port.  When 
things go wrong, people also like to open other terminal software to see 
whats going on which can interfere.  You can't open a windows port with 
two apps.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Thu Jun 15 20:08:53 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 20:08:53 -0600 (MDT)
Subject: [Rxtx] API change question
In-Reply-To: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606151954270.23137@www>

On Thu, 15 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> How closely do you follow the Java Communication API spec?

I can explain how this worked in the past.  How we do it in the future is 
open for discussion.

In the past we have tried to follow it as close as possible in gnu.io 
(rxtx 2.1).  We have added extensions but try to discourage their use. 
The extensions are clearly marked as such in the source code and javadocs.

rxtx 2.0 was intended to be a strict implementation of part of the spec. 
We let Sun's interfaces decide what methods can be called. There are 
differences not covered by the spec such as default values.  Thats not 
intentional but rather hard to avoid.

--
Trent Jarvi
tjarvi at qbang.org





From tjarvi at qbang.org  Thu Jun 15 21:09:11 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 21:09:11 -0600 (MDT)
Subject: [Rxtx] Package to use
In-Reply-To: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606152026120.23137@www>

On Thu, 15 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> While the Java API spec refers to javax.comm, I see that only gnu.io is 
> provide by the rxtx project. Should our projects refer to the gnu.io 
> package or the javax.comm API?
>

Hi Andre

Lets see if I can give a fair and balanced answer to that.

If you are starting a new project and want to use RXTX, I would recommend 
using gnu.io.  The community support for gnu.io will not be going away 
anytime soon.  You can switch between gnu.io (2.1) and javax.comm (2.0) 
fairly easily.  They are not intended to be incompatible.  You just change 
package names and libs.

You can also consider the combination of rxtx 2.0 with Sun's commapi 
2.0-3.  This is considered a stop-gap measure by Sun for previous users of 
that combination.  Together rxtx 2.0 and Sun CommAPI 2.0 work in namespace 
javax.comm for programmers.

Finally, you can opt to just use Sun's oferrings in CommAPI 3.0 without 
rxtx.  That would be in namespace javax.comm also.  CommAPI 3.0 may be 
of more interest to you if you are looking at POS with Sun computers. 
Rxtx does not currently support the changes in CommAPI 3.0 or have firm 
plans to do so.  That does not mean we wouldn't implement them.  It just 
means nobody has contributed code yet.

You can't combine rxtx with CommAPI 3.0 for technical reasons that wont 
likely be fixed soon.

It's up to you as far as what you use.  We like to provide the freedom so 
you can choose.  Realistically, we will be supporting gnu.io mainly 
because we have some control over that name space and can support it.

Things may happen in the future that enable rxtx to provide more support 
in the javax namespace but that has not happened yet.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun 16 00:33:06 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 08:33:06 +0200
Subject: [Rxtx] Wither the XCode project?
In-Reply-To: <20060615233447.48064.qmail@web50311.mail.yahoo.com>
References: <20060615233447.48064.qmail@web50311.mail.yahoo.com>
Message-ID: <D30D660F-A49B-464E-AE4C-6B4563893682@buechse.de>

Hello Matthew,

could you please send me the contents of your

   rxtx-devel/CVS
   rxtx-devel/MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj/CVS

directories as a zip to my personal email address. This should  
indicate why the file is not checked out. I can see that it exists on  
the correct branch in the repository, so something must have gone  
wrong during the "cvs update"...

Best regards,
Joachim

On 16.06.2006, at 01:34, Matthew Hepp wrote:

> Either I don't know how to properly use CVS (entirely possibl), or  
> the XCode
> project is not making through the update properly. Doing a "cvs  
> update" against
> 2.1-7 creates an XCode folder in MACOSX_IDE, and therein a
> LibSerialUniversal.xcodeproj, but trying to open it yields a  
> "Unable to Open
> Project - Project rxtx-devel/MACOSX_IDE/XCode/ 
> LibSerialUniversal.xcodeproj
> cannot be opened because it is missing its project.pbxproj file"  
> error. Showing
> package contents reveals just the cvs-related files. Perhaps this  
> is why
> previous xcode projects have been saved as an sit.hqx - to retain  
> the resource
> fork?
>
> Can someone point me in the right direction?



From joachim at buechse.de  Fri Jun 16 10:41:20 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 18:41:20 +0200
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <p06230903c0b88613dca6@[10.0.1.7]>
References: <p06230903c0b88613dca6@[10.0.1.7]>
Message-ID: <03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>

Hello Bob,

until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was  
behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if  
Trent has migrated all recent changes from 2.1 to 2.0.

I have added the XCode project and updated documentation only to the  
gnu.io branch. Once the 2.0 implementation is up to date I will copy  
over the documentation/build files make them work.

Best regards,
Joachim

On 16.06.2006, at 18:07, Bob Jacobsen wrote:

> I'm one of the developers for the JMRI project, which provides  
> model railroad software in Java.  We've been using RXTX to provide  
> serial port access on MacOS X and Linux; we use the old javax.comm  
> 2.0 on Windows, OS/2 and Solaris.  Because of that, we need to stay  
> with RXTX 2.0, not 2.1
>
> We've been using the 2.0-pre17 installer for a long time, but it's  
> not compatible with Intel macs.
>
> Can you point me to where I can find the right files for RXTX 2.0  
> to package with the program?
>
> The current situation is confusing to me.  I've been pointed to  
> recent 2.1 versions (but we need the javax.comm names), to an even  
> older installer, etc.  I've been reading that some versions require  
> an installer, and others don't, but I haven't been able to figure  
> out which (if any) of those are where in CVS.
>
> I'd really appreciate a clear statement of what files to use and  
> what to do with them that I can pass on to our users.
>
> I'm more than happy to put files in the local classpath, have users  
> run an installer, or anything else.  Whatever is easiest for you.
>
> Thanks!  I really appreciate all that you do to keep RXTX working.
>
> Bob
> -- 
> Bob Jacobsen +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG



From joachim at buechse.de  Fri Jun 16 09:59:28 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 17:59:28 +0200
Subject: [Rxtx] Wither the XCode project?
In-Reply-To: <20060616150240.49464.qmail@web50309.mail.yahoo.com>
References: <20060616150240.49464.qmail@web50309.mail.yahoo.com>
Message-ID: <D9935E05-2B83-488D-86DD-42599E229052@buechse.de>

Hello Matthew,

you have checked out the trunk (which is the 2.0.7 javax.comm.xxx  
release). For rxtx-2.1.7 (gnu.io.xxx release) you need to check out  
the branch

      commapi-0-0-1

The easiest way to do this is to download the rxtx src archive,  
unpack it and then do a cvs up inside the decompressed tree.  
Optionally you could do a

      cvs co -r commapi-0-0-1

but this will take much longer!

Best regards,
Joachim

When you do a cvs status it will show the sticky tag.

41:~/jdevelop/rxtx-2.1-7r2 joachim$ cvs status README.OSX
===================================================================
File: README.OSX        Status: Up-to-date

    Working revision:    1.1.2.1
    Repository revision: 1.1.2.1 /usr/local/cvsroot/rxtx-devel/Attic/ 
README.OSX,v
    Sticky Tag:          commapi-0-0-1 (branch: 1.1.2)
    Sticky Date:         (none)
    Sticky Options:      (none)




On 16.06.2006, at 17:02, Matthew Hepp wrote:

> %cvs status README.MACOSX
> ===================================================================
> File: README.MACOSX     Status: Up-to-date
>
>    Working revision:    1.1
>    Repository revision: 1.1     /usr/local/cvsroot/rxtx-devel/ 
> README.MACOSX,v
>    Sticky Tag:          (none)
>    Sticky Date:         (none)
>    Sticky Options:      (none)



From tjarvi at qbang.org  Fri Jun 16 16:31:18 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Fri, 16 Jun 2006 16:31:18 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
Message-ID: <Pine.LNX.4.61.0606161630030.14139@www>

On Fri, 16 Jun 2006, Joachim Buechse wrote:

> Hello Bob,
>
> until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was
> behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if
> Trent has migrated all recent changes from 2.1 to 2.0.
>

The src/ directory and configure.in/configure files should be fine.  I 
have not touched the Mac OS X directories.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sat Jun 17 02:39:55 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sat, 17 Jun 2006 10:39:55 +0200
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <Pine.LNX.4.61.0606161630030.14139@www>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
Message-ID: <350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>

Hello Trent,

apparently the IOEXCL changes have not made it into 2.0. I will add  
them to achieve a minimal diff between 2.0 and 2.1.

One other thing that bugs me for a while...

Shouldn't we replace "if !defined(TIOCSERGETLSR) && !defined(WIN32)"  
by a definition of its own "if defined(DRAINTHREAD)"? I think this  
would make the code clearer for people starting to read it.

Regards,
Joachim


On 17.06.2006, at 00:31, Trent Jarvi wrote:

> On Fri, 16 Jun 2006, Joachim Buechse wrote:
>
>> Hello Bob,
>>
>> until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was
>> behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if
>> Trent has migrated all recent changes from 2.1 to 2.0.
>>
>
> The src/ directory and configure.in/configure files should be fine.  I
> have not touched the Mac OS X directories.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From tropicsu at hotmail.com  Sat Jun 17 09:32:48 2006
From: tropicsu at hotmail.com (Yoke K)
Date: Sat, 17 Jun 2006 15:32:48 +0000
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
Message-ID: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>

Hi,

I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to work with 
MAC OS X.
I am using iTegno 3000 - USB GPRS Modem.

Files in /dev and a symbolic link as follows:

crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 -> tty.usbserial

In my SendMessage.java, I have this line:
CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");

Appreciate any help ?

- Jon


Errors as follows:

>>INFO: SMSLib API for Java / v1.2.2
>>INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>INFO: JRE Version: 1.5.0_06
>>INFO: JRE Impl Version: 1.5.0_06-64
>>INFO: O/S: Mac OS X / ppc / 10.4.6
>>INFO: Using Wavecom (Generic) AT handler.

SendMessage(): Send a message.
  Using SMSLib API for Java v1.2.2

Connecting ..... :
>>INFO: CSerialDriver(): Connecting...
Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
>>INFO: CSerialDriver(): Disconnecting...
gnu.io.NoSuchPortException
        at 
gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:218)
        at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
        at org.smslib.CService.connect(CService.java:197)
        at SendMessage.main(SendMessage.java:38)

_________________________________________________________________
Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/



From tjarvi at qbang.org  Sat Jun 17 10:12:30 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 10:12:30 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
	<350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
Message-ID: <Pine.LNX.4.61.0606171010060.14139@www>

On Sat, 17 Jun 2006, Joachim Buechse wrote:

> Hello Trent,
>
> apparently the IOEXCL changes have not made it into 2.0. I will add
> them to achieve a minimal diff between 2.0 and 2.1.
>

Hi Joachim

As I recall the IOEXCL change was after 2.1-7.  I was just syncing with 
2.1-7.  We can release 2.1-8 and 2.0-8 with the same changes.

> One other thing that bugs me for a while...
>
> Shouldn't we replace "if !defined(TIOCSERGETLSR) && !defined(WIN32)"
> by a definition of its own "if defined(DRAINTHREAD)"? I think this
> would make the code clearer for people starting to read it.
>


Sure.  We can do that for -8.  The TIOCSERGETLSR code should be a special 
case not the expected.  I think only Linux uses it.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Sat Jun 17 10:48:21 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 10:48:21 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <Pine.LNX.4.61.0606171010060.14139@www>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
	<350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
	<Pine.LNX.4.61.0606171010060.14139@www>
Message-ID: <Pine.LNX.4.61.0606171047310.14139@www>

On Sat, 17 Jun 2006, Trent Jarvi wrote:

> On Sat, 17 Jun 2006, Joachim Buechse wrote:
>
>> Hello Trent,
>>
>> apparently the IOEXCL changes have not made it into 2.0. I will add
>> them to achieve a minimal diff between 2.0 and 2.1.
>>
>
> Hi Joachim
>
> As I recall the IOEXCL change was after 2.1-7.  I was just syncing with
> 2.1-7.  We can release 2.1-8 and 2.0-8 with the same changes.
>

We could just move to 2.1-8 and 2.0-8.

--
Trent Jarvi
tjarvi at qbang.org


From brian.t.lamb at gmail.com  Tue Jun 13 13:54:13 2006
From: brian.t.lamb at gmail.com (Brian Lamb)
Date: Tue, 13 Jun 2006 15:54:13 -0400
Subject: [Rxtx] Windows XP Installation
Message-ID: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>

I've not installed Java packages on Windows before and am unsure how to
proceed. All the documentation I've seen provides detailed instructions on
how to install on Linux or Solaris. I was wondering how to install rxtx on
Windows XP.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060613/6f68cd5c/attachment-0010.html

From tjarvi at qbang.org  Sat Jun 17 13:57:03 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 13:57:03 -0600 (MDT)
Subject: [Rxtx] Windows XP Installation
In-Reply-To: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>
References: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0606171356120.14139@www>

On Tue, 13 Jun 2006, Brian Lamb wrote:

> I've not installed Java packages on Windows before and am unsure how to
> proceed. All the documentation I've seen provides detailed instructions on
> how to install on Linux or Solaris. I was wondering how to install rxtx on
> Windows XP.
>

Hi Brian

Which rxtx version are you trying to install?

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sun Jun 18 10:41:44 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sun, 18 Jun 2006 18:41:44 +0200
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
References: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
Message-ID: <8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>

Hello Jon,

 From OSX's standpoint a symbolic link is not a device (as far as I  
know). What stops you from using tty.usbserial? Did you try hard- 
linking?

Regards,
Joachim

On 17.06.2006, at 17:32, Yoke K wrote:
> Hi,
>
> I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to  
> work with
> MAC OS X.
> I am using iTegno 3000 - USB GPRS Modem.
>
> Files in /dev and a symbolic link as follows:
>
> crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
> crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
> lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->  
> tty.usbserial
>
> In my SendMessage.java, I have this line:
> CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
>
> Appreciate any help ?
>
> - Jon
>
>
> Errors as follows:
>
>>> INFO: SMSLib API for Java / v1.2.2
>>> INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>> INFO: JRE Version: 1.5.0_06
>>> INFO: JRE Impl Version: 1.5.0_06-64
>>> INFO: O/S: Mac OS X / ppc / 10.4.6
>>> INFO: Using Wavecom (Generic) AT handler.
>
> SendMessage(): Send a message.
>   Using SMSLib API for Java v1.2.2
>
> Connecting ..... :
>>> INFO: CSerialDriver(): Connecting...
> Experimental:  JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
>>> INFO: CSerialDriver(): Disconnecting...
> gnu.io.NoSuchPortException
>         at
> gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java: 
> 218)
>         at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
>         at org.smslib.CService.connect(CService.java:197)
>         at SendMessage.main(SendMessage.java:38)
>
> _________________________________________________________________
> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Sun Jun 18 10:56:55 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 12:56:55 -0400
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>
References: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
	<8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>
Message-ID: <7B6834E3-F41D-46B6-B979-55466BC73859@sympatico.ca>

Have you been able to get any other software to talk with your
modem? What port is it using? Have tried using the cu.usbserial
instead?

Andre

On 18-Jun-06, at 12:41 , Joachim Buechse wrote:

> Hello Jon,
>
>  From OSX's standpoint a symbolic link is not a device (as far as I
> know). What stops you from using tty.usbserial? Did you try hard-
> linking?
>
> Regards,
> Joachim
>
> On 17.06.2006, at 17:32, Yoke K wrote:
>> Hi,
>>
>> I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to
>> work with
>> MAC OS X.
>> I am using iTegno 3000 - USB GPRS Modem.
>>
>> Files in /dev and a symbolic link as follows:
>>
>> crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
>> crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
>> lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->
>> tty.usbserial
>>
>> In my SendMessage.java, I have this line:
>> CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
>>
>> Appreciate any help ?
>>
>> - Jon
>>
>>
>> Errors as follows:
>>
>>>> INFO: SMSLib API for Java / v1.2.2
>>>> INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>>> INFO: JRE Version: 1.5.0_06
>>>> INFO: JRE Impl Version: 1.5.0_06-64
>>>> INFO: O/S: Mac OS X / ppc / 10.4.6
>>>> INFO: Using Wavecom (Generic) AT handler.
>>
>> SendMessage(): Send a message.
>>   Using SMSLib API for Java v1.2.2
>>
>> Connecting ..... :
>>>> INFO: CSerialDriver(): Connecting...
>> Experimental:  JNI_OnLoad called.
>> Stable Library
>> =========================================
>> Native lib Version = RXTX-2.1-7
>> Java lib Version   = RXTX-2.1-7
>>>> INFO: CSerialDriver(): Disconnecting...
>> gnu.io.NoSuchPortException
>>         at
>> gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:
>> 218)
>>         at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
>>         at org.smslib.CService.connect(CService.java:197)
>>         at SendMessage.main(SendMessage.java:38)
>>
>> _________________________________________________________________
>> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Sun Jun 18 17:33:08 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 19:33:08 -0400
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
Message-ID: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>

Hi,

I am have a program that I wrote in Java to communicate with a  
Bluetooth GPS device. I am
trying to get this working on my Mac, but I keep getting told that:

gnu.io.PortInUseException: Unknown Application

but

portIdentifier.isCurrentlyOwned()

returns false and when I do lsof on the device I am trying to connect  
to, I see no application
using it. As the same time if I go to the command line and use  
minicom I have no issues. The
exception happens with this call:

CommPort commPort = portIdentifier.open(null,0);

Any suggestions?

Andre


From ajmas at sympatico.ca  Sun Jun 18 17:45:11 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 19:45:11 -0400
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
Message-ID: <30245B30-682D-4EAE-8084-8227B719F10D@sympatico.ca>

BTW My code snippet is:

     private InputStream connectToSerial () throws IOException,  
Exception
     {
         InputStream in = null;

         Enumeration portEnum = CommPortIdentifier.getPortIdentifiers();
         while ( portEnum.hasMoreElements() )
         {
             CommPortIdentifier portIdentifier = (CommPortIdentifier)  
portEnum.nextElement();
             System.out.println(portIdentifier.getName() + " - " +  
portIdentifier.getPortType() );
         }

         CommPortIdentifier portIdentifier =  
CommPortIdentifier.getPortIdentifier("/dev/cu.BTGPS-SPPslave-1");
         System.out.println("current owner: " +  
portIdentifier.getCurrentOwner());
         if ( portIdentifier.isCurrentlyOwned() )
         {
             System.out.println("Error: Port is currently in use");
             return null;
         }
         else
         {
             CommPort commPort = portIdentifier.open(this.getClass 
().getName(),2000);

             if ( commPort instanceof SerialPort )
             {
                 SerialPort serialPort = (SerialPort) commPort;
                 serialPort.setSerialPortParams 
(4800,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE 
);
                 in = serialPort.getInputStream();

                 return in;
             }
             else
             {
                 System.out.println("Error: Only serial ports are  
handled.");
             }
         }


         return in;
     }


On 18-Jun-06, at 19:33 , Andr?-John Mas wrote:

> Hi,
>
> I am have a program that I wrote in Java to communicate with a
> Bluetooth GPS device. I am
> trying to get this working on my Mac, but I keep getting told that:
>
> gnu.io.PortInUseException: Unknown Application
>
> but
>
> portIdentifier.isCurrentlyOwned()
>
> returns false and when I do lsof on the device I am trying to connect
> to, I see no application
> using it. As the same time if I go to the command line and use
> minicom I have no issues. The
> exception happens with this call:
>
> CommPort commPort = portIdentifier.open(null,0);
>
> Any suggestions?
>
> Andre
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From joachim at buechse.de  Mon Jun 19 05:54:49 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 13:54:49 +0200
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de>

This is most likely due to a problem with lock files. If you have  
downloaded the binaries of 2.17 rxtx will try to create non-standard  
lock files on OSX. We have since changed the code to use OSX device  
locking - however the binaries have not been updated yet. The 2.18  
release fixing this issue is due shortly.

Regards,
Joachim

On 19.06.2006, at 01:33, Andr?-John Mas wrote:

> Hi,
>
> I am have a program that I wrote in Java to communicate with a
> Bluetooth GPS device. I am
> trying to get this working on my Mac, but I keep getting told that:
>
> gnu.io.PortInUseException: Unknown Application
>
> but
>
> portIdentifier.isCurrentlyOwned()
>
> returns false and when I do lsof on the device I am trying to connect
> to, I see no application
> using it. As the same time if I go to the command line and use
> minicom I have no issues. The
> exception happens with this call:
>
> CommPort commPort = portIdentifier.open(null,0);
>
> Any suggestions?
>
> Andre
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From joachim at buechse.de  Mon Jun 19 06:44:27 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 14:44:27 +0200
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <4490A60A.9090305@sun.com>
References: <4490A60A.9090305@sun.com>
Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>

Hello Paul,

I just downloaded the "generic" javax.comm version now available. A  
first check indicates, that it was compiled with a JDK 1.4 javac  
without setting the target classfile version. In other words in can  
not be loaded by 1.1-1.3 VMs (or PersonalJava).

Do you see any chance to provide a version compiled with classfile  
format 45.3 (ie JVM1.1).

---
52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose  
javax.comm.SerialPort | head -5
Compiled from "SerialPort.java"
public abstract class javax.comm.SerialPort extends javax.comm.CommPort
   SourceFile: "SerialPort.java"
   minor version: 0
   major version: 48
---

Best regards,
Joachim


On 15.06.2006, at 02:12, Paul Klissner wrote:

> Hello RxTx community,
>
> I finally think I have a compromise in place that will stand in the  
> gap.
>
> If you go to http://www.sun.com and search for javax.comm, you'll
> get taken to a download page, where now users can get a copy of the
> comm.jar file out of 2.0.3, along with just a license and a README.
>
> I trust this will suffice until such time as RxTx decided to implement
> their own java classes or we can get a JSR going to mitigate some
> of the problems (the readme in the comm.jar 2.0.3 zip file
> contains my thoughts on that).
>
> Thanks,
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Mon Jun 19 09:11:45 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Mon, 19 Jun 2006 11:11:45 -0400
Subject: [Rxtx] Examples added to Wiki
Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

I have added a couple of examples to the Wiki:

http://rxtx.qbang.org/wiki/index.php/Examples

If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :)

Andre



From paul.klissner at sun.com  Mon Jun 19 10:42:47 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Mon, 19 Jun 2006 09:42:47 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>
References: <4490A60A.9090305@sun.com>
	<03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>
Message-ID: <4496D407.1090609@sun.com>

Joachim Buechse wrote:
> Hello Paul,
> 
> I just downloaded the "generic" javax.comm version now available. A  
> first check indicates, that it was compiled with a JDK 1.4 javac  
> without setting the target classfile version. In other words in can  
> not be loaded by 1.1-1.3 VMs (or PersonalJava).
> 
> Do you see any chance to provide a version compiled with classfile  
> format 45.3 (ie JVM1.1).
> 
> ---
> 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose  
> javax.comm.SerialPort | head -5
> Compiled from "SerialPort.java"
> public abstract class javax.comm.SerialPort extends javax.comm.CommPort
>    SourceFile: "SerialPort.java"
>    minor version: 0
>    major version: 48
> ---

I cannot promise when I can do that. Since we thought we were done
with javax.comm, the build environment got moved around, and right
now it doesn't even compile in it's new home.  I tried and it was
not cooperative at all. I was never impressed with that workspace
(in fact far far from it, it is a mess, which is why I migrated 3.0
to ant and never looked back).  It will take some real determination
for me to rebuild it, and frankly, right now I'm swamped.  If I can
find a bit of time over the next few weeks to do it, and it isn't
too bad an ordeal, I will.

Posting that will give me an excuse to post javax.comm 3.0, Update 2 as
well, while I'm working with the people who put content up on our
download center.  The only reason for a new update to 3.0 is that
I've changed the distribution to provide ispt (Interactive Serial
Port Tool), such that it can be launched as soon as the zip file
is unpacked, via a provided script.  ISPT is a command line
interactive tool for  manipulating one or two serial port,
sending data, managing events, etc... I've found it to be so useful
for doing certain kinds of validation  that I assume others will
find it useful to.  ISPT is already in 3.0u1, but one has to set
up their own classpath and launch it and since few people ever read
the documentation most won't know about it.  I've added the ability
to set stop bits and parity since 3.0u1 too.  But I digress.

Paul


From joachim at buechse.de  Mon Jun 19 11:01:28 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 19:01:28 +0200
Subject: [Rxtx] load mechanism of 2.0x
Message-ID: <CFD1440C-21AA-4D3B-9EA6-270D0FF9D6FC@buechse.de>

Good day,

I am trying to figure out, how the 2.0x distribution interacts with  
Suns implementation of javax.comm.CommPortIdentifier.

1) Apparently one can put javax.comm.properties in {java.home}/lib
2) The javax.comm package also reacts to -Djavax.comm.properties="...."

Looking at the javap output it also seems like CommPortIdentifier  
tries to find it's jar file and load the properties from there??


What I'm really looking for is a solution that allows using  
javax.comm with RXTX without modifying the VM installation. So I  
would prefer not to use 1) but I can't figure out how to use 2).

Any hints are welcome,
Joachim



From bob_tai2001 at yahoo.com  Mon Jun 19 15:00:35 2006
From: bob_tai2001 at yahoo.com (Bob Tai)
Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT)
Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place
	to start?
Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>

Hi, 

I got  rxtx Windows 2000 installed.  I did not use the
"best" way ... I just follow the insturuction and dump
the necessary files into the jre... I know it's "best"
idea, I got lazy didn't want to change my setting to
my Eclipse and classpath.

I was able to modify SimpleWrite.java to print on my
AddMaster serial printer.  I think I am ready to code!
But I need to make sure I can handle exceptions and so
on.  I notice the \samples\NullDriver\  has two files
seems to have some of the require method done, should
I start coding from those file?  I like the idea it
has the "time out" and basic exceptions done.   I am
slowly digging into the samples, but if you think any
of the code from Sun is good to checkout please let me
know.

btw, http://rxtx.qbang.org/wiki/index.php/Examples/
was very helpful, wish there are more examples.

thank you,

    Bob


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Mon Jun 19 15:55:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT)
Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good
 place to start?
In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>
References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606191542260.14139@www>

> I am
> slowly digging into the samples, but if you think any
> of the code from Sun is good to checkout please let me
> know.
>

I think NullDriver.java was an example stub driver for implementing 
something like rxtx.  It has been a while.  Unless they have been updated, 
you will find the examples are very dated.  You can look at how they use 
the port but avoid the GUI and hard coded variables (number of ports for 
instance).

There was no Swing and nobody knew what requirements today's compilers 
would make on code.  The examples worked fine with jdk 1.1 but times have 
changed.

--
Trent Jarvi
tjarvi at qbang.org


From tropicsu at hotmail.com  Mon Jun 19 19:49:08 2006
From: tropicsu at hotmail.com (Yoke K)
Date: Tue, 20 Jun 2006 01:49:08 +0000
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
Message-ID: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>

An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/fa588f00/attachment-0001.html

From ajmas at sympatico.ca  Mon Jun 19 21:14:37 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Mon, 19 Jun 2006 23:14:37 -0400
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>
References: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>
Message-ID: <CA22AB2A-5712-458B-9984-68477C6042AF@sympatico.ca>

Regarding the PortInUseException, I had a similar issue and got
this response from the mailing list:

   http://mailman.qbang.org/pipermail/rxtx/Week-of- 
Mon-20060619/062838.html

Andre
On 19-Jun-06, at 21:49 , Yoke K wrote:

> Hi Andre, Joachim
>
> I have tried using /dev/tty.usbserial and also /dev/cu.usbserial  
> and it also reported error as  "gnu.io.PortInUseException".
>
> The iTegno modem works in windows environment. As I moving around  
> using my ibook and I need to get it work on MAC OS as well.
>
> >> INFO: SMSLib API for Java / v1.2.2
> >> INFO: Using port: /dev/tty.usbserial @ 115200 baud.
> >> INFO: JRE Version: 1.5.0_06
> >> INFO: JRE Impl Version: 1.5.0_06-64
> >> INFO: O/S: Mac OS X / ppc / 10.4.6
> >> INFO: Using Wavecom (Generic) AT handler.
>
> SendMessage(): Send a message.
> Using SMSLib API for Java v1.2.2
>
> Connecting ..... :
> >> INFO: CSerialDriver(): Connecting...
> Experimental: JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version = RXTX-2.1-7
> >> INFO: CSerialDriver(): Disconnecting...
> gnu.io.PortInUseException: Unknown Application
> at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354)
> at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1)
> at org.smslib.CService.connect(CService.java:197)
> at SendMessage.main(SendMessage.java:38)
>
> Thanks.
>
> - Jon
>
>
>
>
> ====================
>
> Hello Jon,
>
> From OSX's standpoint a symbolic link is not a device (as far as I
> know). What stops you from using tty.usbserial? Did you try hard-
> linking?
>
> Regards,
> Joachim
>
>
>
> From:  "Yoke K" <tropicsu at hotmail.com>
> To:  rxtx at qbang.org
> Subject:  RXTX-2.1-7 / MAC OS X / NoSuchPortException
> Date:  Sat, 17 Jun 2006 15:32:48 +0000
> >Hi,
> >
> >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to
> >work with MAC OS X.
> >I am using iTegno 3000 - USB GPRS Modem.
> >
> >Files in /dev and a symbolic link as follows:
> >
> >crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
> >crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
> >lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->
> >tty.usbserial
> >
> >In my SendMessage.java, I have this line:
> >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
> >
> >Appreciate any help ?
> >
> >- Jon
> >
> >
> >Errors as follows:
> >
> >>>INFO: SMSLib API for Java / v1.2.2
> >>>INFO: Using port: /dev/ttyS1 @ 56000 baud.
> >>>INFO: JRE Version: 1.5.0_06
> >>>INFO: JRE Impl Version: 1.5.0_06-64
> >>>INFO: O/S: Mac OS X / ppc / 10.4.6
> >>>INFO: Using Wavecom (Generic) AT handler.
> >
> >SendMessage(): Send a message.
> >  Using SMSLib API for Java v1.2.2
> >
> >Connecting ..... :
> >>>INFO: CSerialDriver(): Connecting...
> >Experimental:  JNI_OnLoad called.
> >Stable Library
> >=========================================
> >Native lib Version = RXTX-2.1-7
> >Java lib Version   = RXTX-2.1-7
> >>>INFO: CSerialDriver(): Disconnecting...
> >gnu.io.NoSuchPortException
> >        at
> >gnu.io.CommPortIdentifier.getPortIdentifier 
> (CommPortIdentifier.java:218)
> >        at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
> >        at org.smslib.CService.connect(CService.java:197)
> >        at SendMessage.main(SendMessage.java:38)
> >
> >_________________________________________________________________
> >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
> >
>
> Find love online with MSN Personals
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Tue Jun 20 02:35:24 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 10:35:24 +0200
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>

Hello everybody,

I have been fighting a bit with the javax.comm version of RXTX the  
last days. I am working on the README .OSX now and try to figure out  
which should be the "suggested" installation.

The facts:
------

- the "generic" comm.jar version of javax.comm which has been made re- 
available tries to load com.sun.comm.SolarisDriver
- this classname can be overridden ONLY by putting a file  
javax.comm.properties in {java.home}/lib
- if it is not overridden and SolarisDriver.class is not found  
CommPortIdentifier will be disfunctional (in particual it is not  
possible to add CommPort's via CommPortIdentifier.add).
- the license distributed with comm.jar does not allow the  
modification/addition of classes in javax.comm (however no mention of  
com.sun...)


What really bothers me is to suggest putting this config file in the  
"global" vm installation. This is particularly ugly on the Mac as  
there are several VM installations and the file may be forgotten.  
Additionally it may create versioning problems. I prefer an  
installation where all files are local to the application (even  
comm.jar).

In my opinion the ideal situation would be:
------

1) The author of a program compiles against javax.comm.
2a) For platforms supported by Sun the user is free to use the 3.0  
comm.jar download from Sun
2b) For platforms not supported by Sun the user adds RXTXComm.jar to  
the classpath of the application (and librxtxSerial.jnilib to the  
application directory). Also he will need the 2.0.3 generic comm.jar  
from Sun.
3) Nobody messes with the global VM installation.

Of course 2a) and 2b) could be handled by the author of the program  
via an appropriate installer. The author could also decide to always  
use RXTX and include the generic javax.comm classes as well as the  
RXTX classes in his application jar. [If he further uses an explicit  
call to System.load() he may even include the jnilib(s) in the jar,  
extract it (based on the platform name) at runtime to a temp file and  
load it from there.]


Suggested solution:
------

We only need to put the following class in the classpath BEFORE Suns  
comm.jar

   package com.sun.comm;
   public class SolarisDriver extends gnu.io.RXTXCommDriver {
   }

This is not "the pure art" (TM). It depends on an implementation  
detail of the generic driver. However, so does the  
javax.comm.properties file - as we have seen when Sun released 3.0.  
It has the following advantages:

- The "generic" javax.comm implementation will happily load this  
class as its primary driver.
- No javax.comm.properties file is required.
- This does not violate the javax.comm license agreement as there is  
no mention of the "com.sun.comm" package in this license agreement at  
all.
- Authors packaging comm.jar with their application can strip out all  
com.sun.comm classes from comm.jar


Please comment!

Joachim



From joachim at buechse.de  Tue Jun 20 02:50:36 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 10:50:36 +0200
Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar
Message-ID: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>

There has been some discussions about the best way to install RXTX  
and where to place files.

I suggest that,

- we include the native libraries for the most common operating  
systems (in a special version of) RXTXcomm.jar
- we add loader code which tries to extract and load the platform  
specific binary at runtime
- on failure the current mechanism remains as a fallback

Wether the current mechanism should have priority (ie loadLibrary  
before load) remains to be discussed.


The advantages of this solution are
  - users of RXTX do not need to worry about java/platform specific  
file placement.
  - authors of applications may fully merge RXTX into their  
application jar (which provides a double-clickable application for  
Windows and OSX, Linux?).

Please comment,
Joachim

PS: Of course the suggested solution is already possible today,  
however relatively few programmers know how to correctly extract a  
binary resource file via the class loader and load it as a native  
library.


From tjarvi at qbang.org  Tue Jun 20 03:58:12 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT)
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
Message-ID: <Pine.LNX.4.61.0606200335190.14139@www>

> 2a) For platforms supported by Sun the user is free to use the 3.0
> comm.jar download from Sun
> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to
> the classpath of the application (and librxtxSerial.jnilib to the
> application directory). Also he will need the 2.0.3 generic comm.jar
> from Sun.

As there are no plans to support CommAPI 3.0 due to the limitations in its 
implementation mentioned before, I would not recommend projects use Sun's 
3.0 comm.jar.  They will lose the freedom to chose their low level 
implementation by being locked into vendor specific modifications.

Projects should chose between platform neutrality in CommAPI 2.0 and 
reduced platform neutrality in commapi 3.0.  Projects should also strongly 
consider the fact that the 2.0 comm.jar targets only a reduced number of 
JVMs.

Projects can go with rxtx 2.1 or other packages but should probably only 
consider using Sun CommAPI with rxtx if they did so in the past.  They 
should take steps to no longer depend upon this option being available.

> Suggested solution:
> ------
>
> We only need to put the following class in the classpath BEFORE Suns
> comm.jar
>
>   package com.sun.comm;
>   public class SolarisDriver extends gnu.io.RXTXCommDriver {
>   }
>
> This is not "the pure art" (TM). It depends on an implementation
> detail of the generic driver. However, so does the
> javax.comm.properties file - as we have seen when Sun released 3.0.
> It has the following advantages:
>
> - The "generic" javax.comm implementation will happily load this
> class as its primary driver.
> - No javax.comm.properties file is required.
> - This does not violate the javax.comm license agreement as there is
> no mention of the "com.sun.comm" package in this license agreement at
> all.
> - Authors packaging comm.jar with their application can strip out all
> com.sun.comm classes from comm.jar
>

I would not encourage people to place packages in the com.sun.comm 
namespace.  Authors using Sun's commapi 2.0 should just realize it is 
greatly limited in practical utility and consider moving to something that 
isn't being rescued from EOL.

The primary focus of this release is projects previously depending upon 
Sun CommAPI + RXTX.  There are no plans at this time to provide future 
support in this arrangement due to technical incompatabilities we have no 
control over in commapi 3.0 and limited utility of Sun's generic comm.jar 
in commapi 2.0 offered.  Projects should be aware of this so they can make 
appropriate plans.

--
Trent Jarvi
tjarvi at qbang.org


From paul.klissner at sun.com  Tue Jun 20 05:24:00 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Tue, 20 Jun 2006 04:24:00 -0700
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
In-Reply-To: <Pine.LNX.4.61.0606200335190.14139@www>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
	<Pine.LNX.4.61.0606200335190.14139@www>
Message-ID: <4497DAD0.10803@sun.com>

Trent Jarvi wrote:
>> 2a) For platforms supported by Sun the user is free to use the 3.0
>> comm.jar download from Sun
>> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to
>> the classpath of the application (and librxtxSerial.jnilib to the
>> application directory). Also he will need the 2.0.3 generic comm.jar
>> from Sun.
> 
> As there are no plans to support CommAPI 3.0 due to the limitations in its 
> implementation mentioned before, I would not recommend projects use Sun's 
> 3.0 comm.jar.  They will lose the freedom to chose their low level 
> implementation by being locked into vendor specific modifications.
> 
> Projects should chose between platform neutrality in CommAPI 2.0 and 
> reduced platform neutrality in commapi 3.0.  Projects should also strongly 
> consider the fact that the 2.0 comm.jar targets only a reduced number of 
> JVMs.

Well, that's a little ambiguous because the API is the same
either way.  We're talking about Sun's implementation vs.
other implementations.
> 
> Projects can go with rxtx 2.1 or other packages but should probably only 
> consider using Sun CommAPI with rxtx if they did so in the past.  They 
> should take steps to no longer depend upon this option being available.

3.0 is platform centric because there is a need to add some
platform awareness to Sun's implementation, and the choices
for how to do that are limited by the constraints of the API,
as mentioned in the javax.comm 2.0.3 comm.jar download's README.

I am really advocating getting a JSR open (http://www.jcp.org)
to push a new comm API that is more pluggable, platform neutral
and addresses some of the deficiencies of the current API. Then
we can achieve the optimal of platform neutrality while
simulataneously allowing the API to flexibly adapt to
heterogeneous environments.

This is not a question of attitude, this is an issue of resources,
time and commitment.  The current owners of javax.comm within
Sun would like nothing better than to see the ideal reached for
the API and a model that will extend well beyond the foreseeable
future and work for the industry overall.



> 
>> Suggested solution:
>> ------
>>
>> We only need to put the following class in the classpath BEFORE Suns
>> comm.jar
>>
>>   package com.sun.comm;
>>   public class SolarisDriver extends gnu.io.RXTXCommDriver {
>>   }
>>
>> This is not "the pure art" (TM). It depends on an implementation
>> detail of the generic driver. However, so does the
>> javax.comm.properties file - as we have seen when Sun released 3.0.
>> It has the following advantages:
>>
>> - The "generic" javax.comm implementation will happily load this
>> class as its primary driver.
>> - No javax.comm.properties file is required.
>> - This does not violate the javax.comm license agreement as there is
>> no mention of the "com.sun.comm" package in this license agreement at
>> all.
>> - Authors packaging comm.jar with their application can strip out all
>> com.sun.comm classes from comm.jar
>>
> 
> I would not encourage people to place packages in the com.sun.comm 
> namespace.  Authors using Sun's commapi 2.0 should just realize it is 
> greatly limited in practical utility and consider moving to something that 
> isn't being rescued from EOL.
> 
> The primary focus of this release is projects previously depending upon 
> Sun CommAPI + RXTX.  There are no plans at this time to provide future 
> support in this arrangement due to technical incompatabilities we have no 
> control over in commapi 3.0 and limited utility of Sun's generic comm.jar 
> in commapi 2.0 offered.  Projects should be aware of this so they can make 
> appropriate plans.

Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86,
or need the powerful portmapping features in javax.com 3.0, or would like to
acquire the Interactive Serial Port Test utility.

-Paul


From paul.klissner at sun.com  Tue Jun 20 05:33:44 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Tue, 20 Jun 2006 04:33:44 -0700
Subject: [Rxtx] Suggested installation RXTX 2.0x...
In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
Message-ID: <4497DD18.70207@sun.com>

Joachim Buechse wrote:
> Hello everybody,
> 
> I have been fighting a bit with the javax.comm version of RXTX the  
> last days. I am working on the README .OSX now and try to figure out  
> which should be the "suggested" installation.
> 
> The facts:
> ------
> 
> - the "generic" comm.jar version of javax.comm which has been made re- 
> available tries to load com.sun.comm.SolarisDriver
> - this classname can be overridden ONLY by putting a file  
> javax.comm.properties in {java.home}/lib
> - if it is not overridden and SolarisDriver.class is not found  
> CommPortIdentifier will be disfunctional (in particual it is not  
> possible to add CommPort's via CommPortIdentifier.add).
> - the license distributed with comm.jar does not allow the  
> modification/addition of classes in javax.comm (however no mention of  
> com.sun...)
> 
> 
> What really bothers me is to suggest putting this config file in the  
> "global" vm installation. This is particularly ugly on the Mac as  
> there are several VM installations and the file may be forgotten.  
> Additionally it may create versioning problems. I prefer an  
> installation where all files are local to the application (even  
> comm.jar).
> 
> In my opinion the ideal situation would be:
> ------
> 
> 1) The author of a program compiles against javax.comm.
> 2a) For platforms supported by Sun the user is free to use the 3.0  
> comm.jar download from Sun
> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to  
> the classpath of the application (and librxtxSerial.jnilib to the  
> application directory). Also he will need the 2.0.3 generic comm.jar  
> from Sun.
> 3) Nobody messes with the global VM installation.
> 
> Of course 2a) and 2b) could be handled by the author of the program  
> via an appropriate installer. The author could also decide to always  
> use RXTX and include the generic javax.comm classes as well as the  
> RXTX classes in his application jar. [If he further uses an explicit  
> call to System.load() he may even include the jnilib(s) in the jar,  
> extract it (based on the platform name) at runtime to a temp file and  
> load it from there.]
> 

This was how the Sun implementation originated (I did not write
that code).  I completely agree, and I fixed the whole conf file
locating mechanism in 3.0 to avoid the problems youmentioned.
However, I was unaware of how RxTx was using Sun's implementation,
so I didn't architect it in such a way as to avoid namespace pollution
in the native space in for the backend provider.  In retrospect,
I should have done that differently just as a design principle,
but at this point I don't have the spare cycles to get that all
re-factored.  Further, I'm loathe to do it, because the whole
thing will still be an under-the-hood hack due to the constraints
of the API itself.

Paul





From brian at mbari.org  Tue Jun 20 10:23:54 2006
From: brian at mbari.org (Brian Schlining)
Date: Tue, 20 Jun 2006 09:23:54 -0700
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>


Hi Joachim,

> There has been some discussions about the best way to install RXTX
> and where to place files.
>
> I suggest that,
>
> - we include the native libraries for the most common operating
> systems (in a special version of) RXTXcomm.jar
> - we add loader code which tries to extract and load the platform
> specific binary at runtime
> - on failure the current mechanism remains as a fallback

I like your suggestion. However, my understanding is that in general  
the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH  
(Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to  
be loaded by the JVM. The alternative is to point to your native lib  
directory using -Djava.library.path=/my/dir/with/native/libs when you  
launch the JVM. So, I'm very interested to know how you're planning  
to work around this.

> PS: Of course the suggested solution is already possible today,
> however relatively few programmers know how to correctly extract a
> binary resource file via the class loader and load it as a native
> library.

So how do you use it to dynamically load a native lib? I've read that  
you can't really modify the java.library.path after the JVM has been  
launched. (http://forum.java.sun.com/thread.jspa? 
threadID=627890&tstart=90)

Thanks

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0010.html

From joachim at buechse.de  Tue Jun 20 09:20:29 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 17:20:29 +0200
Subject: [Rxtx] 2.0x in sync with 2.1x
Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>

I have added most of the changes from the 2.1 branch to the 2.0 branch.

This includes
  - correction of illegal javadoc comments
  - implementation errors in handling of Thread.interrupt in  
RXTXPort.java
  - MacOS X locking without lock files/special user groups
  - XCode project which builds a universal binary library
  - updated documentation for OSX

I have done some minimal testing (only G4).
[Trent: there are still some changes you made for specific baud  
rates. I will not sync this, as I can not test them. From my  
perspective we are ready for 2.08/2.18]

The updated documentation can be found in the file README.OSX. Here  
it is:

------------------------ Required files -----------------------

To use or compile RXTX 2.0.x you need to downlad the "generic"  
version (2.0.3)
of the javax.comm implementation from Sun. The zip you download  
contains an
archive comm.jar which is required:

- To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar

- To run the app you will need comm.jar in the classpath or in  
{java.lib.path}


------------------------ Installation on MacOSX -----------------------

WARNING: Please read this section until the end.

---
Preparation
---

You may want to spare your users the burden of modifying the global VM
installation. OSX has several different VM versions installed by  
default and
regular users will be unable to figure out which version will load your
application.

If you provide the class

package com.sun.comm;
public class SolarisDriver extends gnu.io.RXTXCommDriver {
}

and make sure, that it is present in the classpath before Suns  
"generic" comm.jar
your users can skip the following step:

Create a file named
    javax.comm.properties
in the directory
    /System/Library/Frameworks/JavaVM.framework/Home/lib/
which contains (only) the following line (no leading space):
    Driver=gnu.io.RXTXCommDriver



----
The unsafe way of using RXTX on OS X:
----

RXTX can be installed by putting the files
   libSerial.jnilib
   RXTXcomm.jar
   comm.jar
into the folder
   /Library/Java/Extensions

This is NOT RECOMMENDED as it creates versioning conflicts among  
applications.
However you may be forced to install it this way if an application  
was written
for Windows or Linux, requires RXTX and you are not able to change  
its starter.


----
The safe way of using RXTX on OS X:
----

Make sure that you have no (older) version of RXTX installed in
   /Library/Java/Extensions
   /System/Library/Java/Extensions
   /usr/lib/java

Put
   libSerial.jnilib
in the directory of the application (the JavaVM will find it there). Add
   RXTXComm.jar
   comm.jar
to the application classpath or include the classes in the  
application jar.
(Some applications already include the RXTX classes in their  
application jar,
in which case only the file libSerial.jnilib is required).


----
History
----

Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation  
of lockfiles
required special permissions for the user executing an application  
based on RXTX.
To simplify the setup RXTX came with an installer modifying group  
permissions
and installing RXTX in the global location /Library/Java/Extensions.  
However
this was prune to versioning conflicts and is no longer recommended.

--------------------- Build instructions for OSX XCode  
-------------------

contributed by Joachim Buechse <joachim at buechse.de>
original version by Dmitry Markman <dmarkman at mac.com>

System requirements for building:
MacOSX 10.4
XCode 2.3

   open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj
   choose libSerial.jnilib target
   build

After the build you will find RXTXcomm.jar and libSerial.jnilib files  
in the
directory build/Development.

In case you can't find RXTXcomm.jar build the RXTXcomm target manually.
In case of (serious) problems feel free to contact joachim at buechse.de .



From tjarvi at qbang.org  Tue Jun 20 22:01:45 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT)
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
Message-ID: <Pine.LNX.4.61.0606202127270.14139@www>

> ---
> Preparation
> ---
>
> You may want to spare your users the burden of modifying the global VM
> installation. OSX has several different VM versions installed by
> default and
> regular users will be unable to figure out which version will load your
> application.
>
> If you provide the class
>
> package com.sun.comm;
> public class SolarisDriver extends gnu.io.RXTXCommDriver {
> }
>
> and make sure, that it is present in the classpath before Suns
> "generic" comm.jar
> your users can skip the following step:

Hi Joachim

With regards to the above, I have not seen that we have Sun's OK to 
promote that.  I'm not very comfortable with the distribution 
documentation advocating this without Sun agreeing.

I see your point but I'd rather not actively promote putting classes in 
Sun's namespace without permission if you don't mind.  This isn't about 
what is in a license.

I'll go through the code tomorrow night.  It was a late night at work 
today.  There is also a w32 fix comming for people opening and closing 
multiple ports.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Wed Jun 21 01:56:45 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 21 Jun 2006 09:56:45 +0200
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <Pine.LNX.4.61.0606202127270.14139@www>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
	<Pine.LNX.4.61.0606202127270.14139@www>
Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>

Hello Trent,

I guess we will not get an explicit OK from Sun for such a hack. I  
think Paul has made it pretty clear, that he does not have the  
resources to modify the 2.x or 3.x code for the needs of RXTX. I'm  
not thrilled but OK with the current API. Hence I dont agree with  
Paul's idea to start a new JSR to fix the implementation - but that's  
mainly because I dont have the time to push it. According to their  
Readme Sun sees no business case in having cross platform support for  
javax.comm - that is sad but it's none of my business. However I  
prefer to program versus javax.comm in my projects as this gives an  
advanced user the chance to exchange the provider without access to  
the code.

I interpret Pauls reponse to my original "Request for comment" as a  
quiet acceptance of the hack I propose (he did respond, but not at  
all to the sun.comm namespace suggestion). This is certainly not  
something we should put into RXTXcomm.jar but hinting a work around  
for implementation errors should be allowed. That's why I've choosen  
the wording "You may want to spare" and "If you provide". The company  
I worked for has choosen similar hacks for years to fix bugs in swing  
for JDK1.1 applications. Those hacks were usually included in their  
own swingpatch.jar.

Having said all that - I do not take it as an insult if you remove  
the paragraph from the Readme. I appreciate that you notified me  
before. It would be interesting to hear some more opinions from the  
list members...

Best regards,
Joachim


On 21.06.2006, at 06:01, Trent Jarvi wrote:

>> ---
>> Preparation
>> ---
>>
>> You may want to spare your users the burden of modifying the  
>> global VM
>> installation. OSX has several different VM versions installed by
>> default and
>> regular users will be unable to figure out which version will load  
>> your
>> application.
>>
>> If you provide the class
>>
>> package com.sun.comm;
>> public class SolarisDriver extends gnu.io.RXTXCommDriver {
>> }
>>
>> and make sure, that it is present in the classpath before Suns
>> "generic" comm.jar
>> your users can skip the following step:
>
> Hi Joachim
>
> With regards to the above, I have not seen that we have Sun's OK to
> promote that.  I'm not very comfortable with the distribution
> documentation advocating this without Sun agreeing.
>
> I see your point but I'd rather not actively promote putting  
> classes in
> Sun's namespace without permission if you don't mind.  This isn't  
> about
> what is in a license.
>
> I'll go through the code tomorrow night.  It was a late night at work
> today.  There is also a w32 fix comming for people opening and closing
> multiple ports.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Wed Jun 21 02:03:33 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 21 Jun 2006 10:03:33 +0200
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
	<6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
Message-ID: <BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>

See System.load(String) [it's also mentioned under the URL you posted].

Regards,
Joachim


On 20.06.2006, at 18:23, Brian Schlining wrote:

> So how do you use it to dynamically load a native lib? I've read  
> that you can't really modify the java.library.path after the JVM  
> has been launched. (http://forum.java.sun.com/thread.jspa? 
> threadID=627890&tstart=90)
>
> Thanks
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From baris.ozkan at elikasu.com.tr  Wed Jun 21 07:58:06 2006
From: baris.ozkan at elikasu.com.tr (Baris)
Date: Wed, 21 Jun 2006 16:58:06 +0300
Subject: [Rxtx] RS 232 ..additional parameters
Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>

Hi,
 
Currently i am developing an application that requires to connect to a
remote rs232 device through  a dialup connection.
 
My problem is that the communication needs several more connection
parameters (i extracted that information from the vendor's dll , listed at
the end of the message)
 
I explored rxtx API and src files and could not find methods to set a
majority  of the parameters.
Am i missing any point or does rxtx is limited to soem standard set of
functionality(e.g. commAPI)? How  is it possible ,if i want to put some
extensions(???) to current rxtx implementation?
 
I am not very good at rs232 programming so excuse me if this message  is
boring one.
 
Thanx
 
Baris Ozkan
 
 
A Listing of Parameters:
 
 
typedef struct _DCB {

DWORD DCBlength; /* sizeof(DCB) */

DWORD BaudRate; /* Baudrate at which running */

DWORD fBinary: 1; /* Binary Mode (skip EOF check) */

DWORD fParity: 1; /* Enable parity checking */

DWORD fOutxCtsFlow:1; /* CTS handshaking on output */

DWORD fOutxDsrFlow:1; /* DSR handshaking on output */

DWORD fDtrControl:2; /* DTR Flow control */

DWORD fDsrSensitivity:1; /* DSR Sensitivity */

DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */

DWORD fOutX: 1; /* Enable output X-ON/X-OFF */

DWORD fInX: 1; /* Enable input X-ON/X-OFF */

DWORD fErrorChar: 1; /* Enable Err Replacement */

DWORD fNull: 1; /* Enable Null stripping */

DWORD fRtsControl:2; /* Rts Flow control */

DWORD fAbortOnError:1; /* Abort all reads and writes on Error */

DWORD fDummy2:17; /* Reserved */

WORD wReserved; /* Not currently used */

WORD XonLim; /* Transmit X-ON threshold */

WORD XoffLim; /* Transmit X-OFF threshold */

BYTE ByteSize; /* Number of bits/byte, 4-8 */

BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */

BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */

char XonChar; /* Tx and Rx X-ON character */

char XoffChar; /* Tx and Rx X-OFF character */

char ErrorChar; /* Error replacement char */

char EofChar; /* End of Input character */

char EvtChar; /* Received Event character */

WORD wReserved1; /* Fill for now. */

} DCB, *LPDCB;

typedef struct _COMMTIMEOUTS {

DWORD ReadIntervalTimeout; /* Maximum time between read chars. */

DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */

DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */

DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */

DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */

} COMMTIMEOUTS,*LPCOMMTIMEOUTS;

dcb.fOutX = FALSE;

dcb.fInX = FALSE;

dcb.fOutxCtsFlow = FALSE;

dcb.fBinary = TRUE;

dcb.fRtsControl = RTS_CONTROL_ENABLE;

SetCommState(hComm , &dcb ); 

COMMTIMEOUTS commTimeOut;

GetCommTimeouts(hComm, &commTimeOut );

commTimeOut.WriteTotalTimeoutMultiplier = 1; 

commTimeOut.WriteTotalTimeoutConstant = 18; 

// commTimeOut.ReadIntervalTimeout = 28; 

commTimeOut.ReadIntervalTimeout = 0; 

// commTimeOut.ReadTotalTimeoutMultiplier = 184; 

commTimeOut.ReadTotalTimeoutMultiplier = 300; 

// commTimeOut.ReadTotalTimeoutConstant = 1200;

commTimeOut.ReadTotalTimeoutConstant = 1200;

SetCommTimeouts(hComm, &commTimeOut);

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0010.html

From ajmas at sympatico.ca  Wed Jun 21 08:14:26 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Wed, 21 Jun 2006 10:14:26 -0400
Subject: [Rxtx] When is 2.18 planned for?
Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

Just curious as to know if there is a target date for 2.18?

Andre



From brian at mbari.org  Wed Jun 21 09:36:00 2006
From: brian at mbari.org (Brian Schlining)
Date: Wed, 21 Jun 2006 08:36:00 -0700
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
	<6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
	<BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>
Message-ID: <A21C9BC0-7894-4B08-AC82-44E11AB3D461@mbari.org>

Ha!!

I suppose I should read my own postings. ;-)

Thanks
B

On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote:

> See System.load(String) [it's also mentioned under the URL you  
> posted].
>
> Regards,
> Joachim
>
>
> On 20.06.2006, at 18:23, Brian Schlining wrote:
>
>> So how do you use it to dynamically load a native lib? I've read
>> that you can't really modify the java.library.path after the JVM
>> has been launched. (http://forum.java.sun.com/thread.jspa?
>> threadID=627890&tstart=90)

Brian Schlining
Software Engineer
http://www.mbari.org




From ajmas at sympatico.ca  Wed Jun 21 16:41:28 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Wed, 21 Jun 2006 18:41:28 -0400
Subject: [Rxtx] CVS build question
Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X:

 The JCL extension to RxTx requires comm.jar
 If you intend to use RxTx for commapi support comm.jar
 needs to be located in  /System/Library/Frameworks/JavaVM.framework/
  Versions/1.5/Home/lib/ext/comm.jar

I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me.

On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native).

Andre






From tjarvi at qbang.org  Wed Jun 21 18:00:04 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT)
Subject: [Rxtx] CVS build question
In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606211756310.14139@www>

On Wed, 21 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> Is the CVS repository meant to build for gnu.io or javax.comm? I ask 
> this, because I see the following when calling ./configure from MacOS X:
>
> The JCL extension to RxTx requires comm.jar
> If you intend to use RxTx for commapi support comm.jar
> needs to be located in  /System/Library/Frameworks/JavaVM.framework/
>  Versions/1.5/Home/lib/ext/comm.jar
>
> I am wanting to build for the gnu.io package, since I want to jump ahead 
> and see if the changes, intended for 2.18 for MacOS X, work for me.
>
> On a side note /Library/Java/Extensions should be included as a valid 
> search path for the JAR, since this is where Apple recommends placing 
> third party extensions (both Java and native).
>

rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel"
rxtx 2.0 src is obtained with "cvs checkout rxtx-devel"

rxtx 2.1 is a complete package in namespace gnu.io
rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 18:02:23 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT)
Subject: [Rxtx] When is 2.18 planned for?
In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606211800180.14139@www>

On Wed, 21 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> Just curious as to know if there is a target date for 2.18?
>

Hi Andre

"When it is ready" :)

Probably this weekend.  Maybe sooner.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 18:10:18 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT)
Subject: [Rxtx] RS 232 ..additional parameters
In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>
References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>
Message-ID: <Pine.LNX.4.61.0606211805010.14139@www>

On Wed, 21 Jun 2006, Baris wrote:

> Hi,
>
> Currently i am developing an application that requires to connect to a
> remote rs232 device through  a dialup connection.
>
> My problem is that the communication needs several more connection
> parameters (i extracted that information from the vendor's dll , listed at
> the end of the message)
>
> I explored rxtx API and src files and could not find methods to set a
> majority  of the parameters.
> Am i missing any point or does rxtx is limited to soem standard set of
> functionality(e.g. commAPI)? How  is it possible ,if i want to put some
> extensions(???) to current rxtx implementation?
>
> I am not very good at rs232 programming so excuse me if this message  is
> boring one.
>
> Thanx
>

Hi Baris

> typedef struct _DCB {
> typedef struct _COMMTIMEOUTS {

These are all handled in termios.c.  It is possible to add extensions to 
rxtx 2.1.  It may well be that the defaults are the same for the variables 
not covered by the existing API.  You can dump the DCB and COMMTIMEOUTS 
from inside termios.c to compare.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 20:23:30 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT)
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
	<Pine.LNX.4.61.0606202127270.14139@www>
	<789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>
Message-ID: <Pine.LNX.4.61.0606212012210.14139@www>

> I'm
> not thrilled but OK with the current API. Hence I dont agree with
> Paul's idea to start a new JSR to fix the implementation - but that's
> mainly because I dont have the time to push it. According to their
> Readme Sun sees no business case in having cross platform support for
> javax.comm - that is sad but it's none of my business. However I
> prefer to program versus javax.comm in my projects as this gives an
> advanced user the chance to exchange the provider without access to
> the code.

Hi Joachim

With regards to the JSR, I think that would be Doug's call.  The effort I 
put in would have to be on my own time which would not be a great deal.  I 
could help things go smoothly but thats not the same as pushing something 
through.

--
Trent Jarvi
tjarvi at qbang.org



From vt at freehold.crocodile.org  Wed Jun 21 21:05:22 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Wed, 21 Jun 2006 20:05:22 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
Message-ID: <449A08F2.3020106@freehold.crocodile.org>

Hello all,

I know this question may belong to JSR lists, but since all interested 
parties are here, I thought I just ask this question here, again...

A while ago I run into a problem and wrote a rant, here: 
http://servomaster.sourceforge.net/dev/serial-usb.html
At the time of writing I didn't think of adding another possible 
solution - changing the CommAPI specs to support removable devices. 
Apparently, Serial/USB bridges are here to stay, and this issue has to 
be addressed.

Wonder if anything changed since, and any abstractions for supporting 
removable devices made it into current or future Java CommAPI drafts - 
Paul, any comments?

--vt



From joachim at buechse.de  Thu Jun 22 01:59:54 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 22 Jun 2006 09:59:54 +0200
Subject: [Rxtx] CVS build question
In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de>

Hello Andre,

I am not sure how well the configure/make mechanism will work on OSX.  
I know that a while ago some contributors tried to get configure/make  
working on OSX but from comments I found in the readmes this work was  
only partially successfull. For compilation on OSX we have used the  
ProjectBuilder/XCode projects you can find in MACOSX_IDE.

Regarding the  ./configure comment:
RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config  
file javax.comm.properties. The later MUST reside in {java.home}/lib.  
As the two only work together putting comm.jar into  /Library/Java/ 
Extensions  and hence making it available to all current and future  
VM installations will only add to confusion.

Regards,
Joachim

On 22.06.2006, at 00:41, Andre-John Mas wrote:

> Hi,
>
> Is the CVS repository meant to build for gnu.io or javax.comm? I  
> ask this, because I see the following when calling ./configure from  
> MacOS X:
>
>  The JCL extension to RxTx requires comm.jar
>  If you intend to use RxTx for commapi support comm.jar
>  needs to be located in  /System/Library/Frameworks/JavaVM.framework/
>   Versions/1.5/Home/lib/ext/comm.jar
>
> I am wanting to build for the gnu.io package, since I want to jump  
> ahead and see if the changes, intended for 2.18 for MacOS X, work  
> for me.
>
> On a side note /Library/Java/Extensions should be included as a  
> valid search path for the JAR, since this is where Apple recommends  
> placing third party extensions (both Java and native).
>
> Andre
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Thu Jun 22 02:51:05 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 22 Jun 2006 10:51:05 +0200
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449A08F2.3020106@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>

Hello Vadim,

I think that your rant is to the point. However it is a bit like  
saying that Windows is at the source of email degradation and the  
only solution is to have users switch to safer operating systems.

I don't see how javax.comm or RXTX can address the problems you  
mention. Of course it would be super cool if javax.comm could magicly  
find the "matching" usb-device and query it's configuration via the  
usb protocol - however this magic (mapping /dev/xyz to its underlying  
USB device) is not supported by any kernel APIs I am aware of. It  
could be supported via POSSIX ioctl calls but then you should address  
your rant to the POSSIX group...

So for the time beeing it's either up to the virtual comm port driver  
to provide a usefull name under /dev/ or to the user choosing the  
right port to use. One example of a smart(er) com port driver is the  
KDDI driver for OSX, which will create device names like "/dev/ 
cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- 
encoded into the bridge chip. The same driver for windows also has  
some options allowing it in theory to recreate the same COMx every  
time a device is plugged/unplugged.

For most industrial applications however it will be up to the user to  
choose the right port (without getting a lot of help doing so).

Probing serial ports can go wrong, that's right. However any serial  
device developper would be well adviced to implement a basic set of  
Hayes AT modem commands (be it a modem or not). Especially AT I0.  
Anyone failing to do so risks that the users favourite TCP/PPP/FAX  
application or stack will kill the device in short time.

Best regards,
Joachim


On 22.06.2006, at 05:05, Vadim Tkachenko wrote:

> Hello all,
>
> I know this question may belong to JSR lists, but since all interested
> parties are here, I thought I just ask this question here, again...
>
> A while ago I run into a problem and wrote a rant, here:
> http://servomaster.sourceforge.net/dev/serial-usb.html
> At the time of writing I didn't think of adding another possible
> solution - changing the CommAPI specs to support removable devices.
> Apparently, Serial/USB bridges are here to stay, and this issue has to
> be addressed.
>
> Wonder if anything changed since, and any abstractions for supporting
> removable devices made it into current or future Java CommAPI drafts -
> Paul, any comments?
>
> --vt
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From vt at freehold.crocodile.org  Thu Jun 22 13:16:03 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 12:16:03 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
Message-ID: <20060622191603.GA17487@freehold.crocodile.org>

Hello Joachim,

> I think that your rant is to the point. However it is a bit like  
> saying that Windows is at the source of email degradation and the  
> only solution is to have users switch to safer operating systems.

I guess the problem is that the rant itself is obsolete and has to be
updated according to latest developments. At the time of writing there
weren't that many bridges around, and the trend didn't manifest itself as it
does now.

> I don't see how javax.comm or RXTX can address the problems you  
> mention.

I would agree that javax.comm won't be able to address the problem, at least
in the short run. As for RxTx - well, nobody prevents it from being a
superset of CommAPI specification, right? RxTx being the de-facto standard
for quite a few platforms, I'd daresay the standard may follow.

> Of course it would be super cool if javax.comm could magicly find the
> "matching" usb-device and query it's configuration via the usb protocol -
> however this magic (mapping /dev/xyz to its underlying USB device) is not
> supported by any kernel APIs I am aware of. It could be supported via
> POSSIX ioctl calls but then you should address your rant to the POSSIX
> group...

As a matter of fact, my bigger concern is addressing the fact that a serial
device can now be removable. This hasn't been the case before, and it
clearly is now. Regarding the above, well, I guess if we accept this fact,
we also need to accept the fact that we need at least rudimentary means of
identification of a serial device. For the USB case, it would usually be the
vendor/product ID, plus possible serial number - but it is irrelevant what
exactly the identifying information is, as long as it allows to identify the
device.

A paradigm shift is required, this is what I wanted to say. Serial devices
can be removed and replaced, it's now our turn to learn to deal with it.

> Joachim

--vt


From jredman at ergotech.com  Thu Jun 22 13:41:44 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 13:41:44 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
Message-ID: <449AF278.6000903@ergotech.com>


Vadim Tkachenko wrote:
> A paradigm shift is required, this is what I wanted to say. Serial devices
> can be removed and replaced, it's now our turn to learn to deal with it.

The removal if the serial port hardly significantly different from the 
removal of the device attached to the serial port.   Different, 
slightly, but not a "paradigm shift".

And yes, someone could unplug a USB serial device and plug it into a 
different USB port so that it has a different name/number, but they 
could do that with the device itself, move it from com1 to com2.

Am I missing something?

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 13:57:27 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 12:57:27 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449AF278.6000903@ergotech.com>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
Message-ID: <20060622195727.GA20247@freehold.crocodile.org>

On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote:
> 
> Vadim Tkachenko wrote:
> > A paradigm shift is required, this is what I wanted to say. Serial devices
> > can be removed and replaced, it's now our turn to learn to deal with it.
> 
> The removal if the serial port hardly significantly different from the 
> removal of the device attached to the serial port.   Different, 
> slightly, but not a "paradigm shift".
> 
> And yes, someone could unplug a USB serial device and plug it into a 
> different USB port so that it has a different name/number, but they 
> could do that with the device itself, move it from com1 to com2.
> 
> Am I missing something?

Yes, the fact that they could unplug a device A and plug a device B. With
the introduction of the concept of removability, the notion of the serial
port itself is not as important anymore, but the notion of the unique device
identifier is.

Consider a situation: long running system (enterprise HVAC, tens of nodes,
tens of thousands square feet area, hundreds of thousand dollars worth of
equipment being conditioned, can't shut down), serial/usb device fails, is
replaced by an identical device with a different serial #.

A little bit farfetched, but hopefully highlighting the point I'm trying to
make.

> Jim

--vt


From jredman at ergotech.com  Thu Jun 22 14:37:38 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 14:37:38 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>	<20060622191603.GA17487@freehold.crocodile.org>	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
Message-ID: <449AFF92.8080003@ergotech.com>


Vadim Tkachenko wrote:
>>
>> Am I missing something?
> 
> Yes, the fact that they could unplug a device A and plug a device B. With
> the introduction of the concept of removability, the notion of the serial
> port itself is not as important anymore, but the notion of the unique device
> identifier is.

Serial devices are always removable.  I could unplug _serial_ device A 
and plug in _serial_ device B.  We have systems running with two RS485 
ports, one talks to a Modbus PLC network one to a number of drives on a 
proprietary protocol.  If you plug the wrong DB9 into the wrong port the 
application doesn't work.

If you dangle a USB 485 converter on the end of the DB9 you've just 
moved the problem from RS485 to USB, but the problem/effect is the same.

> 
> Consider a situation: long running system (enterprise HVAC, tens of nodes,
> tens of thousands square feet area, hundreds of thousand dollars worth of
> equipment being conditioned, can't shut down), serial/usb device fails, is
> replaced by an identical device with a different serial #.
> 
> A little bit farfetched, but hopefully highlighting the point I'm trying to
> make.

Nothing's changed.  If I had a 4 port ISA board and plugged it into my 
new shiny '386 machine.  I could have com ports 9-12.  If I took a board 
off the shelf and didn't set the jumpers, I would have com ports 3-6.

The problem's the same.  If you replace with identical product then the 
com ports  will be the same - no software changes required.  If you 
replace one piece of hardware with hardware from a different 
manufacturer, then the naming/numbering may change.  You're physically 
changing the system, so may reasonably expect to have to make a software 
change.  RXTX actually handles this situation quite well with the -D 
command line option.  (My experience has generally been that the port 
number depends more on the USB port used than the hardware - so the 
chances are even with a hardware change the port number/name will be the 
same.)

Slightly Off Topic - there is a reason why industrial users will pay a 
premium for continued availability of hardware.  Yes you can mail-order 
a $10 USB converter and it will work, but there's no guarantee that the 
next time you buy the same part number from the same vendor it will be 
the same.  The industrial vendors will charge you $100+ for the same 
item, but it will be the same every time you buy it for the next 5 to 10 
years.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 14:37:19 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 13:37:19 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
Message-ID: <20060622203719.GA22521@freehold.crocodile.org>

Hello again,

And while I'm at it, why don't just say this: give me one good reason to
write 3+ different ways of handling removable devices, one for USB, one for
FireWire, one for serial...

I understand very well that this goes way beyond the scope of RxTx and
CommAPI and will require cooperation between them and javax.usb and whatever
JSR is responsible for FireWire implementation - but the end result is well
worth it. Abstract out and generalize arrival/departure/monitoring/discovery
API, provide protocol specific extensions for each, live happily ever after.

--vt


On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote:
> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote:
> > 
> > Vadim Tkachenko wrote:
> > > A paradigm shift is required, this is what I wanted to say. Serial devices
> > > can be removed and replaced, it's now our turn to learn to deal with it.
> > 
> > The removal if the serial port hardly significantly different from the 
> > removal of the device attached to the serial port.   Different, 
> > slightly, but not a "paradigm shift".
> > 
> > And yes, someone could unplug a USB serial device and plug it into a 
> > different USB port so that it has a different name/number, but they 
> > could do that with the device itself, move it from com1 to com2.
> > 
> > Am I missing something?
> 
> Yes, the fact that they could unplug a device A and plug a device B. With
> the introduction of the concept of removability, the notion of the serial
> port itself is not as important anymore, but the notion of the unique device
> identifier is.
> 
> Consider a situation: long running system (enterprise HVAC, tens of nodes,
> tens of thousands square feet area, hundreds of thousand dollars worth of
> equipment being conditioned, can't shut down), serial/usb device fails, is
> replaced by an identical device with a different serial #.
> 
> A little bit farfetched, but hopefully highlighting the point I'm trying to
> make.
> 
> > Jim
> 
> --vt
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx


From jredman at ergotech.com  Thu Jun 22 15:13:49 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 15:13:49 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>	<20060622191603.GA17487@freehold.crocodile.org>	<449AF278.6000903@ergotech.com>	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
Message-ID: <449B080D.9080208@ergotech.com>


Vadim Tkachenko wrote:
> Hello again,
> 
> And while I'm at it, why don't just say this: give me one good reason to
> write 3+ different ways of handling removable devices, one for USB, one for
> FireWire, one for serial...

You don't, they're all the same "I have lost communication with my 
serial device".

The only thing you could really do is improve error reporting by knowing 
the exact sub-system.  ("Device X which is/was attached to USB port Y is 
no longer functioning, please check the USB ports, the device, the 
cables and anything else you can think of that may be a cause of 
failure.")  That just requires an intelligent description of the port.

> I understand very well that this goes way beyond the scope of RxTx and
> CommAPI and will require cooperation between them and javax.usb and whatever
> JSR is responsible for FireWire implementation - but the end result is well
> worth it. Abstract out and generalize arrival/departure/monitoring/discovery
> API, provide protocol specific extensions for each, live happily ever after.

There's a huge list of pseudo-serial devices each with a different set 
of requirements, Bluetooth, RFC 2217, a host of proprietary systems, 
etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I 
have no clue how you'd implement them in a general/cross platform sense.

You haven't convinced me (and only me, others may see something that I 
don't, I'm not speaking for them) that this mechanism can be implemented 
in any practical sense.  That is, that the implementation could be wide 
enough to be consider generally available in RXTX regardless of the 
serial port implementation, platform, etc..  However, if you can come up 
with a general design and a reference implementation for one subsystem, 
I'd like to see it and might get on board.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 15:40:55 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 14:40:55 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449B080D.9080208@ergotech.com>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
Message-ID: <20060622214055.GA25497@freehold.crocodile.org>

On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote:
> 
> Vadim Tkachenko wrote:
> > Hello again,
> > 
> > And while I'm at it, why don't just say this: give me one good reason to
> > write 3+ different ways of handling removable devices, one for USB, one for
> > FireWire, one for serial...
> 
> You don't, they're all the same "I have lost communication with my 
> serial device".

"I have lost communication with my ${protocol} device".

> The only thing you could really do is improve error reporting by knowing 
> the exact sub-system.  ("Device X which is/was attached to USB port Y is 
> no longer functioning, please check the USB ports, the device, the 
> cables and anything else you can think of that may be a cause of 
> failure.")

"Device ${id} which is/was attached to ${protocol} port ${port} is no longer
functioning, please check the ${protocol} ports, the device, the
${protocol_media} and anything else you can think of that may be a cause of
failure".

>  That just requires an intelligent description of the port.

Agree absolutely.

> > I understand very well that this goes way beyond the scope of RxTx and
> > CommAPI and will require cooperation between them and javax.usb and whatever
> > JSR is responsible for FireWire implementation - but the end result is well
> > worth it. Abstract out and generalize arrival/departure/monitoring/discovery
> > API, provide protocol specific extensions for each, live happily ever after.
> 
> There's a huge list of pseudo-serial devices each with a different set 
> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, 
> etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I 
> have no clue how you'd implement them in a general/cross platform sense.

That's because some of the protocols were created decades ago when
autoconfiguration wasn't even conceived, much less practical. RS232/RS485
don't have a clue about identity discovery, and even capabilities discovery
beyond obvious 8N1 etc.

I agree that today all these protocols have generally incompatible
strategies for handling the situations I'm trying to address, but there's
nothing that says it's not an oversight. Besides, we're dealing with the
devices at a level of abstraction that allows some simplifications and
generalizations, at least part of the time - unless it's the protocol
specific features we're dealing with.

> You haven't convinced me (and only me, others may see something that I 
> don't, I'm not speaking for them) that this mechanism can be implemented 
> in any practical sense.  That is, that the implementation could be wide 
> enough to be consider generally available in RXTX regardless of the 
> serial port implementation, platform, etc..  However, if you can come up 
> with a general design and a reference implementation for one subsystem, 
> I'd like to see it and might get on board.

Actually, I wasn't even thinking about all this stuff when I wrote the first
message on the subject :) Now that you mention it - well, I'm not sure I can
chew the piece I just tried to bite in reasonable amount of time.

How do you eat an elephant? One bite at a time. If we could agree that a
small step in the specification is acceptable at this time, and express
further intentions, things may start happening.

To put it succinctly:

- Concept of a "port" should be augmented with a concept of a "device". A
device may be attached to a port in an implicit or explicit way.
- Implicitly connected device is exactly what the current scope of the
specification covers. No new functionality is offered.
- Explicitly connected device supports detachable device semantics, just as
other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a
few).
- The input and output streams are not properties of a port now, but
properties of the device attached to the port.
- A mechanism to allow listening for device arrivals and departures must be
made available.

That's it, off the top of my head.

I understand that this goes completely against current javax.comm specs, but
an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be
difficult to implement without disrupting javax.comm compatibility.

One concern is how to deal with the device identity - but there's no general
way of dealing with this at this time, devices may or may not offer identity
discovery.

> Jim

--vt


From joachim at buechse.de  Fri Jun 23 02:12:43 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 23 Jun 2006 10:12:43 +0200
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
Message-ID: <CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>

Hello++ Vadim,

I would like to repeat that your request is best addressed to the  
POSSIX standardization group - or maybe the BSD/Linux maintainers. If  
you convince the BSD or Linux guys to add this kind of functionality  
(they can as most of there VCP drivers are open source), there is a  
certain chance that other vendors will pick it up. I assure you that  
RXTX will happily provide this functionality once it's possible - I'm  
sure there is more than one maintainer that would love to add it.  
Having this concept penetrate the market may take some years though.

SHORT: The solution you would like to see could be added to the API  
but it can not be implemented (at least not on the platforms I know).  
There are currently no hooks in the kernel that allow you to discover  
"the device" or even the "means of connection" based on an existing  
"device file descriptor" ie COM-port or /dev/... entry. The name  
mapping of the device is handled by the virtual com port driver of  
the device. Unless you are suggesting RXTX should reimplement virtual  
com port drivers for all usb/serial bridges out there your request is  
understandable from a users viewpoint but simply not realizable. It's  
like asking that the Socket api should identify the computer behind  
an IP address (ie by its Ethernet address). While this COULD be  
implemented in TCP/IP, it IS not, and hence there is no point adding  
such a function to the Socket API.

The current trend for USB/Bluetooth/Irda/etc connected devices is  
going away from serial port abstraction towards RPC (ie the drivers  
provide a device specific or device class specific driver that  
provides an application level api to the device functions). The line  
level protocol is often not even published.

Best regards,
Joachim

On 22.06.2006, at 23:40, Vadim Tkachenko wrote:

> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote:
>>
>> Vadim Tkachenko wrote:
>>> Hello again,
>>>
>>> And while I'm at it, why don't just say this: give me one good  
>>> reason to
>>> write 3+ different ways of handling removable devices, one for  
>>> USB, one for
>>> FireWire, one for serial...
>>
>> You don't, they're all the same "I have lost communication with my
>> serial device".
>
> "I have lost communication with my ${protocol} device".
>
>> The only thing you could really do is improve error reporting by  
>> knowing
>> the exact sub-system.  ("Device X which is/was attached to USB  
>> port Y is
>> no longer functioning, please check the USB ports, the device, the
>> cables and anything else you can think of that may be a cause of
>> failure.")
>
> "Device ${id} which is/was attached to ${protocol} port ${port} is  
> no longer
> functioning, please check the ${protocol} ports, the device, the
> ${protocol_media} and anything else you can think of that may be a  
> cause of
> failure".
>
>>  That just requires an intelligent description of the port.
>
> Agree absolutely.
>
>>> I understand very well that this goes way beyond the scope of  
>>> RxTx and
>>> CommAPI and will require cooperation between them and javax.usb  
>>> and whatever
>>> JSR is responsible for FireWire implementation - but the end  
>>> result is well
>>> worth it. Abstract out and generalize arrival/departure/ 
>>> monitoring/discovery
>>> API, provide protocol specific extensions for each, live happily  
>>> ever after.
>>
>> There's a huge list of pseudo-serial devices each with a different  
>> set
>> of requirements, Bluetooth, RFC 2217, a host of proprietary systems,
>> etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I
>> have no clue how you'd implement them in a general/cross platform  
>> sense.
>
> That's because some of the protocols were created decades ago when
> autoconfiguration wasn't even conceived, much less practical. RS232/ 
> RS485
> don't have a clue about identity discovery, and even capabilities  
> discovery
> beyond obvious 8N1 etc.
>
> I agree that today all these protocols have generally incompatible
> strategies for handling the situations I'm trying to address, but  
> there's
> nothing that says it's not an oversight. Besides, we're dealing  
> with the
> devices at a level of abstraction that allows some simplifications and
> generalizations, at least part of the time - unless it's the protocol
> specific features we're dealing with.
>
>> You haven't convinced me (and only me, others may see something  
>> that I
>> don't, I'm not speaking for them) that this mechanism can be  
>> implemented
>> in any practical sense.  That is, that the implementation could be  
>> wide
>> enough to be consider generally available in RXTX regardless of the
>> serial port implementation, platform, etc..  However, if you can  
>> come up
>> with a general design and a reference implementation for one  
>> subsystem,
>> I'd like to see it and might get on board.
>
> Actually, I wasn't even thinking about all this stuff when I wrote  
> the first
> message on the subject :) Now that you mention it - well, I'm not  
> sure I can
> chew the piece I just tried to bite in reasonable amount of time.
>
> How do you eat an elephant? One bite at a time. If we could agree  
> that a
> small step in the specification is acceptable at this time, and  
> express
> further intentions, things may start happening.
>
> To put it succinctly:
>
> - Concept of a "port" should be augmented with a concept of a  
> "device". A
> device may be attached to a port in an implicit or explicit way.
> - Implicitly connected device is exactly what the current scope of the
> specification covers. No new functionality is offered.
> - Explicitly connected device supports detachable device semantics,  
> just as
> other protocols do (USB, FireWire, Wireless USB, Bluetooth, to  
> mention a
> few).
> - The input and output streams are not properties of a port now, but
> properties of the device attached to the port.
> - A mechanism to allow listening for device arrivals and departures  
> must be
> made available.
>
> That's it, off the top of my head.
>
> I understand that this goes completely against current javax.comm  
> specs, but
> an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern )  
> won't be
> difficult to implement without disrupting javax.comm compatibility.
>
> One concern is how to deal with the device identity - but there's  
> no general
> way of dealing with this at this time, devices may or may not offer  
> identity
> discovery.
>
>> Jim
>
> --vt
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From vt at freehold.crocodile.org  Fri Jun 23 11:28:29 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Fri, 23 Jun 2006 10:28:29 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
	<CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
Message-ID: <20060623172829.GA5335@freehold.crocodile.org>

Hello Joachim,

> I would like to repeat that your request is best addressed to the POSSIX
> standardization group - or maybe the BSD/Linux maintainers. If you
> convince the BSD or Linux guys to add this kind of functionality (they can
> as most of there VCP drivers are open source), there is a certain chance
> that other vendors will pick it up. I assure you that RXTX will happily
> provide this functionality once it's possible - I'm sure there is more
> than one maintainer that would love to add it.

I realize this thing is bigger than RxTx itself, and I'm afraid it's too
global not to cause people to laugh before they think about it :)

> Having this concept penetrate the market may take some years though.

Well, I'm sure it'll get there, the only question is - when.

> SHORT: The solution you would like to see could be added to the API but it
> can not be implemented (at least not on the platforms I know).

I guess I'm concerned about the abstraction more than I'm concerned about
the implementation at this point.
  
> There are currently no hooks in the kernel that allow you to discover  
> "the device" or even the "means of connection" based on an existing  
> "device file descriptor" ie COM-port or /dev/... entry.

Well, I'm not so sure you need to keep the literal mapping from /dev
namespace to your device namespace. As long as you can consistently offer a
virtual serial device on top of a virtual serial port, it may be irrelevant
whether you can map it into /dev. The mapping is going be schitzofrenic
anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the
representation...

> The name mapping of the device is handled by the virtual com port driver
> of the device. Unless you are suggesting RXTX should reimplement virtual
> com port drivers for all usb/serial bridges out there your request is
> understandable from a users viewpoint but simply not realizable.

It's not so much a request but rather an offer of participation. I run a few
projects actively using serial communications, as well as USB device
drivers, in different degrees of readiness (Servomaster, Haywire, DIY
Zoning) - and it would be a perfect playground.

You mentioned above that this task is about two things: a) abstraction b)
implementation. I could start the abstraction part of it without changing
the current CommAPI, on top of it, as an adapter. Even if the removable
device semantics are not implemented, but offered, this is already a step
forward.

> It's like asking that the Socket api should identify the computer behind
> an IP address (ie by its Ethernet address). While this COULD be
> implemented in TCP/IP, it IS not, and hence there is no point adding such
> a function to the Socket API.

Thank you for bringing up this example - I guess this is just about the same
thing that I'd like to see. Socket transparently provides you with the
input/output streams, at the same time offering protocol level specifics to
you.

> The current trend for USB/Bluetooth/Irda/etc connected devices is going
> away from serial port abstraction towards RPC (ie the drivers provide a
> device specific or device class specific driver that provides an
> application level api to the device functions). The line level protocol is
> often not even published.

I can't say I'm that happy with it. The best (or, rather, worst) example is
suchlike support for the Phidget servo controller - zealous Linux developers
implemented kernel module support for it, completely hijacking a possibility
of using it on a different level (it's somewhat fixed by now, thankfully).

I believe that whenever an abstraction is offered, it must be made optional
and/or pluggable so it can be replaced by something more suited to the task.

The nature of Java applications is such that they'd probably care much more
about Java API offered, than about no matter how rich application level api
that is offered outside of Java. I've dealt with JNI adapters in the past,
and whereas they can be made reasonably stable, the very fact that you are
forced to deal with things that are not on the critical timing/memory path
and could've been done much easier in Java causes endless grief.

> Joachim

--vt


From lyon at docjava.com  Sat Jun 24 04:54:12 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Sat, 24 Jun 2006 06:54:12 -0400
Subject: [Rxtx] jsr
In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
	<CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
	<20060623172829.GA5335@freehold.crocodile.org>
Message-ID: <p060204a3c0c2c9dde4f8@[192.168.1.152]>

Hi All,
I have had some off-list discussion with Trent.
Opening up a JSR with Sun, as per Peters' suggestion
seems like a reasonable idea, to us.

Does anyone having any concerns about the JSR process
that they would like to raise?

Thanks!
  - Doug



From the.grey.lantern at gmail.com  Sat Jun 24 18:15:26 2006
From: the.grey.lantern at gmail.com (Craig Nicoll)
Date: Sun, 25 Jun 2006 01:15:26 +0100
Subject: [Rxtx] Cannot create virtual serial port
Message-ID: <a1221cc50606241715g2d1e2af6r747347dd4c20e997@mail.gmail.com>

Hello,

This is my first post on this mailing list and I hope someone can help me.

I am having great difficult establishing a virtual serial port for the
Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia
7600.

Every time I try to run the SendMessage program that comes with SMSLib, I
get the following exception: gnu.io.NoSuchPortException

The port names I have tried are:
rfcomm0
rfcomm
/dev/rfcomm0
/dev/rfcomm

This is what I have done so far:
Modified /etc/bluetooth/rfcomm.conf to include the address of my phone:

rfcomm0 {
# Automatically bind the device at startup
bind no;

# Bluetooth address of the device
device 00:0e:6d:7a:98:43;

# RFCOMM channel for the connection
channel 1;

# Description of the connection
comment "Example Bluetooth device";
}

I also tried running the following command: rfcomm bind /dev/rfcomm0

I have searched the mailing list archives and found this post where someone
had a very similar problem to me:
http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried
changing the system properties as suggested and it made no difference.

I have also been scouring Google all day to no avail.

I would be incredibly grateful if anyone could give me some tips.

Thank you,

Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060625/cfa6df35/attachment-0001.html

From tjarvi at qbang.org  Sun Jun 25 19:56:08 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT)
Subject: [Rxtx] Pending release
Message-ID: <Pine.LNX.4.61.0606251942460.15744@www>


With frustration, I was unable to get to the pending release this weekend.
The release should be comming this next week once things calm down.
The source is in CVS except for a fix for multiple ports in windows.

I had planned on doing the release this weekend but that was disrupted by 
my transportation failing in a spectacular fashion.

--
Trent Jarvi
tjarvi at qbang.org


From Pawan.Kharbanda at dot.state.co.us  Tue Jun 27 22:28:51 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 27 Jun 2006 22:28:51 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>

 Trent, 
   I have an application running in a cluster in linux environment and I
am using RXTX2.1.7 (final) with JDK1.5. The application opens and closes
serial comm ports every 30 seconds and exchanges datas. I have
experienced some of my Comm Ports are left hanging (I can see the
LCK..cufXX lock files under /var/lock folder). On putting the debugs I
found out that, it is stuck at a native call line 809 in RXTXPort.java
class (Please see the code snippet below). Can you help me explain what
this method does in the native code? Am I getting into some thread
deadlocks? Thanks in advance.

Pawan Kharbanda 


public void removeEventListener()
	{
		if (debug)
			z.reportln( "RXTXPort:removeEventListener()
called");
		waitForTheNativeCodeSilly();
		//if( monThread != null && monThread.isAlive() )
		if( monThreadisInterrupted == true )
		{
			z.reportln( "	RXTXPort:removeEventListener()
already interrupted");
			monThread = null;
			SPEventListener = null;
			return;
		}
		else if( monThread != null && monThread.isAlive() )
		{
			if (debug)
				z.reportln( "
RXTXPort:Interrupt=true");
			monThreadisInterrupted=true;
			/*
			   Notify all threads in this PID that something
is up
			   They will call back to see if its their
thread
			   using isInterrupted().
			*/
			if (debug)
				z.reportln( "	RXTXPort:calling
interruptEventLoop");
// LINE 809			interruptEventLoop( ); It never returns
out of this 
			
			if (debug)
				z.reportln( "	RXTXPort:calling
monThread.join()");
			try {
				monThread.join(1000);
			} catch (Exception ex) {
				/* yikes */
				ex.printStackTrace();
			}
			if (debug)
				z.reportln( "	RXTXPort:waiting on
isAlive()");
			while( monThread.isAlive() )
			{
				if ( debug )
					z.reportln( "	MonThread is
still alive!");
				try {
					monThread.join(1000);
					Thread.sleep( 1000 );
				} catch( Exception e ){} 
				//monThread.stop();
			}
			
		}
		if (debug)
			z.reportln( "	RXTXPort:calling gc()");
		monThread = null;
		SPEventListener = null;
		MonitorThreadLock = false;
		MonitorThreadAlive=false;
		monThreadisInterrupted=true;
		z.reportln( "RXTXPort:removeEventListener() returning");
	} 

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Sunday, June 25, 2006 7:56 PM
To: rxtx at qbang.org
Subject: [Rxtx] Pending release


With frustration, I was unable to get to the pending release this
weekend.
The release should be comming this next week once things calm down.
The source is in CVS except for a fix for multiple ports in windows.

I had planned on doing the release this weekend but that was disrupted
by my transportation failing in a spectacular fashion.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Wed Jun 28 04:17:29 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 28 Jun 2006 04:17:29 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606280406330.9561@www>



Hi Pawan

You may have found a deadlock but I've not seen on recently on linux.

If you can, please update from CVS.  This will have some close fixes. 
I'm running with the same code as is in CVS.  It is not perfect but I've 
not seen anything like you mention.  Be sure to set timeouts and 
thresholds on the port.  It may be that the port is waiting on pending io 
that never happens.  I think the CVS patches deal with this also but it 
looks like your in a better test environment to know for sure.

The exploded vehicle mentioned below is expected to be fixed today.  It 
was just a ninja small radiator hose.  The pressure test afterwards 
created its own set of problems.  Until this is resolved, I'm spending 
most of my free time commuting by bicycle.

On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>   I have an application running in a cluster in linux environment and I
> am using RXTX2.1.7 (final) with JDK1.5. The application opens and closes
> serial comm ports every 30 seconds and exchanges datas. I have
> experienced some of my Comm Ports are left hanging (I can see the
> LCK..cufXX lock files under /var/lock folder). On putting the debugs I
> found out that, it is stuck at a native call line 809 in RXTXPort.java
> class (Please see the code snippet below). Can you help me explain what
> this method does in the native code? Am I getting into some thread
> deadlocks? Thanks in advance.
>
> Pawan Kharbanda
>
>
> public void removeEventListener()
> 	{
> 		if (debug)
> 			z.reportln( "RXTXPort:removeEventListener()
> called");
> 		waitForTheNativeCodeSilly();
> 		//if( monThread != null && monThread.isAlive() )
> 		if( monThreadisInterrupted == true )
> 		{
> 			z.reportln( "	RXTXPort:removeEventListener()
> already interrupted");
> 			monThread = null;
> 			SPEventListener = null;
> 			return;
> 		}
> 		else if( monThread != null && monThread.isAlive() )
> 		{
> 			if (debug)
> 				z.reportln( "
> RXTXPort:Interrupt=true");
> 			monThreadisInterrupted=true;
> 			/*
> 			   Notify all threads in this PID that something
> is up
> 			   They will call back to see if its their
> thread
> 			   using isInterrupted().
> 			*/
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> interruptEventLoop");
> // LINE 809			interruptEventLoop( ); It never returns
> out of this
>
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> monThread.join()");
> 			try {
> 				monThread.join(1000);
> 			} catch (Exception ex) {
> 				/* yikes */
> 				ex.printStackTrace();
> 			}
> 			if (debug)
> 				z.reportln( "	RXTXPort:waiting on
> isAlive()");
> 			while( monThread.isAlive() )
> 			{
> 				if ( debug )
> 					z.reportln( "	MonThread is
> still alive!");
> 				try {
> 					monThread.join(1000);
> 					Thread.sleep( 1000 );
> 				} catch( Exception e ){}
> 				//monThread.stop();
> 			}
>
> 		}
> 		if (debug)
> 			z.reportln( "	RXTXPort:calling gc()");
> 		monThread = null;
> 		SPEventListener = null;
> 		MonitorThreadLock = false;
> 		MonitorThreadAlive=false;
> 		monThreadisInterrupted=true;
> 		z.reportln( "RXTXPort:removeEventListener() returning");
> 	}
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Sunday, June 25, 2006 7:56 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] Pending release
>
>
> With frustration, I was unable to get to the pending release this
> weekend.
> The release should be comming this next week once things calm down.
> The source is in CVS except for a fix for multiple ports in windows.
>
> I had planned on doing the release this weekend but that was disrupted
> by my transportation failing in a spectacular fashion.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From Pawan.Kharbanda at dot.state.co.us  Wed Jun 28 12:11:06 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Wed, 28 Jun 2006 12:11:06 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>

Trent,
    Again thanks for the reply. First of all I have Receive timeouts set
on all communications including Max no of bytes to expect during the
call. I have noticed the problem is during "closing the connection". I
am not sure if the RXTX is 100% thread-safe yet. There seems to be a
glitch in the native calls. I am sure I have the latest code I did the
update on the Version 2.1.7 from CVS, is this where the latest updates
are located, I have noticed another version in CVS "rxtx-devel".

Regards
Pawan Kharbanda

    

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Wednesday, June 28, 2006 4:17 AM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports



Hi Pawan

You may have found a deadlock but I've not seen on recently on linux.

If you can, please update from CVS.  This will have some close fixes. 
I'm running with the same code as is in CVS.  It is not perfect but I've
not seen anything like you mention.  Be sure to set timeouts and
thresholds on the port.  It may be that the port is waiting on pending
io that never happens.  I think the CVS patches deal with this also but
it looks like your in a better test environment to know for sure.

The exploded vehicle mentioned below is expected to be fixed today.  It
was just a ninja small radiator hose.  The pressure test afterwards
created its own set of problems.  Until this is resolved, I'm spending
most of my free time commuting by bicycle.

On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>   I have an application running in a cluster in linux environment and 
> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and 
> closes serial comm ports every 30 seconds and exchanges datas. I have 
> experienced some of my Comm Ports are left hanging (I can see the 
> LCK..cufXX lock files under /var/lock folder). On putting the debugs I

> found out that, it is stuck at a native call line 809 in RXTXPort.java

> class (Please see the code snippet below). Can you help me explain 
> what this method does in the native code? Am I getting into some 
> thread deadlocks? Thanks in advance.
>
> Pawan Kharbanda
>
>
> public void removeEventListener()
> 	{
> 		if (debug)
> 			z.reportln( "RXTXPort:removeEventListener()
called");
> 		waitForTheNativeCodeSilly();
> 		//if( monThread != null && monThread.isAlive() )
> 		if( monThreadisInterrupted == true )
> 		{
> 			z.reportln( "	RXTXPort:removeEventListener()
> already interrupted");
> 			monThread = null;
> 			SPEventListener = null;
> 			return;
> 		}
> 		else if( monThread != null && monThread.isAlive() )
> 		{
> 			if (debug)
> 				z.reportln( "
> RXTXPort:Interrupt=true");
> 			monThreadisInterrupted=true;
> 			/*
> 			   Notify all threads in this PID that something
is up
> 			   They will call back to see if its their
thread
> 			   using isInterrupted().
> 			*/
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> interruptEventLoop");
> // LINE 809			interruptEventLoop( ); It never returns
> out of this
>
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> monThread.join()");
> 			try {
> 				monThread.join(1000);
> 			} catch (Exception ex) {
> 				/* yikes */
> 				ex.printStackTrace();
> 			}
> 			if (debug)
> 				z.reportln( "	RXTXPort:waiting on
> isAlive()");
> 			while( monThread.isAlive() )
> 			{
> 				if ( debug )
> 					z.reportln( "	MonThread is
> still alive!");
> 				try {
> 					monThread.join(1000);
> 					Thread.sleep( 1000 );
> 				} catch( Exception e ){}
> 				//monThread.stop();
> 			}
>
> 		}
> 		if (debug)
> 			z.reportln( "	RXTXPort:calling gc()");
> 		monThread = null;
> 		SPEventListener = null;
> 		MonitorThreadLock = false;
> 		MonitorThreadAlive=false;
> 		monThreadisInterrupted=true;
> 		z.reportln( "RXTXPort:removeEventListener() returning");
> 	}
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf

> Of Trent Jarvi
> Sent: Sunday, June 25, 2006 7:56 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] Pending release
>
>
> With frustration, I was unable to get to the pending release this 
> weekend.
> The release should be comming this next week once things calm down.
> The source is in CVS except for a fix for multiple ports in windows.
>
> I had planned on doing the release this weekend but that was disrupted

> by my transportation failing in a spectacular fashion.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Wed Jun 28 12:26:21 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 28 Jun 2006 12:26:21 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606281222420.9561@www>


Hi Pawan

If you did a cvs update from the 2.1-7 tar ball, you have the current 
version.  All rxtx in CVS is under rxtx-devel.  The 2.1-7 just has -r
commapi-0-0-1.

You may well have found something.  I have seen win32 fail on closing 
ports but not linux that I can think of.  Your use is much different than 
I normally see too.

Could you give us more information on how we would reproduce this and the 
frequency?


On Wed, 28 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>    Again thanks for the reply. First of all I have Receive timeouts set
> on all communications including Max no of bytes to expect during the
> call. I have noticed the problem is during "closing the connection". I
> am not sure if the RXTX is 100% thread-safe yet. There seems to be a
> glitch in the native calls. I am sure I have the latest code I did the
> update on the Version 2.1.7 from CVS, is this where the latest updates
> are located, I have noticed another version in CVS "rxtx-devel".
>
> Regards
> Pawan Kharbanda
>
>
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Wednesday, June 28, 2006 4:17 AM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] Locked Ports
>
>
>
> Hi Pawan
>
> You may have found a deadlock but I've not seen on recently on linux.
>
> If you can, please update from CVS.  This will have some close fixes.
> I'm running with the same code as is in CVS.  It is not perfect but I've
> not seen anything like you mention.  Be sure to set timeouts and
> thresholds on the port.  It may be that the port is waiting on pending
> io that never happens.  I think the CVS patches deal with this also but
> it looks like your in a better test environment to know for sure.
>
> The exploded vehicle mentioned below is expected to be fixed today.  It
> was just a ninja small radiator hose.  The pressure test afterwards
> created its own set of problems.  Until this is resolved, I'm spending
> most of my free time commuting by bicycle.
>
> On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:
>
>> Trent,
>>   I have an application running in a cluster in linux environment and
>> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and
>> closes serial comm ports every 30 seconds and exchanges datas. I have
>> experienced some of my Comm Ports are left hanging (I can see the
>> LCK..cufXX lock files under /var/lock folder). On putting the debugs I
>
>> found out that, it is stuck at a native call line 809 in RXTXPort.java
>
>> class (Please see the code snippet below). Can you help me explain
>> what this method does in the native code? Am I getting into some
>> thread deadlocks? Thanks in advance.
>>
>> Pawan Kharbanda
>>
>>
>> public void removeEventListener()
>> 	{
>> 		if (debug)
>> 			z.reportln( "RXTXPort:removeEventListener()
> called");
>> 		waitForTheNativeCodeSilly();
>> 		//if( monThread != null && monThread.isAlive() )
>> 		if( monThreadisInterrupted == true )
>> 		{
>> 			z.reportln( "	RXTXPort:removeEventListener()
>> already interrupted");
>> 			monThread = null;
>> 			SPEventListener = null;
>> 			return;
>> 		}
>> 		else if( monThread != null && monThread.isAlive() )
>> 		{
>> 			if (debug)
>> 				z.reportln( "
>> RXTXPort:Interrupt=true");
>> 			monThreadisInterrupted=true;
>> 			/*
>> 			   Notify all threads in this PID that something
> is up
>> 			   They will call back to see if its their
> thread
>> 			   using isInterrupted().
>> 			*/
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> interruptEventLoop");
>> // LINE 809			interruptEventLoop( ); It never returns
>> out of this
>>
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> monThread.join()");
>> 			try {
>> 				monThread.join(1000);
>> 			} catch (Exception ex) {
>> 				/* yikes */
>> 				ex.printStackTrace();
>> 			}
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:waiting on
>> isAlive()");
>> 			while( monThread.isAlive() )
>> 			{
>> 				if ( debug )
>> 					z.reportln( "	MonThread is
>> still alive!");
>> 				try {
>> 					monThread.join(1000);
>> 					Thread.sleep( 1000 );
>> 				} catch( Exception e ){}
>> 				//monThread.stop();
>> 			}
>>
>> 		}
>> 		if (debug)
>> 			z.reportln( "	RXTXPort:calling gc()");
>> 		monThread = null;
>> 		SPEventListener = null;
>> 		MonitorThreadLock = false;
>> 		MonitorThreadAlive=false;
>> 		monThreadisInterrupted=true;
>> 		z.reportln( "RXTXPort:removeEventListener() returning");
>> 	}
>>
>> -----Original Message-----
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
>
>> Of Trent Jarvi
>> Sent: Sunday, June 25, 2006 7:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] Pending release
>>
>>
>> With frustration, I was unable to get to the pending release this
>> weekend.
>> The release should be comming this next week once things calm down.
>> The source is in CVS except for a fix for multiple ports in windows.
>>
>> I had planned on doing the release this weekend but that was disrupted
>
>> by my transportation failing in a spectacular fashion.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From Pawan.Kharbanda at dot.state.co.us  Wed Jun 28 15:42:49 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Wed, 28 Jun 2006 15:42:49 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>

Trent,
    I will try to explain how I am setup and will try to write you a
Sample code little later to reproduce this. On our system we have
DigiBoxes installed on the 2 Linux servers. Both of them have RXTX2.1-7
version installed with the JRE(1.5) and both the machines have the same
port mappings in gnu.io.rxtx.properties (Currently in the production
system I have 64 ports). This is how the system works:

1) A thick Map based client initiates a Action on the Device on the
field. One of the Thread Workers(Asynchronous Call) in the Cluster picks
up the request. 
2) Once the worker gets the request it locks the Device and
Communication port in the DB's(These are our persistent locks, because
most of the devices do one to one communication with the serial ports).
After that the worker (or Comm Server) opens up the connection and after
exchanging the information calls the "Close" and returns.
3) Once the connection is closed , the DB lock is removed on the comm
port and is made available to accept future calls. Here is where the
glitch is the Serial Comm Close method never returns due to the
deadlock. 

I have noticed that the deadlocks are very inconsistent, sometime it
happens right away as soon as Application server starts and sometimes I
don't see any deadlocks for days, but it happens for sure. 

Here is how you can test if you have resources/ test environment. Write
a program and try to open/close  different ports(I will say have a
minimum of four) randomly and very frequently(may be 30 seconds), I am
pretty sure you will see the deadlocks and it happens in the native call
to interrptEventLoop in RXTXPort.java in removeEventListener() method
call.

Also I have noticed that the JVM carshes (without any memrory errors or
JVM errors. Its just not there) when native call is made to eventLoop()
in run() method in MonitorThread inner class. I am still investigating
why this is happening, but at this point I can just tell you the
location. You might have a question How I am so sure about the location?
My application is configured with Log4J and I have enabled the debugs on
the RXTXPort.java, so every time my JVM dies I see these logs at the end
of the file.

"2006-06-28 15:27:15,183 INFO  [STDOUT] RXTXPort:RXTXPort(/dev/cub01)
called
2006-06-28 15:27:15,218 INFO  [STDOUT]
RXTXPort:MontitorThread:MonitorThread()
2006-06-28 15:27:15,219 INFO  [STDOUT] RXTXPort:MontitorThread:run()"

I surely do have a luxury of a testing environment(ports, devices etc.)
and can help you fix these problems? Please advise me how we can resolve
these issues.

Thanks 
Pawan Kharbanda
303-478-2991





-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Wednesday, June 28, 2006 12:26 PM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports


Hi Pawan

If you did a cvs update from the 2.1-7 tar ball, you have the current
version.  All rxtx in CVS is under rxtx-devel.  The 2.1-7 just has -r
commapi-0-0-1.

You may well have found something.  I have seen win32 fail on closing
ports but not linux that I can think of.  Your use is much different
than I normally see too.

Could you give us more information on how we would reproduce this and
the frequency?


On Wed, 28 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>    Again thanks for the reply. First of all I have Receive timeouts
set
> on all communications including Max no of bytes to expect during the
> call. I have noticed the problem is during "closing the connection". I
> am not sure if the RXTX is 100% thread-safe yet. There seems to be a
> glitch in the native calls. I am sure I have the latest code I did the
> update on the Version 2.1.7 from CVS, is this where the latest updates
> are located, I have noticed another version in CVS "rxtx-devel".
>
> Regards
> Pawan Kharbanda
>
>
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Wednesday, June 28, 2006 4:17 AM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] Locked Ports
>
>
>
> Hi Pawan
>
> You may have found a deadlock but I've not seen on recently on linux.
>
> If you can, please update from CVS.  This will have some close fixes.
> I'm running with the same code as is in CVS.  It is not perfect but
I've
> not seen anything like you mention.  Be sure to set timeouts and
> thresholds on the port.  It may be that the port is waiting on pending
> io that never happens.  I think the CVS patches deal with this also
but
> it looks like your in a better test environment to know for sure.
>
> The exploded vehicle mentioned below is expected to be fixed today.
It
> was just a ninja small radiator hose.  The pressure test afterwards
> created its own set of problems.  Until this is resolved, I'm spending
> most of my free time commuting by bicycle.
>
> On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:
>
>> Trent,
>>   I have an application running in a cluster in linux environment and
>> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and
>> closes serial comm ports every 30 seconds and exchanges datas. I have
>> experienced some of my Comm Ports are left hanging (I can see the
>> LCK..cufXX lock files under /var/lock folder). On putting the debugs
I
>
>> found out that, it is stuck at a native call line 809 in
RXTXPort.java
>
>> class (Please see the code snippet below). Can you help me explain
>> what this method does in the native code? Am I getting into some
>> thread deadlocks? Thanks in advance.
>>
>> Pawan Kharbanda
>>
>>
>> public void removeEventListener()
>> 	{
>> 		if (debug)
>> 			z.reportln( "RXTXPort:removeEventListener()
> called");
>> 		waitForTheNativeCodeSilly();
>> 		//if( monThread != null && monThread.isAlive() )
>> 		if( monThreadisInterrupted == true )
>> 		{
>> 			z.reportln( "	RXTXPort:removeEventListener()
>> already interrupted");
>> 			monThread = null;
>> 			SPEventListener = null;
>> 			return;
>> 		}
>> 		else if( monThread != null && monThread.isAlive() )
>> 		{
>> 			if (debug)
>> 				z.reportln( "
>> RXTXPort:Interrupt=true");
>> 			monThreadisInterrupted=true;
>> 			/*
>> 			   Notify all threads in this PID that something
> is up
>> 			   They will call back to see if its their
> thread
>> 			   using isInterrupted().
>> 			*/
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> interruptEventLoop");
>> // LINE 809			interruptEventLoop( ); It never returns
>> out of this
>>
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> monThread.join()");
>> 			try {
>> 				monThread.join(1000);
>> 			} catch (Exception ex) {
>> 				/* yikes */
>> 				ex.printStackTrace();
>> 			}
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:waiting on
>> isAlive()");
>> 			while( monThread.isAlive() )
>> 			{
>> 				if ( debug )
>> 					z.reportln( "	MonThread is
>> still alive!");
>> 				try {
>> 					monThread.join(1000);
>> 					Thread.sleep( 1000 );
>> 				} catch( Exception e ){}
>> 				//monThread.stop();
>> 			}
>>
>> 		}
>> 		if (debug)
>> 			z.reportln( "	RXTXPort:calling gc()");
>> 		monThread = null;
>> 		SPEventListener = null;
>> 		MonitorThreadLock = false;
>> 		MonitorThreadAlive=false;
>> 		monThreadisInterrupted=true;
>> 		z.reportln( "RXTXPort:removeEventListener() returning");
>> 	}
>>
>> -----Original Message-----
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On
Behalf
>
>> Of Trent Jarvi
>> Sent: Sunday, June 25, 2006 7:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] Pending release
>>
>>
>> With frustration, I was unable to get to the pending release this
>> weekend.
>> The release should be comming this next week once things calm down.
>> The source is in CVS except for a fix for multiple ports in windows.
>>
>> I had planned on doing the release this weekend but that was
disrupted
>
>> by my transportation failing in a spectacular fashion.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx 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 khattar31 at yahoo.com  Wed Jun 28 22:04:59 2006
From: khattar31 at yahoo.com (rahul khattar)
Date: Wed, 28 Jun 2006 21:04:59 -0700 (PDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
Message-ID: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>

Hi All,

I was looking at the src file on the last release.
I did notice a missing header file while trying to
compile the parallelport.dll. Would somebody be kind
enoughf to share the missing header file:
gnu_io_LPRPort.h

I am using MinGw to compile the same from Parinya
(which is an execellent tool)


Regards,
Rahul Khattar

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Thu Jun 29 03:43:53 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 03:43:53 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>
References: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606290341210.9561@www>

On Wed, 28 Jun 2006, rahul khattar wrote:

> Hi All,
>
> I was looking at the src file on the last release.
> I did notice a missing header file while trying to
> compile the parallelport.dll. Would somebody be kind
> enoughf to share the missing header file:
> gnu_io_LPRPort.h
>
> I am using MinGw to compile the same from Parinya
> (which is an execellent tool)
>

Hi Rahul

The gnu.io_LPRPort.h file is generated with javah.  You can see the 
command in the Makefile I presume.  You do not need rxtxParallel.dll to 
use w32 serial btw.

--
Trent Jarvi
tjarvi at qbang.org


From khattar31 at yahoo.com  Thu Jun 29 04:47:01 2006
From: khattar31 at yahoo.com (rahul khattar)
Date: Thu, 29 Jun 2006 03:47:01 -0700 (PDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606290341210.9561@www>
Message-ID: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>

Hi Trent 
I did notice this file is required in the source file
ParallelImp.c
on line 38

Attached the O/P 

Regards,
Rahul Khattar




--- Trent Jarvi <tjarvi at qbang.org> wrote:

> On Wed, 28 Jun 2006, rahul khattar wrote:
> 
> > Hi All,
> >
> > I was looking at the src file on the last release.
> > I did notice a missing header file while trying to
> > compile the parallelport.dll. Would somebody be
> kind
> > enoughf to share the missing header file:
> > gnu_io_LPRPort.h
> >
> > I am using MinGw to compile the same from Parinya
> > (which is an execellent tool)
> >
> 
> Hi Rahul
> 
> The gnu.io_LPRPort.h file is generated with javah. 
> You can see the 
> command in the Makefile I presume.  You do not need
> rxtxParallel.dll to 
> use w32 serial btw.
> 
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Error.zip
Type: application/x-zip-compressed
Size: 1746 bytes
Desc: 2948039066-Error.zip
Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060629/a5b6f783/Error-0010.bin

From tjarvi at qbang.org  Thu Jun 29 06:16:24 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 06:16:24 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606290614530.9561@www>

On Thu, 29 Jun 2006, rahul khattar wrote:

> Hi Trent
> I did notice this file is required in the source file
> ParallelImp.c
> on line 38
>
> Attached the O/P
>

The command to generate the .h file will be something like:

javah -classpath . -jni gnu.io.LPRPort

The makefile should have this.  There are several approaches to creating 
or using makefiles so I have no idea which one you used if any.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Thu Jun 29 06:20:51 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 06:20:51 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606290616420.9561@www>

> Here is how you can test if you have resources/ test environment. Write
> a program and try to open/close  different ports(I will say have a
> minimum of four) randomly and very frequently(may be 30 seconds), I am
> pretty sure you will see the deadlocks and it happens in the native call
> to interrptEventLoop in RXTXPort.java in removeEventListener() method
> call.

Hi Pawan

I'll try to find a way to reproduce this.  One thing to note is that you 
are using different kernel drivers (digi) to perform this task.  So I 
probably will not be able to reproduce the exact same environment.

In general, multiport kernel drivers have been tested far less than 
typical serial drivers.  This may or may not be an issue.

--
Trent Jarvi
tjarvi at qbang.org



From jhaysonn at gmail.com  Thu Jun 29 12:29:13 2006
From: jhaysonn at gmail.com (jhaysonn pathak)
Date: Thu, 29 Jun 2006 14:29:13 -0400
Subject: [Rxtx] RXTX install
Message-ID: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>

Hi Guys,

I'm doing trying to write a generative piece of Sonic Art using an EEG
plugged into a mac runnning Max/MSP.  I just recently discovered RXTX
drivers in my search for a piece of software that might give me more
output options for my EEG (I'm using the CEO from MindPeak).  I found
Bioera which uses RXTX drivers.  Thing is - I can't figure out how to
install RXTX correctly.

After I build the 'libSerial.jnilib' target inside of
'LibSerial.pbproj' I can't find the libSerial.jnilib file that
accompanies the RXTXcomm.jar nor do I know where to put them.

I also don't understand this part at the bottom of the OS X instructions at all:

"AFTER INSTALLATION VERY IMPORTANT
	check existence of the folder /var/spool/uucp
	if you don't have it create it with command
	sudo mkdir /var/spool/uucp
	permissions should be: drwxrwxr-x
	if they are not do command
	sudo chmod 775 /var/spool/uucp

	YOU should be a member of the uucp group
	you can check it with command
		niutil -readprop / /groups/uucp users
	you should see your name in output of the niutil command
	if you don't do following:
		sudo niutil -appendprop / /groups/uucp users <yourname>
			substitute  <yourname> with your user's name
			for example if your user name is peter:
				sudo niutil -appendprop / /groups/uucp users peter

	NOTES: RXTX.pkg should create uucp folder and insert your name  in
uucp group automatically"



I really appreciate any help that you guys can offer.  I've been
struggling with this for a while now as part of a research grant that
I was awarded.  Thanks again for the help.

Jhaysonn Pathak


From naranjo.manuel at gmail.com  Thu Jun 29 07:19:15 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 10:19:15 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606290614530.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www>
Message-ID: <44A3D353.6010605@gmail.com>

Speaking about Windows Support, I had seen that inside the 
rxtx-2.1-7-bins-r2 package inside Windows directory it says:
"i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will 
not make harm to anyone, and i'm almost sure that someone has noticed it 
before.
Cheers,
Manuel


From joachim at buechse.de  Thu Jun 29 13:25:16 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 29 Jun 2006 21:25:16 +0200
Subject: [Rxtx] RXTX install
In-Reply-To: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>
References: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>
Message-ID: <2A003E42-97E1-4237-8438-646BDE2E3961@buechse.de>

Hello Jhaysonn,

I assume you are trying to use the javax.comm version of RXTX.

Please use "cvs up" to update your download to the latest version of  
the repository. The latest version does not use lock files, so the  
mentioned process is no longer needed. Updating with CVS will also  
provide you with a new README.OSX file that should be simpler to  
understand.

You will find LibSerialUniversal.xcodeproj in MACOSX_IDE/Xcode. Put  
comm.jar (downloaded from Sun) into MACOSX_IDE/Xcode. Compile the  
library. You will find RXTXcomm.jar and librxtxSerial.jnilib in  
MACOSX_IDE/Xcode/build/Default

Best regards,
Joachim
---
Joachim B?chse
Softwarel?sungen und Beratung
Hadlaubsteig 2
CH-8006 Z?rich


On 29.06.2006, at 20:29, jhaysonn pathak wrote:

> Hi Guys,
>
> I'm doing trying to write a generative piece of Sonic Art using an EEG
> plugged into a mac runnning Max/MSP.  I just recently discovered RXTX
> drivers in my search for a piece of software that might give me more
> output options for my EEG (I'm using the CEO from MindPeak).  I found
> Bioera which uses RXTX drivers.  Thing is - I can't figure out how to
> install RXTX correctly.
>
> After I build the 'libSerial.jnilib' target inside of
> 'LibSerial.pbproj' I can't find the libSerial.jnilib file that
> accompanies the RXTXcomm.jar nor do I know where to put them.
>
> I also don't understand this part at the bottom of the OS X  
> instructions at all:
>
> "AFTER INSTALLATION VERY IMPORTANT
> 	check existence of the folder /var/spool/uucp
> 	if you don't have it create it with command
> 	sudo mkdir /var/spool/uucp
> 	permissions should be: drwxrwxr-x
> 	if they are not do command
> 	sudo chmod 775 /var/spool/uucp
>
> 	YOU should be a member of the uucp group
> 	you can check it with command
> 		niutil -readprop / /groups/uucp users
> 	you should see your name in output of the niutil command
> 	if you don't do following:
> 		sudo niutil -appendprop / /groups/uucp users <yourname>
> 			substitute  <yourname> with your user's name
> 			for example if your user name is peter:
> 				sudo niutil -appendprop / /groups/uucp users peter
>
> 	NOTES: RXTX.pkg should create uucp folder and insert your name  in
> uucp group automatically"
>
>
>
> I really appreciate any help that you guys can offer.  I've been
> struggling with this for a while now as part of a research grant that
> I was awarded.  Thanks again for the help.
>
> Jhaysonn Pathak
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From tjarvi at qbang.org  Thu Jun 29 19:30:00 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 19:30:00 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A3D353.6010605@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
Message-ID: <Pine.LNX.4.61.0606291923000.9561@www>

On Thu, 29 Jun 2006, Manuel Naranjo wrote:

> Speaking about Windows Support, I had seen that inside the
> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
> not make harm to anyone, and i'm almost sure that someone has noticed it
> before.

Hi Manuel

         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
     47421  01-30-06 00:23 
rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
     77759  03-01-06 12:01 
rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README


It looks normal to me.  There are no fancy tools used there :)

--
Trent Jarvi
tjarvi at qbang.org

From naranjo.manuel at gmail.com  Thu Jun 29 19:38:16 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 22:38:16 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606291923000.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com> <Pine.LNX.4.61.0606291923000.9561@www>
Message-ID: <44A48088.2040407@gmail.com>

> On Thu, 29 Jun 2006, Manuel Naranjo wrote:
> 
>> Speaking about Windows Support, I had seen that inside the
>> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
>> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
>> not make harm to anyone, and i'm almost sure that someone has noticed it
>> before.
> 
> Hi Manuel
> 
>         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
>         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
>     47421  01-30-06 00:23 
> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
>     77759  03-01-06 12:01 
> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
>       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README
> 
> 
> It looks normal to me.  There are no fancy tools used there :)
> 
Hi Trent:
Is not the i368 representing the name of the Architecture?? If so the 
name should start with i386 it will not break any system, is simply miss
written, I saw that and wanted to report it. It a silly thing.
Ohh I forgoten I must congratulate you for your GREAT libray, I was able 
to make an .exe with JSmooth that launches an application that uses RXTX 
with out the need to install RXTX on users system :). The .exe tells JVM 
where to find the RXTX Library and Binaries. I tried with Sun's Java 
Comm but it was imposible.
Regards,
Manuel


From tjarvi at qbang.org  Thu Jun 29 19:52:45 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 19:52:45 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A48088.2040407@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
	<Pine.LNX.4.61.0606291923000.9561@www> <44A48088.2040407@gmail.com>
Message-ID: <Pine.LNX.4.61.0606291945060.9561@www>

On Thu, 29 Jun 2006, Manuel Naranjo wrote:

>> On Thu, 29 Jun 2006, Manuel Naranjo wrote:
>>
>>> Speaking about Windows Support, I had seen that inside the
>>> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
>>> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
>>> not make harm to anyone, and i'm almost sure that someone has noticed it
>>> before.
>>
>> Hi Manuel
>>
>>         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
>>         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
>>     47421  01-30-06 00:23
>> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
>>     77759  03-01-06 12:01
>> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
>>       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README
>>
>>
>> It looks normal to me.  There are no fancy tools used there :)
>>
> Hi Trent:
> Is not the i368 representing the name of the Architecture?? If so the
> name should start with i386 it will not break any system, is simply miss
> written, I saw that and wanted to report it. It a silly thing.
> Ohh I forgoten I must congratulate you for your GREAT libray, I was able
> to make an .exe with JSmooth that launches an application that uses RXTX
> with out the need to install RXTX on users system :). The .exe tells JVM
> where to find the RXTX Library and Binaries. I tried with Sun's Java
> Comm but it was imposible.

Hi Manuel

The compiler uses only the i386 instruction set for windows.  I doubt 
there will be any measurable advantages with going to later instruction 
sets.  In theory rxtx would run on a 386 but I doubt anyone does that.

So it looks odd but is not a typo.

We could compile to i686 but don't.  The compiler used does not appear to 
be a problem yet so I don't see any point in changing it.  Right now, we 
could not compile 64 bit windows binaries.  gcc/mingw/... do not support 
them that I know of.  People will have to compile those with closed source 
tools on their own until an option is available.

--
Trent Jarvi
tjarvi at qbang.org

From naranjo.manuel at gmail.com  Thu Jun 29 20:00:48 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 23:00:48 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606291945060.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com>	<Pine.LNX.4.61.0606291923000.9561@www>
	<44A48088.2040407@gmail.com> <Pine.LNX.4.61.0606291945060.9561@www>
Message-ID: <44A485D0.7050202@gmail.com>

Trent you did not get my point
The folder says 368 three hundred sixty eight, when
it should say 386 three hundred eighty six. Is simply a miss writting.
Regards,
Manuel


From tjarvi at qbang.org  Thu Jun 29 20:12:15 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 20:12:15 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A485D0.7050202@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
	<Pine.LNX.4.61.0606291923000.9561@www> <44A48088.2040407@gmail.com>
	<Pine.LNX.4.61.0606291945060.9561@www> <44A485D0.7050202@gmail.com>
Message-ID: <Pine.LNX.4.61.0606292008061.9561@www>


On Thu, 29 Jun 2006, Manuel Naranjo wrote:

> Trent you did not get my point
> The folder says 368 three hundred sixty eight, when
> it should say 386 three hundred eighty six. Is simply a miss writting.

hehe..  OK.  My bad.  It's been a long day.

Nevermind :)

--
Trent Jarvi
tjarvi at qbang.org




From naranjo.manuel at gmail.com  Thu Jun 29 20:18:44 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 23:18:44 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606292008061.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com>	<Pine.LNX.4.61.0606291923000.9561@www>
	<44A48088.2040407@gmail.com>	<Pine.LNX.4.61.0606291945060.9561@www>
	<44A485D0.7050202@gmail.com> <Pine.LNX.4.61.0606292008061.9561@www>
Message-ID: <44A48A04.9040401@gmail.com>

Don't worry Trent.
About 64 bits compilation, I would like to colaborate, I have a Pc with 
64 bits, the only problem is that i do not have windows 64 bits 
installed :(.




From Pawan.Kharbanda at dot.state.co.us  Fri Jun 30 08:49:52 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 30 Jun 2006 08:49:52 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E996@hqexchange3.dot.state.co.us>

Trent,  
    Can you explain what the interruptedEventLoop() native method is
doing is there a possibility that method is somehow getting into the
infinite loop(there are 2 while loops without any break statements).
This might be a very basic question how can I debug the native code(or
print the debug statements).  Again thanks for the help. 

Pawan Kharbanda

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Thursday, June 29, 2006 6:21 AM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports

> Here is how you can test if you have resources/ test environment. 
> Write a program and try to open/close  different ports(I will say have

> a minimum of four) randomly and very frequently(may be 30 seconds), I 
> am pretty sure you will see the deadlocks and it happens in the native

> call to interrptEventLoop in RXTXPort.java in removeEventListener() 
> method call.

Hi Pawan

I'll try to find a way to reproduce this.  One thing to note is that you
are using different kernel drivers (digi) to perform this task.  So I
probably will not be able to reproduce the exact same environment.

In general, multiport kernel drivers have been tested far less than
typical serial drivers.  This may or may not be an issue.

--
Trent Jarvi
tjarvi at qbang.org

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From cpine at wrsystems.com  Thu Jun 29 15:17:12 2006
From: cpine at wrsystems.com (Chris Pine)
Date: Thu, 29 Jun 2006 17:17:12 -0400
Subject: [Rxtx]  Controlling Individual Signals DTR and RTS
Message-ID: <MAIL4FJo0S8ACLEBajJ000005cf@mail4.wrsystems.com>

Dear Moussa Ba,
	I hope I am not being too forward, but we are having the exact same
issue with needing to control DTR from RXTX in Linux.  Did you ever have any
luck figuring it out?

Thank you very much for your time,

Chris Pine




From tjarvi at qbang.org  Thu Jun  1 11:13:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 11:13:40 -0600 (MDT)
Subject: [Rxtx] custom baud rate win32
In-Reply-To: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606011107210.30220@www>


Hi Daren

I can't imagine that 1953 is possibly the actual value on the UART.  Maybe 
if your baud base is very high with a custom serial board.  More likely, 
the driver just remembers that what you asked for and did something else.

I'll have more to say on the dcb->BaudRate after I try some things here. 
I have managed to do something like that in the past as a quick hack but 
it was for 14400.  I may have used the CBR_14400.

If we can't access this through the win32 API with protected mode, there 
is another layer of complication.  With real mode, it would be easy.
With protected mode, I assume there would have to be some kernel driver or 
a hook I'm not aware of to access the MCR directly (bang a memory 
addresss).



On Thu, 1 Jun 2006, Daren wrote:

> Trent,
> I have managed to successfully open the port at this speed using Realterm
> (available on sourceforge). From memory this uses DLPortIO.
>
> Using portmon.exe with realterm, even there it says that the port has opened
> at 1953.
>
> I changed termios.c:560 to
> dcb->BaudRate        = 1953 ;
>
> and it still opens the port at 9600.
>
> Daren
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Trent Jarvi
> Sent: Thursday, 1 June 2006 1:44 PM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] custom baud rate win32
>
> On Thu, 1 Jun 2006, Daren wrote:
>
>> Hi all,
>>
>> I downloaded 2.1.7-pre16 and managed to build it and get it going. I made
>> the changes as suggested by Peter Smith in an old post, by adding his code
>> to SerialImpl.c, uncommenting the TIOCGSERIAL and TIOCSSERIAL, and
> defining
>> ASYNC_SPD_CUST which is equal to 0x0030 (according to linus header
> files)..
>>
>>
>> Still not working, it opens the port at 9600 according to portmon.exe .
> Has
>> anyone managed to get this going at a custom rate?
>>
>> Here is the post I'm referring to:
>> http://marc.theaimsgroup.com/?l=rxtx&m=106270038110713&w=2
>>
>>
>> Thanks,
>> Daren
>>
>> ________________________________________
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
>> Daren
>> Sent: Wednesday, 31 May 2006 10:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] (no subject)
>>
>> Hi All,
>> I have been using rxtx for a little while and needed to get it working at
>> 1953, like a past user in the mailing list, who seemed to have got it
>> working by changing some C code.
>>
>> I wanted to build rxtx myself with these changes but don't know where to
>> start. I have windows here and FC4 at home. I downloaded cygwin and
> mingw32,
>> each build works by building a rxtxSerial.dll file that is ~11k smaller
> than
>> the original, and I always get the following error when testing the dll:
>>
>> Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at
>> PC=0x8077655
>> Function=[Unknown.]
>> Library=C:\opt\java\j2sdk1.4.2\jre\bin\client\jvm.dll
>>
>> NOTE: We are unable to locate the function name symbol for the error
>>      just occurred. Please refer to release documentation for possible
>>      reason and solutions.
>>
>>
>> Current Java thread:
>> 	at gnu.io.RXTXPort.open(Native Method)
>> 	- locked <0x1002c800> (a gnu.io.RXTXPort)
>> 	at gnu.io.RXTXPort.<init>(RXTXPort.java:84)
>>
>> Anyone know what im doing wrong?
>>
>>
>>
>>
>
> Hi Daren
>
> You are running into the same rats nest I'm looking at now.
>
> With win32 and specific custom baud rates, I'm not sure how this will go.
> I've got the Linux custom baud rates working very nicely.  I did much like
> the post you linked.  In fact I had forgot about that post.  You probably
> noticed that it becomes a bunch of dirt roads going noplace fast in
> termios.c for w32.
>
> I'm probably only going to get 14400, 28800, 128000 and 256000 working
> with the next release on w32.  I'll look a little further.  If you have an
> example w32 that works at 1953 I'd really like to hear.  Thats an unusual
> baud rate.
>
> Assuming a baud_base of 128000, your divisor will be 65 or 66.
>
> 128000/66=1939 -14
> 128000/65=1969 +13
>
> One thing I've been wondering about with linux is which would be the right
> answer in cases like this.  Right now it would just go with a baud base of
> 65 and ignore the modulus details.
>
> It appears to be a general trend for kernel developers to hide these
> details thinking that they can come up with a general solution.  Then they
> run out of time.  Perahps the solution is to help out but there are
> ultiple OS's rxtx supports making that nontrivial.
>
> If you look at current linux kernels, the 'tricks' above have been marked
> deprecated with no replacement.  Windows has some hard defines and then
> ancient near magic.  I've not looked at Solaris via Open Solaris yet but
> doubt there is a solution at all.
>
> What I'd try since you have the equipment and the monitor software is to
> hardcode the dcb->Baud in termios.c to 1953 (no define) and see what the
> w32 kernel does with it.  I think if you toss a baud rate at the driver it
> will try to come close.  You may try comming closer to a real baudrate
> based upon the 128000 baud base as shown above.
>
> If it works, it is worth looking at the rest of the ping/pong logic then.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
>
>
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From doug at dupreeinc.com  Thu Jun  1 13:22:13 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 12:22:13 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011107210.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
Message-ID: <447F3E65.1020809@dupreeinc.com>

Hello,

I am still trying to get this startup a little faster so I turned on the 
debug of a few of the classes.  The COM ports are scanned really fast 
and the delay occurs during the LPT scan.  The console output looks like 
this:

    ...
      LPT1
      LPT2
      LPT3
     valid port prefixes:
      LPT
    LPT1 LPT
    1 1
    LPT2 LPT
    2 2                                                                 
      * <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
    CommPortIdentifier:addPortName(LPT2)
    CommPortIdentifier:AddIdentifierToList()
    LPT3 LPT
    3 3
    CommPortIdentifier:addPortName(LPT3)
    CommPortIdentifier:AddIdentifierToList()
    CommPortIdentifier:AddIdentifierToList() index.next
    Leaving registerValidPorts()
    Have not implemented native_psmisc_report_owner(PortName)); in
    CommPortIdentifier
    CommPortIdentifier:getPortIdentifier(COM3)
    CommPortIdentifier:open(densConnect, 30000)
    RXTXCommDriver:getCommPort(COM3,1)
    ...

It would seem to me that if I removed the code for port scanning of LPT 
ports I could solve this problem. I would much prefer to use unmodified 
code if at all possible.  Do any of you have alternate suggestions?

Thank you for your time.

Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/cf433ee7/attachment-0011.html

From tjarvi at qbang.org  Thu Jun  1 13:52:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 13:52:06 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F3E65.1020809@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011348380.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I am still trying to get this startup a little faster so I turned on the 
> debug of a few of the classes.  The COM ports are scanned really fast and the 
> delay occurs during the LPT scan.  The console output looks like this:
>
>   ...
>     LPT1
>     LPT2
>     LPT3
>    valid port prefixes:
>     LPT
>   LPT1 LPT
>   1 1
>   LPT2 LPT
>   2 2                                                                      * 
> <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>   CommPortIdentifier:addPortName(LPT2)
>   CommPortIdentifier:AddIdentifierToList()
>   LPT3 LPT
>   3 3
>   CommPortIdentifier:addPortName(LPT3)
>   CommPortIdentifier:AddIdentifierToList()
>   CommPortIdentifier:AddIdentifierToList() index.next
>   Leaving registerValidPorts()
>   Have not implemented native_psmisc_report_owner(PortName)); in
>   CommPortIdentifier
>   CommPortIdentifier:getPortIdentifier(COM3)
>   CommPortIdentifier:open(densConnect, 30000)
>   RXTXCommDriver:getCommPort(COM3,1)
>   ...
>
> It would seem to me that if I removed the code for port scanning of LPT ports 
> I could solve this problem. I would much prefer to use unmodified code if at 
> all possible.  Do any of you have alternate suggestions?
>
> Thank you for your time.
>
> Doug
>


Does commenting out the LPT enumeration actually help?  There can often be 
differences between debug information printed and whats really going on. 
When you combine various environments the debug info can even come out in 
the wrong order.

I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
I do not think this problem is universal.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Thu Jun  1 14:29:44 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:29:44 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4E38.2060004@dupreeinc.com>

I will give it a try.  One thing to note on this PC is it has no LPT 
Parallel ports.

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
>>Hello,
>>
>>I am still trying to get this startup a little faster so I turned on the 
>>debug of a few of the classes.  The COM ports are scanned really fast and the 
>>delay occurs during the LPT scan.  The console output looks like this:
>>
>>  ...
>>    LPT1
>>    LPT2
>>    LPT3
>>   valid port prefixes:
>>    LPT
>>  LPT1 LPT
>>  1 1
>>  LPT2 LPT
>>  2 2                                                                      * 
>><<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>>  CommPortIdentifier:addPortName(LPT2)
>>  CommPortIdentifier:AddIdentifierToList()
>>  LPT3 LPT
>>  3 3
>>  CommPortIdentifier:addPortName(LPT3)
>>  CommPortIdentifier:AddIdentifierToList()
>>  CommPortIdentifier:AddIdentifierToList() index.next
>>  Leaving registerValidPorts()
>>  Have not implemented native_psmisc_report_owner(PortName)); in
>>  CommPortIdentifier
>>  CommPortIdentifier:getPortIdentifier(COM3)
>>  CommPortIdentifier:open(densConnect, 30000)
>>  RXTXCommDriver:getCommPort(COM3,1)
>>  ...
>>
>>It would seem to me that if I removed the code for port scanning of LPT ports 
>>I could solve this problem. I would much prefer to use unmodified code if at 
>>all possible.  Do any of you have alternate suggestions?
>>
>>Thank you for your time.
>>
>>Doug
>>
>>    
>>
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/dd31fed5/attachment-0011.html

From doug at dupreeinc.com  Thu Jun  1 14:36:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:36:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4FC8.9080106@dupreeinc.com>

Trent,

I commented out the section in RegisterScannedPorts() that adds the 
three LPT ports to the CandidateDeviceNames string array.  The 
application started immediately.  This is probably not the way to do 
this, but it was quick ,dirty, and worked.

It would be nice if there was a way to pole the OS to see if there is 
even a port there, though I guess this is what this code is suppose to do...

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
> ...
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From lynn at swcp.com  Thu Jun  1 14:49:34 2006
From: lynn at swcp.com (lynn@swcp.com)
Date: Thu, 1 Jun 2006 20:49:34 -0000
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>,
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <twig.1149194974.97617@swcp.com>

Perhaps we could add an argument to port enumeration where if not specified,
you get the default behavior that looks for everything.  With a new
constructor that has an argument(or more) you could optionally declare it to
not inspect printer ports.

Existing code would work as it always has.  New code could be smarter.

Lynn



Doug Thistlethwaite <doug at dupreeinc.com> said:

> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
> >On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
> >
> >  
> >
> > ...
> >
> >
> >Does commenting out the LPT enumeration actually help?  There can often be 
> >differences between debug information printed and whats really going on. 
> >When you combine various environments the debug info can even come out in 
> >the wrong order.
> >
> >I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
> >I do not think this problem is universal.
> >
> >--
> >Trent Jarvi
> >tjarvi at qbang.org
> >_______________________________________________
> >Rxtx mailing list
> >Rxtx at qbang.org
> >http://mailman.qbang.org/mailman/listinfo/rxtx
> >
> >
> >  
> >
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



-- 





From jredman at ergotech.com  Thu Jun  1 15:20:20 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 01 Jun 2006 15:20:20 -0600
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
Message-ID: <447F5A14.6010803@ergotech.com>

Doug,

If you specifically request ports, eg:

-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

or
 
-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

Depending upon the version  (Windows is COM1:COM2, etc. I assume).

Does it still enumerate the parallel ports?

Jim

Doug Thistlethwaite wrote:
> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
>> On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>
>>  
>>
>> ...
>>
>>
>> Does commenting out the LPT enumeration actually help?  There can often be 
>> differences between debug information printed and whats really going on. 
>> When you combine various environments the debug info can even come out in 
>> the wrong order.
>>
>> I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>> I do not think this problem is universal.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>>
>>  
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  1 16:49:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:49:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6EF4.7080709@dupreeinc.com>

I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
folder.  I created this file and added the following to the file:

gnu.io.rxtx.SerialPorts=COM3

and I get the following error on the console:
CommPortIdentifier:static initialization()
RXTXCommDriver {}
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
RXTXCommDriver:
    Jar version = RXTX-2.1-7
    native lib Version = RXTX-2.1-7
RXTXCommDriver:initialize()
checking for system-known ports of type 1
checking registry for ports of type 1

RXTXCommDriver:addSpecifiedPorts()
Exception in thread "main" java.lang.ExceptionInInitializerError
    at 
densconnect.SerialConnection.openConnection(SerialConnection.java:136)
    at densconnect.DensTalk.<init>(DensTalk.java:165)
    at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
    at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
    at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
    at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
Caused by: java.lang.NullPointerException
    at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
CommPortIdentifier:addPortName(COM3)
CommPortIdentifier:AddIdentifierToList()
CommPortIdentifier:AddIdentifierToList() null
...


It looks like it  read COM3 from the file, but it had the above 
exception that killed it.  The strange this is this error is from 
RXTXCommDriver initialize function (if statement line):

        OS = System.getProperty("os.name");
                System.out.println("OS NAME: " + OS);
        if(OS.toLowerCase().indexOf("linux") == -1)

OS is returning null, thus the error.

If the file is not present, it scans the ports and reads the OS.

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>Doug Thistlethwaite wrote:
>  
>
>>Trent,
>>
>>I commented out the section in RegisterScannedPorts() that adds the 
>>three LPT ports to the CandidateDeviceNames string array.  The 
>>application started immediately.  This is probably not the way to do 
>>this, but it was quick ,dirty, and worked.
>>
>>It would be nice if there was a way to pole the OS to see if there is 
>>even a port there, though I guess this is what this code is suppose to do...
>>
>>Doug
>>
>>Trent Jarvi wrote:
>>
>>    
>>
>>>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>>
>>> 
>>>
>>>...
>>>
>>>
>>>Does commenting out the LPT enumeration actually help?  There can often be 
>>>differences between debug information printed and whats really going on. 
>>>When you combine various environments the debug info can even come out in 
>>>the wrong order.
>>>
>>>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>>>I do not think this problem is universal.
>>>
>>>--
>>>Trent Jarvi
>>>tjarvi at qbang.org
>>>_______________________________________________
>>>Rxtx mailing list
>>>Rxtx at qbang.org
>>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>>
>>>
>>> 
>>>
>>>      
>>>
>>_______________________________________________
>>Rxtx mailing list
>>Rxtx at qbang.org
>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>    
>>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/bf4cca0e/attachment-0011.html

From doug at dupreeinc.com  Thu Jun  1 16:51:26 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:51:26 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6F6E.5060603@dupreeinc.com>

Jim,

I did not try your suggestion as I do not understand where I would put 
these command line parameters (it that is what they are).  It appears 
that using the properties file should do that same thing...

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>
>  
>


From doug at dupreeinc.com  Thu Jun  1 17:56:19 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 16:56:19 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
Message-ID: <447F7EA3.6050400@dupreeinc.com>

I think there is an error in the registerSpecifiedPorts() method.  When 
I have a gnu.io.rxtx.properties file in the ext directory, this function 
kills the System class  IF I call System.getProperty("os.name") before 
the call  to registerSpecifiedPorts(), it returns the os name, after the 
call, it returns null.  I have not played much with properties, except 
for reading them, so I don't really understand the code.

Doug



From doug at dupreeinc.com  Thu Jun  1 18:11:14 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 17:11:14 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F7EA3.6050400@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com>
Message-ID: <447F8222.3060402@dupreeinc.com>

Ok, I just hacked this thing up and got it to read the 
gnu.io.rxtx.properties file.

I commented out the line:
System.setProperties(p); in the method registerSpecifiedPorts() in 
RXTXCommDriver class.  I really don't understand that much about 
properties, but this call kills the System class.

I used the following in the gnu.io.rxtx.properties file:

gnu.io.rxtx.SerialPorts=COM3
gnu.io.rxtx.ParallelPorts=null

This allows the application to open very quickly without any errors.  
Whomever coded this class or somebody who understands properties should 
look at this method and make sure it is doing what they expect.

Doug




Doug Thistlethwaite wrote:

>I think there is an error in the registerSpecifiedPorts() method.  When 
>I have a gnu.io.rxtx.properties file in the ext directory, this function 
>kills the System class  IF I call System.getProperty("os.name") before 
>the call  to registerSpecifiedPorts(), it returns the os name, after the 
>call, it returns null.  I have not played much with properties, except 
>for reading them, so I don't really understand the code.
>
>Doug
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From tjarvi at qbang.org  Thu Jun  1 18:32:50 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 18:32:50 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F6EF4.7080709@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com> <447F6EF4.7080709@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011831510.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
> folder.  I created this file and added the following to the file:
>
> gnu.io.rxtx.SerialPorts=COM3
>
> and I get the following error on the console:
> CommPortIdentifier:static initialization()
> RXTXCommDriver {}
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
> RXTXCommDriver:
>   Jar version = RXTX-2.1-7
>   native lib Version = RXTX-2.1-7
> RXTXCommDriver:initialize()
> checking for system-known ports of type 1
> checking registry for ports of type 1
>
> RXTXCommDriver:addSpecifiedPorts()
> Exception in thread "main" java.lang.ExceptionInInitializerError
>   at densconnect.SerialConnection.openConnection(SerialConnection.java:136)
>   at densconnect.DensTalk.<init>(DensTalk.java:165)
>   at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
>   at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
>   at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
>   at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
> Caused by: java.lang.NullPointerException
>   at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
> CommPortIdentifier:addPortName(COM3)
> CommPortIdentifier:AddIdentifierToList()
> CommPortIdentifier:AddIdentifierToList() null
> ...
>
>

There is a solution for this bug.

http://bugzilla.qbang.org/show_bug.cgi?id=54

We have been horribly slow at getting the next round of patches in but 
they are comming.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  2 00:58:02 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 08:58:02 +0200
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F8222.3060402@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
Message-ID: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>

Hi Doug,

you wrote in an earlier message, that you would prefer an unchanged  
version. What about simply removing the RXTX parallel lib from the  
ext directory. This does not fix the bug, but it should fix your  
problem.

In general I think it is not a good idea to put the RXTX files in a  
system wide location. Putting the libs in the application folder and  
including the .jar in the application classpath (or application jar)  
is all that is required.

Regards,
Joachim

On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:

> Ok, I just hacked this thing up and got it to read the
> gnu.io.rxtx.properties file.
>
> I commented out the line:
> System.setProperties(p); in the method registerSpecifiedPorts() in
> RXTXCommDriver class.  I really don't understand that much about
> properties, but this call kills the System class.
>
> I used the following in the gnu.io.rxtx.properties file:
>
> gnu.io.rxtx.SerialPorts=COM3
> gnu.io.rxtx.ParallelPorts=null
>
> This allows the application to open very quickly without any errors.
> Whomever coded this class or somebody who understands properties  
> should
> look at this method and make sure it is doing what they expect.
>
> Doug
>
>
>
>
> Doug Thistlethwaite wrote:
>
>> I think there is an error in the registerSpecifiedPorts() method.   
>> When
>> I have a gnu.io.rxtx.properties file in the ext directory, this  
>> function
>> kills the System class  IF I call System.getProperty("os.name")  
>> before
>> the call  to registerSpecifiedPorts(), it returns the os name,  
>> after the
>> call, it returns null.  I have not played much with properties,  
>> except
>> for reading them, so I don't really understand the code.
>>
>> 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 antonio.luis at iscte.pt  Fri Jun  2 02:42:28 2006
From: antonio.luis at iscte.pt (=?ISO-8859-1?Q?Ant=F3nio_Lopes?=)
Date: Fri, 02 Jun 2006 09:42:28 +0100
Subject: [Rxtx] Exception when closing serial port
Message-ID: <447FF9F4.7060209@iscte.pt>

Hello everyone,
I've been using RXTX in a Java application in my Pocket PC.
The communication through the (bluetooth) serial port is working perfectly.

However, when I disconnect the app and close the serial port, sometimes I get 
the following error:

"1149237595000: RXTXPort:close detected bad File Descriptor"

The problem is that after this error occurs, the app is no longer able to 
connect to the serial port and I have to soft-reset the device in order to be 
able to connect to it again.

Any ideas on how to solve this issue?

Any help is appreciated.
Thanks,
regards,
-- 
Ant?nio Lopes

@contact: antonio.luis at iscte.pt
@work: ADETTI - ISCTE
@web: http://antonio.lopes.googlepages.com


From paul.klissner at sun.com  Fri Jun  2 02:44:34 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 01:44:34 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to RXTX
	again
Message-ID: <447FFA72.6040807@sun.com>

After looking into javax.comm 3.1 and what it would take to re-engineer it
to be compatible with RXTX platform libraries, I've decided, due my group's
priorities, complexity of the effort vs. benefit, and limited resources, 
to re-post
javax.comm 2.0 binaries on Sun's software download server, unsupported,
with disclaimers, as it was previously.

I don't think there will be any snags doing this from the standpoint of Sun
management or legality.  I will try to have it  posted there in the next 
week
or two, depending on how fast we can get it pushed through the process.

I'd like to think of this as a stop gap measure... ie. a compromise, 
where, at some
point in the not too distant future RXTX implements their own version of the
Java side of the API, as is normally done by javax.extension porters. 
That way
we avoid uncomfortable dependencies in the future.  And that really is 
the Java
development model.

Since RXTX already has the back-end code, porting the java code shouldn't
be a gargantuan effort at all, and RXTX will be in full control of the 
code top
to bottom. I think RXTX can do at least as good a job as the original 
coder.
Prepping 2.0 to be open sourced is more trouble than it is worth. ie. I 
don't
think the current implementation warrants it.

Ultimately, it would be nice to see someone open up a JSR and re-architect
the comm. API to overcome some of it's current design flaws (ie. be more
adaptable to modern platforms, more pluggable, better defined SPI, better
port ownership handling, etc...). A superior architecture would allow for
better collaboration in the future and better interchangeability of 
components
among projects.

Sun's 3.1 version of javax.comm, which is Sun's currently supported version,
has changes pertaining mostly to Sun platform-specific portmapping and has
some minor additional interactions with our back end code, but generally
has little bearing on RXTX. 

Paul



From joachim at buechse.de  Fri Jun  2 04:00:19 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 12:00:19 +0200
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
	RXTX again
In-Reply-To: <447FFA72.6040807@sun.com>
References: <447FFA72.6040807@sun.com>
Message-ID: <1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>

Good day Paul!

A clean architecture with loadable drivers and reusable code would be  
very beneficial for the future, I think everybody agrees. However  
this could be several years into the future. In the meantime, there  
is a real existing problem with IO support on Java. I have the strong  
feeling that most programmers want to code against one specification  
(javax.comm) and be able to replace the underlying implementation via  
a "plugin" on platforms where the SUN implementation is not  
sufficient. RXTX could be just this plugin (reusing very close to 0%  
of the javax.comm implementation but 100% of its API).

I want to propose an API addition and implementation change that will  
take less then 2 hours of manpower to implement and create a solution  
that can bridge the years until javax.comm has been based on a new  
architecture.

Looking at the javax.comm api at http://java.sun.com/products/ 
javacomm/reference/api/index.html I would like to propose the following:

The only entry point to javax.comm is CommPortIdentifier. It has 3  
static methods plus the constructor.

1) define one additional Interface

public interface CommProvider {
    CommPortIdentifier getPortIdentifier(CommPort port);
    CommPortIdentifier getPortIdentifier(String portName);
    Enumeration getPortIdentifiers ();
}

2) add one method to CommPortIdentifier

   public static setCustomCommProvider (CommProvider);

3) change the three static methods of CommPortIdentifier to dispatch  
to the CommProvider if it is set

4) change the constructor of CommPortIdentifier to

   public CommPortIdentifier(...) {
      if (isProviderSet && this.getClass() ==  
javax.comm.CommPortIdentifier) {
          throw new RuntimeException("illegal creation of  
CommPortIndentifier, custom CommProvider is in use");
      }

5) (this is optional, but would be very nice) automatically set a  
custom CommProvider if it is found on the classpath or defined via a  
system property.


The above 1) - 4) can be implemented in less than 1hour. 5) may take  
another hour. I agree that this is not the most elegant design, but  
it would solve a lot of problems with very little effort. It would  
certainly allow RXTX to move forward. If the javax.comm API needs to  
be redesigned completely this addition will not hurt, as people will  
move to the new API anyway and javax.comm 3.0 was so far never  
included in the main distribution.

Best regards,
Joachim

On 02.06.2006, at 10:44, Paul Klissner wrote:

> After looking into javax.comm 3.1 and what it would take to re- 
> engineer it
> to be compatible with RXTX platform libraries, I've decided, due my  
> group's
> priorities, complexity of the effort vs. benefit, and limited  
> resources,
> to re-post
> javax.comm 2.0 binaries on Sun's software download server,  
> unsupported,
> with disclaimers, as it was previously.
>
> I don't think there will be any snags doing this from the  
> standpoint of Sun
> management or legality.  I will try to have it  posted there in the  
> next
> week
> or two, depending on how fast we can get it pushed through the  
> process.
>
> I'd like to think of this as a stop gap measure... ie. a compromise,
> where, at some
> point in the not too distant future RXTX implements their own  
> version of the
> Java side of the API, as is normally done by javax.extension porters.
> That way
> we avoid uncomfortable dependencies in the future.  And that really is
> the Java
> development model.
>
> Since RXTX already has the back-end code, porting the java code  
> shouldn't
> be a gargantuan effort at all, and RXTX will be in full control of the
> code top
> to bottom. I think RXTX can do at least as good a job as the original
> coder.
> Prepping 2.0 to be open sourced is more trouble than it is worth.  
> ie. I
> don't
> think the current implementation warrants it.
>
> Ultimately, it would be nice to see someone open up a JSR and re- 
> architect
> the comm. API to overcome some of it's current design flaws (ie. be  
> more
> adaptable to modern platforms, more pluggable, better defined SPI,  
> better
> port ownership handling, etc...). A superior architecture would  
> allow for
> better collaboration in the future and better interchangeability of
> components
> among projects.
>
> Sun's 3.1 version of javax.comm, which is Sun's currently supported  
> version,
> has changes pertaining mostly to Sun platform-specific portmapping  
> and has
> some minor additional interactions with our back end code, but  
> generally
> has little bearing on RXTX.
>
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Fri Jun  2 09:10:13 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Fri, 2 Jun 2006 09:10:13 -0600 (MDT)
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <447FFA72.6040807@sun.com>
References: <447FFA72.6040807@sun.com>
Message-ID: <Pine.LNX.4.61.0606020906400.15971@www>

On Fri, 2 Jun 2006, Paul Klissner wrote:

> After looking into javax.comm 3.1 and what it would take to re-engineer it
> to be compatible with RXTX platform libraries, I've decided, due my group's
> priorities, complexity of the effort vs. benefit, and limited resources,
> to re-post
> javax.comm 2.0 binaries on Sun's software download server, unsupported,
> with disclaimers, as it was previously.
>

Hi Paul

To address users' immediate needs, we can release rxtx 2.0-7 (final) to 
match the 2.0 binaries from Sun when they are offered for download.

We can discuss potential long term solutions after that.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Fri Jun  2 10:20:09 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 02 Jun 2006 09:20:09 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
	<9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
Message-ID: <44806539.8080902@dupreeinc.com>

Thanks for the suggestion, I will give it a try.

Doug

Joachim Buechse wrote:

>Hi Doug,
>
>you wrote in an earlier message, that you would prefer an unchanged  
>version. What about simply removing the RXTX parallel lib from the  
>ext directory. This does not fix the bug, but it should fix your  
>problem.
>
>In general I think it is not a good idea to put the RXTX files in a  
>system wide location. Putting the libs in the application folder and  
>including the .jar in the application classpath (or application jar)  
>is all that is required.
>
>Regards,
>Joachim
>
>On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:
>
>  
>
>>Ok, I just hacked this thing up and got it to read the
>>gnu.io.rxtx.properties file.
>>
>>I commented out the line:
>>System.setProperties(p); in the method registerSpecifiedPorts() in
>>RXTXCommDriver class.  I really don't understand that much about
>>properties, but this call kills the System class.
>>
>>I used the following in the gnu.io.rxtx.properties file:
>>
>>gnu.io.rxtx.SerialPorts=COM3
>>gnu.io.rxtx.ParallelPorts=null
>>
>>This allows the application to open very quickly without any errors.
>>Whomever coded this class or somebody who understands properties  
>>should
>>look at this method and make sure it is doing what they expect.
>>
>>Doug
>>
>>
>>
>>
>>Doug Thistlethwaite wrote:
>>
>>    
>>
>>>I think there is an error in the registerSpecifiedPorts() method.   
>>>When
>>>I have a gnu.io.rxtx.properties file in the ext directory, this  
>>>function
>>>kills the System class  IF I call System.getProperty("os.name")  
>>>before
>>>the call  to registerSpecifiedPorts(), it returns the os name,  
>>>after the
>>>call, it returns null.  I have not played much with properties,  
>>>except
>>>for reading them, so I don't really understand the code.
>>>
>>>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
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060602/c8892a46/attachment-0011.html

From paul.klissner at sun.com  Fri Jun  2 12:09:26 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 11:09:26 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
Message-ID: <44807ED6.8000903@sun.com>

Joachim Buechse wrote:
> Good day Paul!
>
> A clean architecture with loadable drivers and reusable code would be  
> very beneficial for the future, I think everybody agrees. However  
> this could be several years into the future. In the meantime, there  
> is a real existing problem with IO support on Java. I have the strong  
> feeling that most programmers want to code against one specification  
> (javax.comm) and be able to replace the underlying implementation via  
> a "plugin" on platforms where the SUN implementation is not  
> sufficient. RXTX could be just this plugin (reusing very close to 0%  
> of the javax.comm implementation but 100% of its API).
>
> I want to propose an API addition and implementation change that will  
> take less then 2 hours of manpower to implement and create a solution  
> that can bridge the years until javax.comm has been based on a new  
> architecture.
>
> Looking at the javax.comm api at http://java.sun.com/products/ 
> javacomm/reference/api/index.html I would like to propose the following:
>
> The only entry point to javax.comm is CommPortIdentifier. It has 3  
> static methods plus the constructor.
>
> 1) define one additional Interface
>
> public interface CommProvider {
>     CommPortIdentifier getPortIdentifier(CommPort port);
>     CommPortIdentifier getPortIdentifier(String portName);
>     Enumeration getPortIdentifiers ();
> }
>
> 2) add one method to CommPortIdentifier
>
>    public static setCustomCommProvider (CommProvider);
>
> 3) change the three static methods of CommPortIdentifier to dispatch  
> to the CommProvider if it is set
>
> 4) change the constructor of CommPortIdentifier to
>
>    public CommPortIdentifier(...) {
>       if (isProviderSet && this.getClass() ==  
> javax.comm.CommPortIdentifier) {
>           throw new RuntimeException("illegal creation of  
> CommPortIndentifier, custom CommProvider is in use");
>       }
>
> 5) (this is optional, but would be very nice) automatically set a  
> custom CommProvider if it is found on the classpath or defined via a  
> system property.
>
>
> The above 1) - 4) can be implemented in less than 1hour. 5) may take  
> another hour. I agree that this is not the most elegant design, but  
> it would solve a lot of problems with very little effort. It would  
> certainly allow RXTX to move forward. If the javax.comm API needs to  
> be redesigned completely this addition will not hurt, as people will  
> move to the new API anyway and javax.comm 3.0 was so far never  
> included in the main distribution.
>
> Best regards,
> Joachi
I'm afraid modifying the interface classes isn't my call.  There was 
actually
a TCK written and one of the tests was to ensure that the interface classes
match the spec.  Thus my hands have already been tied since this project
was essentially grandfathered into the JCP.

That's why we need to open a new JSR and find someone who wants
to be the spec lead, and go in with a new reference implementation.
I'm not sure why it would have to take years, since this isn't bleeding edge
technology and there are only so many things that can be done with it,
and we already have practical experience about many functional aspects
that we could cite precedence on.

As it becomes clear that the specification is being accepted completely
or by-and-large by the community, nothing would stop people from
starting adapting to the new API (using the reference implementation or
porting it) and using it in their projects prior to it's final community and
JCP approval, since approval is required only to make it official and
get the "100% pure java" certification for platform ports.

You have one idea already.  Why don't you implement it, solicit some
design feedback from Sun and the RXTX, and create a functional
implementation that addresses the needs of the community, then
we can document it and open a JSR.  That's it.  It should march through
the approval stages reasonably quickly I would imagine, and meantime
RXTX could start using it.

Paul




From doug at dupreeinc.com  Fri Jun  2 12:45:01 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 02 Jun 2006 11:45:01 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
	<9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
Message-ID: <4480872D.6000605@dupreeinc.com>

Joachim,

Thank you for the suggestion.  I restored the jar file to the one I 
downloaded, moved the dll files into the project directory, and added 
the jar to the classpath.  The SerialDemo program that was included with 
the Sun commapi started in 12 seconds instead of the 58 seconds when the 
parallel dll is present.  I did get the startup time to about a second 
by modifying the java code and adding the properties file but this is 
probably not a good idea.

Doug

Joachim Buechse wrote:

>Hi Doug,
>
>you wrote in an earlier message, that you would prefer an unchanged  
>version. What about simply removing the RXTX parallel lib from the  
>ext directory. This does not fix the bug, but it should fix your  
>problem.
>
>In general I think it is not a good idea to put the RXTX files in a  
>system wide location. Putting the libs in the application folder and  
>including the .jar in the application classpath (or application jar)  
>is all that is required.
>
>Regards,
>Joachim
>
>On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:
>
>  
>
>>Ok, I just hacked this thing up and got it to read the
>>gnu.io.rxtx.properties file.
>>
>>I commented out the line:
>>System.setProperties(p); in the method registerSpecifiedPorts() in
>>RXTXCommDriver class.  I really don't understand that much about
>>properties, but this call kills the System class.
>>
>>I used the following in the gnu.io.rxtx.properties file:
>>
>>gnu.io.rxtx.SerialPorts=COM3
>>gnu.io.rxtx.ParallelPorts=null
>>
>>This allows the application to open very quickly without any errors.
>>Whomever coded this class or somebody who understands properties  
>>should
>>look at this method and make sure it is doing what they expect.
>>
>>Doug
>>
>>
>>
>>
>>Doug Thistlethwaite wrote:
>>
>>    
>>
>>>I think there is an error in the registerSpecifiedPorts() method.   
>>>When
>>>I have a gnu.io.rxtx.properties file in the ext directory, this  
>>>function
>>>kills the System class  IF I call System.getProperty("os.name")  
>>>before
>>>the call  to registerSpecifiedPorts(), it returns the os name,  
>>>after the
>>>call, it returns null.  I have not played much with properties,  
>>>except
>>>for reading them, so I don't really understand the code.
>>>
>>>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
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060602/3c0e420f/attachment-0011.html

From joachim at buechse.de  Fri Jun  2 13:46:36 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 21:46:36 +0200
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
	RXTX again
In-Reply-To: <44807ED6.8000903@sun.com>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
	<44807ED6.8000903@sun.com>
Message-ID: <6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>

Hello Paul,

of course, the basic change I suggested could be done "hidden".  The  
CommProvider interface could live somewhere in sun.xyz.*
The setCustomCommProvider method would not be in CommPortIdentifier  
but also somewhere in sun.xyz.* This would be an unofficial feature,  
the official interface stays exactly the same. However RXTX (and  
others) could access the hidden interface.

Don't get me wrong, I don't want to harass you into making changes  
you don't like (which probably wouldn't work anyway;-). But I'm a  
long time Java programmer and seeing the state of cross platform  
serial support for Java makes me feel really sad. In fact, when I  
started to look into Java serial port programming some months ago I  
was very surprised that javax.comm never made it into the JDK.

I'm sorry that I did not contribute my feedback to the JSR for  
javax.comm 3.0. However at the time I didn't do serial port  
programming in Java. I agree that a new JSR should be opened - I'm  
not an expert on JSRs or the JCP process, but from looking quickly  
over the progress of some JSRs I would be very surprised if we can  
have a new version in less then a year. In the meanwhile some people  
will start using javax.comm 3.0 (which can not be supported by RXTX),  
some will use javax.comm 2.0 (which means the 2.0.7 release of RXTX  
still needs to be maintained). This may get even worse if eg Apple  
decides to port and include javax.comm 3.0 at which point it may get  
very tricky to write a cross platform Java application.

All of this simply means, that we are loosing a lot of man-power that  
could otherwise be invested in building a clean solution and/or to  
add features that are becoming more and more important (USB events...).

In the automation / machine control universe Java makes a lot of  
sense. Right now many people are migrating to Linux or from  
propietary systems (even DOS) to Windows. Writing the control/ 
configuration applications in Java is the kings way to unify the code  
base.

Best regards,
Joachim


On 02.06.2006, at 20:09, Paul Klissner wrote:

> Joachim Buechse wrote:
>> Good day Paul!
>>
>> A clean architecture with loadable drivers and reusable code would be
>> very beneficial for the future, I think everybody agrees. However
>> this could be several years into the future. In the meantime, there
>> is a real existing problem with IO support on Java. I have the strong
>> feeling that most programmers want to code against one specification
>> (javax.comm) and be able to replace the underlying implementation via
>> a "plugin" on platforms where the SUN implementation is not
>> sufficient. RXTX could be just this plugin (reusing very close to 0%
>> of the javax.comm implementation but 100% of its API).
>>
>> I want to propose an API addition and implementation change that will
>> take less then 2 hours of manpower to implement and create a solution
>> that can bridge the years until javax.comm has been based on a new
>> architecture.
>>
>> Looking at the javax.comm api at http://java.sun.com/products/
>> javacomm/reference/api/index.html I would like to propose the  
>> following:
>>
>> The only entry point to javax.comm is CommPortIdentifier. It has 3
>> static methods plus the constructor.
>>
>> 1) define one additional Interface
>>
>> public interface CommProvider {
>>     CommPortIdentifier getPortIdentifier(CommPort port);
>>     CommPortIdentifier getPortIdentifier(String portName);
>>     Enumeration getPortIdentifiers ();
>> }
>>
>> 2) add one method to CommPortIdentifier
>>
>>    public static setCustomCommProvider (CommProvider);
>>
>> 3) change the three static methods of CommPortIdentifier to dispatch
>> to the CommProvider if it is set
>>
>> 4) change the constructor of CommPortIdentifier to
>>
>>    public CommPortIdentifier(...) {
>>       if (isProviderSet && this.getClass() ==
>> javax.comm.CommPortIdentifier) {
>>           throw new RuntimeException("illegal creation of
>> CommPortIndentifier, custom CommProvider is in use");
>>       }
>>
>> 5) (this is optional, but would be very nice) automatically set a
>> custom CommProvider if it is found on the classpath or defined via a
>> system property.
>>
>>
>> The above 1) - 4) can be implemented in less than 1hour. 5) may take
>> another hour. I agree that this is not the most elegant design, but
>> it would solve a lot of problems with very little effort. It would
>> certainly allow RXTX to move forward. If the javax.comm API needs to
>> be redesigned completely this addition will not hurt, as people will
>> move to the new API anyway and javax.comm 3.0 was so far never
>> included in the main distribution.
>>
>> Best regards,
>> Joachi
> I'm afraid modifying the interface classes isn't my call.  There was
> actually
> a TCK written and one of the tests was to ensure that the interface  
> classes
> match the spec.  Thus my hands have already been tied since this  
> project
> was essentially grandfathered into the JCP.
>
> That's why we need to open a new JSR and find someone who wants
> to be the spec lead, and go in with a new reference implementation.
> I'm not sure why it would have to take years, since this isn't  
> bleeding edge
> technology and there are only so many things that can be done with it,
> and we already have practical experience about many functional aspects
> that we could cite precedence on.
>
> As it becomes clear that the specification is being accepted  
> completely
> or by-and-large by the community, nothing would stop people from
> starting adapting to the new API (using the reference  
> implementation or
> porting it) and using it in their projects prior to it's final  
> community and
> JCP approval, since approval is required only to make it official and
> get the "100% pure java" certification for platform ports.
>
> You have one idea already.  Why don't you implement it, solicit some
> design feedback from Sun and the RXTX, and create a functional
> implementation that addresses the needs of the community, then
> we can document it and open a JSR.  That's it.  It should march  
> through
> the approval stages reasonably quickly I would imagine, and meantime
> RXTX could start using it.
>
> Paul
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From paul.klissner at sun.com  Fri Jun  2 14:38:49 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 13:38:49 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
	<44807ED6.8000903@sun.com>
	<6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>
Message-ID: <4480A1D9.5060106@sun.com>

Joachim Buechse wrote:
> Hello Paul,
>
> of course, the basic change I suggested could be done "hidden".  The  
> CommProvider interface could live somewhere in sun.xyz.*
> The setCustomCommProvider method would not be in CommPortIdentifier  
> but also somewhere in sun.xyz.* This would be an unofficial feature,  
> the official interface stays exactly the same. However RXTX (and  
> others) could access the hidden interface.
>
> Don't get me wrong, I don't want to harass you into making changes  
> you don't like (which probably wouldn't work anyway;-). But I'm a  
> long time Java programmer and seeing the state of cross platform  
> serial support for Java makes me feel really sad. In fact, when I  
> started to look into Java serial port programming some months ago I  
> was very surprised that javax.comm never made it into the JDK.
>
> I'm sorry that I did not contribute my feedback to the JSR for  
> javax.comm 3.0. 
There was no JSR for 3.0, because we didn't have the resources to make 
the commitment.
Yet Sun needed to add support for platform-dependent port name mapping, 
which had to
be done 'under the hood', since the API isn't designed to handle that in 
a pluggable way.
But these quick fixes aren't the right approach, they just kick the dog 
down the road,
setting bad precedent, inviting confusion and more intractable problems 
(such as the
one plaguing us now).

My changes could have been layered better, it was a trade off between 
achieving an
ideal architecture, trying to find internal reviewers, and meet the 
needs of big customers
in a timely way.  Thus my namespace changes collided with RXTX's 
dependencies.
I was unaware of Jagane's rogue agreement made with the RXTX community 7 
years ago,
before Jagane left Sun.  I think this was a wag-the-dog situation.

Now it is time to do it right, and I don't think it is going to be as 
much trouble as people
some people fear. If RXTX wants to sponsor the JSR and seed a new spec, 
Sun can join
the Expert Group.  And we'd be largely in agreement, since we're not 
talking about
humongous changes, and looking for mutually beneficial changes. The core 
API is already
largely proved and tested.
> However at the time I didn't do serial port  
> programming in Java. I agree that a new JSR should be opened - I'm  
> not an expert on JSRs or the JCP process, but from looking quickly  
> over the progress of some JSRs I would be very surprised if we can  
> have a new version in less then a year. 
*Approved*  But that doesn't mean the spec couldn't be 99.9% stable 
before that.  Once
the delta rate declines and changes approach nil, people could start 
adapting to the API in
advance of formal approval.   It isn't going to be drawn out like 
javax.usb, which was new
technology, a very complex API, and involved precedent setting corporate 
disputes and
policy issues to resolve.

> In the meanwhile some people  
> will start using javax.comm 3.0 (which can not be supported by RXTX),  
> some will use javax.comm 2.0 (which means the 2.0.7 release of RXTX  
> still needs to be maintained). This may get even worse if eg Apple  
> decides to port and include javax.comm 3.0 at which point it may get  
> very tricky to write a cross platform Java application.
>   
The interfaces haven't changed since 1.0.  If we open a JSR ,we can 
contact Apple and
allow them to be on the E.G., if they want.  That might make the JSR a 
bit more drawn out,
but then we'd arrive ultimately arrive at a best-of-all-worlds API that 
most people would
accept, perhaps forever, and arrive at a respectable set of compromises.

-Paul

> All of this simply means, that we are loosing a lot of man-power that  
> could otherwise be invested in building a clean solution and/or to  
> add features that are becoming more and more important (USB events...).
>
> In the automation / machine control universe Java makes a lot of  
> sense. Right now many people are migrating to Linux or from  
> propietary systems (even DOS) to Windows. Writing the control/ 
> configuration applications in Java is the kings way to unify the code  
> base.
>
> Best regards,
> Joachim
>
>
> On 02.06.2006, at 20:09, Paul Klissner wrote:
>
>   
>> Joachim Buechse wrote:
>>     
>>> Good day Paul!
>>>
>>> A clean architecture with loadable drivers and reusable code would be
>>> very beneficial for the future, I think everybody agrees. However
>>> this could be several years into the future. In the meantime, there
>>> is a real existing problem with IO support on Java. I have the strong
>>> feeling that most programmers want to code against one specification
>>> (javax.comm) and be able to replace the underlying implementation via
>>> a "plugin" on platforms where the SUN implementation is not
>>> sufficient. RXTX could be just this plugin (reusing very close to 0%
>>> of the javax.comm implementation but 100% of its API).
>>>
>>> I want to propose an API addition and implementation change that will
>>> take less then 2 hours of manpower to implement and create a solution
>>> that can bridge the years until javax.comm has been based on a new
>>> architecture.
>>>
>>> Looking at the javax.comm api at http://java.sun.com/products/
>>> javacomm/reference/api/index.html I would like to propose the  
>>> following:
>>>
>>> The only entry point to javax.comm is CommPortIdentifier. It has 3
>>> static methods plus the constructor.
>>>
>>> 1) define one additional Interface
>>>
>>> public interface CommProvider {
>>>     CommPortIdentifier getPortIdentifier(CommPort port);
>>>     CommPortIdentifier getPortIdentifier(String portName);
>>>     Enumeration getPortIdentifiers ();
>>> }
>>>
>>> 2) add one method to CommPortIdentifier
>>>
>>>    public static setCustomCommProvider (CommProvider);
>>>
>>> 3) change the three static methods of CommPortIdentifier to dispatch
>>> to the CommProvider if it is set
>>>
>>> 4) change the constructor of CommPortIdentifier to
>>>
>>>    public CommPortIdentifier(...) {
>>>       if (isProviderSet && this.getClass() ==
>>> javax.comm.CommPortIdentifier) {
>>>           throw new RuntimeException("illegal creation of
>>> CommPortIndentifier, custom CommProvider is in use");
>>>       }
>>>
>>> 5) (this is optional, but would be very nice) automatically set a
>>> custom CommProvider if it is found on the classpath or defined via a
>>> system property.
>>>
>>>
>>> The above 1) - 4) can be implemented in less than 1hour. 5) may take
>>> another hour. I agree that this is not the most elegant design, but
>>> it would solve a lot of problems with very little effort. It would
>>> certainly allow RXTX to move forward. If the javax.comm API needs to
>>> be redesigned completely this addition will not hurt, as people will
>>> move to the new API anyway and javax.comm 3.0 was so far never
>>> included in the main distribution.
>>>
>>> Best regards,
>>> Joachi
>>>       
>> I'm afraid modifying the interface classes isn't my call.  There was
>> actually
>> a TCK written and one of the tests was to ensure that the interface  
>> classes
>> match the spec.  Thus my hands have already been tied since this  
>> project
>> was essentially grandfathered into the JCP.
>>
>> That's why we need to open a new JSR and find someone who wants
>> to be the spec lead, and go in with a new reference implementation.
>> I'm not sure why it would have to take years, since this isn't  
>> bleeding edge
>> technology and there are only so many things that can be done with it,
>> and we already have practical experience about many functional aspects
>> that we could cite precedence on.
>>
>> As it becomes clear that the specification is being accepted  
>> completely
>> or by-and-large by the community, nothing would stop people from
>> starting adapting to the new API (using the reference  
>> implementation or
>> porting it) and using it in their projects prior to it's final  
>> community and
>> JCP approval, since approval is required only to make it official and
>> get the "100% pure java" certification for platform ports.
>>
>> You have one idea already.  Why don't you implement it, solicit some
>> design feedback from Sun and the RXTX, and create a functional
>> implementation that addresses the needs of the community, then
>> we can document it and open a JSR.  That's it.  It should march  
>> through
>> the approval stages reasonably quickly I would imagine, and meantime
>> RXTX could start using it.
>>
>> Paul
>>
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at 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  Sat Jun  3 18:15:24 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 18:15:24 -0600 (MDT)
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
Message-ID: <Pine.LNX.4.61.0606031715100.10890@www>


The attached patch allows baud rates of 14400, 28800, 128000 and 256000.

That was my goal.

[import standard disclaimer]

But I took some time to look a little further.  I got custom baud rates 
working enough that someone (perhaps me) can properly fix them in the 
future.  Proof of concept.

As an undocumented bonus, you can toss random baudrates (say 1953), at the 
API and it will set it to something close to that on windows and linux. 
Solaris should say the baud rate is not supported but I have not tested it 
yet.  Mac OS X behavior is unknown at this point.  Just dont expect 
correct behavior at ~8192-9009 baudrates or baudrates less than 20 on 
windows; these baud rates overlap with defines in win32termios.h.  I 
conveniently closed my eyes there.  Try another value close.  On Linux, a 
baud base and divisor are guestimated and set.  On windows, we wave pixie 
dust over the kernel driver and hope.  Do not expect pixie dust and 
guestimates to be the same on windows and linux.  They may well round to 
different values in yet to be tested ways.  There are only so many 
divisors.  If it isn't working, try a little higher or lower.

In the example of 1953 for instance, there is no divisor for commodity 
hardware that comes to that baudrate.  We just come close on one side or 
the other.  If tools tell you they got 1953 exactly, the tools may be 
questionable and just reading values not directly related to the actual 
hardware settings.

These fixes have been tested on Linux and Windows while using an 
oscilloscope to confirm they change relative to known baudrates at 9600, 
14400*, 19200, 28800* (and 1800, 1953** and 2400).

* = previously unsupported.
** = still not supported but probably works from what I saw.

There could be future discussion in this area.  For now this is working 
for almost all unusual baud rate demands.  Cleaning up the custom baud 
rate should be easier with a working starting point.  Baud bases other 
than 128000 have not been characterized.  Yes.. this overlapps with two of 
the baud rates enabled.

Feedback and ideas are welcome.

--
Trent Jarvi
tjarvi at qbang.org
-------------- next part --------------
Index: SerialImp.c
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v
retrieving revision 1.46.2.187
diff -u -r1.46.2.187 SerialImp.c
--- SerialImp.c	29 Jan 2006 22:19:04 -0000	1.46.2.187
+++ SerialImp.c	3 Jun 2006 23:12:40 -0000
@@ -793,6 +793,19 @@
 		result &= ~TIOCM_DTR;
 		ioctl( fd, TIOCMSET, &result );
 	}
+	/*
+	   B38400 is a special case in Linux for custom baud rates.
+
+	   We just treat this as a custom speed for now.  If you take this ifdef
+	   out and select baud rates 38400 then 28800 then 38400, you will get
+	   a final baud rate of 28800 because you did not update the divisor.
+
+	   See the next ifdef below for the divisor.
+	*/
+#if defined(TIOCGSERIAL)
+	if ( cspeed == B38400 )
+		cspeed = 38400;
+#endif /* TIOCGSERIAL */
 	if(     cfsetispeed( &ttyset, cspeed ) < 0 ||
 		cfsetospeed( &ttyset, cspeed ) < 0 )
 	{
@@ -814,6 +827,7 @@
 		*/
 
 #if defined(TIOCGSERIAL)
+		ioctl( fd, TIOCGSERIAL, &sstruct );
 		sstruct.custom_divisor = ( sstruct.baud_base/cspeed );
 		cspeed = B38400;
 #endif /* TIOCGSERIAL */
@@ -827,7 +841,7 @@
 #if defined(TIOCSSERIAL)
 		/*  It is assumed Win32 does this for us */
 		if (	sstruct.baud_base < 1 ||
-			ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
+		ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
 		{
 			return( 1 );
 		}
Index: termios.c
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v
retrieving revision 1.9.2.56
diff -u -r1.9.2.56 termios.c
--- termios.c	16 Jan 2006 02:50:32 -0000	1.9.2.56
+++ termios.c	3 Jun 2006 23:12:40 -0000
@@ -323,8 +323,8 @@
 		case CBR_3500000:	return( B3500000 );
 		case CBR_4000000:	return( B4000000 );
 		default:
-			set_errno(EINVAL );
-			return -1;
+			/* assume custom baudrate */
+			return( Baud );
 	}
 }
 
@@ -361,12 +361,13 @@
 		case B9600:	ret = CBR_9600;		break;
 		case B14400:	ret = CBR_14400;	break;
 		case B19200:	ret = CBR_19200;	break;
+		case B28800:	ret = CBR_28800;	break;
 		case B38400:	ret = CBR_38400;	break;
 		case B57600:	ret = CBR_57600;	break;
 		case B115200:	ret = CBR_115200;	break;
 		case B128000:	ret = CBR_128000;	break;
-		case B256000: 	ret = CBR_256000;	break;
 		case B230400:	ret = CBR_230400;	break;
+		case B256000: 	ret = CBR_256000;	break;
 		case B460800:	ret = CBR_460800;	break;
 		case B500000:	ret = CBR_500000;	break;
 		case B576000:	ret = CBR_576000;	break;
@@ -381,10 +382,8 @@
 		case B4000000:	ret = CBR_4000000;	break;
 	
 		default:
-			fprintf( stderr, "B_to_CBR: invalid baudrate: %#o\n",
-				Baud );
-			set_errno( EINVAL );
-			return -1;
+			/* assume custom baudrate */
+			return Baud;
 	}
 	LEAVE( "B_to_CBR" );
 	return ret;
@@ -708,12 +707,9 @@
 	ENTER( "init_serial_struct" );
 
 	/*
-	FIXME
-
-	This needs to use inb() to read the actual baud_base
-	and divisor from the UART registers.  Question is how
-	far do we take this?
-
+	use of custom_divisor and baud_base requires access to
+	kernel space.  The kernel does try its best if you just
+	toss a baud rate at it though.
 	*/
 
 	sstruct->custom_divisor = 0;
@@ -1678,16 +1674,17 @@
 {
 	char message[80];
 	ENTER( "cfsetospeed" );
+	/* clear baudrate */
+	s_termios->c_cflag &= ~CBAUD;
 	if ( speed & ~CBAUD )
 	{
 		sprintf( message, "cfsetospeed: not speed: %#o\n", speed );
 		report( message );
-		return 0;
+		/* continue assuming its a custom baudrate */
+		s_termios->c_cflag |= B38400;  /* use 38400 during custom */
+		s_termios->c_cflag |= CBAUDEX; /* use CBAUDEX for custom */
 	}
-	s_termios->c_ispeed = s_termios->c_ospeed = speed;
-	/* clear baudrate */
-	s_termios->c_cflag &= ~CBAUD;
-	if( speed )
+	else if( speed )
 	{
 		s_termios->c_cflag |= speed;
 	}
@@ -1696,6 +1693,7 @@
 		/* PC blows up with speed 0 handled in Java */
 		s_termios->c_cflag |= B9600;
 	}
+	s_termios->c_ispeed = s_termios->c_ospeed = speed;
 	LEAVE( "cfsetospeed" );
 	return 1;
 }
@@ -1767,25 +1765,6 @@
 }
 
 /*----------------------------------------------------------
-serial_struct_to_DCB()
-
-   accept:      
-   perform:     
-   return:      
-   exceptions:  
-   win32api:     None
-   comments:    
-----------------------------------------------------------*/
-int serial_struct_to_DCB( struct serial_struct *sstruct, DCB *dcb )
-{
-	/* 5 Baud rate fix
-	sstruct.baud_base
-	sstruct.custom_divisor = ( sstruct.baud_base/cspeed );
-	*/
-	return(0);
-}
-
-/*----------------------------------------------------------
 termios_to_DCB()
 
    accept:      
@@ -1798,7 +1777,8 @@
 int termios_to_DCB( struct termios *s_termios, DCB *dcb )
 {
 	ENTER( "termios_to_DCB" );
-	s_termios->c_ispeed = s_termios->c_ospeed = s_termios->c_cflag & CBAUD;
+	if ( !(s_termios->c_cflag & CBAUDEX) )
+		s_termios->c_ispeed = s_termios->c_ospeed = s_termios->c_cflag & CBAUD;
 	dcb->BaudRate        = B_to_CBR( s_termios->c_ispeed );
 	dcb->ByteSize = termios_to_bytesize( s_termios->c_cflag );
 
@@ -2863,11 +2843,6 @@
 			GetCommState( index->hComm, dcb );
 
 			index->sstruct = va_arg( ap, struct serial_struct * );
-			if ( serial_struct_to_DCB( index->sstruct, dcb ) < 0 )
-			{
-				va_end( ap );
-				return -1;
-			}
 
 			report( "TIOCSSERIAL\n" );
 			free(dcb);
Index: win32termios.h
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v
retrieving revision 1.5.2.28
diff -u -r1.5.2.28 win32termios.h
--- win32termios.h	30 Jun 2005 20:23:26 -0000	1.5.2.28
+++ win32termios.h	3 Jun 2006 23:12:40 -0000
@@ -279,7 +279,7 @@
 #define XTABS	01000000 /* Hmm.. Linux/i386 considers this part of TABDLY.. */
 
 /* c_cflag bit meaning */
-# define CBAUD	0010017
+#define  CBAUD  0030017
 #define  B0	0000000		/* hang up */
 #define  B50	0000001
 #define  B75	0000002
@@ -312,13 +312,16 @@
 #define  B3500000 0010016
 #define  B4000000 0010017
 
-/* glue for unsupported linux speeds see also SerialImp.h */
-/* hosed */
-
-#define B14400		1010001
-#define B28800		1010002
-#define B128000		1010003
-#define B256000		1010004
+/*
+	glue for unsupported linux speeds see also SerialImp.h 
+	custom baud rates around 8192-9000 will not work because
+	of these.
+*/
+
+#define B14400		0020001
+#define B28800		0020002
+#define B128000		0020003
+#define B256000		0020004
 
 #define EXTA B19200
 #define EXTB B38400
@@ -356,8 +359,10 @@
 
 /* glue for unsupported windows speeds */
 
-#define CBR_230400	230400
 #define CBR_28800	28800
+#define CBR_128000	128000
+#define CBR_230400	230400
+#define CBR_256000	256000
 #define CBR_460800	460800
 #define CBR_500000	500000
 #define CBR_576000	576000

From impakt01 at optusnet.com.au  Sat Jun  3 18:30:37 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 10:30:37 +1000
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
In-Reply-To: <Pine.LNX.4.61.0606031715100.10890@www>
Message-ID: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>

Hi Trent,
I'd love to try the patch but I can't get the latest build compiling, only
pre16. 

Can you attach the rxtxSerial.dll file with this patch?

Also, I hardcoded 1953 in a couple more places last night on pre16 and it
managed to open the port at the right speed, but stopped receiving anything
after 100-150 bytes, even though more data was getting sent to the port.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 10:15 AM
To: rxtx at qbang.org
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.


The attached patch allows baud rates of 14400, 28800, 128000 and 256000.

That was my goal.

[import standard disclaimer]

But I took some time to look a little further.  I got custom baud rates 
working enough that someone (perhaps me) can properly fix them in the 
future.  Proof of concept.

As an undocumented bonus, you can toss random baudrates (say 1953), at the 
API and it will set it to something close to that on windows and linux. 
Solaris should say the baud rate is not supported but I have not tested it 
yet.  Mac OS X behavior is unknown at this point.  Just dont expect 
correct behavior at ~8192-9009 baudrates or baudrates less than 20 on 
windows; these baud rates overlap with defines in win32termios.h.  I 
conveniently closed my eyes there.  Try another value close.  On Linux, a 
baud base and divisor are guestimated and set.  On windows, we wave pixie 
dust over the kernel driver and hope.  Do not expect pixie dust and 
guestimates to be the same on windows and linux.  They may well round to 
different values in yet to be tested ways.  There are only so many 
divisors.  If it isn't working, try a little higher or lower.

In the example of 1953 for instance, there is no divisor for commodity 
hardware that comes to that baudrate.  We just come close on one side or 
the other.  If tools tell you they got 1953 exactly, the tools may be 
questionable and just reading values not directly related to the actual 
hardware settings.

These fixes have been tested on Linux and Windows while using an 
oscilloscope to confirm they change relative to known baudrates at 9600, 
14400*, 19200, 28800* (and 1800, 1953** and 2400).

* = previously unsupported.
** = still not supported but probably works from what I saw.

There could be future discussion in this area.  For now this is working 
for almost all unusual baud rate demands.  Cleaning up the custom baud 
rate should be easier with a working starting point.  Baud bases other 
than 128000 have not been characterized.  Yes.. this overlapps with two of 
the baud rates enabled.

Feedback and ideas are welcome.

--
Trent Jarvi
tjarvi at qbang.org



From tjarvi at qbang.org  Sat Jun  3 19:05:11 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 19:05:11 -0600 (MDT)
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
In-Reply-To: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>
References: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606031840400.10890@www>

On Sun, 4 Jun 2006, Daren wrote:

> Hi Trent,
> I'd love to try the patch but I can't get the latest build compiling, only
> pre16.
>
> Can you attach the rxtxSerial.dll file with this patch?
>
> Also, I hardcoded 1953 in a couple more places last night on pre16 and it
> managed to open the port at the right speed, but stopped receiving anything
> after 100-150 bytes, even though more data was getting sent to the port.
>


ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing

I dont think they will hang.  But I was just testing via loopback/break 
out box/scope.

I'll be putting about 10 patches and another set of binaries in that 
directory shortly.  For now the binaries should just have the baud_rate 
fix.

I'll announce all the patches at once.  but wont be releasing 2.1-8 right 
away.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Sat Jun  3 21:00:01 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 21:00:01 -0600 (MDT)
Subject: [Rxtx] CVS for 2.1 should have everything
Message-ID: <Pine.LNX.4.61.0606032056190.10890@www>


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org


From impakt01 at optusnet.com.au  Sat Jun  3 21:08:14 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 13:08:14 +1000
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <Pine.LNX.4.61.0606032056190.10890@www>
Message-ID: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>

Hi Trent,
I tried the latest dll and it opens the port, receives 100-200 bytes and
then stops receiving anything else..

I'll keep playing with it.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 1:00 PM
To: rxtx at qbang.org
Subject: [Rxtx] CVS for 2.1 should have everything


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From impakt01 at optusnet.com.au  Sat Jun  3 21:22:41 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 13:22:41 +1000
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
Message-ID: <200606040322.k543MqW1008455@mail12.syd.optusnet.com.au>

Played with it, problem, with a while loop in my code, working great now

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Daren
Sent: Sunday, 4 June 2006 1:08 PM
To: 'RXTX Developers and Users'
Subject: Re: [Rxtx] CVS for 2.1 should have everything

Hi Trent,
I tried the latest dll and it opens the port, receives 100-200 bytes and
then stops receiving anything else..

I'll keep playing with it.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 1:00 PM
To: rxtx at qbang.org
Subject: [Rxtx] CVS for 2.1 should have everything


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Sat Jun  3 21:35:41 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 21:35:41 -0600 (MDT)
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
References: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606032131140.10890@www>

On Sun, 4 Jun 2006, Daren wrote:

> Hi Trent,
> I tried the latest dll and it opens the port, receives 100-200 bytes and
> then stops receiving anything else..
>
> I'll keep playing with it.
>
> Daren

The difference may be that I'm talking to something at the exact same baud 
rate (loopback).

You may also try setting the baudrate to ~1933 and ~1973 to force the 
guesses one way or the other.  If you are on windows, we are not doing 
anything fancy in the end.  Thats the kernel guessing.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sun Jun  4 04:12:09 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sun, 4 Jun 2006 12:12:09 +0200
Subject: [Rxtx] Update of OSX installer, Readme, etc
Message-ID: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>

Good day,

after the latest changes a lot of OS X specific files should be  
updated. Especially the installer!

- The "MaxOSX" readme file on the root level is outdated (ie  
CodeWarrior information). Maybe we could even rename it to README.OSX  
to be in line with README.IPAQ, README.SCO (Trent do you mind copying/ 
renaming ,v files in the repository?).

- The lock files are no longer used and hence the user group magic  
and lock folder creation should be removed from the installer.

- MACOSX_IDE/ForPackageMaker/Resources/ReadMe.rtf and Welcome.rtf  
need to be updated.

- I suggest to replace the current installation instruction for OS X:  
Installation should occur into the application directory, not in the  
Java-VM directory. This simplifies things a lot, as the Mac Installer  
can be removed completely.

- The xcodeproject's build settings need to be updated to generate  
JAVA 1.1 format class files.


Dimitry: do you have time to tackle this? I could do it, but as this  
is "your baby" I thought you may prefer to do it yourself.

Regards,
Joachim



From dmarkman at mac.com  Sun Jun  4 11:27:53 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Sun, 4 Jun 2006 13:27:53 -0400
Subject: [Rxtx] Update of OSX installer, Readme, etc
In-Reply-To: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
References: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
Message-ID: <26E7A202-962B-4C19-93B6-29426C467249@mac.com>

Joachim,
unfortunately I don't have time right now to do that
so if you can do that, please do

it's not only my baby
it's yours too :-)

thanks


On Jun 4, 2006, at 6:12 AM, Joachim Buechse wrote:

> Good day,
>
> after the latest changes a lot of OS X specific files should be
> updated. Especially the installer!
>
> - The "MaxOSX" readme file on the root level is outdated (ie
> CodeWarrior information). Maybe we could even rename it to README.OSX
> to be in line with README.IPAQ, README.SCO (Trent do you mind copying/
> renaming ,v files in the repository?).
>
> - The lock files are no longer used and hence the user group magic
> and lock folder creation should be removed from the installer.
>
> - MACOSX_IDE/ForPackageMaker/Resources/ReadMe.rtf and Welcome.rtf
> need to be updated.
>
> - I suggest to replace the current installation instruction for OS X:
> Installation should occur into the application directory, not in the
> Java-VM directory. This simplifies things a lot, as the Mac Installer
> can be removed completely.
>
> - The xcodeproject's build settings need to be updated to generate
> JAVA 1.1 format class files.
>
>
> Dimitry: do you have time to tackle this? I could do it, but as this
> is "your baby" I thought you may prefer to do it yourself.
>
> Regards,
> Joachim
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman



From tjarvi at qbang.org  Sun Jun  4 13:54:02 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 4 Jun 2006 13:54:02 -0600 (MDT)
Subject: [Rxtx] Update of OSX installer, Readme, etc
In-Reply-To: <26E7A202-962B-4C19-93B6-29426C467249@mac.com>
References: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
	<26E7A202-962B-4C19-93B6-29426C467249@mac.com>
Message-ID: <Pine.LNX.4.61.0606041353040.22522@www>

On Sun, 4 Jun 2006, Dmitry Markman wrote:

> Joachim,
> unfortunately I don't have time right now to do that
> so if you can do that, please do
>
> it's not only my baby
> it's yours too :-)
>

I've given Joachim cvs access.  He has shown good work in bugzilla.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Mon Jun  5 10:08:32 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 5 Jun 2006 18:08:32 +0200
Subject: [Rxtx] Build process changes for Mac OS X
Message-ID: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>

Good day,

I have cleaned up some outdated Mac OSX specific build files in the  
repository.

There was not a lot left of the readme file "MacOSX" after cleaning  
it up, so I decided to rename it README.OSX to be in harmony with the  
other files in the directory (ie README.IPAQ, README.SCO, ...)

I added an (uncompressed) XCode 2.3 project file/structure  
with .cvsignore files that will ignore the user specific settings.  
This should work "out of the box" for OSX10.4. Users of 10.2/10.3 may  
have to switch the build settings.

[It's kind of tricky to choose "the right" setting. Afaik there is no  
way to compile a universal binary that will work on 10.3 or before.  
So it's either UniversalBinary OR Legacy. Maybe we should have  
different build targets for these different targets?? I would like to  
get some feedback from the Mac developers on this list regarding the  
subject].

Besides other things the OSX installer is no longer required. Since  
the next version (2.1.8) will no longer use lockfiles on OSX, the  
group/permission magic is no longer required and hence there remains  
basicly no work for the installer - other than copying 2 files to the  
VM extension directory. Then again, this is not the best way to  
install RXTX. So I removed the installer completely without modifying  
it, this should simplify a "resurrection" should it ever get necessary.

I had problems with the (compressed, ie sit.hqx) legacy project files  
on the latest installation of OSX (javac 1.5 creating non JDK1.1  
class files and some minor problems). To reduce potential confusion  
for newcomers I decided to remove them. This means that there is no  
longer a simple way to build RXTX for OSX 10.0 and 10.1 (I deeply  
apologize if anyone still relied on this ... well the files are in  
the Attiq).

Best regards,
Joachim


From joachim at buechse.de  Mon Jun  5 10:16:37 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 5 Jun 2006 18:16:37 +0200
Subject: [Rxtx] RXTX and lockfiles on OSX [it is fixed now]
Message-ID: <7D2C4418-9397-4B59-8091-9FDE4ED67836@buechse.de>

Quite a number of people contacted me in the last couple of weeks  
because of problems installing RXTX on OSX. I told you to wait for  
the "official" fix. Well, it has been fixed.

So if you were among the people waiting for the solution, you can now  
download the source rxtx-2.1-7r2.zip from the website. Once unpacked  
dont forget to use "cvs up" to update the files to the latest  
version. You can then open MACOSX_IDE/XCode/ 
LibSerialUniversal.xcodeproj with XCode 2.3 and build the libraries  
that no longer try to create lock files.

Regards,
Joachim


From brian at mbari.org  Mon Jun  5 10:52:43 2006
From: brian at mbari.org (Brian Schlining)
Date: Mon, 5 Jun 2006 09:52:43 -0700
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
Message-ID: <78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>

Hi Joachim,

> [It's kind of tricky to choose "the right" setting. Afaik there is no
> way to compile a universal binary that will work on 10.3 or before.
> So it's either UniversalBinary OR Legacy. Maybe we should have
> different build targets for these different targets?? I would like to
> get some feedback from the Mac developers on this list regarding the
> subject].

I imagine most developers will be compiling on 10.4 (It's the nature  
of the coder...gotta have the latest and greatest) and deploying to  
both 10.3 and 10.4; both of which will run Universal Binaries (see  
http://forums.macrumors.com/showthread.php?t=205348). So it sounds  
like you've covered the majority of users. Still, you know someone's  
going to pipe up about needing RXTX on 10.2 so it would be nice to  
have a target to make a PPC only build.

Just my 2 cents

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/1cac8c39/attachment-0011.html

From dmarkman at mac.com  Mon Jun  5 13:47:50 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Mon, 5 Jun 2006 15:47:50 -0400
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
Message-ID: <686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>

I don't think it will be a problem to run universal binary
on 10.2
however if binary has some calls that aren't implemented in 10.2
then you'll have a problem


On Jun 5, 2006, at 12:52 PM, Brian Schlining wrote:

> Hi Joachim,
>
>> [It's kind of tricky to choose "the right" setting. Afaik there is no
>> way to compile a universal binary that will work on 10.3 or before.
>> So it's either UniversalBinary OR Legacy. Maybe we should have
>> different build targets for these different targets?? I would like to
>> get some feedback from the Mac developers on this list regarding the
>> subject].
>
> I imagine most developers will be compiling on 10.4 (It's the  
> nature of the coder...gotta have the latest and greatest) and  
> deploying to both 10.3 and 10.4; both of which will run Universal  
> Binaries (see http://forums.macrumors.com/showthread.php?t=205348).  
> So it sounds like you've covered the majority of users. Still, you  
> know someone's going to pipe up about needing RXTX on 10.2 so it  
> would be nice to have a target to make a PPC only build.
>
> Just my 2 cents
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/9fafc878/attachment-0011.html

From brian at mbari.org  Mon Jun  5 14:52:41 2006
From: brian at mbari.org (Brian Schlining)
Date: Mon, 5 Jun 2006 13:52:41 -0700
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
Message-ID: <E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>

Hi Dmitry,

> I don't think it will be a problem to run universal binary
> on 10.2
> however if binary has some calls that aren't implemented in 10.2
> then you'll have a problem

You're right...I stand corrected.

Note however, to deploy a universal binary to 10.2 RXTX will need to  
use the 10.2 SDK to build the PPC side. (see http:// 
developer.apple.com/documentation/DeveloperTools/Conceptual/ 
cross_development/UniversalBinaries/chapter_4_section_1.html). I  
haven't been paying close attention to the new locking mechanism used  
by RXTX on the Mac...does 10.2 support it?

Joachim, which SDK will you be using by default for building the Mac  
PPC binaries?

>> Hi Joachim,
>>
>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>> is no
>>> way to compile a universal binary that will work on 10.3 or before.
>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>> different build targets for these different targets?? I would  
>>> like to
>>> get some feedback from the Mac developers on this list regarding the
>>> subject].
>>
>> I imagine most developers will be compiling on 10.4 (It's the  
>> nature of the coder...gotta have the latest and greatest) and  
>> deploying to both 10.3 and 10.4; both of which will run Universal  
>> Binaries (see http://forums.macrumors.com/showthread.php? 
>> t=205348). So it sounds like you've covered the majority of users.  
>> Still, you know someone's going to pipe up about needing RXTX on  
>> 10.2 so it would be nice to have a target to make a PPC only build.

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/153bf50e/attachment-0011.html

From dmarkman at mac.com  Mon Jun  5 19:02:04 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Mon, 5 Jun 2006 21:02:04 -0400
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
Message-ID: <7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>

if Joachim didn't change xcode project setting

/Developer/SDKs/MacOSX10.4u.sdk is used to build universal binary

so it's quite possible that it won't run properly on 10.2

so we have to change the building process, so ppc part will be built
with
/Developer/SDKs/MacOSX10.2.8.sdk

and finally to use lipo utility to build universal binaries

Joachim, did you use some specific locking API that wasn't implemented

in MacOSX10.2.8.sdk?

thanks


On Jun 5, 2006, at 4:52 PM, Brian Schlining wrote:

> Hi Dmitry,
>
>> I don't think it will be a problem to run universal binary
>> on 10.2
>> however if binary has some calls that aren't implemented in 10.2
>> then you'll have a problem
>
> You're right...I stand corrected.
>
> Note however, to deploy a universal binary to 10.2 RXTX will need  
> to use the 10.2 SDK to build the PPC side. (see http:// 
> developer.apple.com/documentation/DeveloperTools/Conceptual/ 
> cross_development/UniversalBinaries/chapter_4_section_1.html). I  
> haven't been paying close attention to the new locking mechanism  
> used by RXTX on the Mac...does 10.2 support it?
>
> Joachim, which SDK will you be using by default for building the  
> Mac PPC binaries?
>
>>> Hi Joachim,
>>>
>>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>>> is no
>>>> way to compile a universal binary that will work on 10.3 or before.
>>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>>> different build targets for these different targets?? I would  
>>>> like to
>>>> get some feedback from the Mac developers on this list regarding  
>>>> the
>>>> subject].
>>>
>>> I imagine most developers will be compiling on 10.4 (It's the  
>>> nature of the coder...gotta have the latest and greatest) and  
>>> deploying to both 10.3 and 10.4; both of which will run Universal  
>>> Binaries (see http://forums.macrumors.com/showthread.php? 
>>> t=205348). So it sounds like you've covered the majority of  
>>> users. Still, you know someone's going to pipe up about needing  
>>> RXTX on 10.2 so it would be nice to have a target to make a PPC  
>>> only build.
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/84790f80/attachment-0011.html

From joachim at buechse.de  Tue Jun  6 02:40:47 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 6 Jun 2006 10:40:47 +0200
Subject: [Rxtx] Building on OS X, Impl Changes
In-Reply-To: <7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
Message-ID: <CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>

Good day!

What's in the XCode project setting?
----------

The xcode project remained pretty much the same as before. I excluded  
the user specific files from CVS and changed some settings. I kept  
all the built targets (you shouldn't change what you don't understand;-)

Currently we the following build targets:
    RXTXComm (java files)
    librxtxParallel.jnilib (usefull on the Mac???)
    libI2C.jnilib (not yet working in RXTX)
    libRS485.jnilib (not yet working in RXTX)
    librxtxSerial.jnilib (1)
    librxtxSerial.jnilib Dynamic (2)
    rxtxSerial (3)
We also have the following build configurations for each target:
    Development
    Default
    Deployment

What was changed in the xcode project from previous versions:
- java.souce=1.3 and java.target=1.1 in RXTXComm settings
- removed copying of build products into installer directory
- removed "(Upgraded)" from build target names

What remains to be changed:
- choosing a "non-debug" Build-configuration as default
- potentially removing "Default"/"Development" Build-configurations
- reducing the number of build targets
- creating 10.2 compatible universal binaries

I suggest, that the build configurations should be reduced to 2  
(Debug/Deployment), possibly even 1 (Debug).
I have not yet found the deeper meaning of the build targets(1)(2) 
(3), it seems to me like they should be reduced into one "doing the  
right thing" or maybe into two "rxtxSerial.jnilib Legacy" (back to  
10.2, universal if possible) and "rxtxSerial.jnilib 10.4 
+" (universal, 10.4+).

Should the code work on 10.2?
----------

Absolutely. The code should work on NextStep, in fact on any BSD  
unix. I would go as far as saying, this code should work on any  
POSSIX based unix. All that was added is the call "ioctl(fd,  
TIOCEXCL)" to request excusivity of the port:

http://gemma.apple.com/documentation/DeviceDrivers/Conceptual/ 
WorkingWSerial/WWSerial_SerialDevs/chapter_2_section_8.html

It is not yet "the perfect solution". Normally an open /dev/tty  
(listen for incomming connection) should be "preemptable" by opening  
a /dev/cu (outgoing connection) for the same port. This is not yet  
implemented as it needs calls outside of POSSIX on OSX.

On "classic" systems (like NextStep) this worked based on the  
"carried detect line". open() on /dev/tty.xxx would block until the  
carrier detect signal was raised. As the device was not "opened"  
opening /dev/cu.xxx worked without a hitch. When they ported to the  
Mac this broke. On Macs the "carier detect" is usually not wired.  
Furthermore FAX modems did no longer raise the line. So the OSX  
implementor defined a new call, which is documented here:

http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00045.html

Best regards,
Joachim




On 06.06.2006, at 03:02, Dmitry Markman wrote:

> if Joachim didn't change xcode project setting
>
> /Developer/SDKs/MacOSX10.4u.sdk is used to build universal binary
>
> so it's quite possible that it won't run properly on 10.2
>
> so we have to change the building process, so ppc part will be built
> with
> /Developer/SDKs/MacOSX10.2.8.sdk
>
> and finally to use lipo utility to build universal binaries
>
> Joachim, did you use some specific locking API that wasn't implemented
>
> in MacOSX10.2.8.sdk?
>
> thanks
>
>
> On Jun 5, 2006, at 4:52 PM, Brian Schlining wrote:
>
>> Hi Dmitry,
>>
>>> I don't think it will be a problem to run universal binary
>>> on 10.2
>>> however if binary has some calls that aren't implemented in 10.2
>>> then you'll have a problem
>>
>> You're right...I stand corrected.
>>
>> Note however, to deploy a universal binary to 10.2 RXTX will need  
>> to use the 10.2 SDK to build the PPC side. (see http:// 
>> developer.apple.com/documentation/DeveloperTools/Conceptual/ 
>> cross_development/UniversalBinaries/chapter_4_section_1.html). I  
>> haven't been paying close attention to the new locking mechanism  
>> used by RXTX on the Mac...does 10.2 support it?
>>
>> Joachim, which SDK will you be using by default for building the  
>> Mac PPC binaries?
>>
>>>> Hi Joachim,
>>>>
>>>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>>>> is no
>>>>> way to compile a universal binary that will work on 10.3 or  
>>>>> before.
>>>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>>>> different build targets for these different targets?? I would  
>>>>> like to
>>>>> get some feedback from the Mac developers on this list  
>>>>> regarding the
>>>>> subject].
>>>>
>>>> I imagine most developers will be compiling on 10.4 (It's the  
>>>> nature of the coder...gotta have the latest and greatest) and  
>>>> deploying to both 10.3 and 10.4; both of which will run  
>>>> Universal Binaries (see http://forums.macrumors.com/ 
>>>> showthread.php?t=205348). So it sounds like you've covered the  
>>>> majority of users. Still, you know someone's going to pipe up  
>>>> about needing RXTX on 10.2 so it would be nice to have a target  
>>>> to make a PPC only build.
>>
>> Brian Schlining
>> Software Engineer
>> http://www.mbari.org
>>
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> Dmitry Markman
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Tue Jun  6 07:01:06 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 6 Jun 2006 15:01:06 +0200
Subject: [Rxtx] Serial port code for OS X, future steps
In-Reply-To: <CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
	<CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
Message-ID: <8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>

I posted the "wrong link". There is a correction here:

    http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00059.html

In fact, the 2.1.7 implementation of RXTX has quite some deficiencies  
on OSX. I have tried to supply some patches that don't interfere to  
much with the existing RXTX code base, but there are limits to what  
can be done with local patches.

There are some very intrusive changes that should be done. Ie proper  
mapping of /dev/tty <-> /dev/cu handling to correct behaviour of  
CommPortOwnershipListener (http://java.sun.com/products/javacomm/ 
reference/api/index.html). I dont think this can be done with  
patches. Hence I think, RXTX should be rewritten from scratch de- 
unifying the native code base (and implementing thread safe code on  
the Java side).


How "should" /dev/tty vs /dev/cu be implemented?

=====
The Unix contract is this: An open /dev/tty.xxx port (incomming)  
should be interrupted/auto-closed when opening /dev/cu.xxx (outgoing)  
[if /dev/tty.xxx is not currently handling a communication].  /dev/ 
cu.xxx and /dev/tty.xxx refer to the same device, so owning  
"exclusively" should block both. This should be respected across all  
applications native or Java.

This contract is realizable on OSX with the existing javax.comm  
interface while also respecting (to the biggest part) the contract  
defined by javax.comm.PortOwnershipListener.

The one point where the suggested implementation "breaks" the  
javax.comm contract, is by the fact that one can loose a /dev/tty  
port without calling close. However, the only option I see is to  
always open serial ports "non-exclusively" which would outrule Java  
as a platform for (dormant) applications waiting for incoming  
connections/faxes/etc. There could be a system property to choose the  
intended behavior.
=====

Here is how it could be done on OSX:

Calling port=ComportIdentifier.open("/dev/cu.xxx") opens and owns the  
port exclusively until port.close() is called.
- Java applications listening with a PortOwnershipListener should get  
a PORT_OWNED event reasonably soon.
- Any further attempt by a Java or native application to open "/dev/ 
cu.xxx" or "/dev/tty.xxx" fails.
- /dev/cu.xxx is for "outgoing" connections, so receiving  
PORT_OWNERSHIP_REQUESTED makes little to no sense. With native  
applications it can not be implemented. For Java applications it  
could be implemented (by a hidden communication channel). I think  
it's not worth bothering. If anyone is willing to give up a port to  
others he should use /dev/tty.xxx instead of /dev/cu.xxx.

Registering a PortOwnershipListener on "/dev/cu.xxx" without opening  
it, uses /dev/tty.xxx (native open()) non-exclusively and polls its  
state. PORT_OWNED and PORT_UNOWNED can be produced.

Calling port=ComportIdentifier.open("/dev/tty.xxx") should open the  
port non-exclusively.
- Adding a SerialPortEventListener and reading from the port could be  
allowed while keeping it non-exclusive.
- When port.getOutputStream() is called, the state should be changed  
to an "exclusive" ownership. This may be configurable via a system  
property.
- To return to the non-exclusive state the port must be closed and  
reopened.
- While non-exclusively opened, opening the corresponding /dev/cu.xxx  
produces a PORT_OWNERSHIP_REQUESTED event. Which should be responded  
by closing the port from within the callback (as described in  
java.comm.PortOwnershipListener). If there is a pending read, it will  
return after the listener finishes (with -1 or "0 bytes read").
- Calling write() on the /dev/tty.xxx after somebody opened /dev/ 
cu.xxx will fail with a descriptive IOException.
- Calling read() on the /dev/tty.xxx after somebody opened /dev/ 
cu.xxx will fail with a descriptive IOException (or potentially  
block, see side notes below).

CommPortIdentifier.getCurrentOwner() can be implemented by an  
external call to lsof.

CommPortIdentifier.isCurrentlyOwned() can be implemented by trying an  
open on the /dev/tty.
- It returns true if the port is currently held "exclusively".
- Whether it should also return true on /dev/tty if /dev/tty is  
already opened non-exclusively might be a system property option. In  
general, having several applications waiting for incoming connections  
on the same port will require an application level "arbitration"  
protocol...

[[side note1: One interesting question is, what happens if the  
process holding /dev/tty non-exclusively ignores  
PORT_OWNERSHIP_REQUESTED. Ie after "loosing" a non-exclusively opened  
"dev/tty.xxx" port to another process. One possible implementation  
is, that the port is "regained" when the other process gives up the  
port. This would mean that in the meanwhile read() returns no data,  
and any changes to the configuration of the port are stored but not  
forwarded. I guess, the safe (and simple) way to do this is to make  
the close() mandatory (ie setting the port into an "awaiting_close"  
state which produces IOExceptions to any other call than close). ]]

[[side note2:  Another interesting question is, what should happen if  
several applications open the same /dev/tty.xxx port "non- 
exclusively" and start to change the settings of the device.]]

Regards,
Joachim



On 06.06.2006, at 10:40, Joachim Buechse wrote:

> Should the code work on 10.2?
> ----------
>
> Absolutely. The code should work on NextStep, in fact on any BSD
> unix. I would go as far as saying, this code should work on any
> POSSIX based unix. All that was added is the call "ioctl(fd,
> TIOCEXCL)" to request excusivity of the port:
>
> http://gemma.apple.com/documentation/DeviceDrivers/Conceptual/
> WorkingWSerial/WWSerial_SerialDevs/chapter_2_section_8.html
>
> It is not yet "the perfect solution". Normally an open /dev/tty
> (listen for incomming connection) should be "preemptable" by opening
> a /dev/cu (outgoing connection) for the same port. This is not yet
> implemented as it needs calls outside of POSSIX on OSX.
>
> On "classic" systems (like NextStep) this worked based on the
> "carried detect line". open() on /dev/tty.xxx would block until the
> carrier detect signal was raised. As the device was not "opened"
> opening /dev/cu.xxx worked without a hitch. When they ported to the
> Mac this broke. On Macs the "carier detect" is usually not wired.
> Furthermore FAX modems did no longer raise the line. So the OSX
> implementor defined a new call, which is documented here:
>
> http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00045.html
>
> Best regards,
> Joachim



From sds at dcs.gla.ac.uk  Tue Jun  6 11:22:45 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Tue, 06 Jun 2006 18:22:45 +0100
Subject: [Rxtx] Correct compile flag for HP iPAQ hx4700 running Familiar
	Linux?
Message-ID: <1149614565.19496.10.camel@addu>

Hi,

I'd like to use RXTX 2.1 on my HP iPAQ hx4700. The iPAQ is running
Familiar Linux 0.8.2 (as I recall), with Blackdown Java 1.3.1.

I can compile and run a test program which uses RXTX on my i686 machine,
and it works fine. But I can't seem to get things working quite right on
my PDA.

I compile the code on the laptop with the following commands:
	./configure --host=arm-gnu-linux && make
... as suggested in a post to this list, albeit some time ago. This
compiles, I transfer the files, set up LD_LIBRARY_PATH and CLASSPATH
variables, and get the following error on the PDA:

sds at ipaq-pxa-2:~# java Test
java.lang.UnsatisfiedLinkError: /usr/local/lib/ext/librxtxSerial.so: /usr/local/lib/ext/librxtxSerial.so: cannot open shared object file: No such file or directory thrown while loading gnu.io.RXTXCommDriver
Exception in thread "main"
java.lang.UnsatisfiedLinkError: /usr/local/lib/ext/librxtxSerial.so: /usr/local/lib/ext/librxtxSerial.so: cannot open shared object file: No such file or directory
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1382)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1290)
        at java.lang.Runtime.loadLibrary0(Runtime.java:749)
        at java.lang.System.loadLibrary(System.java:820)
        at
gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:83)
        at Test.<init>(Test.java:9)
        at Test.main(Test.java:32)
sds at ipaq-pxa-2:~# 

Note that I'm copying the files to /usr/local/lib/ext/ along with the
RXTXcomm.jar file, purely to keep things separate from the rest of the
system while testing. The location of the .so files doesn't seem to have
any bearing on whether "java Test" will succeed or not. The contents of
this directory are:

sds at ipaq-pxa-2:~$ ls /usr/local/lib/ext/
RXTXcomm.jar              librxtxParallel-2.1-7.so  librxtxRS485.so
librxtxSerial-2.1-7.so
librxtxI2C-2.1-7.so       librxtxParallel.so        librxtxRaw-2.1-7.so
librxtxSerial.so
librxtxI2C.so             librxtxRS485-2.1-7.so     librxtxRaw.so
sds at ipaq-pxa-2:~$

Test.java fails on the first real line of code I'm using to test that
things are working, prior to real development, and was carefully pinched
from the web:
Enumeration portIdentifiers = CommPortIdentifier.getPortIdentifiers();


I assume that I've gotten my --host flag wrong way back up there at
the ./configure step. But if that's the case, what should I set it to?
Or am I missing something more obvious?


Cheers,
Stephen Strowes,
University of Glasgow.




From tjarvi at qbang.org  Tue Jun  6 13:39:41 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 6 Jun 2006 13:39:41 -0600 (MDT)
Subject: [Rxtx] Serial port code for OS X, future steps
In-Reply-To: <8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
	<CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
	<8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>
Message-ID: <Pine.LNX.4.61.0606061315070.9856@www>


>>
There are some very intrusive changes that should be done. Ie proper
mapping of /dev/tty <-> /dev/cu handling to correct behaviour of
CommPortOwnershipListener (http://java.sun.com/products/javacomm/
reference/api/index.html). I dont think this can be done with
patches. Hence I think, RXTX should be rewritten from scratch de-
unifying the native code base (and implementing thread safe code on
the Java side).
<<

This appears to be a very small amount of functionality for a total 
rewrite.  The port ownership only needs maybe 3 native calls if it is done 
with native calls at all.

Those features which are not part of the Unix standard(s) can be special 
cased.  I'm not sure /dev/cu is standard.  We can look.  I know linux 
deprecated /dev/cua years ago.

Thread safe Java code is not a platform specific issue.

--
Trent Jarvi
tjarvi at qbang.org


From sds at dcs.gla.ac.uk  Wed Jun  7 12:36:43 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Wed, 07 Jun 2006 19:36:43 +0100
Subject: [Rxtx] Expected RXTX behaviour?
In-Reply-To: <1149703900.30891.19.camel@addu>
References: <1149703900.30891.19.camel@addu>
Message-ID: <1149705403.30891.25.camel@addu>

Apologies, caught the problem. Had to append '\r' to the end of the AT
string. A non obvious but stupid mistake... :-)

Final quick question though: How might I stop the echoing of
outputStream data back into the inputStream? I still see the ATI
commands on the inputStream, along with the output from the device.


Cheers,
S.



On Wed, 2006-06-07 at 19:11 +0100, Stephen Strowes wrote:
> Hi,
> 
> I managed to get RXTX to compile for my iPAQ following my previous post
> to this list. Quick query though:
> 
> I want to be able to issue AT commands to a device, and interpret the
> responses. For this, I assume I do the following, in psuedo-form:
> 
> 	CommPortIdentifier.getPortIdentifiers();
> 	// find the correct device id
> 	serialPort= (SerialPort)portID.open("Test");
> 	// Set parameters and flow control
> 	outputStream= serialPort.getOutputStream();
> 	inputStream=  serialPort.getInputStream();
> 
> ... following this, I spawn a thread to respond to DATA_AVAILABLE events
> on serialPort with inputStream, and occasionally write and flush an
> "ATI" onto the outputStream. Nothing complex, I just want to see it
> work.
> 
> I would have expected inputStream to give the same information back from
> an "ATI" command as minicom provides, but instead inputStream only sees
> the "ATI" I put onto the outputStream.
> 
> Have I missed something?
> 
> 
> Cheers,
> S.
> 



From sds at dcs.gla.ac.uk  Wed Jun  7 12:11:40 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Wed, 07 Jun 2006 19:11:40 +0100
Subject: [Rxtx] Expected RXTX behaviour?
Message-ID: <1149703900.30891.19.camel@addu>

Hi,

I managed to get RXTX to compile for my iPAQ following my previous post
to this list. Quick query though:

I want to be able to issue AT commands to a device, and interpret the
responses. For this, I assume I do the following, in psuedo-form:

	CommPortIdentifier.getPortIdentifiers();
	// find the correct device id
	serialPort= (SerialPort)portID.open("Test");
	// Set parameters and flow control
	outputStream= serialPort.getOutputStream();
	inputStream=  serialPort.getInputStream();

... following this, I spawn a thread to respond to DATA_AVAILABLE events
on serialPort with inputStream, and occasionally write and flush an
"ATI" onto the outputStream. Nothing complex, I just want to see it
work.

I would have expected inputStream to give the same information back from
an "ATI" command as minicom provides, but instead inputStream only sees
the "ATI" I put onto the outputStream.

Have I missed something?


Cheers,
S.




From joachim at buechse.de  Wed Jun  7 09:02:13 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 7 Jun 2006 17:02:13 +0200
Subject: [Rxtx] Update of build process for OSX (XCode project)
Message-ID: <62EC47B1-46BD-4ECA-B9EC-C4061D147CDA@buechse.de>

With the help of Dmitry Markman and Brian Schilling I have updated  
(and largely simplifed) the XCode project file for Mac OS X.

Changes:
- compiles a universal binary library with intel=OSX10.4+, ppc=OSX10.2 
+ support
- compiles the Java sources into a JRE1.1 compatible, compressed jar.

Please test on your configuration, especially if you have computers  
running 10.2/10.3 or intel.

Best regards,
Joachim


From joachim at buechse.de  Wed Jun  7 14:36:37 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 7 Jun 2006 22:36:37 +0200
Subject: [Rxtx] Expected RXTX behaviour?
In-Reply-To: <1149705403.30891.25.camel@addu>
References: <1149703900.30891.19.camel@addu> <1149705403.30891.25.camel@addu>
Message-ID: <D3AD6EAF-27BB-455E-9697-86C1121920C3@buechse.de>

Echoing is a feature of the modem. Try ATE0 which works with most  
"rockwell" compatible modems.

Regards,
Joachim


On 07.06.2006, at 20:36, Stephen Strowes wrote:

> Apologies, caught the problem. Had to append '\r' to the end of the AT
> string. A non obvious but stupid mistake... :-)
>
> Final quick question though: How might I stop the echoing of
> outputStream data back into the inputStream? I still see the ATI
> commands on the inputStream, along with the output from the device.
>
>
> Cheers,
> S.
>
>
>
> On Wed, 2006-06-07 at 19:11 +0100, Stephen Strowes wrote:
>> Hi,
>>
>> I managed to get RXTX to compile for my iPAQ following my previous  
>> post
>> to this list. Quick query though:
>>
>> I want to be able to issue AT commands to a device, and interpret the
>> responses. For this, I assume I do the following, in psuedo-form:
>>
>> 	CommPortIdentifier.getPortIdentifiers();
>> 	// find the correct device id
>> 	serialPort= (SerialPort)portID.open("Test");
>> 	// Set parameters and flow control
>> 	outputStream= serialPort.getOutputStream();
>> 	inputStream=  serialPort.getInputStream();
>>
>> ... following this, I spawn a thread to respond to DATA_AVAILABLE  
>> events
>> on serialPort with inputStream, and occasionally write and flush an
>> "ATI" onto the outputStream. Nothing complex, I just want to see it
>> work.
>>
>> I would have expected inputStream to give the same information  
>> back from
>> an "ATI" command as minicom provides, but instead inputStream only  
>> sees
>> the "ATI" I put onto the outputStream.
>>
>> Have I missed something?
>>
>>
>> Cheers,
>> S.
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From g_petrini at yahoo.it  Thu Jun  8 01:41:58 2006
From: g_petrini at yahoo.it (Giacomo Petrini)
Date: Thu, 8 Jun 2006 09:41:58 +0200 (CEST)
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from FieldTalk
Message-ID: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>

Hi,
I'm evaluating the library for the modbus protocol
from FieldTalk
(http://www.modbusdriver.com/fieldtalk/.
I'm using J2SE 5.0 and RXTX 2.1 on win XP.
The problem is that the modbus lib has a method (the
openProtocol method, but maybe there are others) tha
throws the
javax.comm.UnsupportedCommOperationException.
Now, in RXTX 2.1 the namespace has changed in gnu.io,
so the modbus library doesn't work anymore (it look
for things in javax.comm). I've already sent an email
to fieldtalk to see if they are aware of the problem.
The solution should be to use JavaComm + RXTX 2.0. But
I've read somewhere that JavaComm 2.0 does not work
with Java 5.0 and JavaComm 3.0 does not work with RXTX
2.0 so I don't know what to do.

Any ideas?

Thanks Jack

PS: can you make a CC to my personal email
(g_petrini at yahoo.it) too please?

Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 


From rxtx at tapastda.co.uk  Thu Jun  8 02:27:57 2006
From: rxtx at tapastda.co.uk (rxtx@tapastda.co.uk)
Date: Thu, 08 Jun 2006 09:27:57 +0100
Subject: [Rxtx] Win XP and Infrared based serial port
Message-ID: <4487DF8D.5050807@tapastda.co.uk>

I'm attempting to use RXTX 2.1.7 on Win XP with J2SE 5.0 to communicate with a
GSM mobile using a COM port. A peculiarity that I've seen is that whilst I can
communicate successfully with a mobile which uses an infrared based COM port
using the SUN provided javax.comm (v2.0) I cannot use RXTX because it fails to
read anything from the port (i.e. read timeout always occurs returning zero bytes).

I assumed that this could be the result of flow control problems and thus I've
tried setting either software or hardware based flow control on the port however
this has no affect.

Can you suggest any other port configuration changes which might be required to
make such a port work with RXTX.

Thanks
Stu
-- 
Stuart
Tapastda Limited


From tjarvi at qbang.org  Thu Jun  8 05:17:12 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 8 Jun 2006 05:17:12 -0600 (MDT)
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from
	FieldTalk
In-Reply-To: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
References: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606080504480.9856@www>

On Thu, 8 Jun 2006, Giacomo Petrini wrote:

> Hi,
> I'm evaluating the library for the modbus protocol
> from FieldTalk
> (http://www.modbusdriver.com/fieldtalk/.
> I'm using J2SE 5.0 and RXTX 2.1 on win XP.
> The problem is that the modbus lib has a method (the
> openProtocol method, but maybe there are others) tha
> throws the
> javax.comm.UnsupportedCommOperationException.
> Now, in RXTX 2.1 the namespace has changed in gnu.io,
> so the modbus library doesn't work anymore (it look
> for things in javax.comm). I've already sent an email
> to fieldtalk to see if they are aware of the problem.
> The solution should be to use JavaComm + RXTX 2.0. But
> I've read somewhere that JavaComm 2.0 does not work
> with Java 5.0 and JavaComm 3.0 does not work with RXTX
> 2.0 so I don't know what to do.
>
> Any ideas?
>
> Thanks Jack
>


Hi Jack

There are plans for Sun to rerelease JavaComm 2.0 mentioned in the rxtx 
mail-list archives.  When this happens rxtx will release a current rxtx 
2.0 library that works with it.

There are no dates promised by either side but rxtx will do it as soon as 
possible after Sun's rerelease.  Just to give you a feel for the time 
frame, this started last year and no significant progress has been made. 
There have been friendly talks pointing towards solutions (rerelease 2.0) 
but that does not get your application working today.  rxtx is preparing 
for its second release in gnu.io since then.

--
Trent Jarvi
tjarvi at qbang.org




From jredman at ergotech.com  Thu Jun  8 08:47:23 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 08 Jun 2006 08:47:23 -0600
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from
	FieldTalk
In-Reply-To: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
References: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
Message-ID: <4488387B.6040903@ergotech.com>

You could always try a different library, eg.

http://sourceforge.net/projects/jamod

I've only used the slave side since we have our own implementation of 
Modbus Client (and a host of other PLC protocols).  However the client 
side seems to be pretty well supported and fairly widely used.  Since 
the source is there you could change to gnu.io.

I think I should take more of an interest in this issue.  We generally 
run 1.4.2 on Linux, but also have some J9 and old platforms that we 
support that are basically Personal Java.  5.0 on Linux has some 
horrible MDI bugs, to the point of being unusable.   Sounds as though we 
are going to have code compatibility problems across these platforms.

Jim


Giacomo Petrini wrote:
> Hi,
> I'm evaluating the library for the modbus protocol
> from FieldTalk
> (http://www.modbusdriver.com/fieldtalk/.
> I'm using J2SE 5.0 and RXTX 2.1 on win XP.
> The problem is that the modbus lib has a method (the
> openProtocol method, but maybe there are others) tha
> throws the
> javax.comm.UnsupportedCommOperationException.
> Now, in RXTX 2.1 the namespace has changed in gnu.io,
> so the modbus library doesn't work anymore (it look
> for things in javax.comm). I've already sent an email
> to fieldtalk to see if they are aware of the problem.
> The solution should be to use JavaComm + RXTX 2.0. But
> I've read somewhere that JavaComm 2.0 does not work
> with Java 5.0 and JavaComm 3.0 does not work with RXTX
> 2.0 so I don't know what to do.
> 
> Any ideas?
> 
> Thanks Jack
> 
> PS: can you make a CC to my personal email
> (g_petrini at yahoo.it) too please?
> 
> Chiacchiera con i tuoi amici in tempo reale! 
>  http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  8 18:17:23 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 08 Jun 2006 17:17:23 -0700
Subject: [Rxtx] rxtx access is denied error
Message-ID: <4488BE13.2050706@dupreeinc.com>

Hello,

I have been trying to replace the commapi from sun with rxtx for a 
project that communicates with a serial port that is a USB-Serial 
interface.  To be exact, I am using the FTDI VCP driver with one of 
their modules connected to a windows XP system.

I have the RXTX package working pretty well as long as nothing goes wrong.

If a user disconnects the USB port while my java application is running, 
my application goes into an endless loop with lots of messages in the  
errors stream  like the ones below:

    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(481):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.


I believe when this happens the COM port completely disappears and the 
rxtx driver has a heart attack.  Obviously, the user should not do this, 
but my application needs to ideally, correct the situation or as a worse 
case, terminate with a little dignity.  Currently, I have not figured 
out how to catch this error.

The closest I have come is to trap an exception to my input stream read  
that says "No error in readByte"  This error appears to be outside of 
the endless loop of the errors listed above.

Does anybody have an idea of how to identify and trap this error?  Any 
suggestions on how to gracefully recover from it would be greatly 
appreciated!

Thank you for your time,

Doug Thistlethwaite




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060608/9cfca302/attachment-0011.html

From tjarvi at qbang.org  Thu Jun  8 20:54:17 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 8 Jun 2006 20:54:17 -0600 (MDT)
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <4488BE13.2050706@dupreeinc.com>
References: <4488BE13.2050706@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606082022580.1323@www>

On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I have been trying to replace the commapi from sun with rxtx for a project 
> that communicates with a serial port that is a USB-Serial interface.  To be 
> exact, I am using the FTDI VCP driver with one of their modules connected to 
> a windows XP system.
>
> I have the RXTX package working pretty well as long as nothing goes wrong.
>
> If a user disconnects the USB port while my java application is running, my 
> application goes into an endless loop with lots of messages in the  errors 
> stream  like the ones below:
>
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(481):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>
>
> I believe when this happens the COM port completely disappears and the rxtx 
> driver has a heart attack.  Obviously, the user should not do this, but my 
> application needs to ideally, correct the situation or as a worse case, 
> terminate with a little dignity.  Currently, I have not figured out how to 
> catch this error.
>
> The closest I have come is to trap an exception to my input stream read  that 
> says "No error in readByte"  This error appears to be outside of the endless 
> loop of the errors listed above.
>
> Does anybody have an idea of how to identify and trap this error?  Any 
> suggestions on how to gracefully recover from it would be greatly 
> appreciated!
>

Hi Doug

Sadly I don't have a quick solution for you.

Termios has no knowlage about the JVM so it wont be throwing exceptions 
you can catch.

We can return error and set the error number to something reasonable that 
results in an exception.  The No Error message simply means we did not set 
an error number in termios.c.  Those are the line numbers in the code you 
see.  SerialImp.c realizes it errored but does not know much more yet. 
Everything touching the file descriptor is going to error after the port 
is gone presumably.

We don't currently have a plan in place for vanishing (or appearing) com 
ports.

Another example of what we need to think about is what happens if you 
start your application and then plug in the dongle?  Or what if you unplug 
and then plug it in again?

So in each of these three cases, what would the behavior of the (yet to 
be) correct implementation do?

How will the enumerated ports be handled during these changes?

There can also be hints from the OS that could be taken into 
consideration.

We can probably get some exceptions thrown that make sense and null the 
file descriptor when it happens to prevent io attempts.  That would be a 
crude way to let applications know something strange has happened.

Is anyone else tinkering with this problem?

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  9 01:31:29 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 9 Jun 2006 09:31:29 +0200
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <Pine.LNX.4.61.0606082022580.1323@www>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
Message-ID: <AC6EDDDD-0A64-401F-B16B-E484788CDF4A@buechse.de>

Hello Trent,

I am not tinkering with this on the Source Level - but I think it  
should work pretty much the same way as it currently does in OSX.  
When the port goes away you get an IOException thrown for any read/ 
write. It will no longer be in the list of ports from  
CommPortIdentifier.getPortIdentifiers(). When a port (re-)appears it  
is added to the list. It's up to the application to re-check the list  
from time to time.

On Windows you can't do much better then that, because the ports  
don't have useful names. Which USB "virtual com port" is on which  
COMx depends on the order the devices were added. So reconnecting to  
the same device may mean connecting to another port.

Regarding the exception thrown: it would be nice to use an  
IOException subclass but the Exception message should definetly be  
informative also as most applications may want to keep compatibility  
with javax.comm.

Regards,
Joachim


On 09.06.2006, at 04:54, Trent Jarvi wrote:

> On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:
>
>> Hello,
>>
>> I have been trying to replace the commapi from sun with rxtx for a  
>> project
>> that communicates with a serial port that is a USB-Serial  
>> interface.  To be
>> exact, I am using the FTDI VCP driver with one of their modules  
>> connected to
>> a windows XP system.
>>
>> I have the RXTX package working pretty well as long as nothing  
>> goes wrong.
>>
>> If a user disconnects the USB port while my java application is  
>> running, my
>> application goes into an endless loop with lots of messages in  
>> the  errors
>> stream  like the ones below:
>>
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (481):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>
>>
>> I believe when this happens the COM port completely disappears and  
>> the rxtx
>> driver has a heart attack.  Obviously, the user should not do  
>> this, but my
>> application needs to ideally, correct the situation or as a worse  
>> case,
>> terminate with a little dignity.  Currently, I have not figured  
>> out how to
>> catch this error.
>>
>> The closest I have come is to trap an exception to my input stream  
>> read  that
>> says "No error in readByte"  This error appears to be outside of  
>> the endless
>> loop of the errors listed above.
>>
>> Does anybody have an idea of how to identify and trap this error?   
>> Any
>> suggestions on how to gracefully recover from it would be greatly
>> appreciated!
>>
>
> Hi Doug
>
> Sadly I don't have a quick solution for you.
>
> Termios has no knowlage about the JVM so it wont be throwing  
> exceptions
> you can catch.
>
> We can return error and set the error number to something  
> reasonable that
> results in an exception.  The No Error message simply means we did  
> not set
> an error number in termios.c.  Those are the line numbers in the  
> code you
> see.  SerialImp.c realizes it errored but does not know much more yet.
> Everything touching the file descriptor is going to error after the  
> port
> is gone presumably.
>
> We don't currently have a plan in place for vanishing (or  
> appearing) com
> ports.
>
> Another example of what we need to think about is what happens if you
> start your application and then plug in the dongle?  Or what if you  
> unplug
> and then plug it in again?
>
> So in each of these three cases, what would the behavior of the  
> (yet to
> be) correct implementation do?
>
> How will the enumerated ports be handled during these changes?
>
> There can also be hints from the OS that could be taken into
> consideration.
>
> We can probably get some exceptions thrown that make sense and null  
> the
> file descriptor when it happens to prevent io attempts.  That would  
> be a
> crude way to let applications know something strange has happened.
>
> Is anyone else tinkering with this problem?
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From doug at dupreeinc.com  Fri Jun  9 13:09:58 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 09 Jun 2006 12:09:58 -0700
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <Pine.LNX.4.61.0606082022580.1323@www>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
Message-ID: <4489C786.9050504@dupreeinc.com>


Ideally, it would be nice if it would throw an exception and terminate 
the loop.  I am still trying to figure out how to detect the condition 
and recover form it in some form...  I am getting the "No error in 
readByte" exception in my serialEvent() method after an input stream 
read.  It appears to me that the only graceful recovery is to close the 
port and then reopen it when it becomes available.  I can pass the event 
up to the update method in my main frame, but I still can't close the 
port from within that thread.  Any suggestions on how to pass this event 
to a location where the port can be safely closed?

Re: Slow startup in windows XP
I have been looking into this a little closer and have found out the 
following:
System Windows XP Pro 3GHz dual core with 1GB RAM and NO parallel port.
Starting the SerialDemo included with the commapi using the rxtx instead 
of javax.comm takes 60 seconds.
Starting the SerialDemo using rxrx with the rxtxParallel.dll file 
removed takes about 20 seconds.
Modify initialize in RXRXCommDriver.java to not test the parallel ports 
takes less than 1 second.

It would be nice if the initialize routine could detect the presence of 
rxtxParallel.dll file and just skip the whole process if not present.  
Is there an easy way to check for the presence of this file without 
running the parallel port test?

Doug


 

Trent Jarvi wrote:

>On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:
>...
>  
>
>
>Hi Doug
>
>Sadly I don't have a quick solution for you.
>
>Termios has no knowlage about the JVM so it wont be throwing exceptions 
>you can catch.
>
>We can return error and set the error number to something reasonable that 
>results in an exception.  The No Error message simply means we did not set 
>an error number in termios.c.  Those are the line numbers in the code you 
>see.  SerialImp.c realizes it errored but does not know much more yet. 
>Everything touching the file descriptor is going to error after the port 
>is gone presumably.
>
>We don't currently have a plan in place for vanishing (or appearing) com 
>ports.
>
>Another example of what we need to think about is what happens if you 
>start your application and then plug in the dongle?  Or what if you unplug 
>and then plug it in again?
>
>So in each of these three cases, what would the behavior of the (yet to 
>be) correct implementation do?
>
>How will the enumerated ports be handled during these changes?
>
>There can also be hints from the OS that could be taken into 
>consideration.
>
>We can probably get some exceptions thrown that make sense and null the 
>file descriptor when it happens to prevent io attempts.  That would be a 
>crude way to let applications know something strange has happened.
>
>Is anyone else tinkering with this problem?
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060609/911ed787/attachment-0011.html

From Ugo.Landini at Sun.COM  Fri Jun  2 14:23:47 2006
From: Ugo.Landini at Sun.COM (Ugo Landini)
Date: Fri, 02 Jun 2006 22:23:47 +0200
Subject: [Rxtx] OSX 10.4.7 and usb
Message-ID: <44809E53.2070905@sun.com>

Hi, I have installed the library and the native libraries on OSX 10.4.7. 
Then I have run this simple code:

...
while (portList.hasMoreElements()) {
             portId = (CommPortIdentifier) portList.nextElement();
             System.out.println("-> " + portId.getName() + " Port Type:" 
+ portId.getPortType());
...

and the output is:

Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7

Ports found:
-> /dev/tty.Bluetooth-PDA-Sync Port Type:1
-> /dev/cu.Bluetooth-PDA-Sync Port Type:1
-> /dev/tty.Bluetooth-Modem Port Type:1
-> /dev/cu.Bluetooth-Modem Port Type:1

I can't see any USB ports... with javax.comm on linux I could see the 
/dev/ttyUSB stuff, but that's not the case with OSX. Any idea?

tia

uL


From tod at todbot.com  Sun Jun 11 12:04:37 2006
From: tod at todbot.com (Tod E. Kurt)
Date: Sun, 11 Jun 2006 11:04:37 -0700
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <44809E53.2070905@sun.com>
References: <44809E53.2070905@sun.com>
Message-ID: <E2EB14A1-20A7-4611-8F1A-E3D2ABE41F48@todbot.com>

A dumb question, but: do you have the USB serial adapters plugged  
in?  They only show up in /dev when plugged in.  Also, you can verify  
they exist independent of RXTX by doing something like "ls -l /dev/ 
cu.*".

On Jun 2, 2006, at 1:23 PM, Ugo Landini wrote:

> Hi, I have installed the library and the native libraries on OSX  
> 10.4.7.
> Then I have run this simple code:
>
> ...
> while (portList.hasMoreElements()) {
>              portId = (CommPortIdentifier) portList.nextElement();
>              System.out.println("-> " + portId.getName() + " Port  
> Type:"
> + portId.getPortType());
> ...
>
> and the output is:
>
> Experimental:  JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
>
> Ports found:
> -> /dev/tty.Bluetooth-PDA-Sync Port Type:1
> -> /dev/cu.Bluetooth-PDA-Sync Port Type:1
> -> /dev/tty.Bluetooth-Modem Port Type:1
> -> /dev/cu.Bluetooth-Modem Port Type:1
>
> I can't see any USB ports... with javax.comm on linux I could see the
> /dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>
> tia
>
> uL
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>



From lyon at docjava.com  Sun Jun 11 12:14:50 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Sun, 11 Jun 2006 14:14:50 -0400
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <44809E53.2070905@sun.com>
References: <44809E53.2070905@sun.com>
Message-ID: <p06020444c0b20de7d248@[192.168.1.152]>

>Hi Ugo,

Do you have any USB serial ports (like the keyspan 19-HS) plugged
into the mac?
Thanks!
  - DL


>Hi, I have installed the library and the native libraries on OSX 10.4.7.
>Then I have run this simple code:
>
>...
>while (portList.hasMoreElements()) {
>              portId = (CommPortIdentifier) portList.nextElement();
>              System.out.println("-> " + portId.getName() + " Port Type:"
>+ portId.getPortType());
>...
>
>and the output is:
>
>Experimental:  JNI_OnLoad called.
>Stable Library
>=========================================
>Native lib Version = RXTX-2.1-7
>Java lib Version   = RXTX-2.1-7
>
>Ports found:
>-> /dev/tty.Bluetooth-PDA-Sync Port Type:1
>-> /dev/cu.Bluetooth-PDA-Sync Port Type:1
>-> /dev/tty.Bluetooth-Modem Port Type:1
>-> /dev/cu.Bluetooth-Modem Port Type:1
>
>I can't see any USB ports... with javax.comm on linux I could see the
>/dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>
>tia
>
>uL
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx



From dmarkman at mac.com  Sun Jun 11 14:30:27 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Sun, 11 Jun 2006 16:30:27 -0400
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <p06020444c0b20de7d248@[192.168.1.152]>
References: <44809E53.2070905@sun.com> <p06020444c0b20de7d248@[192.168.1.152]>
Message-ID: <B9C1606B-4339-4564-A175-FE83DFFA7D76@mac.com>

afaik
10.4.7 wasn't released yet
it will soon, no doubts


On Jun 11, 2006, at 2:14 PM, Dr. Douglas Lyon wrote:

>> Hi Ugo,
>
> Do you have any USB serial ports (like the keyspan 19-HS) plugged
> into the mac?
> Thanks!
>   - DL
>
>
>> Hi, I have installed the library and the native libraries on OSX  
>> 10.4.7.
>> Then I have run this simple code:
>>
>> ...
>> while (portList.hasMoreElements()) {
>>              portId = (CommPortIdentifier) portList.nextElement();
>>              System.out.println("-> " + portId.getName() + " Port  
>> Type:"
>> + portId.getPortType());
>> ...
>>
>> and the output is:
>>
>> Experimental:  JNI_OnLoad called.
>> Stable Library
>> =========================================
>> Native lib Version = RXTX-2.1-7
>> Java lib Version   = RXTX-2.1-7
>>
>> Ports found:
>> -> /dev/tty.Bluetooth-PDA-Sync Port Type:1
>> -> /dev/cu.Bluetooth-PDA-Sync Port Type:1
>> -> /dev/tty.Bluetooth-Modem Port Type:1
>> -> /dev/cu.Bluetooth-Modem Port Type:1
>>
>> I can't see any USB ports... with javax.comm on linux I could see the
>> /dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>>
>> tia
>>
>> uL
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman



From tjarvi at qbang.org  Sun Jun 11 18:52:59 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 11 Jun 2006 18:52:59 -0600 (MDT)
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <4489C786.9050504@dupreeinc.com>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
	<4489C786.9050504@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606111845430.7274@www>

On Fri, 9 Jun 2006, Doug Thistlethwaite wrote:

>
> Ideally, it would be nice if it would throw an exception and terminate the 
> loop.  I am still trying to figure out how to detect the condition and 
> recover form it in some form...  I am getting the "No error in readByte" 
> exception in my serialEvent() method after an input stream read.  It appears 
> to me that the only graceful recovery is to close the port and then reopen it 
> when it becomes available.  I can pass the event up to the update method in 
> my main frame, but I still can't close the port from within that thread.  Any 
> suggestions on how to pass this event to a location where the port can be 
> safely closed?
>

I've gone through and cleaned up the termios.c layer.  I need to get to a 
windows machine with a USB dongle and see where the ioctl() is being 
called.  Probably the eventLoop.  But all of the ioctls should probably 
result in an IOException during this condition.

I'll probably finish this up Monday night when I can borrow a USB 
dongle.

There is no point in putting the code into CVS yet.  If you are tinkering 
I can mail the patch.  I think we will want to make a couple fixes in 
SerialImp.c to handle errors before it's ready.

--
Trent Jarvi
tjarvi at qbang.org



From bob_tai2001 at yahoo.com  Mon Jun 12 09:42:14 2006
From: bob_tai2001 at yahoo.com (Bob Tai)
Date: Mon, 12 Jun 2006 08:42:14 -0700 (PDT)
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to RXTX
	again
Message-ID: <20060612154214.58219.qmail@web32804.mail.mud.yahoo.com>


thank you Paul, Joachim, Trent and everyone try to
workout the java comm and Rxtx situation.  At least
now I have something that is solid enough to make my
decision.  

thank you,
     Bob

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From Ralph.Buchfelder at gmx.net  Mon Jun 12 15:30:20 2006
From: Ralph.Buchfelder at gmx.net (Ralph Buchfelder)
Date: Mon, 12 Jun 2006 23:30:20 +0200
Subject: [Rxtx] rxtx binaries or porting to XSCALE Windows Mobile 2003 / 2005
Message-ID: <448DDCEC.7090506@gmx.net>

dear group,

i have been carefully reading your homepage, wiki and archives
but there seems to be no detailled information on porting to Windows 
Mobile/CE.

as far as i understood from the 'porting' section you can do porting to 
winCE. but how? do i only need to obtain the sourcecode (which one?) and 
compile this in Microsoft eMbedded Visual C++ for ARM/Xscale?
Any other ways?


unfortunately i must admit that i do have little linux skills but i have 
made my way through gcc and makefiles. right now i need to implement com 
  communication in a J2ME application and found your website as >the< 
solution.

best regards
Ralph Buchfelder

University of Regensburg
Department of Geography

PS: i dont care about Javacomm compliancy (ie. 2.0 or 2.1) - i just need 
a working serial port API in IBM J9 VM.


From paul.klissner at sun.com  Wed Jun 14 18:12:58 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Wed, 14 Jun 2006 17:12:58 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
Message-ID: <4490A60A.9090305@sun.com>

Hello RxTx community,

I finally think I have a compromise in place that will stand in the gap.

If you go to http://www.sun.com and search for javax.comm, you'll
get taken to a download page, where now users can get a copy of the
comm.jar file out of 2.0.3, along with just a license and a README.

I trust this will suffice until such time as RxTx decided to implement
their own java classes or we can get a JSR going to mitigate some
of the problems (the readme in the comm.jar 2.0.3 zip file
contains my thoughts on that).

Thanks,
Paul



From tjarvi at qbang.org  Wed Jun 14 21:15:35 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 14 Jun 2006 21:15:35 -0600 (MDT)
Subject: [Rxtx] rxtx-2.0-7 (final) src is in CVS
Message-ID: <Pine.LNX.4.61.0606142100500.2742@www>


I wasn't expecting to be working on rxtx 2.0 tonight :)

Thanks go out to Paul Klissner for his work in making the coming release 
of rxtx-2.0-7 possible for users that require package javax.comm on many 
platforms.

Most people know that rxtx 2.0 is for use with Sun's CommAPI 2.0 for 
Solaris or the Generic CommAPI 2.0-3 available for download at Sun.  If 
you need javax.comm packages on many platforms, you are probably 
interested.  If you use rxtx 2.1 in package gnu.io, then you are not going 
to care much.

I've tried to update the rxtx 2.0 src directory in preparation for 
rxtx-2.0-7 (final).  Linux should compile.  Windows will compile if you 
generate your own .def files (I'll generate these tomorrow).  If you have 
some time to do basic testing of the source, I'd appreciate it.  The 
source should be good but you may find classes not found.  This source is 
a backport from rxtx 2.1.

I wanted to get things started so anyone interested on Mac OS X could get 
a head start.

All of this is in CVS.  http://www.rxtx.org/cvs.html

I suspect we will have binaries for testing in a couple days if you are 
unable to compile.   Consider this a smoke test.

--
Trent Jarvi
tjarvi at qbang.org


From legolas.w at gmail.com  Wed Jun 14 22:04:28 2006
From: legolas.w at gmail.com (Legolas Woodland)
Date: Wed, 14 Jun 2006 21:04:28 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <4490A60A.9090305@sun.com>
References: <4490A60A.9090305@sun.com>
Message-ID: <87ee9b170606142104p745fcef0vea622fbc8f528bfc@mail.gmail.com>

is there anything new in this version of javax.comm ?
thanks


On 6/14/06, Paul Klissner <paul.klissner at sun.com> wrote:
>
> Hello RxTx community,
>
> I finally think I have a compromise in place that will stand in the gap.
>
> If you go to http://www.sun.com and search for javax.comm, you'll
> get taken to a download page, where now users can get a copy of the
> comm.jar file out of 2.0.3, along with just a license and a README.
>
> I trust this will suffice until such time as RxTx decided to implement
> their own java classes or we can get a JSR going to mitigate some
> of the problems (the readme in the comm.jar 2.0.3 zip file
> contains my thoughts on that).
>
> Thanks,
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060614/5ff4dfbc/attachment-0011.html

From joachim at buechse.de  Thu Jun 15 07:22:48 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 15 Jun 2006 15:22:48 +0200
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
Message-ID: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>

Good day!

Some of my users report problems using RXTX 2.1.7 on Windows98 to  
communicate with an FTDI FT245BM chip (using their latest VCP  
driver). Either no ports are being shown (ie returned form  
CommPortIdentifier.getPortIdentifiers()) or the transfers fail.

Did anyone run into similar Problems with Win98??

Best regards,
Joachim



From ajmas at sympatico.ca  Thu Jun 15 08:12:28 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Thu, 15 Jun 2006 10:12:28 -0400
Subject: [Rxtx] API change question
Message-ID: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

How closely do you follow the Java Communication API spec? The reason I ask is because I would be interested in augmenting the CommPortIdentifier class to include a getDisplayName() method. By default it would return the same value as getName(), but would provide the possibility of displaying a 'user friendly' name, for platforms where the display name is not the same as the device name. An example of this is on MacOS X, where currently the names seem to be of the form /dev/cu.* and /dev/tty.*, yet what the expects to see is simply the part after the full-stop. Although I could move this logic into the Java code, it would be nice to see it transparent to the Java code.

Andre




From ajmas at sympatico.ca  Thu Jun 15 08:16:22 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Thu, 15 Jun 2006 10:16:22 -0400
Subject: [Rxtx] Package to use
Message-ID: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

While the Java API spec refers to javax.comm, I see that only gnu.io is provide by the rxtx project. Should our projects refer to the gnu.io package or the javax.comm API?

Andre



From joachim at buechse.de  Thu Jun 15 08:45:05 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 15 Jun 2006 16:45:05 +0200
Subject: [Rxtx] API change question
In-Reply-To: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>

Hello Andre,

the /dev/cu and /dev/tty have different semantics on OS X. It is much  
more than a simply naming issue to unify them, see my recent mail to  
the list...

Best regards,
Joachim


On 15.06.2006, at 16:12, Andre-John Mas wrote:

> Hi,
>
> How closely do you follow the Java Communication API spec? The  
> reason I ask is because I would be interested in augmenting the  
> CommPortIdentifier class to include a getDisplayName() method. By  
> default it would return the same value as getName(), but would  
> provide the possibility of displaying a 'user friendly' name, for  
> platforms where the display name is not the same as the device  
> name. An example of this is on MacOS X, where currently the names  
> seem to be of the form /dev/cu.* and /dev/tty.*, yet what the  
> expects to see is simply the part after the full-stop. Although I  
> could move this logic into the Java code, it would be nice to see  
> it transparent to the Java code.
>
> Andre
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From lyon at docjava.com  Thu Jun 15 10:16:29 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Thu, 15 Jun 2006 12:16:29 -0400
Subject: [Rxtx] cu.modem != /dev/ttya on mac.
In-Reply-To: <763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
	<763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>
Message-ID: <p0602046cc0b7378a95b0@[192.168.1.152]>

>Hi All,

I think that Joachim is correct. For the longest time,
I have been trying to figure out how to direct dial using
the cu.modem on the mac under os x.

As a less-than-optimal approach to auto-dialing, I have used
a keyspan USB 19HS adapter, along with an external modem, to
obtain the dialing feature.

Ideally, it would be better to dial with the built-in modem...but that did not
always seem to work, for some reason. Have others had some experience with
using the built in modem for dialing on the mac?

Thanks!
  - Doug


>Hello Andre,
>
>the /dev/cu and /dev/tty have different semantics on OS X. It is much?
>more than a simply naming issue to unify them, see my recent mail to?
>the list...
>
>Best regards,
>Joachim
>



From doug at dupreeinc.com  Thu Jun 15 14:52:50 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 15 Jun 2006 13:52:50 -0700
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
In-Reply-To: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
References: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
Message-ID: <4491C8A2.8090108@dupreeinc.com>

Hi Joachim,

I have been doing a lot with the new FTDI driver with win XP and have 
not had that particular problem.  I did notice that the new driver 
(dated May19th, 2006) is only for XP, Server 2003, and 2000.  Are they 
trying to use the 2.00.00 drivers or the old 1.09.06 version.  I am 
using a FT232R based module, but it uses the same drivers and I assume 
it would have the same problems.  Let me know which driver they are 
using and I can load up a 98 system here and see if  I can duplicate the 
problem.

Doug

Joachim Buechse wrote:

>Good day!
>
>Some of my users report problems using RXTX 2.1.7 on Windows98 to  
>communicate with an FTDI FT245BM chip (using their latest VCP  
>driver). Either no ports are being shown (ie returned form  
>CommPortIdentifier.getPortIdentifiers()) or the transfers fail.
>
>Did anyone run into similar Problems with Win98??
>
>Best regards,
>Joachim
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From matthewhepp at yahoo.com  Thu Jun 15 17:34:47 2006
From: matthewhepp at yahoo.com (Matthew Hepp)
Date: Thu, 15 Jun 2006 16:34:47 -0700 (PDT)
Subject: [Rxtx] Wither the XCode project?
Message-ID: <20060615233447.48064.qmail@web50311.mail.yahoo.com>

Either I don't know how to properly use CVS (entirely possibl), or the XCode
project is not making through the update properly. Doing a "cvs update" against
2.1-7 creates an XCode folder in MACOSX_IDE, and therein a
LibSerialUniversal.xcodeproj, but trying to open it yields a "Unable to Open
Project - Project rxtx-devel/MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj
cannot be opened because it is missing its project.pbxproj file" error. Showing
package contents reveals just the cvs-related files. Perhaps this is why
previous xcode projects have been saved as an sit.hqx - to retain the resource
fork?

Can someone point me in the right direction?

Thanks,

Matt

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Thu Jun 15 19:53:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 19:53:06 -0600 (MDT)
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
In-Reply-To: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
References: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
Message-ID: <Pine.LNX.4.61.0606151944070.23137@www>

On Thu, 15 Jun 2006, Joachim Buechse wrote:

> Good day!
>
> Some of my users report problems using RXTX 2.1.7 on Windows98 to
> communicate with an FTDI FT245BM chip (using their latest VCP
> driver). Either no ports are being shown (ie returned form
> CommPortIdentifier.getPortIdentifiers()) or the transfers fail.
>
> Did anyone run into similar Problems with Win98??
>

Hi Joachim

It has been a long time since I've tested win98.  I know rxtx-2.1-7pre16 
did get testing on win98 with ~jdk 1.3 though.  I wonder if jdks are still 
tested on that platform.

With win98 you usually have older boxes.  They can be short on CPU and 
memory.  Enumeration should work but I could picture runtime performance 
issues on win98.

The enumeration problems could result from other copies of your 
application if various states of decay still holding onto the port.  When 
things go wrong, people also like to open other terminal software to see 
whats going on which can interfere.  You can't open a windows port with 
two apps.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Thu Jun 15 20:08:53 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 20:08:53 -0600 (MDT)
Subject: [Rxtx] API change question
In-Reply-To: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606151954270.23137@www>

On Thu, 15 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> How closely do you follow the Java Communication API spec?

I can explain how this worked in the past.  How we do it in the future is 
open for discussion.

In the past we have tried to follow it as close as possible in gnu.io 
(rxtx 2.1).  We have added extensions but try to discourage their use. 
The extensions are clearly marked as such in the source code and javadocs.

rxtx 2.0 was intended to be a strict implementation of part of the spec. 
We let Sun's interfaces decide what methods can be called. There are 
differences not covered by the spec such as default values.  Thats not 
intentional but rather hard to avoid.

--
Trent Jarvi
tjarvi at qbang.org





From tjarvi at qbang.org  Thu Jun 15 21:09:11 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 21:09:11 -0600 (MDT)
Subject: [Rxtx] Package to use
In-Reply-To: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606152026120.23137@www>

On Thu, 15 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> While the Java API spec refers to javax.comm, I see that only gnu.io is 
> provide by the rxtx project. Should our projects refer to the gnu.io 
> package or the javax.comm API?
>

Hi Andre

Lets see if I can give a fair and balanced answer to that.

If you are starting a new project and want to use RXTX, I would recommend 
using gnu.io.  The community support for gnu.io will not be going away 
anytime soon.  You can switch between gnu.io (2.1) and javax.comm (2.0) 
fairly easily.  They are not intended to be incompatible.  You just change 
package names and libs.

You can also consider the combination of rxtx 2.0 with Sun's commapi 
2.0-3.  This is considered a stop-gap measure by Sun for previous users of 
that combination.  Together rxtx 2.0 and Sun CommAPI 2.0 work in namespace 
javax.comm for programmers.

Finally, you can opt to just use Sun's oferrings in CommAPI 3.0 without 
rxtx.  That would be in namespace javax.comm also.  CommAPI 3.0 may be 
of more interest to you if you are looking at POS with Sun computers. 
Rxtx does not currently support the changes in CommAPI 3.0 or have firm 
plans to do so.  That does not mean we wouldn't implement them.  It just 
means nobody has contributed code yet.

You can't combine rxtx with CommAPI 3.0 for technical reasons that wont 
likely be fixed soon.

It's up to you as far as what you use.  We like to provide the freedom so 
you can choose.  Realistically, we will be supporting gnu.io mainly 
because we have some control over that name space and can support it.

Things may happen in the future that enable rxtx to provide more support 
in the javax namespace but that has not happened yet.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun 16 00:33:06 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 08:33:06 +0200
Subject: [Rxtx] Wither the XCode project?
In-Reply-To: <20060615233447.48064.qmail@web50311.mail.yahoo.com>
References: <20060615233447.48064.qmail@web50311.mail.yahoo.com>
Message-ID: <D30D660F-A49B-464E-AE4C-6B4563893682@buechse.de>

Hello Matthew,

could you please send me the contents of your

   rxtx-devel/CVS
   rxtx-devel/MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj/CVS

directories as a zip to my personal email address. This should  
indicate why the file is not checked out. I can see that it exists on  
the correct branch in the repository, so something must have gone  
wrong during the "cvs update"...

Best regards,
Joachim

On 16.06.2006, at 01:34, Matthew Hepp wrote:

> Either I don't know how to properly use CVS (entirely possibl), or  
> the XCode
> project is not making through the update properly. Doing a "cvs  
> update" against
> 2.1-7 creates an XCode folder in MACOSX_IDE, and therein a
> LibSerialUniversal.xcodeproj, but trying to open it yields a  
> "Unable to Open
> Project - Project rxtx-devel/MACOSX_IDE/XCode/ 
> LibSerialUniversal.xcodeproj
> cannot be opened because it is missing its project.pbxproj file"  
> error. Showing
> package contents reveals just the cvs-related files. Perhaps this  
> is why
> previous xcode projects have been saved as an sit.hqx - to retain  
> the resource
> fork?
>
> Can someone point me in the right direction?



From joachim at buechse.de  Fri Jun 16 10:41:20 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 18:41:20 +0200
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <p06230903c0b88613dca6@[10.0.1.7]>
References: <p06230903c0b88613dca6@[10.0.1.7]>
Message-ID: <03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>

Hello Bob,

until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was  
behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if  
Trent has migrated all recent changes from 2.1 to 2.0.

I have added the XCode project and updated documentation only to the  
gnu.io branch. Once the 2.0 implementation is up to date I will copy  
over the documentation/build files make them work.

Best regards,
Joachim

On 16.06.2006, at 18:07, Bob Jacobsen wrote:

> I'm one of the developers for the JMRI project, which provides  
> model railroad software in Java.  We've been using RXTX to provide  
> serial port access on MacOS X and Linux; we use the old javax.comm  
> 2.0 on Windows, OS/2 and Solaris.  Because of that, we need to stay  
> with RXTX 2.0, not 2.1
>
> We've been using the 2.0-pre17 installer for a long time, but it's  
> not compatible with Intel macs.
>
> Can you point me to where I can find the right files for RXTX 2.0  
> to package with the program?
>
> The current situation is confusing to me.  I've been pointed to  
> recent 2.1 versions (but we need the javax.comm names), to an even  
> older installer, etc.  I've been reading that some versions require  
> an installer, and others don't, but I haven't been able to figure  
> out which (if any) of those are where in CVS.
>
> I'd really appreciate a clear statement of what files to use and  
> what to do with them that I can pass on to our users.
>
> I'm more than happy to put files in the local classpath, have users  
> run an installer, or anything else.  Whatever is easiest for you.
>
> Thanks!  I really appreciate all that you do to keep RXTX working.
>
> Bob
> -- 
> Bob Jacobsen +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG



From joachim at buechse.de  Fri Jun 16 09:59:28 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 17:59:28 +0200
Subject: [Rxtx] Wither the XCode project?
In-Reply-To: <20060616150240.49464.qmail@web50309.mail.yahoo.com>
References: <20060616150240.49464.qmail@web50309.mail.yahoo.com>
Message-ID: <D9935E05-2B83-488D-86DD-42599E229052@buechse.de>

Hello Matthew,

you have checked out the trunk (which is the 2.0.7 javax.comm.xxx  
release). For rxtx-2.1.7 (gnu.io.xxx release) you need to check out  
the branch

      commapi-0-0-1

The easiest way to do this is to download the rxtx src archive,  
unpack it and then do a cvs up inside the decompressed tree.  
Optionally you could do a

      cvs co -r commapi-0-0-1

but this will take much longer!

Best regards,
Joachim

When you do a cvs status it will show the sticky tag.

41:~/jdevelop/rxtx-2.1-7r2 joachim$ cvs status README.OSX
===================================================================
File: README.OSX        Status: Up-to-date

    Working revision:    1.1.2.1
    Repository revision: 1.1.2.1 /usr/local/cvsroot/rxtx-devel/Attic/ 
README.OSX,v
    Sticky Tag:          commapi-0-0-1 (branch: 1.1.2)
    Sticky Date:         (none)
    Sticky Options:      (none)




On 16.06.2006, at 17:02, Matthew Hepp wrote:

> %cvs status README.MACOSX
> ===================================================================
> File: README.MACOSX     Status: Up-to-date
>
>    Working revision:    1.1
>    Repository revision: 1.1     /usr/local/cvsroot/rxtx-devel/ 
> README.MACOSX,v
>    Sticky Tag:          (none)
>    Sticky Date:         (none)
>    Sticky Options:      (none)



From tjarvi at qbang.org  Fri Jun 16 16:31:18 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Fri, 16 Jun 2006 16:31:18 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
Message-ID: <Pine.LNX.4.61.0606161630030.14139@www>

On Fri, 16 Jun 2006, Joachim Buechse wrote:

> Hello Bob,
>
> until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was
> behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if
> Trent has migrated all recent changes from 2.1 to 2.0.
>

The src/ directory and configure.in/configure files should be fine.  I 
have not touched the Mac OS X directories.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sat Jun 17 02:39:55 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sat, 17 Jun 2006 10:39:55 +0200
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <Pine.LNX.4.61.0606161630030.14139@www>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
Message-ID: <350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>

Hello Trent,

apparently the IOEXCL changes have not made it into 2.0. I will add  
them to achieve a minimal diff between 2.0 and 2.1.

One other thing that bugs me for a while...

Shouldn't we replace "if !defined(TIOCSERGETLSR) && !defined(WIN32)"  
by a definition of its own "if defined(DRAINTHREAD)"? I think this  
would make the code clearer for people starting to read it.

Regards,
Joachim


On 17.06.2006, at 00:31, Trent Jarvi wrote:

> On Fri, 16 Jun 2006, Joachim Buechse wrote:
>
>> Hello Bob,
>>
>> until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was
>> behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if
>> Trent has migrated all recent changes from 2.1 to 2.0.
>>
>
> The src/ directory and configure.in/configure files should be fine.  I
> have not touched the Mac OS X directories.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From tropicsu at hotmail.com  Sat Jun 17 09:32:48 2006
From: tropicsu at hotmail.com (Yoke K)
Date: Sat, 17 Jun 2006 15:32:48 +0000
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
Message-ID: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>

Hi,

I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to work with 
MAC OS X.
I am using iTegno 3000 - USB GPRS Modem.

Files in /dev and a symbolic link as follows:

crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 -> tty.usbserial

In my SendMessage.java, I have this line:
CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");

Appreciate any help ?

- Jon


Errors as follows:

>>INFO: SMSLib API for Java / v1.2.2
>>INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>INFO: JRE Version: 1.5.0_06
>>INFO: JRE Impl Version: 1.5.0_06-64
>>INFO: O/S: Mac OS X / ppc / 10.4.6
>>INFO: Using Wavecom (Generic) AT handler.

SendMessage(): Send a message.
  Using SMSLib API for Java v1.2.2

Connecting ..... :
>>INFO: CSerialDriver(): Connecting...
Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
>>INFO: CSerialDriver(): Disconnecting...
gnu.io.NoSuchPortException
        at 
gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:218)
        at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
        at org.smslib.CService.connect(CService.java:197)
        at SendMessage.main(SendMessage.java:38)

_________________________________________________________________
Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/



From tjarvi at qbang.org  Sat Jun 17 10:12:30 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 10:12:30 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
	<350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
Message-ID: <Pine.LNX.4.61.0606171010060.14139@www>

On Sat, 17 Jun 2006, Joachim Buechse wrote:

> Hello Trent,
>
> apparently the IOEXCL changes have not made it into 2.0. I will add
> them to achieve a minimal diff between 2.0 and 2.1.
>

Hi Joachim

As I recall the IOEXCL change was after 2.1-7.  I was just syncing with 
2.1-7.  We can release 2.1-8 and 2.0-8 with the same changes.

> One other thing that bugs me for a while...
>
> Shouldn't we replace "if !defined(TIOCSERGETLSR) && !defined(WIN32)"
> by a definition of its own "if defined(DRAINTHREAD)"? I think this
> would make the code clearer for people starting to read it.
>


Sure.  We can do that for -8.  The TIOCSERGETLSR code should be a special 
case not the expected.  I think only Linux uses it.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Sat Jun 17 10:48:21 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 10:48:21 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <Pine.LNX.4.61.0606171010060.14139@www>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
	<350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
	<Pine.LNX.4.61.0606171010060.14139@www>
Message-ID: <Pine.LNX.4.61.0606171047310.14139@www>

On Sat, 17 Jun 2006, Trent Jarvi wrote:

> On Sat, 17 Jun 2006, Joachim Buechse wrote:
>
>> Hello Trent,
>>
>> apparently the IOEXCL changes have not made it into 2.0. I will add
>> them to achieve a minimal diff between 2.0 and 2.1.
>>
>
> Hi Joachim
>
> As I recall the IOEXCL change was after 2.1-7.  I was just syncing with
> 2.1-7.  We can release 2.1-8 and 2.0-8 with the same changes.
>

We could just move to 2.1-8 and 2.0-8.

--
Trent Jarvi
tjarvi at qbang.org


From brian.t.lamb at gmail.com  Tue Jun 13 13:54:13 2006
From: brian.t.lamb at gmail.com (Brian Lamb)
Date: Tue, 13 Jun 2006 15:54:13 -0400
Subject: [Rxtx] Windows XP Installation
Message-ID: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>

I've not installed Java packages on Windows before and am unsure how to
proceed. All the documentation I've seen provides detailed instructions on
how to install on Linux or Solaris. I was wondering how to install rxtx on
Windows XP.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060613/6f68cd5c/attachment-0011.html

From tjarvi at qbang.org  Sat Jun 17 13:57:03 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 13:57:03 -0600 (MDT)
Subject: [Rxtx] Windows XP Installation
In-Reply-To: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>
References: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0606171356120.14139@www>

On Tue, 13 Jun 2006, Brian Lamb wrote:

> I've not installed Java packages on Windows before and am unsure how to
> proceed. All the documentation I've seen provides detailed instructions on
> how to install on Linux or Solaris. I was wondering how to install rxtx on
> Windows XP.
>

Hi Brian

Which rxtx version are you trying to install?

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sun Jun 18 10:41:44 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sun, 18 Jun 2006 18:41:44 +0200
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
References: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
Message-ID: <8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>

Hello Jon,

 From OSX's standpoint a symbolic link is not a device (as far as I  
know). What stops you from using tty.usbserial? Did you try hard- 
linking?

Regards,
Joachim

On 17.06.2006, at 17:32, Yoke K wrote:
> Hi,
>
> I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to  
> work with
> MAC OS X.
> I am using iTegno 3000 - USB GPRS Modem.
>
> Files in /dev and a symbolic link as follows:
>
> crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
> crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
> lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->  
> tty.usbserial
>
> In my SendMessage.java, I have this line:
> CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
>
> Appreciate any help ?
>
> - Jon
>
>
> Errors as follows:
>
>>> INFO: SMSLib API for Java / v1.2.2
>>> INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>> INFO: JRE Version: 1.5.0_06
>>> INFO: JRE Impl Version: 1.5.0_06-64
>>> INFO: O/S: Mac OS X / ppc / 10.4.6
>>> INFO: Using Wavecom (Generic) AT handler.
>
> SendMessage(): Send a message.
>   Using SMSLib API for Java v1.2.2
>
> Connecting ..... :
>>> INFO: CSerialDriver(): Connecting...
> Experimental:  JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
>>> INFO: CSerialDriver(): Disconnecting...
> gnu.io.NoSuchPortException
>         at
> gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java: 
> 218)
>         at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
>         at org.smslib.CService.connect(CService.java:197)
>         at SendMessage.main(SendMessage.java:38)
>
> _________________________________________________________________
> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Sun Jun 18 10:56:55 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 12:56:55 -0400
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>
References: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
	<8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>
Message-ID: <7B6834E3-F41D-46B6-B979-55466BC73859@sympatico.ca>

Have you been able to get any other software to talk with your
modem? What port is it using? Have tried using the cu.usbserial
instead?

Andre

On 18-Jun-06, at 12:41 , Joachim Buechse wrote:

> Hello Jon,
>
>  From OSX's standpoint a symbolic link is not a device (as far as I
> know). What stops you from using tty.usbserial? Did you try hard-
> linking?
>
> Regards,
> Joachim
>
> On 17.06.2006, at 17:32, Yoke K wrote:
>> Hi,
>>
>> I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to
>> work with
>> MAC OS X.
>> I am using iTegno 3000 - USB GPRS Modem.
>>
>> Files in /dev and a symbolic link as follows:
>>
>> crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
>> crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
>> lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->
>> tty.usbserial
>>
>> In my SendMessage.java, I have this line:
>> CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
>>
>> Appreciate any help ?
>>
>> - Jon
>>
>>
>> Errors as follows:
>>
>>>> INFO: SMSLib API for Java / v1.2.2
>>>> INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>>> INFO: JRE Version: 1.5.0_06
>>>> INFO: JRE Impl Version: 1.5.0_06-64
>>>> INFO: O/S: Mac OS X / ppc / 10.4.6
>>>> INFO: Using Wavecom (Generic) AT handler.
>>
>> SendMessage(): Send a message.
>>   Using SMSLib API for Java v1.2.2
>>
>> Connecting ..... :
>>>> INFO: CSerialDriver(): Connecting...
>> Experimental:  JNI_OnLoad called.
>> Stable Library
>> =========================================
>> Native lib Version = RXTX-2.1-7
>> Java lib Version   = RXTX-2.1-7
>>>> INFO: CSerialDriver(): Disconnecting...
>> gnu.io.NoSuchPortException
>>         at
>> gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:
>> 218)
>>         at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
>>         at org.smslib.CService.connect(CService.java:197)
>>         at SendMessage.main(SendMessage.java:38)
>>
>> _________________________________________________________________
>> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Sun Jun 18 17:33:08 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 19:33:08 -0400
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
Message-ID: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>

Hi,

I am have a program that I wrote in Java to communicate with a  
Bluetooth GPS device. I am
trying to get this working on my Mac, but I keep getting told that:

gnu.io.PortInUseException: Unknown Application

but

portIdentifier.isCurrentlyOwned()

returns false and when I do lsof on the device I am trying to connect  
to, I see no application
using it. As the same time if I go to the command line and use  
minicom I have no issues. The
exception happens with this call:

CommPort commPort = portIdentifier.open(null,0);

Any suggestions?

Andre


From ajmas at sympatico.ca  Sun Jun 18 17:45:11 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 19:45:11 -0400
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
Message-ID: <30245B30-682D-4EAE-8084-8227B719F10D@sympatico.ca>

BTW My code snippet is:

     private InputStream connectToSerial () throws IOException,  
Exception
     {
         InputStream in = null;

         Enumeration portEnum = CommPortIdentifier.getPortIdentifiers();
         while ( portEnum.hasMoreElements() )
         {
             CommPortIdentifier portIdentifier = (CommPortIdentifier)  
portEnum.nextElement();
             System.out.println(portIdentifier.getName() + " - " +  
portIdentifier.getPortType() );
         }

         CommPortIdentifier portIdentifier =  
CommPortIdentifier.getPortIdentifier("/dev/cu.BTGPS-SPPslave-1");
         System.out.println("current owner: " +  
portIdentifier.getCurrentOwner());
         if ( portIdentifier.isCurrentlyOwned() )
         {
             System.out.println("Error: Port is currently in use");
             return null;
         }
         else
         {
             CommPort commPort = portIdentifier.open(this.getClass 
().getName(),2000);

             if ( commPort instanceof SerialPort )
             {
                 SerialPort serialPort = (SerialPort) commPort;
                 serialPort.setSerialPortParams 
(4800,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE 
);
                 in = serialPort.getInputStream();

                 return in;
             }
             else
             {
                 System.out.println("Error: Only serial ports are  
handled.");
             }
         }


         return in;
     }


On 18-Jun-06, at 19:33 , Andr?-John Mas wrote:

> Hi,
>
> I am have a program that I wrote in Java to communicate with a
> Bluetooth GPS device. I am
> trying to get this working on my Mac, but I keep getting told that:
>
> gnu.io.PortInUseException: Unknown Application
>
> but
>
> portIdentifier.isCurrentlyOwned()
>
> returns false and when I do lsof on the device I am trying to connect
> to, I see no application
> using it. As the same time if I go to the command line and use
> minicom I have no issues. The
> exception happens with this call:
>
> CommPort commPort = portIdentifier.open(null,0);
>
> Any suggestions?
>
> Andre
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From joachim at buechse.de  Mon Jun 19 05:54:49 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 13:54:49 +0200
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de>

This is most likely due to a problem with lock files. If you have  
downloaded the binaries of 2.17 rxtx will try to create non-standard  
lock files on OSX. We have since changed the code to use OSX device  
locking - however the binaries have not been updated yet. The 2.18  
release fixing this issue is due shortly.

Regards,
Joachim

On 19.06.2006, at 01:33, Andr?-John Mas wrote:

> Hi,
>
> I am have a program that I wrote in Java to communicate with a
> Bluetooth GPS device. I am
> trying to get this working on my Mac, but I keep getting told that:
>
> gnu.io.PortInUseException: Unknown Application
>
> but
>
> portIdentifier.isCurrentlyOwned()
>
> returns false and when I do lsof on the device I am trying to connect
> to, I see no application
> using it. As the same time if I go to the command line and use
> minicom I have no issues. The
> exception happens with this call:
>
> CommPort commPort = portIdentifier.open(null,0);
>
> Any suggestions?
>
> Andre
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From joachim at buechse.de  Mon Jun 19 06:44:27 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 14:44:27 +0200
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <4490A60A.9090305@sun.com>
References: <4490A60A.9090305@sun.com>
Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>

Hello Paul,

I just downloaded the "generic" javax.comm version now available. A  
first check indicates, that it was compiled with a JDK 1.4 javac  
without setting the target classfile version. In other words in can  
not be loaded by 1.1-1.3 VMs (or PersonalJava).

Do you see any chance to provide a version compiled with classfile  
format 45.3 (ie JVM1.1).

---
52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose  
javax.comm.SerialPort | head -5
Compiled from "SerialPort.java"
public abstract class javax.comm.SerialPort extends javax.comm.CommPort
   SourceFile: "SerialPort.java"
   minor version: 0
   major version: 48
---

Best regards,
Joachim


On 15.06.2006, at 02:12, Paul Klissner wrote:

> Hello RxTx community,
>
> I finally think I have a compromise in place that will stand in the  
> gap.
>
> If you go to http://www.sun.com and search for javax.comm, you'll
> get taken to a download page, where now users can get a copy of the
> comm.jar file out of 2.0.3, along with just a license and a README.
>
> I trust this will suffice until such time as RxTx decided to implement
> their own java classes or we can get a JSR going to mitigate some
> of the problems (the readme in the comm.jar 2.0.3 zip file
> contains my thoughts on that).
>
> Thanks,
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Mon Jun 19 09:11:45 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Mon, 19 Jun 2006 11:11:45 -0400
Subject: [Rxtx] Examples added to Wiki
Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

I have added a couple of examples to the Wiki:

http://rxtx.qbang.org/wiki/index.php/Examples

If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :)

Andre



From paul.klissner at sun.com  Mon Jun 19 10:42:47 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Mon, 19 Jun 2006 09:42:47 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>
References: <4490A60A.9090305@sun.com>
	<03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>
Message-ID: <4496D407.1090609@sun.com>

Joachim Buechse wrote:
> Hello Paul,
> 
> I just downloaded the "generic" javax.comm version now available. A  
> first check indicates, that it was compiled with a JDK 1.4 javac  
> without setting the target classfile version. In other words in can  
> not be loaded by 1.1-1.3 VMs (or PersonalJava).
> 
> Do you see any chance to provide a version compiled with classfile  
> format 45.3 (ie JVM1.1).
> 
> ---
> 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose  
> javax.comm.SerialPort | head -5
> Compiled from "SerialPort.java"
> public abstract class javax.comm.SerialPort extends javax.comm.CommPort
>    SourceFile: "SerialPort.java"
>    minor version: 0
>    major version: 48
> ---

I cannot promise when I can do that. Since we thought we were done
with javax.comm, the build environment got moved around, and right
now it doesn't even compile in it's new home.  I tried and it was
not cooperative at all. I was never impressed with that workspace
(in fact far far from it, it is a mess, which is why I migrated 3.0
to ant and never looked back).  It will take some real determination
for me to rebuild it, and frankly, right now I'm swamped.  If I can
find a bit of time over the next few weeks to do it, and it isn't
too bad an ordeal, I will.

Posting that will give me an excuse to post javax.comm 3.0, Update 2 as
well, while I'm working with the people who put content up on our
download center.  The only reason for a new update to 3.0 is that
I've changed the distribution to provide ispt (Interactive Serial
Port Tool), such that it can be launched as soon as the zip file
is unpacked, via a provided script.  ISPT is a command line
interactive tool for  manipulating one or two serial port,
sending data, managing events, etc... I've found it to be so useful
for doing certain kinds of validation  that I assume others will
find it useful to.  ISPT is already in 3.0u1, but one has to set
up their own classpath and launch it and since few people ever read
the documentation most won't know about it.  I've added the ability
to set stop bits and parity since 3.0u1 too.  But I digress.

Paul


From joachim at buechse.de  Mon Jun 19 11:01:28 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 19:01:28 +0200
Subject: [Rxtx] load mechanism of 2.0x
Message-ID: <CFD1440C-21AA-4D3B-9EA6-270D0FF9D6FC@buechse.de>

Good day,

I am trying to figure out, how the 2.0x distribution interacts with  
Suns implementation of javax.comm.CommPortIdentifier.

1) Apparently one can put javax.comm.properties in {java.home}/lib
2) The javax.comm package also reacts to -Djavax.comm.properties="...."

Looking at the javap output it also seems like CommPortIdentifier  
tries to find it's jar file and load the properties from there??


What I'm really looking for is a solution that allows using  
javax.comm with RXTX without modifying the VM installation. So I  
would prefer not to use 1) but I can't figure out how to use 2).

Any hints are welcome,
Joachim



From bob_tai2001 at yahoo.com  Mon Jun 19 15:00:35 2006
From: bob_tai2001 at yahoo.com (Bob Tai)
Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT)
Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place
	to start?
Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>

Hi, 

I got  rxtx Windows 2000 installed.  I did not use the
"best" way ... I just follow the insturuction and dump
the necessary files into the jre... I know it's "best"
idea, I got lazy didn't want to change my setting to
my Eclipse and classpath.

I was able to modify SimpleWrite.java to print on my
AddMaster serial printer.  I think I am ready to code!
But I need to make sure I can handle exceptions and so
on.  I notice the \samples\NullDriver\  has two files
seems to have some of the require method done, should
I start coding from those file?  I like the idea it
has the "time out" and basic exceptions done.   I am
slowly digging into the samples, but if you think any
of the code from Sun is good to checkout please let me
know.

btw, http://rxtx.qbang.org/wiki/index.php/Examples/
was very helpful, wish there are more examples.

thank you,

    Bob


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Mon Jun 19 15:55:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT)
Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good
 place to start?
In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>
References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606191542260.14139@www>

> I am
> slowly digging into the samples, but if you think any
> of the code from Sun is good to checkout please let me
> know.
>

I think NullDriver.java was an example stub driver for implementing 
something like rxtx.  It has been a while.  Unless they have been updated, 
you will find the examples are very dated.  You can look at how they use 
the port but avoid the GUI and hard coded variables (number of ports for 
instance).

There was no Swing and nobody knew what requirements today's compilers 
would make on code.  The examples worked fine with jdk 1.1 but times have 
changed.

--
Trent Jarvi
tjarvi at qbang.org


From tropicsu at hotmail.com  Mon Jun 19 19:49:08 2006
From: tropicsu at hotmail.com (Yoke K)
Date: Tue, 20 Jun 2006 01:49:08 +0000
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
Message-ID: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>

An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/fa588f00/attachment-0002.html

From ajmas at sympatico.ca  Mon Jun 19 21:14:37 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Mon, 19 Jun 2006 23:14:37 -0400
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>
References: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>
Message-ID: <CA22AB2A-5712-458B-9984-68477C6042AF@sympatico.ca>

Regarding the PortInUseException, I had a similar issue and got
this response from the mailing list:

   http://mailman.qbang.org/pipermail/rxtx/Week-of- 
Mon-20060619/062838.html

Andre
On 19-Jun-06, at 21:49 , Yoke K wrote:

> Hi Andre, Joachim
>
> I have tried using /dev/tty.usbserial and also /dev/cu.usbserial  
> and it also reported error as  "gnu.io.PortInUseException".
>
> The iTegno modem works in windows environment. As I moving around  
> using my ibook and I need to get it work on MAC OS as well.
>
> >> INFO: SMSLib API for Java / v1.2.2
> >> INFO: Using port: /dev/tty.usbserial @ 115200 baud.
> >> INFO: JRE Version: 1.5.0_06
> >> INFO: JRE Impl Version: 1.5.0_06-64
> >> INFO: O/S: Mac OS X / ppc / 10.4.6
> >> INFO: Using Wavecom (Generic) AT handler.
>
> SendMessage(): Send a message.
> Using SMSLib API for Java v1.2.2
>
> Connecting ..... :
> >> INFO: CSerialDriver(): Connecting...
> Experimental: JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version = RXTX-2.1-7
> >> INFO: CSerialDriver(): Disconnecting...
> gnu.io.PortInUseException: Unknown Application
> at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354)
> at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1)
> at org.smslib.CService.connect(CService.java:197)
> at SendMessage.main(SendMessage.java:38)
>
> Thanks.
>
> - Jon
>
>
>
>
> ====================
>
> Hello Jon,
>
> From OSX's standpoint a symbolic link is not a device (as far as I
> know). What stops you from using tty.usbserial? Did you try hard-
> linking?
>
> Regards,
> Joachim
>
>
>
> From:  "Yoke K" <tropicsu at hotmail.com>
> To:  rxtx at qbang.org
> Subject:  RXTX-2.1-7 / MAC OS X / NoSuchPortException
> Date:  Sat, 17 Jun 2006 15:32:48 +0000
> >Hi,
> >
> >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to
> >work with MAC OS X.
> >I am using iTegno 3000 - USB GPRS Modem.
> >
> >Files in /dev and a symbolic link as follows:
> >
> >crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
> >crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
> >lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->
> >tty.usbserial
> >
> >In my SendMessage.java, I have this line:
> >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
> >
> >Appreciate any help ?
> >
> >- Jon
> >
> >
> >Errors as follows:
> >
> >>>INFO: SMSLib API for Java / v1.2.2
> >>>INFO: Using port: /dev/ttyS1 @ 56000 baud.
> >>>INFO: JRE Version: 1.5.0_06
> >>>INFO: JRE Impl Version: 1.5.0_06-64
> >>>INFO: O/S: Mac OS X / ppc / 10.4.6
> >>>INFO: Using Wavecom (Generic) AT handler.
> >
> >SendMessage(): Send a message.
> >  Using SMSLib API for Java v1.2.2
> >
> >Connecting ..... :
> >>>INFO: CSerialDriver(): Connecting...
> >Experimental:  JNI_OnLoad called.
> >Stable Library
> >=========================================
> >Native lib Version = RXTX-2.1-7
> >Java lib Version   = RXTX-2.1-7
> >>>INFO: CSerialDriver(): Disconnecting...
> >gnu.io.NoSuchPortException
> >        at
> >gnu.io.CommPortIdentifier.getPortIdentifier 
> (CommPortIdentifier.java:218)
> >        at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
> >        at org.smslib.CService.connect(CService.java:197)
> >        at SendMessage.main(SendMessage.java:38)
> >
> >_________________________________________________________________
> >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
> >
>
> Find love online with MSN Personals
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Tue Jun 20 02:35:24 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 10:35:24 +0200
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>

Hello everybody,

I have been fighting a bit with the javax.comm version of RXTX the  
last days. I am working on the README .OSX now and try to figure out  
which should be the "suggested" installation.

The facts:
------

- the "generic" comm.jar version of javax.comm which has been made re- 
available tries to load com.sun.comm.SolarisDriver
- this classname can be overridden ONLY by putting a file  
javax.comm.properties in {java.home}/lib
- if it is not overridden and SolarisDriver.class is not found  
CommPortIdentifier will be disfunctional (in particual it is not  
possible to add CommPort's via CommPortIdentifier.add).
- the license distributed with comm.jar does not allow the  
modification/addition of classes in javax.comm (however no mention of  
com.sun...)


What really bothers me is to suggest putting this config file in the  
"global" vm installation. This is particularly ugly on the Mac as  
there are several VM installations and the file may be forgotten.  
Additionally it may create versioning problems. I prefer an  
installation where all files are local to the application (even  
comm.jar).

In my opinion the ideal situation would be:
------

1) The author of a program compiles against javax.comm.
2a) For platforms supported by Sun the user is free to use the 3.0  
comm.jar download from Sun
2b) For platforms not supported by Sun the user adds RXTXComm.jar to  
the classpath of the application (and librxtxSerial.jnilib to the  
application directory). Also he will need the 2.0.3 generic comm.jar  
from Sun.
3) Nobody messes with the global VM installation.

Of course 2a) and 2b) could be handled by the author of the program  
via an appropriate installer. The author could also decide to always  
use RXTX and include the generic javax.comm classes as well as the  
RXTX classes in his application jar. [If he further uses an explicit  
call to System.load() he may even include the jnilib(s) in the jar,  
extract it (based on the platform name) at runtime to a temp file and  
load it from there.]


Suggested solution:
------

We only need to put the following class in the classpath BEFORE Suns  
comm.jar

   package com.sun.comm;
   public class SolarisDriver extends gnu.io.RXTXCommDriver {
   }

This is not "the pure art" (TM). It depends on an implementation  
detail of the generic driver. However, so does the  
javax.comm.properties file - as we have seen when Sun released 3.0.  
It has the following advantages:

- The "generic" javax.comm implementation will happily load this  
class as its primary driver.
- No javax.comm.properties file is required.
- This does not violate the javax.comm license agreement as there is  
no mention of the "com.sun.comm" package in this license agreement at  
all.
- Authors packaging comm.jar with their application can strip out all  
com.sun.comm classes from comm.jar


Please comment!

Joachim



From joachim at buechse.de  Tue Jun 20 02:50:36 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 10:50:36 +0200
Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar
Message-ID: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>

There has been some discussions about the best way to install RXTX  
and where to place files.

I suggest that,

- we include the native libraries for the most common operating  
systems (in a special version of) RXTXcomm.jar
- we add loader code which tries to extract and load the platform  
specific binary at runtime
- on failure the current mechanism remains as a fallback

Wether the current mechanism should have priority (ie loadLibrary  
before load) remains to be discussed.


The advantages of this solution are
  - users of RXTX do not need to worry about java/platform specific  
file placement.
  - authors of applications may fully merge RXTX into their  
application jar (which provides a double-clickable application for  
Windows and OSX, Linux?).

Please comment,
Joachim

PS: Of course the suggested solution is already possible today,  
however relatively few programmers know how to correctly extract a  
binary resource file via the class loader and load it as a native  
library.


From tjarvi at qbang.org  Tue Jun 20 03:58:12 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT)
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
Message-ID: <Pine.LNX.4.61.0606200335190.14139@www>

> 2a) For platforms supported by Sun the user is free to use the 3.0
> comm.jar download from Sun
> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to
> the classpath of the application (and librxtxSerial.jnilib to the
> application directory). Also he will need the 2.0.3 generic comm.jar
> from Sun.

As there are no plans to support CommAPI 3.0 due to the limitations in its 
implementation mentioned before, I would not recommend projects use Sun's 
3.0 comm.jar.  They will lose the freedom to chose their low level 
implementation by being locked into vendor specific modifications.

Projects should chose between platform neutrality in CommAPI 2.0 and 
reduced platform neutrality in commapi 3.0.  Projects should also strongly 
consider the fact that the 2.0 comm.jar targets only a reduced number of 
JVMs.

Projects can go with rxtx 2.1 or other packages but should probably only 
consider using Sun CommAPI with rxtx if they did so in the past.  They 
should take steps to no longer depend upon this option being available.

> Suggested solution:
> ------
>
> We only need to put the following class in the classpath BEFORE Suns
> comm.jar
>
>   package com.sun.comm;
>   public class SolarisDriver extends gnu.io.RXTXCommDriver {
>   }
>
> This is not "the pure art" (TM). It depends on an implementation
> detail of the generic driver. However, so does the
> javax.comm.properties file - as we have seen when Sun released 3.0.
> It has the following advantages:
>
> - The "generic" javax.comm implementation will happily load this
> class as its primary driver.
> - No javax.comm.properties file is required.
> - This does not violate the javax.comm license agreement as there is
> no mention of the "com.sun.comm" package in this license agreement at
> all.
> - Authors packaging comm.jar with their application can strip out all
> com.sun.comm classes from comm.jar
>

I would not encourage people to place packages in the com.sun.comm 
namespace.  Authors using Sun's commapi 2.0 should just realize it is 
greatly limited in practical utility and consider moving to something that 
isn't being rescued from EOL.

The primary focus of this release is projects previously depending upon 
Sun CommAPI + RXTX.  There are no plans at this time to provide future 
support in this arrangement due to technical incompatabilities we have no 
control over in commapi 3.0 and limited utility of Sun's generic comm.jar 
in commapi 2.0 offered.  Projects should be aware of this so they can make 
appropriate plans.

--
Trent Jarvi
tjarvi at qbang.org


From paul.klissner at sun.com  Tue Jun 20 05:24:00 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Tue, 20 Jun 2006 04:24:00 -0700
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
In-Reply-To: <Pine.LNX.4.61.0606200335190.14139@www>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
	<Pine.LNX.4.61.0606200335190.14139@www>
Message-ID: <4497DAD0.10803@sun.com>

Trent Jarvi wrote:
>> 2a) For platforms supported by Sun the user is free to use the 3.0
>> comm.jar download from Sun
>> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to
>> the classpath of the application (and librxtxSerial.jnilib to the
>> application directory). Also he will need the 2.0.3 generic comm.jar
>> from Sun.
> 
> As there are no plans to support CommAPI 3.0 due to the limitations in its 
> implementation mentioned before, I would not recommend projects use Sun's 
> 3.0 comm.jar.  They will lose the freedom to chose their low level 
> implementation by being locked into vendor specific modifications.
> 
> Projects should chose between platform neutrality in CommAPI 2.0 and 
> reduced platform neutrality in commapi 3.0.  Projects should also strongly 
> consider the fact that the 2.0 comm.jar targets only a reduced number of 
> JVMs.

Well, that's a little ambiguous because the API is the same
either way.  We're talking about Sun's implementation vs.
other implementations.
> 
> Projects can go with rxtx 2.1 or other packages but should probably only 
> consider using Sun CommAPI with rxtx if they did so in the past.  They 
> should take steps to no longer depend upon this option being available.

3.0 is platform centric because there is a need to add some
platform awareness to Sun's implementation, and the choices
for how to do that are limited by the constraints of the API,
as mentioned in the javax.comm 2.0.3 comm.jar download's README.

I am really advocating getting a JSR open (http://www.jcp.org)
to push a new comm API that is more pluggable, platform neutral
and addresses some of the deficiencies of the current API. Then
we can achieve the optimal of platform neutrality while
simulataneously allowing the API to flexibly adapt to
heterogeneous environments.

This is not a question of attitude, this is an issue of resources,
time and commitment.  The current owners of javax.comm within
Sun would like nothing better than to see the ideal reached for
the API and a model that will extend well beyond the foreseeable
future and work for the industry overall.



> 
>> Suggested solution:
>> ------
>>
>> We only need to put the following class in the classpath BEFORE Suns
>> comm.jar
>>
>>   package com.sun.comm;
>>   public class SolarisDriver extends gnu.io.RXTXCommDriver {
>>   }
>>
>> This is not "the pure art" (TM). It depends on an implementation
>> detail of the generic driver. However, so does the
>> javax.comm.properties file - as we have seen when Sun released 3.0.
>> It has the following advantages:
>>
>> - The "generic" javax.comm implementation will happily load this
>> class as its primary driver.
>> - No javax.comm.properties file is required.
>> - This does not violate the javax.comm license agreement as there is
>> no mention of the "com.sun.comm" package in this license agreement at
>> all.
>> - Authors packaging comm.jar with their application can strip out all
>> com.sun.comm classes from comm.jar
>>
> 
> I would not encourage people to place packages in the com.sun.comm 
> namespace.  Authors using Sun's commapi 2.0 should just realize it is 
> greatly limited in practical utility and consider moving to something that 
> isn't being rescued from EOL.
> 
> The primary focus of this release is projects previously depending upon 
> Sun CommAPI + RXTX.  There are no plans at this time to provide future 
> support in this arrangement due to technical incompatabilities we have no 
> control over in commapi 3.0 and limited utility of Sun's generic comm.jar 
> in commapi 2.0 offered.  Projects should be aware of this so they can make 
> appropriate plans.

Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86,
or need the powerful portmapping features in javax.com 3.0, or would like to
acquire the Interactive Serial Port Test utility.

-Paul


From paul.klissner at sun.com  Tue Jun 20 05:33:44 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Tue, 20 Jun 2006 04:33:44 -0700
Subject: [Rxtx] Suggested installation RXTX 2.0x...
In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
Message-ID: <4497DD18.70207@sun.com>

Joachim Buechse wrote:
> Hello everybody,
> 
> I have been fighting a bit with the javax.comm version of RXTX the  
> last days. I am working on the README .OSX now and try to figure out  
> which should be the "suggested" installation.
> 
> The facts:
> ------
> 
> - the "generic" comm.jar version of javax.comm which has been made re- 
> available tries to load com.sun.comm.SolarisDriver
> - this classname can be overridden ONLY by putting a file  
> javax.comm.properties in {java.home}/lib
> - if it is not overridden and SolarisDriver.class is not found  
> CommPortIdentifier will be disfunctional (in particual it is not  
> possible to add CommPort's via CommPortIdentifier.add).
> - the license distributed with comm.jar does not allow the  
> modification/addition of classes in javax.comm (however no mention of  
> com.sun...)
> 
> 
> What really bothers me is to suggest putting this config file in the  
> "global" vm installation. This is particularly ugly on the Mac as  
> there are several VM installations and the file may be forgotten.  
> Additionally it may create versioning problems. I prefer an  
> installation where all files are local to the application (even  
> comm.jar).
> 
> In my opinion the ideal situation would be:
> ------
> 
> 1) The author of a program compiles against javax.comm.
> 2a) For platforms supported by Sun the user is free to use the 3.0  
> comm.jar download from Sun
> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to  
> the classpath of the application (and librxtxSerial.jnilib to the  
> application directory). Also he will need the 2.0.3 generic comm.jar  
> from Sun.
> 3) Nobody messes with the global VM installation.
> 
> Of course 2a) and 2b) could be handled by the author of the program  
> via an appropriate installer. The author could also decide to always  
> use RXTX and include the generic javax.comm classes as well as the  
> RXTX classes in his application jar. [If he further uses an explicit  
> call to System.load() he may even include the jnilib(s) in the jar,  
> extract it (based on the platform name) at runtime to a temp file and  
> load it from there.]
> 

This was how the Sun implementation originated (I did not write
that code).  I completely agree, and I fixed the whole conf file
locating mechanism in 3.0 to avoid the problems youmentioned.
However, I was unaware of how RxTx was using Sun's implementation,
so I didn't architect it in such a way as to avoid namespace pollution
in the native space in for the backend provider.  In retrospect,
I should have done that differently just as a design principle,
but at this point I don't have the spare cycles to get that all
re-factored.  Further, I'm loathe to do it, because the whole
thing will still be an under-the-hood hack due to the constraints
of the API itself.

Paul





From brian at mbari.org  Tue Jun 20 10:23:54 2006
From: brian at mbari.org (Brian Schlining)
Date: Tue, 20 Jun 2006 09:23:54 -0700
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>


Hi Joachim,

> There has been some discussions about the best way to install RXTX
> and where to place files.
>
> I suggest that,
>
> - we include the native libraries for the most common operating
> systems (in a special version of) RXTXcomm.jar
> - we add loader code which tries to extract and load the platform
> specific binary at runtime
> - on failure the current mechanism remains as a fallback

I like your suggestion. However, my understanding is that in general  
the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH  
(Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to  
be loaded by the JVM. The alternative is to point to your native lib  
directory using -Djava.library.path=/my/dir/with/native/libs when you  
launch the JVM. So, I'm very interested to know how you're planning  
to work around this.

> PS: Of course the suggested solution is already possible today,
> however relatively few programmers know how to correctly extract a
> binary resource file via the class loader and load it as a native
> library.

So how do you use it to dynamically load a native lib? I've read that  
you can't really modify the java.library.path after the JVM has been  
launched. (http://forum.java.sun.com/thread.jspa? 
threadID=627890&tstart=90)

Thanks

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0011.html

From joachim at buechse.de  Tue Jun 20 09:20:29 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 17:20:29 +0200
Subject: [Rxtx] 2.0x in sync with 2.1x
Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>

I have added most of the changes from the 2.1 branch to the 2.0 branch.

This includes
  - correction of illegal javadoc comments
  - implementation errors in handling of Thread.interrupt in  
RXTXPort.java
  - MacOS X locking without lock files/special user groups
  - XCode project which builds a universal binary library
  - updated documentation for OSX

I have done some minimal testing (only G4).
[Trent: there are still some changes you made for specific baud  
rates. I will not sync this, as I can not test them. From my  
perspective we are ready for 2.08/2.18]

The updated documentation can be found in the file README.OSX. Here  
it is:

------------------------ Required files -----------------------

To use or compile RXTX 2.0.x you need to downlad the "generic"  
version (2.0.3)
of the javax.comm implementation from Sun. The zip you download  
contains an
archive comm.jar which is required:

- To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar

- To run the app you will need comm.jar in the classpath or in  
{java.lib.path}


------------------------ Installation on MacOSX -----------------------

WARNING: Please read this section until the end.

---
Preparation
---

You may want to spare your users the burden of modifying the global VM
installation. OSX has several different VM versions installed by  
default and
regular users will be unable to figure out which version will load your
application.

If you provide the class

package com.sun.comm;
public class SolarisDriver extends gnu.io.RXTXCommDriver {
}

and make sure, that it is present in the classpath before Suns  
"generic" comm.jar
your users can skip the following step:

Create a file named
    javax.comm.properties
in the directory
    /System/Library/Frameworks/JavaVM.framework/Home/lib/
which contains (only) the following line (no leading space):
    Driver=gnu.io.RXTXCommDriver



----
The unsafe way of using RXTX on OS X:
----

RXTX can be installed by putting the files
   libSerial.jnilib
   RXTXcomm.jar
   comm.jar
into the folder
   /Library/Java/Extensions

This is NOT RECOMMENDED as it creates versioning conflicts among  
applications.
However you may be forced to install it this way if an application  
was written
for Windows or Linux, requires RXTX and you are not able to change  
its starter.


----
The safe way of using RXTX on OS X:
----

Make sure that you have no (older) version of RXTX installed in
   /Library/Java/Extensions
   /System/Library/Java/Extensions
   /usr/lib/java

Put
   libSerial.jnilib
in the directory of the application (the JavaVM will find it there). Add
   RXTXComm.jar
   comm.jar
to the application classpath or include the classes in the  
application jar.
(Some applications already include the RXTX classes in their  
application jar,
in which case only the file libSerial.jnilib is required).


----
History
----

Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation  
of lockfiles
required special permissions for the user executing an application  
based on RXTX.
To simplify the setup RXTX came with an installer modifying group  
permissions
and installing RXTX in the global location /Library/Java/Extensions.  
However
this was prune to versioning conflicts and is no longer recommended.

--------------------- Build instructions for OSX XCode  
-------------------

contributed by Joachim Buechse <joachim at buechse.de>
original version by Dmitry Markman <dmarkman at mac.com>

System requirements for building:
MacOSX 10.4
XCode 2.3

   open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj
   choose libSerial.jnilib target
   build

After the build you will find RXTXcomm.jar and libSerial.jnilib files  
in the
directory build/Development.

In case you can't find RXTXcomm.jar build the RXTXcomm target manually.
In case of (serious) problems feel free to contact joachim at buechse.de .



From tjarvi at qbang.org  Tue Jun 20 22:01:45 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT)
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
Message-ID: <Pine.LNX.4.61.0606202127270.14139@www>

> ---
> Preparation
> ---
>
> You may want to spare your users the burden of modifying the global VM
> installation. OSX has several different VM versions installed by
> default and
> regular users will be unable to figure out which version will load your
> application.
>
> If you provide the class
>
> package com.sun.comm;
> public class SolarisDriver extends gnu.io.RXTXCommDriver {
> }
>
> and make sure, that it is present in the classpath before Suns
> "generic" comm.jar
> your users can skip the following step:

Hi Joachim

With regards to the above, I have not seen that we have Sun's OK to 
promote that.  I'm not very comfortable with the distribution 
documentation advocating this without Sun agreeing.

I see your point but I'd rather not actively promote putting classes in 
Sun's namespace without permission if you don't mind.  This isn't about 
what is in a license.

I'll go through the code tomorrow night.  It was a late night at work 
today.  There is also a w32 fix comming for people opening and closing 
multiple ports.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Wed Jun 21 01:56:45 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 21 Jun 2006 09:56:45 +0200
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <Pine.LNX.4.61.0606202127270.14139@www>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
	<Pine.LNX.4.61.0606202127270.14139@www>
Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>

Hello Trent,

I guess we will not get an explicit OK from Sun for such a hack. I  
think Paul has made it pretty clear, that he does not have the  
resources to modify the 2.x or 3.x code for the needs of RXTX. I'm  
not thrilled but OK with the current API. Hence I dont agree with  
Paul's idea to start a new JSR to fix the implementation - but that's  
mainly because I dont have the time to push it. According to their  
Readme Sun sees no business case in having cross platform support for  
javax.comm - that is sad but it's none of my business. However I  
prefer to program versus javax.comm in my projects as this gives an  
advanced user the chance to exchange the provider without access to  
the code.

I interpret Pauls reponse to my original "Request for comment" as a  
quiet acceptance of the hack I propose (he did respond, but not at  
all to the sun.comm namespace suggestion). This is certainly not  
something we should put into RXTXcomm.jar but hinting a work around  
for implementation errors should be allowed. That's why I've choosen  
the wording "You may want to spare" and "If you provide". The company  
I worked for has choosen similar hacks for years to fix bugs in swing  
for JDK1.1 applications. Those hacks were usually included in their  
own swingpatch.jar.

Having said all that - I do not take it as an insult if you remove  
the paragraph from the Readme. I appreciate that you notified me  
before. It would be interesting to hear some more opinions from the  
list members...

Best regards,
Joachim


On 21.06.2006, at 06:01, Trent Jarvi wrote:

>> ---
>> Preparation
>> ---
>>
>> You may want to spare your users the burden of modifying the  
>> global VM
>> installation. OSX has several different VM versions installed by
>> default and
>> regular users will be unable to figure out which version will load  
>> your
>> application.
>>
>> If you provide the class
>>
>> package com.sun.comm;
>> public class SolarisDriver extends gnu.io.RXTXCommDriver {
>> }
>>
>> and make sure, that it is present in the classpath before Suns
>> "generic" comm.jar
>> your users can skip the following step:
>
> Hi Joachim
>
> With regards to the above, I have not seen that we have Sun's OK to
> promote that.  I'm not very comfortable with the distribution
> documentation advocating this without Sun agreeing.
>
> I see your point but I'd rather not actively promote putting  
> classes in
> Sun's namespace without permission if you don't mind.  This isn't  
> about
> what is in a license.
>
> I'll go through the code tomorrow night.  It was a late night at work
> today.  There is also a w32 fix comming for people opening and closing
> multiple ports.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Wed Jun 21 02:03:33 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 21 Jun 2006 10:03:33 +0200
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
	<6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
Message-ID: <BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>

See System.load(String) [it's also mentioned under the URL you posted].

Regards,
Joachim


On 20.06.2006, at 18:23, Brian Schlining wrote:

> So how do you use it to dynamically load a native lib? I've read  
> that you can't really modify the java.library.path after the JVM  
> has been launched. (http://forum.java.sun.com/thread.jspa? 
> threadID=627890&tstart=90)
>
> Thanks
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From baris.ozkan at elikasu.com.tr  Wed Jun 21 07:58:06 2006
From: baris.ozkan at elikasu.com.tr (Baris)
Date: Wed, 21 Jun 2006 16:58:06 +0300
Subject: [Rxtx] RS 232 ..additional parameters
Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>

Hi,
 
Currently i am developing an application that requires to connect to a
remote rs232 device through  a dialup connection.
 
My problem is that the communication needs several more connection
parameters (i extracted that information from the vendor's dll , listed at
the end of the message)
 
I explored rxtx API and src files and could not find methods to set a
majority  of the parameters.
Am i missing any point or does rxtx is limited to soem standard set of
functionality(e.g. commAPI)? How  is it possible ,if i want to put some
extensions(???) to current rxtx implementation?
 
I am not very good at rs232 programming so excuse me if this message  is
boring one.
 
Thanx
 
Baris Ozkan
 
 
A Listing of Parameters:
 
 
typedef struct _DCB {

DWORD DCBlength; /* sizeof(DCB) */

DWORD BaudRate; /* Baudrate at which running */

DWORD fBinary: 1; /* Binary Mode (skip EOF check) */

DWORD fParity: 1; /* Enable parity checking */

DWORD fOutxCtsFlow:1; /* CTS handshaking on output */

DWORD fOutxDsrFlow:1; /* DSR handshaking on output */

DWORD fDtrControl:2; /* DTR Flow control */

DWORD fDsrSensitivity:1; /* DSR Sensitivity */

DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */

DWORD fOutX: 1; /* Enable output X-ON/X-OFF */

DWORD fInX: 1; /* Enable input X-ON/X-OFF */

DWORD fErrorChar: 1; /* Enable Err Replacement */

DWORD fNull: 1; /* Enable Null stripping */

DWORD fRtsControl:2; /* Rts Flow control */

DWORD fAbortOnError:1; /* Abort all reads and writes on Error */

DWORD fDummy2:17; /* Reserved */

WORD wReserved; /* Not currently used */

WORD XonLim; /* Transmit X-ON threshold */

WORD XoffLim; /* Transmit X-OFF threshold */

BYTE ByteSize; /* Number of bits/byte, 4-8 */

BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */

BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */

char XonChar; /* Tx and Rx X-ON character */

char XoffChar; /* Tx and Rx X-OFF character */

char ErrorChar; /* Error replacement char */

char EofChar; /* End of Input character */

char EvtChar; /* Received Event character */

WORD wReserved1; /* Fill for now. */

} DCB, *LPDCB;

typedef struct _COMMTIMEOUTS {

DWORD ReadIntervalTimeout; /* Maximum time between read chars. */

DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */

DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */

DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */

DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */

} COMMTIMEOUTS,*LPCOMMTIMEOUTS;

dcb.fOutX = FALSE;

dcb.fInX = FALSE;

dcb.fOutxCtsFlow = FALSE;

dcb.fBinary = TRUE;

dcb.fRtsControl = RTS_CONTROL_ENABLE;

SetCommState(hComm , &dcb ); 

COMMTIMEOUTS commTimeOut;

GetCommTimeouts(hComm, &commTimeOut );

commTimeOut.WriteTotalTimeoutMultiplier = 1; 

commTimeOut.WriteTotalTimeoutConstant = 18; 

// commTimeOut.ReadIntervalTimeout = 28; 

commTimeOut.ReadIntervalTimeout = 0; 

// commTimeOut.ReadTotalTimeoutMultiplier = 184; 

commTimeOut.ReadTotalTimeoutMultiplier = 300; 

// commTimeOut.ReadTotalTimeoutConstant = 1200;

commTimeOut.ReadTotalTimeoutConstant = 1200;

SetCommTimeouts(hComm, &commTimeOut);

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0011.html

From ajmas at sympatico.ca  Wed Jun 21 08:14:26 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Wed, 21 Jun 2006 10:14:26 -0400
Subject: [Rxtx] When is 2.18 planned for?
Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

Just curious as to know if there is a target date for 2.18?

Andre



From brian at mbari.org  Wed Jun 21 09:36:00 2006
From: brian at mbari.org (Brian Schlining)
Date: Wed, 21 Jun 2006 08:36:00 -0700
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
	<6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
	<BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>
Message-ID: <A21C9BC0-7894-4B08-AC82-44E11AB3D461@mbari.org>

Ha!!

I suppose I should read my own postings. ;-)

Thanks
B

On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote:

> See System.load(String) [it's also mentioned under the URL you  
> posted].
>
> Regards,
> Joachim
>
>
> On 20.06.2006, at 18:23, Brian Schlining wrote:
>
>> So how do you use it to dynamically load a native lib? I've read
>> that you can't really modify the java.library.path after the JVM
>> has been launched. (http://forum.java.sun.com/thread.jspa?
>> threadID=627890&tstart=90)

Brian Schlining
Software Engineer
http://www.mbari.org




From ajmas at sympatico.ca  Wed Jun 21 16:41:28 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Wed, 21 Jun 2006 18:41:28 -0400
Subject: [Rxtx] CVS build question
Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X:

 The JCL extension to RxTx requires comm.jar
 If you intend to use RxTx for commapi support comm.jar
 needs to be located in  /System/Library/Frameworks/JavaVM.framework/
  Versions/1.5/Home/lib/ext/comm.jar

I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me.

On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native).

Andre






From tjarvi at qbang.org  Wed Jun 21 18:00:04 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT)
Subject: [Rxtx] CVS build question
In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606211756310.14139@www>

On Wed, 21 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> Is the CVS repository meant to build for gnu.io or javax.comm? I ask 
> this, because I see the following when calling ./configure from MacOS X:
>
> The JCL extension to RxTx requires comm.jar
> If you intend to use RxTx for commapi support comm.jar
> needs to be located in  /System/Library/Frameworks/JavaVM.framework/
>  Versions/1.5/Home/lib/ext/comm.jar
>
> I am wanting to build for the gnu.io package, since I want to jump ahead 
> and see if the changes, intended for 2.18 for MacOS X, work for me.
>
> On a side note /Library/Java/Extensions should be included as a valid 
> search path for the JAR, since this is where Apple recommends placing 
> third party extensions (both Java and native).
>

rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel"
rxtx 2.0 src is obtained with "cvs checkout rxtx-devel"

rxtx 2.1 is a complete package in namespace gnu.io
rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 18:02:23 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT)
Subject: [Rxtx] When is 2.18 planned for?
In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606211800180.14139@www>

On Wed, 21 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> Just curious as to know if there is a target date for 2.18?
>

Hi Andre

"When it is ready" :)

Probably this weekend.  Maybe sooner.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 18:10:18 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT)
Subject: [Rxtx] RS 232 ..additional parameters
In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>
References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>
Message-ID: <Pine.LNX.4.61.0606211805010.14139@www>

On Wed, 21 Jun 2006, Baris wrote:

> Hi,
>
> Currently i am developing an application that requires to connect to a
> remote rs232 device through  a dialup connection.
>
> My problem is that the communication needs several more connection
> parameters (i extracted that information from the vendor's dll , listed at
> the end of the message)
>
> I explored rxtx API and src files and could not find methods to set a
> majority  of the parameters.
> Am i missing any point or does rxtx is limited to soem standard set of
> functionality(e.g. commAPI)? How  is it possible ,if i want to put some
> extensions(???) to current rxtx implementation?
>
> I am not very good at rs232 programming so excuse me if this message  is
> boring one.
>
> Thanx
>

Hi Baris

> typedef struct _DCB {
> typedef struct _COMMTIMEOUTS {

These are all handled in termios.c.  It is possible to add extensions to 
rxtx 2.1.  It may well be that the defaults are the same for the variables 
not covered by the existing API.  You can dump the DCB and COMMTIMEOUTS 
from inside termios.c to compare.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 20:23:30 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT)
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
	<Pine.LNX.4.61.0606202127270.14139@www>
	<789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>
Message-ID: <Pine.LNX.4.61.0606212012210.14139@www>

> I'm
> not thrilled but OK with the current API. Hence I dont agree with
> Paul's idea to start a new JSR to fix the implementation - but that's
> mainly because I dont have the time to push it. According to their
> Readme Sun sees no business case in having cross platform support for
> javax.comm - that is sad but it's none of my business. However I
> prefer to program versus javax.comm in my projects as this gives an
> advanced user the chance to exchange the provider without access to
> the code.

Hi Joachim

With regards to the JSR, I think that would be Doug's call.  The effort I 
put in would have to be on my own time which would not be a great deal.  I 
could help things go smoothly but thats not the same as pushing something 
through.

--
Trent Jarvi
tjarvi at qbang.org



From vt at freehold.crocodile.org  Wed Jun 21 21:05:22 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Wed, 21 Jun 2006 20:05:22 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
Message-ID: <449A08F2.3020106@freehold.crocodile.org>

Hello all,

I know this question may belong to JSR lists, but since all interested 
parties are here, I thought I just ask this question here, again...

A while ago I run into a problem and wrote a rant, here: 
http://servomaster.sourceforge.net/dev/serial-usb.html
At the time of writing I didn't think of adding another possible 
solution - changing the CommAPI specs to support removable devices. 
Apparently, Serial/USB bridges are here to stay, and this issue has to 
be addressed.

Wonder if anything changed since, and any abstractions for supporting 
removable devices made it into current or future Java CommAPI drafts - 
Paul, any comments?

--vt



From joachim at buechse.de  Thu Jun 22 01:59:54 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 22 Jun 2006 09:59:54 +0200
Subject: [Rxtx] CVS build question
In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de>

Hello Andre,

I am not sure how well the configure/make mechanism will work on OSX.  
I know that a while ago some contributors tried to get configure/make  
working on OSX but from comments I found in the readmes this work was  
only partially successfull. For compilation on OSX we have used the  
ProjectBuilder/XCode projects you can find in MACOSX_IDE.

Regarding the  ./configure comment:
RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config  
file javax.comm.properties. The later MUST reside in {java.home}/lib.  
As the two only work together putting comm.jar into  /Library/Java/ 
Extensions  and hence making it available to all current and future  
VM installations will only add to confusion.

Regards,
Joachim

On 22.06.2006, at 00:41, Andre-John Mas wrote:

> Hi,
>
> Is the CVS repository meant to build for gnu.io or javax.comm? I  
> ask this, because I see the following when calling ./configure from  
> MacOS X:
>
>  The JCL extension to RxTx requires comm.jar
>  If you intend to use RxTx for commapi support comm.jar
>  needs to be located in  /System/Library/Frameworks/JavaVM.framework/
>   Versions/1.5/Home/lib/ext/comm.jar
>
> I am wanting to build for the gnu.io package, since I want to jump  
> ahead and see if the changes, intended for 2.18 for MacOS X, work  
> for me.
>
> On a side note /Library/Java/Extensions should be included as a  
> valid search path for the JAR, since this is where Apple recommends  
> placing third party extensions (both Java and native).
>
> Andre
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Thu Jun 22 02:51:05 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 22 Jun 2006 10:51:05 +0200
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449A08F2.3020106@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>

Hello Vadim,

I think that your rant is to the point. However it is a bit like  
saying that Windows is at the source of email degradation and the  
only solution is to have users switch to safer operating systems.

I don't see how javax.comm or RXTX can address the problems you  
mention. Of course it would be super cool if javax.comm could magicly  
find the "matching" usb-device and query it's configuration via the  
usb protocol - however this magic (mapping /dev/xyz to its underlying  
USB device) is not supported by any kernel APIs I am aware of. It  
could be supported via POSSIX ioctl calls but then you should address  
your rant to the POSSIX group...

So for the time beeing it's either up to the virtual comm port driver  
to provide a usefull name under /dev/ or to the user choosing the  
right port to use. One example of a smart(er) com port driver is the  
KDDI driver for OSX, which will create device names like "/dev/ 
cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- 
encoded into the bridge chip. The same driver for windows also has  
some options allowing it in theory to recreate the same COMx every  
time a device is plugged/unplugged.

For most industrial applications however it will be up to the user to  
choose the right port (without getting a lot of help doing so).

Probing serial ports can go wrong, that's right. However any serial  
device developper would be well adviced to implement a basic set of  
Hayes AT modem commands (be it a modem or not). Especially AT I0.  
Anyone failing to do so risks that the users favourite TCP/PPP/FAX  
application or stack will kill the device in short time.

Best regards,
Joachim


On 22.06.2006, at 05:05, Vadim Tkachenko wrote:

> Hello all,
>
> I know this question may belong to JSR lists, but since all interested
> parties are here, I thought I just ask this question here, again...
>
> A while ago I run into a problem and wrote a rant, here:
> http://servomaster.sourceforge.net/dev/serial-usb.html
> At the time of writing I didn't think of adding another possible
> solution - changing the CommAPI specs to support removable devices.
> Apparently, Serial/USB bridges are here to stay, and this issue has to
> be addressed.
>
> Wonder if anything changed since, and any abstractions for supporting
> removable devices made it into current or future Java CommAPI drafts -
> Paul, any comments?
>
> --vt
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From vt at freehold.crocodile.org  Thu Jun 22 13:16:03 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 12:16:03 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
Message-ID: <20060622191603.GA17487@freehold.crocodile.org>

Hello Joachim,

> I think that your rant is to the point. However it is a bit like  
> saying that Windows is at the source of email degradation and the  
> only solution is to have users switch to safer operating systems.

I guess the problem is that the rant itself is obsolete and has to be
updated according to latest developments. At the time of writing there
weren't that many bridges around, and the trend didn't manifest itself as it
does now.

> I don't see how javax.comm or RXTX can address the problems you  
> mention.

I would agree that javax.comm won't be able to address the problem, at least
in the short run. As for RxTx - well, nobody prevents it from being a
superset of CommAPI specification, right? RxTx being the de-facto standard
for quite a few platforms, I'd daresay the standard may follow.

> Of course it would be super cool if javax.comm could magicly find the
> "matching" usb-device and query it's configuration via the usb protocol -
> however this magic (mapping /dev/xyz to its underlying USB device) is not
> supported by any kernel APIs I am aware of. It could be supported via
> POSSIX ioctl calls but then you should address your rant to the POSSIX
> group...

As a matter of fact, my bigger concern is addressing the fact that a serial
device can now be removable. This hasn't been the case before, and it
clearly is now. Regarding the above, well, I guess if we accept this fact,
we also need to accept the fact that we need at least rudimentary means of
identification of a serial device. For the USB case, it would usually be the
vendor/product ID, plus possible serial number - but it is irrelevant what
exactly the identifying information is, as long as it allows to identify the
device.

A paradigm shift is required, this is what I wanted to say. Serial devices
can be removed and replaced, it's now our turn to learn to deal with it.

> Joachim

--vt


From jredman at ergotech.com  Thu Jun 22 13:41:44 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 13:41:44 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
Message-ID: <449AF278.6000903@ergotech.com>


Vadim Tkachenko wrote:
> A paradigm shift is required, this is what I wanted to say. Serial devices
> can be removed and replaced, it's now our turn to learn to deal with it.

The removal if the serial port hardly significantly different from the 
removal of the device attached to the serial port.   Different, 
slightly, but not a "paradigm shift".

And yes, someone could unplug a USB serial device and plug it into a 
different USB port so that it has a different name/number, but they 
could do that with the device itself, move it from com1 to com2.

Am I missing something?

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 13:57:27 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 12:57:27 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449AF278.6000903@ergotech.com>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
Message-ID: <20060622195727.GA20247@freehold.crocodile.org>

On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote:
> 
> Vadim Tkachenko wrote:
> > A paradigm shift is required, this is what I wanted to say. Serial devices
> > can be removed and replaced, it's now our turn to learn to deal with it.
> 
> The removal if the serial port hardly significantly different from the 
> removal of the device attached to the serial port.   Different, 
> slightly, but not a "paradigm shift".
> 
> And yes, someone could unplug a USB serial device and plug it into a 
> different USB port so that it has a different name/number, but they 
> could do that with the device itself, move it from com1 to com2.
> 
> Am I missing something?

Yes, the fact that they could unplug a device A and plug a device B. With
the introduction of the concept of removability, the notion of the serial
port itself is not as important anymore, but the notion of the unique device
identifier is.

Consider a situation: long running system (enterprise HVAC, tens of nodes,
tens of thousands square feet area, hundreds of thousand dollars worth of
equipment being conditioned, can't shut down), serial/usb device fails, is
replaced by an identical device with a different serial #.

A little bit farfetched, but hopefully highlighting the point I'm trying to
make.

> Jim

--vt


From jredman at ergotech.com  Thu Jun 22 14:37:38 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 14:37:38 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>	<20060622191603.GA17487@freehold.crocodile.org>	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
Message-ID: <449AFF92.8080003@ergotech.com>


Vadim Tkachenko wrote:
>>
>> Am I missing something?
> 
> Yes, the fact that they could unplug a device A and plug a device B. With
> the introduction of the concept of removability, the notion of the serial
> port itself is not as important anymore, but the notion of the unique device
> identifier is.

Serial devices are always removable.  I could unplug _serial_ device A 
and plug in _serial_ device B.  We have systems running with two RS485 
ports, one talks to a Modbus PLC network one to a number of drives on a 
proprietary protocol.  If you plug the wrong DB9 into the wrong port the 
application doesn't work.

If you dangle a USB 485 converter on the end of the DB9 you've just 
moved the problem from RS485 to USB, but the problem/effect is the same.

> 
> Consider a situation: long running system (enterprise HVAC, tens of nodes,
> tens of thousands square feet area, hundreds of thousand dollars worth of
> equipment being conditioned, can't shut down), serial/usb device fails, is
> replaced by an identical device with a different serial #.
> 
> A little bit farfetched, but hopefully highlighting the point I'm trying to
> make.

Nothing's changed.  If I had a 4 port ISA board and plugged it into my 
new shiny '386 machine.  I could have com ports 9-12.  If I took a board 
off the shelf and didn't set the jumpers, I would have com ports 3-6.

The problem's the same.  If you replace with identical product then the 
com ports  will be the same - no software changes required.  If you 
replace one piece of hardware with hardware from a different 
manufacturer, then the naming/numbering may change.  You're physically 
changing the system, so may reasonably expect to have to make a software 
change.  RXTX actually handles this situation quite well with the -D 
command line option.  (My experience has generally been that the port 
number depends more on the USB port used than the hardware - so the 
chances are even with a hardware change the port number/name will be the 
same.)

Slightly Off Topic - there is a reason why industrial users will pay a 
premium for continued availability of hardware.  Yes you can mail-order 
a $10 USB converter and it will work, but there's no guarantee that the 
next time you buy the same part number from the same vendor it will be 
the same.  The industrial vendors will charge you $100+ for the same 
item, but it will be the same every time you buy it for the next 5 to 10 
years.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 14:37:19 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 13:37:19 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
Message-ID: <20060622203719.GA22521@freehold.crocodile.org>

Hello again,

And while I'm at it, why don't just say this: give me one good reason to
write 3+ different ways of handling removable devices, one for USB, one for
FireWire, one for serial...

I understand very well that this goes way beyond the scope of RxTx and
CommAPI and will require cooperation between them and javax.usb and whatever
JSR is responsible for FireWire implementation - but the end result is well
worth it. Abstract out and generalize arrival/departure/monitoring/discovery
API, provide protocol specific extensions for each, live happily ever after.

--vt


On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote:
> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote:
> > 
> > Vadim Tkachenko wrote:
> > > A paradigm shift is required, this is what I wanted to say. Serial devices
> > > can be removed and replaced, it's now our turn to learn to deal with it.
> > 
> > The removal if the serial port hardly significantly different from the 
> > removal of the device attached to the serial port.   Different, 
> > slightly, but not a "paradigm shift".
> > 
> > And yes, someone could unplug a USB serial device and plug it into a 
> > different USB port so that it has a different name/number, but they 
> > could do that with the device itself, move it from com1 to com2.
> > 
> > Am I missing something?
> 
> Yes, the fact that they could unplug a device A and plug a device B. With
> the introduction of the concept of removability, the notion of the serial
> port itself is not as important anymore, but the notion of the unique device
> identifier is.
> 
> Consider a situation: long running system (enterprise HVAC, tens of nodes,
> tens of thousands square feet area, hundreds of thousand dollars worth of
> equipment being conditioned, can't shut down), serial/usb device fails, is
> replaced by an identical device with a different serial #.
> 
> A little bit farfetched, but hopefully highlighting the point I'm trying to
> make.
> 
> > Jim
> 
> --vt
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx


From jredman at ergotech.com  Thu Jun 22 15:13:49 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 15:13:49 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>	<20060622191603.GA17487@freehold.crocodile.org>	<449AF278.6000903@ergotech.com>	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
Message-ID: <449B080D.9080208@ergotech.com>


Vadim Tkachenko wrote:
> Hello again,
> 
> And while I'm at it, why don't just say this: give me one good reason to
> write 3+ different ways of handling removable devices, one for USB, one for
> FireWire, one for serial...

You don't, they're all the same "I have lost communication with my 
serial device".

The only thing you could really do is improve error reporting by knowing 
the exact sub-system.  ("Device X which is/was attached to USB port Y is 
no longer functioning, please check the USB ports, the device, the 
cables and anything else you can think of that may be a cause of 
failure.")  That just requires an intelligent description of the port.

> I understand very well that this goes way beyond the scope of RxTx and
> CommAPI and will require cooperation between them and javax.usb and whatever
> JSR is responsible for FireWire implementation - but the end result is well
> worth it. Abstract out and generalize arrival/departure/monitoring/discovery
> API, provide protocol specific extensions for each, live happily ever after.

There's a huge list of pseudo-serial devices each with a different set 
of requirements, Bluetooth, RFC 2217, a host of proprietary systems, 
etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I 
have no clue how you'd implement them in a general/cross platform sense.

You haven't convinced me (and only me, others may see something that I 
don't, I'm not speaking for them) that this mechanism can be implemented 
in any practical sense.  That is, that the implementation could be wide 
enough to be consider generally available in RXTX regardless of the 
serial port implementation, platform, etc..  However, if you can come up 
with a general design and a reference implementation for one subsystem, 
I'd like to see it and might get on board.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 15:40:55 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 14:40:55 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449B080D.9080208@ergotech.com>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
Message-ID: <20060622214055.GA25497@freehold.crocodile.org>

On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote:
> 
> Vadim Tkachenko wrote:
> > Hello again,
> > 
> > And while I'm at it, why don't just say this: give me one good reason to
> > write 3+ different ways of handling removable devices, one for USB, one for
> > FireWire, one for serial...
> 
> You don't, they're all the same "I have lost communication with my 
> serial device".

"I have lost communication with my ${protocol} device".

> The only thing you could really do is improve error reporting by knowing 
> the exact sub-system.  ("Device X which is/was attached to USB port Y is 
> no longer functioning, please check the USB ports, the device, the 
> cables and anything else you can think of that may be a cause of 
> failure.")

"Device ${id} which is/was attached to ${protocol} port ${port} is no longer
functioning, please check the ${protocol} ports, the device, the
${protocol_media} and anything else you can think of that may be a cause of
failure".

>  That just requires an intelligent description of the port.

Agree absolutely.

> > I understand very well that this goes way beyond the scope of RxTx and
> > CommAPI and will require cooperation between them and javax.usb and whatever
> > JSR is responsible for FireWire implementation - but the end result is well
> > worth it. Abstract out and generalize arrival/departure/monitoring/discovery
> > API, provide protocol specific extensions for each, live happily ever after.
> 
> There's a huge list of pseudo-serial devices each with a different set 
> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, 
> etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I 
> have no clue how you'd implement them in a general/cross platform sense.

That's because some of the protocols were created decades ago when
autoconfiguration wasn't even conceived, much less practical. RS232/RS485
don't have a clue about identity discovery, and even capabilities discovery
beyond obvious 8N1 etc.

I agree that today all these protocols have generally incompatible
strategies for handling the situations I'm trying to address, but there's
nothing that says it's not an oversight. Besides, we're dealing with the
devices at a level of abstraction that allows some simplifications and
generalizations, at least part of the time - unless it's the protocol
specific features we're dealing with.

> You haven't convinced me (and only me, others may see something that I 
> don't, I'm not speaking for them) that this mechanism can be implemented 
> in any practical sense.  That is, that the implementation could be wide 
> enough to be consider generally available in RXTX regardless of the 
> serial port implementation, platform, etc..  However, if you can come up 
> with a general design and a reference implementation for one subsystem, 
> I'd like to see it and might get on board.

Actually, I wasn't even thinking about all this stuff when I wrote the first
message on the subject :) Now that you mention it - well, I'm not sure I can
chew the piece I just tried to bite in reasonable amount of time.

How do you eat an elephant? One bite at a time. If we could agree that a
small step in the specification is acceptable at this time, and express
further intentions, things may start happening.

To put it succinctly:

- Concept of a "port" should be augmented with a concept of a "device". A
device may be attached to a port in an implicit or explicit way.
- Implicitly connected device is exactly what the current scope of the
specification covers. No new functionality is offered.
- Explicitly connected device supports detachable device semantics, just as
other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a
few).
- The input and output streams are not properties of a port now, but
properties of the device attached to the port.
- A mechanism to allow listening for device arrivals and departures must be
made available.

That's it, off the top of my head.

I understand that this goes completely against current javax.comm specs, but
an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be
difficult to implement without disrupting javax.comm compatibility.

One concern is how to deal with the device identity - but there's no general
way of dealing with this at this time, devices may or may not offer identity
discovery.

> Jim

--vt


From joachim at buechse.de  Fri Jun 23 02:12:43 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 23 Jun 2006 10:12:43 +0200
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
Message-ID: <CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>

Hello++ Vadim,

I would like to repeat that your request is best addressed to the  
POSSIX standardization group - or maybe the BSD/Linux maintainers. If  
you convince the BSD or Linux guys to add this kind of functionality  
(they can as most of there VCP drivers are open source), there is a  
certain chance that other vendors will pick it up. I assure you that  
RXTX will happily provide this functionality once it's possible - I'm  
sure there is more than one maintainer that would love to add it.  
Having this concept penetrate the market may take some years though.

SHORT: The solution you would like to see could be added to the API  
but it can not be implemented (at least not on the platforms I know).  
There are currently no hooks in the kernel that allow you to discover  
"the device" or even the "means of connection" based on an existing  
"device file descriptor" ie COM-port or /dev/... entry. The name  
mapping of the device is handled by the virtual com port driver of  
the device. Unless you are suggesting RXTX should reimplement virtual  
com port drivers for all usb/serial bridges out there your request is  
understandable from a users viewpoint but simply not realizable. It's  
like asking that the Socket api should identify the computer behind  
an IP address (ie by its Ethernet address). While this COULD be  
implemented in TCP/IP, it IS not, and hence there is no point adding  
such a function to the Socket API.

The current trend for USB/Bluetooth/Irda/etc connected devices is  
going away from serial port abstraction towards RPC (ie the drivers  
provide a device specific or device class specific driver that  
provides an application level api to the device functions). The line  
level protocol is often not even published.

Best regards,
Joachim

On 22.06.2006, at 23:40, Vadim Tkachenko wrote:

> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote:
>>
>> Vadim Tkachenko wrote:
>>> Hello again,
>>>
>>> And while I'm at it, why don't just say this: give me one good  
>>> reason to
>>> write 3+ different ways of handling removable devices, one for  
>>> USB, one for
>>> FireWire, one for serial...
>>
>> You don't, they're all the same "I have lost communication with my
>> serial device".
>
> "I have lost communication with my ${protocol} device".
>
>> The only thing you could really do is improve error reporting by  
>> knowing
>> the exact sub-system.  ("Device X which is/was attached to USB  
>> port Y is
>> no longer functioning, please check the USB ports, the device, the
>> cables and anything else you can think of that may be a cause of
>> failure.")
>
> "Device ${id} which is/was attached to ${protocol} port ${port} is  
> no longer
> functioning, please check the ${protocol} ports, the device, the
> ${protocol_media} and anything else you can think of that may be a  
> cause of
> failure".
>
>>  That just requires an intelligent description of the port.
>
> Agree absolutely.
>
>>> I understand very well that this goes way beyond the scope of  
>>> RxTx and
>>> CommAPI and will require cooperation between them and javax.usb  
>>> and whatever
>>> JSR is responsible for FireWire implementation - but the end  
>>> result is well
>>> worth it. Abstract out and generalize arrival/departure/ 
>>> monitoring/discovery
>>> API, provide protocol specific extensions for each, live happily  
>>> ever after.
>>
>> There's a huge list of pseudo-serial devices each with a different  
>> set
>> of requirements, Bluetooth, RFC 2217, a host of proprietary systems,
>> etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I
>> have no clue how you'd implement them in a general/cross platform  
>> sense.
>
> That's because some of the protocols were created decades ago when
> autoconfiguration wasn't even conceived, much less practical. RS232/ 
> RS485
> don't have a clue about identity discovery, and even capabilities  
> discovery
> beyond obvious 8N1 etc.
>
> I agree that today all these protocols have generally incompatible
> strategies for handling the situations I'm trying to address, but  
> there's
> nothing that says it's not an oversight. Besides, we're dealing  
> with the
> devices at a level of abstraction that allows some simplifications and
> generalizations, at least part of the time - unless it's the protocol
> specific features we're dealing with.
>
>> You haven't convinced me (and only me, others may see something  
>> that I
>> don't, I'm not speaking for them) that this mechanism can be  
>> implemented
>> in any practical sense.  That is, that the implementation could be  
>> wide
>> enough to be consider generally available in RXTX regardless of the
>> serial port implementation, platform, etc..  However, if you can  
>> come up
>> with a general design and a reference implementation for one  
>> subsystem,
>> I'd like to see it and might get on board.
>
> Actually, I wasn't even thinking about all this stuff when I wrote  
> the first
> message on the subject :) Now that you mention it - well, I'm not  
> sure I can
> chew the piece I just tried to bite in reasonable amount of time.
>
> How do you eat an elephant? One bite at a time. If we could agree  
> that a
> small step in the specification is acceptable at this time, and  
> express
> further intentions, things may start happening.
>
> To put it succinctly:
>
> - Concept of a "port" should be augmented with a concept of a  
> "device". A
> device may be attached to a port in an implicit or explicit way.
> - Implicitly connected device is exactly what the current scope of the
> specification covers. No new functionality is offered.
> - Explicitly connected device supports detachable device semantics,  
> just as
> other protocols do (USB, FireWire, Wireless USB, Bluetooth, to  
> mention a
> few).
> - The input and output streams are not properties of a port now, but
> properties of the device attached to the port.
> - A mechanism to allow listening for device arrivals and departures  
> must be
> made available.
>
> That's it, off the top of my head.
>
> I understand that this goes completely against current javax.comm  
> specs, but
> an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern )  
> won't be
> difficult to implement without disrupting javax.comm compatibility.
>
> One concern is how to deal with the device identity - but there's  
> no general
> way of dealing with this at this time, devices may or may not offer  
> identity
> discovery.
>
>> Jim
>
> --vt
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From vt at freehold.crocodile.org  Fri Jun 23 11:28:29 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Fri, 23 Jun 2006 10:28:29 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
	<CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
Message-ID: <20060623172829.GA5335@freehold.crocodile.org>

Hello Joachim,

> I would like to repeat that your request is best addressed to the POSSIX
> standardization group - or maybe the BSD/Linux maintainers. If you
> convince the BSD or Linux guys to add this kind of functionality (they can
> as most of there VCP drivers are open source), there is a certain chance
> that other vendors will pick it up. I assure you that RXTX will happily
> provide this functionality once it's possible - I'm sure there is more
> than one maintainer that would love to add it.

I realize this thing is bigger than RxTx itself, and I'm afraid it's too
global not to cause people to laugh before they think about it :)

> Having this concept penetrate the market may take some years though.

Well, I'm sure it'll get there, the only question is - when.

> SHORT: The solution you would like to see could be added to the API but it
> can not be implemented (at least not on the platforms I know).

I guess I'm concerned about the abstraction more than I'm concerned about
the implementation at this point.
  
> There are currently no hooks in the kernel that allow you to discover  
> "the device" or even the "means of connection" based on an existing  
> "device file descriptor" ie COM-port or /dev/... entry.

Well, I'm not so sure you need to keep the literal mapping from /dev
namespace to your device namespace. As long as you can consistently offer a
virtual serial device on top of a virtual serial port, it may be irrelevant
whether you can map it into /dev. The mapping is going be schitzofrenic
anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the
representation...

> The name mapping of the device is handled by the virtual com port driver
> of the device. Unless you are suggesting RXTX should reimplement virtual
> com port drivers for all usb/serial bridges out there your request is
> understandable from a users viewpoint but simply not realizable.

It's not so much a request but rather an offer of participation. I run a few
projects actively using serial communications, as well as USB device
drivers, in different degrees of readiness (Servomaster, Haywire, DIY
Zoning) - and it would be a perfect playground.

You mentioned above that this task is about two things: a) abstraction b)
implementation. I could start the abstraction part of it without changing
the current CommAPI, on top of it, as an adapter. Even if the removable
device semantics are not implemented, but offered, this is already a step
forward.

> It's like asking that the Socket api should identify the computer behind
> an IP address (ie by its Ethernet address). While this COULD be
> implemented in TCP/IP, it IS not, and hence there is no point adding such
> a function to the Socket API.

Thank you for bringing up this example - I guess this is just about the same
thing that I'd like to see. Socket transparently provides you with the
input/output streams, at the same time offering protocol level specifics to
you.

> The current trend for USB/Bluetooth/Irda/etc connected devices is going
> away from serial port abstraction towards RPC (ie the drivers provide a
> device specific or device class specific driver that provides an
> application level api to the device functions). The line level protocol is
> often not even published.

I can't say I'm that happy with it. The best (or, rather, worst) example is
suchlike support for the Phidget servo controller - zealous Linux developers
implemented kernel module support for it, completely hijacking a possibility
of using it on a different level (it's somewhat fixed by now, thankfully).

I believe that whenever an abstraction is offered, it must be made optional
and/or pluggable so it can be replaced by something more suited to the task.

The nature of Java applications is such that they'd probably care much more
about Java API offered, than about no matter how rich application level api
that is offered outside of Java. I've dealt with JNI adapters in the past,
and whereas they can be made reasonably stable, the very fact that you are
forced to deal with things that are not on the critical timing/memory path
and could've been done much easier in Java causes endless grief.

> Joachim

--vt


From lyon at docjava.com  Sat Jun 24 04:54:12 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Sat, 24 Jun 2006 06:54:12 -0400
Subject: [Rxtx] jsr
In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
	<CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
	<20060623172829.GA5335@freehold.crocodile.org>
Message-ID: <p060204a3c0c2c9dde4f8@[192.168.1.152]>

Hi All,
I have had some off-list discussion with Trent.
Opening up a JSR with Sun, as per Peters' suggestion
seems like a reasonable idea, to us.

Does anyone having any concerns about the JSR process
that they would like to raise?

Thanks!
  - Doug



From the.grey.lantern at gmail.com  Sat Jun 24 18:15:26 2006
From: the.grey.lantern at gmail.com (Craig Nicoll)
Date: Sun, 25 Jun 2006 01:15:26 +0100
Subject: [Rxtx] Cannot create virtual serial port
Message-ID: <a1221cc50606241715g2d1e2af6r747347dd4c20e997@mail.gmail.com>

Hello,

This is my first post on this mailing list and I hope someone can help me.

I am having great difficult establishing a virtual serial port for the
Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia
7600.

Every time I try to run the SendMessage program that comes with SMSLib, I
get the following exception: gnu.io.NoSuchPortException

The port names I have tried are:
rfcomm0
rfcomm
/dev/rfcomm0
/dev/rfcomm

This is what I have done so far:
Modified /etc/bluetooth/rfcomm.conf to include the address of my phone:

rfcomm0 {
# Automatically bind the device at startup
bind no;

# Bluetooth address of the device
device 00:0e:6d:7a:98:43;

# RFCOMM channel for the connection
channel 1;

# Description of the connection
comment "Example Bluetooth device";
}

I also tried running the following command: rfcomm bind /dev/rfcomm0

I have searched the mailing list archives and found this post where someone
had a very similar problem to me:
http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried
changing the system properties as suggested and it made no difference.

I have also been scouring Google all day to no avail.

I would be incredibly grateful if anyone could give me some tips.

Thank you,

Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060625/cfa6df35/attachment-0002.html

From tjarvi at qbang.org  Sun Jun 25 19:56:08 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT)
Subject: [Rxtx] Pending release
Message-ID: <Pine.LNX.4.61.0606251942460.15744@www>


With frustration, I was unable to get to the pending release this weekend.
The release should be comming this next week once things calm down.
The source is in CVS except for a fix for multiple ports in windows.

I had planned on doing the release this weekend but that was disrupted by 
my transportation failing in a spectacular fashion.

--
Trent Jarvi
tjarvi at qbang.org


From Pawan.Kharbanda at dot.state.co.us  Tue Jun 27 22:28:51 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 27 Jun 2006 22:28:51 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>

 Trent, 
   I have an application running in a cluster in linux environment and I
am using RXTX2.1.7 (final) with JDK1.5. The application opens and closes
serial comm ports every 30 seconds and exchanges datas. I have
experienced some of my Comm Ports are left hanging (I can see the
LCK..cufXX lock files under /var/lock folder). On putting the debugs I
found out that, it is stuck at a native call line 809 in RXTXPort.java
class (Please see the code snippet below). Can you help me explain what
this method does in the native code? Am I getting into some thread
deadlocks? Thanks in advance.

Pawan Kharbanda 


public void removeEventListener()
	{
		if (debug)
			z.reportln( "RXTXPort:removeEventListener()
called");
		waitForTheNativeCodeSilly();
		//if( monThread != null && monThread.isAlive() )
		if( monThreadisInterrupted == true )
		{
			z.reportln( "	RXTXPort:removeEventListener()
already interrupted");
			monThread = null;
			SPEventListener = null;
			return;
		}
		else if( monThread != null && monThread.isAlive() )
		{
			if (debug)
				z.reportln( "
RXTXPort:Interrupt=true");
			monThreadisInterrupted=true;
			/*
			   Notify all threads in this PID that something
is up
			   They will call back to see if its their
thread
			   using isInterrupted().
			*/
			if (debug)
				z.reportln( "	RXTXPort:calling
interruptEventLoop");
// LINE 809			interruptEventLoop( ); It never returns
out of this 
			
			if (debug)
				z.reportln( "	RXTXPort:calling
monThread.join()");
			try {
				monThread.join(1000);
			} catch (Exception ex) {
				/* yikes */
				ex.printStackTrace();
			}
			if (debug)
				z.reportln( "	RXTXPort:waiting on
isAlive()");
			while( monThread.isAlive() )
			{
				if ( debug )
					z.reportln( "	MonThread is
still alive!");
				try {
					monThread.join(1000);
					Thread.sleep( 1000 );
				} catch( Exception e ){} 
				//monThread.stop();
			}
			
		}
		if (debug)
			z.reportln( "	RXTXPort:calling gc()");
		monThread = null;
		SPEventListener = null;
		MonitorThreadLock = false;
		MonitorThreadAlive=false;
		monThreadisInterrupted=true;
		z.reportln( "RXTXPort:removeEventListener() returning");
	} 

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Sunday, June 25, 2006 7:56 PM
To: rxtx at qbang.org
Subject: [Rxtx] Pending release


With frustration, I was unable to get to the pending release this
weekend.
The release should be comming this next week once things calm down.
The source is in CVS except for a fix for multiple ports in windows.

I had planned on doing the release this weekend but that was disrupted
by my transportation failing in a spectacular fashion.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Wed Jun 28 04:17:29 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 28 Jun 2006 04:17:29 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606280406330.9561@www>



Hi Pawan

You may have found a deadlock but I've not seen on recently on linux.

If you can, please update from CVS.  This will have some close fixes. 
I'm running with the same code as is in CVS.  It is not perfect but I've 
not seen anything like you mention.  Be sure to set timeouts and 
thresholds on the port.  It may be that the port is waiting on pending io 
that never happens.  I think the CVS patches deal with this also but it 
looks like your in a better test environment to know for sure.

The exploded vehicle mentioned below is expected to be fixed today.  It 
was just a ninja small radiator hose.  The pressure test afterwards 
created its own set of problems.  Until this is resolved, I'm spending 
most of my free time commuting by bicycle.

On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>   I have an application running in a cluster in linux environment and I
> am using RXTX2.1.7 (final) with JDK1.5. The application opens and closes
> serial comm ports every 30 seconds and exchanges datas. I have
> experienced some of my Comm Ports are left hanging (I can see the
> LCK..cufXX lock files under /var/lock folder). On putting the debugs I
> found out that, it is stuck at a native call line 809 in RXTXPort.java
> class (Please see the code snippet below). Can you help me explain what
> this method does in the native code? Am I getting into some thread
> deadlocks? Thanks in advance.
>
> Pawan Kharbanda
>
>
> public void removeEventListener()
> 	{
> 		if (debug)
> 			z.reportln( "RXTXPort:removeEventListener()
> called");
> 		waitForTheNativeCodeSilly();
> 		//if( monThread != null && monThread.isAlive() )
> 		if( monThreadisInterrupted == true )
> 		{
> 			z.reportln( "	RXTXPort:removeEventListener()
> already interrupted");
> 			monThread = null;
> 			SPEventListener = null;
> 			return;
> 		}
> 		else if( monThread != null && monThread.isAlive() )
> 		{
> 			if (debug)
> 				z.reportln( "
> RXTXPort:Interrupt=true");
> 			monThreadisInterrupted=true;
> 			/*
> 			   Notify all threads in this PID that something
> is up
> 			   They will call back to see if its their
> thread
> 			   using isInterrupted().
> 			*/
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> interruptEventLoop");
> // LINE 809			interruptEventLoop( ); It never returns
> out of this
>
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> monThread.join()");
> 			try {
> 				monThread.join(1000);
> 			} catch (Exception ex) {
> 				/* yikes */
> 				ex.printStackTrace();
> 			}
> 			if (debug)
> 				z.reportln( "	RXTXPort:waiting on
> isAlive()");
> 			while( monThread.isAlive() )
> 			{
> 				if ( debug )
> 					z.reportln( "	MonThread is
> still alive!");
> 				try {
> 					monThread.join(1000);
> 					Thread.sleep( 1000 );
> 				} catch( Exception e ){}
> 				//monThread.stop();
> 			}
>
> 		}
> 		if (debug)
> 			z.reportln( "	RXTXPort:calling gc()");
> 		monThread = null;
> 		SPEventListener = null;
> 		MonitorThreadLock = false;
> 		MonitorThreadAlive=false;
> 		monThreadisInterrupted=true;
> 		z.reportln( "RXTXPort:removeEventListener() returning");
> 	}
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Sunday, June 25, 2006 7:56 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] Pending release
>
>
> With frustration, I was unable to get to the pending release this
> weekend.
> The release should be comming this next week once things calm down.
> The source is in CVS except for a fix for multiple ports in windows.
>
> I had planned on doing the release this weekend but that was disrupted
> by my transportation failing in a spectacular fashion.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From Pawan.Kharbanda at dot.state.co.us  Wed Jun 28 12:11:06 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Wed, 28 Jun 2006 12:11:06 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>

Trent,
    Again thanks for the reply. First of all I have Receive timeouts set
on all communications including Max no of bytes to expect during the
call. I have noticed the problem is during "closing the connection". I
am not sure if the RXTX is 100% thread-safe yet. There seems to be a
glitch in the native calls. I am sure I have the latest code I did the
update on the Version 2.1.7 from CVS, is this where the latest updates
are located, I have noticed another version in CVS "rxtx-devel".

Regards
Pawan Kharbanda

    

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Wednesday, June 28, 2006 4:17 AM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports



Hi Pawan

You may have found a deadlock but I've not seen on recently on linux.

If you can, please update from CVS.  This will have some close fixes. 
I'm running with the same code as is in CVS.  It is not perfect but I've
not seen anything like you mention.  Be sure to set timeouts and
thresholds on the port.  It may be that the port is waiting on pending
io that never happens.  I think the CVS patches deal with this also but
it looks like your in a better test environment to know for sure.

The exploded vehicle mentioned below is expected to be fixed today.  It
was just a ninja small radiator hose.  The pressure test afterwards
created its own set of problems.  Until this is resolved, I'm spending
most of my free time commuting by bicycle.

On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>   I have an application running in a cluster in linux environment and 
> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and 
> closes serial comm ports every 30 seconds and exchanges datas. I have 
> experienced some of my Comm Ports are left hanging (I can see the 
> LCK..cufXX lock files under /var/lock folder). On putting the debugs I

> found out that, it is stuck at a native call line 809 in RXTXPort.java

> class (Please see the code snippet below). Can you help me explain 
> what this method does in the native code? Am I getting into some 
> thread deadlocks? Thanks in advance.
>
> Pawan Kharbanda
>
>
> public void removeEventListener()
> 	{
> 		if (debug)
> 			z.reportln( "RXTXPort:removeEventListener()
called");
> 		waitForTheNativeCodeSilly();
> 		//if( monThread != null && monThread.isAlive() )
> 		if( monThreadisInterrupted == true )
> 		{
> 			z.reportln( "	RXTXPort:removeEventListener()
> already interrupted");
> 			monThread = null;
> 			SPEventListener = null;
> 			return;
> 		}
> 		else if( monThread != null && monThread.isAlive() )
> 		{
> 			if (debug)
> 				z.reportln( "
> RXTXPort:Interrupt=true");
> 			monThreadisInterrupted=true;
> 			/*
> 			   Notify all threads in this PID that something
is up
> 			   They will call back to see if its their
thread
> 			   using isInterrupted().
> 			*/
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> interruptEventLoop");
> // LINE 809			interruptEventLoop( ); It never returns
> out of this
>
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> monThread.join()");
> 			try {
> 				monThread.join(1000);
> 			} catch (Exception ex) {
> 				/* yikes */
> 				ex.printStackTrace();
> 			}
> 			if (debug)
> 				z.reportln( "	RXTXPort:waiting on
> isAlive()");
> 			while( monThread.isAlive() )
> 			{
> 				if ( debug )
> 					z.reportln( "	MonThread is
> still alive!");
> 				try {
> 					monThread.join(1000);
> 					Thread.sleep( 1000 );
> 				} catch( Exception e ){}
> 				//monThread.stop();
> 			}
>
> 		}
> 		if (debug)
> 			z.reportln( "	RXTXPort:calling gc()");
> 		monThread = null;
> 		SPEventListener = null;
> 		MonitorThreadLock = false;
> 		MonitorThreadAlive=false;
> 		monThreadisInterrupted=true;
> 		z.reportln( "RXTXPort:removeEventListener() returning");
> 	}
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf

> Of Trent Jarvi
> Sent: Sunday, June 25, 2006 7:56 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] Pending release
>
>
> With frustration, I was unable to get to the pending release this 
> weekend.
> The release should be comming this next week once things calm down.
> The source is in CVS except for a fix for multiple ports in windows.
>
> I had planned on doing the release this weekend but that was disrupted

> by my transportation failing in a spectacular fashion.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Wed Jun 28 12:26:21 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 28 Jun 2006 12:26:21 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606281222420.9561@www>


Hi Pawan

If you did a cvs update from the 2.1-7 tar ball, you have the current 
version.  All rxtx in CVS is under rxtx-devel.  The 2.1-7 just has -r
commapi-0-0-1.

You may well have found something.  I have seen win32 fail on closing 
ports but not linux that I can think of.  Your use is much different than 
I normally see too.

Could you give us more information on how we would reproduce this and the 
frequency?


On Wed, 28 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>    Again thanks for the reply. First of all I have Receive timeouts set
> on all communications including Max no of bytes to expect during the
> call. I have noticed the problem is during "closing the connection". I
> am not sure if the RXTX is 100% thread-safe yet. There seems to be a
> glitch in the native calls. I am sure I have the latest code I did the
> update on the Version 2.1.7 from CVS, is this where the latest updates
> are located, I have noticed another version in CVS "rxtx-devel".
>
> Regards
> Pawan Kharbanda
>
>
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Wednesday, June 28, 2006 4:17 AM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] Locked Ports
>
>
>
> Hi Pawan
>
> You may have found a deadlock but I've not seen on recently on linux.
>
> If you can, please update from CVS.  This will have some close fixes.
> I'm running with the same code as is in CVS.  It is not perfect but I've
> not seen anything like you mention.  Be sure to set timeouts and
> thresholds on the port.  It may be that the port is waiting on pending
> io that never happens.  I think the CVS patches deal with this also but
> it looks like your in a better test environment to know for sure.
>
> The exploded vehicle mentioned below is expected to be fixed today.  It
> was just a ninja small radiator hose.  The pressure test afterwards
> created its own set of problems.  Until this is resolved, I'm spending
> most of my free time commuting by bicycle.
>
> On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:
>
>> Trent,
>>   I have an application running in a cluster in linux environment and
>> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and
>> closes serial comm ports every 30 seconds and exchanges datas. I have
>> experienced some of my Comm Ports are left hanging (I can see the
>> LCK..cufXX lock files under /var/lock folder). On putting the debugs I
>
>> found out that, it is stuck at a native call line 809 in RXTXPort.java
>
>> class (Please see the code snippet below). Can you help me explain
>> what this method does in the native code? Am I getting into some
>> thread deadlocks? Thanks in advance.
>>
>> Pawan Kharbanda
>>
>>
>> public void removeEventListener()
>> 	{
>> 		if (debug)
>> 			z.reportln( "RXTXPort:removeEventListener()
> called");
>> 		waitForTheNativeCodeSilly();
>> 		//if( monThread != null && monThread.isAlive() )
>> 		if( monThreadisInterrupted == true )
>> 		{
>> 			z.reportln( "	RXTXPort:removeEventListener()
>> already interrupted");
>> 			monThread = null;
>> 			SPEventListener = null;
>> 			return;
>> 		}
>> 		else if( monThread != null && monThread.isAlive() )
>> 		{
>> 			if (debug)
>> 				z.reportln( "
>> RXTXPort:Interrupt=true");
>> 			monThreadisInterrupted=true;
>> 			/*
>> 			   Notify all threads in this PID that something
> is up
>> 			   They will call back to see if its their
> thread
>> 			   using isInterrupted().
>> 			*/
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> interruptEventLoop");
>> // LINE 809			interruptEventLoop( ); It never returns
>> out of this
>>
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> monThread.join()");
>> 			try {
>> 				monThread.join(1000);
>> 			} catch (Exception ex) {
>> 				/* yikes */
>> 				ex.printStackTrace();
>> 			}
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:waiting on
>> isAlive()");
>> 			while( monThread.isAlive() )
>> 			{
>> 				if ( debug )
>> 					z.reportln( "	MonThread is
>> still alive!");
>> 				try {
>> 					monThread.join(1000);
>> 					Thread.sleep( 1000 );
>> 				} catch( Exception e ){}
>> 				//monThread.stop();
>> 			}
>>
>> 		}
>> 		if (debug)
>> 			z.reportln( "	RXTXPort:calling gc()");
>> 		monThread = null;
>> 		SPEventListener = null;
>> 		MonitorThreadLock = false;
>> 		MonitorThreadAlive=false;
>> 		monThreadisInterrupted=true;
>> 		z.reportln( "RXTXPort:removeEventListener() returning");
>> 	}
>>
>> -----Original Message-----
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
>
>> Of Trent Jarvi
>> Sent: Sunday, June 25, 2006 7:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] Pending release
>>
>>
>> With frustration, I was unable to get to the pending release this
>> weekend.
>> The release should be comming this next week once things calm down.
>> The source is in CVS except for a fix for multiple ports in windows.
>>
>> I had planned on doing the release this weekend but that was disrupted
>
>> by my transportation failing in a spectacular fashion.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From Pawan.Kharbanda at dot.state.co.us  Wed Jun 28 15:42:49 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Wed, 28 Jun 2006 15:42:49 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>

Trent,
    I will try to explain how I am setup and will try to write you a
Sample code little later to reproduce this. On our system we have
DigiBoxes installed on the 2 Linux servers. Both of them have RXTX2.1-7
version installed with the JRE(1.5) and both the machines have the same
port mappings in gnu.io.rxtx.properties (Currently in the production
system I have 64 ports). This is how the system works:

1) A thick Map based client initiates a Action on the Device on the
field. One of the Thread Workers(Asynchronous Call) in the Cluster picks
up the request. 
2) Once the worker gets the request it locks the Device and
Communication port in the DB's(These are our persistent locks, because
most of the devices do one to one communication with the serial ports).
After that the worker (or Comm Server) opens up the connection and after
exchanging the information calls the "Close" and returns.
3) Once the connection is closed , the DB lock is removed on the comm
port and is made available to accept future calls. Here is where the
glitch is the Serial Comm Close method never returns due to the
deadlock. 

I have noticed that the deadlocks are very inconsistent, sometime it
happens right away as soon as Application server starts and sometimes I
don't see any deadlocks for days, but it happens for sure. 

Here is how you can test if you have resources/ test environment. Write
a program and try to open/close  different ports(I will say have a
minimum of four) randomly and very frequently(may be 30 seconds), I am
pretty sure you will see the deadlocks and it happens in the native call
to interrptEventLoop in RXTXPort.java in removeEventListener() method
call.

Also I have noticed that the JVM carshes (without any memrory errors or
JVM errors. Its just not there) when native call is made to eventLoop()
in run() method in MonitorThread inner class. I am still investigating
why this is happening, but at this point I can just tell you the
location. You might have a question How I am so sure about the location?
My application is configured with Log4J and I have enabled the debugs on
the RXTXPort.java, so every time my JVM dies I see these logs at the end
of the file.

"2006-06-28 15:27:15,183 INFO  [STDOUT] RXTXPort:RXTXPort(/dev/cub01)
called
2006-06-28 15:27:15,218 INFO  [STDOUT]
RXTXPort:MontitorThread:MonitorThread()
2006-06-28 15:27:15,219 INFO  [STDOUT] RXTXPort:MontitorThread:run()"

I surely do have a luxury of a testing environment(ports, devices etc.)
and can help you fix these problems? Please advise me how we can resolve
these issues.

Thanks 
Pawan Kharbanda
303-478-2991





-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Wednesday, June 28, 2006 12:26 PM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports


Hi Pawan

If you did a cvs update from the 2.1-7 tar ball, you have the current
version.  All rxtx in CVS is under rxtx-devel.  The 2.1-7 just has -r
commapi-0-0-1.

You may well have found something.  I have seen win32 fail on closing
ports but not linux that I can think of.  Your use is much different
than I normally see too.

Could you give us more information on how we would reproduce this and
the frequency?


On Wed, 28 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>    Again thanks for the reply. First of all I have Receive timeouts
set
> on all communications including Max no of bytes to expect during the
> call. I have noticed the problem is during "closing the connection". I
> am not sure if the RXTX is 100% thread-safe yet. There seems to be a
> glitch in the native calls. I am sure I have the latest code I did the
> update on the Version 2.1.7 from CVS, is this where the latest updates
> are located, I have noticed another version in CVS "rxtx-devel".
>
> Regards
> Pawan Kharbanda
>
>
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Wednesday, June 28, 2006 4:17 AM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] Locked Ports
>
>
>
> Hi Pawan
>
> You may have found a deadlock but I've not seen on recently on linux.
>
> If you can, please update from CVS.  This will have some close fixes.
> I'm running with the same code as is in CVS.  It is not perfect but
I've
> not seen anything like you mention.  Be sure to set timeouts and
> thresholds on the port.  It may be that the port is waiting on pending
> io that never happens.  I think the CVS patches deal with this also
but
> it looks like your in a better test environment to know for sure.
>
> The exploded vehicle mentioned below is expected to be fixed today.
It
> was just a ninja small radiator hose.  The pressure test afterwards
> created its own set of problems.  Until this is resolved, I'm spending
> most of my free time commuting by bicycle.
>
> On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:
>
>> Trent,
>>   I have an application running in a cluster in linux environment and
>> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and
>> closes serial comm ports every 30 seconds and exchanges datas. I have
>> experienced some of my Comm Ports are left hanging (I can see the
>> LCK..cufXX lock files under /var/lock folder). On putting the debugs
I
>
>> found out that, it is stuck at a native call line 809 in
RXTXPort.java
>
>> class (Please see the code snippet below). Can you help me explain
>> what this method does in the native code? Am I getting into some
>> thread deadlocks? Thanks in advance.
>>
>> Pawan Kharbanda
>>
>>
>> public void removeEventListener()
>> 	{
>> 		if (debug)
>> 			z.reportln( "RXTXPort:removeEventListener()
> called");
>> 		waitForTheNativeCodeSilly();
>> 		//if( monThread != null && monThread.isAlive() )
>> 		if( monThreadisInterrupted == true )
>> 		{
>> 			z.reportln( "	RXTXPort:removeEventListener()
>> already interrupted");
>> 			monThread = null;
>> 			SPEventListener = null;
>> 			return;
>> 		}
>> 		else if( monThread != null && monThread.isAlive() )
>> 		{
>> 			if (debug)
>> 				z.reportln( "
>> RXTXPort:Interrupt=true");
>> 			monThreadisInterrupted=true;
>> 			/*
>> 			   Notify all threads in this PID that something
> is up
>> 			   They will call back to see if its their
> thread
>> 			   using isInterrupted().
>> 			*/
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> interruptEventLoop");
>> // LINE 809			interruptEventLoop( ); It never returns
>> out of this
>>
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> monThread.join()");
>> 			try {
>> 				monThread.join(1000);
>> 			} catch (Exception ex) {
>> 				/* yikes */
>> 				ex.printStackTrace();
>> 			}
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:waiting on
>> isAlive()");
>> 			while( monThread.isAlive() )
>> 			{
>> 				if ( debug )
>> 					z.reportln( "	MonThread is
>> still alive!");
>> 				try {
>> 					monThread.join(1000);
>> 					Thread.sleep( 1000 );
>> 				} catch( Exception e ){}
>> 				//monThread.stop();
>> 			}
>>
>> 		}
>> 		if (debug)
>> 			z.reportln( "	RXTXPort:calling gc()");
>> 		monThread = null;
>> 		SPEventListener = null;
>> 		MonitorThreadLock = false;
>> 		MonitorThreadAlive=false;
>> 		monThreadisInterrupted=true;
>> 		z.reportln( "RXTXPort:removeEventListener() returning");
>> 	}
>>
>> -----Original Message-----
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On
Behalf
>
>> Of Trent Jarvi
>> Sent: Sunday, June 25, 2006 7:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] Pending release
>>
>>
>> With frustration, I was unable to get to the pending release this
>> weekend.
>> The release should be comming this next week once things calm down.
>> The source is in CVS except for a fix for multiple ports in windows.
>>
>> I had planned on doing the release this weekend but that was
disrupted
>
>> by my transportation failing in a spectacular fashion.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx 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 khattar31 at yahoo.com  Wed Jun 28 22:04:59 2006
From: khattar31 at yahoo.com (rahul khattar)
Date: Wed, 28 Jun 2006 21:04:59 -0700 (PDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
Message-ID: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>

Hi All,

I was looking at the src file on the last release.
I did notice a missing header file while trying to
compile the parallelport.dll. Would somebody be kind
enoughf to share the missing header file:
gnu_io_LPRPort.h

I am using MinGw to compile the same from Parinya
(which is an execellent tool)


Regards,
Rahul Khattar

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Thu Jun 29 03:43:53 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 03:43:53 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>
References: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606290341210.9561@www>

On Wed, 28 Jun 2006, rahul khattar wrote:

> Hi All,
>
> I was looking at the src file on the last release.
> I did notice a missing header file while trying to
> compile the parallelport.dll. Would somebody be kind
> enoughf to share the missing header file:
> gnu_io_LPRPort.h
>
> I am using MinGw to compile the same from Parinya
> (which is an execellent tool)
>

Hi Rahul

The gnu.io_LPRPort.h file is generated with javah.  You can see the 
command in the Makefile I presume.  You do not need rxtxParallel.dll to 
use w32 serial btw.

--
Trent Jarvi
tjarvi at qbang.org


From khattar31 at yahoo.com  Thu Jun 29 04:47:01 2006
From: khattar31 at yahoo.com (rahul khattar)
Date: Thu, 29 Jun 2006 03:47:01 -0700 (PDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606290341210.9561@www>
Message-ID: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>

Hi Trent 
I did notice this file is required in the source file
ParallelImp.c
on line 38

Attached the O/P 

Regards,
Rahul Khattar




--- Trent Jarvi <tjarvi at qbang.org> wrote:

> On Wed, 28 Jun 2006, rahul khattar wrote:
> 
> > Hi All,
> >
> > I was looking at the src file on the last release.
> > I did notice a missing header file while trying to
> > compile the parallelport.dll. Would somebody be
> kind
> > enoughf to share the missing header file:
> > gnu_io_LPRPort.h
> >
> > I am using MinGw to compile the same from Parinya
> > (which is an execellent tool)
> >
> 
> Hi Rahul
> 
> The gnu.io_LPRPort.h file is generated with javah. 
> You can see the 
> command in the Makefile I presume.  You do not need
> rxtxParallel.dll to 
> use w32 serial btw.
> 
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Error.zip
Type: application/x-zip-compressed
Size: 1746 bytes
Desc: 2948039066-Error.zip
Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060629/a5b6f783/Error-0011.bin

From tjarvi at qbang.org  Thu Jun 29 06:16:24 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 06:16:24 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606290614530.9561@www>

On Thu, 29 Jun 2006, rahul khattar wrote:

> Hi Trent
> I did notice this file is required in the source file
> ParallelImp.c
> on line 38
>
> Attached the O/P
>

The command to generate the .h file will be something like:

javah -classpath . -jni gnu.io.LPRPort

The makefile should have this.  There are several approaches to creating 
or using makefiles so I have no idea which one you used if any.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Thu Jun 29 06:20:51 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 06:20:51 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606290616420.9561@www>

> Here is how you can test if you have resources/ test environment. Write
> a program and try to open/close  different ports(I will say have a
> minimum of four) randomly and very frequently(may be 30 seconds), I am
> pretty sure you will see the deadlocks and it happens in the native call
> to interrptEventLoop in RXTXPort.java in removeEventListener() method
> call.

Hi Pawan

I'll try to find a way to reproduce this.  One thing to note is that you 
are using different kernel drivers (digi) to perform this task.  So I 
probably will not be able to reproduce the exact same environment.

In general, multiport kernel drivers have been tested far less than 
typical serial drivers.  This may or may not be an issue.

--
Trent Jarvi
tjarvi at qbang.org



From jhaysonn at gmail.com  Thu Jun 29 12:29:13 2006
From: jhaysonn at gmail.com (jhaysonn pathak)
Date: Thu, 29 Jun 2006 14:29:13 -0400
Subject: [Rxtx] RXTX install
Message-ID: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>

Hi Guys,

I'm doing trying to write a generative piece of Sonic Art using an EEG
plugged into a mac runnning Max/MSP.  I just recently discovered RXTX
drivers in my search for a piece of software that might give me more
output options for my EEG (I'm using the CEO from MindPeak).  I found
Bioera which uses RXTX drivers.  Thing is - I can't figure out how to
install RXTX correctly.

After I build the 'libSerial.jnilib' target inside of
'LibSerial.pbproj' I can't find the libSerial.jnilib file that
accompanies the RXTXcomm.jar nor do I know where to put them.

I also don't understand this part at the bottom of the OS X instructions at all:

"AFTER INSTALLATION VERY IMPORTANT
	check existence of the folder /var/spool/uucp
	if you don't have it create it with command
	sudo mkdir /var/spool/uucp
	permissions should be: drwxrwxr-x
	if they are not do command
	sudo chmod 775 /var/spool/uucp

	YOU should be a member of the uucp group
	you can check it with command
		niutil -readprop / /groups/uucp users
	you should see your name in output of the niutil command
	if you don't do following:
		sudo niutil -appendprop / /groups/uucp users <yourname>
			substitute  <yourname> with your user's name
			for example if your user name is peter:
				sudo niutil -appendprop / /groups/uucp users peter

	NOTES: RXTX.pkg should create uucp folder and insert your name  in
uucp group automatically"



I really appreciate any help that you guys can offer.  I've been
struggling with this for a while now as part of a research grant that
I was awarded.  Thanks again for the help.

Jhaysonn Pathak


From naranjo.manuel at gmail.com  Thu Jun 29 07:19:15 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 10:19:15 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606290614530.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www>
Message-ID: <44A3D353.6010605@gmail.com>

Speaking about Windows Support, I had seen that inside the 
rxtx-2.1-7-bins-r2 package inside Windows directory it says:
"i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will 
not make harm to anyone, and i'm almost sure that someone has noticed it 
before.
Cheers,
Manuel


From joachim at buechse.de  Thu Jun 29 13:25:16 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 29 Jun 2006 21:25:16 +0200
Subject: [Rxtx] RXTX install
In-Reply-To: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>
References: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>
Message-ID: <2A003E42-97E1-4237-8438-646BDE2E3961@buechse.de>

Hello Jhaysonn,

I assume you are trying to use the javax.comm version of RXTX.

Please use "cvs up" to update your download to the latest version of  
the repository. The latest version does not use lock files, so the  
mentioned process is no longer needed. Updating with CVS will also  
provide you with a new README.OSX file that should be simpler to  
understand.

You will find LibSerialUniversal.xcodeproj in MACOSX_IDE/Xcode. Put  
comm.jar (downloaded from Sun) into MACOSX_IDE/Xcode. Compile the  
library. You will find RXTXcomm.jar and librxtxSerial.jnilib in  
MACOSX_IDE/Xcode/build/Default

Best regards,
Joachim
---
Joachim B?chse
Softwarel?sungen und Beratung
Hadlaubsteig 2
CH-8006 Z?rich


On 29.06.2006, at 20:29, jhaysonn pathak wrote:

> Hi Guys,
>
> I'm doing trying to write a generative piece of Sonic Art using an EEG
> plugged into a mac runnning Max/MSP.  I just recently discovered RXTX
> drivers in my search for a piece of software that might give me more
> output options for my EEG (I'm using the CEO from MindPeak).  I found
> Bioera which uses RXTX drivers.  Thing is - I can't figure out how to
> install RXTX correctly.
>
> After I build the 'libSerial.jnilib' target inside of
> 'LibSerial.pbproj' I can't find the libSerial.jnilib file that
> accompanies the RXTXcomm.jar nor do I know where to put them.
>
> I also don't understand this part at the bottom of the OS X  
> instructions at all:
>
> "AFTER INSTALLATION VERY IMPORTANT
> 	check existence of the folder /var/spool/uucp
> 	if you don't have it create it with command
> 	sudo mkdir /var/spool/uucp
> 	permissions should be: drwxrwxr-x
> 	if they are not do command
> 	sudo chmod 775 /var/spool/uucp
>
> 	YOU should be a member of the uucp group
> 	you can check it with command
> 		niutil -readprop / /groups/uucp users
> 	you should see your name in output of the niutil command
> 	if you don't do following:
> 		sudo niutil -appendprop / /groups/uucp users <yourname>
> 			substitute  <yourname> with your user's name
> 			for example if your user name is peter:
> 				sudo niutil -appendprop / /groups/uucp users peter
>
> 	NOTES: RXTX.pkg should create uucp folder and insert your name  in
> uucp group automatically"
>
>
>
> I really appreciate any help that you guys can offer.  I've been
> struggling with this for a while now as part of a research grant that
> I was awarded.  Thanks again for the help.
>
> Jhaysonn Pathak
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From tjarvi at qbang.org  Thu Jun 29 19:30:00 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 19:30:00 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A3D353.6010605@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
Message-ID: <Pine.LNX.4.61.0606291923000.9561@www>

On Thu, 29 Jun 2006, Manuel Naranjo wrote:

> Speaking about Windows Support, I had seen that inside the
> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
> not make harm to anyone, and i'm almost sure that someone has noticed it
> before.

Hi Manuel

         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
     47421  01-30-06 00:23 
rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
     77759  03-01-06 12:01 
rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README


It looks normal to me.  There are no fancy tools used there :)

--
Trent Jarvi
tjarvi at qbang.org

From naranjo.manuel at gmail.com  Thu Jun 29 19:38:16 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 22:38:16 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606291923000.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com> <Pine.LNX.4.61.0606291923000.9561@www>
Message-ID: <44A48088.2040407@gmail.com>

> On Thu, 29 Jun 2006, Manuel Naranjo wrote:
> 
>> Speaking about Windows Support, I had seen that inside the
>> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
>> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
>> not make harm to anyone, and i'm almost sure that someone has noticed it
>> before.
> 
> Hi Manuel
> 
>         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
>         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
>     47421  01-30-06 00:23 
> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
>     77759  03-01-06 12:01 
> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
>       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README
> 
> 
> It looks normal to me.  There are no fancy tools used there :)
> 
Hi Trent:
Is not the i368 representing the name of the Architecture?? If so the 
name should start with i386 it will not break any system, is simply miss
written, I saw that and wanted to report it. It a silly thing.
Ohh I forgoten I must congratulate you for your GREAT libray, I was able 
to make an .exe with JSmooth that launches an application that uses RXTX 
with out the need to install RXTX on users system :). The .exe tells JVM 
where to find the RXTX Library and Binaries. I tried with Sun's Java 
Comm but it was imposible.
Regards,
Manuel


From tjarvi at qbang.org  Thu Jun 29 19:52:45 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 19:52:45 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A48088.2040407@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
	<Pine.LNX.4.61.0606291923000.9561@www> <44A48088.2040407@gmail.com>
Message-ID: <Pine.LNX.4.61.0606291945060.9561@www>

On Thu, 29 Jun 2006, Manuel Naranjo wrote:

>> On Thu, 29 Jun 2006, Manuel Naranjo wrote:
>>
>>> Speaking about Windows Support, I had seen that inside the
>>> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
>>> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
>>> not make harm to anyone, and i'm almost sure that someone has noticed it
>>> before.
>>
>> Hi Manuel
>>
>>         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
>>         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
>>     47421  01-30-06 00:23
>> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
>>     77759  03-01-06 12:01
>> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
>>       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README
>>
>>
>> It looks normal to me.  There are no fancy tools used there :)
>>
> Hi Trent:
> Is not the i368 representing the name of the Architecture?? If so the
> name should start with i386 it will not break any system, is simply miss
> written, I saw that and wanted to report it. It a silly thing.
> Ohh I forgoten I must congratulate you for your GREAT libray, I was able
> to make an .exe with JSmooth that launches an application that uses RXTX
> with out the need to install RXTX on users system :). The .exe tells JVM
> where to find the RXTX Library and Binaries. I tried with Sun's Java
> Comm but it was imposible.

Hi Manuel

The compiler uses only the i386 instruction set for windows.  I doubt 
there will be any measurable advantages with going to later instruction 
sets.  In theory rxtx would run on a 386 but I doubt anyone does that.

So it looks odd but is not a typo.

We could compile to i686 but don't.  The compiler used does not appear to 
be a problem yet so I don't see any point in changing it.  Right now, we 
could not compile 64 bit windows binaries.  gcc/mingw/... do not support 
them that I know of.  People will have to compile those with closed source 
tools on their own until an option is available.

--
Trent Jarvi
tjarvi at qbang.org

From naranjo.manuel at gmail.com  Thu Jun 29 20:00:48 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 23:00:48 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606291945060.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com>	<Pine.LNX.4.61.0606291923000.9561@www>
	<44A48088.2040407@gmail.com> <Pine.LNX.4.61.0606291945060.9561@www>
Message-ID: <44A485D0.7050202@gmail.com>

Trent you did not get my point
The folder says 368 three hundred sixty eight, when
it should say 386 three hundred eighty six. Is simply a miss writting.
Regards,
Manuel


From tjarvi at qbang.org  Thu Jun 29 20:12:15 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 20:12:15 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A485D0.7050202@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
	<Pine.LNX.4.61.0606291923000.9561@www> <44A48088.2040407@gmail.com>
	<Pine.LNX.4.61.0606291945060.9561@www> <44A485D0.7050202@gmail.com>
Message-ID: <Pine.LNX.4.61.0606292008061.9561@www>


On Thu, 29 Jun 2006, Manuel Naranjo wrote:

> Trent you did not get my point
> The folder says 368 three hundred sixty eight, when
> it should say 386 three hundred eighty six. Is simply a miss writting.

hehe..  OK.  My bad.  It's been a long day.

Nevermind :)

--
Trent Jarvi
tjarvi at qbang.org




From naranjo.manuel at gmail.com  Thu Jun 29 20:18:44 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 23:18:44 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606292008061.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com>	<Pine.LNX.4.61.0606291923000.9561@www>
	<44A48088.2040407@gmail.com>	<Pine.LNX.4.61.0606291945060.9561@www>
	<44A485D0.7050202@gmail.com> <Pine.LNX.4.61.0606292008061.9561@www>
Message-ID: <44A48A04.9040401@gmail.com>

Don't worry Trent.
About 64 bits compilation, I would like to colaborate, I have a Pc with 
64 bits, the only problem is that i do not have windows 64 bits 
installed :(.




From Pawan.Kharbanda at dot.state.co.us  Fri Jun 30 08:49:52 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 30 Jun 2006 08:49:52 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E996@hqexchange3.dot.state.co.us>

Trent,  
    Can you explain what the interruptedEventLoop() native method is
doing is there a possibility that method is somehow getting into the
infinite loop(there are 2 while loops without any break statements).
This might be a very basic question how can I debug the native code(or
print the debug statements).  Again thanks for the help. 

Pawan Kharbanda

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Thursday, June 29, 2006 6:21 AM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports

> Here is how you can test if you have resources/ test environment. 
> Write a program and try to open/close  different ports(I will say have

> a minimum of four) randomly and very frequently(may be 30 seconds), I 
> am pretty sure you will see the deadlocks and it happens in the native

> call to interrptEventLoop in RXTXPort.java in removeEventListener() 
> method call.

Hi Pawan

I'll try to find a way to reproduce this.  One thing to note is that you
are using different kernel drivers (digi) to perform this task.  So I
probably will not be able to reproduce the exact same environment.

In general, multiport kernel drivers have been tested far less than
typical serial drivers.  This may or may not be an issue.

--
Trent Jarvi
tjarvi at qbang.org

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From cpine at wrsystems.com  Thu Jun 29 15:17:12 2006
From: cpine at wrsystems.com (Chris Pine)
Date: Thu, 29 Jun 2006 17:17:12 -0400
Subject: [Rxtx]  Controlling Individual Signals DTR and RTS
Message-ID: <MAIL4FJo0S8ACLEBajJ000005cf@mail4.wrsystems.com>

Dear Moussa Ba,
	I hope I am not being too forward, but we are having the exact same
issue with needing to control DTR from RXTX in Linux.  Did you ever have any
luck figuring it out?

Thank you very much for your time,

Chris Pine




From tjarvi at qbang.org  Thu Jun  1 11:13:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 11:13:40 -0600 (MDT)
Subject: [Rxtx] custom baud rate win32
In-Reply-To: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606011107210.30220@www>


Hi Daren

I can't imagine that 1953 is possibly the actual value on the UART.  Maybe 
if your baud base is very high with a custom serial board.  More likely, 
the driver just remembers that what you asked for and did something else.

I'll have more to say on the dcb->BaudRate after I try some things here. 
I have managed to do something like that in the past as a quick hack but 
it was for 14400.  I may have used the CBR_14400.

If we can't access this through the win32 API with protected mode, there 
is another layer of complication.  With real mode, it would be easy.
With protected mode, I assume there would have to be some kernel driver or 
a hook I'm not aware of to access the MCR directly (bang a memory 
addresss).



On Thu, 1 Jun 2006, Daren wrote:

> Trent,
> I have managed to successfully open the port at this speed using Realterm
> (available on sourceforge). From memory this uses DLPortIO.
>
> Using portmon.exe with realterm, even there it says that the port has opened
> at 1953.
>
> I changed termios.c:560 to
> dcb->BaudRate        = 1953 ;
>
> and it still opens the port at 9600.
>
> Daren
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Trent Jarvi
> Sent: Thursday, 1 June 2006 1:44 PM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] custom baud rate win32
>
> On Thu, 1 Jun 2006, Daren wrote:
>
>> Hi all,
>>
>> I downloaded 2.1.7-pre16 and managed to build it and get it going. I made
>> the changes as suggested by Peter Smith in an old post, by adding his code
>> to SerialImpl.c, uncommenting the TIOCGSERIAL and TIOCSSERIAL, and
> defining
>> ASYNC_SPD_CUST which is equal to 0x0030 (according to linus header
> files)..
>>
>>
>> Still not working, it opens the port at 9600 according to portmon.exe .
> Has
>> anyone managed to get this going at a custom rate?
>>
>> Here is the post I'm referring to:
>> http://marc.theaimsgroup.com/?l=rxtx&m=106270038110713&w=2
>>
>>
>> Thanks,
>> Daren
>>
>> ________________________________________
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
>> Daren
>> Sent: Wednesday, 31 May 2006 10:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] (no subject)
>>
>> Hi All,
>> I have been using rxtx for a little while and needed to get it working at
>> 1953, like a past user in the mailing list, who seemed to have got it
>> working by changing some C code.
>>
>> I wanted to build rxtx myself with these changes but don't know where to
>> start. I have windows here and FC4 at home. I downloaded cygwin and
> mingw32,
>> each build works by building a rxtxSerial.dll file that is ~11k smaller
> than
>> the original, and I always get the following error when testing the dll:
>>
>> Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at
>> PC=0x8077655
>> Function=[Unknown.]
>> Library=C:\opt\java\j2sdk1.4.2\jre\bin\client\jvm.dll
>>
>> NOTE: We are unable to locate the function name symbol for the error
>>      just occurred. Please refer to release documentation for possible
>>      reason and solutions.
>>
>>
>> Current Java thread:
>> 	at gnu.io.RXTXPort.open(Native Method)
>> 	- locked <0x1002c800> (a gnu.io.RXTXPort)
>> 	at gnu.io.RXTXPort.<init>(RXTXPort.java:84)
>>
>> Anyone know what im doing wrong?
>>
>>
>>
>>
>
> Hi Daren
>
> You are running into the same rats nest I'm looking at now.
>
> With win32 and specific custom baud rates, I'm not sure how this will go.
> I've got the Linux custom baud rates working very nicely.  I did much like
> the post you linked.  In fact I had forgot about that post.  You probably
> noticed that it becomes a bunch of dirt roads going noplace fast in
> termios.c for w32.
>
> I'm probably only going to get 14400, 28800, 128000 and 256000 working
> with the next release on w32.  I'll look a little further.  If you have an
> example w32 that works at 1953 I'd really like to hear.  Thats an unusual
> baud rate.
>
> Assuming a baud_base of 128000, your divisor will be 65 or 66.
>
> 128000/66=1939 -14
> 128000/65=1969 +13
>
> One thing I've been wondering about with linux is which would be the right
> answer in cases like this.  Right now it would just go with a baud base of
> 65 and ignore the modulus details.
>
> It appears to be a general trend for kernel developers to hide these
> details thinking that they can come up with a general solution.  Then they
> run out of time.  Perahps the solution is to help out but there are
> ultiple OS's rxtx supports making that nontrivial.
>
> If you look at current linux kernels, the 'tricks' above have been marked
> deprecated with no replacement.  Windows has some hard defines and then
> ancient near magic.  I've not looked at Solaris via Open Solaris yet but
> doubt there is a solution at all.
>
> What I'd try since you have the equipment and the monitor software is to
> hardcode the dcb->Baud in termios.c to 1953 (no define) and see what the
> w32 kernel does with it.  I think if you toss a baud rate at the driver it
> will try to come close.  You may try comming closer to a real baudrate
> based upon the 128000 baud base as shown above.
>
> If it works, it is worth looking at the rest of the ping/pong logic then.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
>
>
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From doug at dupreeinc.com  Thu Jun  1 13:22:13 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 12:22:13 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011107210.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
Message-ID: <447F3E65.1020809@dupreeinc.com>

Hello,

I am still trying to get this startup a little faster so I turned on the 
debug of a few of the classes.  The COM ports are scanned really fast 
and the delay occurs during the LPT scan.  The console output looks like 
this:

    ...
      LPT1
      LPT2
      LPT3
     valid port prefixes:
      LPT
    LPT1 LPT
    1 1
    LPT2 LPT
    2 2                                                                 
      * <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
    CommPortIdentifier:addPortName(LPT2)
    CommPortIdentifier:AddIdentifierToList()
    LPT3 LPT
    3 3
    CommPortIdentifier:addPortName(LPT3)
    CommPortIdentifier:AddIdentifierToList()
    CommPortIdentifier:AddIdentifierToList() index.next
    Leaving registerValidPorts()
    Have not implemented native_psmisc_report_owner(PortName)); in
    CommPortIdentifier
    CommPortIdentifier:getPortIdentifier(COM3)
    CommPortIdentifier:open(densConnect, 30000)
    RXTXCommDriver:getCommPort(COM3,1)
    ...

It would seem to me that if I removed the code for port scanning of LPT 
ports I could solve this problem. I would much prefer to use unmodified 
code if at all possible.  Do any of you have alternate suggestions?

Thank you for your time.

Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/cf433ee7/attachment-0012.html

From tjarvi at qbang.org  Thu Jun  1 13:52:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 13:52:06 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F3E65.1020809@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011348380.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I am still trying to get this startup a little faster so I turned on the 
> debug of a few of the classes.  The COM ports are scanned really fast and the 
> delay occurs during the LPT scan.  The console output looks like this:
>
>   ...
>     LPT1
>     LPT2
>     LPT3
>    valid port prefixes:
>     LPT
>   LPT1 LPT
>   1 1
>   LPT2 LPT
>   2 2                                                                      * 
> <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>   CommPortIdentifier:addPortName(LPT2)
>   CommPortIdentifier:AddIdentifierToList()
>   LPT3 LPT
>   3 3
>   CommPortIdentifier:addPortName(LPT3)
>   CommPortIdentifier:AddIdentifierToList()
>   CommPortIdentifier:AddIdentifierToList() index.next
>   Leaving registerValidPorts()
>   Have not implemented native_psmisc_report_owner(PortName)); in
>   CommPortIdentifier
>   CommPortIdentifier:getPortIdentifier(COM3)
>   CommPortIdentifier:open(densConnect, 30000)
>   RXTXCommDriver:getCommPort(COM3,1)
>   ...
>
> It would seem to me that if I removed the code for port scanning of LPT ports 
> I could solve this problem. I would much prefer to use unmodified code if at 
> all possible.  Do any of you have alternate suggestions?
>
> Thank you for your time.
>
> Doug
>


Does commenting out the LPT enumeration actually help?  There can often be 
differences between debug information printed and whats really going on. 
When you combine various environments the debug info can even come out in 
the wrong order.

I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
I do not think this problem is universal.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Thu Jun  1 14:29:44 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:29:44 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4E38.2060004@dupreeinc.com>

I will give it a try.  One thing to note on this PC is it has no LPT 
Parallel ports.

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
>>Hello,
>>
>>I am still trying to get this startup a little faster so I turned on the 
>>debug of a few of the classes.  The COM ports are scanned really fast and the 
>>delay occurs during the LPT scan.  The console output looks like this:
>>
>>  ...
>>    LPT1
>>    LPT2
>>    LPT3
>>   valid port prefixes:
>>    LPT
>>  LPT1 LPT
>>  1 1
>>  LPT2 LPT
>>  2 2                                                                      * 
>><<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>>  CommPortIdentifier:addPortName(LPT2)
>>  CommPortIdentifier:AddIdentifierToList()
>>  LPT3 LPT
>>  3 3
>>  CommPortIdentifier:addPortName(LPT3)
>>  CommPortIdentifier:AddIdentifierToList()
>>  CommPortIdentifier:AddIdentifierToList() index.next
>>  Leaving registerValidPorts()
>>  Have not implemented native_psmisc_report_owner(PortName)); in
>>  CommPortIdentifier
>>  CommPortIdentifier:getPortIdentifier(COM3)
>>  CommPortIdentifier:open(densConnect, 30000)
>>  RXTXCommDriver:getCommPort(COM3,1)
>>  ...
>>
>>It would seem to me that if I removed the code for port scanning of LPT ports 
>>I could solve this problem. I would much prefer to use unmodified code if at 
>>all possible.  Do any of you have alternate suggestions?
>>
>>Thank you for your time.
>>
>>Doug
>>
>>    
>>
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/dd31fed5/attachment-0012.html

From doug at dupreeinc.com  Thu Jun  1 14:36:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:36:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4FC8.9080106@dupreeinc.com>

Trent,

I commented out the section in RegisterScannedPorts() that adds the 
three LPT ports to the CandidateDeviceNames string array.  The 
application started immediately.  This is probably not the way to do 
this, but it was quick ,dirty, and worked.

It would be nice if there was a way to pole the OS to see if there is 
even a port there, though I guess this is what this code is suppose to do...

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
> ...
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From lynn at swcp.com  Thu Jun  1 14:49:34 2006
From: lynn at swcp.com (lynn@swcp.com)
Date: Thu, 1 Jun 2006 20:49:34 -0000
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>,
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <twig.1149194974.97617@swcp.com>

Perhaps we could add an argument to port enumeration where if not specified,
you get the default behavior that looks for everything.  With a new
constructor that has an argument(or more) you could optionally declare it to
not inspect printer ports.

Existing code would work as it always has.  New code could be smarter.

Lynn



Doug Thistlethwaite <doug at dupreeinc.com> said:

> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
> >On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
> >
> >  
> >
> > ...
> >
> >
> >Does commenting out the LPT enumeration actually help?  There can often be 
> >differences between debug information printed and whats really going on. 
> >When you combine various environments the debug info can even come out in 
> >the wrong order.
> >
> >I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
> >I do not think this problem is universal.
> >
> >--
> >Trent Jarvi
> >tjarvi at qbang.org
> >_______________________________________________
> >Rxtx mailing list
> >Rxtx at qbang.org
> >http://mailman.qbang.org/mailman/listinfo/rxtx
> >
> >
> >  
> >
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



-- 





From jredman at ergotech.com  Thu Jun  1 15:20:20 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 01 Jun 2006 15:20:20 -0600
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
Message-ID: <447F5A14.6010803@ergotech.com>

Doug,

If you specifically request ports, eg:

-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

or
 
-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

Depending upon the version  (Windows is COM1:COM2, etc. I assume).

Does it still enumerate the parallel ports?

Jim

Doug Thistlethwaite wrote:
> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
>> On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>
>>  
>>
>> ...
>>
>>
>> Does commenting out the LPT enumeration actually help?  There can often be 
>> differences between debug information printed and whats really going on. 
>> When you combine various environments the debug info can even come out in 
>> the wrong order.
>>
>> I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>> I do not think this problem is universal.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>>
>>  
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  1 16:49:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:49:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6EF4.7080709@dupreeinc.com>

I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
folder.  I created this file and added the following to the file:

gnu.io.rxtx.SerialPorts=COM3

and I get the following error on the console:
CommPortIdentifier:static initialization()
RXTXCommDriver {}
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
RXTXCommDriver:
    Jar version = RXTX-2.1-7
    native lib Version = RXTX-2.1-7
RXTXCommDriver:initialize()
checking for system-known ports of type 1
checking registry for ports of type 1

RXTXCommDriver:addSpecifiedPorts()
Exception in thread "main" java.lang.ExceptionInInitializerError
    at 
densconnect.SerialConnection.openConnection(SerialConnection.java:136)
    at densconnect.DensTalk.<init>(DensTalk.java:165)
    at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
    at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
    at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
    at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
Caused by: java.lang.NullPointerException
    at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
CommPortIdentifier:addPortName(COM3)
CommPortIdentifier:AddIdentifierToList()
CommPortIdentifier:AddIdentifierToList() null
...


It looks like it  read COM3 from the file, but it had the above 
exception that killed it.  The strange this is this error is from 
RXTXCommDriver initialize function (if statement line):

        OS = System.getProperty("os.name");
                System.out.println("OS NAME: " + OS);
        if(OS.toLowerCase().indexOf("linux") == -1)

OS is returning null, thus the error.

If the file is not present, it scans the ports and reads the OS.

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>Doug Thistlethwaite wrote:
>  
>
>>Trent,
>>
>>I commented out the section in RegisterScannedPorts() that adds the 
>>three LPT ports to the CandidateDeviceNames string array.  The 
>>application started immediately.  This is probably not the way to do 
>>this, but it was quick ,dirty, and worked.
>>
>>It would be nice if there was a way to pole the OS to see if there is 
>>even a port there, though I guess this is what this code is suppose to do...
>>
>>Doug
>>
>>Trent Jarvi wrote:
>>
>>    
>>
>>>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>>
>>> 
>>>
>>>...
>>>
>>>
>>>Does commenting out the LPT enumeration actually help?  There can often be 
>>>differences between debug information printed and whats really going on. 
>>>When you combine various environments the debug info can even come out in 
>>>the wrong order.
>>>
>>>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>>>I do not think this problem is universal.
>>>
>>>--
>>>Trent Jarvi
>>>tjarvi at qbang.org
>>>_______________________________________________
>>>Rxtx mailing list
>>>Rxtx at qbang.org
>>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>>
>>>
>>> 
>>>
>>>      
>>>
>>_______________________________________________
>>Rxtx mailing list
>>Rxtx at qbang.org
>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>    
>>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/bf4cca0e/attachment-0012.html

From doug at dupreeinc.com  Thu Jun  1 16:51:26 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:51:26 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6F6E.5060603@dupreeinc.com>

Jim,

I did not try your suggestion as I do not understand where I would put 
these command line parameters (it that is what they are).  It appears 
that using the properties file should do that same thing...

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>
>  
>


From doug at dupreeinc.com  Thu Jun  1 17:56:19 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 16:56:19 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
Message-ID: <447F7EA3.6050400@dupreeinc.com>

I think there is an error in the registerSpecifiedPorts() method.  When 
I have a gnu.io.rxtx.properties file in the ext directory, this function 
kills the System class  IF I call System.getProperty("os.name") before 
the call  to registerSpecifiedPorts(), it returns the os name, after the 
call, it returns null.  I have not played much with properties, except 
for reading them, so I don't really understand the code.

Doug



From doug at dupreeinc.com  Thu Jun  1 18:11:14 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 17:11:14 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F7EA3.6050400@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com>
Message-ID: <447F8222.3060402@dupreeinc.com>

Ok, I just hacked this thing up and got it to read the 
gnu.io.rxtx.properties file.

I commented out the line:
System.setProperties(p); in the method registerSpecifiedPorts() in 
RXTXCommDriver class.  I really don't understand that much about 
properties, but this call kills the System class.

I used the following in the gnu.io.rxtx.properties file:

gnu.io.rxtx.SerialPorts=COM3
gnu.io.rxtx.ParallelPorts=null

This allows the application to open very quickly without any errors.  
Whomever coded this class or somebody who understands properties should 
look at this method and make sure it is doing what they expect.

Doug




Doug Thistlethwaite wrote:

>I think there is an error in the registerSpecifiedPorts() method.  When 
>I have a gnu.io.rxtx.properties file in the ext directory, this function 
>kills the System class  IF I call System.getProperty("os.name") before 
>the call  to registerSpecifiedPorts(), it returns the os name, after the 
>call, it returns null.  I have not played much with properties, except 
>for reading them, so I don't really understand the code.
>
>Doug
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From tjarvi at qbang.org  Thu Jun  1 18:32:50 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 18:32:50 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F6EF4.7080709@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com> <447F6EF4.7080709@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011831510.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
> folder.  I created this file and added the following to the file:
>
> gnu.io.rxtx.SerialPorts=COM3
>
> and I get the following error on the console:
> CommPortIdentifier:static initialization()
> RXTXCommDriver {}
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
> RXTXCommDriver:
>   Jar version = RXTX-2.1-7
>   native lib Version = RXTX-2.1-7
> RXTXCommDriver:initialize()
> checking for system-known ports of type 1
> checking registry for ports of type 1
>
> RXTXCommDriver:addSpecifiedPorts()
> Exception in thread "main" java.lang.ExceptionInInitializerError
>   at densconnect.SerialConnection.openConnection(SerialConnection.java:136)
>   at densconnect.DensTalk.<init>(DensTalk.java:165)
>   at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
>   at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
>   at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
>   at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
> Caused by: java.lang.NullPointerException
>   at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
> CommPortIdentifier:addPortName(COM3)
> CommPortIdentifier:AddIdentifierToList()
> CommPortIdentifier:AddIdentifierToList() null
> ...
>
>

There is a solution for this bug.

http://bugzilla.qbang.org/show_bug.cgi?id=54

We have been horribly slow at getting the next round of patches in but 
they are comming.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  2 00:58:02 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 08:58:02 +0200
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F8222.3060402@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
Message-ID: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>

Hi Doug,

you wrote in an earlier message, that you would prefer an unchanged  
version. What about simply removing the RXTX parallel lib from the  
ext directory. This does not fix the bug, but it should fix your  
problem.

In general I think it is not a good idea to put the RXTX files in a  
system wide location. Putting the libs in the application folder and  
including the .jar in the application classpath (or application jar)  
is all that is required.

Regards,
Joachim

On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:

> Ok, I just hacked this thing up and got it to read the
> gnu.io.rxtx.properties file.
>
> I commented out the line:
> System.setProperties(p); in the method registerSpecifiedPorts() in
> RXTXCommDriver class.  I really don't understand that much about
> properties, but this call kills the System class.
>
> I used the following in the gnu.io.rxtx.properties file:
>
> gnu.io.rxtx.SerialPorts=COM3
> gnu.io.rxtx.ParallelPorts=null
>
> This allows the application to open very quickly without any errors.
> Whomever coded this class or somebody who understands properties  
> should
> look at this method and make sure it is doing what they expect.
>
> Doug
>
>
>
>
> Doug Thistlethwaite wrote:
>
>> I think there is an error in the registerSpecifiedPorts() method.   
>> When
>> I have a gnu.io.rxtx.properties file in the ext directory, this  
>> function
>> kills the System class  IF I call System.getProperty("os.name")  
>> before
>> the call  to registerSpecifiedPorts(), it returns the os name,  
>> after the
>> call, it returns null.  I have not played much with properties,  
>> except
>> for reading them, so I don't really understand the code.
>>
>> 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 antonio.luis at iscte.pt  Fri Jun  2 02:42:28 2006
From: antonio.luis at iscte.pt (=?ISO-8859-1?Q?Ant=F3nio_Lopes?=)
Date: Fri, 02 Jun 2006 09:42:28 +0100
Subject: [Rxtx] Exception when closing serial port
Message-ID: <447FF9F4.7060209@iscte.pt>

Hello everyone,
I've been using RXTX in a Java application in my Pocket PC.
The communication through the (bluetooth) serial port is working perfectly.

However, when I disconnect the app and close the serial port, sometimes I get 
the following error:

"1149237595000: RXTXPort:close detected bad File Descriptor"

The problem is that after this error occurs, the app is no longer able to 
connect to the serial port and I have to soft-reset the device in order to be 
able to connect to it again.

Any ideas on how to solve this issue?

Any help is appreciated.
Thanks,
regards,
-- 
Ant?nio Lopes

@contact: antonio.luis at iscte.pt
@work: ADETTI - ISCTE
@web: http://antonio.lopes.googlepages.com


From paul.klissner at sun.com  Fri Jun  2 02:44:34 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 01:44:34 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to RXTX
	again
Message-ID: <447FFA72.6040807@sun.com>

After looking into javax.comm 3.1 and what it would take to re-engineer it
to be compatible with RXTX platform libraries, I've decided, due my group's
priorities, complexity of the effort vs. benefit, and limited resources, 
to re-post
javax.comm 2.0 binaries on Sun's software download server, unsupported,
with disclaimers, as it was previously.

I don't think there will be any snags doing this from the standpoint of Sun
management or legality.  I will try to have it  posted there in the next 
week
or two, depending on how fast we can get it pushed through the process.

I'd like to think of this as a stop gap measure... ie. a compromise, 
where, at some
point in the not too distant future RXTX implements their own version of the
Java side of the API, as is normally done by javax.extension porters. 
That way
we avoid uncomfortable dependencies in the future.  And that really is 
the Java
development model.

Since RXTX already has the back-end code, porting the java code shouldn't
be a gargantuan effort at all, and RXTX will be in full control of the 
code top
to bottom. I think RXTX can do at least as good a job as the original 
coder.
Prepping 2.0 to be open sourced is more trouble than it is worth. ie. I 
don't
think the current implementation warrants it.

Ultimately, it would be nice to see someone open up a JSR and re-architect
the comm. API to overcome some of it's current design flaws (ie. be more
adaptable to modern platforms, more pluggable, better defined SPI, better
port ownership handling, etc...). A superior architecture would allow for
better collaboration in the future and better interchangeability of 
components
among projects.

Sun's 3.1 version of javax.comm, which is Sun's currently supported version,
has changes pertaining mostly to Sun platform-specific portmapping and has
some minor additional interactions with our back end code, but generally
has little bearing on RXTX. 

Paul



From joachim at buechse.de  Fri Jun  2 04:00:19 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 12:00:19 +0200
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
	RXTX again
In-Reply-To: <447FFA72.6040807@sun.com>
References: <447FFA72.6040807@sun.com>
Message-ID: <1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>

Good day Paul!

A clean architecture with loadable drivers and reusable code would be  
very beneficial for the future, I think everybody agrees. However  
this could be several years into the future. In the meantime, there  
is a real existing problem with IO support on Java. I have the strong  
feeling that most programmers want to code against one specification  
(javax.comm) and be able to replace the underlying implementation via  
a "plugin" on platforms where the SUN implementation is not  
sufficient. RXTX could be just this plugin (reusing very close to 0%  
of the javax.comm implementation but 100% of its API).

I want to propose an API addition and implementation change that will  
take less then 2 hours of manpower to implement and create a solution  
that can bridge the years until javax.comm has been based on a new  
architecture.

Looking at the javax.comm api at http://java.sun.com/products/ 
javacomm/reference/api/index.html I would like to propose the following:

The only entry point to javax.comm is CommPortIdentifier. It has 3  
static methods plus the constructor.

1) define one additional Interface

public interface CommProvider {
    CommPortIdentifier getPortIdentifier(CommPort port);
    CommPortIdentifier getPortIdentifier(String portName);
    Enumeration getPortIdentifiers ();
}

2) add one method to CommPortIdentifier

   public static setCustomCommProvider (CommProvider);

3) change the three static methods of CommPortIdentifier to dispatch  
to the CommProvider if it is set

4) change the constructor of CommPortIdentifier to

   public CommPortIdentifier(...) {
      if (isProviderSet && this.getClass() ==  
javax.comm.CommPortIdentifier) {
          throw new RuntimeException("illegal creation of  
CommPortIndentifier, custom CommProvider is in use");
      }

5) (this is optional, but would be very nice) automatically set a  
custom CommProvider if it is found on the classpath or defined via a  
system property.


The above 1) - 4) can be implemented in less than 1hour. 5) may take  
another hour. I agree that this is not the most elegant design, but  
it would solve a lot of problems with very little effort. It would  
certainly allow RXTX to move forward. If the javax.comm API needs to  
be redesigned completely this addition will not hurt, as people will  
move to the new API anyway and javax.comm 3.0 was so far never  
included in the main distribution.

Best regards,
Joachim

On 02.06.2006, at 10:44, Paul Klissner wrote:

> After looking into javax.comm 3.1 and what it would take to re- 
> engineer it
> to be compatible with RXTX platform libraries, I've decided, due my  
> group's
> priorities, complexity of the effort vs. benefit, and limited  
> resources,
> to re-post
> javax.comm 2.0 binaries on Sun's software download server,  
> unsupported,
> with disclaimers, as it was previously.
>
> I don't think there will be any snags doing this from the  
> standpoint of Sun
> management or legality.  I will try to have it  posted there in the  
> next
> week
> or two, depending on how fast we can get it pushed through the  
> process.
>
> I'd like to think of this as a stop gap measure... ie. a compromise,
> where, at some
> point in the not too distant future RXTX implements their own  
> version of the
> Java side of the API, as is normally done by javax.extension porters.
> That way
> we avoid uncomfortable dependencies in the future.  And that really is
> the Java
> development model.
>
> Since RXTX already has the back-end code, porting the java code  
> shouldn't
> be a gargantuan effort at all, and RXTX will be in full control of the
> code top
> to bottom. I think RXTX can do at least as good a job as the original
> coder.
> Prepping 2.0 to be open sourced is more trouble than it is worth.  
> ie. I
> don't
> think the current implementation warrants it.
>
> Ultimately, it would be nice to see someone open up a JSR and re- 
> architect
> the comm. API to overcome some of it's current design flaws (ie. be  
> more
> adaptable to modern platforms, more pluggable, better defined SPI,  
> better
> port ownership handling, etc...). A superior architecture would  
> allow for
> better collaboration in the future and better interchangeability of
> components
> among projects.
>
> Sun's 3.1 version of javax.comm, which is Sun's currently supported  
> version,
> has changes pertaining mostly to Sun platform-specific portmapping  
> and has
> some minor additional interactions with our back end code, but  
> generally
> has little bearing on RXTX.
>
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Fri Jun  2 09:10:13 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Fri, 2 Jun 2006 09:10:13 -0600 (MDT)
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <447FFA72.6040807@sun.com>
References: <447FFA72.6040807@sun.com>
Message-ID: <Pine.LNX.4.61.0606020906400.15971@www>

On Fri, 2 Jun 2006, Paul Klissner wrote:

> After looking into javax.comm 3.1 and what it would take to re-engineer it
> to be compatible with RXTX platform libraries, I've decided, due my group's
> priorities, complexity of the effort vs. benefit, and limited resources,
> to re-post
> javax.comm 2.0 binaries on Sun's software download server, unsupported,
> with disclaimers, as it was previously.
>

Hi Paul

To address users' immediate needs, we can release rxtx 2.0-7 (final) to 
match the 2.0 binaries from Sun when they are offered for download.

We can discuss potential long term solutions after that.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Fri Jun  2 10:20:09 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 02 Jun 2006 09:20:09 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
	<9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
Message-ID: <44806539.8080902@dupreeinc.com>

Thanks for the suggestion, I will give it a try.

Doug

Joachim Buechse wrote:

>Hi Doug,
>
>you wrote in an earlier message, that you would prefer an unchanged  
>version. What about simply removing the RXTX parallel lib from the  
>ext directory. This does not fix the bug, but it should fix your  
>problem.
>
>In general I think it is not a good idea to put the RXTX files in a  
>system wide location. Putting the libs in the application folder and  
>including the .jar in the application classpath (or application jar)  
>is all that is required.
>
>Regards,
>Joachim
>
>On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:
>
>  
>
>>Ok, I just hacked this thing up and got it to read the
>>gnu.io.rxtx.properties file.
>>
>>I commented out the line:
>>System.setProperties(p); in the method registerSpecifiedPorts() in
>>RXTXCommDriver class.  I really don't understand that much about
>>properties, but this call kills the System class.
>>
>>I used the following in the gnu.io.rxtx.properties file:
>>
>>gnu.io.rxtx.SerialPorts=COM3
>>gnu.io.rxtx.ParallelPorts=null
>>
>>This allows the application to open very quickly without any errors.
>>Whomever coded this class or somebody who understands properties  
>>should
>>look at this method and make sure it is doing what they expect.
>>
>>Doug
>>
>>
>>
>>
>>Doug Thistlethwaite wrote:
>>
>>    
>>
>>>I think there is an error in the registerSpecifiedPorts() method.   
>>>When
>>>I have a gnu.io.rxtx.properties file in the ext directory, this  
>>>function
>>>kills the System class  IF I call System.getProperty("os.name")  
>>>before
>>>the call  to registerSpecifiedPorts(), it returns the os name,  
>>>after the
>>>call, it returns null.  I have not played much with properties,  
>>>except
>>>for reading them, so I don't really understand the code.
>>>
>>>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
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060602/c8892a46/attachment-0012.html

From paul.klissner at sun.com  Fri Jun  2 12:09:26 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 11:09:26 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
Message-ID: <44807ED6.8000903@sun.com>

Joachim Buechse wrote:
> Good day Paul!
>
> A clean architecture with loadable drivers and reusable code would be  
> very beneficial for the future, I think everybody agrees. However  
> this could be several years into the future. In the meantime, there  
> is a real existing problem with IO support on Java. I have the strong  
> feeling that most programmers want to code against one specification  
> (javax.comm) and be able to replace the underlying implementation via  
> a "plugin" on platforms where the SUN implementation is not  
> sufficient. RXTX could be just this plugin (reusing very close to 0%  
> of the javax.comm implementation but 100% of its API).
>
> I want to propose an API addition and implementation change that will  
> take less then 2 hours of manpower to implement and create a solution  
> that can bridge the years until javax.comm has been based on a new  
> architecture.
>
> Looking at the javax.comm api at http://java.sun.com/products/ 
> javacomm/reference/api/index.html I would like to propose the following:
>
> The only entry point to javax.comm is CommPortIdentifier. It has 3  
> static methods plus the constructor.
>
> 1) define one additional Interface
>
> public interface CommProvider {
>     CommPortIdentifier getPortIdentifier(CommPort port);
>     CommPortIdentifier getPortIdentifier(String portName);
>     Enumeration getPortIdentifiers ();
> }
>
> 2) add one method to CommPortIdentifier
>
>    public static setCustomCommProvider (CommProvider);
>
> 3) change the three static methods of CommPortIdentifier to dispatch  
> to the CommProvider if it is set
>
> 4) change the constructor of CommPortIdentifier to
>
>    public CommPortIdentifier(...) {
>       if (isProviderSet && this.getClass() ==  
> javax.comm.CommPortIdentifier) {
>           throw new RuntimeException("illegal creation of  
> CommPortIndentifier, custom CommProvider is in use");
>       }
>
> 5) (this is optional, but would be very nice) automatically set a  
> custom CommProvider if it is found on the classpath or defined via a  
> system property.
>
>
> The above 1) - 4) can be implemented in less than 1hour. 5) may take  
> another hour. I agree that this is not the most elegant design, but  
> it would solve a lot of problems with very little effort. It would  
> certainly allow RXTX to move forward. If the javax.comm API needs to  
> be redesigned completely this addition will not hurt, as people will  
> move to the new API anyway and javax.comm 3.0 was so far never  
> included in the main distribution.
>
> Best regards,
> Joachi
I'm afraid modifying the interface classes isn't my call.  There was 
actually
a TCK written and one of the tests was to ensure that the interface classes
match the spec.  Thus my hands have already been tied since this project
was essentially grandfathered into the JCP.

That's why we need to open a new JSR and find someone who wants
to be the spec lead, and go in with a new reference implementation.
I'm not sure why it would have to take years, since this isn't bleeding edge
technology and there are only so many things that can be done with it,
and we already have practical experience about many functional aspects
that we could cite precedence on.

As it becomes clear that the specification is being accepted completely
or by-and-large by the community, nothing would stop people from
starting adapting to the new API (using the reference implementation or
porting it) and using it in their projects prior to it's final community and
JCP approval, since approval is required only to make it official and
get the "100% pure java" certification for platform ports.

You have one idea already.  Why don't you implement it, solicit some
design feedback from Sun and the RXTX, and create a functional
implementation that addresses the needs of the community, then
we can document it and open a JSR.  That's it.  It should march through
the approval stages reasonably quickly I would imagine, and meantime
RXTX could start using it.

Paul




From doug at dupreeinc.com  Fri Jun  2 12:45:01 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 02 Jun 2006 11:45:01 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
	<9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
Message-ID: <4480872D.6000605@dupreeinc.com>

Joachim,

Thank you for the suggestion.  I restored the jar file to the one I 
downloaded, moved the dll files into the project directory, and added 
the jar to the classpath.  The SerialDemo program that was included with 
the Sun commapi started in 12 seconds instead of the 58 seconds when the 
parallel dll is present.  I did get the startup time to about a second 
by modifying the java code and adding the properties file but this is 
probably not a good idea.

Doug

Joachim Buechse wrote:

>Hi Doug,
>
>you wrote in an earlier message, that you would prefer an unchanged  
>version. What about simply removing the RXTX parallel lib from the  
>ext directory. This does not fix the bug, but it should fix your  
>problem.
>
>In general I think it is not a good idea to put the RXTX files in a  
>system wide location. Putting the libs in the application folder and  
>including the .jar in the application classpath (or application jar)  
>is all that is required.
>
>Regards,
>Joachim
>
>On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:
>
>  
>
>>Ok, I just hacked this thing up and got it to read the
>>gnu.io.rxtx.properties file.
>>
>>I commented out the line:
>>System.setProperties(p); in the method registerSpecifiedPorts() in
>>RXTXCommDriver class.  I really don't understand that much about
>>properties, but this call kills the System class.
>>
>>I used the following in the gnu.io.rxtx.properties file:
>>
>>gnu.io.rxtx.SerialPorts=COM3
>>gnu.io.rxtx.ParallelPorts=null
>>
>>This allows the application to open very quickly without any errors.
>>Whomever coded this class or somebody who understands properties  
>>should
>>look at this method and make sure it is doing what they expect.
>>
>>Doug
>>
>>
>>
>>
>>Doug Thistlethwaite wrote:
>>
>>    
>>
>>>I think there is an error in the registerSpecifiedPorts() method.   
>>>When
>>>I have a gnu.io.rxtx.properties file in the ext directory, this  
>>>function
>>>kills the System class  IF I call System.getProperty("os.name")  
>>>before
>>>the call  to registerSpecifiedPorts(), it returns the os name,  
>>>after the
>>>call, it returns null.  I have not played much with properties,  
>>>except
>>>for reading them, so I don't really understand the code.
>>>
>>>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
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060602/3c0e420f/attachment-0012.html

From joachim at buechse.de  Fri Jun  2 13:46:36 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 21:46:36 +0200
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
	RXTX again
In-Reply-To: <44807ED6.8000903@sun.com>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
	<44807ED6.8000903@sun.com>
Message-ID: <6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>

Hello Paul,

of course, the basic change I suggested could be done "hidden".  The  
CommProvider interface could live somewhere in sun.xyz.*
The setCustomCommProvider method would not be in CommPortIdentifier  
but also somewhere in sun.xyz.* This would be an unofficial feature,  
the official interface stays exactly the same. However RXTX (and  
others) could access the hidden interface.

Don't get me wrong, I don't want to harass you into making changes  
you don't like (which probably wouldn't work anyway;-). But I'm a  
long time Java programmer and seeing the state of cross platform  
serial support for Java makes me feel really sad. In fact, when I  
started to look into Java serial port programming some months ago I  
was very surprised that javax.comm never made it into the JDK.

I'm sorry that I did not contribute my feedback to the JSR for  
javax.comm 3.0. However at the time I didn't do serial port  
programming in Java. I agree that a new JSR should be opened - I'm  
not an expert on JSRs or the JCP process, but from looking quickly  
over the progress of some JSRs I would be very surprised if we can  
have a new version in less then a year. In the meanwhile some people  
will start using javax.comm 3.0 (which can not be supported by RXTX),  
some will use javax.comm 2.0 (which means the 2.0.7 release of RXTX  
still needs to be maintained). This may get even worse if eg Apple  
decides to port and include javax.comm 3.0 at which point it may get  
very tricky to write a cross platform Java application.

All of this simply means, that we are loosing a lot of man-power that  
could otherwise be invested in building a clean solution and/or to  
add features that are becoming more and more important (USB events...).

In the automation / machine control universe Java makes a lot of  
sense. Right now many people are migrating to Linux or from  
propietary systems (even DOS) to Windows. Writing the control/ 
configuration applications in Java is the kings way to unify the code  
base.

Best regards,
Joachim


On 02.06.2006, at 20:09, Paul Klissner wrote:

> Joachim Buechse wrote:
>> Good day Paul!
>>
>> A clean architecture with loadable drivers and reusable code would be
>> very beneficial for the future, I think everybody agrees. However
>> this could be several years into the future. In the meantime, there
>> is a real existing problem with IO support on Java. I have the strong
>> feeling that most programmers want to code against one specification
>> (javax.comm) and be able to replace the underlying implementation via
>> a "plugin" on platforms where the SUN implementation is not
>> sufficient. RXTX could be just this plugin (reusing very close to 0%
>> of the javax.comm implementation but 100% of its API).
>>
>> I want to propose an API addition and implementation change that will
>> take less then 2 hours of manpower to implement and create a solution
>> that can bridge the years until javax.comm has been based on a new
>> architecture.
>>
>> Looking at the javax.comm api at http://java.sun.com/products/
>> javacomm/reference/api/index.html I would like to propose the  
>> following:
>>
>> The only entry point to javax.comm is CommPortIdentifier. It has 3
>> static methods plus the constructor.
>>
>> 1) define one additional Interface
>>
>> public interface CommProvider {
>>     CommPortIdentifier getPortIdentifier(CommPort port);
>>     CommPortIdentifier getPortIdentifier(String portName);
>>     Enumeration getPortIdentifiers ();
>> }
>>
>> 2) add one method to CommPortIdentifier
>>
>>    public static setCustomCommProvider (CommProvider);
>>
>> 3) change the three static methods of CommPortIdentifier to dispatch
>> to the CommProvider if it is set
>>
>> 4) change the constructor of CommPortIdentifier to
>>
>>    public CommPortIdentifier(...) {
>>       if (isProviderSet && this.getClass() ==
>> javax.comm.CommPortIdentifier) {
>>           throw new RuntimeException("illegal creation of
>> CommPortIndentifier, custom CommProvider is in use");
>>       }
>>
>> 5) (this is optional, but would be very nice) automatically set a
>> custom CommProvider if it is found on the classpath or defined via a
>> system property.
>>
>>
>> The above 1) - 4) can be implemented in less than 1hour. 5) may take
>> another hour. I agree that this is not the most elegant design, but
>> it would solve a lot of problems with very little effort. It would
>> certainly allow RXTX to move forward. If the javax.comm API needs to
>> be redesigned completely this addition will not hurt, as people will
>> move to the new API anyway and javax.comm 3.0 was so far never
>> included in the main distribution.
>>
>> Best regards,
>> Joachi
> I'm afraid modifying the interface classes isn't my call.  There was
> actually
> a TCK written and one of the tests was to ensure that the interface  
> classes
> match the spec.  Thus my hands have already been tied since this  
> project
> was essentially grandfathered into the JCP.
>
> That's why we need to open a new JSR and find someone who wants
> to be the spec lead, and go in with a new reference implementation.
> I'm not sure why it would have to take years, since this isn't  
> bleeding edge
> technology and there are only so many things that can be done with it,
> and we already have practical experience about many functional aspects
> that we could cite precedence on.
>
> As it becomes clear that the specification is being accepted  
> completely
> or by-and-large by the community, nothing would stop people from
> starting adapting to the new API (using the reference  
> implementation or
> porting it) and using it in their projects prior to it's final  
> community and
> JCP approval, since approval is required only to make it official and
> get the "100% pure java" certification for platform ports.
>
> You have one idea already.  Why don't you implement it, solicit some
> design feedback from Sun and the RXTX, and create a functional
> implementation that addresses the needs of the community, then
> we can document it and open a JSR.  That's it.  It should march  
> through
> the approval stages reasonably quickly I would imagine, and meantime
> RXTX could start using it.
>
> Paul
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From paul.klissner at sun.com  Fri Jun  2 14:38:49 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 13:38:49 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
	<44807ED6.8000903@sun.com>
	<6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>
Message-ID: <4480A1D9.5060106@sun.com>

Joachim Buechse wrote:
> Hello Paul,
>
> of course, the basic change I suggested could be done "hidden".  The  
> CommProvider interface could live somewhere in sun.xyz.*
> The setCustomCommProvider method would not be in CommPortIdentifier  
> but also somewhere in sun.xyz.* This would be an unofficial feature,  
> the official interface stays exactly the same. However RXTX (and  
> others) could access the hidden interface.
>
> Don't get me wrong, I don't want to harass you into making changes  
> you don't like (which probably wouldn't work anyway;-). But I'm a  
> long time Java programmer and seeing the state of cross platform  
> serial support for Java makes me feel really sad. In fact, when I  
> started to look into Java serial port programming some months ago I  
> was very surprised that javax.comm never made it into the JDK.
>
> I'm sorry that I did not contribute my feedback to the JSR for  
> javax.comm 3.0. 
There was no JSR for 3.0, because we didn't have the resources to make 
the commitment.
Yet Sun needed to add support for platform-dependent port name mapping, 
which had to
be done 'under the hood', since the API isn't designed to handle that in 
a pluggable way.
But these quick fixes aren't the right approach, they just kick the dog 
down the road,
setting bad precedent, inviting confusion and more intractable problems 
(such as the
one plaguing us now).

My changes could have been layered better, it was a trade off between 
achieving an
ideal architecture, trying to find internal reviewers, and meet the 
needs of big customers
in a timely way.  Thus my namespace changes collided with RXTX's 
dependencies.
I was unaware of Jagane's rogue agreement made with the RXTX community 7 
years ago,
before Jagane left Sun.  I think this was a wag-the-dog situation.

Now it is time to do it right, and I don't think it is going to be as 
much trouble as people
some people fear. If RXTX wants to sponsor the JSR and seed a new spec, 
Sun can join
the Expert Group.  And we'd be largely in agreement, since we're not 
talking about
humongous changes, and looking for mutually beneficial changes. The core 
API is already
largely proved and tested.
> However at the time I didn't do serial port  
> programming in Java. I agree that a new JSR should be opened - I'm  
> not an expert on JSRs or the JCP process, but from looking quickly  
> over the progress of some JSRs I would be very surprised if we can  
> have a new version in less then a year. 
*Approved*  But that doesn't mean the spec couldn't be 99.9% stable 
before that.  Once
the delta rate declines and changes approach nil, people could start 
adapting to the API in
advance of formal approval.   It isn't going to be drawn out like 
javax.usb, which was new
technology, a very complex API, and involved precedent setting corporate 
disputes and
policy issues to resolve.

> In the meanwhile some people  
> will start using javax.comm 3.0 (which can not be supported by RXTX),  
> some will use javax.comm 2.0 (which means the 2.0.7 release of RXTX  
> still needs to be maintained). This may get even worse if eg Apple  
> decides to port and include javax.comm 3.0 at which point it may get  
> very tricky to write a cross platform Java application.
>   
The interfaces haven't changed since 1.0.  If we open a JSR ,we can 
contact Apple and
allow them to be on the E.G., if they want.  That might make the JSR a 
bit more drawn out,
but then we'd arrive ultimately arrive at a best-of-all-worlds API that 
most people would
accept, perhaps forever, and arrive at a respectable set of compromises.

-Paul

> All of this simply means, that we are loosing a lot of man-power that  
> could otherwise be invested in building a clean solution and/or to  
> add features that are becoming more and more important (USB events...).
>
> In the automation / machine control universe Java makes a lot of  
> sense. Right now many people are migrating to Linux or from  
> propietary systems (even DOS) to Windows. Writing the control/ 
> configuration applications in Java is the kings way to unify the code  
> base.
>
> Best regards,
> Joachim
>
>
> On 02.06.2006, at 20:09, Paul Klissner wrote:
>
>   
>> Joachim Buechse wrote:
>>     
>>> Good day Paul!
>>>
>>> A clean architecture with loadable drivers and reusable code would be
>>> very beneficial for the future, I think everybody agrees. However
>>> this could be several years into the future. In the meantime, there
>>> is a real existing problem with IO support on Java. I have the strong
>>> feeling that most programmers want to code against one specification
>>> (javax.comm) and be able to replace the underlying implementation via
>>> a "plugin" on platforms where the SUN implementation is not
>>> sufficient. RXTX could be just this plugin (reusing very close to 0%
>>> of the javax.comm implementation but 100% of its API).
>>>
>>> I want to propose an API addition and implementation change that will
>>> take less then 2 hours of manpower to implement and create a solution
>>> that can bridge the years until javax.comm has been based on a new
>>> architecture.
>>>
>>> Looking at the javax.comm api at http://java.sun.com/products/
>>> javacomm/reference/api/index.html I would like to propose the  
>>> following:
>>>
>>> The only entry point to javax.comm is CommPortIdentifier. It has 3
>>> static methods plus the constructor.
>>>
>>> 1) define one additional Interface
>>>
>>> public interface CommProvider {
>>>     CommPortIdentifier getPortIdentifier(CommPort port);
>>>     CommPortIdentifier getPortIdentifier(String portName);
>>>     Enumeration getPortIdentifiers ();
>>> }
>>>
>>> 2) add one method to CommPortIdentifier
>>>
>>>    public static setCustomCommProvider (CommProvider);
>>>
>>> 3) change the three static methods of CommPortIdentifier to dispatch
>>> to the CommProvider if it is set
>>>
>>> 4) change the constructor of CommPortIdentifier to
>>>
>>>    public CommPortIdentifier(...) {
>>>       if (isProviderSet && this.getClass() ==
>>> javax.comm.CommPortIdentifier) {
>>>           throw new RuntimeException("illegal creation of
>>> CommPortIndentifier, custom CommProvider is in use");
>>>       }
>>>
>>> 5) (this is optional, but would be very nice) automatically set a
>>> custom CommProvider if it is found on the classpath or defined via a
>>> system property.
>>>
>>>
>>> The above 1) - 4) can be implemented in less than 1hour. 5) may take
>>> another hour. I agree that this is not the most elegant design, but
>>> it would solve a lot of problems with very little effort. It would
>>> certainly allow RXTX to move forward. If the javax.comm API needs to
>>> be redesigned completely this addition will not hurt, as people will
>>> move to the new API anyway and javax.comm 3.0 was so far never
>>> included in the main distribution.
>>>
>>> Best regards,
>>> Joachi
>>>       
>> I'm afraid modifying the interface classes isn't my call.  There was
>> actually
>> a TCK written and one of the tests was to ensure that the interface  
>> classes
>> match the spec.  Thus my hands have already been tied since this  
>> project
>> was essentially grandfathered into the JCP.
>>
>> That's why we need to open a new JSR and find someone who wants
>> to be the spec lead, and go in with a new reference implementation.
>> I'm not sure why it would have to take years, since this isn't  
>> bleeding edge
>> technology and there are only so many things that can be done with it,
>> and we already have practical experience about many functional aspects
>> that we could cite precedence on.
>>
>> As it becomes clear that the specification is being accepted  
>> completely
>> or by-and-large by the community, nothing would stop people from
>> starting adapting to the new API (using the reference  
>> implementation or
>> porting it) and using it in their projects prior to it's final  
>> community and
>> JCP approval, since approval is required only to make it official and
>> get the "100% pure java" certification for platform ports.
>>
>> You have one idea already.  Why don't you implement it, solicit some
>> design feedback from Sun and the RXTX, and create a functional
>> implementation that addresses the needs of the community, then
>> we can document it and open a JSR.  That's it.  It should march  
>> through
>> the approval stages reasonably quickly I would imagine, and meantime
>> RXTX could start using it.
>>
>> Paul
>>
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at 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  Sat Jun  3 18:15:24 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 18:15:24 -0600 (MDT)
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
Message-ID: <Pine.LNX.4.61.0606031715100.10890@www>


The attached patch allows baud rates of 14400, 28800, 128000 and 256000.

That was my goal.

[import standard disclaimer]

But I took some time to look a little further.  I got custom baud rates 
working enough that someone (perhaps me) can properly fix them in the 
future.  Proof of concept.

As an undocumented bonus, you can toss random baudrates (say 1953), at the 
API and it will set it to something close to that on windows and linux. 
Solaris should say the baud rate is not supported but I have not tested it 
yet.  Mac OS X behavior is unknown at this point.  Just dont expect 
correct behavior at ~8192-9009 baudrates or baudrates less than 20 on 
windows; these baud rates overlap with defines in win32termios.h.  I 
conveniently closed my eyes there.  Try another value close.  On Linux, a 
baud base and divisor are guestimated and set.  On windows, we wave pixie 
dust over the kernel driver and hope.  Do not expect pixie dust and 
guestimates to be the same on windows and linux.  They may well round to 
different values in yet to be tested ways.  There are only so many 
divisors.  If it isn't working, try a little higher or lower.

In the example of 1953 for instance, there is no divisor for commodity 
hardware that comes to that baudrate.  We just come close on one side or 
the other.  If tools tell you they got 1953 exactly, the tools may be 
questionable and just reading values not directly related to the actual 
hardware settings.

These fixes have been tested on Linux and Windows while using an 
oscilloscope to confirm they change relative to known baudrates at 9600, 
14400*, 19200, 28800* (and 1800, 1953** and 2400).

* = previously unsupported.
** = still not supported but probably works from what I saw.

There could be future discussion in this area.  For now this is working 
for almost all unusual baud rate demands.  Cleaning up the custom baud 
rate should be easier with a working starting point.  Baud bases other 
than 128000 have not been characterized.  Yes.. this overlapps with two of 
the baud rates enabled.

Feedback and ideas are welcome.

--
Trent Jarvi
tjarvi at qbang.org
-------------- next part --------------
Index: SerialImp.c
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v
retrieving revision 1.46.2.187
diff -u -r1.46.2.187 SerialImp.c
--- SerialImp.c	29 Jan 2006 22:19:04 -0000	1.46.2.187
+++ SerialImp.c	3 Jun 2006 23:12:40 -0000
@@ -793,6 +793,19 @@
 		result &= ~TIOCM_DTR;
 		ioctl( fd, TIOCMSET, &result );
 	}
+	/*
+	   B38400 is a special case in Linux for custom baud rates.
+
+	   We just treat this as a custom speed for now.  If you take this ifdef
+	   out and select baud rates 38400 then 28800 then 38400, you will get
+	   a final baud rate of 28800 because you did not update the divisor.
+
+	   See the next ifdef below for the divisor.
+	*/
+#if defined(TIOCGSERIAL)
+	if ( cspeed == B38400 )
+		cspeed = 38400;
+#endif /* TIOCGSERIAL */
 	if(     cfsetispeed( &ttyset, cspeed ) < 0 ||
 		cfsetospeed( &ttyset, cspeed ) < 0 )
 	{
@@ -814,6 +827,7 @@
 		*/
 
 #if defined(TIOCGSERIAL)
+		ioctl( fd, TIOCGSERIAL, &sstruct );
 		sstruct.custom_divisor = ( sstruct.baud_base/cspeed );
 		cspeed = B38400;
 #endif /* TIOCGSERIAL */
@@ -827,7 +841,7 @@
 #if defined(TIOCSSERIAL)
 		/*  It is assumed Win32 does this for us */
 		if (	sstruct.baud_base < 1 ||
-			ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
+		ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
 		{
 			return( 1 );
 		}
Index: termios.c
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v
retrieving revision 1.9.2.56
diff -u -r1.9.2.56 termios.c
--- termios.c	16 Jan 2006 02:50:32 -0000	1.9.2.56
+++ termios.c	3 Jun 2006 23:12:40 -0000
@@ -323,8 +323,8 @@
 		case CBR_3500000:	return( B3500000 );
 		case CBR_4000000:	return( B4000000 );
 		default:
-			set_errno(EINVAL );
-			return -1;
+			/* assume custom baudrate */
+			return( Baud );
 	}
 }
 
@@ -361,12 +361,13 @@
 		case B9600:	ret = CBR_9600;		break;
 		case B14400:	ret = CBR_14400;	break;
 		case B19200:	ret = CBR_19200;	break;
+		case B28800:	ret = CBR_28800;	break;
 		case B38400:	ret = CBR_38400;	break;
 		case B57600:	ret = CBR_57600;	break;
 		case B115200:	ret = CBR_115200;	break;
 		case B128000:	ret = CBR_128000;	break;
-		case B256000: 	ret = CBR_256000;	break;
 		case B230400:	ret = CBR_230400;	break;
+		case B256000: 	ret = CBR_256000;	break;
 		case B460800:	ret = CBR_460800;	break;
 		case B500000:	ret = CBR_500000;	break;
 		case B576000:	ret = CBR_576000;	break;
@@ -381,10 +382,8 @@
 		case B4000000:	ret = CBR_4000000;	break;
 	
 		default:
-			fprintf( stderr, "B_to_CBR: invalid baudrate: %#o\n",
-				Baud );
-			set_errno( EINVAL );
-			return -1;
+			/* assume custom baudrate */
+			return Baud;
 	}
 	LEAVE( "B_to_CBR" );
 	return ret;
@@ -708,12 +707,9 @@
 	ENTER( "init_serial_struct" );
 
 	/*
-	FIXME
-
-	This needs to use inb() to read the actual baud_base
-	and divisor from the UART registers.  Question is how
-	far do we take this?
-
+	use of custom_divisor and baud_base requires access to
+	kernel space.  The kernel does try its best if you just
+	toss a baud rate at it though.
 	*/
 
 	sstruct->custom_divisor = 0;
@@ -1678,16 +1674,17 @@
 {
 	char message[80];
 	ENTER( "cfsetospeed" );
+	/* clear baudrate */
+	s_termios->c_cflag &= ~CBAUD;
 	if ( speed & ~CBAUD )
 	{
 		sprintf( message, "cfsetospeed: not speed: %#o\n", speed );
 		report( message );
-		return 0;
+		/* continue assuming its a custom baudrate */
+		s_termios->c_cflag |= B38400;  /* use 38400 during custom */
+		s_termios->c_cflag |= CBAUDEX; /* use CBAUDEX for custom */
 	}
-	s_termios->c_ispeed = s_termios->c_ospeed = speed;
-	/* clear baudrate */
-	s_termios->c_cflag &= ~CBAUD;
-	if( speed )
+	else if( speed )
 	{
 		s_termios->c_cflag |= speed;
 	}
@@ -1696,6 +1693,7 @@
 		/* PC blows up with speed 0 handled in Java */
 		s_termios->c_cflag |= B9600;
 	}
+	s_termios->c_ispeed = s_termios->c_ospeed = speed;
 	LEAVE( "cfsetospeed" );
 	return 1;
 }
@@ -1767,25 +1765,6 @@
 }
 
 /*----------------------------------------------------------
-serial_struct_to_DCB()
-
-   accept:      
-   perform:     
-   return:      
-   exceptions:  
-   win32api:     None
-   comments:    
-----------------------------------------------------------*/
-int serial_struct_to_DCB( struct serial_struct *sstruct, DCB *dcb )
-{
-	/* 5 Baud rate fix
-	sstruct.baud_base
-	sstruct.custom_divisor = ( sstruct.baud_base/cspeed );
-	*/
-	return(0);
-}
-
-/*----------------------------------------------------------
 termios_to_DCB()
 
    accept:      
@@ -1798,7 +1777,8 @@
 int termios_to_DCB( struct termios *s_termios, DCB *dcb )
 {
 	ENTER( "termios_to_DCB" );
-	s_termios->c_ispeed = s_termios->c_ospeed = s_termios->c_cflag & CBAUD;
+	if ( !(s_termios->c_cflag & CBAUDEX) )
+		s_termios->c_ispeed = s_termios->c_ospeed = s_termios->c_cflag & CBAUD;
 	dcb->BaudRate        = B_to_CBR( s_termios->c_ispeed );
 	dcb->ByteSize = termios_to_bytesize( s_termios->c_cflag );
 
@@ -2863,11 +2843,6 @@
 			GetCommState( index->hComm, dcb );
 
 			index->sstruct = va_arg( ap, struct serial_struct * );
-			if ( serial_struct_to_DCB( index->sstruct, dcb ) < 0 )
-			{
-				va_end( ap );
-				return -1;
-			}
 
 			report( "TIOCSSERIAL\n" );
 			free(dcb);
Index: win32termios.h
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v
retrieving revision 1.5.2.28
diff -u -r1.5.2.28 win32termios.h
--- win32termios.h	30 Jun 2005 20:23:26 -0000	1.5.2.28
+++ win32termios.h	3 Jun 2006 23:12:40 -0000
@@ -279,7 +279,7 @@
 #define XTABS	01000000 /* Hmm.. Linux/i386 considers this part of TABDLY.. */
 
 /* c_cflag bit meaning */
-# define CBAUD	0010017
+#define  CBAUD  0030017
 #define  B0	0000000		/* hang up */
 #define  B50	0000001
 #define  B75	0000002
@@ -312,13 +312,16 @@
 #define  B3500000 0010016
 #define  B4000000 0010017
 
-/* glue for unsupported linux speeds see also SerialImp.h */
-/* hosed */
-
-#define B14400		1010001
-#define B28800		1010002
-#define B128000		1010003
-#define B256000		1010004
+/*
+	glue for unsupported linux speeds see also SerialImp.h 
+	custom baud rates around 8192-9000 will not work because
+	of these.
+*/
+
+#define B14400		0020001
+#define B28800		0020002
+#define B128000		0020003
+#define B256000		0020004
 
 #define EXTA B19200
 #define EXTB B38400
@@ -356,8 +359,10 @@
 
 /* glue for unsupported windows speeds */
 
-#define CBR_230400	230400
 #define CBR_28800	28800
+#define CBR_128000	128000
+#define CBR_230400	230400
+#define CBR_256000	256000
 #define CBR_460800	460800
 #define CBR_500000	500000
 #define CBR_576000	576000

From impakt01 at optusnet.com.au  Sat Jun  3 18:30:37 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 10:30:37 +1000
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
In-Reply-To: <Pine.LNX.4.61.0606031715100.10890@www>
Message-ID: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>

Hi Trent,
I'd love to try the patch but I can't get the latest build compiling, only
pre16. 

Can you attach the rxtxSerial.dll file with this patch?

Also, I hardcoded 1953 in a couple more places last night on pre16 and it
managed to open the port at the right speed, but stopped receiving anything
after 100-150 bytes, even though more data was getting sent to the port.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 10:15 AM
To: rxtx at qbang.org
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.


The attached patch allows baud rates of 14400, 28800, 128000 and 256000.

That was my goal.

[import standard disclaimer]

But I took some time to look a little further.  I got custom baud rates 
working enough that someone (perhaps me) can properly fix them in the 
future.  Proof of concept.

As an undocumented bonus, you can toss random baudrates (say 1953), at the 
API and it will set it to something close to that on windows and linux. 
Solaris should say the baud rate is not supported but I have not tested it 
yet.  Mac OS X behavior is unknown at this point.  Just dont expect 
correct behavior at ~8192-9009 baudrates or baudrates less than 20 on 
windows; these baud rates overlap with defines in win32termios.h.  I 
conveniently closed my eyes there.  Try another value close.  On Linux, a 
baud base and divisor are guestimated and set.  On windows, we wave pixie 
dust over the kernel driver and hope.  Do not expect pixie dust and 
guestimates to be the same on windows and linux.  They may well round to 
different values in yet to be tested ways.  There are only so many 
divisors.  If it isn't working, try a little higher or lower.

In the example of 1953 for instance, there is no divisor for commodity 
hardware that comes to that baudrate.  We just come close on one side or 
the other.  If tools tell you they got 1953 exactly, the tools may be 
questionable and just reading values not directly related to the actual 
hardware settings.

These fixes have been tested on Linux and Windows while using an 
oscilloscope to confirm they change relative to known baudrates at 9600, 
14400*, 19200, 28800* (and 1800, 1953** and 2400).

* = previously unsupported.
** = still not supported but probably works from what I saw.

There could be future discussion in this area.  For now this is working 
for almost all unusual baud rate demands.  Cleaning up the custom baud 
rate should be easier with a working starting point.  Baud bases other 
than 128000 have not been characterized.  Yes.. this overlapps with two of 
the baud rates enabled.

Feedback and ideas are welcome.

--
Trent Jarvi
tjarvi at qbang.org



From tjarvi at qbang.org  Sat Jun  3 19:05:11 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 19:05:11 -0600 (MDT)
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
In-Reply-To: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>
References: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606031840400.10890@www>

On Sun, 4 Jun 2006, Daren wrote:

> Hi Trent,
> I'd love to try the patch but I can't get the latest build compiling, only
> pre16.
>
> Can you attach the rxtxSerial.dll file with this patch?
>
> Also, I hardcoded 1953 in a couple more places last night on pre16 and it
> managed to open the port at the right speed, but stopped receiving anything
> after 100-150 bytes, even though more data was getting sent to the port.
>


ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing

I dont think they will hang.  But I was just testing via loopback/break 
out box/scope.

I'll be putting about 10 patches and another set of binaries in that 
directory shortly.  For now the binaries should just have the baud_rate 
fix.

I'll announce all the patches at once.  but wont be releasing 2.1-8 right 
away.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Sat Jun  3 21:00:01 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 21:00:01 -0600 (MDT)
Subject: [Rxtx] CVS for 2.1 should have everything
Message-ID: <Pine.LNX.4.61.0606032056190.10890@www>


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org


From impakt01 at optusnet.com.au  Sat Jun  3 21:08:14 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 13:08:14 +1000
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <Pine.LNX.4.61.0606032056190.10890@www>
Message-ID: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>

Hi Trent,
I tried the latest dll and it opens the port, receives 100-200 bytes and
then stops receiving anything else..

I'll keep playing with it.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 1:00 PM
To: rxtx at qbang.org
Subject: [Rxtx] CVS for 2.1 should have everything


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From impakt01 at optusnet.com.au  Sat Jun  3 21:22:41 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 13:22:41 +1000
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
Message-ID: <200606040322.k543MqW1008455@mail12.syd.optusnet.com.au>

Played with it, problem, with a while loop in my code, working great now

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Daren
Sent: Sunday, 4 June 2006 1:08 PM
To: 'RXTX Developers and Users'
Subject: Re: [Rxtx] CVS for 2.1 should have everything

Hi Trent,
I tried the latest dll and it opens the port, receives 100-200 bytes and
then stops receiving anything else..

I'll keep playing with it.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 1:00 PM
To: rxtx at qbang.org
Subject: [Rxtx] CVS for 2.1 should have everything


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Sat Jun  3 21:35:41 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 21:35:41 -0600 (MDT)
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
References: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606032131140.10890@www>

On Sun, 4 Jun 2006, Daren wrote:

> Hi Trent,
> I tried the latest dll and it opens the port, receives 100-200 bytes and
> then stops receiving anything else..
>
> I'll keep playing with it.
>
> Daren

The difference may be that I'm talking to something at the exact same baud 
rate (loopback).

You may also try setting the baudrate to ~1933 and ~1973 to force the 
guesses one way or the other.  If you are on windows, we are not doing 
anything fancy in the end.  Thats the kernel guessing.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sun Jun  4 04:12:09 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sun, 4 Jun 2006 12:12:09 +0200
Subject: [Rxtx] Update of OSX installer, Readme, etc
Message-ID: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>

Good day,

after the latest changes a lot of OS X specific files should be  
updated. Especially the installer!

- The "MaxOSX" readme file on the root level is outdated (ie  
CodeWarrior information). Maybe we could even rename it to README.OSX  
to be in line with README.IPAQ, README.SCO (Trent do you mind copying/ 
renaming ,v files in the repository?).

- The lock files are no longer used and hence the user group magic  
and lock folder creation should be removed from the installer.

- MACOSX_IDE/ForPackageMaker/Resources/ReadMe.rtf and Welcome.rtf  
need to be updated.

- I suggest to replace the current installation instruction for OS X:  
Installation should occur into the application directory, not in the  
Java-VM directory. This simplifies things a lot, as the Mac Installer  
can be removed completely.

- The xcodeproject's build settings need to be updated to generate  
JAVA 1.1 format class files.


Dimitry: do you have time to tackle this? I could do it, but as this  
is "your baby" I thought you may prefer to do it yourself.

Regards,
Joachim



From dmarkman at mac.com  Sun Jun  4 11:27:53 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Sun, 4 Jun 2006 13:27:53 -0400
Subject: [Rxtx] Update of OSX installer, Readme, etc
In-Reply-To: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
References: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
Message-ID: <26E7A202-962B-4C19-93B6-29426C467249@mac.com>

Joachim,
unfortunately I don't have time right now to do that
so if you can do that, please do

it's not only my baby
it's yours too :-)

thanks


On Jun 4, 2006, at 6:12 AM, Joachim Buechse wrote:

> Good day,
>
> after the latest changes a lot of OS X specific files should be
> updated. Especially the installer!
>
> - The "MaxOSX" readme file on the root level is outdated (ie
> CodeWarrior information). Maybe we could even rename it to README.OSX
> to be in line with README.IPAQ, README.SCO (Trent do you mind copying/
> renaming ,v files in the repository?).
>
> - The lock files are no longer used and hence the user group magic
> and lock folder creation should be removed from the installer.
>
> - MACOSX_IDE/ForPackageMaker/Resources/ReadMe.rtf and Welcome.rtf
> need to be updated.
>
> - I suggest to replace the current installation instruction for OS X:
> Installation should occur into the application directory, not in the
> Java-VM directory. This simplifies things a lot, as the Mac Installer
> can be removed completely.
>
> - The xcodeproject's build settings need to be updated to generate
> JAVA 1.1 format class files.
>
>
> Dimitry: do you have time to tackle this? I could do it, but as this
> is "your baby" I thought you may prefer to do it yourself.
>
> Regards,
> Joachim
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman



From tjarvi at qbang.org  Sun Jun  4 13:54:02 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 4 Jun 2006 13:54:02 -0600 (MDT)
Subject: [Rxtx] Update of OSX installer, Readme, etc
In-Reply-To: <26E7A202-962B-4C19-93B6-29426C467249@mac.com>
References: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
	<26E7A202-962B-4C19-93B6-29426C467249@mac.com>
Message-ID: <Pine.LNX.4.61.0606041353040.22522@www>

On Sun, 4 Jun 2006, Dmitry Markman wrote:

> Joachim,
> unfortunately I don't have time right now to do that
> so if you can do that, please do
>
> it's not only my baby
> it's yours too :-)
>

I've given Joachim cvs access.  He has shown good work in bugzilla.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Mon Jun  5 10:08:32 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 5 Jun 2006 18:08:32 +0200
Subject: [Rxtx] Build process changes for Mac OS X
Message-ID: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>

Good day,

I have cleaned up some outdated Mac OSX specific build files in the  
repository.

There was not a lot left of the readme file "MacOSX" after cleaning  
it up, so I decided to rename it README.OSX to be in harmony with the  
other files in the directory (ie README.IPAQ, README.SCO, ...)

I added an (uncompressed) XCode 2.3 project file/structure  
with .cvsignore files that will ignore the user specific settings.  
This should work "out of the box" for OSX10.4. Users of 10.2/10.3 may  
have to switch the build settings.

[It's kind of tricky to choose "the right" setting. Afaik there is no  
way to compile a universal binary that will work on 10.3 or before.  
So it's either UniversalBinary OR Legacy. Maybe we should have  
different build targets for these different targets?? I would like to  
get some feedback from the Mac developers on this list regarding the  
subject].

Besides other things the OSX installer is no longer required. Since  
the next version (2.1.8) will no longer use lockfiles on OSX, the  
group/permission magic is no longer required and hence there remains  
basicly no work for the installer - other than copying 2 files to the  
VM extension directory. Then again, this is not the best way to  
install RXTX. So I removed the installer completely without modifying  
it, this should simplify a "resurrection" should it ever get necessary.

I had problems with the (compressed, ie sit.hqx) legacy project files  
on the latest installation of OSX (javac 1.5 creating non JDK1.1  
class files and some minor problems). To reduce potential confusion  
for newcomers I decided to remove them. This means that there is no  
longer a simple way to build RXTX for OSX 10.0 and 10.1 (I deeply  
apologize if anyone still relied on this ... well the files are in  
the Attiq).

Best regards,
Joachim


From joachim at buechse.de  Mon Jun  5 10:16:37 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 5 Jun 2006 18:16:37 +0200
Subject: [Rxtx] RXTX and lockfiles on OSX [it is fixed now]
Message-ID: <7D2C4418-9397-4B59-8091-9FDE4ED67836@buechse.de>

Quite a number of people contacted me in the last couple of weeks  
because of problems installing RXTX on OSX. I told you to wait for  
the "official" fix. Well, it has been fixed.

So if you were among the people waiting for the solution, you can now  
download the source rxtx-2.1-7r2.zip from the website. Once unpacked  
dont forget to use "cvs up" to update the files to the latest  
version. You can then open MACOSX_IDE/XCode/ 
LibSerialUniversal.xcodeproj with XCode 2.3 and build the libraries  
that no longer try to create lock files.

Regards,
Joachim


From brian at mbari.org  Mon Jun  5 10:52:43 2006
From: brian at mbari.org (Brian Schlining)
Date: Mon, 5 Jun 2006 09:52:43 -0700
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
Message-ID: <78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>

Hi Joachim,

> [It's kind of tricky to choose "the right" setting. Afaik there is no
> way to compile a universal binary that will work on 10.3 or before.
> So it's either UniversalBinary OR Legacy. Maybe we should have
> different build targets for these different targets?? I would like to
> get some feedback from the Mac developers on this list regarding the
> subject].

I imagine most developers will be compiling on 10.4 (It's the nature  
of the coder...gotta have the latest and greatest) and deploying to  
both 10.3 and 10.4; both of which will run Universal Binaries (see  
http://forums.macrumors.com/showthread.php?t=205348). So it sounds  
like you've covered the majority of users. Still, you know someone's  
going to pipe up about needing RXTX on 10.2 so it would be nice to  
have a target to make a PPC only build.

Just my 2 cents

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/1cac8c39/attachment-0012.html

From dmarkman at mac.com  Mon Jun  5 13:47:50 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Mon, 5 Jun 2006 15:47:50 -0400
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
Message-ID: <686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>

I don't think it will be a problem to run universal binary
on 10.2
however if binary has some calls that aren't implemented in 10.2
then you'll have a problem


On Jun 5, 2006, at 12:52 PM, Brian Schlining wrote:

> Hi Joachim,
>
>> [It's kind of tricky to choose "the right" setting. Afaik there is no
>> way to compile a universal binary that will work on 10.3 or before.
>> So it's either UniversalBinary OR Legacy. Maybe we should have
>> different build targets for these different targets?? I would like to
>> get some feedback from the Mac developers on this list regarding the
>> subject].
>
> I imagine most developers will be compiling on 10.4 (It's the  
> nature of the coder...gotta have the latest and greatest) and  
> deploying to both 10.3 and 10.4; both of which will run Universal  
> Binaries (see http://forums.macrumors.com/showthread.php?t=205348).  
> So it sounds like you've covered the majority of users. Still, you  
> know someone's going to pipe up about needing RXTX on 10.2 so it  
> would be nice to have a target to make a PPC only build.
>
> Just my 2 cents
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/9fafc878/attachment-0012.html

From brian at mbari.org  Mon Jun  5 14:52:41 2006
From: brian at mbari.org (Brian Schlining)
Date: Mon, 5 Jun 2006 13:52:41 -0700
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
Message-ID: <E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>

Hi Dmitry,

> I don't think it will be a problem to run universal binary
> on 10.2
> however if binary has some calls that aren't implemented in 10.2
> then you'll have a problem

You're right...I stand corrected.

Note however, to deploy a universal binary to 10.2 RXTX will need to  
use the 10.2 SDK to build the PPC side. (see http:// 
developer.apple.com/documentation/DeveloperTools/Conceptual/ 
cross_development/UniversalBinaries/chapter_4_section_1.html). I  
haven't been paying close attention to the new locking mechanism used  
by RXTX on the Mac...does 10.2 support it?

Joachim, which SDK will you be using by default for building the Mac  
PPC binaries?

>> Hi Joachim,
>>
>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>> is no
>>> way to compile a universal binary that will work on 10.3 or before.
>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>> different build targets for these different targets?? I would  
>>> like to
>>> get some feedback from the Mac developers on this list regarding the
>>> subject].
>>
>> I imagine most developers will be compiling on 10.4 (It's the  
>> nature of the coder...gotta have the latest and greatest) and  
>> deploying to both 10.3 and 10.4; both of which will run Universal  
>> Binaries (see http://forums.macrumors.com/showthread.php? 
>> t=205348). So it sounds like you've covered the majority of users.  
>> Still, you know someone's going to pipe up about needing RXTX on  
>> 10.2 so it would be nice to have a target to make a PPC only build.

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/153bf50e/attachment-0012.html

From dmarkman at mac.com  Mon Jun  5 19:02:04 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Mon, 5 Jun 2006 21:02:04 -0400
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
Message-ID: <7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>

if Joachim didn't change xcode project setting

/Developer/SDKs/MacOSX10.4u.sdk is used to build universal binary

so it's quite possible that it won't run properly on 10.2

so we have to change the building process, so ppc part will be built
with
/Developer/SDKs/MacOSX10.2.8.sdk

and finally to use lipo utility to build universal binaries

Joachim, did you use some specific locking API that wasn't implemented

in MacOSX10.2.8.sdk?

thanks


On Jun 5, 2006, at 4:52 PM, Brian Schlining wrote:

> Hi Dmitry,
>
>> I don't think it will be a problem to run universal binary
>> on 10.2
>> however if binary has some calls that aren't implemented in 10.2
>> then you'll have a problem
>
> You're right...I stand corrected.
>
> Note however, to deploy a universal binary to 10.2 RXTX will need  
> to use the 10.2 SDK to build the PPC side. (see http:// 
> developer.apple.com/documentation/DeveloperTools/Conceptual/ 
> cross_development/UniversalBinaries/chapter_4_section_1.html). I  
> haven't been paying close attention to the new locking mechanism  
> used by RXTX on the Mac...does 10.2 support it?
>
> Joachim, which SDK will you be using by default for building the  
> Mac PPC binaries?
>
>>> Hi Joachim,
>>>
>>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>>> is no
>>>> way to compile a universal binary that will work on 10.3 or before.
>>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>>> different build targets for these different targets?? I would  
>>>> like to
>>>> get some feedback from the Mac developers on this list regarding  
>>>> the
>>>> subject].
>>>
>>> I imagine most developers will be compiling on 10.4 (It's the  
>>> nature of the coder...gotta have the latest and greatest) and  
>>> deploying to both 10.3 and 10.4; both of which will run Universal  
>>> Binaries (see http://forums.macrumors.com/showthread.php? 
>>> t=205348). So it sounds like you've covered the majority of  
>>> users. Still, you know someone's going to pipe up about needing  
>>> RXTX on 10.2 so it would be nice to have a target to make a PPC  
>>> only build.
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/84790f80/attachment-0012.html

From joachim at buechse.de  Tue Jun  6 02:40:47 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 6 Jun 2006 10:40:47 +0200
Subject: [Rxtx] Building on OS X, Impl Changes
In-Reply-To: <7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
Message-ID: <CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>

Good day!

What's in the XCode project setting?
----------

The xcode project remained pretty much the same as before. I excluded  
the user specific files from CVS and changed some settings. I kept  
all the built targets (you shouldn't change what you don't understand;-)

Currently we the following build targets:
    RXTXComm (java files)
    librxtxParallel.jnilib (usefull on the Mac???)
    libI2C.jnilib (not yet working in RXTX)
    libRS485.jnilib (not yet working in RXTX)
    librxtxSerial.jnilib (1)
    librxtxSerial.jnilib Dynamic (2)
    rxtxSerial (3)
We also have the following build configurations for each target:
    Development
    Default
    Deployment

What was changed in the xcode project from previous versions:
- java.souce=1.3 and java.target=1.1 in RXTXComm settings
- removed copying of build products into installer directory
- removed "(Upgraded)" from build target names

What remains to be changed:
- choosing a "non-debug" Build-configuration as default
- potentially removing "Default"/"Development" Build-configurations
- reducing the number of build targets
- creating 10.2 compatible universal binaries

I suggest, that the build configurations should be reduced to 2  
(Debug/Deployment), possibly even 1 (Debug).
I have not yet found the deeper meaning of the build targets(1)(2) 
(3), it seems to me like they should be reduced into one "doing the  
right thing" or maybe into two "rxtxSerial.jnilib Legacy" (back to  
10.2, universal if possible) and "rxtxSerial.jnilib 10.4 
+" (universal, 10.4+).

Should the code work on 10.2?
----------

Absolutely. The code should work on NextStep, in fact on any BSD  
unix. I would go as far as saying, this code should work on any  
POSSIX based unix. All that was added is the call "ioctl(fd,  
TIOCEXCL)" to request excusivity of the port:

http://gemma.apple.com/documentation/DeviceDrivers/Conceptual/ 
WorkingWSerial/WWSerial_SerialDevs/chapter_2_section_8.html

It is not yet "the perfect solution". Normally an open /dev/tty  
(listen for incomming connection) should be "preemptable" by opening  
a /dev/cu (outgoing connection) for the same port. This is not yet  
implemented as it needs calls outside of POSSIX on OSX.

On "classic" systems (like NextStep) this worked based on the  
"carried detect line". open() on /dev/tty.xxx would block until the  
carrier detect signal was raised. As the device was not "opened"  
opening /dev/cu.xxx worked without a hitch. When they ported to the  
Mac this broke. On Macs the "carier detect" is usually not wired.  
Furthermore FAX modems did no longer raise the line. So the OSX  
implementor defined a new call, which is documented here:

http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00045.html

Best regards,
Joachim




On 06.06.2006, at 03:02, Dmitry Markman wrote:

> if Joachim didn't change xcode project setting
>
> /Developer/SDKs/MacOSX10.4u.sdk is used to build universal binary
>
> so it's quite possible that it won't run properly on 10.2
>
> so we have to change the building process, so ppc part will be built
> with
> /Developer/SDKs/MacOSX10.2.8.sdk
>
> and finally to use lipo utility to build universal binaries
>
> Joachim, did you use some specific locking API that wasn't implemented
>
> in MacOSX10.2.8.sdk?
>
> thanks
>
>
> On Jun 5, 2006, at 4:52 PM, Brian Schlining wrote:
>
>> Hi Dmitry,
>>
>>> I don't think it will be a problem to run universal binary
>>> on 10.2
>>> however if binary has some calls that aren't implemented in 10.2
>>> then you'll have a problem
>>
>> You're right...I stand corrected.
>>
>> Note however, to deploy a universal binary to 10.2 RXTX will need  
>> to use the 10.2 SDK to build the PPC side. (see http:// 
>> developer.apple.com/documentation/DeveloperTools/Conceptual/ 
>> cross_development/UniversalBinaries/chapter_4_section_1.html). I  
>> haven't been paying close attention to the new locking mechanism  
>> used by RXTX on the Mac...does 10.2 support it?
>>
>> Joachim, which SDK will you be using by default for building the  
>> Mac PPC binaries?
>>
>>>> Hi Joachim,
>>>>
>>>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>>>> is no
>>>>> way to compile a universal binary that will work on 10.3 or  
>>>>> before.
>>>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>>>> different build targets for these different targets?? I would  
>>>>> like to
>>>>> get some feedback from the Mac developers on this list  
>>>>> regarding the
>>>>> subject].
>>>>
>>>> I imagine most developers will be compiling on 10.4 (It's the  
>>>> nature of the coder...gotta have the latest and greatest) and  
>>>> deploying to both 10.3 and 10.4; both of which will run  
>>>> Universal Binaries (see http://forums.macrumors.com/ 
>>>> showthread.php?t=205348). So it sounds like you've covered the  
>>>> majority of users. Still, you know someone's going to pipe up  
>>>> about needing RXTX on 10.2 so it would be nice to have a target  
>>>> to make a PPC only build.
>>
>> Brian Schlining
>> Software Engineer
>> http://www.mbari.org
>>
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> Dmitry Markman
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Tue Jun  6 07:01:06 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 6 Jun 2006 15:01:06 +0200
Subject: [Rxtx] Serial port code for OS X, future steps
In-Reply-To: <CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
	<CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
Message-ID: <8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>

I posted the "wrong link". There is a correction here:

    http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00059.html

In fact, the 2.1.7 implementation of RXTX has quite some deficiencies  
on OSX. I have tried to supply some patches that don't interfere to  
much with the existing RXTX code base, but there are limits to what  
can be done with local patches.

There are some very intrusive changes that should be done. Ie proper  
mapping of /dev/tty <-> /dev/cu handling to correct behaviour of  
CommPortOwnershipListener (http://java.sun.com/products/javacomm/ 
reference/api/index.html). I dont think this can be done with  
patches. Hence I think, RXTX should be rewritten from scratch de- 
unifying the native code base (and implementing thread safe code on  
the Java side).


How "should" /dev/tty vs /dev/cu be implemented?

=====
The Unix contract is this: An open /dev/tty.xxx port (incomming)  
should be interrupted/auto-closed when opening /dev/cu.xxx (outgoing)  
[if /dev/tty.xxx is not currently handling a communication].  /dev/ 
cu.xxx and /dev/tty.xxx refer to the same device, so owning  
"exclusively" should block both. This should be respected across all  
applications native or Java.

This contract is realizable on OSX with the existing javax.comm  
interface while also respecting (to the biggest part) the contract  
defined by javax.comm.PortOwnershipListener.

The one point where the suggested implementation "breaks" the  
javax.comm contract, is by the fact that one can loose a /dev/tty  
port without calling close. However, the only option I see is to  
always open serial ports "non-exclusively" which would outrule Java  
as a platform for (dormant) applications waiting for incoming  
connections/faxes/etc. There could be a system property to choose the  
intended behavior.
=====

Here is how it could be done on OSX:

Calling port=ComportIdentifier.open("/dev/cu.xxx") opens and owns the  
port exclusively until port.close() is called.
- Java applications listening with a PortOwnershipListener should get  
a PORT_OWNED event reasonably soon.
- Any further attempt by a Java or native application to open "/dev/ 
cu.xxx" or "/dev/tty.xxx" fails.
- /dev/cu.xxx is for "outgoing" connections, so receiving  
PORT_OWNERSHIP_REQUESTED makes little to no sense. With native  
applications it can not be implemented. For Java applications it  
could be implemented (by a hidden communication channel). I think  
it's not worth bothering. If anyone is willing to give up a port to  
others he should use /dev/tty.xxx instead of /dev/cu.xxx.

Registering a PortOwnershipListener on "/dev/cu.xxx" without opening  
it, uses /dev/tty.xxx (native open()) non-exclusively and polls its  
state. PORT_OWNED and PORT_UNOWNED can be produced.

Calling port=ComportIdentifier.open("/dev/tty.xxx") should open the  
port non-exclusively.
- Adding a SerialPortEventListener and reading from the port could be  
allowed while keeping it non-exclusive.
- When port.getOutputStream() is called, the state should be changed  
to an "exclusive" ownership. This may be configurable via a system  
property.
- To return to the non-exclusive state the port must be closed and  
reopened.
- While non-exclusively opened, opening the corresponding /dev/cu.xxx  
produces a PORT_OWNERSHIP_REQUESTED event. Which should be responded  
by closing the port from within the callback (as described in  
java.comm.PortOwnershipListener). If there is a pending read, it will  
return after the listener finishes (with -1 or "0 bytes read").
- Calling write() on the /dev/tty.xxx after somebody opened /dev/ 
cu.xxx will fail with a descriptive IOException.
- Calling read() on the /dev/tty.xxx after somebody opened /dev/ 
cu.xxx will fail with a descriptive IOException (or potentially  
block, see side notes below).

CommPortIdentifier.getCurrentOwner() can be implemented by an  
external call to lsof.

CommPortIdentifier.isCurrentlyOwned() can be implemented by trying an  
open on the /dev/tty.
- It returns true if the port is currently held "exclusively".
- Whether it should also return true on /dev/tty if /dev/tty is  
already opened non-exclusively might be a system property option. In  
general, having several applications waiting for incoming connections  
on the same port will require an application level "arbitration"  
protocol...

[[side note1: One interesting question is, what happens if the  
process holding /dev/tty non-exclusively ignores  
PORT_OWNERSHIP_REQUESTED. Ie after "loosing" a non-exclusively opened  
"dev/tty.xxx" port to another process. One possible implementation  
is, that the port is "regained" when the other process gives up the  
port. This would mean that in the meanwhile read() returns no data,  
and any changes to the configuration of the port are stored but not  
forwarded. I guess, the safe (and simple) way to do this is to make  
the close() mandatory (ie setting the port into an "awaiting_close"  
state which produces IOExceptions to any other call than close). ]]

[[side note2:  Another interesting question is, what should happen if  
several applications open the same /dev/tty.xxx port "non- 
exclusively" and start to change the settings of the device.]]

Regards,
Joachim



On 06.06.2006, at 10:40, Joachim Buechse wrote:

> Should the code work on 10.2?
> ----------
>
> Absolutely. The code should work on NextStep, in fact on any BSD
> unix. I would go as far as saying, this code should work on any
> POSSIX based unix. All that was added is the call "ioctl(fd,
> TIOCEXCL)" to request excusivity of the port:
>
> http://gemma.apple.com/documentation/DeviceDrivers/Conceptual/
> WorkingWSerial/WWSerial_SerialDevs/chapter_2_section_8.html
>
> It is not yet "the perfect solution". Normally an open /dev/tty
> (listen for incomming connection) should be "preemptable" by opening
> a /dev/cu (outgoing connection) for the same port. This is not yet
> implemented as it needs calls outside of POSSIX on OSX.
>
> On "classic" systems (like NextStep) this worked based on the
> "carried detect line". open() on /dev/tty.xxx would block until the
> carrier detect signal was raised. As the device was not "opened"
> opening /dev/cu.xxx worked without a hitch. When they ported to the
> Mac this broke. On Macs the "carier detect" is usually not wired.
> Furthermore FAX modems did no longer raise the line. So the OSX
> implementor defined a new call, which is documented here:
>
> http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00045.html
>
> Best regards,
> Joachim



From sds at dcs.gla.ac.uk  Tue Jun  6 11:22:45 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Tue, 06 Jun 2006 18:22:45 +0100
Subject: [Rxtx] Correct compile flag for HP iPAQ hx4700 running Familiar
	Linux?
Message-ID: <1149614565.19496.10.camel@addu>

Hi,

I'd like to use RXTX 2.1 on my HP iPAQ hx4700. The iPAQ is running
Familiar Linux 0.8.2 (as I recall), with Blackdown Java 1.3.1.

I can compile and run a test program which uses RXTX on my i686 machine,
and it works fine. But I can't seem to get things working quite right on
my PDA.

I compile the code on the laptop with the following commands:
	./configure --host=arm-gnu-linux && make
... as suggested in a post to this list, albeit some time ago. This
compiles, I transfer the files, set up LD_LIBRARY_PATH and CLASSPATH
variables, and get the following error on the PDA:

sds at ipaq-pxa-2:~# java Test
java.lang.UnsatisfiedLinkError: /usr/local/lib/ext/librxtxSerial.so: /usr/local/lib/ext/librxtxSerial.so: cannot open shared object file: No such file or directory thrown while loading gnu.io.RXTXCommDriver
Exception in thread "main"
java.lang.UnsatisfiedLinkError: /usr/local/lib/ext/librxtxSerial.so: /usr/local/lib/ext/librxtxSerial.so: cannot open shared object file: No such file or directory
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1382)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1290)
        at java.lang.Runtime.loadLibrary0(Runtime.java:749)
        at java.lang.System.loadLibrary(System.java:820)
        at
gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:83)
        at Test.<init>(Test.java:9)
        at Test.main(Test.java:32)
sds at ipaq-pxa-2:~# 

Note that I'm copying the files to /usr/local/lib/ext/ along with the
RXTXcomm.jar file, purely to keep things separate from the rest of the
system while testing. The location of the .so files doesn't seem to have
any bearing on whether "java Test" will succeed or not. The contents of
this directory are:

sds at ipaq-pxa-2:~$ ls /usr/local/lib/ext/
RXTXcomm.jar              librxtxParallel-2.1-7.so  librxtxRS485.so
librxtxSerial-2.1-7.so
librxtxI2C-2.1-7.so       librxtxParallel.so        librxtxRaw-2.1-7.so
librxtxSerial.so
librxtxI2C.so             librxtxRS485-2.1-7.so     librxtxRaw.so
sds at ipaq-pxa-2:~$

Test.java fails on the first real line of code I'm using to test that
things are working, prior to real development, and was carefully pinched
from the web:
Enumeration portIdentifiers = CommPortIdentifier.getPortIdentifiers();


I assume that I've gotten my --host flag wrong way back up there at
the ./configure step. But if that's the case, what should I set it to?
Or am I missing something more obvious?


Cheers,
Stephen Strowes,
University of Glasgow.




From tjarvi at qbang.org  Tue Jun  6 13:39:41 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 6 Jun 2006 13:39:41 -0600 (MDT)
Subject: [Rxtx] Serial port code for OS X, future steps
In-Reply-To: <8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
	<CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
	<8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>
Message-ID: <Pine.LNX.4.61.0606061315070.9856@www>


>>
There are some very intrusive changes that should be done. Ie proper
mapping of /dev/tty <-> /dev/cu handling to correct behaviour of
CommPortOwnershipListener (http://java.sun.com/products/javacomm/
reference/api/index.html). I dont think this can be done with
patches. Hence I think, RXTX should be rewritten from scratch de-
unifying the native code base (and implementing thread safe code on
the Java side).
<<

This appears to be a very small amount of functionality for a total 
rewrite.  The port ownership only needs maybe 3 native calls if it is done 
with native calls at all.

Those features which are not part of the Unix standard(s) can be special 
cased.  I'm not sure /dev/cu is standard.  We can look.  I know linux 
deprecated /dev/cua years ago.

Thread safe Java code is not a platform specific issue.

--
Trent Jarvi
tjarvi at qbang.org


From sds at dcs.gla.ac.uk  Wed Jun  7 12:36:43 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Wed, 07 Jun 2006 19:36:43 +0100
Subject: [Rxtx] Expected RXTX behaviour?
In-Reply-To: <1149703900.30891.19.camel@addu>
References: <1149703900.30891.19.camel@addu>
Message-ID: <1149705403.30891.25.camel@addu>

Apologies, caught the problem. Had to append '\r' to the end of the AT
string. A non obvious but stupid mistake... :-)

Final quick question though: How might I stop the echoing of
outputStream data back into the inputStream? I still see the ATI
commands on the inputStream, along with the output from the device.


Cheers,
S.



On Wed, 2006-06-07 at 19:11 +0100, Stephen Strowes wrote:
> Hi,
> 
> I managed to get RXTX to compile for my iPAQ following my previous post
> to this list. Quick query though:
> 
> I want to be able to issue AT commands to a device, and interpret the
> responses. For this, I assume I do the following, in psuedo-form:
> 
> 	CommPortIdentifier.getPortIdentifiers();
> 	// find the correct device id
> 	serialPort= (SerialPort)portID.open("Test");
> 	// Set parameters and flow control
> 	outputStream= serialPort.getOutputStream();
> 	inputStream=  serialPort.getInputStream();
> 
> ... following this, I spawn a thread to respond to DATA_AVAILABLE events
> on serialPort with inputStream, and occasionally write and flush an
> "ATI" onto the outputStream. Nothing complex, I just want to see it
> work.
> 
> I would have expected inputStream to give the same information back from
> an "ATI" command as minicom provides, but instead inputStream only sees
> the "ATI" I put onto the outputStream.
> 
> Have I missed something?
> 
> 
> Cheers,
> S.
> 



From sds at dcs.gla.ac.uk  Wed Jun  7 12:11:40 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Wed, 07 Jun 2006 19:11:40 +0100
Subject: [Rxtx] Expected RXTX behaviour?
Message-ID: <1149703900.30891.19.camel@addu>

Hi,

I managed to get RXTX to compile for my iPAQ following my previous post
to this list. Quick query though:

I want to be able to issue AT commands to a device, and interpret the
responses. For this, I assume I do the following, in psuedo-form:

	CommPortIdentifier.getPortIdentifiers();
	// find the correct device id
	serialPort= (SerialPort)portID.open("Test");
	// Set parameters and flow control
	outputStream= serialPort.getOutputStream();
	inputStream=  serialPort.getInputStream();

... following this, I spawn a thread to respond to DATA_AVAILABLE events
on serialPort with inputStream, and occasionally write and flush an
"ATI" onto the outputStream. Nothing complex, I just want to see it
work.

I would have expected inputStream to give the same information back from
an "ATI" command as minicom provides, but instead inputStream only sees
the "ATI" I put onto the outputStream.

Have I missed something?


Cheers,
S.




From joachim at buechse.de  Wed Jun  7 09:02:13 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 7 Jun 2006 17:02:13 +0200
Subject: [Rxtx] Update of build process for OSX (XCode project)
Message-ID: <62EC47B1-46BD-4ECA-B9EC-C4061D147CDA@buechse.de>

With the help of Dmitry Markman and Brian Schilling I have updated  
(and largely simplifed) the XCode project file for Mac OS X.

Changes:
- compiles a universal binary library with intel=OSX10.4+, ppc=OSX10.2 
+ support
- compiles the Java sources into a JRE1.1 compatible, compressed jar.

Please test on your configuration, especially if you have computers  
running 10.2/10.3 or intel.

Best regards,
Joachim


From joachim at buechse.de  Wed Jun  7 14:36:37 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 7 Jun 2006 22:36:37 +0200
Subject: [Rxtx] Expected RXTX behaviour?
In-Reply-To: <1149705403.30891.25.camel@addu>
References: <1149703900.30891.19.camel@addu> <1149705403.30891.25.camel@addu>
Message-ID: <D3AD6EAF-27BB-455E-9697-86C1121920C3@buechse.de>

Echoing is a feature of the modem. Try ATE0 which works with most  
"rockwell" compatible modems.

Regards,
Joachim


On 07.06.2006, at 20:36, Stephen Strowes wrote:

> Apologies, caught the problem. Had to append '\r' to the end of the AT
> string. A non obvious but stupid mistake... :-)
>
> Final quick question though: How might I stop the echoing of
> outputStream data back into the inputStream? I still see the ATI
> commands on the inputStream, along with the output from the device.
>
>
> Cheers,
> S.
>
>
>
> On Wed, 2006-06-07 at 19:11 +0100, Stephen Strowes wrote:
>> Hi,
>>
>> I managed to get RXTX to compile for my iPAQ following my previous  
>> post
>> to this list. Quick query though:
>>
>> I want to be able to issue AT commands to a device, and interpret the
>> responses. For this, I assume I do the following, in psuedo-form:
>>
>> 	CommPortIdentifier.getPortIdentifiers();
>> 	// find the correct device id
>> 	serialPort= (SerialPort)portID.open("Test");
>> 	// Set parameters and flow control
>> 	outputStream= serialPort.getOutputStream();
>> 	inputStream=  serialPort.getInputStream();
>>
>> ... following this, I spawn a thread to respond to DATA_AVAILABLE  
>> events
>> on serialPort with inputStream, and occasionally write and flush an
>> "ATI" onto the outputStream. Nothing complex, I just want to see it
>> work.
>>
>> I would have expected inputStream to give the same information  
>> back from
>> an "ATI" command as minicom provides, but instead inputStream only  
>> sees
>> the "ATI" I put onto the outputStream.
>>
>> Have I missed something?
>>
>>
>> Cheers,
>> S.
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From g_petrini at yahoo.it  Thu Jun  8 01:41:58 2006
From: g_petrini at yahoo.it (Giacomo Petrini)
Date: Thu, 8 Jun 2006 09:41:58 +0200 (CEST)
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from FieldTalk
Message-ID: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>

Hi,
I'm evaluating the library for the modbus protocol
from FieldTalk
(http://www.modbusdriver.com/fieldtalk/.
I'm using J2SE 5.0 and RXTX 2.1 on win XP.
The problem is that the modbus lib has a method (the
openProtocol method, but maybe there are others) tha
throws the
javax.comm.UnsupportedCommOperationException.
Now, in RXTX 2.1 the namespace has changed in gnu.io,
so the modbus library doesn't work anymore (it look
for things in javax.comm). I've already sent an email
to fieldtalk to see if they are aware of the problem.
The solution should be to use JavaComm + RXTX 2.0. But
I've read somewhere that JavaComm 2.0 does not work
with Java 5.0 and JavaComm 3.0 does not work with RXTX
2.0 so I don't know what to do.

Any ideas?

Thanks Jack

PS: can you make a CC to my personal email
(g_petrini at yahoo.it) too please?

Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 


From rxtx at tapastda.co.uk  Thu Jun  8 02:27:57 2006
From: rxtx at tapastda.co.uk (rxtx@tapastda.co.uk)
Date: Thu, 08 Jun 2006 09:27:57 +0100
Subject: [Rxtx] Win XP and Infrared based serial port
Message-ID: <4487DF8D.5050807@tapastda.co.uk>

I'm attempting to use RXTX 2.1.7 on Win XP with J2SE 5.0 to communicate with a
GSM mobile using a COM port. A peculiarity that I've seen is that whilst I can
communicate successfully with a mobile which uses an infrared based COM port
using the SUN provided javax.comm (v2.0) I cannot use RXTX because it fails to
read anything from the port (i.e. read timeout always occurs returning zero bytes).

I assumed that this could be the result of flow control problems and thus I've
tried setting either software or hardware based flow control on the port however
this has no affect.

Can you suggest any other port configuration changes which might be required to
make such a port work with RXTX.

Thanks
Stu
-- 
Stuart
Tapastda Limited


From tjarvi at qbang.org  Thu Jun  8 05:17:12 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 8 Jun 2006 05:17:12 -0600 (MDT)
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from
	FieldTalk
In-Reply-To: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
References: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606080504480.9856@www>

On Thu, 8 Jun 2006, Giacomo Petrini wrote:

> Hi,
> I'm evaluating the library for the modbus protocol
> from FieldTalk
> (http://www.modbusdriver.com/fieldtalk/.
> I'm using J2SE 5.0 and RXTX 2.1 on win XP.
> The problem is that the modbus lib has a method (the
> openProtocol method, but maybe there are others) tha
> throws the
> javax.comm.UnsupportedCommOperationException.
> Now, in RXTX 2.1 the namespace has changed in gnu.io,
> so the modbus library doesn't work anymore (it look
> for things in javax.comm). I've already sent an email
> to fieldtalk to see if they are aware of the problem.
> The solution should be to use JavaComm + RXTX 2.0. But
> I've read somewhere that JavaComm 2.0 does not work
> with Java 5.0 and JavaComm 3.0 does not work with RXTX
> 2.0 so I don't know what to do.
>
> Any ideas?
>
> Thanks Jack
>


Hi Jack

There are plans for Sun to rerelease JavaComm 2.0 mentioned in the rxtx 
mail-list archives.  When this happens rxtx will release a current rxtx 
2.0 library that works with it.

There are no dates promised by either side but rxtx will do it as soon as 
possible after Sun's rerelease.  Just to give you a feel for the time 
frame, this started last year and no significant progress has been made. 
There have been friendly talks pointing towards solutions (rerelease 2.0) 
but that does not get your application working today.  rxtx is preparing 
for its second release in gnu.io since then.

--
Trent Jarvi
tjarvi at qbang.org




From jredman at ergotech.com  Thu Jun  8 08:47:23 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 08 Jun 2006 08:47:23 -0600
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from
	FieldTalk
In-Reply-To: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
References: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
Message-ID: <4488387B.6040903@ergotech.com>

You could always try a different library, eg.

http://sourceforge.net/projects/jamod

I've only used the slave side since we have our own implementation of 
Modbus Client (and a host of other PLC protocols).  However the client 
side seems to be pretty well supported and fairly widely used.  Since 
the source is there you could change to gnu.io.

I think I should take more of an interest in this issue.  We generally 
run 1.4.2 on Linux, but also have some J9 and old platforms that we 
support that are basically Personal Java.  5.0 on Linux has some 
horrible MDI bugs, to the point of being unusable.   Sounds as though we 
are going to have code compatibility problems across these platforms.

Jim


Giacomo Petrini wrote:
> Hi,
> I'm evaluating the library for the modbus protocol
> from FieldTalk
> (http://www.modbusdriver.com/fieldtalk/.
> I'm using J2SE 5.0 and RXTX 2.1 on win XP.
> The problem is that the modbus lib has a method (the
> openProtocol method, but maybe there are others) tha
> throws the
> javax.comm.UnsupportedCommOperationException.
> Now, in RXTX 2.1 the namespace has changed in gnu.io,
> so the modbus library doesn't work anymore (it look
> for things in javax.comm). I've already sent an email
> to fieldtalk to see if they are aware of the problem.
> The solution should be to use JavaComm + RXTX 2.0. But
> I've read somewhere that JavaComm 2.0 does not work
> with Java 5.0 and JavaComm 3.0 does not work with RXTX
> 2.0 so I don't know what to do.
> 
> Any ideas?
> 
> Thanks Jack
> 
> PS: can you make a CC to my personal email
> (g_petrini at yahoo.it) too please?
> 
> Chiacchiera con i tuoi amici in tempo reale! 
>  http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  8 18:17:23 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 08 Jun 2006 17:17:23 -0700
Subject: [Rxtx] rxtx access is denied error
Message-ID: <4488BE13.2050706@dupreeinc.com>

Hello,

I have been trying to replace the commapi from sun with rxtx for a 
project that communicates with a serial port that is a USB-Serial 
interface.  To be exact, I am using the FTDI VCP driver with one of 
their modules connected to a windows XP system.

I have the RXTX package working pretty well as long as nothing goes wrong.

If a user disconnects the USB port while my java application is running, 
my application goes into an endless loop with lots of messages in the  
errors stream  like the ones below:

    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(481):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.


I believe when this happens the COM port completely disappears and the 
rxtx driver has a heart attack.  Obviously, the user should not do this, 
but my application needs to ideally, correct the situation or as a worse 
case, terminate with a little dignity.  Currently, I have not figured 
out how to catch this error.

The closest I have come is to trap an exception to my input stream read  
that says "No error in readByte"  This error appears to be outside of 
the endless loop of the errors listed above.

Does anybody have an idea of how to identify and trap this error?  Any 
suggestions on how to gracefully recover from it would be greatly 
appreciated!

Thank you for your time,

Doug Thistlethwaite




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060608/9cfca302/attachment-0012.html

From tjarvi at qbang.org  Thu Jun  8 20:54:17 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 8 Jun 2006 20:54:17 -0600 (MDT)
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <4488BE13.2050706@dupreeinc.com>
References: <4488BE13.2050706@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606082022580.1323@www>

On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I have been trying to replace the commapi from sun with rxtx for a project 
> that communicates with a serial port that is a USB-Serial interface.  To be 
> exact, I am using the FTDI VCP driver with one of their modules connected to 
> a windows XP system.
>
> I have the RXTX package working pretty well as long as nothing goes wrong.
>
> If a user disconnects the USB port while my java application is running, my 
> application goes into an endless loop with lots of messages in the  errors 
> stream  like the ones below:
>
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(481):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>
>
> I believe when this happens the COM port completely disappears and the rxtx 
> driver has a heart attack.  Obviously, the user should not do this, but my 
> application needs to ideally, correct the situation or as a worse case, 
> terminate with a little dignity.  Currently, I have not figured out how to 
> catch this error.
>
> The closest I have come is to trap an exception to my input stream read  that 
> says "No error in readByte"  This error appears to be outside of the endless 
> loop of the errors listed above.
>
> Does anybody have an idea of how to identify and trap this error?  Any 
> suggestions on how to gracefully recover from it would be greatly 
> appreciated!
>

Hi Doug

Sadly I don't have a quick solution for you.

Termios has no knowlage about the JVM so it wont be throwing exceptions 
you can catch.

We can return error and set the error number to something reasonable that 
results in an exception.  The No Error message simply means we did not set 
an error number in termios.c.  Those are the line numbers in the code you 
see.  SerialImp.c realizes it errored but does not know much more yet. 
Everything touching the file descriptor is going to error after the port 
is gone presumably.

We don't currently have a plan in place for vanishing (or appearing) com 
ports.

Another example of what we need to think about is what happens if you 
start your application and then plug in the dongle?  Or what if you unplug 
and then plug it in again?

So in each of these three cases, what would the behavior of the (yet to 
be) correct implementation do?

How will the enumerated ports be handled during these changes?

There can also be hints from the OS that could be taken into 
consideration.

We can probably get some exceptions thrown that make sense and null the 
file descriptor when it happens to prevent io attempts.  That would be a 
crude way to let applications know something strange has happened.

Is anyone else tinkering with this problem?

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  9 01:31:29 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 9 Jun 2006 09:31:29 +0200
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <Pine.LNX.4.61.0606082022580.1323@www>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
Message-ID: <AC6EDDDD-0A64-401F-B16B-E484788CDF4A@buechse.de>

Hello Trent,

I am not tinkering with this on the Source Level - but I think it  
should work pretty much the same way as it currently does in OSX.  
When the port goes away you get an IOException thrown for any read/ 
write. It will no longer be in the list of ports from  
CommPortIdentifier.getPortIdentifiers(). When a port (re-)appears it  
is added to the list. It's up to the application to re-check the list  
from time to time.

On Windows you can't do much better then that, because the ports  
don't have useful names. Which USB "virtual com port" is on which  
COMx depends on the order the devices were added. So reconnecting to  
the same device may mean connecting to another port.

Regarding the exception thrown: it would be nice to use an  
IOException subclass but the Exception message should definetly be  
informative also as most applications may want to keep compatibility  
with javax.comm.

Regards,
Joachim


On 09.06.2006, at 04:54, Trent Jarvi wrote:

> On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:
>
>> Hello,
>>
>> I have been trying to replace the commapi from sun with rxtx for a  
>> project
>> that communicates with a serial port that is a USB-Serial  
>> interface.  To be
>> exact, I am using the FTDI VCP driver with one of their modules  
>> connected to
>> a windows XP system.
>>
>> I have the RXTX package working pretty well as long as nothing  
>> goes wrong.
>>
>> If a user disconnects the USB port while my java application is  
>> running, my
>> application goes into an endless loop with lots of messages in  
>> the  errors
>> stream  like the ones below:
>>
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (481):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>
>>
>> I believe when this happens the COM port completely disappears and  
>> the rxtx
>> driver has a heart attack.  Obviously, the user should not do  
>> this, but my
>> application needs to ideally, correct the situation or as a worse  
>> case,
>> terminate with a little dignity.  Currently, I have not figured  
>> out how to
>> catch this error.
>>
>> The closest I have come is to trap an exception to my input stream  
>> read  that
>> says "No error in readByte"  This error appears to be outside of  
>> the endless
>> loop of the errors listed above.
>>
>> Does anybody have an idea of how to identify and trap this error?   
>> Any
>> suggestions on how to gracefully recover from it would be greatly
>> appreciated!
>>
>
> Hi Doug
>
> Sadly I don't have a quick solution for you.
>
> Termios has no knowlage about the JVM so it wont be throwing  
> exceptions
> you can catch.
>
> We can return error and set the error number to something  
> reasonable that
> results in an exception.  The No Error message simply means we did  
> not set
> an error number in termios.c.  Those are the line numbers in the  
> code you
> see.  SerialImp.c realizes it errored but does not know much more yet.
> Everything touching the file descriptor is going to error after the  
> port
> is gone presumably.
>
> We don't currently have a plan in place for vanishing (or  
> appearing) com
> ports.
>
> Another example of what we need to think about is what happens if you
> start your application and then plug in the dongle?  Or what if you  
> unplug
> and then plug it in again?
>
> So in each of these three cases, what would the behavior of the  
> (yet to
> be) correct implementation do?
>
> How will the enumerated ports be handled during these changes?
>
> There can also be hints from the OS that could be taken into
> consideration.
>
> We can probably get some exceptions thrown that make sense and null  
> the
> file descriptor when it happens to prevent io attempts.  That would  
> be a
> crude way to let applications know something strange has happened.
>
> Is anyone else tinkering with this problem?
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From doug at dupreeinc.com  Fri Jun  9 13:09:58 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 09 Jun 2006 12:09:58 -0700
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <Pine.LNX.4.61.0606082022580.1323@www>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
Message-ID: <4489C786.9050504@dupreeinc.com>


Ideally, it would be nice if it would throw an exception and terminate 
the loop.  I am still trying to figure out how to detect the condition 
and recover form it in some form...  I am getting the "No error in 
readByte" exception in my serialEvent() method after an input stream 
read.  It appears to me that the only graceful recovery is to close the 
port and then reopen it when it becomes available.  I can pass the event 
up to the update method in my main frame, but I still can't close the 
port from within that thread.  Any suggestions on how to pass this event 
to a location where the port can be safely closed?

Re: Slow startup in windows XP
I have been looking into this a little closer and have found out the 
following:
System Windows XP Pro 3GHz dual core with 1GB RAM and NO parallel port.
Starting the SerialDemo included with the commapi using the rxtx instead 
of javax.comm takes 60 seconds.
Starting the SerialDemo using rxrx with the rxtxParallel.dll file 
removed takes about 20 seconds.
Modify initialize in RXRXCommDriver.java to not test the parallel ports 
takes less than 1 second.

It would be nice if the initialize routine could detect the presence of 
rxtxParallel.dll file and just skip the whole process if not present.  
Is there an easy way to check for the presence of this file without 
running the parallel port test?

Doug


 

Trent Jarvi wrote:

>On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:
>...
>  
>
>
>Hi Doug
>
>Sadly I don't have a quick solution for you.
>
>Termios has no knowlage about the JVM so it wont be throwing exceptions 
>you can catch.
>
>We can return error and set the error number to something reasonable that 
>results in an exception.  The No Error message simply means we did not set 
>an error number in termios.c.  Those are the line numbers in the code you 
>see.  SerialImp.c realizes it errored but does not know much more yet. 
>Everything touching the file descriptor is going to error after the port 
>is gone presumably.
>
>We don't currently have a plan in place for vanishing (or appearing) com 
>ports.
>
>Another example of what we need to think about is what happens if you 
>start your application and then plug in the dongle?  Or what if you unplug 
>and then plug it in again?
>
>So in each of these three cases, what would the behavior of the (yet to 
>be) correct implementation do?
>
>How will the enumerated ports be handled during these changes?
>
>There can also be hints from the OS that could be taken into 
>consideration.
>
>We can probably get some exceptions thrown that make sense and null the 
>file descriptor when it happens to prevent io attempts.  That would be a 
>crude way to let applications know something strange has happened.
>
>Is anyone else tinkering with this problem?
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060609/911ed787/attachment-0012.html

From Ugo.Landini at Sun.COM  Fri Jun  2 14:23:47 2006
From: Ugo.Landini at Sun.COM (Ugo Landini)
Date: Fri, 02 Jun 2006 22:23:47 +0200
Subject: [Rxtx] OSX 10.4.7 and usb
Message-ID: <44809E53.2070905@sun.com>

Hi, I have installed the library and the native libraries on OSX 10.4.7. 
Then I have run this simple code:

...
while (portList.hasMoreElements()) {
             portId = (CommPortIdentifier) portList.nextElement();
             System.out.println("-> " + portId.getName() + " Port Type:" 
+ portId.getPortType());
...

and the output is:

Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7

Ports found:
-> /dev/tty.Bluetooth-PDA-Sync Port Type:1
-> /dev/cu.Bluetooth-PDA-Sync Port Type:1
-> /dev/tty.Bluetooth-Modem Port Type:1
-> /dev/cu.Bluetooth-Modem Port Type:1

I can't see any USB ports... with javax.comm on linux I could see the 
/dev/ttyUSB stuff, but that's not the case with OSX. Any idea?

tia

uL


From tod at todbot.com  Sun Jun 11 12:04:37 2006
From: tod at todbot.com (Tod E. Kurt)
Date: Sun, 11 Jun 2006 11:04:37 -0700
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <44809E53.2070905@sun.com>
References: <44809E53.2070905@sun.com>
Message-ID: <E2EB14A1-20A7-4611-8F1A-E3D2ABE41F48@todbot.com>

A dumb question, but: do you have the USB serial adapters plugged  
in?  They only show up in /dev when plugged in.  Also, you can verify  
they exist independent of RXTX by doing something like "ls -l /dev/ 
cu.*".

On Jun 2, 2006, at 1:23 PM, Ugo Landini wrote:

> Hi, I have installed the library and the native libraries on OSX  
> 10.4.7.
> Then I have run this simple code:
>
> ...
> while (portList.hasMoreElements()) {
>              portId = (CommPortIdentifier) portList.nextElement();
>              System.out.println("-> " + portId.getName() + " Port  
> Type:"
> + portId.getPortType());
> ...
>
> and the output is:
>
> Experimental:  JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
>
> Ports found:
> -> /dev/tty.Bluetooth-PDA-Sync Port Type:1
> -> /dev/cu.Bluetooth-PDA-Sync Port Type:1
> -> /dev/tty.Bluetooth-Modem Port Type:1
> -> /dev/cu.Bluetooth-Modem Port Type:1
>
> I can't see any USB ports... with javax.comm on linux I could see the
> /dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>
> tia
>
> uL
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>



From lyon at docjava.com  Sun Jun 11 12:14:50 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Sun, 11 Jun 2006 14:14:50 -0400
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <44809E53.2070905@sun.com>
References: <44809E53.2070905@sun.com>
Message-ID: <p06020444c0b20de7d248@[192.168.1.152]>

>Hi Ugo,

Do you have any USB serial ports (like the keyspan 19-HS) plugged
into the mac?
Thanks!
  - DL


>Hi, I have installed the library and the native libraries on OSX 10.4.7.
>Then I have run this simple code:
>
>...
>while (portList.hasMoreElements()) {
>              portId = (CommPortIdentifier) portList.nextElement();
>              System.out.println("-> " + portId.getName() + " Port Type:"
>+ portId.getPortType());
>...
>
>and the output is:
>
>Experimental:  JNI_OnLoad called.
>Stable Library
>=========================================
>Native lib Version = RXTX-2.1-7
>Java lib Version   = RXTX-2.1-7
>
>Ports found:
>-> /dev/tty.Bluetooth-PDA-Sync Port Type:1
>-> /dev/cu.Bluetooth-PDA-Sync Port Type:1
>-> /dev/tty.Bluetooth-Modem Port Type:1
>-> /dev/cu.Bluetooth-Modem Port Type:1
>
>I can't see any USB ports... with javax.comm on linux I could see the
>/dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>
>tia
>
>uL
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx



From dmarkman at mac.com  Sun Jun 11 14:30:27 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Sun, 11 Jun 2006 16:30:27 -0400
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <p06020444c0b20de7d248@[192.168.1.152]>
References: <44809E53.2070905@sun.com> <p06020444c0b20de7d248@[192.168.1.152]>
Message-ID: <B9C1606B-4339-4564-A175-FE83DFFA7D76@mac.com>

afaik
10.4.7 wasn't released yet
it will soon, no doubts


On Jun 11, 2006, at 2:14 PM, Dr. Douglas Lyon wrote:

>> Hi Ugo,
>
> Do you have any USB serial ports (like the keyspan 19-HS) plugged
> into the mac?
> Thanks!
>   - DL
>
>
>> Hi, I have installed the library and the native libraries on OSX  
>> 10.4.7.
>> Then I have run this simple code:
>>
>> ...
>> while (portList.hasMoreElements()) {
>>              portId = (CommPortIdentifier) portList.nextElement();
>>              System.out.println("-> " + portId.getName() + " Port  
>> Type:"
>> + portId.getPortType());
>> ...
>>
>> and the output is:
>>
>> Experimental:  JNI_OnLoad called.
>> Stable Library
>> =========================================
>> Native lib Version = RXTX-2.1-7
>> Java lib Version   = RXTX-2.1-7
>>
>> Ports found:
>> -> /dev/tty.Bluetooth-PDA-Sync Port Type:1
>> -> /dev/cu.Bluetooth-PDA-Sync Port Type:1
>> -> /dev/tty.Bluetooth-Modem Port Type:1
>> -> /dev/cu.Bluetooth-Modem Port Type:1
>>
>> I can't see any USB ports... with javax.comm on linux I could see the
>> /dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>>
>> tia
>>
>> uL
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman



From tjarvi at qbang.org  Sun Jun 11 18:52:59 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 11 Jun 2006 18:52:59 -0600 (MDT)
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <4489C786.9050504@dupreeinc.com>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
	<4489C786.9050504@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606111845430.7274@www>

On Fri, 9 Jun 2006, Doug Thistlethwaite wrote:

>
> Ideally, it would be nice if it would throw an exception and terminate the 
> loop.  I am still trying to figure out how to detect the condition and 
> recover form it in some form...  I am getting the "No error in readByte" 
> exception in my serialEvent() method after an input stream read.  It appears 
> to me that the only graceful recovery is to close the port and then reopen it 
> when it becomes available.  I can pass the event up to the update method in 
> my main frame, but I still can't close the port from within that thread.  Any 
> suggestions on how to pass this event to a location where the port can be 
> safely closed?
>

I've gone through and cleaned up the termios.c layer.  I need to get to a 
windows machine with a USB dongle and see where the ioctl() is being 
called.  Probably the eventLoop.  But all of the ioctls should probably 
result in an IOException during this condition.

I'll probably finish this up Monday night when I can borrow a USB 
dongle.

There is no point in putting the code into CVS yet.  If you are tinkering 
I can mail the patch.  I think we will want to make a couple fixes in 
SerialImp.c to handle errors before it's ready.

--
Trent Jarvi
tjarvi at qbang.org



From bob_tai2001 at yahoo.com  Mon Jun 12 09:42:14 2006
From: bob_tai2001 at yahoo.com (Bob Tai)
Date: Mon, 12 Jun 2006 08:42:14 -0700 (PDT)
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to RXTX
	again
Message-ID: <20060612154214.58219.qmail@web32804.mail.mud.yahoo.com>


thank you Paul, Joachim, Trent and everyone try to
workout the java comm and Rxtx situation.  At least
now I have something that is solid enough to make my
decision.  

thank you,
     Bob

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From Ralph.Buchfelder at gmx.net  Mon Jun 12 15:30:20 2006
From: Ralph.Buchfelder at gmx.net (Ralph Buchfelder)
Date: Mon, 12 Jun 2006 23:30:20 +0200
Subject: [Rxtx] rxtx binaries or porting to XSCALE Windows Mobile 2003 / 2005
Message-ID: <448DDCEC.7090506@gmx.net>

dear group,

i have been carefully reading your homepage, wiki and archives
but there seems to be no detailled information on porting to Windows 
Mobile/CE.

as far as i understood from the 'porting' section you can do porting to 
winCE. but how? do i only need to obtain the sourcecode (which one?) and 
compile this in Microsoft eMbedded Visual C++ for ARM/Xscale?
Any other ways?


unfortunately i must admit that i do have little linux skills but i have 
made my way through gcc and makefiles. right now i need to implement com 
  communication in a J2ME application and found your website as >the< 
solution.

best regards
Ralph Buchfelder

University of Regensburg
Department of Geography

PS: i dont care about Javacomm compliancy (ie. 2.0 or 2.1) - i just need 
a working serial port API in IBM J9 VM.


From paul.klissner at sun.com  Wed Jun 14 18:12:58 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Wed, 14 Jun 2006 17:12:58 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
Message-ID: <4490A60A.9090305@sun.com>

Hello RxTx community,

I finally think I have a compromise in place that will stand in the gap.

If you go to http://www.sun.com and search for javax.comm, you'll
get taken to a download page, where now users can get a copy of the
comm.jar file out of 2.0.3, along with just a license and a README.

I trust this will suffice until such time as RxTx decided to implement
their own java classes or we can get a JSR going to mitigate some
of the problems (the readme in the comm.jar 2.0.3 zip file
contains my thoughts on that).

Thanks,
Paul



From tjarvi at qbang.org  Wed Jun 14 21:15:35 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 14 Jun 2006 21:15:35 -0600 (MDT)
Subject: [Rxtx] rxtx-2.0-7 (final) src is in CVS
Message-ID: <Pine.LNX.4.61.0606142100500.2742@www>


I wasn't expecting to be working on rxtx 2.0 tonight :)

Thanks go out to Paul Klissner for his work in making the coming release 
of rxtx-2.0-7 possible for users that require package javax.comm on many 
platforms.

Most people know that rxtx 2.0 is for use with Sun's CommAPI 2.0 for 
Solaris or the Generic CommAPI 2.0-3 available for download at Sun.  If 
you need javax.comm packages on many platforms, you are probably 
interested.  If you use rxtx 2.1 in package gnu.io, then you are not going 
to care much.

I've tried to update the rxtx 2.0 src directory in preparation for 
rxtx-2.0-7 (final).  Linux should compile.  Windows will compile if you 
generate your own .def files (I'll generate these tomorrow).  If you have 
some time to do basic testing of the source, I'd appreciate it.  The 
source should be good but you may find classes not found.  This source is 
a backport from rxtx 2.1.

I wanted to get things started so anyone interested on Mac OS X could get 
a head start.

All of this is in CVS.  http://www.rxtx.org/cvs.html

I suspect we will have binaries for testing in a couple days if you are 
unable to compile.   Consider this a smoke test.

--
Trent Jarvi
tjarvi at qbang.org


From legolas.w at gmail.com  Wed Jun 14 22:04:28 2006
From: legolas.w at gmail.com (Legolas Woodland)
Date: Wed, 14 Jun 2006 21:04:28 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <4490A60A.9090305@sun.com>
References: <4490A60A.9090305@sun.com>
Message-ID: <87ee9b170606142104p745fcef0vea622fbc8f528bfc@mail.gmail.com>

is there anything new in this version of javax.comm ?
thanks


On 6/14/06, Paul Klissner <paul.klissner at sun.com> wrote:
>
> Hello RxTx community,
>
> I finally think I have a compromise in place that will stand in the gap.
>
> If you go to http://www.sun.com and search for javax.comm, you'll
> get taken to a download page, where now users can get a copy of the
> comm.jar file out of 2.0.3, along with just a license and a README.
>
> I trust this will suffice until such time as RxTx decided to implement
> their own java classes or we can get a JSR going to mitigate some
> of the problems (the readme in the comm.jar 2.0.3 zip file
> contains my thoughts on that).
>
> Thanks,
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060614/5ff4dfbc/attachment-0012.html

From joachim at buechse.de  Thu Jun 15 07:22:48 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 15 Jun 2006 15:22:48 +0200
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
Message-ID: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>

Good day!

Some of my users report problems using RXTX 2.1.7 on Windows98 to  
communicate with an FTDI FT245BM chip (using their latest VCP  
driver). Either no ports are being shown (ie returned form  
CommPortIdentifier.getPortIdentifiers()) or the transfers fail.

Did anyone run into similar Problems with Win98??

Best regards,
Joachim



From ajmas at sympatico.ca  Thu Jun 15 08:12:28 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Thu, 15 Jun 2006 10:12:28 -0400
Subject: [Rxtx] API change question
Message-ID: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

How closely do you follow the Java Communication API spec? The reason I ask is because I would be interested in augmenting the CommPortIdentifier class to include a getDisplayName() method. By default it would return the same value as getName(), but would provide the possibility of displaying a 'user friendly' name, for platforms where the display name is not the same as the device name. An example of this is on MacOS X, where currently the names seem to be of the form /dev/cu.* and /dev/tty.*, yet what the expects to see is simply the part after the full-stop. Although I could move this logic into the Java code, it would be nice to see it transparent to the Java code.

Andre




From ajmas at sympatico.ca  Thu Jun 15 08:16:22 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Thu, 15 Jun 2006 10:16:22 -0400
Subject: [Rxtx] Package to use
Message-ID: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

While the Java API spec refers to javax.comm, I see that only gnu.io is provide by the rxtx project. Should our projects refer to the gnu.io package or the javax.comm API?

Andre



From joachim at buechse.de  Thu Jun 15 08:45:05 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 15 Jun 2006 16:45:05 +0200
Subject: [Rxtx] API change question
In-Reply-To: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>

Hello Andre,

the /dev/cu and /dev/tty have different semantics on OS X. It is much  
more than a simply naming issue to unify them, see my recent mail to  
the list...

Best regards,
Joachim


On 15.06.2006, at 16:12, Andre-John Mas wrote:

> Hi,
>
> How closely do you follow the Java Communication API spec? The  
> reason I ask is because I would be interested in augmenting the  
> CommPortIdentifier class to include a getDisplayName() method. By  
> default it would return the same value as getName(), but would  
> provide the possibility of displaying a 'user friendly' name, for  
> platforms where the display name is not the same as the device  
> name. An example of this is on MacOS X, where currently the names  
> seem to be of the form /dev/cu.* and /dev/tty.*, yet what the  
> expects to see is simply the part after the full-stop. Although I  
> could move this logic into the Java code, it would be nice to see  
> it transparent to the Java code.
>
> Andre
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From lyon at docjava.com  Thu Jun 15 10:16:29 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Thu, 15 Jun 2006 12:16:29 -0400
Subject: [Rxtx] cu.modem != /dev/ttya on mac.
In-Reply-To: <763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
	<763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>
Message-ID: <p0602046cc0b7378a95b0@[192.168.1.152]>

>Hi All,

I think that Joachim is correct. For the longest time,
I have been trying to figure out how to direct dial using
the cu.modem on the mac under os x.

As a less-than-optimal approach to auto-dialing, I have used
a keyspan USB 19HS adapter, along with an external modem, to
obtain the dialing feature.

Ideally, it would be better to dial with the built-in modem...but that did not
always seem to work, for some reason. Have others had some experience with
using the built in modem for dialing on the mac?

Thanks!
  - Doug


>Hello Andre,
>
>the /dev/cu and /dev/tty have different semantics on OS X. It is much?
>more than a simply naming issue to unify them, see my recent mail to?
>the list...
>
>Best regards,
>Joachim
>



From doug at dupreeinc.com  Thu Jun 15 14:52:50 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 15 Jun 2006 13:52:50 -0700
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
In-Reply-To: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
References: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
Message-ID: <4491C8A2.8090108@dupreeinc.com>

Hi Joachim,

I have been doing a lot with the new FTDI driver with win XP and have 
not had that particular problem.  I did notice that the new driver 
(dated May19th, 2006) is only for XP, Server 2003, and 2000.  Are they 
trying to use the 2.00.00 drivers or the old 1.09.06 version.  I am 
using a FT232R based module, but it uses the same drivers and I assume 
it would have the same problems.  Let me know which driver they are 
using and I can load up a 98 system here and see if  I can duplicate the 
problem.

Doug

Joachim Buechse wrote:

>Good day!
>
>Some of my users report problems using RXTX 2.1.7 on Windows98 to  
>communicate with an FTDI FT245BM chip (using their latest VCP  
>driver). Either no ports are being shown (ie returned form  
>CommPortIdentifier.getPortIdentifiers()) or the transfers fail.
>
>Did anyone run into similar Problems with Win98??
>
>Best regards,
>Joachim
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From matthewhepp at yahoo.com  Thu Jun 15 17:34:47 2006
From: matthewhepp at yahoo.com (Matthew Hepp)
Date: Thu, 15 Jun 2006 16:34:47 -0700 (PDT)
Subject: [Rxtx] Wither the XCode project?
Message-ID: <20060615233447.48064.qmail@web50311.mail.yahoo.com>

Either I don't know how to properly use CVS (entirely possibl), or the XCode
project is not making through the update properly. Doing a "cvs update" against
2.1-7 creates an XCode folder in MACOSX_IDE, and therein a
LibSerialUniversal.xcodeproj, but trying to open it yields a "Unable to Open
Project - Project rxtx-devel/MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj
cannot be opened because it is missing its project.pbxproj file" error. Showing
package contents reveals just the cvs-related files. Perhaps this is why
previous xcode projects have been saved as an sit.hqx - to retain the resource
fork?

Can someone point me in the right direction?

Thanks,

Matt

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Thu Jun 15 19:53:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 19:53:06 -0600 (MDT)
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
In-Reply-To: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
References: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
Message-ID: <Pine.LNX.4.61.0606151944070.23137@www>

On Thu, 15 Jun 2006, Joachim Buechse wrote:

> Good day!
>
> Some of my users report problems using RXTX 2.1.7 on Windows98 to
> communicate with an FTDI FT245BM chip (using their latest VCP
> driver). Either no ports are being shown (ie returned form
> CommPortIdentifier.getPortIdentifiers()) or the transfers fail.
>
> Did anyone run into similar Problems with Win98??
>

Hi Joachim

It has been a long time since I've tested win98.  I know rxtx-2.1-7pre16 
did get testing on win98 with ~jdk 1.3 though.  I wonder if jdks are still 
tested on that platform.

With win98 you usually have older boxes.  They can be short on CPU and 
memory.  Enumeration should work but I could picture runtime performance 
issues on win98.

The enumeration problems could result from other copies of your 
application if various states of decay still holding onto the port.  When 
things go wrong, people also like to open other terminal software to see 
whats going on which can interfere.  You can't open a windows port with 
two apps.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Thu Jun 15 20:08:53 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 20:08:53 -0600 (MDT)
Subject: [Rxtx] API change question
In-Reply-To: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606151954270.23137@www>

On Thu, 15 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> How closely do you follow the Java Communication API spec?

I can explain how this worked in the past.  How we do it in the future is 
open for discussion.

In the past we have tried to follow it as close as possible in gnu.io 
(rxtx 2.1).  We have added extensions but try to discourage their use. 
The extensions are clearly marked as such in the source code and javadocs.

rxtx 2.0 was intended to be a strict implementation of part of the spec. 
We let Sun's interfaces decide what methods can be called. There are 
differences not covered by the spec such as default values.  Thats not 
intentional but rather hard to avoid.

--
Trent Jarvi
tjarvi at qbang.org





From tjarvi at qbang.org  Thu Jun 15 21:09:11 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 21:09:11 -0600 (MDT)
Subject: [Rxtx] Package to use
In-Reply-To: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606152026120.23137@www>

On Thu, 15 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> While the Java API spec refers to javax.comm, I see that only gnu.io is 
> provide by the rxtx project. Should our projects refer to the gnu.io 
> package or the javax.comm API?
>

Hi Andre

Lets see if I can give a fair and balanced answer to that.

If you are starting a new project and want to use RXTX, I would recommend 
using gnu.io.  The community support for gnu.io will not be going away 
anytime soon.  You can switch between gnu.io (2.1) and javax.comm (2.0) 
fairly easily.  They are not intended to be incompatible.  You just change 
package names and libs.

You can also consider the combination of rxtx 2.0 with Sun's commapi 
2.0-3.  This is considered a stop-gap measure by Sun for previous users of 
that combination.  Together rxtx 2.0 and Sun CommAPI 2.0 work in namespace 
javax.comm for programmers.

Finally, you can opt to just use Sun's oferrings in CommAPI 3.0 without 
rxtx.  That would be in namespace javax.comm also.  CommAPI 3.0 may be 
of more interest to you if you are looking at POS with Sun computers. 
Rxtx does not currently support the changes in CommAPI 3.0 or have firm 
plans to do so.  That does not mean we wouldn't implement them.  It just 
means nobody has contributed code yet.

You can't combine rxtx with CommAPI 3.0 for technical reasons that wont 
likely be fixed soon.

It's up to you as far as what you use.  We like to provide the freedom so 
you can choose.  Realistically, we will be supporting gnu.io mainly 
because we have some control over that name space and can support it.

Things may happen in the future that enable rxtx to provide more support 
in the javax namespace but that has not happened yet.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun 16 00:33:06 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 08:33:06 +0200
Subject: [Rxtx] Wither the XCode project?
In-Reply-To: <20060615233447.48064.qmail@web50311.mail.yahoo.com>
References: <20060615233447.48064.qmail@web50311.mail.yahoo.com>
Message-ID: <D30D660F-A49B-464E-AE4C-6B4563893682@buechse.de>

Hello Matthew,

could you please send me the contents of your

   rxtx-devel/CVS
   rxtx-devel/MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj/CVS

directories as a zip to my personal email address. This should  
indicate why the file is not checked out. I can see that it exists on  
the correct branch in the repository, so something must have gone  
wrong during the "cvs update"...

Best regards,
Joachim

On 16.06.2006, at 01:34, Matthew Hepp wrote:

> Either I don't know how to properly use CVS (entirely possibl), or  
> the XCode
> project is not making through the update properly. Doing a "cvs  
> update" against
> 2.1-7 creates an XCode folder in MACOSX_IDE, and therein a
> LibSerialUniversal.xcodeproj, but trying to open it yields a  
> "Unable to Open
> Project - Project rxtx-devel/MACOSX_IDE/XCode/ 
> LibSerialUniversal.xcodeproj
> cannot be opened because it is missing its project.pbxproj file"  
> error. Showing
> package contents reveals just the cvs-related files. Perhaps this  
> is why
> previous xcode projects have been saved as an sit.hqx - to retain  
> the resource
> fork?
>
> Can someone point me in the right direction?



From joachim at buechse.de  Fri Jun 16 10:41:20 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 18:41:20 +0200
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <p06230903c0b88613dca6@[10.0.1.7]>
References: <p06230903c0b88613dca6@[10.0.1.7]>
Message-ID: <03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>

Hello Bob,

until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was  
behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if  
Trent has migrated all recent changes from 2.1 to 2.0.

I have added the XCode project and updated documentation only to the  
gnu.io branch. Once the 2.0 implementation is up to date I will copy  
over the documentation/build files make them work.

Best regards,
Joachim

On 16.06.2006, at 18:07, Bob Jacobsen wrote:

> I'm one of the developers for the JMRI project, which provides  
> model railroad software in Java.  We've been using RXTX to provide  
> serial port access on MacOS X and Linux; we use the old javax.comm  
> 2.0 on Windows, OS/2 and Solaris.  Because of that, we need to stay  
> with RXTX 2.0, not 2.1
>
> We've been using the 2.0-pre17 installer for a long time, but it's  
> not compatible with Intel macs.
>
> Can you point me to where I can find the right files for RXTX 2.0  
> to package with the program?
>
> The current situation is confusing to me.  I've been pointed to  
> recent 2.1 versions (but we need the javax.comm names), to an even  
> older installer, etc.  I've been reading that some versions require  
> an installer, and others don't, but I haven't been able to figure  
> out which (if any) of those are where in CVS.
>
> I'd really appreciate a clear statement of what files to use and  
> what to do with them that I can pass on to our users.
>
> I'm more than happy to put files in the local classpath, have users  
> run an installer, or anything else.  Whatever is easiest for you.
>
> Thanks!  I really appreciate all that you do to keep RXTX working.
>
> Bob
> -- 
> Bob Jacobsen +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG



From joachim at buechse.de  Fri Jun 16 09:59:28 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 17:59:28 +0200
Subject: [Rxtx] Wither the XCode project?
In-Reply-To: <20060616150240.49464.qmail@web50309.mail.yahoo.com>
References: <20060616150240.49464.qmail@web50309.mail.yahoo.com>
Message-ID: <D9935E05-2B83-488D-86DD-42599E229052@buechse.de>

Hello Matthew,

you have checked out the trunk (which is the 2.0.7 javax.comm.xxx  
release). For rxtx-2.1.7 (gnu.io.xxx release) you need to check out  
the branch

      commapi-0-0-1

The easiest way to do this is to download the rxtx src archive,  
unpack it and then do a cvs up inside the decompressed tree.  
Optionally you could do a

      cvs co -r commapi-0-0-1

but this will take much longer!

Best regards,
Joachim

When you do a cvs status it will show the sticky tag.

41:~/jdevelop/rxtx-2.1-7r2 joachim$ cvs status README.OSX
===================================================================
File: README.OSX        Status: Up-to-date

    Working revision:    1.1.2.1
    Repository revision: 1.1.2.1 /usr/local/cvsroot/rxtx-devel/Attic/ 
README.OSX,v
    Sticky Tag:          commapi-0-0-1 (branch: 1.1.2)
    Sticky Date:         (none)
    Sticky Options:      (none)




On 16.06.2006, at 17:02, Matthew Hepp wrote:

> %cvs status README.MACOSX
> ===================================================================
> File: README.MACOSX     Status: Up-to-date
>
>    Working revision:    1.1
>    Repository revision: 1.1     /usr/local/cvsroot/rxtx-devel/ 
> README.MACOSX,v
>    Sticky Tag:          (none)
>    Sticky Date:         (none)
>    Sticky Options:      (none)



From tjarvi at qbang.org  Fri Jun 16 16:31:18 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Fri, 16 Jun 2006 16:31:18 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
Message-ID: <Pine.LNX.4.61.0606161630030.14139@www>

On Fri, 16 Jun 2006, Joachim Buechse wrote:

> Hello Bob,
>
> until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was
> behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if
> Trent has migrated all recent changes from 2.1 to 2.0.
>

The src/ directory and configure.in/configure files should be fine.  I 
have not touched the Mac OS X directories.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sat Jun 17 02:39:55 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sat, 17 Jun 2006 10:39:55 +0200
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <Pine.LNX.4.61.0606161630030.14139@www>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
Message-ID: <350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>

Hello Trent,

apparently the IOEXCL changes have not made it into 2.0. I will add  
them to achieve a minimal diff between 2.0 and 2.1.

One other thing that bugs me for a while...

Shouldn't we replace "if !defined(TIOCSERGETLSR) && !defined(WIN32)"  
by a definition of its own "if defined(DRAINTHREAD)"? I think this  
would make the code clearer for people starting to read it.

Regards,
Joachim


On 17.06.2006, at 00:31, Trent Jarvi wrote:

> On Fri, 16 Jun 2006, Joachim Buechse wrote:
>
>> Hello Bob,
>>
>> until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was
>> behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if
>> Trent has migrated all recent changes from 2.1 to 2.0.
>>
>
> The src/ directory and configure.in/configure files should be fine.  I
> have not touched the Mac OS X directories.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From tropicsu at hotmail.com  Sat Jun 17 09:32:48 2006
From: tropicsu at hotmail.com (Yoke K)
Date: Sat, 17 Jun 2006 15:32:48 +0000
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
Message-ID: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>

Hi,

I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to work with 
MAC OS X.
I am using iTegno 3000 - USB GPRS Modem.

Files in /dev and a symbolic link as follows:

crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 -> tty.usbserial

In my SendMessage.java, I have this line:
CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");

Appreciate any help ?

- Jon


Errors as follows:

>>INFO: SMSLib API for Java / v1.2.2
>>INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>INFO: JRE Version: 1.5.0_06
>>INFO: JRE Impl Version: 1.5.0_06-64
>>INFO: O/S: Mac OS X / ppc / 10.4.6
>>INFO: Using Wavecom (Generic) AT handler.

SendMessage(): Send a message.
  Using SMSLib API for Java v1.2.2

Connecting ..... :
>>INFO: CSerialDriver(): Connecting...
Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
>>INFO: CSerialDriver(): Disconnecting...
gnu.io.NoSuchPortException
        at 
gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:218)
        at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
        at org.smslib.CService.connect(CService.java:197)
        at SendMessage.main(SendMessage.java:38)

_________________________________________________________________
Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/



From tjarvi at qbang.org  Sat Jun 17 10:12:30 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 10:12:30 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
	<350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
Message-ID: <Pine.LNX.4.61.0606171010060.14139@www>

On Sat, 17 Jun 2006, Joachim Buechse wrote:

> Hello Trent,
>
> apparently the IOEXCL changes have not made it into 2.0. I will add
> them to achieve a minimal diff between 2.0 and 2.1.
>

Hi Joachim

As I recall the IOEXCL change was after 2.1-7.  I was just syncing with 
2.1-7.  We can release 2.1-8 and 2.0-8 with the same changes.

> One other thing that bugs me for a while...
>
> Shouldn't we replace "if !defined(TIOCSERGETLSR) && !defined(WIN32)"
> by a definition of its own "if defined(DRAINTHREAD)"? I think this
> would make the code clearer for people starting to read it.
>


Sure.  We can do that for -8.  The TIOCSERGETLSR code should be a special 
case not the expected.  I think only Linux uses it.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Sat Jun 17 10:48:21 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 10:48:21 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <Pine.LNX.4.61.0606171010060.14139@www>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
	<350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
	<Pine.LNX.4.61.0606171010060.14139@www>
Message-ID: <Pine.LNX.4.61.0606171047310.14139@www>

On Sat, 17 Jun 2006, Trent Jarvi wrote:

> On Sat, 17 Jun 2006, Joachim Buechse wrote:
>
>> Hello Trent,
>>
>> apparently the IOEXCL changes have not made it into 2.0. I will add
>> them to achieve a minimal diff between 2.0 and 2.1.
>>
>
> Hi Joachim
>
> As I recall the IOEXCL change was after 2.1-7.  I was just syncing with
> 2.1-7.  We can release 2.1-8 and 2.0-8 with the same changes.
>

We could just move to 2.1-8 and 2.0-8.

--
Trent Jarvi
tjarvi at qbang.org


From brian.t.lamb at gmail.com  Tue Jun 13 13:54:13 2006
From: brian.t.lamb at gmail.com (Brian Lamb)
Date: Tue, 13 Jun 2006 15:54:13 -0400
Subject: [Rxtx] Windows XP Installation
Message-ID: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>

I've not installed Java packages on Windows before and am unsure how to
proceed. All the documentation I've seen provides detailed instructions on
how to install on Linux or Solaris. I was wondering how to install rxtx on
Windows XP.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060613/6f68cd5c/attachment-0012.html

From tjarvi at qbang.org  Sat Jun 17 13:57:03 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 13:57:03 -0600 (MDT)
Subject: [Rxtx] Windows XP Installation
In-Reply-To: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>
References: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0606171356120.14139@www>

On Tue, 13 Jun 2006, Brian Lamb wrote:

> I've not installed Java packages on Windows before and am unsure how to
> proceed. All the documentation I've seen provides detailed instructions on
> how to install on Linux or Solaris. I was wondering how to install rxtx on
> Windows XP.
>

Hi Brian

Which rxtx version are you trying to install?

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sun Jun 18 10:41:44 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sun, 18 Jun 2006 18:41:44 +0200
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
References: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
Message-ID: <8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>

Hello Jon,

 From OSX's standpoint a symbolic link is not a device (as far as I  
know). What stops you from using tty.usbserial? Did you try hard- 
linking?

Regards,
Joachim

On 17.06.2006, at 17:32, Yoke K wrote:
> Hi,
>
> I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to  
> work with
> MAC OS X.
> I am using iTegno 3000 - USB GPRS Modem.
>
> Files in /dev and a symbolic link as follows:
>
> crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
> crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
> lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->  
> tty.usbserial
>
> In my SendMessage.java, I have this line:
> CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
>
> Appreciate any help ?
>
> - Jon
>
>
> Errors as follows:
>
>>> INFO: SMSLib API for Java / v1.2.2
>>> INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>> INFO: JRE Version: 1.5.0_06
>>> INFO: JRE Impl Version: 1.5.0_06-64
>>> INFO: O/S: Mac OS X / ppc / 10.4.6
>>> INFO: Using Wavecom (Generic) AT handler.
>
> SendMessage(): Send a message.
>   Using SMSLib API for Java v1.2.2
>
> Connecting ..... :
>>> INFO: CSerialDriver(): Connecting...
> Experimental:  JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
>>> INFO: CSerialDriver(): Disconnecting...
> gnu.io.NoSuchPortException
>         at
> gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java: 
> 218)
>         at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
>         at org.smslib.CService.connect(CService.java:197)
>         at SendMessage.main(SendMessage.java:38)
>
> _________________________________________________________________
> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Sun Jun 18 10:56:55 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 12:56:55 -0400
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>
References: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
	<8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>
Message-ID: <7B6834E3-F41D-46B6-B979-55466BC73859@sympatico.ca>

Have you been able to get any other software to talk with your
modem? What port is it using? Have tried using the cu.usbserial
instead?

Andre

On 18-Jun-06, at 12:41 , Joachim Buechse wrote:

> Hello Jon,
>
>  From OSX's standpoint a symbolic link is not a device (as far as I
> know). What stops you from using tty.usbserial? Did you try hard-
> linking?
>
> Regards,
> Joachim
>
> On 17.06.2006, at 17:32, Yoke K wrote:
>> Hi,
>>
>> I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to
>> work with
>> MAC OS X.
>> I am using iTegno 3000 - USB GPRS Modem.
>>
>> Files in /dev and a symbolic link as follows:
>>
>> crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
>> crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
>> lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->
>> tty.usbserial
>>
>> In my SendMessage.java, I have this line:
>> CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
>>
>> Appreciate any help ?
>>
>> - Jon
>>
>>
>> Errors as follows:
>>
>>>> INFO: SMSLib API for Java / v1.2.2
>>>> INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>>> INFO: JRE Version: 1.5.0_06
>>>> INFO: JRE Impl Version: 1.5.0_06-64
>>>> INFO: O/S: Mac OS X / ppc / 10.4.6
>>>> INFO: Using Wavecom (Generic) AT handler.
>>
>> SendMessage(): Send a message.
>>   Using SMSLib API for Java v1.2.2
>>
>> Connecting ..... :
>>>> INFO: CSerialDriver(): Connecting...
>> Experimental:  JNI_OnLoad called.
>> Stable Library
>> =========================================
>> Native lib Version = RXTX-2.1-7
>> Java lib Version   = RXTX-2.1-7
>>>> INFO: CSerialDriver(): Disconnecting...
>> gnu.io.NoSuchPortException
>>         at
>> gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:
>> 218)
>>         at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
>>         at org.smslib.CService.connect(CService.java:197)
>>         at SendMessage.main(SendMessage.java:38)
>>
>> _________________________________________________________________
>> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Sun Jun 18 17:33:08 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 19:33:08 -0400
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
Message-ID: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>

Hi,

I am have a program that I wrote in Java to communicate with a  
Bluetooth GPS device. I am
trying to get this working on my Mac, but I keep getting told that:

gnu.io.PortInUseException: Unknown Application

but

portIdentifier.isCurrentlyOwned()

returns false and when I do lsof on the device I am trying to connect  
to, I see no application
using it. As the same time if I go to the command line and use  
minicom I have no issues. The
exception happens with this call:

CommPort commPort = portIdentifier.open(null,0);

Any suggestions?

Andre


From ajmas at sympatico.ca  Sun Jun 18 17:45:11 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 19:45:11 -0400
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
Message-ID: <30245B30-682D-4EAE-8084-8227B719F10D@sympatico.ca>

BTW My code snippet is:

     private InputStream connectToSerial () throws IOException,  
Exception
     {
         InputStream in = null;

         Enumeration portEnum = CommPortIdentifier.getPortIdentifiers();
         while ( portEnum.hasMoreElements() )
         {
             CommPortIdentifier portIdentifier = (CommPortIdentifier)  
portEnum.nextElement();
             System.out.println(portIdentifier.getName() + " - " +  
portIdentifier.getPortType() );
         }

         CommPortIdentifier portIdentifier =  
CommPortIdentifier.getPortIdentifier("/dev/cu.BTGPS-SPPslave-1");
         System.out.println("current owner: " +  
portIdentifier.getCurrentOwner());
         if ( portIdentifier.isCurrentlyOwned() )
         {
             System.out.println("Error: Port is currently in use");
             return null;
         }
         else
         {
             CommPort commPort = portIdentifier.open(this.getClass 
().getName(),2000);

             if ( commPort instanceof SerialPort )
             {
                 SerialPort serialPort = (SerialPort) commPort;
                 serialPort.setSerialPortParams 
(4800,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE 
);
                 in = serialPort.getInputStream();

                 return in;
             }
             else
             {
                 System.out.println("Error: Only serial ports are  
handled.");
             }
         }


         return in;
     }


On 18-Jun-06, at 19:33 , Andr?-John Mas wrote:

> Hi,
>
> I am have a program that I wrote in Java to communicate with a
> Bluetooth GPS device. I am
> trying to get this working on my Mac, but I keep getting told that:
>
> gnu.io.PortInUseException: Unknown Application
>
> but
>
> portIdentifier.isCurrentlyOwned()
>
> returns false and when I do lsof on the device I am trying to connect
> to, I see no application
> using it. As the same time if I go to the command line and use
> minicom I have no issues. The
> exception happens with this call:
>
> CommPort commPort = portIdentifier.open(null,0);
>
> Any suggestions?
>
> Andre
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From joachim at buechse.de  Mon Jun 19 05:54:49 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 13:54:49 +0200
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de>

This is most likely due to a problem with lock files. If you have  
downloaded the binaries of 2.17 rxtx will try to create non-standard  
lock files on OSX. We have since changed the code to use OSX device  
locking - however the binaries have not been updated yet. The 2.18  
release fixing this issue is due shortly.

Regards,
Joachim

On 19.06.2006, at 01:33, Andr?-John Mas wrote:

> Hi,
>
> I am have a program that I wrote in Java to communicate with a
> Bluetooth GPS device. I am
> trying to get this working on my Mac, but I keep getting told that:
>
> gnu.io.PortInUseException: Unknown Application
>
> but
>
> portIdentifier.isCurrentlyOwned()
>
> returns false and when I do lsof on the device I am trying to connect
> to, I see no application
> using it. As the same time if I go to the command line and use
> minicom I have no issues. The
> exception happens with this call:
>
> CommPort commPort = portIdentifier.open(null,0);
>
> Any suggestions?
>
> Andre
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From joachim at buechse.de  Mon Jun 19 06:44:27 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 14:44:27 +0200
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <4490A60A.9090305@sun.com>
References: <4490A60A.9090305@sun.com>
Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>

Hello Paul,

I just downloaded the "generic" javax.comm version now available. A  
first check indicates, that it was compiled with a JDK 1.4 javac  
without setting the target classfile version. In other words in can  
not be loaded by 1.1-1.3 VMs (or PersonalJava).

Do you see any chance to provide a version compiled with classfile  
format 45.3 (ie JVM1.1).

---
52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose  
javax.comm.SerialPort | head -5
Compiled from "SerialPort.java"
public abstract class javax.comm.SerialPort extends javax.comm.CommPort
   SourceFile: "SerialPort.java"
   minor version: 0
   major version: 48
---

Best regards,
Joachim


On 15.06.2006, at 02:12, Paul Klissner wrote:

> Hello RxTx community,
>
> I finally think I have a compromise in place that will stand in the  
> gap.
>
> If you go to http://www.sun.com and search for javax.comm, you'll
> get taken to a download page, where now users can get a copy of the
> comm.jar file out of 2.0.3, along with just a license and a README.
>
> I trust this will suffice until such time as RxTx decided to implement
> their own java classes or we can get a JSR going to mitigate some
> of the problems (the readme in the comm.jar 2.0.3 zip file
> contains my thoughts on that).
>
> Thanks,
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Mon Jun 19 09:11:45 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Mon, 19 Jun 2006 11:11:45 -0400
Subject: [Rxtx] Examples added to Wiki
Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

I have added a couple of examples to the Wiki:

http://rxtx.qbang.org/wiki/index.php/Examples

If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :)

Andre



From paul.klissner at sun.com  Mon Jun 19 10:42:47 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Mon, 19 Jun 2006 09:42:47 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>
References: <4490A60A.9090305@sun.com>
	<03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>
Message-ID: <4496D407.1090609@sun.com>

Joachim Buechse wrote:
> Hello Paul,
> 
> I just downloaded the "generic" javax.comm version now available. A  
> first check indicates, that it was compiled with a JDK 1.4 javac  
> without setting the target classfile version. In other words in can  
> not be loaded by 1.1-1.3 VMs (or PersonalJava).
> 
> Do you see any chance to provide a version compiled with classfile  
> format 45.3 (ie JVM1.1).
> 
> ---
> 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose  
> javax.comm.SerialPort | head -5
> Compiled from "SerialPort.java"
> public abstract class javax.comm.SerialPort extends javax.comm.CommPort
>    SourceFile: "SerialPort.java"
>    minor version: 0
>    major version: 48
> ---

I cannot promise when I can do that. Since we thought we were done
with javax.comm, the build environment got moved around, and right
now it doesn't even compile in it's new home.  I tried and it was
not cooperative at all. I was never impressed with that workspace
(in fact far far from it, it is a mess, which is why I migrated 3.0
to ant and never looked back).  It will take some real determination
for me to rebuild it, and frankly, right now I'm swamped.  If I can
find a bit of time over the next few weeks to do it, and it isn't
too bad an ordeal, I will.

Posting that will give me an excuse to post javax.comm 3.0, Update 2 as
well, while I'm working with the people who put content up on our
download center.  The only reason for a new update to 3.0 is that
I've changed the distribution to provide ispt (Interactive Serial
Port Tool), such that it can be launched as soon as the zip file
is unpacked, via a provided script.  ISPT is a command line
interactive tool for  manipulating one or two serial port,
sending data, managing events, etc... I've found it to be so useful
for doing certain kinds of validation  that I assume others will
find it useful to.  ISPT is already in 3.0u1, but one has to set
up their own classpath and launch it and since few people ever read
the documentation most won't know about it.  I've added the ability
to set stop bits and parity since 3.0u1 too.  But I digress.

Paul


From joachim at buechse.de  Mon Jun 19 11:01:28 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 19:01:28 +0200
Subject: [Rxtx] load mechanism of 2.0x
Message-ID: <CFD1440C-21AA-4D3B-9EA6-270D0FF9D6FC@buechse.de>

Good day,

I am trying to figure out, how the 2.0x distribution interacts with  
Suns implementation of javax.comm.CommPortIdentifier.

1) Apparently one can put javax.comm.properties in {java.home}/lib
2) The javax.comm package also reacts to -Djavax.comm.properties="...."

Looking at the javap output it also seems like CommPortIdentifier  
tries to find it's jar file and load the properties from there??


What I'm really looking for is a solution that allows using  
javax.comm with RXTX without modifying the VM installation. So I  
would prefer not to use 1) but I can't figure out how to use 2).

Any hints are welcome,
Joachim



From bob_tai2001 at yahoo.com  Mon Jun 19 15:00:35 2006
From: bob_tai2001 at yahoo.com (Bob Tai)
Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT)
Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place
	to start?
Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>

Hi, 

I got  rxtx Windows 2000 installed.  I did not use the
"best" way ... I just follow the insturuction and dump
the necessary files into the jre... I know it's "best"
idea, I got lazy didn't want to change my setting to
my Eclipse and classpath.

I was able to modify SimpleWrite.java to print on my
AddMaster serial printer.  I think I am ready to code!
But I need to make sure I can handle exceptions and so
on.  I notice the \samples\NullDriver\  has two files
seems to have some of the require method done, should
I start coding from those file?  I like the idea it
has the "time out" and basic exceptions done.   I am
slowly digging into the samples, but if you think any
of the code from Sun is good to checkout please let me
know.

btw, http://rxtx.qbang.org/wiki/index.php/Examples/
was very helpful, wish there are more examples.

thank you,

    Bob


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Mon Jun 19 15:55:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT)
Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good
 place to start?
In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>
References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606191542260.14139@www>

> I am
> slowly digging into the samples, but if you think any
> of the code from Sun is good to checkout please let me
> know.
>

I think NullDriver.java was an example stub driver for implementing 
something like rxtx.  It has been a while.  Unless they have been updated, 
you will find the examples are very dated.  You can look at how they use 
the port but avoid the GUI and hard coded variables (number of ports for 
instance).

There was no Swing and nobody knew what requirements today's compilers 
would make on code.  The examples worked fine with jdk 1.1 but times have 
changed.

--
Trent Jarvi
tjarvi at qbang.org


From tropicsu at hotmail.com  Mon Jun 19 19:49:08 2006
From: tropicsu at hotmail.com (Yoke K)
Date: Tue, 20 Jun 2006 01:49:08 +0000
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
Message-ID: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>

An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/fa588f00/attachment-0003.html

From ajmas at sympatico.ca  Mon Jun 19 21:14:37 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Mon, 19 Jun 2006 23:14:37 -0400
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>
References: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>
Message-ID: <CA22AB2A-5712-458B-9984-68477C6042AF@sympatico.ca>

Regarding the PortInUseException, I had a similar issue and got
this response from the mailing list:

   http://mailman.qbang.org/pipermail/rxtx/Week-of- 
Mon-20060619/062838.html

Andre
On 19-Jun-06, at 21:49 , Yoke K wrote:

> Hi Andre, Joachim
>
> I have tried using /dev/tty.usbserial and also /dev/cu.usbserial  
> and it also reported error as  "gnu.io.PortInUseException".
>
> The iTegno modem works in windows environment. As I moving around  
> using my ibook and I need to get it work on MAC OS as well.
>
> >> INFO: SMSLib API for Java / v1.2.2
> >> INFO: Using port: /dev/tty.usbserial @ 115200 baud.
> >> INFO: JRE Version: 1.5.0_06
> >> INFO: JRE Impl Version: 1.5.0_06-64
> >> INFO: O/S: Mac OS X / ppc / 10.4.6
> >> INFO: Using Wavecom (Generic) AT handler.
>
> SendMessage(): Send a message.
> Using SMSLib API for Java v1.2.2
>
> Connecting ..... :
> >> INFO: CSerialDriver(): Connecting...
> Experimental: JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version = RXTX-2.1-7
> >> INFO: CSerialDriver(): Disconnecting...
> gnu.io.PortInUseException: Unknown Application
> at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354)
> at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1)
> at org.smslib.CService.connect(CService.java:197)
> at SendMessage.main(SendMessage.java:38)
>
> Thanks.
>
> - Jon
>
>
>
>
> ====================
>
> Hello Jon,
>
> From OSX's standpoint a symbolic link is not a device (as far as I
> know). What stops you from using tty.usbserial? Did you try hard-
> linking?
>
> Regards,
> Joachim
>
>
>
> From:  "Yoke K" <tropicsu at hotmail.com>
> To:  rxtx at qbang.org
> Subject:  RXTX-2.1-7 / MAC OS X / NoSuchPortException
> Date:  Sat, 17 Jun 2006 15:32:48 +0000
> >Hi,
> >
> >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to
> >work with MAC OS X.
> >I am using iTegno 3000 - USB GPRS Modem.
> >
> >Files in /dev and a symbolic link as follows:
> >
> >crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
> >crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
> >lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->
> >tty.usbserial
> >
> >In my SendMessage.java, I have this line:
> >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
> >
> >Appreciate any help ?
> >
> >- Jon
> >
> >
> >Errors as follows:
> >
> >>>INFO: SMSLib API for Java / v1.2.2
> >>>INFO: Using port: /dev/ttyS1 @ 56000 baud.
> >>>INFO: JRE Version: 1.5.0_06
> >>>INFO: JRE Impl Version: 1.5.0_06-64
> >>>INFO: O/S: Mac OS X / ppc / 10.4.6
> >>>INFO: Using Wavecom (Generic) AT handler.
> >
> >SendMessage(): Send a message.
> >  Using SMSLib API for Java v1.2.2
> >
> >Connecting ..... :
> >>>INFO: CSerialDriver(): Connecting...
> >Experimental:  JNI_OnLoad called.
> >Stable Library
> >=========================================
> >Native lib Version = RXTX-2.1-7
> >Java lib Version   = RXTX-2.1-7
> >>>INFO: CSerialDriver(): Disconnecting...
> >gnu.io.NoSuchPortException
> >        at
> >gnu.io.CommPortIdentifier.getPortIdentifier 
> (CommPortIdentifier.java:218)
> >        at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
> >        at org.smslib.CService.connect(CService.java:197)
> >        at SendMessage.main(SendMessage.java:38)
> >
> >_________________________________________________________________
> >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
> >
>
> Find love online with MSN Personals
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Tue Jun 20 02:35:24 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 10:35:24 +0200
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>

Hello everybody,

I have been fighting a bit with the javax.comm version of RXTX the  
last days. I am working on the README .OSX now and try to figure out  
which should be the "suggested" installation.

The facts:
------

- the "generic" comm.jar version of javax.comm which has been made re- 
available tries to load com.sun.comm.SolarisDriver
- this classname can be overridden ONLY by putting a file  
javax.comm.properties in {java.home}/lib
- if it is not overridden and SolarisDriver.class is not found  
CommPortIdentifier will be disfunctional (in particual it is not  
possible to add CommPort's via CommPortIdentifier.add).
- the license distributed with comm.jar does not allow the  
modification/addition of classes in javax.comm (however no mention of  
com.sun...)


What really bothers me is to suggest putting this config file in the  
"global" vm installation. This is particularly ugly on the Mac as  
there are several VM installations and the file may be forgotten.  
Additionally it may create versioning problems. I prefer an  
installation where all files are local to the application (even  
comm.jar).

In my opinion the ideal situation would be:
------

1) The author of a program compiles against javax.comm.
2a) For platforms supported by Sun the user is free to use the 3.0  
comm.jar download from Sun
2b) For platforms not supported by Sun the user adds RXTXComm.jar to  
the classpath of the application (and librxtxSerial.jnilib to the  
application directory). Also he will need the 2.0.3 generic comm.jar  
from Sun.
3) Nobody messes with the global VM installation.

Of course 2a) and 2b) could be handled by the author of the program  
via an appropriate installer. The author could also decide to always  
use RXTX and include the generic javax.comm classes as well as the  
RXTX classes in his application jar. [If he further uses an explicit  
call to System.load() he may even include the jnilib(s) in the jar,  
extract it (based on the platform name) at runtime to a temp file and  
load it from there.]


Suggested solution:
------

We only need to put the following class in the classpath BEFORE Suns  
comm.jar

   package com.sun.comm;
   public class SolarisDriver extends gnu.io.RXTXCommDriver {
   }

This is not "the pure art" (TM). It depends on an implementation  
detail of the generic driver. However, so does the  
javax.comm.properties file - as we have seen when Sun released 3.0.  
It has the following advantages:

- The "generic" javax.comm implementation will happily load this  
class as its primary driver.
- No javax.comm.properties file is required.
- This does not violate the javax.comm license agreement as there is  
no mention of the "com.sun.comm" package in this license agreement at  
all.
- Authors packaging comm.jar with their application can strip out all  
com.sun.comm classes from comm.jar


Please comment!

Joachim



From joachim at buechse.de  Tue Jun 20 02:50:36 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 10:50:36 +0200
Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar
Message-ID: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>

There has been some discussions about the best way to install RXTX  
and where to place files.

I suggest that,

- we include the native libraries for the most common operating  
systems (in a special version of) RXTXcomm.jar
- we add loader code which tries to extract and load the platform  
specific binary at runtime
- on failure the current mechanism remains as a fallback

Wether the current mechanism should have priority (ie loadLibrary  
before load) remains to be discussed.


The advantages of this solution are
  - users of RXTX do not need to worry about java/platform specific  
file placement.
  - authors of applications may fully merge RXTX into their  
application jar (which provides a double-clickable application for  
Windows and OSX, Linux?).

Please comment,
Joachim

PS: Of course the suggested solution is already possible today,  
however relatively few programmers know how to correctly extract a  
binary resource file via the class loader and load it as a native  
library.


From tjarvi at qbang.org  Tue Jun 20 03:58:12 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT)
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
Message-ID: <Pine.LNX.4.61.0606200335190.14139@www>

> 2a) For platforms supported by Sun the user is free to use the 3.0
> comm.jar download from Sun
> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to
> the classpath of the application (and librxtxSerial.jnilib to the
> application directory). Also he will need the 2.0.3 generic comm.jar
> from Sun.

As there are no plans to support CommAPI 3.0 due to the limitations in its 
implementation mentioned before, I would not recommend projects use Sun's 
3.0 comm.jar.  They will lose the freedom to chose their low level 
implementation by being locked into vendor specific modifications.

Projects should chose between platform neutrality in CommAPI 2.0 and 
reduced platform neutrality in commapi 3.0.  Projects should also strongly 
consider the fact that the 2.0 comm.jar targets only a reduced number of 
JVMs.

Projects can go with rxtx 2.1 or other packages but should probably only 
consider using Sun CommAPI with rxtx if they did so in the past.  They 
should take steps to no longer depend upon this option being available.

> Suggested solution:
> ------
>
> We only need to put the following class in the classpath BEFORE Suns
> comm.jar
>
>   package com.sun.comm;
>   public class SolarisDriver extends gnu.io.RXTXCommDriver {
>   }
>
> This is not "the pure art" (TM). It depends on an implementation
> detail of the generic driver. However, so does the
> javax.comm.properties file - as we have seen when Sun released 3.0.
> It has the following advantages:
>
> - The "generic" javax.comm implementation will happily load this
> class as its primary driver.
> - No javax.comm.properties file is required.
> - This does not violate the javax.comm license agreement as there is
> no mention of the "com.sun.comm" package in this license agreement at
> all.
> - Authors packaging comm.jar with their application can strip out all
> com.sun.comm classes from comm.jar
>

I would not encourage people to place packages in the com.sun.comm 
namespace.  Authors using Sun's commapi 2.0 should just realize it is 
greatly limited in practical utility and consider moving to something that 
isn't being rescued from EOL.

The primary focus of this release is projects previously depending upon 
Sun CommAPI + RXTX.  There are no plans at this time to provide future 
support in this arrangement due to technical incompatabilities we have no 
control over in commapi 3.0 and limited utility of Sun's generic comm.jar 
in commapi 2.0 offered.  Projects should be aware of this so they can make 
appropriate plans.

--
Trent Jarvi
tjarvi at qbang.org


From paul.klissner at sun.com  Tue Jun 20 05:24:00 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Tue, 20 Jun 2006 04:24:00 -0700
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
In-Reply-To: <Pine.LNX.4.61.0606200335190.14139@www>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
	<Pine.LNX.4.61.0606200335190.14139@www>
Message-ID: <4497DAD0.10803@sun.com>

Trent Jarvi wrote:
>> 2a) For platforms supported by Sun the user is free to use the 3.0
>> comm.jar download from Sun
>> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to
>> the classpath of the application (and librxtxSerial.jnilib to the
>> application directory). Also he will need the 2.0.3 generic comm.jar
>> from Sun.
> 
> As there are no plans to support CommAPI 3.0 due to the limitations in its 
> implementation mentioned before, I would not recommend projects use Sun's 
> 3.0 comm.jar.  They will lose the freedom to chose their low level 
> implementation by being locked into vendor specific modifications.
> 
> Projects should chose between platform neutrality in CommAPI 2.0 and 
> reduced platform neutrality in commapi 3.0.  Projects should also strongly 
> consider the fact that the 2.0 comm.jar targets only a reduced number of 
> JVMs.

Well, that's a little ambiguous because the API is the same
either way.  We're talking about Sun's implementation vs.
other implementations.
> 
> Projects can go with rxtx 2.1 or other packages but should probably only 
> consider using Sun CommAPI with rxtx if they did so in the past.  They 
> should take steps to no longer depend upon this option being available.

3.0 is platform centric because there is a need to add some
platform awareness to Sun's implementation, and the choices
for how to do that are limited by the constraints of the API,
as mentioned in the javax.comm 2.0.3 comm.jar download's README.

I am really advocating getting a JSR open (http://www.jcp.org)
to push a new comm API that is more pluggable, platform neutral
and addresses some of the deficiencies of the current API. Then
we can achieve the optimal of platform neutrality while
simulataneously allowing the API to flexibly adapt to
heterogeneous environments.

This is not a question of attitude, this is an issue of resources,
time and commitment.  The current owners of javax.comm within
Sun would like nothing better than to see the ideal reached for
the API and a model that will extend well beyond the foreseeable
future and work for the industry overall.



> 
>> Suggested solution:
>> ------
>>
>> We only need to put the following class in the classpath BEFORE Suns
>> comm.jar
>>
>>   package com.sun.comm;
>>   public class SolarisDriver extends gnu.io.RXTXCommDriver {
>>   }
>>
>> This is not "the pure art" (TM). It depends on an implementation
>> detail of the generic driver. However, so does the
>> javax.comm.properties file - as we have seen when Sun released 3.0.
>> It has the following advantages:
>>
>> - The "generic" javax.comm implementation will happily load this
>> class as its primary driver.
>> - No javax.comm.properties file is required.
>> - This does not violate the javax.comm license agreement as there is
>> no mention of the "com.sun.comm" package in this license agreement at
>> all.
>> - Authors packaging comm.jar with their application can strip out all
>> com.sun.comm classes from comm.jar
>>
> 
> I would not encourage people to place packages in the com.sun.comm 
> namespace.  Authors using Sun's commapi 2.0 should just realize it is 
> greatly limited in practical utility and consider moving to something that 
> isn't being rescued from EOL.
> 
> The primary focus of this release is projects previously depending upon 
> Sun CommAPI + RXTX.  There are no plans at this time to provide future 
> support in this arrangement due to technical incompatabilities we have no 
> control over in commapi 3.0 and limited utility of Sun's generic comm.jar 
> in commapi 2.0 offered.  Projects should be aware of this so they can make 
> appropriate plans.

Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86,
or need the powerful portmapping features in javax.com 3.0, or would like to
acquire the Interactive Serial Port Test utility.

-Paul


From paul.klissner at sun.com  Tue Jun 20 05:33:44 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Tue, 20 Jun 2006 04:33:44 -0700
Subject: [Rxtx] Suggested installation RXTX 2.0x...
In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
Message-ID: <4497DD18.70207@sun.com>

Joachim Buechse wrote:
> Hello everybody,
> 
> I have been fighting a bit with the javax.comm version of RXTX the  
> last days. I am working on the README .OSX now and try to figure out  
> which should be the "suggested" installation.
> 
> The facts:
> ------
> 
> - the "generic" comm.jar version of javax.comm which has been made re- 
> available tries to load com.sun.comm.SolarisDriver
> - this classname can be overridden ONLY by putting a file  
> javax.comm.properties in {java.home}/lib
> - if it is not overridden and SolarisDriver.class is not found  
> CommPortIdentifier will be disfunctional (in particual it is not  
> possible to add CommPort's via CommPortIdentifier.add).
> - the license distributed with comm.jar does not allow the  
> modification/addition of classes in javax.comm (however no mention of  
> com.sun...)
> 
> 
> What really bothers me is to suggest putting this config file in the  
> "global" vm installation. This is particularly ugly on the Mac as  
> there are several VM installations and the file may be forgotten.  
> Additionally it may create versioning problems. I prefer an  
> installation where all files are local to the application (even  
> comm.jar).
> 
> In my opinion the ideal situation would be:
> ------
> 
> 1) The author of a program compiles against javax.comm.
> 2a) For platforms supported by Sun the user is free to use the 3.0  
> comm.jar download from Sun
> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to  
> the classpath of the application (and librxtxSerial.jnilib to the  
> application directory). Also he will need the 2.0.3 generic comm.jar  
> from Sun.
> 3) Nobody messes with the global VM installation.
> 
> Of course 2a) and 2b) could be handled by the author of the program  
> via an appropriate installer. The author could also decide to always  
> use RXTX and include the generic javax.comm classes as well as the  
> RXTX classes in his application jar. [If he further uses an explicit  
> call to System.load() he may even include the jnilib(s) in the jar,  
> extract it (based on the platform name) at runtime to a temp file and  
> load it from there.]
> 

This was how the Sun implementation originated (I did not write
that code).  I completely agree, and I fixed the whole conf file
locating mechanism in 3.0 to avoid the problems youmentioned.
However, I was unaware of how RxTx was using Sun's implementation,
so I didn't architect it in such a way as to avoid namespace pollution
in the native space in for the backend provider.  In retrospect,
I should have done that differently just as a design principle,
but at this point I don't have the spare cycles to get that all
re-factored.  Further, I'm loathe to do it, because the whole
thing will still be an under-the-hood hack due to the constraints
of the API itself.

Paul





From brian at mbari.org  Tue Jun 20 10:23:54 2006
From: brian at mbari.org (Brian Schlining)
Date: Tue, 20 Jun 2006 09:23:54 -0700
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>


Hi Joachim,

> There has been some discussions about the best way to install RXTX
> and where to place files.
>
> I suggest that,
>
> - we include the native libraries for the most common operating
> systems (in a special version of) RXTXcomm.jar
> - we add loader code which tries to extract and load the platform
> specific binary at runtime
> - on failure the current mechanism remains as a fallback

I like your suggestion. However, my understanding is that in general  
the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH  
(Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to  
be loaded by the JVM. The alternative is to point to your native lib  
directory using -Djava.library.path=/my/dir/with/native/libs when you  
launch the JVM. So, I'm very interested to know how you're planning  
to work around this.

> PS: Of course the suggested solution is already possible today,
> however relatively few programmers know how to correctly extract a
> binary resource file via the class loader and load it as a native
> library.

So how do you use it to dynamically load a native lib? I've read that  
you can't really modify the java.library.path after the JVM has been  
launched. (http://forum.java.sun.com/thread.jspa? 
threadID=627890&tstart=90)

Thanks

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0012.html

From joachim at buechse.de  Tue Jun 20 09:20:29 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 17:20:29 +0200
Subject: [Rxtx] 2.0x in sync with 2.1x
Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>

I have added most of the changes from the 2.1 branch to the 2.0 branch.

This includes
  - correction of illegal javadoc comments
  - implementation errors in handling of Thread.interrupt in  
RXTXPort.java
  - MacOS X locking without lock files/special user groups
  - XCode project which builds a universal binary library
  - updated documentation for OSX

I have done some minimal testing (only G4).
[Trent: there are still some changes you made for specific baud  
rates. I will not sync this, as I can not test them. From my  
perspective we are ready for 2.08/2.18]

The updated documentation can be found in the file README.OSX. Here  
it is:

------------------------ Required files -----------------------

To use or compile RXTX 2.0.x you need to downlad the "generic"  
version (2.0.3)
of the javax.comm implementation from Sun. The zip you download  
contains an
archive comm.jar which is required:

- To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar

- To run the app you will need comm.jar in the classpath or in  
{java.lib.path}


------------------------ Installation on MacOSX -----------------------

WARNING: Please read this section until the end.

---
Preparation
---

You may want to spare your users the burden of modifying the global VM
installation. OSX has several different VM versions installed by  
default and
regular users will be unable to figure out which version will load your
application.

If you provide the class

package com.sun.comm;
public class SolarisDriver extends gnu.io.RXTXCommDriver {
}

and make sure, that it is present in the classpath before Suns  
"generic" comm.jar
your users can skip the following step:

Create a file named
    javax.comm.properties
in the directory
    /System/Library/Frameworks/JavaVM.framework/Home/lib/
which contains (only) the following line (no leading space):
    Driver=gnu.io.RXTXCommDriver



----
The unsafe way of using RXTX on OS X:
----

RXTX can be installed by putting the files
   libSerial.jnilib
   RXTXcomm.jar
   comm.jar
into the folder
   /Library/Java/Extensions

This is NOT RECOMMENDED as it creates versioning conflicts among  
applications.
However you may be forced to install it this way if an application  
was written
for Windows or Linux, requires RXTX and you are not able to change  
its starter.


----
The safe way of using RXTX on OS X:
----

Make sure that you have no (older) version of RXTX installed in
   /Library/Java/Extensions
   /System/Library/Java/Extensions
   /usr/lib/java

Put
   libSerial.jnilib
in the directory of the application (the JavaVM will find it there). Add
   RXTXComm.jar
   comm.jar
to the application classpath or include the classes in the  
application jar.
(Some applications already include the RXTX classes in their  
application jar,
in which case only the file libSerial.jnilib is required).


----
History
----

Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation  
of lockfiles
required special permissions for the user executing an application  
based on RXTX.
To simplify the setup RXTX came with an installer modifying group  
permissions
and installing RXTX in the global location /Library/Java/Extensions.  
However
this was prune to versioning conflicts and is no longer recommended.

--------------------- Build instructions for OSX XCode  
-------------------

contributed by Joachim Buechse <joachim at buechse.de>
original version by Dmitry Markman <dmarkman at mac.com>

System requirements for building:
MacOSX 10.4
XCode 2.3

   open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj
   choose libSerial.jnilib target
   build

After the build you will find RXTXcomm.jar and libSerial.jnilib files  
in the
directory build/Development.

In case you can't find RXTXcomm.jar build the RXTXcomm target manually.
In case of (serious) problems feel free to contact joachim at buechse.de .



From tjarvi at qbang.org  Tue Jun 20 22:01:45 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT)
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
Message-ID: <Pine.LNX.4.61.0606202127270.14139@www>

> ---
> Preparation
> ---
>
> You may want to spare your users the burden of modifying the global VM
> installation. OSX has several different VM versions installed by
> default and
> regular users will be unable to figure out which version will load your
> application.
>
> If you provide the class
>
> package com.sun.comm;
> public class SolarisDriver extends gnu.io.RXTXCommDriver {
> }
>
> and make sure, that it is present in the classpath before Suns
> "generic" comm.jar
> your users can skip the following step:

Hi Joachim

With regards to the above, I have not seen that we have Sun's OK to 
promote that.  I'm not very comfortable with the distribution 
documentation advocating this without Sun agreeing.

I see your point but I'd rather not actively promote putting classes in 
Sun's namespace without permission if you don't mind.  This isn't about 
what is in a license.

I'll go through the code tomorrow night.  It was a late night at work 
today.  There is also a w32 fix comming for people opening and closing 
multiple ports.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Wed Jun 21 01:56:45 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 21 Jun 2006 09:56:45 +0200
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <Pine.LNX.4.61.0606202127270.14139@www>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
	<Pine.LNX.4.61.0606202127270.14139@www>
Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>

Hello Trent,

I guess we will not get an explicit OK from Sun for such a hack. I  
think Paul has made it pretty clear, that he does not have the  
resources to modify the 2.x or 3.x code for the needs of RXTX. I'm  
not thrilled but OK with the current API. Hence I dont agree with  
Paul's idea to start a new JSR to fix the implementation - but that's  
mainly because I dont have the time to push it. According to their  
Readme Sun sees no business case in having cross platform support for  
javax.comm - that is sad but it's none of my business. However I  
prefer to program versus javax.comm in my projects as this gives an  
advanced user the chance to exchange the provider without access to  
the code.

I interpret Pauls reponse to my original "Request for comment" as a  
quiet acceptance of the hack I propose (he did respond, but not at  
all to the sun.comm namespace suggestion). This is certainly not  
something we should put into RXTXcomm.jar but hinting a work around  
for implementation errors should be allowed. That's why I've choosen  
the wording "You may want to spare" and "If you provide". The company  
I worked for has choosen similar hacks for years to fix bugs in swing  
for JDK1.1 applications. Those hacks were usually included in their  
own swingpatch.jar.

Having said all that - I do not take it as an insult if you remove  
the paragraph from the Readme. I appreciate that you notified me  
before. It would be interesting to hear some more opinions from the  
list members...

Best regards,
Joachim


On 21.06.2006, at 06:01, Trent Jarvi wrote:

>> ---
>> Preparation
>> ---
>>
>> You may want to spare your users the burden of modifying the  
>> global VM
>> installation. OSX has several different VM versions installed by
>> default and
>> regular users will be unable to figure out which version will load  
>> your
>> application.
>>
>> If you provide the class
>>
>> package com.sun.comm;
>> public class SolarisDriver extends gnu.io.RXTXCommDriver {
>> }
>>
>> and make sure, that it is present in the classpath before Suns
>> "generic" comm.jar
>> your users can skip the following step:
>
> Hi Joachim
>
> With regards to the above, I have not seen that we have Sun's OK to
> promote that.  I'm not very comfortable with the distribution
> documentation advocating this without Sun agreeing.
>
> I see your point but I'd rather not actively promote putting  
> classes in
> Sun's namespace without permission if you don't mind.  This isn't  
> about
> what is in a license.
>
> I'll go through the code tomorrow night.  It was a late night at work
> today.  There is also a w32 fix comming for people opening and closing
> multiple ports.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Wed Jun 21 02:03:33 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 21 Jun 2006 10:03:33 +0200
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
	<6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
Message-ID: <BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>

See System.load(String) [it's also mentioned under the URL you posted].

Regards,
Joachim


On 20.06.2006, at 18:23, Brian Schlining wrote:

> So how do you use it to dynamically load a native lib? I've read  
> that you can't really modify the java.library.path after the JVM  
> has been launched. (http://forum.java.sun.com/thread.jspa? 
> threadID=627890&tstart=90)
>
> Thanks
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From baris.ozkan at elikasu.com.tr  Wed Jun 21 07:58:06 2006
From: baris.ozkan at elikasu.com.tr (Baris)
Date: Wed, 21 Jun 2006 16:58:06 +0300
Subject: [Rxtx] RS 232 ..additional parameters
Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>

Hi,
 
Currently i am developing an application that requires to connect to a
remote rs232 device through  a dialup connection.
 
My problem is that the communication needs several more connection
parameters (i extracted that information from the vendor's dll , listed at
the end of the message)
 
I explored rxtx API and src files and could not find methods to set a
majority  of the parameters.
Am i missing any point or does rxtx is limited to soem standard set of
functionality(e.g. commAPI)? How  is it possible ,if i want to put some
extensions(???) to current rxtx implementation?
 
I am not very good at rs232 programming so excuse me if this message  is
boring one.
 
Thanx
 
Baris Ozkan
 
 
A Listing of Parameters:
 
 
typedef struct _DCB {

DWORD DCBlength; /* sizeof(DCB) */

DWORD BaudRate; /* Baudrate at which running */

DWORD fBinary: 1; /* Binary Mode (skip EOF check) */

DWORD fParity: 1; /* Enable parity checking */

DWORD fOutxCtsFlow:1; /* CTS handshaking on output */

DWORD fOutxDsrFlow:1; /* DSR handshaking on output */

DWORD fDtrControl:2; /* DTR Flow control */

DWORD fDsrSensitivity:1; /* DSR Sensitivity */

DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */

DWORD fOutX: 1; /* Enable output X-ON/X-OFF */

DWORD fInX: 1; /* Enable input X-ON/X-OFF */

DWORD fErrorChar: 1; /* Enable Err Replacement */

DWORD fNull: 1; /* Enable Null stripping */

DWORD fRtsControl:2; /* Rts Flow control */

DWORD fAbortOnError:1; /* Abort all reads and writes on Error */

DWORD fDummy2:17; /* Reserved */

WORD wReserved; /* Not currently used */

WORD XonLim; /* Transmit X-ON threshold */

WORD XoffLim; /* Transmit X-OFF threshold */

BYTE ByteSize; /* Number of bits/byte, 4-8 */

BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */

BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */

char XonChar; /* Tx and Rx X-ON character */

char XoffChar; /* Tx and Rx X-OFF character */

char ErrorChar; /* Error replacement char */

char EofChar; /* End of Input character */

char EvtChar; /* Received Event character */

WORD wReserved1; /* Fill for now. */

} DCB, *LPDCB;

typedef struct _COMMTIMEOUTS {

DWORD ReadIntervalTimeout; /* Maximum time between read chars. */

DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */

DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */

DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */

DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */

} COMMTIMEOUTS,*LPCOMMTIMEOUTS;

dcb.fOutX = FALSE;

dcb.fInX = FALSE;

dcb.fOutxCtsFlow = FALSE;

dcb.fBinary = TRUE;

dcb.fRtsControl = RTS_CONTROL_ENABLE;

SetCommState(hComm , &dcb ); 

COMMTIMEOUTS commTimeOut;

GetCommTimeouts(hComm, &commTimeOut );

commTimeOut.WriteTotalTimeoutMultiplier = 1; 

commTimeOut.WriteTotalTimeoutConstant = 18; 

// commTimeOut.ReadIntervalTimeout = 28; 

commTimeOut.ReadIntervalTimeout = 0; 

// commTimeOut.ReadTotalTimeoutMultiplier = 184; 

commTimeOut.ReadTotalTimeoutMultiplier = 300; 

// commTimeOut.ReadTotalTimeoutConstant = 1200;

commTimeOut.ReadTotalTimeoutConstant = 1200;

SetCommTimeouts(hComm, &commTimeOut);

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0012.html

From ajmas at sympatico.ca  Wed Jun 21 08:14:26 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Wed, 21 Jun 2006 10:14:26 -0400
Subject: [Rxtx] When is 2.18 planned for?
Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

Just curious as to know if there is a target date for 2.18?

Andre



From brian at mbari.org  Wed Jun 21 09:36:00 2006
From: brian at mbari.org (Brian Schlining)
Date: Wed, 21 Jun 2006 08:36:00 -0700
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
	<6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
	<BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>
Message-ID: <A21C9BC0-7894-4B08-AC82-44E11AB3D461@mbari.org>

Ha!!

I suppose I should read my own postings. ;-)

Thanks
B

On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote:

> See System.load(String) [it's also mentioned under the URL you  
> posted].
>
> Regards,
> Joachim
>
>
> On 20.06.2006, at 18:23, Brian Schlining wrote:
>
>> So how do you use it to dynamically load a native lib? I've read
>> that you can't really modify the java.library.path after the JVM
>> has been launched. (http://forum.java.sun.com/thread.jspa?
>> threadID=627890&tstart=90)

Brian Schlining
Software Engineer
http://www.mbari.org




From ajmas at sympatico.ca  Wed Jun 21 16:41:28 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Wed, 21 Jun 2006 18:41:28 -0400
Subject: [Rxtx] CVS build question
Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X:

 The JCL extension to RxTx requires comm.jar
 If you intend to use RxTx for commapi support comm.jar
 needs to be located in  /System/Library/Frameworks/JavaVM.framework/
  Versions/1.5/Home/lib/ext/comm.jar

I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me.

On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native).

Andre






From tjarvi at qbang.org  Wed Jun 21 18:00:04 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT)
Subject: [Rxtx] CVS build question
In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606211756310.14139@www>

On Wed, 21 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> Is the CVS repository meant to build for gnu.io or javax.comm? I ask 
> this, because I see the following when calling ./configure from MacOS X:
>
> The JCL extension to RxTx requires comm.jar
> If you intend to use RxTx for commapi support comm.jar
> needs to be located in  /System/Library/Frameworks/JavaVM.framework/
>  Versions/1.5/Home/lib/ext/comm.jar
>
> I am wanting to build for the gnu.io package, since I want to jump ahead 
> and see if the changes, intended for 2.18 for MacOS X, work for me.
>
> On a side note /Library/Java/Extensions should be included as a valid 
> search path for the JAR, since this is where Apple recommends placing 
> third party extensions (both Java and native).
>

rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel"
rxtx 2.0 src is obtained with "cvs checkout rxtx-devel"

rxtx 2.1 is a complete package in namespace gnu.io
rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 18:02:23 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT)
Subject: [Rxtx] When is 2.18 planned for?
In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606211800180.14139@www>

On Wed, 21 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> Just curious as to know if there is a target date for 2.18?
>

Hi Andre

"When it is ready" :)

Probably this weekend.  Maybe sooner.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 18:10:18 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT)
Subject: [Rxtx] RS 232 ..additional parameters
In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>
References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>
Message-ID: <Pine.LNX.4.61.0606211805010.14139@www>

On Wed, 21 Jun 2006, Baris wrote:

> Hi,
>
> Currently i am developing an application that requires to connect to a
> remote rs232 device through  a dialup connection.
>
> My problem is that the communication needs several more connection
> parameters (i extracted that information from the vendor's dll , listed at
> the end of the message)
>
> I explored rxtx API and src files and could not find methods to set a
> majority  of the parameters.
> Am i missing any point or does rxtx is limited to soem standard set of
> functionality(e.g. commAPI)? How  is it possible ,if i want to put some
> extensions(???) to current rxtx implementation?
>
> I am not very good at rs232 programming so excuse me if this message  is
> boring one.
>
> Thanx
>

Hi Baris

> typedef struct _DCB {
> typedef struct _COMMTIMEOUTS {

These are all handled in termios.c.  It is possible to add extensions to 
rxtx 2.1.  It may well be that the defaults are the same for the variables 
not covered by the existing API.  You can dump the DCB and COMMTIMEOUTS 
from inside termios.c to compare.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 20:23:30 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT)
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
	<Pine.LNX.4.61.0606202127270.14139@www>
	<789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>
Message-ID: <Pine.LNX.4.61.0606212012210.14139@www>

> I'm
> not thrilled but OK with the current API. Hence I dont agree with
> Paul's idea to start a new JSR to fix the implementation - but that's
> mainly because I dont have the time to push it. According to their
> Readme Sun sees no business case in having cross platform support for
> javax.comm - that is sad but it's none of my business. However I
> prefer to program versus javax.comm in my projects as this gives an
> advanced user the chance to exchange the provider without access to
> the code.

Hi Joachim

With regards to the JSR, I think that would be Doug's call.  The effort I 
put in would have to be on my own time which would not be a great deal.  I 
could help things go smoothly but thats not the same as pushing something 
through.

--
Trent Jarvi
tjarvi at qbang.org



From vt at freehold.crocodile.org  Wed Jun 21 21:05:22 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Wed, 21 Jun 2006 20:05:22 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
Message-ID: <449A08F2.3020106@freehold.crocodile.org>

Hello all,

I know this question may belong to JSR lists, but since all interested 
parties are here, I thought I just ask this question here, again...

A while ago I run into a problem and wrote a rant, here: 
http://servomaster.sourceforge.net/dev/serial-usb.html
At the time of writing I didn't think of adding another possible 
solution - changing the CommAPI specs to support removable devices. 
Apparently, Serial/USB bridges are here to stay, and this issue has to 
be addressed.

Wonder if anything changed since, and any abstractions for supporting 
removable devices made it into current or future Java CommAPI drafts - 
Paul, any comments?

--vt



From joachim at buechse.de  Thu Jun 22 01:59:54 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 22 Jun 2006 09:59:54 +0200
Subject: [Rxtx] CVS build question
In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de>

Hello Andre,

I am not sure how well the configure/make mechanism will work on OSX.  
I know that a while ago some contributors tried to get configure/make  
working on OSX but from comments I found in the readmes this work was  
only partially successfull. For compilation on OSX we have used the  
ProjectBuilder/XCode projects you can find in MACOSX_IDE.

Regarding the  ./configure comment:
RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config  
file javax.comm.properties. The later MUST reside in {java.home}/lib.  
As the two only work together putting comm.jar into  /Library/Java/ 
Extensions  and hence making it available to all current and future  
VM installations will only add to confusion.

Regards,
Joachim

On 22.06.2006, at 00:41, Andre-John Mas wrote:

> Hi,
>
> Is the CVS repository meant to build for gnu.io or javax.comm? I  
> ask this, because I see the following when calling ./configure from  
> MacOS X:
>
>  The JCL extension to RxTx requires comm.jar
>  If you intend to use RxTx for commapi support comm.jar
>  needs to be located in  /System/Library/Frameworks/JavaVM.framework/
>   Versions/1.5/Home/lib/ext/comm.jar
>
> I am wanting to build for the gnu.io package, since I want to jump  
> ahead and see if the changes, intended for 2.18 for MacOS X, work  
> for me.
>
> On a side note /Library/Java/Extensions should be included as a  
> valid search path for the JAR, since this is where Apple recommends  
> placing third party extensions (both Java and native).
>
> Andre
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Thu Jun 22 02:51:05 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 22 Jun 2006 10:51:05 +0200
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449A08F2.3020106@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>

Hello Vadim,

I think that your rant is to the point. However it is a bit like  
saying that Windows is at the source of email degradation and the  
only solution is to have users switch to safer operating systems.

I don't see how javax.comm or RXTX can address the problems you  
mention. Of course it would be super cool if javax.comm could magicly  
find the "matching" usb-device and query it's configuration via the  
usb protocol - however this magic (mapping /dev/xyz to its underlying  
USB device) is not supported by any kernel APIs I am aware of. It  
could be supported via POSSIX ioctl calls but then you should address  
your rant to the POSSIX group...

So for the time beeing it's either up to the virtual comm port driver  
to provide a usefull name under /dev/ or to the user choosing the  
right port to use. One example of a smart(er) com port driver is the  
KDDI driver for OSX, which will create device names like "/dev/ 
cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- 
encoded into the bridge chip. The same driver for windows also has  
some options allowing it in theory to recreate the same COMx every  
time a device is plugged/unplugged.

For most industrial applications however it will be up to the user to  
choose the right port (without getting a lot of help doing so).

Probing serial ports can go wrong, that's right. However any serial  
device developper would be well adviced to implement a basic set of  
Hayes AT modem commands (be it a modem or not). Especially AT I0.  
Anyone failing to do so risks that the users favourite TCP/PPP/FAX  
application or stack will kill the device in short time.

Best regards,
Joachim


On 22.06.2006, at 05:05, Vadim Tkachenko wrote:

> Hello all,
>
> I know this question may belong to JSR lists, but since all interested
> parties are here, I thought I just ask this question here, again...
>
> A while ago I run into a problem and wrote a rant, here:
> http://servomaster.sourceforge.net/dev/serial-usb.html
> At the time of writing I didn't think of adding another possible
> solution - changing the CommAPI specs to support removable devices.
> Apparently, Serial/USB bridges are here to stay, and this issue has to
> be addressed.
>
> Wonder if anything changed since, and any abstractions for supporting
> removable devices made it into current or future Java CommAPI drafts -
> Paul, any comments?
>
> --vt
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From vt at freehold.crocodile.org  Thu Jun 22 13:16:03 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 12:16:03 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
Message-ID: <20060622191603.GA17487@freehold.crocodile.org>

Hello Joachim,

> I think that your rant is to the point. However it is a bit like  
> saying that Windows is at the source of email degradation and the  
> only solution is to have users switch to safer operating systems.

I guess the problem is that the rant itself is obsolete and has to be
updated according to latest developments. At the time of writing there
weren't that many bridges around, and the trend didn't manifest itself as it
does now.

> I don't see how javax.comm or RXTX can address the problems you  
> mention.

I would agree that javax.comm won't be able to address the problem, at least
in the short run. As for RxTx - well, nobody prevents it from being a
superset of CommAPI specification, right? RxTx being the de-facto standard
for quite a few platforms, I'd daresay the standard may follow.

> Of course it would be super cool if javax.comm could magicly find the
> "matching" usb-device and query it's configuration via the usb protocol -
> however this magic (mapping /dev/xyz to its underlying USB device) is not
> supported by any kernel APIs I am aware of. It could be supported via
> POSSIX ioctl calls but then you should address your rant to the POSSIX
> group...

As a matter of fact, my bigger concern is addressing the fact that a serial
device can now be removable. This hasn't been the case before, and it
clearly is now. Regarding the above, well, I guess if we accept this fact,
we also need to accept the fact that we need at least rudimentary means of
identification of a serial device. For the USB case, it would usually be the
vendor/product ID, plus possible serial number - but it is irrelevant what
exactly the identifying information is, as long as it allows to identify the
device.

A paradigm shift is required, this is what I wanted to say. Serial devices
can be removed and replaced, it's now our turn to learn to deal with it.

> Joachim

--vt


From jredman at ergotech.com  Thu Jun 22 13:41:44 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 13:41:44 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
Message-ID: <449AF278.6000903@ergotech.com>


Vadim Tkachenko wrote:
> A paradigm shift is required, this is what I wanted to say. Serial devices
> can be removed and replaced, it's now our turn to learn to deal with it.

The removal if the serial port hardly significantly different from the 
removal of the device attached to the serial port.   Different, 
slightly, but not a "paradigm shift".

And yes, someone could unplug a USB serial device and plug it into a 
different USB port so that it has a different name/number, but they 
could do that with the device itself, move it from com1 to com2.

Am I missing something?

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 13:57:27 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 12:57:27 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449AF278.6000903@ergotech.com>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
Message-ID: <20060622195727.GA20247@freehold.crocodile.org>

On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote:
> 
> Vadim Tkachenko wrote:
> > A paradigm shift is required, this is what I wanted to say. Serial devices
> > can be removed and replaced, it's now our turn to learn to deal with it.
> 
> The removal if the serial port hardly significantly different from the 
> removal of the device attached to the serial port.   Different, 
> slightly, but not a "paradigm shift".
> 
> And yes, someone could unplug a USB serial device and plug it into a 
> different USB port so that it has a different name/number, but they 
> could do that with the device itself, move it from com1 to com2.
> 
> Am I missing something?

Yes, the fact that they could unplug a device A and plug a device B. With
the introduction of the concept of removability, the notion of the serial
port itself is not as important anymore, but the notion of the unique device
identifier is.

Consider a situation: long running system (enterprise HVAC, tens of nodes,
tens of thousands square feet area, hundreds of thousand dollars worth of
equipment being conditioned, can't shut down), serial/usb device fails, is
replaced by an identical device with a different serial #.

A little bit farfetched, but hopefully highlighting the point I'm trying to
make.

> Jim

--vt


From jredman at ergotech.com  Thu Jun 22 14:37:38 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 14:37:38 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>	<20060622191603.GA17487@freehold.crocodile.org>	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
Message-ID: <449AFF92.8080003@ergotech.com>


Vadim Tkachenko wrote:
>>
>> Am I missing something?
> 
> Yes, the fact that they could unplug a device A and plug a device B. With
> the introduction of the concept of removability, the notion of the serial
> port itself is not as important anymore, but the notion of the unique device
> identifier is.

Serial devices are always removable.  I could unplug _serial_ device A 
and plug in _serial_ device B.  We have systems running with two RS485 
ports, one talks to a Modbus PLC network one to a number of drives on a 
proprietary protocol.  If you plug the wrong DB9 into the wrong port the 
application doesn't work.

If you dangle a USB 485 converter on the end of the DB9 you've just 
moved the problem from RS485 to USB, but the problem/effect is the same.

> 
> Consider a situation: long running system (enterprise HVAC, tens of nodes,
> tens of thousands square feet area, hundreds of thousand dollars worth of
> equipment being conditioned, can't shut down), serial/usb device fails, is
> replaced by an identical device with a different serial #.
> 
> A little bit farfetched, but hopefully highlighting the point I'm trying to
> make.

Nothing's changed.  If I had a 4 port ISA board and plugged it into my 
new shiny '386 machine.  I could have com ports 9-12.  If I took a board 
off the shelf and didn't set the jumpers, I would have com ports 3-6.

The problem's the same.  If you replace with identical product then the 
com ports  will be the same - no software changes required.  If you 
replace one piece of hardware with hardware from a different 
manufacturer, then the naming/numbering may change.  You're physically 
changing the system, so may reasonably expect to have to make a software 
change.  RXTX actually handles this situation quite well with the -D 
command line option.  (My experience has generally been that the port 
number depends more on the USB port used than the hardware - so the 
chances are even with a hardware change the port number/name will be the 
same.)

Slightly Off Topic - there is a reason why industrial users will pay a 
premium for continued availability of hardware.  Yes you can mail-order 
a $10 USB converter and it will work, but there's no guarantee that the 
next time you buy the same part number from the same vendor it will be 
the same.  The industrial vendors will charge you $100+ for the same 
item, but it will be the same every time you buy it for the next 5 to 10 
years.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 14:37:19 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 13:37:19 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
Message-ID: <20060622203719.GA22521@freehold.crocodile.org>

Hello again,

And while I'm at it, why don't just say this: give me one good reason to
write 3+ different ways of handling removable devices, one for USB, one for
FireWire, one for serial...

I understand very well that this goes way beyond the scope of RxTx and
CommAPI and will require cooperation between them and javax.usb and whatever
JSR is responsible for FireWire implementation - but the end result is well
worth it. Abstract out and generalize arrival/departure/monitoring/discovery
API, provide protocol specific extensions for each, live happily ever after.

--vt


On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote:
> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote:
> > 
> > Vadim Tkachenko wrote:
> > > A paradigm shift is required, this is what I wanted to say. Serial devices
> > > can be removed and replaced, it's now our turn to learn to deal with it.
> > 
> > The removal if the serial port hardly significantly different from the 
> > removal of the device attached to the serial port.   Different, 
> > slightly, but not a "paradigm shift".
> > 
> > And yes, someone could unplug a USB serial device and plug it into a 
> > different USB port so that it has a different name/number, but they 
> > could do that with the device itself, move it from com1 to com2.
> > 
> > Am I missing something?
> 
> Yes, the fact that they could unplug a device A and plug a device B. With
> the introduction of the concept of removability, the notion of the serial
> port itself is not as important anymore, but the notion of the unique device
> identifier is.
> 
> Consider a situation: long running system (enterprise HVAC, tens of nodes,
> tens of thousands square feet area, hundreds of thousand dollars worth of
> equipment being conditioned, can't shut down), serial/usb device fails, is
> replaced by an identical device with a different serial #.
> 
> A little bit farfetched, but hopefully highlighting the point I'm trying to
> make.
> 
> > Jim
> 
> --vt
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx


From jredman at ergotech.com  Thu Jun 22 15:13:49 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 15:13:49 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>	<20060622191603.GA17487@freehold.crocodile.org>	<449AF278.6000903@ergotech.com>	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
Message-ID: <449B080D.9080208@ergotech.com>


Vadim Tkachenko wrote:
> Hello again,
> 
> And while I'm at it, why don't just say this: give me one good reason to
> write 3+ different ways of handling removable devices, one for USB, one for
> FireWire, one for serial...

You don't, they're all the same "I have lost communication with my 
serial device".

The only thing you could really do is improve error reporting by knowing 
the exact sub-system.  ("Device X which is/was attached to USB port Y is 
no longer functioning, please check the USB ports, the device, the 
cables and anything else you can think of that may be a cause of 
failure.")  That just requires an intelligent description of the port.

> I understand very well that this goes way beyond the scope of RxTx and
> CommAPI and will require cooperation between them and javax.usb and whatever
> JSR is responsible for FireWire implementation - but the end result is well
> worth it. Abstract out and generalize arrival/departure/monitoring/discovery
> API, provide protocol specific extensions for each, live happily ever after.

There's a huge list of pseudo-serial devices each with a different set 
of requirements, Bluetooth, RFC 2217, a host of proprietary systems, 
etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I 
have no clue how you'd implement them in a general/cross platform sense.

You haven't convinced me (and only me, others may see something that I 
don't, I'm not speaking for them) that this mechanism can be implemented 
in any practical sense.  That is, that the implementation could be wide 
enough to be consider generally available in RXTX regardless of the 
serial port implementation, platform, etc..  However, if you can come up 
with a general design and a reference implementation for one subsystem, 
I'd like to see it and might get on board.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 15:40:55 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 14:40:55 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449B080D.9080208@ergotech.com>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
Message-ID: <20060622214055.GA25497@freehold.crocodile.org>

On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote:
> 
> Vadim Tkachenko wrote:
> > Hello again,
> > 
> > And while I'm at it, why don't just say this: give me one good reason to
> > write 3+ different ways of handling removable devices, one for USB, one for
> > FireWire, one for serial...
> 
> You don't, they're all the same "I have lost communication with my 
> serial device".

"I have lost communication with my ${protocol} device".

> The only thing you could really do is improve error reporting by knowing 
> the exact sub-system.  ("Device X which is/was attached to USB port Y is 
> no longer functioning, please check the USB ports, the device, the 
> cables and anything else you can think of that may be a cause of 
> failure.")

"Device ${id} which is/was attached to ${protocol} port ${port} is no longer
functioning, please check the ${protocol} ports, the device, the
${protocol_media} and anything else you can think of that may be a cause of
failure".

>  That just requires an intelligent description of the port.

Agree absolutely.

> > I understand very well that this goes way beyond the scope of RxTx and
> > CommAPI and will require cooperation between them and javax.usb and whatever
> > JSR is responsible for FireWire implementation - but the end result is well
> > worth it. Abstract out and generalize arrival/departure/monitoring/discovery
> > API, provide protocol specific extensions for each, live happily ever after.
> 
> There's a huge list of pseudo-serial devices each with a different set 
> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, 
> etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I 
> have no clue how you'd implement them in a general/cross platform sense.

That's because some of the protocols were created decades ago when
autoconfiguration wasn't even conceived, much less practical. RS232/RS485
don't have a clue about identity discovery, and even capabilities discovery
beyond obvious 8N1 etc.

I agree that today all these protocols have generally incompatible
strategies for handling the situations I'm trying to address, but there's
nothing that says it's not an oversight. Besides, we're dealing with the
devices at a level of abstraction that allows some simplifications and
generalizations, at least part of the time - unless it's the protocol
specific features we're dealing with.

> You haven't convinced me (and only me, others may see something that I 
> don't, I'm not speaking for them) that this mechanism can be implemented 
> in any practical sense.  That is, that the implementation could be wide 
> enough to be consider generally available in RXTX regardless of the 
> serial port implementation, platform, etc..  However, if you can come up 
> with a general design and a reference implementation for one subsystem, 
> I'd like to see it and might get on board.

Actually, I wasn't even thinking about all this stuff when I wrote the first
message on the subject :) Now that you mention it - well, I'm not sure I can
chew the piece I just tried to bite in reasonable amount of time.

How do you eat an elephant? One bite at a time. If we could agree that a
small step in the specification is acceptable at this time, and express
further intentions, things may start happening.

To put it succinctly:

- Concept of a "port" should be augmented with a concept of a "device". A
device may be attached to a port in an implicit or explicit way.
- Implicitly connected device is exactly what the current scope of the
specification covers. No new functionality is offered.
- Explicitly connected device supports detachable device semantics, just as
other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a
few).
- The input and output streams are not properties of a port now, but
properties of the device attached to the port.
- A mechanism to allow listening for device arrivals and departures must be
made available.

That's it, off the top of my head.

I understand that this goes completely against current javax.comm specs, but
an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be
difficult to implement without disrupting javax.comm compatibility.

One concern is how to deal with the device identity - but there's no general
way of dealing with this at this time, devices may or may not offer identity
discovery.

> Jim

--vt


From joachim at buechse.de  Fri Jun 23 02:12:43 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 23 Jun 2006 10:12:43 +0200
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
Message-ID: <CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>

Hello++ Vadim,

I would like to repeat that your request is best addressed to the  
POSSIX standardization group - or maybe the BSD/Linux maintainers. If  
you convince the BSD or Linux guys to add this kind of functionality  
(they can as most of there VCP drivers are open source), there is a  
certain chance that other vendors will pick it up. I assure you that  
RXTX will happily provide this functionality once it's possible - I'm  
sure there is more than one maintainer that would love to add it.  
Having this concept penetrate the market may take some years though.

SHORT: The solution you would like to see could be added to the API  
but it can not be implemented (at least not on the platforms I know).  
There are currently no hooks in the kernel that allow you to discover  
"the device" or even the "means of connection" based on an existing  
"device file descriptor" ie COM-port or /dev/... entry. The name  
mapping of the device is handled by the virtual com port driver of  
the device. Unless you are suggesting RXTX should reimplement virtual  
com port drivers for all usb/serial bridges out there your request is  
understandable from a users viewpoint but simply not realizable. It's  
like asking that the Socket api should identify the computer behind  
an IP address (ie by its Ethernet address). While this COULD be  
implemented in TCP/IP, it IS not, and hence there is no point adding  
such a function to the Socket API.

The current trend for USB/Bluetooth/Irda/etc connected devices is  
going away from serial port abstraction towards RPC (ie the drivers  
provide a device specific or device class specific driver that  
provides an application level api to the device functions). The line  
level protocol is often not even published.

Best regards,
Joachim

On 22.06.2006, at 23:40, Vadim Tkachenko wrote:

> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote:
>>
>> Vadim Tkachenko wrote:
>>> Hello again,
>>>
>>> And while I'm at it, why don't just say this: give me one good  
>>> reason to
>>> write 3+ different ways of handling removable devices, one for  
>>> USB, one for
>>> FireWire, one for serial...
>>
>> You don't, they're all the same "I have lost communication with my
>> serial device".
>
> "I have lost communication with my ${protocol} device".
>
>> The only thing you could really do is improve error reporting by  
>> knowing
>> the exact sub-system.  ("Device X which is/was attached to USB  
>> port Y is
>> no longer functioning, please check the USB ports, the device, the
>> cables and anything else you can think of that may be a cause of
>> failure.")
>
> "Device ${id} which is/was attached to ${protocol} port ${port} is  
> no longer
> functioning, please check the ${protocol} ports, the device, the
> ${protocol_media} and anything else you can think of that may be a  
> cause of
> failure".
>
>>  That just requires an intelligent description of the port.
>
> Agree absolutely.
>
>>> I understand very well that this goes way beyond the scope of  
>>> RxTx and
>>> CommAPI and will require cooperation between them and javax.usb  
>>> and whatever
>>> JSR is responsible for FireWire implementation - but the end  
>>> result is well
>>> worth it. Abstract out and generalize arrival/departure/ 
>>> monitoring/discovery
>>> API, provide protocol specific extensions for each, live happily  
>>> ever after.
>>
>> There's a huge list of pseudo-serial devices each with a different  
>> set
>> of requirements, Bluetooth, RFC 2217, a host of proprietary systems,
>> etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I
>> have no clue how you'd implement them in a general/cross platform  
>> sense.
>
> That's because some of the protocols were created decades ago when
> autoconfiguration wasn't even conceived, much less practical. RS232/ 
> RS485
> don't have a clue about identity discovery, and even capabilities  
> discovery
> beyond obvious 8N1 etc.
>
> I agree that today all these protocols have generally incompatible
> strategies for handling the situations I'm trying to address, but  
> there's
> nothing that says it's not an oversight. Besides, we're dealing  
> with the
> devices at a level of abstraction that allows some simplifications and
> generalizations, at least part of the time - unless it's the protocol
> specific features we're dealing with.
>
>> You haven't convinced me (and only me, others may see something  
>> that I
>> don't, I'm not speaking for them) that this mechanism can be  
>> implemented
>> in any practical sense.  That is, that the implementation could be  
>> wide
>> enough to be consider generally available in RXTX regardless of the
>> serial port implementation, platform, etc..  However, if you can  
>> come up
>> with a general design and a reference implementation for one  
>> subsystem,
>> I'd like to see it and might get on board.
>
> Actually, I wasn't even thinking about all this stuff when I wrote  
> the first
> message on the subject :) Now that you mention it - well, I'm not  
> sure I can
> chew the piece I just tried to bite in reasonable amount of time.
>
> How do you eat an elephant? One bite at a time. If we could agree  
> that a
> small step in the specification is acceptable at this time, and  
> express
> further intentions, things may start happening.
>
> To put it succinctly:
>
> - Concept of a "port" should be augmented with a concept of a  
> "device". A
> device may be attached to a port in an implicit or explicit way.
> - Implicitly connected device is exactly what the current scope of the
> specification covers. No new functionality is offered.
> - Explicitly connected device supports detachable device semantics,  
> just as
> other protocols do (USB, FireWire, Wireless USB, Bluetooth, to  
> mention a
> few).
> - The input and output streams are not properties of a port now, but
> properties of the device attached to the port.
> - A mechanism to allow listening for device arrivals and departures  
> must be
> made available.
>
> That's it, off the top of my head.
>
> I understand that this goes completely against current javax.comm  
> specs, but
> an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern )  
> won't be
> difficult to implement without disrupting javax.comm compatibility.
>
> One concern is how to deal with the device identity - but there's  
> no general
> way of dealing with this at this time, devices may or may not offer  
> identity
> discovery.
>
>> Jim
>
> --vt
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From vt at freehold.crocodile.org  Fri Jun 23 11:28:29 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Fri, 23 Jun 2006 10:28:29 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
	<CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
Message-ID: <20060623172829.GA5335@freehold.crocodile.org>

Hello Joachim,

> I would like to repeat that your request is best addressed to the POSSIX
> standardization group - or maybe the BSD/Linux maintainers. If you
> convince the BSD or Linux guys to add this kind of functionality (they can
> as most of there VCP drivers are open source), there is a certain chance
> that other vendors will pick it up. I assure you that RXTX will happily
> provide this functionality once it's possible - I'm sure there is more
> than one maintainer that would love to add it.

I realize this thing is bigger than RxTx itself, and I'm afraid it's too
global not to cause people to laugh before they think about it :)

> Having this concept penetrate the market may take some years though.

Well, I'm sure it'll get there, the only question is - when.

> SHORT: The solution you would like to see could be added to the API but it
> can not be implemented (at least not on the platforms I know).

I guess I'm concerned about the abstraction more than I'm concerned about
the implementation at this point.
  
> There are currently no hooks in the kernel that allow you to discover  
> "the device" or even the "means of connection" based on an existing  
> "device file descriptor" ie COM-port or /dev/... entry.

Well, I'm not so sure you need to keep the literal mapping from /dev
namespace to your device namespace. As long as you can consistently offer a
virtual serial device on top of a virtual serial port, it may be irrelevant
whether you can map it into /dev. The mapping is going be schitzofrenic
anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the
representation...

> The name mapping of the device is handled by the virtual com port driver
> of the device. Unless you are suggesting RXTX should reimplement virtual
> com port drivers for all usb/serial bridges out there your request is
> understandable from a users viewpoint but simply not realizable.

It's not so much a request but rather an offer of participation. I run a few
projects actively using serial communications, as well as USB device
drivers, in different degrees of readiness (Servomaster, Haywire, DIY
Zoning) - and it would be a perfect playground.

You mentioned above that this task is about two things: a) abstraction b)
implementation. I could start the abstraction part of it without changing
the current CommAPI, on top of it, as an adapter. Even if the removable
device semantics are not implemented, but offered, this is already a step
forward.

> It's like asking that the Socket api should identify the computer behind
> an IP address (ie by its Ethernet address). While this COULD be
> implemented in TCP/IP, it IS not, and hence there is no point adding such
> a function to the Socket API.

Thank you for bringing up this example - I guess this is just about the same
thing that I'd like to see. Socket transparently provides you with the
input/output streams, at the same time offering protocol level specifics to
you.

> The current trend for USB/Bluetooth/Irda/etc connected devices is going
> away from serial port abstraction towards RPC (ie the drivers provide a
> device specific or device class specific driver that provides an
> application level api to the device functions). The line level protocol is
> often not even published.

I can't say I'm that happy with it. The best (or, rather, worst) example is
suchlike support for the Phidget servo controller - zealous Linux developers
implemented kernel module support for it, completely hijacking a possibility
of using it on a different level (it's somewhat fixed by now, thankfully).

I believe that whenever an abstraction is offered, it must be made optional
and/or pluggable so it can be replaced by something more suited to the task.

The nature of Java applications is such that they'd probably care much more
about Java API offered, than about no matter how rich application level api
that is offered outside of Java. I've dealt with JNI adapters in the past,
and whereas they can be made reasonably stable, the very fact that you are
forced to deal with things that are not on the critical timing/memory path
and could've been done much easier in Java causes endless grief.

> Joachim

--vt


From lyon at docjava.com  Sat Jun 24 04:54:12 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Sat, 24 Jun 2006 06:54:12 -0400
Subject: [Rxtx] jsr
In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
	<CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
	<20060623172829.GA5335@freehold.crocodile.org>
Message-ID: <p060204a3c0c2c9dde4f8@[192.168.1.152]>

Hi All,
I have had some off-list discussion with Trent.
Opening up a JSR with Sun, as per Peters' suggestion
seems like a reasonable idea, to us.

Does anyone having any concerns about the JSR process
that they would like to raise?

Thanks!
  - Doug



From the.grey.lantern at gmail.com  Sat Jun 24 18:15:26 2006
From: the.grey.lantern at gmail.com (Craig Nicoll)
Date: Sun, 25 Jun 2006 01:15:26 +0100
Subject: [Rxtx] Cannot create virtual serial port
Message-ID: <a1221cc50606241715g2d1e2af6r747347dd4c20e997@mail.gmail.com>

Hello,

This is my first post on this mailing list and I hope someone can help me.

I am having great difficult establishing a virtual serial port for the
Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia
7600.

Every time I try to run the SendMessage program that comes with SMSLib, I
get the following exception: gnu.io.NoSuchPortException

The port names I have tried are:
rfcomm0
rfcomm
/dev/rfcomm0
/dev/rfcomm

This is what I have done so far:
Modified /etc/bluetooth/rfcomm.conf to include the address of my phone:

rfcomm0 {
# Automatically bind the device at startup
bind no;

# Bluetooth address of the device
device 00:0e:6d:7a:98:43;

# RFCOMM channel for the connection
channel 1;

# Description of the connection
comment "Example Bluetooth device";
}

I also tried running the following command: rfcomm bind /dev/rfcomm0

I have searched the mailing list archives and found this post where someone
had a very similar problem to me:
http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried
changing the system properties as suggested and it made no difference.

I have also been scouring Google all day to no avail.

I would be incredibly grateful if anyone could give me some tips.

Thank you,

Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060625/cfa6df35/attachment-0003.html

From tjarvi at qbang.org  Sun Jun 25 19:56:08 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT)
Subject: [Rxtx] Pending release
Message-ID: <Pine.LNX.4.61.0606251942460.15744@www>


With frustration, I was unable to get to the pending release this weekend.
The release should be comming this next week once things calm down.
The source is in CVS except for a fix for multiple ports in windows.

I had planned on doing the release this weekend but that was disrupted by 
my transportation failing in a spectacular fashion.

--
Trent Jarvi
tjarvi at qbang.org


From Pawan.Kharbanda at dot.state.co.us  Tue Jun 27 22:28:51 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 27 Jun 2006 22:28:51 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>

 Trent, 
   I have an application running in a cluster in linux environment and I
am using RXTX2.1.7 (final) with JDK1.5. The application opens and closes
serial comm ports every 30 seconds and exchanges datas. I have
experienced some of my Comm Ports are left hanging (I can see the
LCK..cufXX lock files under /var/lock folder). On putting the debugs I
found out that, it is stuck at a native call line 809 in RXTXPort.java
class (Please see the code snippet below). Can you help me explain what
this method does in the native code? Am I getting into some thread
deadlocks? Thanks in advance.

Pawan Kharbanda 


public void removeEventListener()
	{
		if (debug)
			z.reportln( "RXTXPort:removeEventListener()
called");
		waitForTheNativeCodeSilly();
		//if( monThread != null && monThread.isAlive() )
		if( monThreadisInterrupted == true )
		{
			z.reportln( "	RXTXPort:removeEventListener()
already interrupted");
			monThread = null;
			SPEventListener = null;
			return;
		}
		else if( monThread != null && monThread.isAlive() )
		{
			if (debug)
				z.reportln( "
RXTXPort:Interrupt=true");
			monThreadisInterrupted=true;
			/*
			   Notify all threads in this PID that something
is up
			   They will call back to see if its their
thread
			   using isInterrupted().
			*/
			if (debug)
				z.reportln( "	RXTXPort:calling
interruptEventLoop");
// LINE 809			interruptEventLoop( ); It never returns
out of this 
			
			if (debug)
				z.reportln( "	RXTXPort:calling
monThread.join()");
			try {
				monThread.join(1000);
			} catch (Exception ex) {
				/* yikes */
				ex.printStackTrace();
			}
			if (debug)
				z.reportln( "	RXTXPort:waiting on
isAlive()");
			while( monThread.isAlive() )
			{
				if ( debug )
					z.reportln( "	MonThread is
still alive!");
				try {
					monThread.join(1000);
					Thread.sleep( 1000 );
				} catch( Exception e ){} 
				//monThread.stop();
			}
			
		}
		if (debug)
			z.reportln( "	RXTXPort:calling gc()");
		monThread = null;
		SPEventListener = null;
		MonitorThreadLock = false;
		MonitorThreadAlive=false;
		monThreadisInterrupted=true;
		z.reportln( "RXTXPort:removeEventListener() returning");
	} 

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Sunday, June 25, 2006 7:56 PM
To: rxtx at qbang.org
Subject: [Rxtx] Pending release


With frustration, I was unable to get to the pending release this
weekend.
The release should be comming this next week once things calm down.
The source is in CVS except for a fix for multiple ports in windows.

I had planned on doing the release this weekend but that was disrupted
by my transportation failing in a spectacular fashion.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Wed Jun 28 04:17:29 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 28 Jun 2006 04:17:29 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606280406330.9561@www>



Hi Pawan

You may have found a deadlock but I've not seen on recently on linux.

If you can, please update from CVS.  This will have some close fixes. 
I'm running with the same code as is in CVS.  It is not perfect but I've 
not seen anything like you mention.  Be sure to set timeouts and 
thresholds on the port.  It may be that the port is waiting on pending io 
that never happens.  I think the CVS patches deal with this also but it 
looks like your in a better test environment to know for sure.

The exploded vehicle mentioned below is expected to be fixed today.  It 
was just a ninja small radiator hose.  The pressure test afterwards 
created its own set of problems.  Until this is resolved, I'm spending 
most of my free time commuting by bicycle.

On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>   I have an application running in a cluster in linux environment and I
> am using RXTX2.1.7 (final) with JDK1.5. The application opens and closes
> serial comm ports every 30 seconds and exchanges datas. I have
> experienced some of my Comm Ports are left hanging (I can see the
> LCK..cufXX lock files under /var/lock folder). On putting the debugs I
> found out that, it is stuck at a native call line 809 in RXTXPort.java
> class (Please see the code snippet below). Can you help me explain what
> this method does in the native code? Am I getting into some thread
> deadlocks? Thanks in advance.
>
> Pawan Kharbanda
>
>
> public void removeEventListener()
> 	{
> 		if (debug)
> 			z.reportln( "RXTXPort:removeEventListener()
> called");
> 		waitForTheNativeCodeSilly();
> 		//if( monThread != null && monThread.isAlive() )
> 		if( monThreadisInterrupted == true )
> 		{
> 			z.reportln( "	RXTXPort:removeEventListener()
> already interrupted");
> 			monThread = null;
> 			SPEventListener = null;
> 			return;
> 		}
> 		else if( monThread != null && monThread.isAlive() )
> 		{
> 			if (debug)
> 				z.reportln( "
> RXTXPort:Interrupt=true");
> 			monThreadisInterrupted=true;
> 			/*
> 			   Notify all threads in this PID that something
> is up
> 			   They will call back to see if its their
> thread
> 			   using isInterrupted().
> 			*/
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> interruptEventLoop");
> // LINE 809			interruptEventLoop( ); It never returns
> out of this
>
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> monThread.join()");
> 			try {
> 				monThread.join(1000);
> 			} catch (Exception ex) {
> 				/* yikes */
> 				ex.printStackTrace();
> 			}
> 			if (debug)
> 				z.reportln( "	RXTXPort:waiting on
> isAlive()");
> 			while( monThread.isAlive() )
> 			{
> 				if ( debug )
> 					z.reportln( "	MonThread is
> still alive!");
> 				try {
> 					monThread.join(1000);
> 					Thread.sleep( 1000 );
> 				} catch( Exception e ){}
> 				//monThread.stop();
> 			}
>
> 		}
> 		if (debug)
> 			z.reportln( "	RXTXPort:calling gc()");
> 		monThread = null;
> 		SPEventListener = null;
> 		MonitorThreadLock = false;
> 		MonitorThreadAlive=false;
> 		monThreadisInterrupted=true;
> 		z.reportln( "RXTXPort:removeEventListener() returning");
> 	}
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Sunday, June 25, 2006 7:56 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] Pending release
>
>
> With frustration, I was unable to get to the pending release this
> weekend.
> The release should be comming this next week once things calm down.
> The source is in CVS except for a fix for multiple ports in windows.
>
> I had planned on doing the release this weekend but that was disrupted
> by my transportation failing in a spectacular fashion.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From Pawan.Kharbanda at dot.state.co.us  Wed Jun 28 12:11:06 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Wed, 28 Jun 2006 12:11:06 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>

Trent,
    Again thanks for the reply. First of all I have Receive timeouts set
on all communications including Max no of bytes to expect during the
call. I have noticed the problem is during "closing the connection". I
am not sure if the RXTX is 100% thread-safe yet. There seems to be a
glitch in the native calls. I am sure I have the latest code I did the
update on the Version 2.1.7 from CVS, is this where the latest updates
are located, I have noticed another version in CVS "rxtx-devel".

Regards
Pawan Kharbanda

    

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Wednesday, June 28, 2006 4:17 AM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports



Hi Pawan

You may have found a deadlock but I've not seen on recently on linux.

If you can, please update from CVS.  This will have some close fixes. 
I'm running with the same code as is in CVS.  It is not perfect but I've
not seen anything like you mention.  Be sure to set timeouts and
thresholds on the port.  It may be that the port is waiting on pending
io that never happens.  I think the CVS patches deal with this also but
it looks like your in a better test environment to know for sure.

The exploded vehicle mentioned below is expected to be fixed today.  It
was just a ninja small radiator hose.  The pressure test afterwards
created its own set of problems.  Until this is resolved, I'm spending
most of my free time commuting by bicycle.

On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>   I have an application running in a cluster in linux environment and 
> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and 
> closes serial comm ports every 30 seconds and exchanges datas. I have 
> experienced some of my Comm Ports are left hanging (I can see the 
> LCK..cufXX lock files under /var/lock folder). On putting the debugs I

> found out that, it is stuck at a native call line 809 in RXTXPort.java

> class (Please see the code snippet below). Can you help me explain 
> what this method does in the native code? Am I getting into some 
> thread deadlocks? Thanks in advance.
>
> Pawan Kharbanda
>
>
> public void removeEventListener()
> 	{
> 		if (debug)
> 			z.reportln( "RXTXPort:removeEventListener()
called");
> 		waitForTheNativeCodeSilly();
> 		//if( monThread != null && monThread.isAlive() )
> 		if( monThreadisInterrupted == true )
> 		{
> 			z.reportln( "	RXTXPort:removeEventListener()
> already interrupted");
> 			monThread = null;
> 			SPEventListener = null;
> 			return;
> 		}
> 		else if( monThread != null && monThread.isAlive() )
> 		{
> 			if (debug)
> 				z.reportln( "
> RXTXPort:Interrupt=true");
> 			monThreadisInterrupted=true;
> 			/*
> 			   Notify all threads in this PID that something
is up
> 			   They will call back to see if its their
thread
> 			   using isInterrupted().
> 			*/
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> interruptEventLoop");
> // LINE 809			interruptEventLoop( ); It never returns
> out of this
>
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> monThread.join()");
> 			try {
> 				monThread.join(1000);
> 			} catch (Exception ex) {
> 				/* yikes */
> 				ex.printStackTrace();
> 			}
> 			if (debug)
> 				z.reportln( "	RXTXPort:waiting on
> isAlive()");
> 			while( monThread.isAlive() )
> 			{
> 				if ( debug )
> 					z.reportln( "	MonThread is
> still alive!");
> 				try {
> 					monThread.join(1000);
> 					Thread.sleep( 1000 );
> 				} catch( Exception e ){}
> 				//monThread.stop();
> 			}
>
> 		}
> 		if (debug)
> 			z.reportln( "	RXTXPort:calling gc()");
> 		monThread = null;
> 		SPEventListener = null;
> 		MonitorThreadLock = false;
> 		MonitorThreadAlive=false;
> 		monThreadisInterrupted=true;
> 		z.reportln( "RXTXPort:removeEventListener() returning");
> 	}
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf

> Of Trent Jarvi
> Sent: Sunday, June 25, 2006 7:56 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] Pending release
>
>
> With frustration, I was unable to get to the pending release this 
> weekend.
> The release should be comming this next week once things calm down.
> The source is in CVS except for a fix for multiple ports in windows.
>
> I had planned on doing the release this weekend but that was disrupted

> by my transportation failing in a spectacular fashion.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Wed Jun 28 12:26:21 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 28 Jun 2006 12:26:21 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606281222420.9561@www>


Hi Pawan

If you did a cvs update from the 2.1-7 tar ball, you have the current 
version.  All rxtx in CVS is under rxtx-devel.  The 2.1-7 just has -r
commapi-0-0-1.

You may well have found something.  I have seen win32 fail on closing 
ports but not linux that I can think of.  Your use is much different than 
I normally see too.

Could you give us more information on how we would reproduce this and the 
frequency?


On Wed, 28 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>    Again thanks for the reply. First of all I have Receive timeouts set
> on all communications including Max no of bytes to expect during the
> call. I have noticed the problem is during "closing the connection". I
> am not sure if the RXTX is 100% thread-safe yet. There seems to be a
> glitch in the native calls. I am sure I have the latest code I did the
> update on the Version 2.1.7 from CVS, is this where the latest updates
> are located, I have noticed another version in CVS "rxtx-devel".
>
> Regards
> Pawan Kharbanda
>
>
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Wednesday, June 28, 2006 4:17 AM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] Locked Ports
>
>
>
> Hi Pawan
>
> You may have found a deadlock but I've not seen on recently on linux.
>
> If you can, please update from CVS.  This will have some close fixes.
> I'm running with the same code as is in CVS.  It is not perfect but I've
> not seen anything like you mention.  Be sure to set timeouts and
> thresholds on the port.  It may be that the port is waiting on pending
> io that never happens.  I think the CVS patches deal with this also but
> it looks like your in a better test environment to know for sure.
>
> The exploded vehicle mentioned below is expected to be fixed today.  It
> was just a ninja small radiator hose.  The pressure test afterwards
> created its own set of problems.  Until this is resolved, I'm spending
> most of my free time commuting by bicycle.
>
> On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:
>
>> Trent,
>>   I have an application running in a cluster in linux environment and
>> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and
>> closes serial comm ports every 30 seconds and exchanges datas. I have
>> experienced some of my Comm Ports are left hanging (I can see the
>> LCK..cufXX lock files under /var/lock folder). On putting the debugs I
>
>> found out that, it is stuck at a native call line 809 in RXTXPort.java
>
>> class (Please see the code snippet below). Can you help me explain
>> what this method does in the native code? Am I getting into some
>> thread deadlocks? Thanks in advance.
>>
>> Pawan Kharbanda
>>
>>
>> public void removeEventListener()
>> 	{
>> 		if (debug)
>> 			z.reportln( "RXTXPort:removeEventListener()
> called");
>> 		waitForTheNativeCodeSilly();
>> 		//if( monThread != null && monThread.isAlive() )
>> 		if( monThreadisInterrupted == true )
>> 		{
>> 			z.reportln( "	RXTXPort:removeEventListener()
>> already interrupted");
>> 			monThread = null;
>> 			SPEventListener = null;
>> 			return;
>> 		}
>> 		else if( monThread != null && monThread.isAlive() )
>> 		{
>> 			if (debug)
>> 				z.reportln( "
>> RXTXPort:Interrupt=true");
>> 			monThreadisInterrupted=true;
>> 			/*
>> 			   Notify all threads in this PID that something
> is up
>> 			   They will call back to see if its their
> thread
>> 			   using isInterrupted().
>> 			*/
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> interruptEventLoop");
>> // LINE 809			interruptEventLoop( ); It never returns
>> out of this
>>
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> monThread.join()");
>> 			try {
>> 				monThread.join(1000);
>> 			} catch (Exception ex) {
>> 				/* yikes */
>> 				ex.printStackTrace();
>> 			}
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:waiting on
>> isAlive()");
>> 			while( monThread.isAlive() )
>> 			{
>> 				if ( debug )
>> 					z.reportln( "	MonThread is
>> still alive!");
>> 				try {
>> 					monThread.join(1000);
>> 					Thread.sleep( 1000 );
>> 				} catch( Exception e ){}
>> 				//monThread.stop();
>> 			}
>>
>> 		}
>> 		if (debug)
>> 			z.reportln( "	RXTXPort:calling gc()");
>> 		monThread = null;
>> 		SPEventListener = null;
>> 		MonitorThreadLock = false;
>> 		MonitorThreadAlive=false;
>> 		monThreadisInterrupted=true;
>> 		z.reportln( "RXTXPort:removeEventListener() returning");
>> 	}
>>
>> -----Original Message-----
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
>
>> Of Trent Jarvi
>> Sent: Sunday, June 25, 2006 7:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] Pending release
>>
>>
>> With frustration, I was unable to get to the pending release this
>> weekend.
>> The release should be comming this next week once things calm down.
>> The source is in CVS except for a fix for multiple ports in windows.
>>
>> I had planned on doing the release this weekend but that was disrupted
>
>> by my transportation failing in a spectacular fashion.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From Pawan.Kharbanda at dot.state.co.us  Wed Jun 28 15:42:49 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Wed, 28 Jun 2006 15:42:49 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>

Trent,
    I will try to explain how I am setup and will try to write you a
Sample code little later to reproduce this. On our system we have
DigiBoxes installed on the 2 Linux servers. Both of them have RXTX2.1-7
version installed with the JRE(1.5) and both the machines have the same
port mappings in gnu.io.rxtx.properties (Currently in the production
system I have 64 ports). This is how the system works:

1) A thick Map based client initiates a Action on the Device on the
field. One of the Thread Workers(Asynchronous Call) in the Cluster picks
up the request. 
2) Once the worker gets the request it locks the Device and
Communication port in the DB's(These are our persistent locks, because
most of the devices do one to one communication with the serial ports).
After that the worker (or Comm Server) opens up the connection and after
exchanging the information calls the "Close" and returns.
3) Once the connection is closed , the DB lock is removed on the comm
port and is made available to accept future calls. Here is where the
glitch is the Serial Comm Close method never returns due to the
deadlock. 

I have noticed that the deadlocks are very inconsistent, sometime it
happens right away as soon as Application server starts and sometimes I
don't see any deadlocks for days, but it happens for sure. 

Here is how you can test if you have resources/ test environment. Write
a program and try to open/close  different ports(I will say have a
minimum of four) randomly and very frequently(may be 30 seconds), I am
pretty sure you will see the deadlocks and it happens in the native call
to interrptEventLoop in RXTXPort.java in removeEventListener() method
call.

Also I have noticed that the JVM carshes (without any memrory errors or
JVM errors. Its just not there) when native call is made to eventLoop()
in run() method in MonitorThread inner class. I am still investigating
why this is happening, but at this point I can just tell you the
location. You might have a question How I am so sure about the location?
My application is configured with Log4J and I have enabled the debugs on
the RXTXPort.java, so every time my JVM dies I see these logs at the end
of the file.

"2006-06-28 15:27:15,183 INFO  [STDOUT] RXTXPort:RXTXPort(/dev/cub01)
called
2006-06-28 15:27:15,218 INFO  [STDOUT]
RXTXPort:MontitorThread:MonitorThread()
2006-06-28 15:27:15,219 INFO  [STDOUT] RXTXPort:MontitorThread:run()"

I surely do have a luxury of a testing environment(ports, devices etc.)
and can help you fix these problems? Please advise me how we can resolve
these issues.

Thanks 
Pawan Kharbanda
303-478-2991





-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Wednesday, June 28, 2006 12:26 PM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports


Hi Pawan

If you did a cvs update from the 2.1-7 tar ball, you have the current
version.  All rxtx in CVS is under rxtx-devel.  The 2.1-7 just has -r
commapi-0-0-1.

You may well have found something.  I have seen win32 fail on closing
ports but not linux that I can think of.  Your use is much different
than I normally see too.

Could you give us more information on how we would reproduce this and
the frequency?


On Wed, 28 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>    Again thanks for the reply. First of all I have Receive timeouts
set
> on all communications including Max no of bytes to expect during the
> call. I have noticed the problem is during "closing the connection". I
> am not sure if the RXTX is 100% thread-safe yet. There seems to be a
> glitch in the native calls. I am sure I have the latest code I did the
> update on the Version 2.1.7 from CVS, is this where the latest updates
> are located, I have noticed another version in CVS "rxtx-devel".
>
> Regards
> Pawan Kharbanda
>
>
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Wednesday, June 28, 2006 4:17 AM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] Locked Ports
>
>
>
> Hi Pawan
>
> You may have found a deadlock but I've not seen on recently on linux.
>
> If you can, please update from CVS.  This will have some close fixes.
> I'm running with the same code as is in CVS.  It is not perfect but
I've
> not seen anything like you mention.  Be sure to set timeouts and
> thresholds on the port.  It may be that the port is waiting on pending
> io that never happens.  I think the CVS patches deal with this also
but
> it looks like your in a better test environment to know for sure.
>
> The exploded vehicle mentioned below is expected to be fixed today.
It
> was just a ninja small radiator hose.  The pressure test afterwards
> created its own set of problems.  Until this is resolved, I'm spending
> most of my free time commuting by bicycle.
>
> On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:
>
>> Trent,
>>   I have an application running in a cluster in linux environment and
>> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and
>> closes serial comm ports every 30 seconds and exchanges datas. I have
>> experienced some of my Comm Ports are left hanging (I can see the
>> LCK..cufXX lock files under /var/lock folder). On putting the debugs
I
>
>> found out that, it is stuck at a native call line 809 in
RXTXPort.java
>
>> class (Please see the code snippet below). Can you help me explain
>> what this method does in the native code? Am I getting into some
>> thread deadlocks? Thanks in advance.
>>
>> Pawan Kharbanda
>>
>>
>> public void removeEventListener()
>> 	{
>> 		if (debug)
>> 			z.reportln( "RXTXPort:removeEventListener()
> called");
>> 		waitForTheNativeCodeSilly();
>> 		//if( monThread != null && monThread.isAlive() )
>> 		if( monThreadisInterrupted == true )
>> 		{
>> 			z.reportln( "	RXTXPort:removeEventListener()
>> already interrupted");
>> 			monThread = null;
>> 			SPEventListener = null;
>> 			return;
>> 		}
>> 		else if( monThread != null && monThread.isAlive() )
>> 		{
>> 			if (debug)
>> 				z.reportln( "
>> RXTXPort:Interrupt=true");
>> 			monThreadisInterrupted=true;
>> 			/*
>> 			   Notify all threads in this PID that something
> is up
>> 			   They will call back to see if its their
> thread
>> 			   using isInterrupted().
>> 			*/
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> interruptEventLoop");
>> // LINE 809			interruptEventLoop( ); It never returns
>> out of this
>>
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> monThread.join()");
>> 			try {
>> 				monThread.join(1000);
>> 			} catch (Exception ex) {
>> 				/* yikes */
>> 				ex.printStackTrace();
>> 			}
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:waiting on
>> isAlive()");
>> 			while( monThread.isAlive() )
>> 			{
>> 				if ( debug )
>> 					z.reportln( "	MonThread is
>> still alive!");
>> 				try {
>> 					monThread.join(1000);
>> 					Thread.sleep( 1000 );
>> 				} catch( Exception e ){}
>> 				//monThread.stop();
>> 			}
>>
>> 		}
>> 		if (debug)
>> 			z.reportln( "	RXTXPort:calling gc()");
>> 		monThread = null;
>> 		SPEventListener = null;
>> 		MonitorThreadLock = false;
>> 		MonitorThreadAlive=false;
>> 		monThreadisInterrupted=true;
>> 		z.reportln( "RXTXPort:removeEventListener() returning");
>> 	}
>>
>> -----Original Message-----
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On
Behalf
>
>> Of Trent Jarvi
>> Sent: Sunday, June 25, 2006 7:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] Pending release
>>
>>
>> With frustration, I was unable to get to the pending release this
>> weekend.
>> The release should be comming this next week once things calm down.
>> The source is in CVS except for a fix for multiple ports in windows.
>>
>> I had planned on doing the release this weekend but that was
disrupted
>
>> by my transportation failing in a spectacular fashion.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx 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 khattar31 at yahoo.com  Wed Jun 28 22:04:59 2006
From: khattar31 at yahoo.com (rahul khattar)
Date: Wed, 28 Jun 2006 21:04:59 -0700 (PDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
Message-ID: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>

Hi All,

I was looking at the src file on the last release.
I did notice a missing header file while trying to
compile the parallelport.dll. Would somebody be kind
enoughf to share the missing header file:
gnu_io_LPRPort.h

I am using MinGw to compile the same from Parinya
(which is an execellent tool)


Regards,
Rahul Khattar

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Thu Jun 29 03:43:53 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 03:43:53 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>
References: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606290341210.9561@www>

On Wed, 28 Jun 2006, rahul khattar wrote:

> Hi All,
>
> I was looking at the src file on the last release.
> I did notice a missing header file while trying to
> compile the parallelport.dll. Would somebody be kind
> enoughf to share the missing header file:
> gnu_io_LPRPort.h
>
> I am using MinGw to compile the same from Parinya
> (which is an execellent tool)
>

Hi Rahul

The gnu.io_LPRPort.h file is generated with javah.  You can see the 
command in the Makefile I presume.  You do not need rxtxParallel.dll to 
use w32 serial btw.

--
Trent Jarvi
tjarvi at qbang.org


From khattar31 at yahoo.com  Thu Jun 29 04:47:01 2006
From: khattar31 at yahoo.com (rahul khattar)
Date: Thu, 29 Jun 2006 03:47:01 -0700 (PDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606290341210.9561@www>
Message-ID: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>

Hi Trent 
I did notice this file is required in the source file
ParallelImp.c
on line 38

Attached the O/P 

Regards,
Rahul Khattar




--- Trent Jarvi <tjarvi at qbang.org> wrote:

> On Wed, 28 Jun 2006, rahul khattar wrote:
> 
> > Hi All,
> >
> > I was looking at the src file on the last release.
> > I did notice a missing header file while trying to
> > compile the parallelport.dll. Would somebody be
> kind
> > enoughf to share the missing header file:
> > gnu_io_LPRPort.h
> >
> > I am using MinGw to compile the same from Parinya
> > (which is an execellent tool)
> >
> 
> Hi Rahul
> 
> The gnu.io_LPRPort.h file is generated with javah. 
> You can see the 
> command in the Makefile I presume.  You do not need
> rxtxParallel.dll to 
> use w32 serial btw.
> 
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Error.zip
Type: application/x-zip-compressed
Size: 1746 bytes
Desc: 2948039066-Error.zip
Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060629/a5b6f783/Error-0012.bin

From tjarvi at qbang.org  Thu Jun 29 06:16:24 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 06:16:24 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606290614530.9561@www>

On Thu, 29 Jun 2006, rahul khattar wrote:

> Hi Trent
> I did notice this file is required in the source file
> ParallelImp.c
> on line 38
>
> Attached the O/P
>

The command to generate the .h file will be something like:

javah -classpath . -jni gnu.io.LPRPort

The makefile should have this.  There are several approaches to creating 
or using makefiles so I have no idea which one you used if any.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Thu Jun 29 06:20:51 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 06:20:51 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606290616420.9561@www>

> Here is how you can test if you have resources/ test environment. Write
> a program and try to open/close  different ports(I will say have a
> minimum of four) randomly and very frequently(may be 30 seconds), I am
> pretty sure you will see the deadlocks and it happens in the native call
> to interrptEventLoop in RXTXPort.java in removeEventListener() method
> call.

Hi Pawan

I'll try to find a way to reproduce this.  One thing to note is that you 
are using different kernel drivers (digi) to perform this task.  So I 
probably will not be able to reproduce the exact same environment.

In general, multiport kernel drivers have been tested far less than 
typical serial drivers.  This may or may not be an issue.

--
Trent Jarvi
tjarvi at qbang.org



From jhaysonn at gmail.com  Thu Jun 29 12:29:13 2006
From: jhaysonn at gmail.com (jhaysonn pathak)
Date: Thu, 29 Jun 2006 14:29:13 -0400
Subject: [Rxtx] RXTX install
Message-ID: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>

Hi Guys,

I'm doing trying to write a generative piece of Sonic Art using an EEG
plugged into a mac runnning Max/MSP.  I just recently discovered RXTX
drivers in my search for a piece of software that might give me more
output options for my EEG (I'm using the CEO from MindPeak).  I found
Bioera which uses RXTX drivers.  Thing is - I can't figure out how to
install RXTX correctly.

After I build the 'libSerial.jnilib' target inside of
'LibSerial.pbproj' I can't find the libSerial.jnilib file that
accompanies the RXTXcomm.jar nor do I know where to put them.

I also don't understand this part at the bottom of the OS X instructions at all:

"AFTER INSTALLATION VERY IMPORTANT
	check existence of the folder /var/spool/uucp
	if you don't have it create it with command
	sudo mkdir /var/spool/uucp
	permissions should be: drwxrwxr-x
	if they are not do command
	sudo chmod 775 /var/spool/uucp

	YOU should be a member of the uucp group
	you can check it with command
		niutil -readprop / /groups/uucp users
	you should see your name in output of the niutil command
	if you don't do following:
		sudo niutil -appendprop / /groups/uucp users <yourname>
			substitute  <yourname> with your user's name
			for example if your user name is peter:
				sudo niutil -appendprop / /groups/uucp users peter

	NOTES: RXTX.pkg should create uucp folder and insert your name  in
uucp group automatically"



I really appreciate any help that you guys can offer.  I've been
struggling with this for a while now as part of a research grant that
I was awarded.  Thanks again for the help.

Jhaysonn Pathak


From naranjo.manuel at gmail.com  Thu Jun 29 07:19:15 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 10:19:15 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606290614530.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www>
Message-ID: <44A3D353.6010605@gmail.com>

Speaking about Windows Support, I had seen that inside the 
rxtx-2.1-7-bins-r2 package inside Windows directory it says:
"i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will 
not make harm to anyone, and i'm almost sure that someone has noticed it 
before.
Cheers,
Manuel


From joachim at buechse.de  Thu Jun 29 13:25:16 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 29 Jun 2006 21:25:16 +0200
Subject: [Rxtx] RXTX install
In-Reply-To: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>
References: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>
Message-ID: <2A003E42-97E1-4237-8438-646BDE2E3961@buechse.de>

Hello Jhaysonn,

I assume you are trying to use the javax.comm version of RXTX.

Please use "cvs up" to update your download to the latest version of  
the repository. The latest version does not use lock files, so the  
mentioned process is no longer needed. Updating with CVS will also  
provide you with a new README.OSX file that should be simpler to  
understand.

You will find LibSerialUniversal.xcodeproj in MACOSX_IDE/Xcode. Put  
comm.jar (downloaded from Sun) into MACOSX_IDE/Xcode. Compile the  
library. You will find RXTXcomm.jar and librxtxSerial.jnilib in  
MACOSX_IDE/Xcode/build/Default

Best regards,
Joachim
---
Joachim B?chse
Softwarel?sungen und Beratung
Hadlaubsteig 2
CH-8006 Z?rich


On 29.06.2006, at 20:29, jhaysonn pathak wrote:

> Hi Guys,
>
> I'm doing trying to write a generative piece of Sonic Art using an EEG
> plugged into a mac runnning Max/MSP.  I just recently discovered RXTX
> drivers in my search for a piece of software that might give me more
> output options for my EEG (I'm using the CEO from MindPeak).  I found
> Bioera which uses RXTX drivers.  Thing is - I can't figure out how to
> install RXTX correctly.
>
> After I build the 'libSerial.jnilib' target inside of
> 'LibSerial.pbproj' I can't find the libSerial.jnilib file that
> accompanies the RXTXcomm.jar nor do I know where to put them.
>
> I also don't understand this part at the bottom of the OS X  
> instructions at all:
>
> "AFTER INSTALLATION VERY IMPORTANT
> 	check existence of the folder /var/spool/uucp
> 	if you don't have it create it with command
> 	sudo mkdir /var/spool/uucp
> 	permissions should be: drwxrwxr-x
> 	if they are not do command
> 	sudo chmod 775 /var/spool/uucp
>
> 	YOU should be a member of the uucp group
> 	you can check it with command
> 		niutil -readprop / /groups/uucp users
> 	you should see your name in output of the niutil command
> 	if you don't do following:
> 		sudo niutil -appendprop / /groups/uucp users <yourname>
> 			substitute  <yourname> with your user's name
> 			for example if your user name is peter:
> 				sudo niutil -appendprop / /groups/uucp users peter
>
> 	NOTES: RXTX.pkg should create uucp folder and insert your name  in
> uucp group automatically"
>
>
>
> I really appreciate any help that you guys can offer.  I've been
> struggling with this for a while now as part of a research grant that
> I was awarded.  Thanks again for the help.
>
> Jhaysonn Pathak
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From tjarvi at qbang.org  Thu Jun 29 19:30:00 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 19:30:00 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A3D353.6010605@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
Message-ID: <Pine.LNX.4.61.0606291923000.9561@www>

On Thu, 29 Jun 2006, Manuel Naranjo wrote:

> Speaking about Windows Support, I had seen that inside the
> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
> not make harm to anyone, and i'm almost sure that someone has noticed it
> before.

Hi Manuel

         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
     47421  01-30-06 00:23 
rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
     77759  03-01-06 12:01 
rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README


It looks normal to me.  There are no fancy tools used there :)

--
Trent Jarvi
tjarvi at qbang.org

From naranjo.manuel at gmail.com  Thu Jun 29 19:38:16 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 22:38:16 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606291923000.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com> <Pine.LNX.4.61.0606291923000.9561@www>
Message-ID: <44A48088.2040407@gmail.com>

> On Thu, 29 Jun 2006, Manuel Naranjo wrote:
> 
>> Speaking about Windows Support, I had seen that inside the
>> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
>> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
>> not make harm to anyone, and i'm almost sure that someone has noticed it
>> before.
> 
> Hi Manuel
> 
>         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
>         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
>     47421  01-30-06 00:23 
> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
>     77759  03-01-06 12:01 
> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
>       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README
> 
> 
> It looks normal to me.  There are no fancy tools used there :)
> 
Hi Trent:
Is not the i368 representing the name of the Architecture?? If so the 
name should start with i386 it will not break any system, is simply miss
written, I saw that and wanted to report it. It a silly thing.
Ohh I forgoten I must congratulate you for your GREAT libray, I was able 
to make an .exe with JSmooth that launches an application that uses RXTX 
with out the need to install RXTX on users system :). The .exe tells JVM 
where to find the RXTX Library and Binaries. I tried with Sun's Java 
Comm but it was imposible.
Regards,
Manuel


From tjarvi at qbang.org  Thu Jun 29 19:52:45 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 19:52:45 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A48088.2040407@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
	<Pine.LNX.4.61.0606291923000.9561@www> <44A48088.2040407@gmail.com>
Message-ID: <Pine.LNX.4.61.0606291945060.9561@www>

On Thu, 29 Jun 2006, Manuel Naranjo wrote:

>> On Thu, 29 Jun 2006, Manuel Naranjo wrote:
>>
>>> Speaking about Windows Support, I had seen that inside the
>>> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
>>> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
>>> not make harm to anyone, and i'm almost sure that someone has noticed it
>>> before.
>>
>> Hi Manuel
>>
>>         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
>>         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
>>     47421  01-30-06 00:23
>> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
>>     77759  03-01-06 12:01
>> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
>>       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README
>>
>>
>> It looks normal to me.  There are no fancy tools used there :)
>>
> Hi Trent:
> Is not the i368 representing the name of the Architecture?? If so the
> name should start with i386 it will not break any system, is simply miss
> written, I saw that and wanted to report it. It a silly thing.
> Ohh I forgoten I must congratulate you for your GREAT libray, I was able
> to make an .exe with JSmooth that launches an application that uses RXTX
> with out the need to install RXTX on users system :). The .exe tells JVM
> where to find the RXTX Library and Binaries. I tried with Sun's Java
> Comm but it was imposible.

Hi Manuel

The compiler uses only the i386 instruction set for windows.  I doubt 
there will be any measurable advantages with going to later instruction 
sets.  In theory rxtx would run on a 386 but I doubt anyone does that.

So it looks odd but is not a typo.

We could compile to i686 but don't.  The compiler used does not appear to 
be a problem yet so I don't see any point in changing it.  Right now, we 
could not compile 64 bit windows binaries.  gcc/mingw/... do not support 
them that I know of.  People will have to compile those with closed source 
tools on their own until an option is available.

--
Trent Jarvi
tjarvi at qbang.org

From naranjo.manuel at gmail.com  Thu Jun 29 20:00:48 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 23:00:48 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606291945060.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com>	<Pine.LNX.4.61.0606291923000.9561@www>
	<44A48088.2040407@gmail.com> <Pine.LNX.4.61.0606291945060.9561@www>
Message-ID: <44A485D0.7050202@gmail.com>

Trent you did not get my point
The folder says 368 three hundred sixty eight, when
it should say 386 three hundred eighty six. Is simply a miss writting.
Regards,
Manuel


From tjarvi at qbang.org  Thu Jun 29 20:12:15 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 20:12:15 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A485D0.7050202@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
	<Pine.LNX.4.61.0606291923000.9561@www> <44A48088.2040407@gmail.com>
	<Pine.LNX.4.61.0606291945060.9561@www> <44A485D0.7050202@gmail.com>
Message-ID: <Pine.LNX.4.61.0606292008061.9561@www>


On Thu, 29 Jun 2006, Manuel Naranjo wrote:

> Trent you did not get my point
> The folder says 368 three hundred sixty eight, when
> it should say 386 three hundred eighty six. Is simply a miss writting.

hehe..  OK.  My bad.  It's been a long day.

Nevermind :)

--
Trent Jarvi
tjarvi at qbang.org




From naranjo.manuel at gmail.com  Thu Jun 29 20:18:44 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 23:18:44 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606292008061.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com>	<Pine.LNX.4.61.0606291923000.9561@www>
	<44A48088.2040407@gmail.com>	<Pine.LNX.4.61.0606291945060.9561@www>
	<44A485D0.7050202@gmail.com> <Pine.LNX.4.61.0606292008061.9561@www>
Message-ID: <44A48A04.9040401@gmail.com>

Don't worry Trent.
About 64 bits compilation, I would like to colaborate, I have a Pc with 
64 bits, the only problem is that i do not have windows 64 bits 
installed :(.




From Pawan.Kharbanda at dot.state.co.us  Fri Jun 30 08:49:52 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 30 Jun 2006 08:49:52 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E996@hqexchange3.dot.state.co.us>

Trent,  
    Can you explain what the interruptedEventLoop() native method is
doing is there a possibility that method is somehow getting into the
infinite loop(there are 2 while loops without any break statements).
This might be a very basic question how can I debug the native code(or
print the debug statements).  Again thanks for the help. 

Pawan Kharbanda

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Thursday, June 29, 2006 6:21 AM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports

> Here is how you can test if you have resources/ test environment. 
> Write a program and try to open/close  different ports(I will say have

> a minimum of four) randomly and very frequently(may be 30 seconds), I 
> am pretty sure you will see the deadlocks and it happens in the native

> call to interrptEventLoop in RXTXPort.java in removeEventListener() 
> method call.

Hi Pawan

I'll try to find a way to reproduce this.  One thing to note is that you
are using different kernel drivers (digi) to perform this task.  So I
probably will not be able to reproduce the exact same environment.

In general, multiport kernel drivers have been tested far less than
typical serial drivers.  This may or may not be an issue.

--
Trent Jarvi
tjarvi at qbang.org

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From cpine at wrsystems.com  Thu Jun 29 15:17:12 2006
From: cpine at wrsystems.com (Chris Pine)
Date: Thu, 29 Jun 2006 17:17:12 -0400
Subject: [Rxtx]  Controlling Individual Signals DTR and RTS
Message-ID: <MAIL4FJo0S8ACLEBajJ000005cf@mail4.wrsystems.com>

Dear Moussa Ba,
	I hope I am not being too forward, but we are having the exact same
issue with needing to control DTR from RXTX in Linux.  Did you ever have any
luck figuring it out?

Thank you very much for your time,

Chris Pine




From tjarvi at qbang.org  Thu Jun  1 11:13:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 11:13:40 -0600 (MDT)
Subject: [Rxtx] custom baud rate win32
In-Reply-To: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606011107210.30220@www>


Hi Daren

I can't imagine that 1953 is possibly the actual value on the UART.  Maybe 
if your baud base is very high with a custom serial board.  More likely, 
the driver just remembers that what you asked for and did something else.

I'll have more to say on the dcb->BaudRate after I try some things here. 
I have managed to do something like that in the past as a quick hack but 
it was for 14400.  I may have used the CBR_14400.

If we can't access this through the win32 API with protected mode, there 
is another layer of complication.  With real mode, it would be easy.
With protected mode, I assume there would have to be some kernel driver or 
a hook I'm not aware of to access the MCR directly (bang a memory 
addresss).



On Thu, 1 Jun 2006, Daren wrote:

> Trent,
> I have managed to successfully open the port at this speed using Realterm
> (available on sourceforge). From memory this uses DLPortIO.
>
> Using portmon.exe with realterm, even there it says that the port has opened
> at 1953.
>
> I changed termios.c:560 to
> dcb->BaudRate        = 1953 ;
>
> and it still opens the port at 9600.
>
> Daren
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Trent Jarvi
> Sent: Thursday, 1 June 2006 1:44 PM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] custom baud rate win32
>
> On Thu, 1 Jun 2006, Daren wrote:
>
>> Hi all,
>>
>> I downloaded 2.1.7-pre16 and managed to build it and get it going. I made
>> the changes as suggested by Peter Smith in an old post, by adding his code
>> to SerialImpl.c, uncommenting the TIOCGSERIAL and TIOCSSERIAL, and
> defining
>> ASYNC_SPD_CUST which is equal to 0x0030 (according to linus header
> files)..
>>
>>
>> Still not working, it opens the port at 9600 according to portmon.exe .
> Has
>> anyone managed to get this going at a custom rate?
>>
>> Here is the post I'm referring to:
>> http://marc.theaimsgroup.com/?l=rxtx&m=106270038110713&w=2
>>
>>
>> Thanks,
>> Daren
>>
>> ________________________________________
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
>> Daren
>> Sent: Wednesday, 31 May 2006 10:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] (no subject)
>>
>> Hi All,
>> I have been using rxtx for a little while and needed to get it working at
>> 1953, like a past user in the mailing list, who seemed to have got it
>> working by changing some C code.
>>
>> I wanted to build rxtx myself with these changes but don't know where to
>> start. I have windows here and FC4 at home. I downloaded cygwin and
> mingw32,
>> each build works by building a rxtxSerial.dll file that is ~11k smaller
> than
>> the original, and I always get the following error when testing the dll:
>>
>> Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at
>> PC=0x8077655
>> Function=[Unknown.]
>> Library=C:\opt\java\j2sdk1.4.2\jre\bin\client\jvm.dll
>>
>> NOTE: We are unable to locate the function name symbol for the error
>>      just occurred. Please refer to release documentation for possible
>>      reason and solutions.
>>
>>
>> Current Java thread:
>> 	at gnu.io.RXTXPort.open(Native Method)
>> 	- locked <0x1002c800> (a gnu.io.RXTXPort)
>> 	at gnu.io.RXTXPort.<init>(RXTXPort.java:84)
>>
>> Anyone know what im doing wrong?
>>
>>
>>
>>
>
> Hi Daren
>
> You are running into the same rats nest I'm looking at now.
>
> With win32 and specific custom baud rates, I'm not sure how this will go.
> I've got the Linux custom baud rates working very nicely.  I did much like
> the post you linked.  In fact I had forgot about that post.  You probably
> noticed that it becomes a bunch of dirt roads going noplace fast in
> termios.c for w32.
>
> I'm probably only going to get 14400, 28800, 128000 and 256000 working
> with the next release on w32.  I'll look a little further.  If you have an
> example w32 that works at 1953 I'd really like to hear.  Thats an unusual
> baud rate.
>
> Assuming a baud_base of 128000, your divisor will be 65 or 66.
>
> 128000/66=1939 -14
> 128000/65=1969 +13
>
> One thing I've been wondering about with linux is which would be the right
> answer in cases like this.  Right now it would just go with a baud base of
> 65 and ignore the modulus details.
>
> It appears to be a general trend for kernel developers to hide these
> details thinking that they can come up with a general solution.  Then they
> run out of time.  Perahps the solution is to help out but there are
> ultiple OS's rxtx supports making that nontrivial.
>
> If you look at current linux kernels, the 'tricks' above have been marked
> deprecated with no replacement.  Windows has some hard defines and then
> ancient near magic.  I've not looked at Solaris via Open Solaris yet but
> doubt there is a solution at all.
>
> What I'd try since you have the equipment and the monitor software is to
> hardcode the dcb->Baud in termios.c to 1953 (no define) and see what the
> w32 kernel does with it.  I think if you toss a baud rate at the driver it
> will try to come close.  You may try comming closer to a real baudrate
> based upon the 128000 baud base as shown above.
>
> If it works, it is worth looking at the rest of the ping/pong logic then.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
>
>
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From doug at dupreeinc.com  Thu Jun  1 13:22:13 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 12:22:13 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011107210.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
Message-ID: <447F3E65.1020809@dupreeinc.com>

Hello,

I am still trying to get this startup a little faster so I turned on the 
debug of a few of the classes.  The COM ports are scanned really fast 
and the delay occurs during the LPT scan.  The console output looks like 
this:

    ...
      LPT1
      LPT2
      LPT3
     valid port prefixes:
      LPT
    LPT1 LPT
    1 1
    LPT2 LPT
    2 2                                                                 
      * <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
    CommPortIdentifier:addPortName(LPT2)
    CommPortIdentifier:AddIdentifierToList()
    LPT3 LPT
    3 3
    CommPortIdentifier:addPortName(LPT3)
    CommPortIdentifier:AddIdentifierToList()
    CommPortIdentifier:AddIdentifierToList() index.next
    Leaving registerValidPorts()
    Have not implemented native_psmisc_report_owner(PortName)); in
    CommPortIdentifier
    CommPortIdentifier:getPortIdentifier(COM3)
    CommPortIdentifier:open(densConnect, 30000)
    RXTXCommDriver:getCommPort(COM3,1)
    ...

It would seem to me that if I removed the code for port scanning of LPT 
ports I could solve this problem. I would much prefer to use unmodified 
code if at all possible.  Do any of you have alternate suggestions?

Thank you for your time.

Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/cf433ee7/attachment-0013.html

From tjarvi at qbang.org  Thu Jun  1 13:52:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 13:52:06 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F3E65.1020809@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011348380.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I am still trying to get this startup a little faster so I turned on the 
> debug of a few of the classes.  The COM ports are scanned really fast and the 
> delay occurs during the LPT scan.  The console output looks like this:
>
>   ...
>     LPT1
>     LPT2
>     LPT3
>    valid port prefixes:
>     LPT
>   LPT1 LPT
>   1 1
>   LPT2 LPT
>   2 2                                                                      * 
> <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>   CommPortIdentifier:addPortName(LPT2)
>   CommPortIdentifier:AddIdentifierToList()
>   LPT3 LPT
>   3 3
>   CommPortIdentifier:addPortName(LPT3)
>   CommPortIdentifier:AddIdentifierToList()
>   CommPortIdentifier:AddIdentifierToList() index.next
>   Leaving registerValidPorts()
>   Have not implemented native_psmisc_report_owner(PortName)); in
>   CommPortIdentifier
>   CommPortIdentifier:getPortIdentifier(COM3)
>   CommPortIdentifier:open(densConnect, 30000)
>   RXTXCommDriver:getCommPort(COM3,1)
>   ...
>
> It would seem to me that if I removed the code for port scanning of LPT ports 
> I could solve this problem. I would much prefer to use unmodified code if at 
> all possible.  Do any of you have alternate suggestions?
>
> Thank you for your time.
>
> Doug
>


Does commenting out the LPT enumeration actually help?  There can often be 
differences between debug information printed and whats really going on. 
When you combine various environments the debug info can even come out in 
the wrong order.

I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
I do not think this problem is universal.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Thu Jun  1 14:29:44 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:29:44 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4E38.2060004@dupreeinc.com>

I will give it a try.  One thing to note on this PC is it has no LPT 
Parallel ports.

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
>>Hello,
>>
>>I am still trying to get this startup a little faster so I turned on the 
>>debug of a few of the classes.  The COM ports are scanned really fast and the 
>>delay occurs during the LPT scan.  The console output looks like this:
>>
>>  ...
>>    LPT1
>>    LPT2
>>    LPT3
>>   valid port prefixes:
>>    LPT
>>  LPT1 LPT
>>  1 1
>>  LPT2 LPT
>>  2 2                                                                      * 
>><<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>>  CommPortIdentifier:addPortName(LPT2)
>>  CommPortIdentifier:AddIdentifierToList()
>>  LPT3 LPT
>>  3 3
>>  CommPortIdentifier:addPortName(LPT3)
>>  CommPortIdentifier:AddIdentifierToList()
>>  CommPortIdentifier:AddIdentifierToList() index.next
>>  Leaving registerValidPorts()
>>  Have not implemented native_psmisc_report_owner(PortName)); in
>>  CommPortIdentifier
>>  CommPortIdentifier:getPortIdentifier(COM3)
>>  CommPortIdentifier:open(densConnect, 30000)
>>  RXTXCommDriver:getCommPort(COM3,1)
>>  ...
>>
>>It would seem to me that if I removed the code for port scanning of LPT ports 
>>I could solve this problem. I would much prefer to use unmodified code if at 
>>all possible.  Do any of you have alternate suggestions?
>>
>>Thank you for your time.
>>
>>Doug
>>
>>    
>>
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/dd31fed5/attachment-0013.html

From doug at dupreeinc.com  Thu Jun  1 14:36:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:36:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4FC8.9080106@dupreeinc.com>

Trent,

I commented out the section in RegisterScannedPorts() that adds the 
three LPT ports to the CandidateDeviceNames string array.  The 
application started immediately.  This is probably not the way to do 
this, but it was quick ,dirty, and worked.

It would be nice if there was a way to pole the OS to see if there is 
even a port there, though I guess this is what this code is suppose to do...

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
> ...
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From lynn at swcp.com  Thu Jun  1 14:49:34 2006
From: lynn at swcp.com (lynn@swcp.com)
Date: Thu, 1 Jun 2006 20:49:34 -0000
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>,
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <twig.1149194974.97617@swcp.com>

Perhaps we could add an argument to port enumeration where if not specified,
you get the default behavior that looks for everything.  With a new
constructor that has an argument(or more) you could optionally declare it to
not inspect printer ports.

Existing code would work as it always has.  New code could be smarter.

Lynn



Doug Thistlethwaite <doug at dupreeinc.com> said:

> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
> >On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
> >
> >  
> >
> > ...
> >
> >
> >Does commenting out the LPT enumeration actually help?  There can often be 
> >differences between debug information printed and whats really going on. 
> >When you combine various environments the debug info can even come out in 
> >the wrong order.
> >
> >I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
> >I do not think this problem is universal.
> >
> >--
> >Trent Jarvi
> >tjarvi at qbang.org
> >_______________________________________________
> >Rxtx mailing list
> >Rxtx at qbang.org
> >http://mailman.qbang.org/mailman/listinfo/rxtx
> >
> >
> >  
> >
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



-- 





From jredman at ergotech.com  Thu Jun  1 15:20:20 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 01 Jun 2006 15:20:20 -0600
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
Message-ID: <447F5A14.6010803@ergotech.com>

Doug,

If you specifically request ports, eg:

-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

or
 
-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

Depending upon the version  (Windows is COM1:COM2, etc. I assume).

Does it still enumerate the parallel ports?

Jim

Doug Thistlethwaite wrote:
> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
>> On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>
>>  
>>
>> ...
>>
>>
>> Does commenting out the LPT enumeration actually help?  There can often be 
>> differences between debug information printed and whats really going on. 
>> When you combine various environments the debug info can even come out in 
>> the wrong order.
>>
>> I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>> I do not think this problem is universal.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>>
>>  
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  1 16:49:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:49:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6EF4.7080709@dupreeinc.com>

I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
folder.  I created this file and added the following to the file:

gnu.io.rxtx.SerialPorts=COM3

and I get the following error on the console:
CommPortIdentifier:static initialization()
RXTXCommDriver {}
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
RXTXCommDriver:
    Jar version = RXTX-2.1-7
    native lib Version = RXTX-2.1-7
RXTXCommDriver:initialize()
checking for system-known ports of type 1
checking registry for ports of type 1

RXTXCommDriver:addSpecifiedPorts()
Exception in thread "main" java.lang.ExceptionInInitializerError
    at 
densconnect.SerialConnection.openConnection(SerialConnection.java:136)
    at densconnect.DensTalk.<init>(DensTalk.java:165)
    at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
    at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
    at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
    at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
Caused by: java.lang.NullPointerException
    at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
CommPortIdentifier:addPortName(COM3)
CommPortIdentifier:AddIdentifierToList()
CommPortIdentifier:AddIdentifierToList() null
...


It looks like it  read COM3 from the file, but it had the above 
exception that killed it.  The strange this is this error is from 
RXTXCommDriver initialize function (if statement line):

        OS = System.getProperty("os.name");
                System.out.println("OS NAME: " + OS);
        if(OS.toLowerCase().indexOf("linux") == -1)

OS is returning null, thus the error.

If the file is not present, it scans the ports and reads the OS.

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>Doug Thistlethwaite wrote:
>  
>
>>Trent,
>>
>>I commented out the section in RegisterScannedPorts() that adds the 
>>three LPT ports to the CandidateDeviceNames string array.  The 
>>application started immediately.  This is probably not the way to do 
>>this, but it was quick ,dirty, and worked.
>>
>>It would be nice if there was a way to pole the OS to see if there is 
>>even a port there, though I guess this is what this code is suppose to do...
>>
>>Doug
>>
>>Trent Jarvi wrote:
>>
>>    
>>
>>>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>>
>>> 
>>>
>>>...
>>>
>>>
>>>Does commenting out the LPT enumeration actually help?  There can often be 
>>>differences between debug information printed and whats really going on. 
>>>When you combine various environments the debug info can even come out in 
>>>the wrong order.
>>>
>>>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>>>I do not think this problem is universal.
>>>
>>>--
>>>Trent Jarvi
>>>tjarvi at qbang.org
>>>_______________________________________________
>>>Rxtx mailing list
>>>Rxtx at qbang.org
>>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>>
>>>
>>> 
>>>
>>>      
>>>
>>_______________________________________________
>>Rxtx mailing list
>>Rxtx at qbang.org
>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>    
>>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/bf4cca0e/attachment-0013.html

From doug at dupreeinc.com  Thu Jun  1 16:51:26 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:51:26 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6F6E.5060603@dupreeinc.com>

Jim,

I did not try your suggestion as I do not understand where I would put 
these command line parameters (it that is what they are).  It appears 
that using the properties file should do that same thing...

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>
>  
>


From doug at dupreeinc.com  Thu Jun  1 17:56:19 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 16:56:19 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
Message-ID: <447F7EA3.6050400@dupreeinc.com>

I think there is an error in the registerSpecifiedPorts() method.  When 
I have a gnu.io.rxtx.properties file in the ext directory, this function 
kills the System class  IF I call System.getProperty("os.name") before 
the call  to registerSpecifiedPorts(), it returns the os name, after the 
call, it returns null.  I have not played much with properties, except 
for reading them, so I don't really understand the code.

Doug



From doug at dupreeinc.com  Thu Jun  1 18:11:14 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 17:11:14 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F7EA3.6050400@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com>
Message-ID: <447F8222.3060402@dupreeinc.com>

Ok, I just hacked this thing up and got it to read the 
gnu.io.rxtx.properties file.

I commented out the line:
System.setProperties(p); in the method registerSpecifiedPorts() in 
RXTXCommDriver class.  I really don't understand that much about 
properties, but this call kills the System class.

I used the following in the gnu.io.rxtx.properties file:

gnu.io.rxtx.SerialPorts=COM3
gnu.io.rxtx.ParallelPorts=null

This allows the application to open very quickly without any errors.  
Whomever coded this class or somebody who understands properties should 
look at this method and make sure it is doing what they expect.

Doug




Doug Thistlethwaite wrote:

>I think there is an error in the registerSpecifiedPorts() method.  When 
>I have a gnu.io.rxtx.properties file in the ext directory, this function 
>kills the System class  IF I call System.getProperty("os.name") before 
>the call  to registerSpecifiedPorts(), it returns the os name, after the 
>call, it returns null.  I have not played much with properties, except 
>for reading them, so I don't really understand the code.
>
>Doug
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From tjarvi at qbang.org  Thu Jun  1 18:32:50 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 18:32:50 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F6EF4.7080709@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com> <447F6EF4.7080709@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011831510.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
> folder.  I created this file and added the following to the file:
>
> gnu.io.rxtx.SerialPorts=COM3
>
> and I get the following error on the console:
> CommPortIdentifier:static initialization()
> RXTXCommDriver {}
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
> RXTXCommDriver:
>   Jar version = RXTX-2.1-7
>   native lib Version = RXTX-2.1-7
> RXTXCommDriver:initialize()
> checking for system-known ports of type 1
> checking registry for ports of type 1
>
> RXTXCommDriver:addSpecifiedPorts()
> Exception in thread "main" java.lang.ExceptionInInitializerError
>   at densconnect.SerialConnection.openConnection(SerialConnection.java:136)
>   at densconnect.DensTalk.<init>(DensTalk.java:165)
>   at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
>   at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
>   at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
>   at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
> Caused by: java.lang.NullPointerException
>   at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
> CommPortIdentifier:addPortName(COM3)
> CommPortIdentifier:AddIdentifierToList()
> CommPortIdentifier:AddIdentifierToList() null
> ...
>
>

There is a solution for this bug.

http://bugzilla.qbang.org/show_bug.cgi?id=54

We have been horribly slow at getting the next round of patches in but 
they are comming.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  2 00:58:02 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 08:58:02 +0200
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F8222.3060402@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
Message-ID: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>

Hi Doug,

you wrote in an earlier message, that you would prefer an unchanged  
version. What about simply removing the RXTX parallel lib from the  
ext directory. This does not fix the bug, but it should fix your  
problem.

In general I think it is not a good idea to put the RXTX files in a  
system wide location. Putting the libs in the application folder and  
including the .jar in the application classpath (or application jar)  
is all that is required.

Regards,
Joachim

On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:

> Ok, I just hacked this thing up and got it to read the
> gnu.io.rxtx.properties file.
>
> I commented out the line:
> System.setProperties(p); in the method registerSpecifiedPorts() in
> RXTXCommDriver class.  I really don't understand that much about
> properties, but this call kills the System class.
>
> I used the following in the gnu.io.rxtx.properties file:
>
> gnu.io.rxtx.SerialPorts=COM3
> gnu.io.rxtx.ParallelPorts=null
>
> This allows the application to open very quickly without any errors.
> Whomever coded this class or somebody who understands properties  
> should
> look at this method and make sure it is doing what they expect.
>
> Doug
>
>
>
>
> Doug Thistlethwaite wrote:
>
>> I think there is an error in the registerSpecifiedPorts() method.   
>> When
>> I have a gnu.io.rxtx.properties file in the ext directory, this  
>> function
>> kills the System class  IF I call System.getProperty("os.name")  
>> before
>> the call  to registerSpecifiedPorts(), it returns the os name,  
>> after the
>> call, it returns null.  I have not played much with properties,  
>> except
>> for reading them, so I don't really understand the code.
>>
>> 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 antonio.luis at iscte.pt  Fri Jun  2 02:42:28 2006
From: antonio.luis at iscte.pt (=?ISO-8859-1?Q?Ant=F3nio_Lopes?=)
Date: Fri, 02 Jun 2006 09:42:28 +0100
Subject: [Rxtx] Exception when closing serial port
Message-ID: <447FF9F4.7060209@iscte.pt>

Hello everyone,
I've been using RXTX in a Java application in my Pocket PC.
The communication through the (bluetooth) serial port is working perfectly.

However, when I disconnect the app and close the serial port, sometimes I get 
the following error:

"1149237595000: RXTXPort:close detected bad File Descriptor"

The problem is that after this error occurs, the app is no longer able to 
connect to the serial port and I have to soft-reset the device in order to be 
able to connect to it again.

Any ideas on how to solve this issue?

Any help is appreciated.
Thanks,
regards,
-- 
Ant?nio Lopes

@contact: antonio.luis at iscte.pt
@work: ADETTI - ISCTE
@web: http://antonio.lopes.googlepages.com


From paul.klissner at sun.com  Fri Jun  2 02:44:34 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 01:44:34 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to RXTX
	again
Message-ID: <447FFA72.6040807@sun.com>

After looking into javax.comm 3.1 and what it would take to re-engineer it
to be compatible with RXTX platform libraries, I've decided, due my group's
priorities, complexity of the effort vs. benefit, and limited resources, 
to re-post
javax.comm 2.0 binaries on Sun's software download server, unsupported,
with disclaimers, as it was previously.

I don't think there will be any snags doing this from the standpoint of Sun
management or legality.  I will try to have it  posted there in the next 
week
or two, depending on how fast we can get it pushed through the process.

I'd like to think of this as a stop gap measure... ie. a compromise, 
where, at some
point in the not too distant future RXTX implements their own version of the
Java side of the API, as is normally done by javax.extension porters. 
That way
we avoid uncomfortable dependencies in the future.  And that really is 
the Java
development model.

Since RXTX already has the back-end code, porting the java code shouldn't
be a gargantuan effort at all, and RXTX will be in full control of the 
code top
to bottom. I think RXTX can do at least as good a job as the original 
coder.
Prepping 2.0 to be open sourced is more trouble than it is worth. ie. I 
don't
think the current implementation warrants it.

Ultimately, it would be nice to see someone open up a JSR and re-architect
the comm. API to overcome some of it's current design flaws (ie. be more
adaptable to modern platforms, more pluggable, better defined SPI, better
port ownership handling, etc...). A superior architecture would allow for
better collaboration in the future and better interchangeability of 
components
among projects.

Sun's 3.1 version of javax.comm, which is Sun's currently supported version,
has changes pertaining mostly to Sun platform-specific portmapping and has
some minor additional interactions with our back end code, but generally
has little bearing on RXTX. 

Paul



From joachim at buechse.de  Fri Jun  2 04:00:19 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 12:00:19 +0200
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
	RXTX again
In-Reply-To: <447FFA72.6040807@sun.com>
References: <447FFA72.6040807@sun.com>
Message-ID: <1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>

Good day Paul!

A clean architecture with loadable drivers and reusable code would be  
very beneficial for the future, I think everybody agrees. However  
this could be several years into the future. In the meantime, there  
is a real existing problem with IO support on Java. I have the strong  
feeling that most programmers want to code against one specification  
(javax.comm) and be able to replace the underlying implementation via  
a "plugin" on platforms where the SUN implementation is not  
sufficient. RXTX could be just this plugin (reusing very close to 0%  
of the javax.comm implementation but 100% of its API).

I want to propose an API addition and implementation change that will  
take less then 2 hours of manpower to implement and create a solution  
that can bridge the years until javax.comm has been based on a new  
architecture.

Looking at the javax.comm api at http://java.sun.com/products/ 
javacomm/reference/api/index.html I would like to propose the following:

The only entry point to javax.comm is CommPortIdentifier. It has 3  
static methods plus the constructor.

1) define one additional Interface

public interface CommProvider {
    CommPortIdentifier getPortIdentifier(CommPort port);
    CommPortIdentifier getPortIdentifier(String portName);
    Enumeration getPortIdentifiers ();
}

2) add one method to CommPortIdentifier

   public static setCustomCommProvider (CommProvider);

3) change the three static methods of CommPortIdentifier to dispatch  
to the CommProvider if it is set

4) change the constructor of CommPortIdentifier to

   public CommPortIdentifier(...) {
      if (isProviderSet && this.getClass() ==  
javax.comm.CommPortIdentifier) {
          throw new RuntimeException("illegal creation of  
CommPortIndentifier, custom CommProvider is in use");
      }

5) (this is optional, but would be very nice) automatically set a  
custom CommProvider if it is found on the classpath or defined via a  
system property.


The above 1) - 4) can be implemented in less than 1hour. 5) may take  
another hour. I agree that this is not the most elegant design, but  
it would solve a lot of problems with very little effort. It would  
certainly allow RXTX to move forward. If the javax.comm API needs to  
be redesigned completely this addition will not hurt, as people will  
move to the new API anyway and javax.comm 3.0 was so far never  
included in the main distribution.

Best regards,
Joachim

On 02.06.2006, at 10:44, Paul Klissner wrote:

> After looking into javax.comm 3.1 and what it would take to re- 
> engineer it
> to be compatible with RXTX platform libraries, I've decided, due my  
> group's
> priorities, complexity of the effort vs. benefit, and limited  
> resources,
> to re-post
> javax.comm 2.0 binaries on Sun's software download server,  
> unsupported,
> with disclaimers, as it was previously.
>
> I don't think there will be any snags doing this from the  
> standpoint of Sun
> management or legality.  I will try to have it  posted there in the  
> next
> week
> or two, depending on how fast we can get it pushed through the  
> process.
>
> I'd like to think of this as a stop gap measure... ie. a compromise,
> where, at some
> point in the not too distant future RXTX implements their own  
> version of the
> Java side of the API, as is normally done by javax.extension porters.
> That way
> we avoid uncomfortable dependencies in the future.  And that really is
> the Java
> development model.
>
> Since RXTX already has the back-end code, porting the java code  
> shouldn't
> be a gargantuan effort at all, and RXTX will be in full control of the
> code top
> to bottom. I think RXTX can do at least as good a job as the original
> coder.
> Prepping 2.0 to be open sourced is more trouble than it is worth.  
> ie. I
> don't
> think the current implementation warrants it.
>
> Ultimately, it would be nice to see someone open up a JSR and re- 
> architect
> the comm. API to overcome some of it's current design flaws (ie. be  
> more
> adaptable to modern platforms, more pluggable, better defined SPI,  
> better
> port ownership handling, etc...). A superior architecture would  
> allow for
> better collaboration in the future and better interchangeability of
> components
> among projects.
>
> Sun's 3.1 version of javax.comm, which is Sun's currently supported  
> version,
> has changes pertaining mostly to Sun platform-specific portmapping  
> and has
> some minor additional interactions with our back end code, but  
> generally
> has little bearing on RXTX.
>
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Fri Jun  2 09:10:13 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Fri, 2 Jun 2006 09:10:13 -0600 (MDT)
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <447FFA72.6040807@sun.com>
References: <447FFA72.6040807@sun.com>
Message-ID: <Pine.LNX.4.61.0606020906400.15971@www>

On Fri, 2 Jun 2006, Paul Klissner wrote:

> After looking into javax.comm 3.1 and what it would take to re-engineer it
> to be compatible with RXTX platform libraries, I've decided, due my group's
> priorities, complexity of the effort vs. benefit, and limited resources,
> to re-post
> javax.comm 2.0 binaries on Sun's software download server, unsupported,
> with disclaimers, as it was previously.
>

Hi Paul

To address users' immediate needs, we can release rxtx 2.0-7 (final) to 
match the 2.0 binaries from Sun when they are offered for download.

We can discuss potential long term solutions after that.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Fri Jun  2 10:20:09 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 02 Jun 2006 09:20:09 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
	<9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
Message-ID: <44806539.8080902@dupreeinc.com>

Thanks for the suggestion, I will give it a try.

Doug

Joachim Buechse wrote:

>Hi Doug,
>
>you wrote in an earlier message, that you would prefer an unchanged  
>version. What about simply removing the RXTX parallel lib from the  
>ext directory. This does not fix the bug, but it should fix your  
>problem.
>
>In general I think it is not a good idea to put the RXTX files in a  
>system wide location. Putting the libs in the application folder and  
>including the .jar in the application classpath (or application jar)  
>is all that is required.
>
>Regards,
>Joachim
>
>On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:
>
>  
>
>>Ok, I just hacked this thing up and got it to read the
>>gnu.io.rxtx.properties file.
>>
>>I commented out the line:
>>System.setProperties(p); in the method registerSpecifiedPorts() in
>>RXTXCommDriver class.  I really don't understand that much about
>>properties, but this call kills the System class.
>>
>>I used the following in the gnu.io.rxtx.properties file:
>>
>>gnu.io.rxtx.SerialPorts=COM3
>>gnu.io.rxtx.ParallelPorts=null
>>
>>This allows the application to open very quickly without any errors.
>>Whomever coded this class or somebody who understands properties  
>>should
>>look at this method and make sure it is doing what they expect.
>>
>>Doug
>>
>>
>>
>>
>>Doug Thistlethwaite wrote:
>>
>>    
>>
>>>I think there is an error in the registerSpecifiedPorts() method.   
>>>When
>>>I have a gnu.io.rxtx.properties file in the ext directory, this  
>>>function
>>>kills the System class  IF I call System.getProperty("os.name")  
>>>before
>>>the call  to registerSpecifiedPorts(), it returns the os name,  
>>>after the
>>>call, it returns null.  I have not played much with properties,  
>>>except
>>>for reading them, so I don't really understand the code.
>>>
>>>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
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060602/c8892a46/attachment-0013.html

From paul.klissner at sun.com  Fri Jun  2 12:09:26 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 11:09:26 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
Message-ID: <44807ED6.8000903@sun.com>

Joachim Buechse wrote:
> Good day Paul!
>
> A clean architecture with loadable drivers and reusable code would be  
> very beneficial for the future, I think everybody agrees. However  
> this could be several years into the future. In the meantime, there  
> is a real existing problem with IO support on Java. I have the strong  
> feeling that most programmers want to code against one specification  
> (javax.comm) and be able to replace the underlying implementation via  
> a "plugin" on platforms where the SUN implementation is not  
> sufficient. RXTX could be just this plugin (reusing very close to 0%  
> of the javax.comm implementation but 100% of its API).
>
> I want to propose an API addition and implementation change that will  
> take less then 2 hours of manpower to implement and create a solution  
> that can bridge the years until javax.comm has been based on a new  
> architecture.
>
> Looking at the javax.comm api at http://java.sun.com/products/ 
> javacomm/reference/api/index.html I would like to propose the following:
>
> The only entry point to javax.comm is CommPortIdentifier. It has 3  
> static methods plus the constructor.
>
> 1) define one additional Interface
>
> public interface CommProvider {
>     CommPortIdentifier getPortIdentifier(CommPort port);
>     CommPortIdentifier getPortIdentifier(String portName);
>     Enumeration getPortIdentifiers ();
> }
>
> 2) add one method to CommPortIdentifier
>
>    public static setCustomCommProvider (CommProvider);
>
> 3) change the three static methods of CommPortIdentifier to dispatch  
> to the CommProvider if it is set
>
> 4) change the constructor of CommPortIdentifier to
>
>    public CommPortIdentifier(...) {
>       if (isProviderSet && this.getClass() ==  
> javax.comm.CommPortIdentifier) {
>           throw new RuntimeException("illegal creation of  
> CommPortIndentifier, custom CommProvider is in use");
>       }
>
> 5) (this is optional, but would be very nice) automatically set a  
> custom CommProvider if it is found on the classpath or defined via a  
> system property.
>
>
> The above 1) - 4) can be implemented in less than 1hour. 5) may take  
> another hour. I agree that this is not the most elegant design, but  
> it would solve a lot of problems with very little effort. It would  
> certainly allow RXTX to move forward. If the javax.comm API needs to  
> be redesigned completely this addition will not hurt, as people will  
> move to the new API anyway and javax.comm 3.0 was so far never  
> included in the main distribution.
>
> Best regards,
> Joachi
I'm afraid modifying the interface classes isn't my call.  There was 
actually
a TCK written and one of the tests was to ensure that the interface classes
match the spec.  Thus my hands have already been tied since this project
was essentially grandfathered into the JCP.

That's why we need to open a new JSR and find someone who wants
to be the spec lead, and go in with a new reference implementation.
I'm not sure why it would have to take years, since this isn't bleeding edge
technology and there are only so many things that can be done with it,
and we already have practical experience about many functional aspects
that we could cite precedence on.

As it becomes clear that the specification is being accepted completely
or by-and-large by the community, nothing would stop people from
starting adapting to the new API (using the reference implementation or
porting it) and using it in their projects prior to it's final community and
JCP approval, since approval is required only to make it official and
get the "100% pure java" certification for platform ports.

You have one idea already.  Why don't you implement it, solicit some
design feedback from Sun and the RXTX, and create a functional
implementation that addresses the needs of the community, then
we can document it and open a JSR.  That's it.  It should march through
the approval stages reasonably quickly I would imagine, and meantime
RXTX could start using it.

Paul




From doug at dupreeinc.com  Fri Jun  2 12:45:01 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 02 Jun 2006 11:45:01 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
	<9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
Message-ID: <4480872D.6000605@dupreeinc.com>

Joachim,

Thank you for the suggestion.  I restored the jar file to the one I 
downloaded, moved the dll files into the project directory, and added 
the jar to the classpath.  The SerialDemo program that was included with 
the Sun commapi started in 12 seconds instead of the 58 seconds when the 
parallel dll is present.  I did get the startup time to about a second 
by modifying the java code and adding the properties file but this is 
probably not a good idea.

Doug

Joachim Buechse wrote:

>Hi Doug,
>
>you wrote in an earlier message, that you would prefer an unchanged  
>version. What about simply removing the RXTX parallel lib from the  
>ext directory. This does not fix the bug, but it should fix your  
>problem.
>
>In general I think it is not a good idea to put the RXTX files in a  
>system wide location. Putting the libs in the application folder and  
>including the .jar in the application classpath (or application jar)  
>is all that is required.
>
>Regards,
>Joachim
>
>On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:
>
>  
>
>>Ok, I just hacked this thing up and got it to read the
>>gnu.io.rxtx.properties file.
>>
>>I commented out the line:
>>System.setProperties(p); in the method registerSpecifiedPorts() in
>>RXTXCommDriver class.  I really don't understand that much about
>>properties, but this call kills the System class.
>>
>>I used the following in the gnu.io.rxtx.properties file:
>>
>>gnu.io.rxtx.SerialPorts=COM3
>>gnu.io.rxtx.ParallelPorts=null
>>
>>This allows the application to open very quickly without any errors.
>>Whomever coded this class or somebody who understands properties  
>>should
>>look at this method and make sure it is doing what they expect.
>>
>>Doug
>>
>>
>>
>>
>>Doug Thistlethwaite wrote:
>>
>>    
>>
>>>I think there is an error in the registerSpecifiedPorts() method.   
>>>When
>>>I have a gnu.io.rxtx.properties file in the ext directory, this  
>>>function
>>>kills the System class  IF I call System.getProperty("os.name")  
>>>before
>>>the call  to registerSpecifiedPorts(), it returns the os name,  
>>>after the
>>>call, it returns null.  I have not played much with properties,  
>>>except
>>>for reading them, so I don't really understand the code.
>>>
>>>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
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060602/3c0e420f/attachment-0013.html

From joachim at buechse.de  Fri Jun  2 13:46:36 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 21:46:36 +0200
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
	RXTX again
In-Reply-To: <44807ED6.8000903@sun.com>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
	<44807ED6.8000903@sun.com>
Message-ID: <6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>

Hello Paul,

of course, the basic change I suggested could be done "hidden".  The  
CommProvider interface could live somewhere in sun.xyz.*
The setCustomCommProvider method would not be in CommPortIdentifier  
but also somewhere in sun.xyz.* This would be an unofficial feature,  
the official interface stays exactly the same. However RXTX (and  
others) could access the hidden interface.

Don't get me wrong, I don't want to harass you into making changes  
you don't like (which probably wouldn't work anyway;-). But I'm a  
long time Java programmer and seeing the state of cross platform  
serial support for Java makes me feel really sad. In fact, when I  
started to look into Java serial port programming some months ago I  
was very surprised that javax.comm never made it into the JDK.

I'm sorry that I did not contribute my feedback to the JSR for  
javax.comm 3.0. However at the time I didn't do serial port  
programming in Java. I agree that a new JSR should be opened - I'm  
not an expert on JSRs or the JCP process, but from looking quickly  
over the progress of some JSRs I would be very surprised if we can  
have a new version in less then a year. In the meanwhile some people  
will start using javax.comm 3.0 (which can not be supported by RXTX),  
some will use javax.comm 2.0 (which means the 2.0.7 release of RXTX  
still needs to be maintained). This may get even worse if eg Apple  
decides to port and include javax.comm 3.0 at which point it may get  
very tricky to write a cross platform Java application.

All of this simply means, that we are loosing a lot of man-power that  
could otherwise be invested in building a clean solution and/or to  
add features that are becoming more and more important (USB events...).

In the automation / machine control universe Java makes a lot of  
sense. Right now many people are migrating to Linux or from  
propietary systems (even DOS) to Windows. Writing the control/ 
configuration applications in Java is the kings way to unify the code  
base.

Best regards,
Joachim


On 02.06.2006, at 20:09, Paul Klissner wrote:

> Joachim Buechse wrote:
>> Good day Paul!
>>
>> A clean architecture with loadable drivers and reusable code would be
>> very beneficial for the future, I think everybody agrees. However
>> this could be several years into the future. In the meantime, there
>> is a real existing problem with IO support on Java. I have the strong
>> feeling that most programmers want to code against one specification
>> (javax.comm) and be able to replace the underlying implementation via
>> a "plugin" on platforms where the SUN implementation is not
>> sufficient. RXTX could be just this plugin (reusing very close to 0%
>> of the javax.comm implementation but 100% of its API).
>>
>> I want to propose an API addition and implementation change that will
>> take less then 2 hours of manpower to implement and create a solution
>> that can bridge the years until javax.comm has been based on a new
>> architecture.
>>
>> Looking at the javax.comm api at http://java.sun.com/products/
>> javacomm/reference/api/index.html I would like to propose the  
>> following:
>>
>> The only entry point to javax.comm is CommPortIdentifier. It has 3
>> static methods plus the constructor.
>>
>> 1) define one additional Interface
>>
>> public interface CommProvider {
>>     CommPortIdentifier getPortIdentifier(CommPort port);
>>     CommPortIdentifier getPortIdentifier(String portName);
>>     Enumeration getPortIdentifiers ();
>> }
>>
>> 2) add one method to CommPortIdentifier
>>
>>    public static setCustomCommProvider (CommProvider);
>>
>> 3) change the three static methods of CommPortIdentifier to dispatch
>> to the CommProvider if it is set
>>
>> 4) change the constructor of CommPortIdentifier to
>>
>>    public CommPortIdentifier(...) {
>>       if (isProviderSet && this.getClass() ==
>> javax.comm.CommPortIdentifier) {
>>           throw new RuntimeException("illegal creation of
>> CommPortIndentifier, custom CommProvider is in use");
>>       }
>>
>> 5) (this is optional, but would be very nice) automatically set a
>> custom CommProvider if it is found on the classpath or defined via a
>> system property.
>>
>>
>> The above 1) - 4) can be implemented in less than 1hour. 5) may take
>> another hour. I agree that this is not the most elegant design, but
>> it would solve a lot of problems with very little effort. It would
>> certainly allow RXTX to move forward. If the javax.comm API needs to
>> be redesigned completely this addition will not hurt, as people will
>> move to the new API anyway and javax.comm 3.0 was so far never
>> included in the main distribution.
>>
>> Best regards,
>> Joachi
> I'm afraid modifying the interface classes isn't my call.  There was
> actually
> a TCK written and one of the tests was to ensure that the interface  
> classes
> match the spec.  Thus my hands have already been tied since this  
> project
> was essentially grandfathered into the JCP.
>
> That's why we need to open a new JSR and find someone who wants
> to be the spec lead, and go in with a new reference implementation.
> I'm not sure why it would have to take years, since this isn't  
> bleeding edge
> technology and there are only so many things that can be done with it,
> and we already have practical experience about many functional aspects
> that we could cite precedence on.
>
> As it becomes clear that the specification is being accepted  
> completely
> or by-and-large by the community, nothing would stop people from
> starting adapting to the new API (using the reference  
> implementation or
> porting it) and using it in their projects prior to it's final  
> community and
> JCP approval, since approval is required only to make it official and
> get the "100% pure java" certification for platform ports.
>
> You have one idea already.  Why don't you implement it, solicit some
> design feedback from Sun and the RXTX, and create a functional
> implementation that addresses the needs of the community, then
> we can document it and open a JSR.  That's it.  It should march  
> through
> the approval stages reasonably quickly I would imagine, and meantime
> RXTX could start using it.
>
> Paul
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From paul.klissner at sun.com  Fri Jun  2 14:38:49 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 13:38:49 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
	<44807ED6.8000903@sun.com>
	<6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>
Message-ID: <4480A1D9.5060106@sun.com>

Joachim Buechse wrote:
> Hello Paul,
>
> of course, the basic change I suggested could be done "hidden".  The  
> CommProvider interface could live somewhere in sun.xyz.*
> The setCustomCommProvider method would not be in CommPortIdentifier  
> but also somewhere in sun.xyz.* This would be an unofficial feature,  
> the official interface stays exactly the same. However RXTX (and  
> others) could access the hidden interface.
>
> Don't get me wrong, I don't want to harass you into making changes  
> you don't like (which probably wouldn't work anyway;-). But I'm a  
> long time Java programmer and seeing the state of cross platform  
> serial support for Java makes me feel really sad. In fact, when I  
> started to look into Java serial port programming some months ago I  
> was very surprised that javax.comm never made it into the JDK.
>
> I'm sorry that I did not contribute my feedback to the JSR for  
> javax.comm 3.0. 
There was no JSR for 3.0, because we didn't have the resources to make 
the commitment.
Yet Sun needed to add support for platform-dependent port name mapping, 
which had to
be done 'under the hood', since the API isn't designed to handle that in 
a pluggable way.
But these quick fixes aren't the right approach, they just kick the dog 
down the road,
setting bad precedent, inviting confusion and more intractable problems 
(such as the
one plaguing us now).

My changes could have been layered better, it was a trade off between 
achieving an
ideal architecture, trying to find internal reviewers, and meet the 
needs of big customers
in a timely way.  Thus my namespace changes collided with RXTX's 
dependencies.
I was unaware of Jagane's rogue agreement made with the RXTX community 7 
years ago,
before Jagane left Sun.  I think this was a wag-the-dog situation.

Now it is time to do it right, and I don't think it is going to be as 
much trouble as people
some people fear. If RXTX wants to sponsor the JSR and seed a new spec, 
Sun can join
the Expert Group.  And we'd be largely in agreement, since we're not 
talking about
humongous changes, and looking for mutually beneficial changes. The core 
API is already
largely proved and tested.
> However at the time I didn't do serial port  
> programming in Java. I agree that a new JSR should be opened - I'm  
> not an expert on JSRs or the JCP process, but from looking quickly  
> over the progress of some JSRs I would be very surprised if we can  
> have a new version in less then a year. 
*Approved*  But that doesn't mean the spec couldn't be 99.9% stable 
before that.  Once
the delta rate declines and changes approach nil, people could start 
adapting to the API in
advance of formal approval.   It isn't going to be drawn out like 
javax.usb, which was new
technology, a very complex API, and involved precedent setting corporate 
disputes and
policy issues to resolve.

> In the meanwhile some people  
> will start using javax.comm 3.0 (which can not be supported by RXTX),  
> some will use javax.comm 2.0 (which means the 2.0.7 release of RXTX  
> still needs to be maintained). This may get even worse if eg Apple  
> decides to port and include javax.comm 3.0 at which point it may get  
> very tricky to write a cross platform Java application.
>   
The interfaces haven't changed since 1.0.  If we open a JSR ,we can 
contact Apple and
allow them to be on the E.G., if they want.  That might make the JSR a 
bit more drawn out,
but then we'd arrive ultimately arrive at a best-of-all-worlds API that 
most people would
accept, perhaps forever, and arrive at a respectable set of compromises.

-Paul

> All of this simply means, that we are loosing a lot of man-power that  
> could otherwise be invested in building a clean solution and/or to  
> add features that are becoming more and more important (USB events...).
>
> In the automation / machine control universe Java makes a lot of  
> sense. Right now many people are migrating to Linux or from  
> propietary systems (even DOS) to Windows. Writing the control/ 
> configuration applications in Java is the kings way to unify the code  
> base.
>
> Best regards,
> Joachim
>
>
> On 02.06.2006, at 20:09, Paul Klissner wrote:
>
>   
>> Joachim Buechse wrote:
>>     
>>> Good day Paul!
>>>
>>> A clean architecture with loadable drivers and reusable code would be
>>> very beneficial for the future, I think everybody agrees. However
>>> this could be several years into the future. In the meantime, there
>>> is a real existing problem with IO support on Java. I have the strong
>>> feeling that most programmers want to code against one specification
>>> (javax.comm) and be able to replace the underlying implementation via
>>> a "plugin" on platforms where the SUN implementation is not
>>> sufficient. RXTX could be just this plugin (reusing very close to 0%
>>> of the javax.comm implementation but 100% of its API).
>>>
>>> I want to propose an API addition and implementation change that will
>>> take less then 2 hours of manpower to implement and create a solution
>>> that can bridge the years until javax.comm has been based on a new
>>> architecture.
>>>
>>> Looking at the javax.comm api at http://java.sun.com/products/
>>> javacomm/reference/api/index.html I would like to propose the  
>>> following:
>>>
>>> The only entry point to javax.comm is CommPortIdentifier. It has 3
>>> static methods plus the constructor.
>>>
>>> 1) define one additional Interface
>>>
>>> public interface CommProvider {
>>>     CommPortIdentifier getPortIdentifier(CommPort port);
>>>     CommPortIdentifier getPortIdentifier(String portName);
>>>     Enumeration getPortIdentifiers ();
>>> }
>>>
>>> 2) add one method to CommPortIdentifier
>>>
>>>    public static setCustomCommProvider (CommProvider);
>>>
>>> 3) change the three static methods of CommPortIdentifier to dispatch
>>> to the CommProvider if it is set
>>>
>>> 4) change the constructor of CommPortIdentifier to
>>>
>>>    public CommPortIdentifier(...) {
>>>       if (isProviderSet && this.getClass() ==
>>> javax.comm.CommPortIdentifier) {
>>>           throw new RuntimeException("illegal creation of
>>> CommPortIndentifier, custom CommProvider is in use");
>>>       }
>>>
>>> 5) (this is optional, but would be very nice) automatically set a
>>> custom CommProvider if it is found on the classpath or defined via a
>>> system property.
>>>
>>>
>>> The above 1) - 4) can be implemented in less than 1hour. 5) may take
>>> another hour. I agree that this is not the most elegant design, but
>>> it would solve a lot of problems with very little effort. It would
>>> certainly allow RXTX to move forward. If the javax.comm API needs to
>>> be redesigned completely this addition will not hurt, as people will
>>> move to the new API anyway and javax.comm 3.0 was so far never
>>> included in the main distribution.
>>>
>>> Best regards,
>>> Joachi
>>>       
>> I'm afraid modifying the interface classes isn't my call.  There was
>> actually
>> a TCK written and one of the tests was to ensure that the interface  
>> classes
>> match the spec.  Thus my hands have already been tied since this  
>> project
>> was essentially grandfathered into the JCP.
>>
>> That's why we need to open a new JSR and find someone who wants
>> to be the spec lead, and go in with a new reference implementation.
>> I'm not sure why it would have to take years, since this isn't  
>> bleeding edge
>> technology and there are only so many things that can be done with it,
>> and we already have practical experience about many functional aspects
>> that we could cite precedence on.
>>
>> As it becomes clear that the specification is being accepted  
>> completely
>> or by-and-large by the community, nothing would stop people from
>> starting adapting to the new API (using the reference  
>> implementation or
>> porting it) and using it in their projects prior to it's final  
>> community and
>> JCP approval, since approval is required only to make it official and
>> get the "100% pure java" certification for platform ports.
>>
>> You have one idea already.  Why don't you implement it, solicit some
>> design feedback from Sun and the RXTX, and create a functional
>> implementation that addresses the needs of the community, then
>> we can document it and open a JSR.  That's it.  It should march  
>> through
>> the approval stages reasonably quickly I would imagine, and meantime
>> RXTX could start using it.
>>
>> Paul
>>
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at 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  Sat Jun  3 18:15:24 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 18:15:24 -0600 (MDT)
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
Message-ID: <Pine.LNX.4.61.0606031715100.10890@www>


The attached patch allows baud rates of 14400, 28800, 128000 and 256000.

That was my goal.

[import standard disclaimer]

But I took some time to look a little further.  I got custom baud rates 
working enough that someone (perhaps me) can properly fix them in the 
future.  Proof of concept.

As an undocumented bonus, you can toss random baudrates (say 1953), at the 
API and it will set it to something close to that on windows and linux. 
Solaris should say the baud rate is not supported but I have not tested it 
yet.  Mac OS X behavior is unknown at this point.  Just dont expect 
correct behavior at ~8192-9009 baudrates or baudrates less than 20 on 
windows; these baud rates overlap with defines in win32termios.h.  I 
conveniently closed my eyes there.  Try another value close.  On Linux, a 
baud base and divisor are guestimated and set.  On windows, we wave pixie 
dust over the kernel driver and hope.  Do not expect pixie dust and 
guestimates to be the same on windows and linux.  They may well round to 
different values in yet to be tested ways.  There are only so many 
divisors.  If it isn't working, try a little higher or lower.

In the example of 1953 for instance, there is no divisor for commodity 
hardware that comes to that baudrate.  We just come close on one side or 
the other.  If tools tell you they got 1953 exactly, the tools may be 
questionable and just reading values not directly related to the actual 
hardware settings.

These fixes have been tested on Linux and Windows while using an 
oscilloscope to confirm they change relative to known baudrates at 9600, 
14400*, 19200, 28800* (and 1800, 1953** and 2400).

* = previously unsupported.
** = still not supported but probably works from what I saw.

There could be future discussion in this area.  For now this is working 
for almost all unusual baud rate demands.  Cleaning up the custom baud 
rate should be easier with a working starting point.  Baud bases other 
than 128000 have not been characterized.  Yes.. this overlapps with two of 
the baud rates enabled.

Feedback and ideas are welcome.

--
Trent Jarvi
tjarvi at qbang.org
-------------- next part --------------
Index: SerialImp.c
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v
retrieving revision 1.46.2.187
diff -u -r1.46.2.187 SerialImp.c
--- SerialImp.c	29 Jan 2006 22:19:04 -0000	1.46.2.187
+++ SerialImp.c	3 Jun 2006 23:12:40 -0000
@@ -793,6 +793,19 @@
 		result &= ~TIOCM_DTR;
 		ioctl( fd, TIOCMSET, &result );
 	}
+	/*
+	   B38400 is a special case in Linux for custom baud rates.
+
+	   We just treat this as a custom speed for now.  If you take this ifdef
+	   out and select baud rates 38400 then 28800 then 38400, you will get
+	   a final baud rate of 28800 because you did not update the divisor.
+
+	   See the next ifdef below for the divisor.
+	*/
+#if defined(TIOCGSERIAL)
+	if ( cspeed == B38400 )
+		cspeed = 38400;
+#endif /* TIOCGSERIAL */
 	if(     cfsetispeed( &ttyset, cspeed ) < 0 ||
 		cfsetospeed( &ttyset, cspeed ) < 0 )
 	{
@@ -814,6 +827,7 @@
 		*/
 
 #if defined(TIOCGSERIAL)
+		ioctl( fd, TIOCGSERIAL, &sstruct );
 		sstruct.custom_divisor = ( sstruct.baud_base/cspeed );
 		cspeed = B38400;
 #endif /* TIOCGSERIAL */
@@ -827,7 +841,7 @@
 #if defined(TIOCSSERIAL)
 		/*  It is assumed Win32 does this for us */
 		if (	sstruct.baud_base < 1 ||
-			ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
+		ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
 		{
 			return( 1 );
 		}
Index: termios.c
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v
retrieving revision 1.9.2.56
diff -u -r1.9.2.56 termios.c
--- termios.c	16 Jan 2006 02:50:32 -0000	1.9.2.56
+++ termios.c	3 Jun 2006 23:12:40 -0000
@@ -323,8 +323,8 @@
 		case CBR_3500000:	return( B3500000 );
 		case CBR_4000000:	return( B4000000 );
 		default:
-			set_errno(EINVAL );
-			return -1;
+			/* assume custom baudrate */
+			return( Baud );
 	}
 }
 
@@ -361,12 +361,13 @@
 		case B9600:	ret = CBR_9600;		break;
 		case B14400:	ret = CBR_14400;	break;
 		case B19200:	ret = CBR_19200;	break;
+		case B28800:	ret = CBR_28800;	break;
 		case B38400:	ret = CBR_38400;	break;
 		case B57600:	ret = CBR_57600;	break;
 		case B115200:	ret = CBR_115200;	break;
 		case B128000:	ret = CBR_128000;	break;
-		case B256000: 	ret = CBR_256000;	break;
 		case B230400:	ret = CBR_230400;	break;
+		case B256000: 	ret = CBR_256000;	break;
 		case B460800:	ret = CBR_460800;	break;
 		case B500000:	ret = CBR_500000;	break;
 		case B576000:	ret = CBR_576000;	break;
@@ -381,10 +382,8 @@
 		case B4000000:	ret = CBR_4000000;	break;
 	
 		default:
-			fprintf( stderr, "B_to_CBR: invalid baudrate: %#o\n",
-				Baud );
-			set_errno( EINVAL );
-			return -1;
+			/* assume custom baudrate */
+			return Baud;
 	}
 	LEAVE( "B_to_CBR" );
 	return ret;
@@ -708,12 +707,9 @@
 	ENTER( "init_serial_struct" );
 
 	/*
-	FIXME
-
-	This needs to use inb() to read the actual baud_base
-	and divisor from the UART registers.  Question is how
-	far do we take this?
-
+	use of custom_divisor and baud_base requires access to
+	kernel space.  The kernel does try its best if you just
+	toss a baud rate at it though.
 	*/
 
 	sstruct->custom_divisor = 0;
@@ -1678,16 +1674,17 @@
 {
 	char message[80];
 	ENTER( "cfsetospeed" );
+	/* clear baudrate */
+	s_termios->c_cflag &= ~CBAUD;
 	if ( speed & ~CBAUD )
 	{
 		sprintf( message, "cfsetospeed: not speed: %#o\n", speed );
 		report( message );
-		return 0;
+		/* continue assuming its a custom baudrate */
+		s_termios->c_cflag |= B38400;  /* use 38400 during custom */
+		s_termios->c_cflag |= CBAUDEX; /* use CBAUDEX for custom */
 	}
-	s_termios->c_ispeed = s_termios->c_ospeed = speed;
-	/* clear baudrate */
-	s_termios->c_cflag &= ~CBAUD;
-	if( speed )
+	else if( speed )
 	{
 		s_termios->c_cflag |= speed;
 	}
@@ -1696,6 +1693,7 @@
 		/* PC blows up with speed 0 handled in Java */
 		s_termios->c_cflag |= B9600;
 	}
+	s_termios->c_ispeed = s_termios->c_ospeed = speed;
 	LEAVE( "cfsetospeed" );
 	return 1;
 }
@@ -1767,25 +1765,6 @@
 }
 
 /*----------------------------------------------------------
-serial_struct_to_DCB()
-
-   accept:      
-   perform:     
-   return:      
-   exceptions:  
-   win32api:     None
-   comments:    
-----------------------------------------------------------*/
-int serial_struct_to_DCB( struct serial_struct *sstruct, DCB *dcb )
-{
-	/* 5 Baud rate fix
-	sstruct.baud_base
-	sstruct.custom_divisor = ( sstruct.baud_base/cspeed );
-	*/
-	return(0);
-}
-
-/*----------------------------------------------------------
 termios_to_DCB()
 
    accept:      
@@ -1798,7 +1777,8 @@
 int termios_to_DCB( struct termios *s_termios, DCB *dcb )
 {
 	ENTER( "termios_to_DCB" );
-	s_termios->c_ispeed = s_termios->c_ospeed = s_termios->c_cflag & CBAUD;
+	if ( !(s_termios->c_cflag & CBAUDEX) )
+		s_termios->c_ispeed = s_termios->c_ospeed = s_termios->c_cflag & CBAUD;
 	dcb->BaudRate        = B_to_CBR( s_termios->c_ispeed );
 	dcb->ByteSize = termios_to_bytesize( s_termios->c_cflag );
 
@@ -2863,11 +2843,6 @@
 			GetCommState( index->hComm, dcb );
 
 			index->sstruct = va_arg( ap, struct serial_struct * );
-			if ( serial_struct_to_DCB( index->sstruct, dcb ) < 0 )
-			{
-				va_end( ap );
-				return -1;
-			}
 
 			report( "TIOCSSERIAL\n" );
 			free(dcb);
Index: win32termios.h
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v
retrieving revision 1.5.2.28
diff -u -r1.5.2.28 win32termios.h
--- win32termios.h	30 Jun 2005 20:23:26 -0000	1.5.2.28
+++ win32termios.h	3 Jun 2006 23:12:40 -0000
@@ -279,7 +279,7 @@
 #define XTABS	01000000 /* Hmm.. Linux/i386 considers this part of TABDLY.. */
 
 /* c_cflag bit meaning */
-# define CBAUD	0010017
+#define  CBAUD  0030017
 #define  B0	0000000		/* hang up */
 #define  B50	0000001
 #define  B75	0000002
@@ -312,13 +312,16 @@
 #define  B3500000 0010016
 #define  B4000000 0010017
 
-/* glue for unsupported linux speeds see also SerialImp.h */
-/* hosed */
-
-#define B14400		1010001
-#define B28800		1010002
-#define B128000		1010003
-#define B256000		1010004
+/*
+	glue for unsupported linux speeds see also SerialImp.h 
+	custom baud rates around 8192-9000 will not work because
+	of these.
+*/
+
+#define B14400		0020001
+#define B28800		0020002
+#define B128000		0020003
+#define B256000		0020004
 
 #define EXTA B19200
 #define EXTB B38400
@@ -356,8 +359,10 @@
 
 /* glue for unsupported windows speeds */
 
-#define CBR_230400	230400
 #define CBR_28800	28800
+#define CBR_128000	128000
+#define CBR_230400	230400
+#define CBR_256000	256000
 #define CBR_460800	460800
 #define CBR_500000	500000
 #define CBR_576000	576000

From impakt01 at optusnet.com.au  Sat Jun  3 18:30:37 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 10:30:37 +1000
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
In-Reply-To: <Pine.LNX.4.61.0606031715100.10890@www>
Message-ID: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>

Hi Trent,
I'd love to try the patch but I can't get the latest build compiling, only
pre16. 

Can you attach the rxtxSerial.dll file with this patch?

Also, I hardcoded 1953 in a couple more places last night on pre16 and it
managed to open the port at the right speed, but stopped receiving anything
after 100-150 bytes, even though more data was getting sent to the port.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 10:15 AM
To: rxtx at qbang.org
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.


The attached patch allows baud rates of 14400, 28800, 128000 and 256000.

That was my goal.

[import standard disclaimer]

But I took some time to look a little further.  I got custom baud rates 
working enough that someone (perhaps me) can properly fix them in the 
future.  Proof of concept.

As an undocumented bonus, you can toss random baudrates (say 1953), at the 
API and it will set it to something close to that on windows and linux. 
Solaris should say the baud rate is not supported but I have not tested it 
yet.  Mac OS X behavior is unknown at this point.  Just dont expect 
correct behavior at ~8192-9009 baudrates or baudrates less than 20 on 
windows; these baud rates overlap with defines in win32termios.h.  I 
conveniently closed my eyes there.  Try another value close.  On Linux, a 
baud base and divisor are guestimated and set.  On windows, we wave pixie 
dust over the kernel driver and hope.  Do not expect pixie dust and 
guestimates to be the same on windows and linux.  They may well round to 
different values in yet to be tested ways.  There are only so many 
divisors.  If it isn't working, try a little higher or lower.

In the example of 1953 for instance, there is no divisor for commodity 
hardware that comes to that baudrate.  We just come close on one side or 
the other.  If tools tell you they got 1953 exactly, the tools may be 
questionable and just reading values not directly related to the actual 
hardware settings.

These fixes have been tested on Linux and Windows while using an 
oscilloscope to confirm they change relative to known baudrates at 9600, 
14400*, 19200, 28800* (and 1800, 1953** and 2400).

* = previously unsupported.
** = still not supported but probably works from what I saw.

There could be future discussion in this area.  For now this is working 
for almost all unusual baud rate demands.  Cleaning up the custom baud 
rate should be easier with a working starting point.  Baud bases other 
than 128000 have not been characterized.  Yes.. this overlapps with two of 
the baud rates enabled.

Feedback and ideas are welcome.

--
Trent Jarvi
tjarvi at qbang.org



From tjarvi at qbang.org  Sat Jun  3 19:05:11 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 19:05:11 -0600 (MDT)
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
In-Reply-To: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>
References: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606031840400.10890@www>

On Sun, 4 Jun 2006, Daren wrote:

> Hi Trent,
> I'd love to try the patch but I can't get the latest build compiling, only
> pre16.
>
> Can you attach the rxtxSerial.dll file with this patch?
>
> Also, I hardcoded 1953 in a couple more places last night on pre16 and it
> managed to open the port at the right speed, but stopped receiving anything
> after 100-150 bytes, even though more data was getting sent to the port.
>


ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing

I dont think they will hang.  But I was just testing via loopback/break 
out box/scope.

I'll be putting about 10 patches and another set of binaries in that 
directory shortly.  For now the binaries should just have the baud_rate 
fix.

I'll announce all the patches at once.  but wont be releasing 2.1-8 right 
away.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Sat Jun  3 21:00:01 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 21:00:01 -0600 (MDT)
Subject: [Rxtx] CVS for 2.1 should have everything
Message-ID: <Pine.LNX.4.61.0606032056190.10890@www>


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org


From impakt01 at optusnet.com.au  Sat Jun  3 21:08:14 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 13:08:14 +1000
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <Pine.LNX.4.61.0606032056190.10890@www>
Message-ID: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>

Hi Trent,
I tried the latest dll and it opens the port, receives 100-200 bytes and
then stops receiving anything else..

I'll keep playing with it.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 1:00 PM
To: rxtx at qbang.org
Subject: [Rxtx] CVS for 2.1 should have everything


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From impakt01 at optusnet.com.au  Sat Jun  3 21:22:41 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 13:22:41 +1000
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
Message-ID: <200606040322.k543MqW1008455@mail12.syd.optusnet.com.au>

Played with it, problem, with a while loop in my code, working great now

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Daren
Sent: Sunday, 4 June 2006 1:08 PM
To: 'RXTX Developers and Users'
Subject: Re: [Rxtx] CVS for 2.1 should have everything

Hi Trent,
I tried the latest dll and it opens the port, receives 100-200 bytes and
then stops receiving anything else..

I'll keep playing with it.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 1:00 PM
To: rxtx at qbang.org
Subject: [Rxtx] CVS for 2.1 should have everything


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Sat Jun  3 21:35:41 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 21:35:41 -0600 (MDT)
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
References: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606032131140.10890@www>

On Sun, 4 Jun 2006, Daren wrote:

> Hi Trent,
> I tried the latest dll and it opens the port, receives 100-200 bytes and
> then stops receiving anything else..
>
> I'll keep playing with it.
>
> Daren

The difference may be that I'm talking to something at the exact same baud 
rate (loopback).

You may also try setting the baudrate to ~1933 and ~1973 to force the 
guesses one way or the other.  If you are on windows, we are not doing 
anything fancy in the end.  Thats the kernel guessing.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sun Jun  4 04:12:09 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sun, 4 Jun 2006 12:12:09 +0200
Subject: [Rxtx] Update of OSX installer, Readme, etc
Message-ID: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>

Good day,

after the latest changes a lot of OS X specific files should be  
updated. Especially the installer!

- The "MaxOSX" readme file on the root level is outdated (ie  
CodeWarrior information). Maybe we could even rename it to README.OSX  
to be in line with README.IPAQ, README.SCO (Trent do you mind copying/ 
renaming ,v files in the repository?).

- The lock files are no longer used and hence the user group magic  
and lock folder creation should be removed from the installer.

- MACOSX_IDE/ForPackageMaker/Resources/ReadMe.rtf and Welcome.rtf  
need to be updated.

- I suggest to replace the current installation instruction for OS X:  
Installation should occur into the application directory, not in the  
Java-VM directory. This simplifies things a lot, as the Mac Installer  
can be removed completely.

- The xcodeproject's build settings need to be updated to generate  
JAVA 1.1 format class files.


Dimitry: do you have time to tackle this? I could do it, but as this  
is "your baby" I thought you may prefer to do it yourself.

Regards,
Joachim



From dmarkman at mac.com  Sun Jun  4 11:27:53 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Sun, 4 Jun 2006 13:27:53 -0400
Subject: [Rxtx] Update of OSX installer, Readme, etc
In-Reply-To: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
References: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
Message-ID: <26E7A202-962B-4C19-93B6-29426C467249@mac.com>

Joachim,
unfortunately I don't have time right now to do that
so if you can do that, please do

it's not only my baby
it's yours too :-)

thanks


On Jun 4, 2006, at 6:12 AM, Joachim Buechse wrote:

> Good day,
>
> after the latest changes a lot of OS X specific files should be
> updated. Especially the installer!
>
> - The "MaxOSX" readme file on the root level is outdated (ie
> CodeWarrior information). Maybe we could even rename it to README.OSX
> to be in line with README.IPAQ, README.SCO (Trent do you mind copying/
> renaming ,v files in the repository?).
>
> - The lock files are no longer used and hence the user group magic
> and lock folder creation should be removed from the installer.
>
> - MACOSX_IDE/ForPackageMaker/Resources/ReadMe.rtf and Welcome.rtf
> need to be updated.
>
> - I suggest to replace the current installation instruction for OS X:
> Installation should occur into the application directory, not in the
> Java-VM directory. This simplifies things a lot, as the Mac Installer
> can be removed completely.
>
> - The xcodeproject's build settings need to be updated to generate
> JAVA 1.1 format class files.
>
>
> Dimitry: do you have time to tackle this? I could do it, but as this
> is "your baby" I thought you may prefer to do it yourself.
>
> Regards,
> Joachim
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman



From tjarvi at qbang.org  Sun Jun  4 13:54:02 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 4 Jun 2006 13:54:02 -0600 (MDT)
Subject: [Rxtx] Update of OSX installer, Readme, etc
In-Reply-To: <26E7A202-962B-4C19-93B6-29426C467249@mac.com>
References: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
	<26E7A202-962B-4C19-93B6-29426C467249@mac.com>
Message-ID: <Pine.LNX.4.61.0606041353040.22522@www>

On Sun, 4 Jun 2006, Dmitry Markman wrote:

> Joachim,
> unfortunately I don't have time right now to do that
> so if you can do that, please do
>
> it's not only my baby
> it's yours too :-)
>

I've given Joachim cvs access.  He has shown good work in bugzilla.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Mon Jun  5 10:08:32 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 5 Jun 2006 18:08:32 +0200
Subject: [Rxtx] Build process changes for Mac OS X
Message-ID: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>

Good day,

I have cleaned up some outdated Mac OSX specific build files in the  
repository.

There was not a lot left of the readme file "MacOSX" after cleaning  
it up, so I decided to rename it README.OSX to be in harmony with the  
other files in the directory (ie README.IPAQ, README.SCO, ...)

I added an (uncompressed) XCode 2.3 project file/structure  
with .cvsignore files that will ignore the user specific settings.  
This should work "out of the box" for OSX10.4. Users of 10.2/10.3 may  
have to switch the build settings.

[It's kind of tricky to choose "the right" setting. Afaik there is no  
way to compile a universal binary that will work on 10.3 or before.  
So it's either UniversalBinary OR Legacy. Maybe we should have  
different build targets for these different targets?? I would like to  
get some feedback from the Mac developers on this list regarding the  
subject].

Besides other things the OSX installer is no longer required. Since  
the next version (2.1.8) will no longer use lockfiles on OSX, the  
group/permission magic is no longer required and hence there remains  
basicly no work for the installer - other than copying 2 files to the  
VM extension directory. Then again, this is not the best way to  
install RXTX. So I removed the installer completely without modifying  
it, this should simplify a "resurrection" should it ever get necessary.

I had problems with the (compressed, ie sit.hqx) legacy project files  
on the latest installation of OSX (javac 1.5 creating non JDK1.1  
class files and some minor problems). To reduce potential confusion  
for newcomers I decided to remove them. This means that there is no  
longer a simple way to build RXTX for OSX 10.0 and 10.1 (I deeply  
apologize if anyone still relied on this ... well the files are in  
the Attiq).

Best regards,
Joachim


From joachim at buechse.de  Mon Jun  5 10:16:37 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 5 Jun 2006 18:16:37 +0200
Subject: [Rxtx] RXTX and lockfiles on OSX [it is fixed now]
Message-ID: <7D2C4418-9397-4B59-8091-9FDE4ED67836@buechse.de>

Quite a number of people contacted me in the last couple of weeks  
because of problems installing RXTX on OSX. I told you to wait for  
the "official" fix. Well, it has been fixed.

So if you were among the people waiting for the solution, you can now  
download the source rxtx-2.1-7r2.zip from the website. Once unpacked  
dont forget to use "cvs up" to update the files to the latest  
version. You can then open MACOSX_IDE/XCode/ 
LibSerialUniversal.xcodeproj with XCode 2.3 and build the libraries  
that no longer try to create lock files.

Regards,
Joachim


From brian at mbari.org  Mon Jun  5 10:52:43 2006
From: brian at mbari.org (Brian Schlining)
Date: Mon, 5 Jun 2006 09:52:43 -0700
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
Message-ID: <78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>

Hi Joachim,

> [It's kind of tricky to choose "the right" setting. Afaik there is no
> way to compile a universal binary that will work on 10.3 or before.
> So it's either UniversalBinary OR Legacy. Maybe we should have
> different build targets for these different targets?? I would like to
> get some feedback from the Mac developers on this list regarding the
> subject].

I imagine most developers will be compiling on 10.4 (It's the nature  
of the coder...gotta have the latest and greatest) and deploying to  
both 10.3 and 10.4; both of which will run Universal Binaries (see  
http://forums.macrumors.com/showthread.php?t=205348). So it sounds  
like you've covered the majority of users. Still, you know someone's  
going to pipe up about needing RXTX on 10.2 so it would be nice to  
have a target to make a PPC only build.

Just my 2 cents

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/1cac8c39/attachment-0013.html

From dmarkman at mac.com  Mon Jun  5 13:47:50 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Mon, 5 Jun 2006 15:47:50 -0400
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
Message-ID: <686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>

I don't think it will be a problem to run universal binary
on 10.2
however if binary has some calls that aren't implemented in 10.2
then you'll have a problem


On Jun 5, 2006, at 12:52 PM, Brian Schlining wrote:

> Hi Joachim,
>
>> [It's kind of tricky to choose "the right" setting. Afaik there is no
>> way to compile a universal binary that will work on 10.3 or before.
>> So it's either UniversalBinary OR Legacy. Maybe we should have
>> different build targets for these different targets?? I would like to
>> get some feedback from the Mac developers on this list regarding the
>> subject].
>
> I imagine most developers will be compiling on 10.4 (It's the  
> nature of the coder...gotta have the latest and greatest) and  
> deploying to both 10.3 and 10.4; both of which will run Universal  
> Binaries (see http://forums.macrumors.com/showthread.php?t=205348).  
> So it sounds like you've covered the majority of users. Still, you  
> know someone's going to pipe up about needing RXTX on 10.2 so it  
> would be nice to have a target to make a PPC only build.
>
> Just my 2 cents
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/9fafc878/attachment-0013.html

From brian at mbari.org  Mon Jun  5 14:52:41 2006
From: brian at mbari.org (Brian Schlining)
Date: Mon, 5 Jun 2006 13:52:41 -0700
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
Message-ID: <E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>

Hi Dmitry,

> I don't think it will be a problem to run universal binary
> on 10.2
> however if binary has some calls that aren't implemented in 10.2
> then you'll have a problem

You're right...I stand corrected.

Note however, to deploy a universal binary to 10.2 RXTX will need to  
use the 10.2 SDK to build the PPC side. (see http:// 
developer.apple.com/documentation/DeveloperTools/Conceptual/ 
cross_development/UniversalBinaries/chapter_4_section_1.html). I  
haven't been paying close attention to the new locking mechanism used  
by RXTX on the Mac...does 10.2 support it?

Joachim, which SDK will you be using by default for building the Mac  
PPC binaries?

>> Hi Joachim,
>>
>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>> is no
>>> way to compile a universal binary that will work on 10.3 or before.
>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>> different build targets for these different targets?? I would  
>>> like to
>>> get some feedback from the Mac developers on this list regarding the
>>> subject].
>>
>> I imagine most developers will be compiling on 10.4 (It's the  
>> nature of the coder...gotta have the latest and greatest) and  
>> deploying to both 10.3 and 10.4; both of which will run Universal  
>> Binaries (see http://forums.macrumors.com/showthread.php? 
>> t=205348). So it sounds like you've covered the majority of users.  
>> Still, you know someone's going to pipe up about needing RXTX on  
>> 10.2 so it would be nice to have a target to make a PPC only build.

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/153bf50e/attachment-0013.html

From dmarkman at mac.com  Mon Jun  5 19:02:04 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Mon, 5 Jun 2006 21:02:04 -0400
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
Message-ID: <7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>

if Joachim didn't change xcode project setting

/Developer/SDKs/MacOSX10.4u.sdk is used to build universal binary

so it's quite possible that it won't run properly on 10.2

so we have to change the building process, so ppc part will be built
with
/Developer/SDKs/MacOSX10.2.8.sdk

and finally to use lipo utility to build universal binaries

Joachim, did you use some specific locking API that wasn't implemented

in MacOSX10.2.8.sdk?

thanks


On Jun 5, 2006, at 4:52 PM, Brian Schlining wrote:

> Hi Dmitry,
>
>> I don't think it will be a problem to run universal binary
>> on 10.2
>> however if binary has some calls that aren't implemented in 10.2
>> then you'll have a problem
>
> You're right...I stand corrected.
>
> Note however, to deploy a universal binary to 10.2 RXTX will need  
> to use the 10.2 SDK to build the PPC side. (see http:// 
> developer.apple.com/documentation/DeveloperTools/Conceptual/ 
> cross_development/UniversalBinaries/chapter_4_section_1.html). I  
> haven't been paying close attention to the new locking mechanism  
> used by RXTX on the Mac...does 10.2 support it?
>
> Joachim, which SDK will you be using by default for building the  
> Mac PPC binaries?
>
>>> Hi Joachim,
>>>
>>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>>> is no
>>>> way to compile a universal binary that will work on 10.3 or before.
>>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>>> different build targets for these different targets?? I would  
>>>> like to
>>>> get some feedback from the Mac developers on this list regarding  
>>>> the
>>>> subject].
>>>
>>> I imagine most developers will be compiling on 10.4 (It's the  
>>> nature of the coder...gotta have the latest and greatest) and  
>>> deploying to both 10.3 and 10.4; both of which will run Universal  
>>> Binaries (see http://forums.macrumors.com/showthread.php? 
>>> t=205348). So it sounds like you've covered the majority of  
>>> users. Still, you know someone's going to pipe up about needing  
>>> RXTX on 10.2 so it would be nice to have a target to make a PPC  
>>> only build.
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/84790f80/attachment-0013.html

From joachim at buechse.de  Tue Jun  6 02:40:47 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 6 Jun 2006 10:40:47 +0200
Subject: [Rxtx] Building on OS X, Impl Changes
In-Reply-To: <7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
Message-ID: <CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>

Good day!

What's in the XCode project setting?
----------

The xcode project remained pretty much the same as before. I excluded  
the user specific files from CVS and changed some settings. I kept  
all the built targets (you shouldn't change what you don't understand;-)

Currently we the following build targets:
    RXTXComm (java files)
    librxtxParallel.jnilib (usefull on the Mac???)
    libI2C.jnilib (not yet working in RXTX)
    libRS485.jnilib (not yet working in RXTX)
    librxtxSerial.jnilib (1)
    librxtxSerial.jnilib Dynamic (2)
    rxtxSerial (3)
We also have the following build configurations for each target:
    Development
    Default
    Deployment

What was changed in the xcode project from previous versions:
- java.souce=1.3 and java.target=1.1 in RXTXComm settings
- removed copying of build products into installer directory
- removed "(Upgraded)" from build target names

What remains to be changed:
- choosing a "non-debug" Build-configuration as default
- potentially removing "Default"/"Development" Build-configurations
- reducing the number of build targets
- creating 10.2 compatible universal binaries

I suggest, that the build configurations should be reduced to 2  
(Debug/Deployment), possibly even 1 (Debug).
I have not yet found the deeper meaning of the build targets(1)(2) 
(3), it seems to me like they should be reduced into one "doing the  
right thing" or maybe into two "rxtxSerial.jnilib Legacy" (back to  
10.2, universal if possible) and "rxtxSerial.jnilib 10.4 
+" (universal, 10.4+).

Should the code work on 10.2?
----------

Absolutely. The code should work on NextStep, in fact on any BSD  
unix. I would go as far as saying, this code should work on any  
POSSIX based unix. All that was added is the call "ioctl(fd,  
TIOCEXCL)" to request excusivity of the port:

http://gemma.apple.com/documentation/DeviceDrivers/Conceptual/ 
WorkingWSerial/WWSerial_SerialDevs/chapter_2_section_8.html

It is not yet "the perfect solution". Normally an open /dev/tty  
(listen for incomming connection) should be "preemptable" by opening  
a /dev/cu (outgoing connection) for the same port. This is not yet  
implemented as it needs calls outside of POSSIX on OSX.

On "classic" systems (like NextStep) this worked based on the  
"carried detect line". open() on /dev/tty.xxx would block until the  
carrier detect signal was raised. As the device was not "opened"  
opening /dev/cu.xxx worked without a hitch. When they ported to the  
Mac this broke. On Macs the "carier detect" is usually not wired.  
Furthermore FAX modems did no longer raise the line. So the OSX  
implementor defined a new call, which is documented here:

http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00045.html

Best regards,
Joachim




On 06.06.2006, at 03:02, Dmitry Markman wrote:

> if Joachim didn't change xcode project setting
>
> /Developer/SDKs/MacOSX10.4u.sdk is used to build universal binary
>
> so it's quite possible that it won't run properly on 10.2
>
> so we have to change the building process, so ppc part will be built
> with
> /Developer/SDKs/MacOSX10.2.8.sdk
>
> and finally to use lipo utility to build universal binaries
>
> Joachim, did you use some specific locking API that wasn't implemented
>
> in MacOSX10.2.8.sdk?
>
> thanks
>
>
> On Jun 5, 2006, at 4:52 PM, Brian Schlining wrote:
>
>> Hi Dmitry,
>>
>>> I don't think it will be a problem to run universal binary
>>> on 10.2
>>> however if binary has some calls that aren't implemented in 10.2
>>> then you'll have a problem
>>
>> You're right...I stand corrected.
>>
>> Note however, to deploy a universal binary to 10.2 RXTX will need  
>> to use the 10.2 SDK to build the PPC side. (see http:// 
>> developer.apple.com/documentation/DeveloperTools/Conceptual/ 
>> cross_development/UniversalBinaries/chapter_4_section_1.html). I  
>> haven't been paying close attention to the new locking mechanism  
>> used by RXTX on the Mac...does 10.2 support it?
>>
>> Joachim, which SDK will you be using by default for building the  
>> Mac PPC binaries?
>>
>>>> Hi Joachim,
>>>>
>>>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>>>> is no
>>>>> way to compile a universal binary that will work on 10.3 or  
>>>>> before.
>>>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>>>> different build targets for these different targets?? I would  
>>>>> like to
>>>>> get some feedback from the Mac developers on this list  
>>>>> regarding the
>>>>> subject].
>>>>
>>>> I imagine most developers will be compiling on 10.4 (It's the  
>>>> nature of the coder...gotta have the latest and greatest) and  
>>>> deploying to both 10.3 and 10.4; both of which will run  
>>>> Universal Binaries (see http://forums.macrumors.com/ 
>>>> showthread.php?t=205348). So it sounds like you've covered the  
>>>> majority of users. Still, you know someone's going to pipe up  
>>>> about needing RXTX on 10.2 so it would be nice to have a target  
>>>> to make a PPC only build.
>>
>> Brian Schlining
>> Software Engineer
>> http://www.mbari.org
>>
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> Dmitry Markman
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Tue Jun  6 07:01:06 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 6 Jun 2006 15:01:06 +0200
Subject: [Rxtx] Serial port code for OS X, future steps
In-Reply-To: <CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
	<CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
Message-ID: <8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>

I posted the "wrong link". There is a correction here:

    http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00059.html

In fact, the 2.1.7 implementation of RXTX has quite some deficiencies  
on OSX. I have tried to supply some patches that don't interfere to  
much with the existing RXTX code base, but there are limits to what  
can be done with local patches.

There are some very intrusive changes that should be done. Ie proper  
mapping of /dev/tty <-> /dev/cu handling to correct behaviour of  
CommPortOwnershipListener (http://java.sun.com/products/javacomm/ 
reference/api/index.html). I dont think this can be done with  
patches. Hence I think, RXTX should be rewritten from scratch de- 
unifying the native code base (and implementing thread safe code on  
the Java side).


How "should" /dev/tty vs /dev/cu be implemented?

=====
The Unix contract is this: An open /dev/tty.xxx port (incomming)  
should be interrupted/auto-closed when opening /dev/cu.xxx (outgoing)  
[if /dev/tty.xxx is not currently handling a communication].  /dev/ 
cu.xxx and /dev/tty.xxx refer to the same device, so owning  
"exclusively" should block both. This should be respected across all  
applications native or Java.

This contract is realizable on OSX with the existing javax.comm  
interface while also respecting (to the biggest part) the contract  
defined by javax.comm.PortOwnershipListener.

The one point where the suggested implementation "breaks" the  
javax.comm contract, is by the fact that one can loose a /dev/tty  
port without calling close. However, the only option I see is to  
always open serial ports "non-exclusively" which would outrule Java  
as a platform for (dormant) applications waiting for incoming  
connections/faxes/etc. There could be a system property to choose the  
intended behavior.
=====

Here is how it could be done on OSX:

Calling port=ComportIdentifier.open("/dev/cu.xxx") opens and owns the  
port exclusively until port.close() is called.
- Java applications listening with a PortOwnershipListener should get  
a PORT_OWNED event reasonably soon.
- Any further attempt by a Java or native application to open "/dev/ 
cu.xxx" or "/dev/tty.xxx" fails.
- /dev/cu.xxx is for "outgoing" connections, so receiving  
PORT_OWNERSHIP_REQUESTED makes little to no sense. With native  
applications it can not be implemented. For Java applications it  
could be implemented (by a hidden communication channel). I think  
it's not worth bothering. If anyone is willing to give up a port to  
others he should use /dev/tty.xxx instead of /dev/cu.xxx.

Registering a PortOwnershipListener on "/dev/cu.xxx" without opening  
it, uses /dev/tty.xxx (native open()) non-exclusively and polls its  
state. PORT_OWNED and PORT_UNOWNED can be produced.

Calling port=ComportIdentifier.open("/dev/tty.xxx") should open the  
port non-exclusively.
- Adding a SerialPortEventListener and reading from the port could be  
allowed while keeping it non-exclusive.
- When port.getOutputStream() is called, the state should be changed  
to an "exclusive" ownership. This may be configurable via a system  
property.
- To return to the non-exclusive state the port must be closed and  
reopened.
- While non-exclusively opened, opening the corresponding /dev/cu.xxx  
produces a PORT_OWNERSHIP_REQUESTED event. Which should be responded  
by closing the port from within the callback (as described in  
java.comm.PortOwnershipListener). If there is a pending read, it will  
return after the listener finishes (with -1 or "0 bytes read").
- Calling write() on the /dev/tty.xxx after somebody opened /dev/ 
cu.xxx will fail with a descriptive IOException.
- Calling read() on the /dev/tty.xxx after somebody opened /dev/ 
cu.xxx will fail with a descriptive IOException (or potentially  
block, see side notes below).

CommPortIdentifier.getCurrentOwner() can be implemented by an  
external call to lsof.

CommPortIdentifier.isCurrentlyOwned() can be implemented by trying an  
open on the /dev/tty.
- It returns true if the port is currently held "exclusively".
- Whether it should also return true on /dev/tty if /dev/tty is  
already opened non-exclusively might be a system property option. In  
general, having several applications waiting for incoming connections  
on the same port will require an application level "arbitration"  
protocol...

[[side note1: One interesting question is, what happens if the  
process holding /dev/tty non-exclusively ignores  
PORT_OWNERSHIP_REQUESTED. Ie after "loosing" a non-exclusively opened  
"dev/tty.xxx" port to another process. One possible implementation  
is, that the port is "regained" when the other process gives up the  
port. This would mean that in the meanwhile read() returns no data,  
and any changes to the configuration of the port are stored but not  
forwarded. I guess, the safe (and simple) way to do this is to make  
the close() mandatory (ie setting the port into an "awaiting_close"  
state which produces IOExceptions to any other call than close). ]]

[[side note2:  Another interesting question is, what should happen if  
several applications open the same /dev/tty.xxx port "non- 
exclusively" and start to change the settings of the device.]]

Regards,
Joachim



On 06.06.2006, at 10:40, Joachim Buechse wrote:

> Should the code work on 10.2?
> ----------
>
> Absolutely. The code should work on NextStep, in fact on any BSD
> unix. I would go as far as saying, this code should work on any
> POSSIX based unix. All that was added is the call "ioctl(fd,
> TIOCEXCL)" to request excusivity of the port:
>
> http://gemma.apple.com/documentation/DeviceDrivers/Conceptual/
> WorkingWSerial/WWSerial_SerialDevs/chapter_2_section_8.html
>
> It is not yet "the perfect solution". Normally an open /dev/tty
> (listen for incomming connection) should be "preemptable" by opening
> a /dev/cu (outgoing connection) for the same port. This is not yet
> implemented as it needs calls outside of POSSIX on OSX.
>
> On "classic" systems (like NextStep) this worked based on the
> "carried detect line". open() on /dev/tty.xxx would block until the
> carrier detect signal was raised. As the device was not "opened"
> opening /dev/cu.xxx worked without a hitch. When they ported to the
> Mac this broke. On Macs the "carier detect" is usually not wired.
> Furthermore FAX modems did no longer raise the line. So the OSX
> implementor defined a new call, which is documented here:
>
> http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00045.html
>
> Best regards,
> Joachim



From sds at dcs.gla.ac.uk  Tue Jun  6 11:22:45 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Tue, 06 Jun 2006 18:22:45 +0100
Subject: [Rxtx] Correct compile flag for HP iPAQ hx4700 running Familiar
	Linux?
Message-ID: <1149614565.19496.10.camel@addu>

Hi,

I'd like to use RXTX 2.1 on my HP iPAQ hx4700. The iPAQ is running
Familiar Linux 0.8.2 (as I recall), with Blackdown Java 1.3.1.

I can compile and run a test program which uses RXTX on my i686 machine,
and it works fine. But I can't seem to get things working quite right on
my PDA.

I compile the code on the laptop with the following commands:
	./configure --host=arm-gnu-linux && make
... as suggested in a post to this list, albeit some time ago. This
compiles, I transfer the files, set up LD_LIBRARY_PATH and CLASSPATH
variables, and get the following error on the PDA:

sds at ipaq-pxa-2:~# java Test
java.lang.UnsatisfiedLinkError: /usr/local/lib/ext/librxtxSerial.so: /usr/local/lib/ext/librxtxSerial.so: cannot open shared object file: No such file or directory thrown while loading gnu.io.RXTXCommDriver
Exception in thread "main"
java.lang.UnsatisfiedLinkError: /usr/local/lib/ext/librxtxSerial.so: /usr/local/lib/ext/librxtxSerial.so: cannot open shared object file: No such file or directory
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1382)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1290)
        at java.lang.Runtime.loadLibrary0(Runtime.java:749)
        at java.lang.System.loadLibrary(System.java:820)
        at
gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:83)
        at Test.<init>(Test.java:9)
        at Test.main(Test.java:32)
sds at ipaq-pxa-2:~# 

Note that I'm copying the files to /usr/local/lib/ext/ along with the
RXTXcomm.jar file, purely to keep things separate from the rest of the
system while testing. The location of the .so files doesn't seem to have
any bearing on whether "java Test" will succeed or not. The contents of
this directory are:

sds at ipaq-pxa-2:~$ ls /usr/local/lib/ext/
RXTXcomm.jar              librxtxParallel-2.1-7.so  librxtxRS485.so
librxtxSerial-2.1-7.so
librxtxI2C-2.1-7.so       librxtxParallel.so        librxtxRaw-2.1-7.so
librxtxSerial.so
librxtxI2C.so             librxtxRS485-2.1-7.so     librxtxRaw.so
sds at ipaq-pxa-2:~$

Test.java fails on the first real line of code I'm using to test that
things are working, prior to real development, and was carefully pinched
from the web:
Enumeration portIdentifiers = CommPortIdentifier.getPortIdentifiers();


I assume that I've gotten my --host flag wrong way back up there at
the ./configure step. But if that's the case, what should I set it to?
Or am I missing something more obvious?


Cheers,
Stephen Strowes,
University of Glasgow.




From tjarvi at qbang.org  Tue Jun  6 13:39:41 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 6 Jun 2006 13:39:41 -0600 (MDT)
Subject: [Rxtx] Serial port code for OS X, future steps
In-Reply-To: <8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
	<CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
	<8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>
Message-ID: <Pine.LNX.4.61.0606061315070.9856@www>


>>
There are some very intrusive changes that should be done. Ie proper
mapping of /dev/tty <-> /dev/cu handling to correct behaviour of
CommPortOwnershipListener (http://java.sun.com/products/javacomm/
reference/api/index.html). I dont think this can be done with
patches. Hence I think, RXTX should be rewritten from scratch de-
unifying the native code base (and implementing thread safe code on
the Java side).
<<

This appears to be a very small amount of functionality for a total 
rewrite.  The port ownership only needs maybe 3 native calls if it is done 
with native calls at all.

Those features which are not part of the Unix standard(s) can be special 
cased.  I'm not sure /dev/cu is standard.  We can look.  I know linux 
deprecated /dev/cua years ago.

Thread safe Java code is not a platform specific issue.

--
Trent Jarvi
tjarvi at qbang.org


From sds at dcs.gla.ac.uk  Wed Jun  7 12:36:43 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Wed, 07 Jun 2006 19:36:43 +0100
Subject: [Rxtx] Expected RXTX behaviour?
In-Reply-To: <1149703900.30891.19.camel@addu>
References: <1149703900.30891.19.camel@addu>
Message-ID: <1149705403.30891.25.camel@addu>

Apologies, caught the problem. Had to append '\r' to the end of the AT
string. A non obvious but stupid mistake... :-)

Final quick question though: How might I stop the echoing of
outputStream data back into the inputStream? I still see the ATI
commands on the inputStream, along with the output from the device.


Cheers,
S.



On Wed, 2006-06-07 at 19:11 +0100, Stephen Strowes wrote:
> Hi,
> 
> I managed to get RXTX to compile for my iPAQ following my previous post
> to this list. Quick query though:
> 
> I want to be able to issue AT commands to a device, and interpret the
> responses. For this, I assume I do the following, in psuedo-form:
> 
> 	CommPortIdentifier.getPortIdentifiers();
> 	// find the correct device id
> 	serialPort= (SerialPort)portID.open("Test");
> 	// Set parameters and flow control
> 	outputStream= serialPort.getOutputStream();
> 	inputStream=  serialPort.getInputStream();
> 
> ... following this, I spawn a thread to respond to DATA_AVAILABLE events
> on serialPort with inputStream, and occasionally write and flush an
> "ATI" onto the outputStream. Nothing complex, I just want to see it
> work.
> 
> I would have expected inputStream to give the same information back from
> an "ATI" command as minicom provides, but instead inputStream only sees
> the "ATI" I put onto the outputStream.
> 
> Have I missed something?
> 
> 
> Cheers,
> S.
> 



From sds at dcs.gla.ac.uk  Wed Jun  7 12:11:40 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Wed, 07 Jun 2006 19:11:40 +0100
Subject: [Rxtx] Expected RXTX behaviour?
Message-ID: <1149703900.30891.19.camel@addu>

Hi,

I managed to get RXTX to compile for my iPAQ following my previous post
to this list. Quick query though:

I want to be able to issue AT commands to a device, and interpret the
responses. For this, I assume I do the following, in psuedo-form:

	CommPortIdentifier.getPortIdentifiers();
	// find the correct device id
	serialPort= (SerialPort)portID.open("Test");
	// Set parameters and flow control
	outputStream= serialPort.getOutputStream();
	inputStream=  serialPort.getInputStream();

... following this, I spawn a thread to respond to DATA_AVAILABLE events
on serialPort with inputStream, and occasionally write and flush an
"ATI" onto the outputStream. Nothing complex, I just want to see it
work.

I would have expected inputStream to give the same information back from
an "ATI" command as minicom provides, but instead inputStream only sees
the "ATI" I put onto the outputStream.

Have I missed something?


Cheers,
S.




From joachim at buechse.de  Wed Jun  7 09:02:13 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 7 Jun 2006 17:02:13 +0200
Subject: [Rxtx] Update of build process for OSX (XCode project)
Message-ID: <62EC47B1-46BD-4ECA-B9EC-C4061D147CDA@buechse.de>

With the help of Dmitry Markman and Brian Schilling I have updated  
(and largely simplifed) the XCode project file for Mac OS X.

Changes:
- compiles a universal binary library with intel=OSX10.4+, ppc=OSX10.2 
+ support
- compiles the Java sources into a JRE1.1 compatible, compressed jar.

Please test on your configuration, especially if you have computers  
running 10.2/10.3 or intel.

Best regards,
Joachim


From joachim at buechse.de  Wed Jun  7 14:36:37 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 7 Jun 2006 22:36:37 +0200
Subject: [Rxtx] Expected RXTX behaviour?
In-Reply-To: <1149705403.30891.25.camel@addu>
References: <1149703900.30891.19.camel@addu> <1149705403.30891.25.camel@addu>
Message-ID: <D3AD6EAF-27BB-455E-9697-86C1121920C3@buechse.de>

Echoing is a feature of the modem. Try ATE0 which works with most  
"rockwell" compatible modems.

Regards,
Joachim


On 07.06.2006, at 20:36, Stephen Strowes wrote:

> Apologies, caught the problem. Had to append '\r' to the end of the AT
> string. A non obvious but stupid mistake... :-)
>
> Final quick question though: How might I stop the echoing of
> outputStream data back into the inputStream? I still see the ATI
> commands on the inputStream, along with the output from the device.
>
>
> Cheers,
> S.
>
>
>
> On Wed, 2006-06-07 at 19:11 +0100, Stephen Strowes wrote:
>> Hi,
>>
>> I managed to get RXTX to compile for my iPAQ following my previous  
>> post
>> to this list. Quick query though:
>>
>> I want to be able to issue AT commands to a device, and interpret the
>> responses. For this, I assume I do the following, in psuedo-form:
>>
>> 	CommPortIdentifier.getPortIdentifiers();
>> 	// find the correct device id
>> 	serialPort= (SerialPort)portID.open("Test");
>> 	// Set parameters and flow control
>> 	outputStream= serialPort.getOutputStream();
>> 	inputStream=  serialPort.getInputStream();
>>
>> ... following this, I spawn a thread to respond to DATA_AVAILABLE  
>> events
>> on serialPort with inputStream, and occasionally write and flush an
>> "ATI" onto the outputStream. Nothing complex, I just want to see it
>> work.
>>
>> I would have expected inputStream to give the same information  
>> back from
>> an "ATI" command as minicom provides, but instead inputStream only  
>> sees
>> the "ATI" I put onto the outputStream.
>>
>> Have I missed something?
>>
>>
>> Cheers,
>> S.
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From g_petrini at yahoo.it  Thu Jun  8 01:41:58 2006
From: g_petrini at yahoo.it (Giacomo Petrini)
Date: Thu, 8 Jun 2006 09:41:58 +0200 (CEST)
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from FieldTalk
Message-ID: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>

Hi,
I'm evaluating the library for the modbus protocol
from FieldTalk
(http://www.modbusdriver.com/fieldtalk/.
I'm using J2SE 5.0 and RXTX 2.1 on win XP.
The problem is that the modbus lib has a method (the
openProtocol method, but maybe there are others) tha
throws the
javax.comm.UnsupportedCommOperationException.
Now, in RXTX 2.1 the namespace has changed in gnu.io,
so the modbus library doesn't work anymore (it look
for things in javax.comm). I've already sent an email
to fieldtalk to see if they are aware of the problem.
The solution should be to use JavaComm + RXTX 2.0. But
I've read somewhere that JavaComm 2.0 does not work
with Java 5.0 and JavaComm 3.0 does not work with RXTX
2.0 so I don't know what to do.

Any ideas?

Thanks Jack

PS: can you make a CC to my personal email
(g_petrini at yahoo.it) too please?

Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 


From rxtx at tapastda.co.uk  Thu Jun  8 02:27:57 2006
From: rxtx at tapastda.co.uk (rxtx@tapastda.co.uk)
Date: Thu, 08 Jun 2006 09:27:57 +0100
Subject: [Rxtx] Win XP and Infrared based serial port
Message-ID: <4487DF8D.5050807@tapastda.co.uk>

I'm attempting to use RXTX 2.1.7 on Win XP with J2SE 5.0 to communicate with a
GSM mobile using a COM port. A peculiarity that I've seen is that whilst I can
communicate successfully with a mobile which uses an infrared based COM port
using the SUN provided javax.comm (v2.0) I cannot use RXTX because it fails to
read anything from the port (i.e. read timeout always occurs returning zero bytes).

I assumed that this could be the result of flow control problems and thus I've
tried setting either software or hardware based flow control on the port however
this has no affect.

Can you suggest any other port configuration changes which might be required to
make such a port work with RXTX.

Thanks
Stu
-- 
Stuart
Tapastda Limited


From tjarvi at qbang.org  Thu Jun  8 05:17:12 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 8 Jun 2006 05:17:12 -0600 (MDT)
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from
	FieldTalk
In-Reply-To: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
References: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606080504480.9856@www>

On Thu, 8 Jun 2006, Giacomo Petrini wrote:

> Hi,
> I'm evaluating the library for the modbus protocol
> from FieldTalk
> (http://www.modbusdriver.com/fieldtalk/.
> I'm using J2SE 5.0 and RXTX 2.1 on win XP.
> The problem is that the modbus lib has a method (the
> openProtocol method, but maybe there are others) tha
> throws the
> javax.comm.UnsupportedCommOperationException.
> Now, in RXTX 2.1 the namespace has changed in gnu.io,
> so the modbus library doesn't work anymore (it look
> for things in javax.comm). I've already sent an email
> to fieldtalk to see if they are aware of the problem.
> The solution should be to use JavaComm + RXTX 2.0. But
> I've read somewhere that JavaComm 2.0 does not work
> with Java 5.0 and JavaComm 3.0 does not work with RXTX
> 2.0 so I don't know what to do.
>
> Any ideas?
>
> Thanks Jack
>


Hi Jack

There are plans for Sun to rerelease JavaComm 2.0 mentioned in the rxtx 
mail-list archives.  When this happens rxtx will release a current rxtx 
2.0 library that works with it.

There are no dates promised by either side but rxtx will do it as soon as 
possible after Sun's rerelease.  Just to give you a feel for the time 
frame, this started last year and no significant progress has been made. 
There have been friendly talks pointing towards solutions (rerelease 2.0) 
but that does not get your application working today.  rxtx is preparing 
for its second release in gnu.io since then.

--
Trent Jarvi
tjarvi at qbang.org




From jredman at ergotech.com  Thu Jun  8 08:47:23 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 08 Jun 2006 08:47:23 -0600
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from
	FieldTalk
In-Reply-To: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
References: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
Message-ID: <4488387B.6040903@ergotech.com>

You could always try a different library, eg.

http://sourceforge.net/projects/jamod

I've only used the slave side since we have our own implementation of 
Modbus Client (and a host of other PLC protocols).  However the client 
side seems to be pretty well supported and fairly widely used.  Since 
the source is there you could change to gnu.io.

I think I should take more of an interest in this issue.  We generally 
run 1.4.2 on Linux, but also have some J9 and old platforms that we 
support that are basically Personal Java.  5.0 on Linux has some 
horrible MDI bugs, to the point of being unusable.   Sounds as though we 
are going to have code compatibility problems across these platforms.

Jim


Giacomo Petrini wrote:
> Hi,
> I'm evaluating the library for the modbus protocol
> from FieldTalk
> (http://www.modbusdriver.com/fieldtalk/.
> I'm using J2SE 5.0 and RXTX 2.1 on win XP.
> The problem is that the modbus lib has a method (the
> openProtocol method, but maybe there are others) tha
> throws the
> javax.comm.UnsupportedCommOperationException.
> Now, in RXTX 2.1 the namespace has changed in gnu.io,
> so the modbus library doesn't work anymore (it look
> for things in javax.comm). I've already sent an email
> to fieldtalk to see if they are aware of the problem.
> The solution should be to use JavaComm + RXTX 2.0. But
> I've read somewhere that JavaComm 2.0 does not work
> with Java 5.0 and JavaComm 3.0 does not work with RXTX
> 2.0 so I don't know what to do.
> 
> Any ideas?
> 
> Thanks Jack
> 
> PS: can you make a CC to my personal email
> (g_petrini at yahoo.it) too please?
> 
> Chiacchiera con i tuoi amici in tempo reale! 
>  http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  8 18:17:23 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 08 Jun 2006 17:17:23 -0700
Subject: [Rxtx] rxtx access is denied error
Message-ID: <4488BE13.2050706@dupreeinc.com>

Hello,

I have been trying to replace the commapi from sun with rxtx for a 
project that communicates with a serial port that is a USB-Serial 
interface.  To be exact, I am using the FTDI VCP driver with one of 
their modules connected to a windows XP system.

I have the RXTX package working pretty well as long as nothing goes wrong.

If a user disconnects the USB port while my java application is running, 
my application goes into an endless loop with lots of messages in the  
errors stream  like the ones below:

    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(481):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.


I believe when this happens the COM port completely disappears and the 
rxtx driver has a heart attack.  Obviously, the user should not do this, 
but my application needs to ideally, correct the situation or as a worse 
case, terminate with a little dignity.  Currently, I have not figured 
out how to catch this error.

The closest I have come is to trap an exception to my input stream read  
that says "No error in readByte"  This error appears to be outside of 
the endless loop of the errors listed above.

Does anybody have an idea of how to identify and trap this error?  Any 
suggestions on how to gracefully recover from it would be greatly 
appreciated!

Thank you for your time,

Doug Thistlethwaite




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060608/9cfca302/attachment-0013.html

From tjarvi at qbang.org  Thu Jun  8 20:54:17 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 8 Jun 2006 20:54:17 -0600 (MDT)
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <4488BE13.2050706@dupreeinc.com>
References: <4488BE13.2050706@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606082022580.1323@www>

On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I have been trying to replace the commapi from sun with rxtx for a project 
> that communicates with a serial port that is a USB-Serial interface.  To be 
> exact, I am using the FTDI VCP driver with one of their modules connected to 
> a windows XP system.
>
> I have the RXTX package working pretty well as long as nothing goes wrong.
>
> If a user disconnects the USB port while my java application is running, my 
> application goes into an endless loop with lots of messages in the  errors 
> stream  like the ones below:
>
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(481):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>
>
> I believe when this happens the COM port completely disappears and the rxtx 
> driver has a heart attack.  Obviously, the user should not do this, but my 
> application needs to ideally, correct the situation or as a worse case, 
> terminate with a little dignity.  Currently, I have not figured out how to 
> catch this error.
>
> The closest I have come is to trap an exception to my input stream read  that 
> says "No error in readByte"  This error appears to be outside of the endless 
> loop of the errors listed above.
>
> Does anybody have an idea of how to identify and trap this error?  Any 
> suggestions on how to gracefully recover from it would be greatly 
> appreciated!
>

Hi Doug

Sadly I don't have a quick solution for you.

Termios has no knowlage about the JVM so it wont be throwing exceptions 
you can catch.

We can return error and set the error number to something reasonable that 
results in an exception.  The No Error message simply means we did not set 
an error number in termios.c.  Those are the line numbers in the code you 
see.  SerialImp.c realizes it errored but does not know much more yet. 
Everything touching the file descriptor is going to error after the port 
is gone presumably.

We don't currently have a plan in place for vanishing (or appearing) com 
ports.

Another example of what we need to think about is what happens if you 
start your application and then plug in the dongle?  Or what if you unplug 
and then plug it in again?

So in each of these three cases, what would the behavior of the (yet to 
be) correct implementation do?

How will the enumerated ports be handled during these changes?

There can also be hints from the OS that could be taken into 
consideration.

We can probably get some exceptions thrown that make sense and null the 
file descriptor when it happens to prevent io attempts.  That would be a 
crude way to let applications know something strange has happened.

Is anyone else tinkering with this problem?

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  9 01:31:29 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 9 Jun 2006 09:31:29 +0200
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <Pine.LNX.4.61.0606082022580.1323@www>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
Message-ID: <AC6EDDDD-0A64-401F-B16B-E484788CDF4A@buechse.de>

Hello Trent,

I am not tinkering with this on the Source Level - but I think it  
should work pretty much the same way as it currently does in OSX.  
When the port goes away you get an IOException thrown for any read/ 
write. It will no longer be in the list of ports from  
CommPortIdentifier.getPortIdentifiers(). When a port (re-)appears it  
is added to the list. It's up to the application to re-check the list  
from time to time.

On Windows you can't do much better then that, because the ports  
don't have useful names. Which USB "virtual com port" is on which  
COMx depends on the order the devices were added. So reconnecting to  
the same device may mean connecting to another port.

Regarding the exception thrown: it would be nice to use an  
IOException subclass but the Exception message should definetly be  
informative also as most applications may want to keep compatibility  
with javax.comm.

Regards,
Joachim


On 09.06.2006, at 04:54, Trent Jarvi wrote:

> On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:
>
>> Hello,
>>
>> I have been trying to replace the commapi from sun with rxtx for a  
>> project
>> that communicates with a serial port that is a USB-Serial  
>> interface.  To be
>> exact, I am using the FTDI VCP driver with one of their modules  
>> connected to
>> a windows XP system.
>>
>> I have the RXTX package working pretty well as long as nothing  
>> goes wrong.
>>
>> If a user disconnects the USB port while my java application is  
>> running, my
>> application goes into an endless loop with lots of messages in  
>> the  errors
>> stream  like the ones below:
>>
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (481):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>
>>
>> I believe when this happens the COM port completely disappears and  
>> the rxtx
>> driver has a heart attack.  Obviously, the user should not do  
>> this, but my
>> application needs to ideally, correct the situation or as a worse  
>> case,
>> terminate with a little dignity.  Currently, I have not figured  
>> out how to
>> catch this error.
>>
>> The closest I have come is to trap an exception to my input stream  
>> read  that
>> says "No error in readByte"  This error appears to be outside of  
>> the endless
>> loop of the errors listed above.
>>
>> Does anybody have an idea of how to identify and trap this error?   
>> Any
>> suggestions on how to gracefully recover from it would be greatly
>> appreciated!
>>
>
> Hi Doug
>
> Sadly I don't have a quick solution for you.
>
> Termios has no knowlage about the JVM so it wont be throwing  
> exceptions
> you can catch.
>
> We can return error and set the error number to something  
> reasonable that
> results in an exception.  The No Error message simply means we did  
> not set
> an error number in termios.c.  Those are the line numbers in the  
> code you
> see.  SerialImp.c realizes it errored but does not know much more yet.
> Everything touching the file descriptor is going to error after the  
> port
> is gone presumably.
>
> We don't currently have a plan in place for vanishing (or  
> appearing) com
> ports.
>
> Another example of what we need to think about is what happens if you
> start your application and then plug in the dongle?  Or what if you  
> unplug
> and then plug it in again?
>
> So in each of these three cases, what would the behavior of the  
> (yet to
> be) correct implementation do?
>
> How will the enumerated ports be handled during these changes?
>
> There can also be hints from the OS that could be taken into
> consideration.
>
> We can probably get some exceptions thrown that make sense and null  
> the
> file descriptor when it happens to prevent io attempts.  That would  
> be a
> crude way to let applications know something strange has happened.
>
> Is anyone else tinkering with this problem?
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From doug at dupreeinc.com  Fri Jun  9 13:09:58 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 09 Jun 2006 12:09:58 -0700
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <Pine.LNX.4.61.0606082022580.1323@www>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
Message-ID: <4489C786.9050504@dupreeinc.com>


Ideally, it would be nice if it would throw an exception and terminate 
the loop.  I am still trying to figure out how to detect the condition 
and recover form it in some form...  I am getting the "No error in 
readByte" exception in my serialEvent() method after an input stream 
read.  It appears to me that the only graceful recovery is to close the 
port and then reopen it when it becomes available.  I can pass the event 
up to the update method in my main frame, but I still can't close the 
port from within that thread.  Any suggestions on how to pass this event 
to a location where the port can be safely closed?

Re: Slow startup in windows XP
I have been looking into this a little closer and have found out the 
following:
System Windows XP Pro 3GHz dual core with 1GB RAM and NO parallel port.
Starting the SerialDemo included with the commapi using the rxtx instead 
of javax.comm takes 60 seconds.
Starting the SerialDemo using rxrx with the rxtxParallel.dll file 
removed takes about 20 seconds.
Modify initialize in RXRXCommDriver.java to not test the parallel ports 
takes less than 1 second.

It would be nice if the initialize routine could detect the presence of 
rxtxParallel.dll file and just skip the whole process if not present.  
Is there an easy way to check for the presence of this file without 
running the parallel port test?

Doug


 

Trent Jarvi wrote:

>On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:
>...
>  
>
>
>Hi Doug
>
>Sadly I don't have a quick solution for you.
>
>Termios has no knowlage about the JVM so it wont be throwing exceptions 
>you can catch.
>
>We can return error and set the error number to something reasonable that 
>results in an exception.  The No Error message simply means we did not set 
>an error number in termios.c.  Those are the line numbers in the code you 
>see.  SerialImp.c realizes it errored but does not know much more yet. 
>Everything touching the file descriptor is going to error after the port 
>is gone presumably.
>
>We don't currently have a plan in place for vanishing (or appearing) com 
>ports.
>
>Another example of what we need to think about is what happens if you 
>start your application and then plug in the dongle?  Or what if you unplug 
>and then plug it in again?
>
>So in each of these three cases, what would the behavior of the (yet to 
>be) correct implementation do?
>
>How will the enumerated ports be handled during these changes?
>
>There can also be hints from the OS that could be taken into 
>consideration.
>
>We can probably get some exceptions thrown that make sense and null the 
>file descriptor when it happens to prevent io attempts.  That would be a 
>crude way to let applications know something strange has happened.
>
>Is anyone else tinkering with this problem?
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060609/911ed787/attachment-0013.html

From Ugo.Landini at Sun.COM  Fri Jun  2 14:23:47 2006
From: Ugo.Landini at Sun.COM (Ugo Landini)
Date: Fri, 02 Jun 2006 22:23:47 +0200
Subject: [Rxtx] OSX 10.4.7 and usb
Message-ID: <44809E53.2070905@sun.com>

Hi, I have installed the library and the native libraries on OSX 10.4.7. 
Then I have run this simple code:

...
while (portList.hasMoreElements()) {
             portId = (CommPortIdentifier) portList.nextElement();
             System.out.println("-> " + portId.getName() + " Port Type:" 
+ portId.getPortType());
...

and the output is:

Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7

Ports found:
-> /dev/tty.Bluetooth-PDA-Sync Port Type:1
-> /dev/cu.Bluetooth-PDA-Sync Port Type:1
-> /dev/tty.Bluetooth-Modem Port Type:1
-> /dev/cu.Bluetooth-Modem Port Type:1

I can't see any USB ports... with javax.comm on linux I could see the 
/dev/ttyUSB stuff, but that's not the case with OSX. Any idea?

tia

uL


From tod at todbot.com  Sun Jun 11 12:04:37 2006
From: tod at todbot.com (Tod E. Kurt)
Date: Sun, 11 Jun 2006 11:04:37 -0700
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <44809E53.2070905@sun.com>
References: <44809E53.2070905@sun.com>
Message-ID: <E2EB14A1-20A7-4611-8F1A-E3D2ABE41F48@todbot.com>

A dumb question, but: do you have the USB serial adapters plugged  
in?  They only show up in /dev when plugged in.  Also, you can verify  
they exist independent of RXTX by doing something like "ls -l /dev/ 
cu.*".

On Jun 2, 2006, at 1:23 PM, Ugo Landini wrote:

> Hi, I have installed the library and the native libraries on OSX  
> 10.4.7.
> Then I have run this simple code:
>
> ...
> while (portList.hasMoreElements()) {
>              portId = (CommPortIdentifier) portList.nextElement();
>              System.out.println("-> " + portId.getName() + " Port  
> Type:"
> + portId.getPortType());
> ...
>
> and the output is:
>
> Experimental:  JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
>
> Ports found:
> -> /dev/tty.Bluetooth-PDA-Sync Port Type:1
> -> /dev/cu.Bluetooth-PDA-Sync Port Type:1
> -> /dev/tty.Bluetooth-Modem Port Type:1
> -> /dev/cu.Bluetooth-Modem Port Type:1
>
> I can't see any USB ports... with javax.comm on linux I could see the
> /dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>
> tia
>
> uL
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>



From lyon at docjava.com  Sun Jun 11 12:14:50 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Sun, 11 Jun 2006 14:14:50 -0400
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <44809E53.2070905@sun.com>
References: <44809E53.2070905@sun.com>
Message-ID: <p06020444c0b20de7d248@[192.168.1.152]>

>Hi Ugo,

Do you have any USB serial ports (like the keyspan 19-HS) plugged
into the mac?
Thanks!
  - DL


>Hi, I have installed the library and the native libraries on OSX 10.4.7.
>Then I have run this simple code:
>
>...
>while (portList.hasMoreElements()) {
>              portId = (CommPortIdentifier) portList.nextElement();
>              System.out.println("-> " + portId.getName() + " Port Type:"
>+ portId.getPortType());
>...
>
>and the output is:
>
>Experimental:  JNI_OnLoad called.
>Stable Library
>=========================================
>Native lib Version = RXTX-2.1-7
>Java lib Version   = RXTX-2.1-7
>
>Ports found:
>-> /dev/tty.Bluetooth-PDA-Sync Port Type:1
>-> /dev/cu.Bluetooth-PDA-Sync Port Type:1
>-> /dev/tty.Bluetooth-Modem Port Type:1
>-> /dev/cu.Bluetooth-Modem Port Type:1
>
>I can't see any USB ports... with javax.comm on linux I could see the
>/dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>
>tia
>
>uL
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx



From dmarkman at mac.com  Sun Jun 11 14:30:27 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Sun, 11 Jun 2006 16:30:27 -0400
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <p06020444c0b20de7d248@[192.168.1.152]>
References: <44809E53.2070905@sun.com> <p06020444c0b20de7d248@[192.168.1.152]>
Message-ID: <B9C1606B-4339-4564-A175-FE83DFFA7D76@mac.com>

afaik
10.4.7 wasn't released yet
it will soon, no doubts


On Jun 11, 2006, at 2:14 PM, Dr. Douglas Lyon wrote:

>> Hi Ugo,
>
> Do you have any USB serial ports (like the keyspan 19-HS) plugged
> into the mac?
> Thanks!
>   - DL
>
>
>> Hi, I have installed the library and the native libraries on OSX  
>> 10.4.7.
>> Then I have run this simple code:
>>
>> ...
>> while (portList.hasMoreElements()) {
>>              portId = (CommPortIdentifier) portList.nextElement();
>>              System.out.println("-> " + portId.getName() + " Port  
>> Type:"
>> + portId.getPortType());
>> ...
>>
>> and the output is:
>>
>> Experimental:  JNI_OnLoad called.
>> Stable Library
>> =========================================
>> Native lib Version = RXTX-2.1-7
>> Java lib Version   = RXTX-2.1-7
>>
>> Ports found:
>> -> /dev/tty.Bluetooth-PDA-Sync Port Type:1
>> -> /dev/cu.Bluetooth-PDA-Sync Port Type:1
>> -> /dev/tty.Bluetooth-Modem Port Type:1
>> -> /dev/cu.Bluetooth-Modem Port Type:1
>>
>> I can't see any USB ports... with javax.comm on linux I could see the
>> /dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>>
>> tia
>>
>> uL
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman



From tjarvi at qbang.org  Sun Jun 11 18:52:59 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 11 Jun 2006 18:52:59 -0600 (MDT)
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <4489C786.9050504@dupreeinc.com>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
	<4489C786.9050504@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606111845430.7274@www>

On Fri, 9 Jun 2006, Doug Thistlethwaite wrote:

>
> Ideally, it would be nice if it would throw an exception and terminate the 
> loop.  I am still trying to figure out how to detect the condition and 
> recover form it in some form...  I am getting the "No error in readByte" 
> exception in my serialEvent() method after an input stream read.  It appears 
> to me that the only graceful recovery is to close the port and then reopen it 
> when it becomes available.  I can pass the event up to the update method in 
> my main frame, but I still can't close the port from within that thread.  Any 
> suggestions on how to pass this event to a location where the port can be 
> safely closed?
>

I've gone through and cleaned up the termios.c layer.  I need to get to a 
windows machine with a USB dongle and see where the ioctl() is being 
called.  Probably the eventLoop.  But all of the ioctls should probably 
result in an IOException during this condition.

I'll probably finish this up Monday night when I can borrow a USB 
dongle.

There is no point in putting the code into CVS yet.  If you are tinkering 
I can mail the patch.  I think we will want to make a couple fixes in 
SerialImp.c to handle errors before it's ready.

--
Trent Jarvi
tjarvi at qbang.org



From bob_tai2001 at yahoo.com  Mon Jun 12 09:42:14 2006
From: bob_tai2001 at yahoo.com (Bob Tai)
Date: Mon, 12 Jun 2006 08:42:14 -0700 (PDT)
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to RXTX
	again
Message-ID: <20060612154214.58219.qmail@web32804.mail.mud.yahoo.com>


thank you Paul, Joachim, Trent and everyone try to
workout the java comm and Rxtx situation.  At least
now I have something that is solid enough to make my
decision.  

thank you,
     Bob

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From Ralph.Buchfelder at gmx.net  Mon Jun 12 15:30:20 2006
From: Ralph.Buchfelder at gmx.net (Ralph Buchfelder)
Date: Mon, 12 Jun 2006 23:30:20 +0200
Subject: [Rxtx] rxtx binaries or porting to XSCALE Windows Mobile 2003 / 2005
Message-ID: <448DDCEC.7090506@gmx.net>

dear group,

i have been carefully reading your homepage, wiki and archives
but there seems to be no detailled information on porting to Windows 
Mobile/CE.

as far as i understood from the 'porting' section you can do porting to 
winCE. but how? do i only need to obtain the sourcecode (which one?) and 
compile this in Microsoft eMbedded Visual C++ for ARM/Xscale?
Any other ways?


unfortunately i must admit that i do have little linux skills but i have 
made my way through gcc and makefiles. right now i need to implement com 
  communication in a J2ME application and found your website as >the< 
solution.

best regards
Ralph Buchfelder

University of Regensburg
Department of Geography

PS: i dont care about Javacomm compliancy (ie. 2.0 or 2.1) - i just need 
a working serial port API in IBM J9 VM.


From paul.klissner at sun.com  Wed Jun 14 18:12:58 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Wed, 14 Jun 2006 17:12:58 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
Message-ID: <4490A60A.9090305@sun.com>

Hello RxTx community,

I finally think I have a compromise in place that will stand in the gap.

If you go to http://www.sun.com and search for javax.comm, you'll
get taken to a download page, where now users can get a copy of the
comm.jar file out of 2.0.3, along with just a license and a README.

I trust this will suffice until such time as RxTx decided to implement
their own java classes or we can get a JSR going to mitigate some
of the problems (the readme in the comm.jar 2.0.3 zip file
contains my thoughts on that).

Thanks,
Paul



From tjarvi at qbang.org  Wed Jun 14 21:15:35 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 14 Jun 2006 21:15:35 -0600 (MDT)
Subject: [Rxtx] rxtx-2.0-7 (final) src is in CVS
Message-ID: <Pine.LNX.4.61.0606142100500.2742@www>


I wasn't expecting to be working on rxtx 2.0 tonight :)

Thanks go out to Paul Klissner for his work in making the coming release 
of rxtx-2.0-7 possible for users that require package javax.comm on many 
platforms.

Most people know that rxtx 2.0 is for use with Sun's CommAPI 2.0 for 
Solaris or the Generic CommAPI 2.0-3 available for download at Sun.  If 
you need javax.comm packages on many platforms, you are probably 
interested.  If you use rxtx 2.1 in package gnu.io, then you are not going 
to care much.

I've tried to update the rxtx 2.0 src directory in preparation for 
rxtx-2.0-7 (final).  Linux should compile.  Windows will compile if you 
generate your own .def files (I'll generate these tomorrow).  If you have 
some time to do basic testing of the source, I'd appreciate it.  The 
source should be good but you may find classes not found.  This source is 
a backport from rxtx 2.1.

I wanted to get things started so anyone interested on Mac OS X could get 
a head start.

All of this is in CVS.  http://www.rxtx.org/cvs.html

I suspect we will have binaries for testing in a couple days if you are 
unable to compile.   Consider this a smoke test.

--
Trent Jarvi
tjarvi at qbang.org


From legolas.w at gmail.com  Wed Jun 14 22:04:28 2006
From: legolas.w at gmail.com (Legolas Woodland)
Date: Wed, 14 Jun 2006 21:04:28 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <4490A60A.9090305@sun.com>
References: <4490A60A.9090305@sun.com>
Message-ID: <87ee9b170606142104p745fcef0vea622fbc8f528bfc@mail.gmail.com>

is there anything new in this version of javax.comm ?
thanks


On 6/14/06, Paul Klissner <paul.klissner at sun.com> wrote:
>
> Hello RxTx community,
>
> I finally think I have a compromise in place that will stand in the gap.
>
> If you go to http://www.sun.com and search for javax.comm, you'll
> get taken to a download page, where now users can get a copy of the
> comm.jar file out of 2.0.3, along with just a license and a README.
>
> I trust this will suffice until such time as RxTx decided to implement
> their own java classes or we can get a JSR going to mitigate some
> of the problems (the readme in the comm.jar 2.0.3 zip file
> contains my thoughts on that).
>
> Thanks,
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060614/5ff4dfbc/attachment-0013.html

From joachim at buechse.de  Thu Jun 15 07:22:48 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 15 Jun 2006 15:22:48 +0200
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
Message-ID: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>

Good day!

Some of my users report problems using RXTX 2.1.7 on Windows98 to  
communicate with an FTDI FT245BM chip (using their latest VCP  
driver). Either no ports are being shown (ie returned form  
CommPortIdentifier.getPortIdentifiers()) or the transfers fail.

Did anyone run into similar Problems with Win98??

Best regards,
Joachim



From ajmas at sympatico.ca  Thu Jun 15 08:12:28 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Thu, 15 Jun 2006 10:12:28 -0400
Subject: [Rxtx] API change question
Message-ID: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

How closely do you follow the Java Communication API spec? The reason I ask is because I would be interested in augmenting the CommPortIdentifier class to include a getDisplayName() method. By default it would return the same value as getName(), but would provide the possibility of displaying a 'user friendly' name, for platforms where the display name is not the same as the device name. An example of this is on MacOS X, where currently the names seem to be of the form /dev/cu.* and /dev/tty.*, yet what the expects to see is simply the part after the full-stop. Although I could move this logic into the Java code, it would be nice to see it transparent to the Java code.

Andre




From ajmas at sympatico.ca  Thu Jun 15 08:16:22 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Thu, 15 Jun 2006 10:16:22 -0400
Subject: [Rxtx] Package to use
Message-ID: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

While the Java API spec refers to javax.comm, I see that only gnu.io is provide by the rxtx project. Should our projects refer to the gnu.io package or the javax.comm API?

Andre



From joachim at buechse.de  Thu Jun 15 08:45:05 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 15 Jun 2006 16:45:05 +0200
Subject: [Rxtx] API change question
In-Reply-To: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>

Hello Andre,

the /dev/cu and /dev/tty have different semantics on OS X. It is much  
more than a simply naming issue to unify them, see my recent mail to  
the list...

Best regards,
Joachim


On 15.06.2006, at 16:12, Andre-John Mas wrote:

> Hi,
>
> How closely do you follow the Java Communication API spec? The  
> reason I ask is because I would be interested in augmenting the  
> CommPortIdentifier class to include a getDisplayName() method. By  
> default it would return the same value as getName(), but would  
> provide the possibility of displaying a 'user friendly' name, for  
> platforms where the display name is not the same as the device  
> name. An example of this is on MacOS X, where currently the names  
> seem to be of the form /dev/cu.* and /dev/tty.*, yet what the  
> expects to see is simply the part after the full-stop. Although I  
> could move this logic into the Java code, it would be nice to see  
> it transparent to the Java code.
>
> Andre
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From lyon at docjava.com  Thu Jun 15 10:16:29 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Thu, 15 Jun 2006 12:16:29 -0400
Subject: [Rxtx] cu.modem != /dev/ttya on mac.
In-Reply-To: <763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
	<763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>
Message-ID: <p0602046cc0b7378a95b0@[192.168.1.152]>

>Hi All,

I think that Joachim is correct. For the longest time,
I have been trying to figure out how to direct dial using
the cu.modem on the mac under os x.

As a less-than-optimal approach to auto-dialing, I have used
a keyspan USB 19HS adapter, along with an external modem, to
obtain the dialing feature.

Ideally, it would be better to dial with the built-in modem...but that did not
always seem to work, for some reason. Have others had some experience with
using the built in modem for dialing on the mac?

Thanks!
  - Doug


>Hello Andre,
>
>the /dev/cu and /dev/tty have different semantics on OS X. It is much?
>more than a simply naming issue to unify them, see my recent mail to?
>the list...
>
>Best regards,
>Joachim
>



From doug at dupreeinc.com  Thu Jun 15 14:52:50 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 15 Jun 2006 13:52:50 -0700
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
In-Reply-To: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
References: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
Message-ID: <4491C8A2.8090108@dupreeinc.com>

Hi Joachim,

I have been doing a lot with the new FTDI driver with win XP and have 
not had that particular problem.  I did notice that the new driver 
(dated May19th, 2006) is only for XP, Server 2003, and 2000.  Are they 
trying to use the 2.00.00 drivers or the old 1.09.06 version.  I am 
using a FT232R based module, but it uses the same drivers and I assume 
it would have the same problems.  Let me know which driver they are 
using and I can load up a 98 system here and see if  I can duplicate the 
problem.

Doug

Joachim Buechse wrote:

>Good day!
>
>Some of my users report problems using RXTX 2.1.7 on Windows98 to  
>communicate with an FTDI FT245BM chip (using their latest VCP  
>driver). Either no ports are being shown (ie returned form  
>CommPortIdentifier.getPortIdentifiers()) or the transfers fail.
>
>Did anyone run into similar Problems with Win98??
>
>Best regards,
>Joachim
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From matthewhepp at yahoo.com  Thu Jun 15 17:34:47 2006
From: matthewhepp at yahoo.com (Matthew Hepp)
Date: Thu, 15 Jun 2006 16:34:47 -0700 (PDT)
Subject: [Rxtx] Wither the XCode project?
Message-ID: <20060615233447.48064.qmail@web50311.mail.yahoo.com>

Either I don't know how to properly use CVS (entirely possibl), or the XCode
project is not making through the update properly. Doing a "cvs update" against
2.1-7 creates an XCode folder in MACOSX_IDE, and therein a
LibSerialUniversal.xcodeproj, but trying to open it yields a "Unable to Open
Project - Project rxtx-devel/MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj
cannot be opened because it is missing its project.pbxproj file" error. Showing
package contents reveals just the cvs-related files. Perhaps this is why
previous xcode projects have been saved as an sit.hqx - to retain the resource
fork?

Can someone point me in the right direction?

Thanks,

Matt

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Thu Jun 15 19:53:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 19:53:06 -0600 (MDT)
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
In-Reply-To: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
References: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
Message-ID: <Pine.LNX.4.61.0606151944070.23137@www>

On Thu, 15 Jun 2006, Joachim Buechse wrote:

> Good day!
>
> Some of my users report problems using RXTX 2.1.7 on Windows98 to
> communicate with an FTDI FT245BM chip (using their latest VCP
> driver). Either no ports are being shown (ie returned form
> CommPortIdentifier.getPortIdentifiers()) or the transfers fail.
>
> Did anyone run into similar Problems with Win98??
>

Hi Joachim

It has been a long time since I've tested win98.  I know rxtx-2.1-7pre16 
did get testing on win98 with ~jdk 1.3 though.  I wonder if jdks are still 
tested on that platform.

With win98 you usually have older boxes.  They can be short on CPU and 
memory.  Enumeration should work but I could picture runtime performance 
issues on win98.

The enumeration problems could result from other copies of your 
application if various states of decay still holding onto the port.  When 
things go wrong, people also like to open other terminal software to see 
whats going on which can interfere.  You can't open a windows port with 
two apps.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Thu Jun 15 20:08:53 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 20:08:53 -0600 (MDT)
Subject: [Rxtx] API change question
In-Reply-To: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606151954270.23137@www>

On Thu, 15 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> How closely do you follow the Java Communication API spec?

I can explain how this worked in the past.  How we do it in the future is 
open for discussion.

In the past we have tried to follow it as close as possible in gnu.io 
(rxtx 2.1).  We have added extensions but try to discourage their use. 
The extensions are clearly marked as such in the source code and javadocs.

rxtx 2.0 was intended to be a strict implementation of part of the spec. 
We let Sun's interfaces decide what methods can be called. There are 
differences not covered by the spec such as default values.  Thats not 
intentional but rather hard to avoid.

--
Trent Jarvi
tjarvi at qbang.org





From tjarvi at qbang.org  Thu Jun 15 21:09:11 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 21:09:11 -0600 (MDT)
Subject: [Rxtx] Package to use
In-Reply-To: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606152026120.23137@www>

On Thu, 15 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> While the Java API spec refers to javax.comm, I see that only gnu.io is 
> provide by the rxtx project. Should our projects refer to the gnu.io 
> package or the javax.comm API?
>

Hi Andre

Lets see if I can give a fair and balanced answer to that.

If you are starting a new project and want to use RXTX, I would recommend 
using gnu.io.  The community support for gnu.io will not be going away 
anytime soon.  You can switch between gnu.io (2.1) and javax.comm (2.0) 
fairly easily.  They are not intended to be incompatible.  You just change 
package names and libs.

You can also consider the combination of rxtx 2.0 with Sun's commapi 
2.0-3.  This is considered a stop-gap measure by Sun for previous users of 
that combination.  Together rxtx 2.0 and Sun CommAPI 2.0 work in namespace 
javax.comm for programmers.

Finally, you can opt to just use Sun's oferrings in CommAPI 3.0 without 
rxtx.  That would be in namespace javax.comm also.  CommAPI 3.0 may be 
of more interest to you if you are looking at POS with Sun computers. 
Rxtx does not currently support the changes in CommAPI 3.0 or have firm 
plans to do so.  That does not mean we wouldn't implement them.  It just 
means nobody has contributed code yet.

You can't combine rxtx with CommAPI 3.0 for technical reasons that wont 
likely be fixed soon.

It's up to you as far as what you use.  We like to provide the freedom so 
you can choose.  Realistically, we will be supporting gnu.io mainly 
because we have some control over that name space and can support it.

Things may happen in the future that enable rxtx to provide more support 
in the javax namespace but that has not happened yet.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun 16 00:33:06 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 08:33:06 +0200
Subject: [Rxtx] Wither the XCode project?
In-Reply-To: <20060615233447.48064.qmail@web50311.mail.yahoo.com>
References: <20060615233447.48064.qmail@web50311.mail.yahoo.com>
Message-ID: <D30D660F-A49B-464E-AE4C-6B4563893682@buechse.de>

Hello Matthew,

could you please send me the contents of your

   rxtx-devel/CVS
   rxtx-devel/MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj/CVS

directories as a zip to my personal email address. This should  
indicate why the file is not checked out. I can see that it exists on  
the correct branch in the repository, so something must have gone  
wrong during the "cvs update"...

Best regards,
Joachim

On 16.06.2006, at 01:34, Matthew Hepp wrote:

> Either I don't know how to properly use CVS (entirely possibl), or  
> the XCode
> project is not making through the update properly. Doing a "cvs  
> update" against
> 2.1-7 creates an XCode folder in MACOSX_IDE, and therein a
> LibSerialUniversal.xcodeproj, but trying to open it yields a  
> "Unable to Open
> Project - Project rxtx-devel/MACOSX_IDE/XCode/ 
> LibSerialUniversal.xcodeproj
> cannot be opened because it is missing its project.pbxproj file"  
> error. Showing
> package contents reveals just the cvs-related files. Perhaps this  
> is why
> previous xcode projects have been saved as an sit.hqx - to retain  
> the resource
> fork?
>
> Can someone point me in the right direction?



From joachim at buechse.de  Fri Jun 16 10:41:20 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 18:41:20 +0200
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <p06230903c0b88613dca6@[10.0.1.7]>
References: <p06230903c0b88613dca6@[10.0.1.7]>
Message-ID: <03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>

Hello Bob,

until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was  
behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if  
Trent has migrated all recent changes from 2.1 to 2.0.

I have added the XCode project and updated documentation only to the  
gnu.io branch. Once the 2.0 implementation is up to date I will copy  
over the documentation/build files make them work.

Best regards,
Joachim

On 16.06.2006, at 18:07, Bob Jacobsen wrote:

> I'm one of the developers for the JMRI project, which provides  
> model railroad software in Java.  We've been using RXTX to provide  
> serial port access on MacOS X and Linux; we use the old javax.comm  
> 2.0 on Windows, OS/2 and Solaris.  Because of that, we need to stay  
> with RXTX 2.0, not 2.1
>
> We've been using the 2.0-pre17 installer for a long time, but it's  
> not compatible with Intel macs.
>
> Can you point me to where I can find the right files for RXTX 2.0  
> to package with the program?
>
> The current situation is confusing to me.  I've been pointed to  
> recent 2.1 versions (but we need the javax.comm names), to an even  
> older installer, etc.  I've been reading that some versions require  
> an installer, and others don't, but I haven't been able to figure  
> out which (if any) of those are where in CVS.
>
> I'd really appreciate a clear statement of what files to use and  
> what to do with them that I can pass on to our users.
>
> I'm more than happy to put files in the local classpath, have users  
> run an installer, or anything else.  Whatever is easiest for you.
>
> Thanks!  I really appreciate all that you do to keep RXTX working.
>
> Bob
> -- 
> Bob Jacobsen +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG



From joachim at buechse.de  Fri Jun 16 09:59:28 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 17:59:28 +0200
Subject: [Rxtx] Wither the XCode project?
In-Reply-To: <20060616150240.49464.qmail@web50309.mail.yahoo.com>
References: <20060616150240.49464.qmail@web50309.mail.yahoo.com>
Message-ID: <D9935E05-2B83-488D-86DD-42599E229052@buechse.de>

Hello Matthew,

you have checked out the trunk (which is the 2.0.7 javax.comm.xxx  
release). For rxtx-2.1.7 (gnu.io.xxx release) you need to check out  
the branch

      commapi-0-0-1

The easiest way to do this is to download the rxtx src archive,  
unpack it and then do a cvs up inside the decompressed tree.  
Optionally you could do a

      cvs co -r commapi-0-0-1

but this will take much longer!

Best regards,
Joachim

When you do a cvs status it will show the sticky tag.

41:~/jdevelop/rxtx-2.1-7r2 joachim$ cvs status README.OSX
===================================================================
File: README.OSX        Status: Up-to-date

    Working revision:    1.1.2.1
    Repository revision: 1.1.2.1 /usr/local/cvsroot/rxtx-devel/Attic/ 
README.OSX,v
    Sticky Tag:          commapi-0-0-1 (branch: 1.1.2)
    Sticky Date:         (none)
    Sticky Options:      (none)




On 16.06.2006, at 17:02, Matthew Hepp wrote:

> %cvs status README.MACOSX
> ===================================================================
> File: README.MACOSX     Status: Up-to-date
>
>    Working revision:    1.1
>    Repository revision: 1.1     /usr/local/cvsroot/rxtx-devel/ 
> README.MACOSX,v
>    Sticky Tag:          (none)
>    Sticky Date:         (none)
>    Sticky Options:      (none)



From tjarvi at qbang.org  Fri Jun 16 16:31:18 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Fri, 16 Jun 2006 16:31:18 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
Message-ID: <Pine.LNX.4.61.0606161630030.14139@www>

On Fri, 16 Jun 2006, Joachim Buechse wrote:

> Hello Bob,
>
> until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was
> behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if
> Trent has migrated all recent changes from 2.1 to 2.0.
>

The src/ directory and configure.in/configure files should be fine.  I 
have not touched the Mac OS X directories.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sat Jun 17 02:39:55 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sat, 17 Jun 2006 10:39:55 +0200
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <Pine.LNX.4.61.0606161630030.14139@www>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
Message-ID: <350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>

Hello Trent,

apparently the IOEXCL changes have not made it into 2.0. I will add  
them to achieve a minimal diff between 2.0 and 2.1.

One other thing that bugs me for a while...

Shouldn't we replace "if !defined(TIOCSERGETLSR) && !defined(WIN32)"  
by a definition of its own "if defined(DRAINTHREAD)"? I think this  
would make the code clearer for people starting to read it.

Regards,
Joachim


On 17.06.2006, at 00:31, Trent Jarvi wrote:

> On Fri, 16 Jun 2006, Joachim Buechse wrote:
>
>> Hello Bob,
>>
>> until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was
>> behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if
>> Trent has migrated all recent changes from 2.1 to 2.0.
>>
>
> The src/ directory and configure.in/configure files should be fine.  I
> have not touched the Mac OS X directories.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From tropicsu at hotmail.com  Sat Jun 17 09:32:48 2006
From: tropicsu at hotmail.com (Yoke K)
Date: Sat, 17 Jun 2006 15:32:48 +0000
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
Message-ID: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>

Hi,

I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to work with 
MAC OS X.
I am using iTegno 3000 - USB GPRS Modem.

Files in /dev and a symbolic link as follows:

crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 -> tty.usbserial

In my SendMessage.java, I have this line:
CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");

Appreciate any help ?

- Jon


Errors as follows:

>>INFO: SMSLib API for Java / v1.2.2
>>INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>INFO: JRE Version: 1.5.0_06
>>INFO: JRE Impl Version: 1.5.0_06-64
>>INFO: O/S: Mac OS X / ppc / 10.4.6
>>INFO: Using Wavecom (Generic) AT handler.

SendMessage(): Send a message.
  Using SMSLib API for Java v1.2.2

Connecting ..... :
>>INFO: CSerialDriver(): Connecting...
Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
>>INFO: CSerialDriver(): Disconnecting...
gnu.io.NoSuchPortException
        at 
gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:218)
        at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
        at org.smslib.CService.connect(CService.java:197)
        at SendMessage.main(SendMessage.java:38)

_________________________________________________________________
Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/



From tjarvi at qbang.org  Sat Jun 17 10:12:30 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 10:12:30 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
	<350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
Message-ID: <Pine.LNX.4.61.0606171010060.14139@www>

On Sat, 17 Jun 2006, Joachim Buechse wrote:

> Hello Trent,
>
> apparently the IOEXCL changes have not made it into 2.0. I will add
> them to achieve a minimal diff between 2.0 and 2.1.
>

Hi Joachim

As I recall the IOEXCL change was after 2.1-7.  I was just syncing with 
2.1-7.  We can release 2.1-8 and 2.0-8 with the same changes.

> One other thing that bugs me for a while...
>
> Shouldn't we replace "if !defined(TIOCSERGETLSR) && !defined(WIN32)"
> by a definition of its own "if defined(DRAINTHREAD)"? I think this
> would make the code clearer for people starting to read it.
>


Sure.  We can do that for -8.  The TIOCSERGETLSR code should be a special 
case not the expected.  I think only Linux uses it.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Sat Jun 17 10:48:21 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 10:48:21 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <Pine.LNX.4.61.0606171010060.14139@www>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
	<350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
	<Pine.LNX.4.61.0606171010060.14139@www>
Message-ID: <Pine.LNX.4.61.0606171047310.14139@www>

On Sat, 17 Jun 2006, Trent Jarvi wrote:

> On Sat, 17 Jun 2006, Joachim Buechse wrote:
>
>> Hello Trent,
>>
>> apparently the IOEXCL changes have not made it into 2.0. I will add
>> them to achieve a minimal diff between 2.0 and 2.1.
>>
>
> Hi Joachim
>
> As I recall the IOEXCL change was after 2.1-7.  I was just syncing with
> 2.1-7.  We can release 2.1-8 and 2.0-8 with the same changes.
>

We could just move to 2.1-8 and 2.0-8.

--
Trent Jarvi
tjarvi at qbang.org


From brian.t.lamb at gmail.com  Tue Jun 13 13:54:13 2006
From: brian.t.lamb at gmail.com (Brian Lamb)
Date: Tue, 13 Jun 2006 15:54:13 -0400
Subject: [Rxtx] Windows XP Installation
Message-ID: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>

I've not installed Java packages on Windows before and am unsure how to
proceed. All the documentation I've seen provides detailed instructions on
how to install on Linux or Solaris. I was wondering how to install rxtx on
Windows XP.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060613/6f68cd5c/attachment-0013.html

From tjarvi at qbang.org  Sat Jun 17 13:57:03 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 13:57:03 -0600 (MDT)
Subject: [Rxtx] Windows XP Installation
In-Reply-To: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>
References: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0606171356120.14139@www>

On Tue, 13 Jun 2006, Brian Lamb wrote:

> I've not installed Java packages on Windows before and am unsure how to
> proceed. All the documentation I've seen provides detailed instructions on
> how to install on Linux or Solaris. I was wondering how to install rxtx on
> Windows XP.
>

Hi Brian

Which rxtx version are you trying to install?

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sun Jun 18 10:41:44 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sun, 18 Jun 2006 18:41:44 +0200
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
References: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
Message-ID: <8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>

Hello Jon,

 From OSX's standpoint a symbolic link is not a device (as far as I  
know). What stops you from using tty.usbserial? Did you try hard- 
linking?

Regards,
Joachim

On 17.06.2006, at 17:32, Yoke K wrote:
> Hi,
>
> I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to  
> work with
> MAC OS X.
> I am using iTegno 3000 - USB GPRS Modem.
>
> Files in /dev and a symbolic link as follows:
>
> crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
> crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
> lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->  
> tty.usbserial
>
> In my SendMessage.java, I have this line:
> CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
>
> Appreciate any help ?
>
> - Jon
>
>
> Errors as follows:
>
>>> INFO: SMSLib API for Java / v1.2.2
>>> INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>> INFO: JRE Version: 1.5.0_06
>>> INFO: JRE Impl Version: 1.5.0_06-64
>>> INFO: O/S: Mac OS X / ppc / 10.4.6
>>> INFO: Using Wavecom (Generic) AT handler.
>
> SendMessage(): Send a message.
>   Using SMSLib API for Java v1.2.2
>
> Connecting ..... :
>>> INFO: CSerialDriver(): Connecting...
> Experimental:  JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
>>> INFO: CSerialDriver(): Disconnecting...
> gnu.io.NoSuchPortException
>         at
> gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java: 
> 218)
>         at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
>         at org.smslib.CService.connect(CService.java:197)
>         at SendMessage.main(SendMessage.java:38)
>
> _________________________________________________________________
> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Sun Jun 18 10:56:55 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 12:56:55 -0400
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>
References: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
	<8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>
Message-ID: <7B6834E3-F41D-46B6-B979-55466BC73859@sympatico.ca>

Have you been able to get any other software to talk with your
modem? What port is it using? Have tried using the cu.usbserial
instead?

Andre

On 18-Jun-06, at 12:41 , Joachim Buechse wrote:

> Hello Jon,
>
>  From OSX's standpoint a symbolic link is not a device (as far as I
> know). What stops you from using tty.usbserial? Did you try hard-
> linking?
>
> Regards,
> Joachim
>
> On 17.06.2006, at 17:32, Yoke K wrote:
>> Hi,
>>
>> I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to
>> work with
>> MAC OS X.
>> I am using iTegno 3000 - USB GPRS Modem.
>>
>> Files in /dev and a symbolic link as follows:
>>
>> crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
>> crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
>> lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->
>> tty.usbserial
>>
>> In my SendMessage.java, I have this line:
>> CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
>>
>> Appreciate any help ?
>>
>> - Jon
>>
>>
>> Errors as follows:
>>
>>>> INFO: SMSLib API for Java / v1.2.2
>>>> INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>>> INFO: JRE Version: 1.5.0_06
>>>> INFO: JRE Impl Version: 1.5.0_06-64
>>>> INFO: O/S: Mac OS X / ppc / 10.4.6
>>>> INFO: Using Wavecom (Generic) AT handler.
>>
>> SendMessage(): Send a message.
>>   Using SMSLib API for Java v1.2.2
>>
>> Connecting ..... :
>>>> INFO: CSerialDriver(): Connecting...
>> Experimental:  JNI_OnLoad called.
>> Stable Library
>> =========================================
>> Native lib Version = RXTX-2.1-7
>> Java lib Version   = RXTX-2.1-7
>>>> INFO: CSerialDriver(): Disconnecting...
>> gnu.io.NoSuchPortException
>>         at
>> gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:
>> 218)
>>         at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
>>         at org.smslib.CService.connect(CService.java:197)
>>         at SendMessage.main(SendMessage.java:38)
>>
>> _________________________________________________________________
>> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Sun Jun 18 17:33:08 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 19:33:08 -0400
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
Message-ID: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>

Hi,

I am have a program that I wrote in Java to communicate with a  
Bluetooth GPS device. I am
trying to get this working on my Mac, but I keep getting told that:

gnu.io.PortInUseException: Unknown Application

but

portIdentifier.isCurrentlyOwned()

returns false and when I do lsof on the device I am trying to connect  
to, I see no application
using it. As the same time if I go to the command line and use  
minicom I have no issues. The
exception happens with this call:

CommPort commPort = portIdentifier.open(null,0);

Any suggestions?

Andre


From ajmas at sympatico.ca  Sun Jun 18 17:45:11 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 19:45:11 -0400
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
Message-ID: <30245B30-682D-4EAE-8084-8227B719F10D@sympatico.ca>

BTW My code snippet is:

     private InputStream connectToSerial () throws IOException,  
Exception
     {
         InputStream in = null;

         Enumeration portEnum = CommPortIdentifier.getPortIdentifiers();
         while ( portEnum.hasMoreElements() )
         {
             CommPortIdentifier portIdentifier = (CommPortIdentifier)  
portEnum.nextElement();
             System.out.println(portIdentifier.getName() + " - " +  
portIdentifier.getPortType() );
         }

         CommPortIdentifier portIdentifier =  
CommPortIdentifier.getPortIdentifier("/dev/cu.BTGPS-SPPslave-1");
         System.out.println("current owner: " +  
portIdentifier.getCurrentOwner());
         if ( portIdentifier.isCurrentlyOwned() )
         {
             System.out.println("Error: Port is currently in use");
             return null;
         }
         else
         {
             CommPort commPort = portIdentifier.open(this.getClass 
().getName(),2000);

             if ( commPort instanceof SerialPort )
             {
                 SerialPort serialPort = (SerialPort) commPort;
                 serialPort.setSerialPortParams 
(4800,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE 
);
                 in = serialPort.getInputStream();

                 return in;
             }
             else
             {
                 System.out.println("Error: Only serial ports are  
handled.");
             }
         }


         return in;
     }


On 18-Jun-06, at 19:33 , Andr?-John Mas wrote:

> Hi,
>
> I am have a program that I wrote in Java to communicate with a
> Bluetooth GPS device. I am
> trying to get this working on my Mac, but I keep getting told that:
>
> gnu.io.PortInUseException: Unknown Application
>
> but
>
> portIdentifier.isCurrentlyOwned()
>
> returns false and when I do lsof on the device I am trying to connect
> to, I see no application
> using it. As the same time if I go to the command line and use
> minicom I have no issues. The
> exception happens with this call:
>
> CommPort commPort = portIdentifier.open(null,0);
>
> Any suggestions?
>
> Andre
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From joachim at buechse.de  Mon Jun 19 05:54:49 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 13:54:49 +0200
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de>

This is most likely due to a problem with lock files. If you have  
downloaded the binaries of 2.17 rxtx will try to create non-standard  
lock files on OSX. We have since changed the code to use OSX device  
locking - however the binaries have not been updated yet. The 2.18  
release fixing this issue is due shortly.

Regards,
Joachim

On 19.06.2006, at 01:33, Andr?-John Mas wrote:

> Hi,
>
> I am have a program that I wrote in Java to communicate with a
> Bluetooth GPS device. I am
> trying to get this working on my Mac, but I keep getting told that:
>
> gnu.io.PortInUseException: Unknown Application
>
> but
>
> portIdentifier.isCurrentlyOwned()
>
> returns false and when I do lsof on the device I am trying to connect
> to, I see no application
> using it. As the same time if I go to the command line and use
> minicom I have no issues. The
> exception happens with this call:
>
> CommPort commPort = portIdentifier.open(null,0);
>
> Any suggestions?
>
> Andre
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From joachim at buechse.de  Mon Jun 19 06:44:27 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 14:44:27 +0200
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <4490A60A.9090305@sun.com>
References: <4490A60A.9090305@sun.com>
Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>

Hello Paul,

I just downloaded the "generic" javax.comm version now available. A  
first check indicates, that it was compiled with a JDK 1.4 javac  
without setting the target classfile version. In other words in can  
not be loaded by 1.1-1.3 VMs (or PersonalJava).

Do you see any chance to provide a version compiled with classfile  
format 45.3 (ie JVM1.1).

---
52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose  
javax.comm.SerialPort | head -5
Compiled from "SerialPort.java"
public abstract class javax.comm.SerialPort extends javax.comm.CommPort
   SourceFile: "SerialPort.java"
   minor version: 0
   major version: 48
---

Best regards,
Joachim


On 15.06.2006, at 02:12, Paul Klissner wrote:

> Hello RxTx community,
>
> I finally think I have a compromise in place that will stand in the  
> gap.
>
> If you go to http://www.sun.com and search for javax.comm, you'll
> get taken to a download page, where now users can get a copy of the
> comm.jar file out of 2.0.3, along with just a license and a README.
>
> I trust this will suffice until such time as RxTx decided to implement
> their own java classes or we can get a JSR going to mitigate some
> of the problems (the readme in the comm.jar 2.0.3 zip file
> contains my thoughts on that).
>
> Thanks,
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Mon Jun 19 09:11:45 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Mon, 19 Jun 2006 11:11:45 -0400
Subject: [Rxtx] Examples added to Wiki
Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

I have added a couple of examples to the Wiki:

http://rxtx.qbang.org/wiki/index.php/Examples

If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :)

Andre



From paul.klissner at sun.com  Mon Jun 19 10:42:47 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Mon, 19 Jun 2006 09:42:47 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>
References: <4490A60A.9090305@sun.com>
	<03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>
Message-ID: <4496D407.1090609@sun.com>

Joachim Buechse wrote:
> Hello Paul,
> 
> I just downloaded the "generic" javax.comm version now available. A  
> first check indicates, that it was compiled with a JDK 1.4 javac  
> without setting the target classfile version. In other words in can  
> not be loaded by 1.1-1.3 VMs (or PersonalJava).
> 
> Do you see any chance to provide a version compiled with classfile  
> format 45.3 (ie JVM1.1).
> 
> ---
> 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose  
> javax.comm.SerialPort | head -5
> Compiled from "SerialPort.java"
> public abstract class javax.comm.SerialPort extends javax.comm.CommPort
>    SourceFile: "SerialPort.java"
>    minor version: 0
>    major version: 48
> ---

I cannot promise when I can do that. Since we thought we were done
with javax.comm, the build environment got moved around, and right
now it doesn't even compile in it's new home.  I tried and it was
not cooperative at all. I was never impressed with that workspace
(in fact far far from it, it is a mess, which is why I migrated 3.0
to ant and never looked back).  It will take some real determination
for me to rebuild it, and frankly, right now I'm swamped.  If I can
find a bit of time over the next few weeks to do it, and it isn't
too bad an ordeal, I will.

Posting that will give me an excuse to post javax.comm 3.0, Update 2 as
well, while I'm working with the people who put content up on our
download center.  The only reason for a new update to 3.0 is that
I've changed the distribution to provide ispt (Interactive Serial
Port Tool), such that it can be launched as soon as the zip file
is unpacked, via a provided script.  ISPT is a command line
interactive tool for  manipulating one or two serial port,
sending data, managing events, etc... I've found it to be so useful
for doing certain kinds of validation  that I assume others will
find it useful to.  ISPT is already in 3.0u1, but one has to set
up their own classpath and launch it and since few people ever read
the documentation most won't know about it.  I've added the ability
to set stop bits and parity since 3.0u1 too.  But I digress.

Paul


From joachim at buechse.de  Mon Jun 19 11:01:28 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 19:01:28 +0200
Subject: [Rxtx] load mechanism of 2.0x
Message-ID: <CFD1440C-21AA-4D3B-9EA6-270D0FF9D6FC@buechse.de>

Good day,

I am trying to figure out, how the 2.0x distribution interacts with  
Suns implementation of javax.comm.CommPortIdentifier.

1) Apparently one can put javax.comm.properties in {java.home}/lib
2) The javax.comm package also reacts to -Djavax.comm.properties="...."

Looking at the javap output it also seems like CommPortIdentifier  
tries to find it's jar file and load the properties from there??


What I'm really looking for is a solution that allows using  
javax.comm with RXTX without modifying the VM installation. So I  
would prefer not to use 1) but I can't figure out how to use 2).

Any hints are welcome,
Joachim



From bob_tai2001 at yahoo.com  Mon Jun 19 15:00:35 2006
From: bob_tai2001 at yahoo.com (Bob Tai)
Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT)
Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place
	to start?
Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>

Hi, 

I got  rxtx Windows 2000 installed.  I did not use the
"best" way ... I just follow the insturuction and dump
the necessary files into the jre... I know it's "best"
idea, I got lazy didn't want to change my setting to
my Eclipse and classpath.

I was able to modify SimpleWrite.java to print on my
AddMaster serial printer.  I think I am ready to code!
But I need to make sure I can handle exceptions and so
on.  I notice the \samples\NullDriver\  has two files
seems to have some of the require method done, should
I start coding from those file?  I like the idea it
has the "time out" and basic exceptions done.   I am
slowly digging into the samples, but if you think any
of the code from Sun is good to checkout please let me
know.

btw, http://rxtx.qbang.org/wiki/index.php/Examples/
was very helpful, wish there are more examples.

thank you,

    Bob


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Mon Jun 19 15:55:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT)
Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good
 place to start?
In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>
References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606191542260.14139@www>

> I am
> slowly digging into the samples, but if you think any
> of the code from Sun is good to checkout please let me
> know.
>

I think NullDriver.java was an example stub driver for implementing 
something like rxtx.  It has been a while.  Unless they have been updated, 
you will find the examples are very dated.  You can look at how they use 
the port but avoid the GUI and hard coded variables (number of ports for 
instance).

There was no Swing and nobody knew what requirements today's compilers 
would make on code.  The examples worked fine with jdk 1.1 but times have 
changed.

--
Trent Jarvi
tjarvi at qbang.org


From tropicsu at hotmail.com  Mon Jun 19 19:49:08 2006
From: tropicsu at hotmail.com (Yoke K)
Date: Tue, 20 Jun 2006 01:49:08 +0000
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
Message-ID: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>

An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/fa588f00/attachment-0004.html

From ajmas at sympatico.ca  Mon Jun 19 21:14:37 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Mon, 19 Jun 2006 23:14:37 -0400
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>
References: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>
Message-ID: <CA22AB2A-5712-458B-9984-68477C6042AF@sympatico.ca>

Regarding the PortInUseException, I had a similar issue and got
this response from the mailing list:

   http://mailman.qbang.org/pipermail/rxtx/Week-of- 
Mon-20060619/062838.html

Andre
On 19-Jun-06, at 21:49 , Yoke K wrote:

> Hi Andre, Joachim
>
> I have tried using /dev/tty.usbserial and also /dev/cu.usbserial  
> and it also reported error as  "gnu.io.PortInUseException".
>
> The iTegno modem works in windows environment. As I moving around  
> using my ibook and I need to get it work on MAC OS as well.
>
> >> INFO: SMSLib API for Java / v1.2.2
> >> INFO: Using port: /dev/tty.usbserial @ 115200 baud.
> >> INFO: JRE Version: 1.5.0_06
> >> INFO: JRE Impl Version: 1.5.0_06-64
> >> INFO: O/S: Mac OS X / ppc / 10.4.6
> >> INFO: Using Wavecom (Generic) AT handler.
>
> SendMessage(): Send a message.
> Using SMSLib API for Java v1.2.2
>
> Connecting ..... :
> >> INFO: CSerialDriver(): Connecting...
> Experimental: JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version = RXTX-2.1-7
> >> INFO: CSerialDriver(): Disconnecting...
> gnu.io.PortInUseException: Unknown Application
> at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354)
> at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1)
> at org.smslib.CService.connect(CService.java:197)
> at SendMessage.main(SendMessage.java:38)
>
> Thanks.
>
> - Jon
>
>
>
>
> ====================
>
> Hello Jon,
>
> From OSX's standpoint a symbolic link is not a device (as far as I
> know). What stops you from using tty.usbserial? Did you try hard-
> linking?
>
> Regards,
> Joachim
>
>
>
> From:  "Yoke K" <tropicsu at hotmail.com>
> To:  rxtx at qbang.org
> Subject:  RXTX-2.1-7 / MAC OS X / NoSuchPortException
> Date:  Sat, 17 Jun 2006 15:32:48 +0000
> >Hi,
> >
> >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to
> >work with MAC OS X.
> >I am using iTegno 3000 - USB GPRS Modem.
> >
> >Files in /dev and a symbolic link as follows:
> >
> >crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
> >crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
> >lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->
> >tty.usbserial
> >
> >In my SendMessage.java, I have this line:
> >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
> >
> >Appreciate any help ?
> >
> >- Jon
> >
> >
> >Errors as follows:
> >
> >>>INFO: SMSLib API for Java / v1.2.2
> >>>INFO: Using port: /dev/ttyS1 @ 56000 baud.
> >>>INFO: JRE Version: 1.5.0_06
> >>>INFO: JRE Impl Version: 1.5.0_06-64
> >>>INFO: O/S: Mac OS X / ppc / 10.4.6
> >>>INFO: Using Wavecom (Generic) AT handler.
> >
> >SendMessage(): Send a message.
> >  Using SMSLib API for Java v1.2.2
> >
> >Connecting ..... :
> >>>INFO: CSerialDriver(): Connecting...
> >Experimental:  JNI_OnLoad called.
> >Stable Library
> >=========================================
> >Native lib Version = RXTX-2.1-7
> >Java lib Version   = RXTX-2.1-7
> >>>INFO: CSerialDriver(): Disconnecting...
> >gnu.io.NoSuchPortException
> >        at
> >gnu.io.CommPortIdentifier.getPortIdentifier 
> (CommPortIdentifier.java:218)
> >        at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
> >        at org.smslib.CService.connect(CService.java:197)
> >        at SendMessage.main(SendMessage.java:38)
> >
> >_________________________________________________________________
> >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
> >
>
> Find love online with MSN Personals
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Tue Jun 20 02:35:24 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 10:35:24 +0200
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>

Hello everybody,

I have been fighting a bit with the javax.comm version of RXTX the  
last days. I am working on the README .OSX now and try to figure out  
which should be the "suggested" installation.

The facts:
------

- the "generic" comm.jar version of javax.comm which has been made re- 
available tries to load com.sun.comm.SolarisDriver
- this classname can be overridden ONLY by putting a file  
javax.comm.properties in {java.home}/lib
- if it is not overridden and SolarisDriver.class is not found  
CommPortIdentifier will be disfunctional (in particual it is not  
possible to add CommPort's via CommPortIdentifier.add).
- the license distributed with comm.jar does not allow the  
modification/addition of classes in javax.comm (however no mention of  
com.sun...)


What really bothers me is to suggest putting this config file in the  
"global" vm installation. This is particularly ugly on the Mac as  
there are several VM installations and the file may be forgotten.  
Additionally it may create versioning problems. I prefer an  
installation where all files are local to the application (even  
comm.jar).

In my opinion the ideal situation would be:
------

1) The author of a program compiles against javax.comm.
2a) For platforms supported by Sun the user is free to use the 3.0  
comm.jar download from Sun
2b) For platforms not supported by Sun the user adds RXTXComm.jar to  
the classpath of the application (and librxtxSerial.jnilib to the  
application directory). Also he will need the 2.0.3 generic comm.jar  
from Sun.
3) Nobody messes with the global VM installation.

Of course 2a) and 2b) could be handled by the author of the program  
via an appropriate installer. The author could also decide to always  
use RXTX and include the generic javax.comm classes as well as the  
RXTX classes in his application jar. [If he further uses an explicit  
call to System.load() he may even include the jnilib(s) in the jar,  
extract it (based on the platform name) at runtime to a temp file and  
load it from there.]


Suggested solution:
------

We only need to put the following class in the classpath BEFORE Suns  
comm.jar

   package com.sun.comm;
   public class SolarisDriver extends gnu.io.RXTXCommDriver {
   }

This is not "the pure art" (TM). It depends on an implementation  
detail of the generic driver. However, so does the  
javax.comm.properties file - as we have seen when Sun released 3.0.  
It has the following advantages:

- The "generic" javax.comm implementation will happily load this  
class as its primary driver.
- No javax.comm.properties file is required.
- This does not violate the javax.comm license agreement as there is  
no mention of the "com.sun.comm" package in this license agreement at  
all.
- Authors packaging comm.jar with their application can strip out all  
com.sun.comm classes from comm.jar


Please comment!

Joachim



From joachim at buechse.de  Tue Jun 20 02:50:36 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 10:50:36 +0200
Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar
Message-ID: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>

There has been some discussions about the best way to install RXTX  
and where to place files.

I suggest that,

- we include the native libraries for the most common operating  
systems (in a special version of) RXTXcomm.jar
- we add loader code which tries to extract and load the platform  
specific binary at runtime
- on failure the current mechanism remains as a fallback

Wether the current mechanism should have priority (ie loadLibrary  
before load) remains to be discussed.


The advantages of this solution are
  - users of RXTX do not need to worry about java/platform specific  
file placement.
  - authors of applications may fully merge RXTX into their  
application jar (which provides a double-clickable application for  
Windows and OSX, Linux?).

Please comment,
Joachim

PS: Of course the suggested solution is already possible today,  
however relatively few programmers know how to correctly extract a  
binary resource file via the class loader and load it as a native  
library.


From tjarvi at qbang.org  Tue Jun 20 03:58:12 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT)
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
Message-ID: <Pine.LNX.4.61.0606200335190.14139@www>

> 2a) For platforms supported by Sun the user is free to use the 3.0
> comm.jar download from Sun
> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to
> the classpath of the application (and librxtxSerial.jnilib to the
> application directory). Also he will need the 2.0.3 generic comm.jar
> from Sun.

As there are no plans to support CommAPI 3.0 due to the limitations in its 
implementation mentioned before, I would not recommend projects use Sun's 
3.0 comm.jar.  They will lose the freedom to chose their low level 
implementation by being locked into vendor specific modifications.

Projects should chose between platform neutrality in CommAPI 2.0 and 
reduced platform neutrality in commapi 3.0.  Projects should also strongly 
consider the fact that the 2.0 comm.jar targets only a reduced number of 
JVMs.

Projects can go with rxtx 2.1 or other packages but should probably only 
consider using Sun CommAPI with rxtx if they did so in the past.  They 
should take steps to no longer depend upon this option being available.

> Suggested solution:
> ------
>
> We only need to put the following class in the classpath BEFORE Suns
> comm.jar
>
>   package com.sun.comm;
>   public class SolarisDriver extends gnu.io.RXTXCommDriver {
>   }
>
> This is not "the pure art" (TM). It depends on an implementation
> detail of the generic driver. However, so does the
> javax.comm.properties file - as we have seen when Sun released 3.0.
> It has the following advantages:
>
> - The "generic" javax.comm implementation will happily load this
> class as its primary driver.
> - No javax.comm.properties file is required.
> - This does not violate the javax.comm license agreement as there is
> no mention of the "com.sun.comm" package in this license agreement at
> all.
> - Authors packaging comm.jar with their application can strip out all
> com.sun.comm classes from comm.jar
>

I would not encourage people to place packages in the com.sun.comm 
namespace.  Authors using Sun's commapi 2.0 should just realize it is 
greatly limited in practical utility and consider moving to something that 
isn't being rescued from EOL.

The primary focus of this release is projects previously depending upon 
Sun CommAPI + RXTX.  There are no plans at this time to provide future 
support in this arrangement due to technical incompatabilities we have no 
control over in commapi 3.0 and limited utility of Sun's generic comm.jar 
in commapi 2.0 offered.  Projects should be aware of this so they can make 
appropriate plans.

--
Trent Jarvi
tjarvi at qbang.org


From paul.klissner at sun.com  Tue Jun 20 05:24:00 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Tue, 20 Jun 2006 04:24:00 -0700
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
In-Reply-To: <Pine.LNX.4.61.0606200335190.14139@www>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
	<Pine.LNX.4.61.0606200335190.14139@www>
Message-ID: <4497DAD0.10803@sun.com>

Trent Jarvi wrote:
>> 2a) For platforms supported by Sun the user is free to use the 3.0
>> comm.jar download from Sun
>> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to
>> the classpath of the application (and librxtxSerial.jnilib to the
>> application directory). Also he will need the 2.0.3 generic comm.jar
>> from Sun.
> 
> As there are no plans to support CommAPI 3.0 due to the limitations in its 
> implementation mentioned before, I would not recommend projects use Sun's 
> 3.0 comm.jar.  They will lose the freedom to chose their low level 
> implementation by being locked into vendor specific modifications.
> 
> Projects should chose between platform neutrality in CommAPI 2.0 and 
> reduced platform neutrality in commapi 3.0.  Projects should also strongly 
> consider the fact that the 2.0 comm.jar targets only a reduced number of 
> JVMs.

Well, that's a little ambiguous because the API is the same
either way.  We're talking about Sun's implementation vs.
other implementations.
> 
> Projects can go with rxtx 2.1 or other packages but should probably only 
> consider using Sun CommAPI with rxtx if they did so in the past.  They 
> should take steps to no longer depend upon this option being available.

3.0 is platform centric because there is a need to add some
platform awareness to Sun's implementation, and the choices
for how to do that are limited by the constraints of the API,
as mentioned in the javax.comm 2.0.3 comm.jar download's README.

I am really advocating getting a JSR open (http://www.jcp.org)
to push a new comm API that is more pluggable, platform neutral
and addresses some of the deficiencies of the current API. Then
we can achieve the optimal of platform neutrality while
simulataneously allowing the API to flexibly adapt to
heterogeneous environments.

This is not a question of attitude, this is an issue of resources,
time and commitment.  The current owners of javax.comm within
Sun would like nothing better than to see the ideal reached for
the API and a model that will extend well beyond the foreseeable
future and work for the industry overall.



> 
>> Suggested solution:
>> ------
>>
>> We only need to put the following class in the classpath BEFORE Suns
>> comm.jar
>>
>>   package com.sun.comm;
>>   public class SolarisDriver extends gnu.io.RXTXCommDriver {
>>   }
>>
>> This is not "the pure art" (TM). It depends on an implementation
>> detail of the generic driver. However, so does the
>> javax.comm.properties file - as we have seen when Sun released 3.0.
>> It has the following advantages:
>>
>> - The "generic" javax.comm implementation will happily load this
>> class as its primary driver.
>> - No javax.comm.properties file is required.
>> - This does not violate the javax.comm license agreement as there is
>> no mention of the "com.sun.comm" package in this license agreement at
>> all.
>> - Authors packaging comm.jar with their application can strip out all
>> com.sun.comm classes from comm.jar
>>
> 
> I would not encourage people to place packages in the com.sun.comm 
> namespace.  Authors using Sun's commapi 2.0 should just realize it is 
> greatly limited in practical utility and consider moving to something that 
> isn't being rescued from EOL.
> 
> The primary focus of this release is projects previously depending upon 
> Sun CommAPI + RXTX.  There are no plans at this time to provide future 
> support in this arrangement due to technical incompatabilities we have no 
> control over in commapi 3.0 and limited utility of Sun's generic comm.jar 
> in commapi 2.0 offered.  Projects should be aware of this so they can make 
> appropriate plans.

Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86,
or need the powerful portmapping features in javax.com 3.0, or would like to
acquire the Interactive Serial Port Test utility.

-Paul


From paul.klissner at sun.com  Tue Jun 20 05:33:44 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Tue, 20 Jun 2006 04:33:44 -0700
Subject: [Rxtx] Suggested installation RXTX 2.0x...
In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
Message-ID: <4497DD18.70207@sun.com>

Joachim Buechse wrote:
> Hello everybody,
> 
> I have been fighting a bit with the javax.comm version of RXTX the  
> last days. I am working on the README .OSX now and try to figure out  
> which should be the "suggested" installation.
> 
> The facts:
> ------
> 
> - the "generic" comm.jar version of javax.comm which has been made re- 
> available tries to load com.sun.comm.SolarisDriver
> - this classname can be overridden ONLY by putting a file  
> javax.comm.properties in {java.home}/lib
> - if it is not overridden and SolarisDriver.class is not found  
> CommPortIdentifier will be disfunctional (in particual it is not  
> possible to add CommPort's via CommPortIdentifier.add).
> - the license distributed with comm.jar does not allow the  
> modification/addition of classes in javax.comm (however no mention of  
> com.sun...)
> 
> 
> What really bothers me is to suggest putting this config file in the  
> "global" vm installation. This is particularly ugly on the Mac as  
> there are several VM installations and the file may be forgotten.  
> Additionally it may create versioning problems. I prefer an  
> installation where all files are local to the application (even  
> comm.jar).
> 
> In my opinion the ideal situation would be:
> ------
> 
> 1) The author of a program compiles against javax.comm.
> 2a) For platforms supported by Sun the user is free to use the 3.0  
> comm.jar download from Sun
> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to  
> the classpath of the application (and librxtxSerial.jnilib to the  
> application directory). Also he will need the 2.0.3 generic comm.jar  
> from Sun.
> 3) Nobody messes with the global VM installation.
> 
> Of course 2a) and 2b) could be handled by the author of the program  
> via an appropriate installer. The author could also decide to always  
> use RXTX and include the generic javax.comm classes as well as the  
> RXTX classes in his application jar. [If he further uses an explicit  
> call to System.load() he may even include the jnilib(s) in the jar,  
> extract it (based on the platform name) at runtime to a temp file and  
> load it from there.]
> 

This was how the Sun implementation originated (I did not write
that code).  I completely agree, and I fixed the whole conf file
locating mechanism in 3.0 to avoid the problems youmentioned.
However, I was unaware of how RxTx was using Sun's implementation,
so I didn't architect it in such a way as to avoid namespace pollution
in the native space in for the backend provider.  In retrospect,
I should have done that differently just as a design principle,
but at this point I don't have the spare cycles to get that all
re-factored.  Further, I'm loathe to do it, because the whole
thing will still be an under-the-hood hack due to the constraints
of the API itself.

Paul





From brian at mbari.org  Tue Jun 20 10:23:54 2006
From: brian at mbari.org (Brian Schlining)
Date: Tue, 20 Jun 2006 09:23:54 -0700
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>


Hi Joachim,

> There has been some discussions about the best way to install RXTX
> and where to place files.
>
> I suggest that,
>
> - we include the native libraries for the most common operating
> systems (in a special version of) RXTXcomm.jar
> - we add loader code which tries to extract and load the platform
> specific binary at runtime
> - on failure the current mechanism remains as a fallback

I like your suggestion. However, my understanding is that in general  
the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH  
(Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to  
be loaded by the JVM. The alternative is to point to your native lib  
directory using -Djava.library.path=/my/dir/with/native/libs when you  
launch the JVM. So, I'm very interested to know how you're planning  
to work around this.

> PS: Of course the suggested solution is already possible today,
> however relatively few programmers know how to correctly extract a
> binary resource file via the class loader and load it as a native
> library.

So how do you use it to dynamically load a native lib? I've read that  
you can't really modify the java.library.path after the JVM has been  
launched. (http://forum.java.sun.com/thread.jspa? 
threadID=627890&tstart=90)

Thanks

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0013.html

From joachim at buechse.de  Tue Jun 20 09:20:29 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 17:20:29 +0200
Subject: [Rxtx] 2.0x in sync with 2.1x
Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>

I have added most of the changes from the 2.1 branch to the 2.0 branch.

This includes
  - correction of illegal javadoc comments
  - implementation errors in handling of Thread.interrupt in  
RXTXPort.java
  - MacOS X locking without lock files/special user groups
  - XCode project which builds a universal binary library
  - updated documentation for OSX

I have done some minimal testing (only G4).
[Trent: there are still some changes you made for specific baud  
rates. I will not sync this, as I can not test them. From my  
perspective we are ready for 2.08/2.18]

The updated documentation can be found in the file README.OSX. Here  
it is:

------------------------ Required files -----------------------

To use or compile RXTX 2.0.x you need to downlad the "generic"  
version (2.0.3)
of the javax.comm implementation from Sun. The zip you download  
contains an
archive comm.jar which is required:

- To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar

- To run the app you will need comm.jar in the classpath or in  
{java.lib.path}


------------------------ Installation on MacOSX -----------------------

WARNING: Please read this section until the end.

---
Preparation
---

You may want to spare your users the burden of modifying the global VM
installation. OSX has several different VM versions installed by  
default and
regular users will be unable to figure out which version will load your
application.

If you provide the class

package com.sun.comm;
public class SolarisDriver extends gnu.io.RXTXCommDriver {
}

and make sure, that it is present in the classpath before Suns  
"generic" comm.jar
your users can skip the following step:

Create a file named
    javax.comm.properties
in the directory
    /System/Library/Frameworks/JavaVM.framework/Home/lib/
which contains (only) the following line (no leading space):
    Driver=gnu.io.RXTXCommDriver



----
The unsafe way of using RXTX on OS X:
----

RXTX can be installed by putting the files
   libSerial.jnilib
   RXTXcomm.jar
   comm.jar
into the folder
   /Library/Java/Extensions

This is NOT RECOMMENDED as it creates versioning conflicts among  
applications.
However you may be forced to install it this way if an application  
was written
for Windows or Linux, requires RXTX and you are not able to change  
its starter.


----
The safe way of using RXTX on OS X:
----

Make sure that you have no (older) version of RXTX installed in
   /Library/Java/Extensions
   /System/Library/Java/Extensions
   /usr/lib/java

Put
   libSerial.jnilib
in the directory of the application (the JavaVM will find it there). Add
   RXTXComm.jar
   comm.jar
to the application classpath or include the classes in the  
application jar.
(Some applications already include the RXTX classes in their  
application jar,
in which case only the file libSerial.jnilib is required).


----
History
----

Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation  
of lockfiles
required special permissions for the user executing an application  
based on RXTX.
To simplify the setup RXTX came with an installer modifying group  
permissions
and installing RXTX in the global location /Library/Java/Extensions.  
However
this was prune to versioning conflicts and is no longer recommended.

--------------------- Build instructions for OSX XCode  
-------------------

contributed by Joachim Buechse <joachim at buechse.de>
original version by Dmitry Markman <dmarkman at mac.com>

System requirements for building:
MacOSX 10.4
XCode 2.3

   open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj
   choose libSerial.jnilib target
   build

After the build you will find RXTXcomm.jar and libSerial.jnilib files  
in the
directory build/Development.

In case you can't find RXTXcomm.jar build the RXTXcomm target manually.
In case of (serious) problems feel free to contact joachim at buechse.de .



From tjarvi at qbang.org  Tue Jun 20 22:01:45 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT)
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
Message-ID: <Pine.LNX.4.61.0606202127270.14139@www>

> ---
> Preparation
> ---
>
> You may want to spare your users the burden of modifying the global VM
> installation. OSX has several different VM versions installed by
> default and
> regular users will be unable to figure out which version will load your
> application.
>
> If you provide the class
>
> package com.sun.comm;
> public class SolarisDriver extends gnu.io.RXTXCommDriver {
> }
>
> and make sure, that it is present in the classpath before Suns
> "generic" comm.jar
> your users can skip the following step:

Hi Joachim

With regards to the above, I have not seen that we have Sun's OK to 
promote that.  I'm not very comfortable with the distribution 
documentation advocating this without Sun agreeing.

I see your point but I'd rather not actively promote putting classes in 
Sun's namespace without permission if you don't mind.  This isn't about 
what is in a license.

I'll go through the code tomorrow night.  It was a late night at work 
today.  There is also a w32 fix comming for people opening and closing 
multiple ports.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Wed Jun 21 01:56:45 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 21 Jun 2006 09:56:45 +0200
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <Pine.LNX.4.61.0606202127270.14139@www>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
	<Pine.LNX.4.61.0606202127270.14139@www>
Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>

Hello Trent,

I guess we will not get an explicit OK from Sun for such a hack. I  
think Paul has made it pretty clear, that he does not have the  
resources to modify the 2.x or 3.x code for the needs of RXTX. I'm  
not thrilled but OK with the current API. Hence I dont agree with  
Paul's idea to start a new JSR to fix the implementation - but that's  
mainly because I dont have the time to push it. According to their  
Readme Sun sees no business case in having cross platform support for  
javax.comm - that is sad but it's none of my business. However I  
prefer to program versus javax.comm in my projects as this gives an  
advanced user the chance to exchange the provider without access to  
the code.

I interpret Pauls reponse to my original "Request for comment" as a  
quiet acceptance of the hack I propose (he did respond, but not at  
all to the sun.comm namespace suggestion). This is certainly not  
something we should put into RXTXcomm.jar but hinting a work around  
for implementation errors should be allowed. That's why I've choosen  
the wording "You may want to spare" and "If you provide". The company  
I worked for has choosen similar hacks for years to fix bugs in swing  
for JDK1.1 applications. Those hacks were usually included in their  
own swingpatch.jar.

Having said all that - I do not take it as an insult if you remove  
the paragraph from the Readme. I appreciate that you notified me  
before. It would be interesting to hear some more opinions from the  
list members...

Best regards,
Joachim


On 21.06.2006, at 06:01, Trent Jarvi wrote:

>> ---
>> Preparation
>> ---
>>
>> You may want to spare your users the burden of modifying the  
>> global VM
>> installation. OSX has several different VM versions installed by
>> default and
>> regular users will be unable to figure out which version will load  
>> your
>> application.
>>
>> If you provide the class
>>
>> package com.sun.comm;
>> public class SolarisDriver extends gnu.io.RXTXCommDriver {
>> }
>>
>> and make sure, that it is present in the classpath before Suns
>> "generic" comm.jar
>> your users can skip the following step:
>
> Hi Joachim
>
> With regards to the above, I have not seen that we have Sun's OK to
> promote that.  I'm not very comfortable with the distribution
> documentation advocating this without Sun agreeing.
>
> I see your point but I'd rather not actively promote putting  
> classes in
> Sun's namespace without permission if you don't mind.  This isn't  
> about
> what is in a license.
>
> I'll go through the code tomorrow night.  It was a late night at work
> today.  There is also a w32 fix comming for people opening and closing
> multiple ports.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Wed Jun 21 02:03:33 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 21 Jun 2006 10:03:33 +0200
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
	<6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
Message-ID: <BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>

See System.load(String) [it's also mentioned under the URL you posted].

Regards,
Joachim


On 20.06.2006, at 18:23, Brian Schlining wrote:

> So how do you use it to dynamically load a native lib? I've read  
> that you can't really modify the java.library.path after the JVM  
> has been launched. (http://forum.java.sun.com/thread.jspa? 
> threadID=627890&tstart=90)
>
> Thanks
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From baris.ozkan at elikasu.com.tr  Wed Jun 21 07:58:06 2006
From: baris.ozkan at elikasu.com.tr (Baris)
Date: Wed, 21 Jun 2006 16:58:06 +0300
Subject: [Rxtx] RS 232 ..additional parameters
Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>

Hi,
 
Currently i am developing an application that requires to connect to a
remote rs232 device through  a dialup connection.
 
My problem is that the communication needs several more connection
parameters (i extracted that information from the vendor's dll , listed at
the end of the message)
 
I explored rxtx API and src files and could not find methods to set a
majority  of the parameters.
Am i missing any point or does rxtx is limited to soem standard set of
functionality(e.g. commAPI)? How  is it possible ,if i want to put some
extensions(???) to current rxtx implementation?
 
I am not very good at rs232 programming so excuse me if this message  is
boring one.
 
Thanx
 
Baris Ozkan
 
 
A Listing of Parameters:
 
 
typedef struct _DCB {

DWORD DCBlength; /* sizeof(DCB) */

DWORD BaudRate; /* Baudrate at which running */

DWORD fBinary: 1; /* Binary Mode (skip EOF check) */

DWORD fParity: 1; /* Enable parity checking */

DWORD fOutxCtsFlow:1; /* CTS handshaking on output */

DWORD fOutxDsrFlow:1; /* DSR handshaking on output */

DWORD fDtrControl:2; /* DTR Flow control */

DWORD fDsrSensitivity:1; /* DSR Sensitivity */

DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */

DWORD fOutX: 1; /* Enable output X-ON/X-OFF */

DWORD fInX: 1; /* Enable input X-ON/X-OFF */

DWORD fErrorChar: 1; /* Enable Err Replacement */

DWORD fNull: 1; /* Enable Null stripping */

DWORD fRtsControl:2; /* Rts Flow control */

DWORD fAbortOnError:1; /* Abort all reads and writes on Error */

DWORD fDummy2:17; /* Reserved */

WORD wReserved; /* Not currently used */

WORD XonLim; /* Transmit X-ON threshold */

WORD XoffLim; /* Transmit X-OFF threshold */

BYTE ByteSize; /* Number of bits/byte, 4-8 */

BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */

BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */

char XonChar; /* Tx and Rx X-ON character */

char XoffChar; /* Tx and Rx X-OFF character */

char ErrorChar; /* Error replacement char */

char EofChar; /* End of Input character */

char EvtChar; /* Received Event character */

WORD wReserved1; /* Fill for now. */

} DCB, *LPDCB;

typedef struct _COMMTIMEOUTS {

DWORD ReadIntervalTimeout; /* Maximum time between read chars. */

DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */

DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */

DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */

DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */

} COMMTIMEOUTS,*LPCOMMTIMEOUTS;

dcb.fOutX = FALSE;

dcb.fInX = FALSE;

dcb.fOutxCtsFlow = FALSE;

dcb.fBinary = TRUE;

dcb.fRtsControl = RTS_CONTROL_ENABLE;

SetCommState(hComm , &dcb ); 

COMMTIMEOUTS commTimeOut;

GetCommTimeouts(hComm, &commTimeOut );

commTimeOut.WriteTotalTimeoutMultiplier = 1; 

commTimeOut.WriteTotalTimeoutConstant = 18; 

// commTimeOut.ReadIntervalTimeout = 28; 

commTimeOut.ReadIntervalTimeout = 0; 

// commTimeOut.ReadTotalTimeoutMultiplier = 184; 

commTimeOut.ReadTotalTimeoutMultiplier = 300; 

// commTimeOut.ReadTotalTimeoutConstant = 1200;

commTimeOut.ReadTotalTimeoutConstant = 1200;

SetCommTimeouts(hComm, &commTimeOut);

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0013.html

From ajmas at sympatico.ca  Wed Jun 21 08:14:26 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Wed, 21 Jun 2006 10:14:26 -0400
Subject: [Rxtx] When is 2.18 planned for?
Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

Just curious as to know if there is a target date for 2.18?

Andre



From brian at mbari.org  Wed Jun 21 09:36:00 2006
From: brian at mbari.org (Brian Schlining)
Date: Wed, 21 Jun 2006 08:36:00 -0700
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
	<6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
	<BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>
Message-ID: <A21C9BC0-7894-4B08-AC82-44E11AB3D461@mbari.org>

Ha!!

I suppose I should read my own postings. ;-)

Thanks
B

On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote:

> See System.load(String) [it's also mentioned under the URL you  
> posted].
>
> Regards,
> Joachim
>
>
> On 20.06.2006, at 18:23, Brian Schlining wrote:
>
>> So how do you use it to dynamically load a native lib? I've read
>> that you can't really modify the java.library.path after the JVM
>> has been launched. (http://forum.java.sun.com/thread.jspa?
>> threadID=627890&tstart=90)

Brian Schlining
Software Engineer
http://www.mbari.org




From ajmas at sympatico.ca  Wed Jun 21 16:41:28 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Wed, 21 Jun 2006 18:41:28 -0400
Subject: [Rxtx] CVS build question
Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X:

 The JCL extension to RxTx requires comm.jar
 If you intend to use RxTx for commapi support comm.jar
 needs to be located in  /System/Library/Frameworks/JavaVM.framework/
  Versions/1.5/Home/lib/ext/comm.jar

I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me.

On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native).

Andre






From tjarvi at qbang.org  Wed Jun 21 18:00:04 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT)
Subject: [Rxtx] CVS build question
In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606211756310.14139@www>

On Wed, 21 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> Is the CVS repository meant to build for gnu.io or javax.comm? I ask 
> this, because I see the following when calling ./configure from MacOS X:
>
> The JCL extension to RxTx requires comm.jar
> If you intend to use RxTx for commapi support comm.jar
> needs to be located in  /System/Library/Frameworks/JavaVM.framework/
>  Versions/1.5/Home/lib/ext/comm.jar
>
> I am wanting to build for the gnu.io package, since I want to jump ahead 
> and see if the changes, intended for 2.18 for MacOS X, work for me.
>
> On a side note /Library/Java/Extensions should be included as a valid 
> search path for the JAR, since this is where Apple recommends placing 
> third party extensions (both Java and native).
>

rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel"
rxtx 2.0 src is obtained with "cvs checkout rxtx-devel"

rxtx 2.1 is a complete package in namespace gnu.io
rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 18:02:23 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT)
Subject: [Rxtx] When is 2.18 planned for?
In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606211800180.14139@www>

On Wed, 21 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> Just curious as to know if there is a target date for 2.18?
>

Hi Andre

"When it is ready" :)

Probably this weekend.  Maybe sooner.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 18:10:18 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT)
Subject: [Rxtx] RS 232 ..additional parameters
In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>
References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>
Message-ID: <Pine.LNX.4.61.0606211805010.14139@www>

On Wed, 21 Jun 2006, Baris wrote:

> Hi,
>
> Currently i am developing an application that requires to connect to a
> remote rs232 device through  a dialup connection.
>
> My problem is that the communication needs several more connection
> parameters (i extracted that information from the vendor's dll , listed at
> the end of the message)
>
> I explored rxtx API and src files and could not find methods to set a
> majority  of the parameters.
> Am i missing any point or does rxtx is limited to soem standard set of
> functionality(e.g. commAPI)? How  is it possible ,if i want to put some
> extensions(???) to current rxtx implementation?
>
> I am not very good at rs232 programming so excuse me if this message  is
> boring one.
>
> Thanx
>

Hi Baris

> typedef struct _DCB {
> typedef struct _COMMTIMEOUTS {

These are all handled in termios.c.  It is possible to add extensions to 
rxtx 2.1.  It may well be that the defaults are the same for the variables 
not covered by the existing API.  You can dump the DCB and COMMTIMEOUTS 
from inside termios.c to compare.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 20:23:30 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT)
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
	<Pine.LNX.4.61.0606202127270.14139@www>
	<789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>
Message-ID: <Pine.LNX.4.61.0606212012210.14139@www>

> I'm
> not thrilled but OK with the current API. Hence I dont agree with
> Paul's idea to start a new JSR to fix the implementation - but that's
> mainly because I dont have the time to push it. According to their
> Readme Sun sees no business case in having cross platform support for
> javax.comm - that is sad but it's none of my business. However I
> prefer to program versus javax.comm in my projects as this gives an
> advanced user the chance to exchange the provider without access to
> the code.

Hi Joachim

With regards to the JSR, I think that would be Doug's call.  The effort I 
put in would have to be on my own time which would not be a great deal.  I 
could help things go smoothly but thats not the same as pushing something 
through.

--
Trent Jarvi
tjarvi at qbang.org



From vt at freehold.crocodile.org  Wed Jun 21 21:05:22 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Wed, 21 Jun 2006 20:05:22 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
Message-ID: <449A08F2.3020106@freehold.crocodile.org>

Hello all,

I know this question may belong to JSR lists, but since all interested 
parties are here, I thought I just ask this question here, again...

A while ago I run into a problem and wrote a rant, here: 
http://servomaster.sourceforge.net/dev/serial-usb.html
At the time of writing I didn't think of adding another possible 
solution - changing the CommAPI specs to support removable devices. 
Apparently, Serial/USB bridges are here to stay, and this issue has to 
be addressed.

Wonder if anything changed since, and any abstractions for supporting 
removable devices made it into current or future Java CommAPI drafts - 
Paul, any comments?

--vt



From joachim at buechse.de  Thu Jun 22 01:59:54 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 22 Jun 2006 09:59:54 +0200
Subject: [Rxtx] CVS build question
In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de>

Hello Andre,

I am not sure how well the configure/make mechanism will work on OSX.  
I know that a while ago some contributors tried to get configure/make  
working on OSX but from comments I found in the readmes this work was  
only partially successfull. For compilation on OSX we have used the  
ProjectBuilder/XCode projects you can find in MACOSX_IDE.

Regarding the  ./configure comment:
RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config  
file javax.comm.properties. The later MUST reside in {java.home}/lib.  
As the two only work together putting comm.jar into  /Library/Java/ 
Extensions  and hence making it available to all current and future  
VM installations will only add to confusion.

Regards,
Joachim

On 22.06.2006, at 00:41, Andre-John Mas wrote:

> Hi,
>
> Is the CVS repository meant to build for gnu.io or javax.comm? I  
> ask this, because I see the following when calling ./configure from  
> MacOS X:
>
>  The JCL extension to RxTx requires comm.jar
>  If you intend to use RxTx for commapi support comm.jar
>  needs to be located in  /System/Library/Frameworks/JavaVM.framework/
>   Versions/1.5/Home/lib/ext/comm.jar
>
> I am wanting to build for the gnu.io package, since I want to jump  
> ahead and see if the changes, intended for 2.18 for MacOS X, work  
> for me.
>
> On a side note /Library/Java/Extensions should be included as a  
> valid search path for the JAR, since this is where Apple recommends  
> placing third party extensions (both Java and native).
>
> Andre
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Thu Jun 22 02:51:05 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 22 Jun 2006 10:51:05 +0200
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449A08F2.3020106@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>

Hello Vadim,

I think that your rant is to the point. However it is a bit like  
saying that Windows is at the source of email degradation and the  
only solution is to have users switch to safer operating systems.

I don't see how javax.comm or RXTX can address the problems you  
mention. Of course it would be super cool if javax.comm could magicly  
find the "matching" usb-device and query it's configuration via the  
usb protocol - however this magic (mapping /dev/xyz to its underlying  
USB device) is not supported by any kernel APIs I am aware of. It  
could be supported via POSSIX ioctl calls but then you should address  
your rant to the POSSIX group...

So for the time beeing it's either up to the virtual comm port driver  
to provide a usefull name under /dev/ or to the user choosing the  
right port to use. One example of a smart(er) com port driver is the  
KDDI driver for OSX, which will create device names like "/dev/ 
cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- 
encoded into the bridge chip. The same driver for windows also has  
some options allowing it in theory to recreate the same COMx every  
time a device is plugged/unplugged.

For most industrial applications however it will be up to the user to  
choose the right port (without getting a lot of help doing so).

Probing serial ports can go wrong, that's right. However any serial  
device developper would be well adviced to implement a basic set of  
Hayes AT modem commands (be it a modem or not). Especially AT I0.  
Anyone failing to do so risks that the users favourite TCP/PPP/FAX  
application or stack will kill the device in short time.

Best regards,
Joachim


On 22.06.2006, at 05:05, Vadim Tkachenko wrote:

> Hello all,
>
> I know this question may belong to JSR lists, but since all interested
> parties are here, I thought I just ask this question here, again...
>
> A while ago I run into a problem and wrote a rant, here:
> http://servomaster.sourceforge.net/dev/serial-usb.html
> At the time of writing I didn't think of adding another possible
> solution - changing the CommAPI specs to support removable devices.
> Apparently, Serial/USB bridges are here to stay, and this issue has to
> be addressed.
>
> Wonder if anything changed since, and any abstractions for supporting
> removable devices made it into current or future Java CommAPI drafts -
> Paul, any comments?
>
> --vt
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From vt at freehold.crocodile.org  Thu Jun 22 13:16:03 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 12:16:03 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
Message-ID: <20060622191603.GA17487@freehold.crocodile.org>

Hello Joachim,

> I think that your rant is to the point. However it is a bit like  
> saying that Windows is at the source of email degradation and the  
> only solution is to have users switch to safer operating systems.

I guess the problem is that the rant itself is obsolete and has to be
updated according to latest developments. At the time of writing there
weren't that many bridges around, and the trend didn't manifest itself as it
does now.

> I don't see how javax.comm or RXTX can address the problems you  
> mention.

I would agree that javax.comm won't be able to address the problem, at least
in the short run. As for RxTx - well, nobody prevents it from being a
superset of CommAPI specification, right? RxTx being the de-facto standard
for quite a few platforms, I'd daresay the standard may follow.

> Of course it would be super cool if javax.comm could magicly find the
> "matching" usb-device and query it's configuration via the usb protocol -
> however this magic (mapping /dev/xyz to its underlying USB device) is not
> supported by any kernel APIs I am aware of. It could be supported via
> POSSIX ioctl calls but then you should address your rant to the POSSIX
> group...

As a matter of fact, my bigger concern is addressing the fact that a serial
device can now be removable. This hasn't been the case before, and it
clearly is now. Regarding the above, well, I guess if we accept this fact,
we also need to accept the fact that we need at least rudimentary means of
identification of a serial device. For the USB case, it would usually be the
vendor/product ID, plus possible serial number - but it is irrelevant what
exactly the identifying information is, as long as it allows to identify the
device.

A paradigm shift is required, this is what I wanted to say. Serial devices
can be removed and replaced, it's now our turn to learn to deal with it.

> Joachim

--vt


From jredman at ergotech.com  Thu Jun 22 13:41:44 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 13:41:44 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
Message-ID: <449AF278.6000903@ergotech.com>


Vadim Tkachenko wrote:
> A paradigm shift is required, this is what I wanted to say. Serial devices
> can be removed and replaced, it's now our turn to learn to deal with it.

The removal if the serial port hardly significantly different from the 
removal of the device attached to the serial port.   Different, 
slightly, but not a "paradigm shift".

And yes, someone could unplug a USB serial device and plug it into a 
different USB port so that it has a different name/number, but they 
could do that with the device itself, move it from com1 to com2.

Am I missing something?

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 13:57:27 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 12:57:27 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449AF278.6000903@ergotech.com>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
Message-ID: <20060622195727.GA20247@freehold.crocodile.org>

On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote:
> 
> Vadim Tkachenko wrote:
> > A paradigm shift is required, this is what I wanted to say. Serial devices
> > can be removed and replaced, it's now our turn to learn to deal with it.
> 
> The removal if the serial port hardly significantly different from the 
> removal of the device attached to the serial port.   Different, 
> slightly, but not a "paradigm shift".
> 
> And yes, someone could unplug a USB serial device and plug it into a 
> different USB port so that it has a different name/number, but they 
> could do that with the device itself, move it from com1 to com2.
> 
> Am I missing something?

Yes, the fact that they could unplug a device A and plug a device B. With
the introduction of the concept of removability, the notion of the serial
port itself is not as important anymore, but the notion of the unique device
identifier is.

Consider a situation: long running system (enterprise HVAC, tens of nodes,
tens of thousands square feet area, hundreds of thousand dollars worth of
equipment being conditioned, can't shut down), serial/usb device fails, is
replaced by an identical device with a different serial #.

A little bit farfetched, but hopefully highlighting the point I'm trying to
make.

> Jim

--vt


From jredman at ergotech.com  Thu Jun 22 14:37:38 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 14:37:38 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>	<20060622191603.GA17487@freehold.crocodile.org>	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
Message-ID: <449AFF92.8080003@ergotech.com>


Vadim Tkachenko wrote:
>>
>> Am I missing something?
> 
> Yes, the fact that they could unplug a device A and plug a device B. With
> the introduction of the concept of removability, the notion of the serial
> port itself is not as important anymore, but the notion of the unique device
> identifier is.

Serial devices are always removable.  I could unplug _serial_ device A 
and plug in _serial_ device B.  We have systems running with two RS485 
ports, one talks to a Modbus PLC network one to a number of drives on a 
proprietary protocol.  If you plug the wrong DB9 into the wrong port the 
application doesn't work.

If you dangle a USB 485 converter on the end of the DB9 you've just 
moved the problem from RS485 to USB, but the problem/effect is the same.

> 
> Consider a situation: long running system (enterprise HVAC, tens of nodes,
> tens of thousands square feet area, hundreds of thousand dollars worth of
> equipment being conditioned, can't shut down), serial/usb device fails, is
> replaced by an identical device with a different serial #.
> 
> A little bit farfetched, but hopefully highlighting the point I'm trying to
> make.

Nothing's changed.  If I had a 4 port ISA board and plugged it into my 
new shiny '386 machine.  I could have com ports 9-12.  If I took a board 
off the shelf and didn't set the jumpers, I would have com ports 3-6.

The problem's the same.  If you replace with identical product then the 
com ports  will be the same - no software changes required.  If you 
replace one piece of hardware with hardware from a different 
manufacturer, then the naming/numbering may change.  You're physically 
changing the system, so may reasonably expect to have to make a software 
change.  RXTX actually handles this situation quite well with the -D 
command line option.  (My experience has generally been that the port 
number depends more on the USB port used than the hardware - so the 
chances are even with a hardware change the port number/name will be the 
same.)

Slightly Off Topic - there is a reason why industrial users will pay a 
premium for continued availability of hardware.  Yes you can mail-order 
a $10 USB converter and it will work, but there's no guarantee that the 
next time you buy the same part number from the same vendor it will be 
the same.  The industrial vendors will charge you $100+ for the same 
item, but it will be the same every time you buy it for the next 5 to 10 
years.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 14:37:19 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 13:37:19 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
Message-ID: <20060622203719.GA22521@freehold.crocodile.org>

Hello again,

And while I'm at it, why don't just say this: give me one good reason to
write 3+ different ways of handling removable devices, one for USB, one for
FireWire, one for serial...

I understand very well that this goes way beyond the scope of RxTx and
CommAPI and will require cooperation between them and javax.usb and whatever
JSR is responsible for FireWire implementation - but the end result is well
worth it. Abstract out and generalize arrival/departure/monitoring/discovery
API, provide protocol specific extensions for each, live happily ever after.

--vt


On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote:
> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote:
> > 
> > Vadim Tkachenko wrote:
> > > A paradigm shift is required, this is what I wanted to say. Serial devices
> > > can be removed and replaced, it's now our turn to learn to deal with it.
> > 
> > The removal if the serial port hardly significantly different from the 
> > removal of the device attached to the serial port.   Different, 
> > slightly, but not a "paradigm shift".
> > 
> > And yes, someone could unplug a USB serial device and plug it into a 
> > different USB port so that it has a different name/number, but they 
> > could do that with the device itself, move it from com1 to com2.
> > 
> > Am I missing something?
> 
> Yes, the fact that they could unplug a device A and plug a device B. With
> the introduction of the concept of removability, the notion of the serial
> port itself is not as important anymore, but the notion of the unique device
> identifier is.
> 
> Consider a situation: long running system (enterprise HVAC, tens of nodes,
> tens of thousands square feet area, hundreds of thousand dollars worth of
> equipment being conditioned, can't shut down), serial/usb device fails, is
> replaced by an identical device with a different serial #.
> 
> A little bit farfetched, but hopefully highlighting the point I'm trying to
> make.
> 
> > Jim
> 
> --vt
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx


From jredman at ergotech.com  Thu Jun 22 15:13:49 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 15:13:49 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>	<20060622191603.GA17487@freehold.crocodile.org>	<449AF278.6000903@ergotech.com>	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
Message-ID: <449B080D.9080208@ergotech.com>


Vadim Tkachenko wrote:
> Hello again,
> 
> And while I'm at it, why don't just say this: give me one good reason to
> write 3+ different ways of handling removable devices, one for USB, one for
> FireWire, one for serial...

You don't, they're all the same "I have lost communication with my 
serial device".

The only thing you could really do is improve error reporting by knowing 
the exact sub-system.  ("Device X which is/was attached to USB port Y is 
no longer functioning, please check the USB ports, the device, the 
cables and anything else you can think of that may be a cause of 
failure.")  That just requires an intelligent description of the port.

> I understand very well that this goes way beyond the scope of RxTx and
> CommAPI and will require cooperation between them and javax.usb and whatever
> JSR is responsible for FireWire implementation - but the end result is well
> worth it. Abstract out and generalize arrival/departure/monitoring/discovery
> API, provide protocol specific extensions for each, live happily ever after.

There's a huge list of pseudo-serial devices each with a different set 
of requirements, Bluetooth, RFC 2217, a host of proprietary systems, 
etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I 
have no clue how you'd implement them in a general/cross platform sense.

You haven't convinced me (and only me, others may see something that I 
don't, I'm not speaking for them) that this mechanism can be implemented 
in any practical sense.  That is, that the implementation could be wide 
enough to be consider generally available in RXTX regardless of the 
serial port implementation, platform, etc..  However, if you can come up 
with a general design and a reference implementation for one subsystem, 
I'd like to see it and might get on board.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 15:40:55 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 14:40:55 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449B080D.9080208@ergotech.com>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
Message-ID: <20060622214055.GA25497@freehold.crocodile.org>

On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote:
> 
> Vadim Tkachenko wrote:
> > Hello again,
> > 
> > And while I'm at it, why don't just say this: give me one good reason to
> > write 3+ different ways of handling removable devices, one for USB, one for
> > FireWire, one for serial...
> 
> You don't, they're all the same "I have lost communication with my 
> serial device".

"I have lost communication with my ${protocol} device".

> The only thing you could really do is improve error reporting by knowing 
> the exact sub-system.  ("Device X which is/was attached to USB port Y is 
> no longer functioning, please check the USB ports, the device, the 
> cables and anything else you can think of that may be a cause of 
> failure.")

"Device ${id} which is/was attached to ${protocol} port ${port} is no longer
functioning, please check the ${protocol} ports, the device, the
${protocol_media} and anything else you can think of that may be a cause of
failure".

>  That just requires an intelligent description of the port.

Agree absolutely.

> > I understand very well that this goes way beyond the scope of RxTx and
> > CommAPI and will require cooperation between them and javax.usb and whatever
> > JSR is responsible for FireWire implementation - but the end result is well
> > worth it. Abstract out and generalize arrival/departure/monitoring/discovery
> > API, provide protocol specific extensions for each, live happily ever after.
> 
> There's a huge list of pseudo-serial devices each with a different set 
> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, 
> etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I 
> have no clue how you'd implement them in a general/cross platform sense.

That's because some of the protocols were created decades ago when
autoconfiguration wasn't even conceived, much less practical. RS232/RS485
don't have a clue about identity discovery, and even capabilities discovery
beyond obvious 8N1 etc.

I agree that today all these protocols have generally incompatible
strategies for handling the situations I'm trying to address, but there's
nothing that says it's not an oversight. Besides, we're dealing with the
devices at a level of abstraction that allows some simplifications and
generalizations, at least part of the time - unless it's the protocol
specific features we're dealing with.

> You haven't convinced me (and only me, others may see something that I 
> don't, I'm not speaking for them) that this mechanism can be implemented 
> in any practical sense.  That is, that the implementation could be wide 
> enough to be consider generally available in RXTX regardless of the 
> serial port implementation, platform, etc..  However, if you can come up 
> with a general design and a reference implementation for one subsystem, 
> I'd like to see it and might get on board.

Actually, I wasn't even thinking about all this stuff when I wrote the first
message on the subject :) Now that you mention it - well, I'm not sure I can
chew the piece I just tried to bite in reasonable amount of time.

How do you eat an elephant? One bite at a time. If we could agree that a
small step in the specification is acceptable at this time, and express
further intentions, things may start happening.

To put it succinctly:

- Concept of a "port" should be augmented with a concept of a "device". A
device may be attached to a port in an implicit or explicit way.
- Implicitly connected device is exactly what the current scope of the
specification covers. No new functionality is offered.
- Explicitly connected device supports detachable device semantics, just as
other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a
few).
- The input and output streams are not properties of a port now, but
properties of the device attached to the port.
- A mechanism to allow listening for device arrivals and departures must be
made available.

That's it, off the top of my head.

I understand that this goes completely against current javax.comm specs, but
an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be
difficult to implement without disrupting javax.comm compatibility.

One concern is how to deal with the device identity - but there's no general
way of dealing with this at this time, devices may or may not offer identity
discovery.

> Jim

--vt


From joachim at buechse.de  Fri Jun 23 02:12:43 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 23 Jun 2006 10:12:43 +0200
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
Message-ID: <CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>

Hello++ Vadim,

I would like to repeat that your request is best addressed to the  
POSSIX standardization group - or maybe the BSD/Linux maintainers. If  
you convince the BSD or Linux guys to add this kind of functionality  
(they can as most of there VCP drivers are open source), there is a  
certain chance that other vendors will pick it up. I assure you that  
RXTX will happily provide this functionality once it's possible - I'm  
sure there is more than one maintainer that would love to add it.  
Having this concept penetrate the market may take some years though.

SHORT: The solution you would like to see could be added to the API  
but it can not be implemented (at least not on the platforms I know).  
There are currently no hooks in the kernel that allow you to discover  
"the device" or even the "means of connection" based on an existing  
"device file descriptor" ie COM-port or /dev/... entry. The name  
mapping of the device is handled by the virtual com port driver of  
the device. Unless you are suggesting RXTX should reimplement virtual  
com port drivers for all usb/serial bridges out there your request is  
understandable from a users viewpoint but simply not realizable. It's  
like asking that the Socket api should identify the computer behind  
an IP address (ie by its Ethernet address). While this COULD be  
implemented in TCP/IP, it IS not, and hence there is no point adding  
such a function to the Socket API.

The current trend for USB/Bluetooth/Irda/etc connected devices is  
going away from serial port abstraction towards RPC (ie the drivers  
provide a device specific or device class specific driver that  
provides an application level api to the device functions). The line  
level protocol is often not even published.

Best regards,
Joachim

On 22.06.2006, at 23:40, Vadim Tkachenko wrote:

> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote:
>>
>> Vadim Tkachenko wrote:
>>> Hello again,
>>>
>>> And while I'm at it, why don't just say this: give me one good  
>>> reason to
>>> write 3+ different ways of handling removable devices, one for  
>>> USB, one for
>>> FireWire, one for serial...
>>
>> You don't, they're all the same "I have lost communication with my
>> serial device".
>
> "I have lost communication with my ${protocol} device".
>
>> The only thing you could really do is improve error reporting by  
>> knowing
>> the exact sub-system.  ("Device X which is/was attached to USB  
>> port Y is
>> no longer functioning, please check the USB ports, the device, the
>> cables and anything else you can think of that may be a cause of
>> failure.")
>
> "Device ${id} which is/was attached to ${protocol} port ${port} is  
> no longer
> functioning, please check the ${protocol} ports, the device, the
> ${protocol_media} and anything else you can think of that may be a  
> cause of
> failure".
>
>>  That just requires an intelligent description of the port.
>
> Agree absolutely.
>
>>> I understand very well that this goes way beyond the scope of  
>>> RxTx and
>>> CommAPI and will require cooperation between them and javax.usb  
>>> and whatever
>>> JSR is responsible for FireWire implementation - but the end  
>>> result is well
>>> worth it. Abstract out and generalize arrival/departure/ 
>>> monitoring/discovery
>>> API, provide protocol specific extensions for each, live happily  
>>> ever after.
>>
>> There's a huge list of pseudo-serial devices each with a different  
>> set
>> of requirements, Bluetooth, RFC 2217, a host of proprietary systems,
>> etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I
>> have no clue how you'd implement them in a general/cross platform  
>> sense.
>
> That's because some of the protocols were created decades ago when
> autoconfiguration wasn't even conceived, much less practical. RS232/ 
> RS485
> don't have a clue about identity discovery, and even capabilities  
> discovery
> beyond obvious 8N1 etc.
>
> I agree that today all these protocols have generally incompatible
> strategies for handling the situations I'm trying to address, but  
> there's
> nothing that says it's not an oversight. Besides, we're dealing  
> with the
> devices at a level of abstraction that allows some simplifications and
> generalizations, at least part of the time - unless it's the protocol
> specific features we're dealing with.
>
>> You haven't convinced me (and only me, others may see something  
>> that I
>> don't, I'm not speaking for them) that this mechanism can be  
>> implemented
>> in any practical sense.  That is, that the implementation could be  
>> wide
>> enough to be consider generally available in RXTX regardless of the
>> serial port implementation, platform, etc..  However, if you can  
>> come up
>> with a general design and a reference implementation for one  
>> subsystem,
>> I'd like to see it and might get on board.
>
> Actually, I wasn't even thinking about all this stuff when I wrote  
> the first
> message on the subject :) Now that you mention it - well, I'm not  
> sure I can
> chew the piece I just tried to bite in reasonable amount of time.
>
> How do you eat an elephant? One bite at a time. If we could agree  
> that a
> small step in the specification is acceptable at this time, and  
> express
> further intentions, things may start happening.
>
> To put it succinctly:
>
> - Concept of a "port" should be augmented with a concept of a  
> "device". A
> device may be attached to a port in an implicit or explicit way.
> - Implicitly connected device is exactly what the current scope of the
> specification covers. No new functionality is offered.
> - Explicitly connected device supports detachable device semantics,  
> just as
> other protocols do (USB, FireWire, Wireless USB, Bluetooth, to  
> mention a
> few).
> - The input and output streams are not properties of a port now, but
> properties of the device attached to the port.
> - A mechanism to allow listening for device arrivals and departures  
> must be
> made available.
>
> That's it, off the top of my head.
>
> I understand that this goes completely against current javax.comm  
> specs, but
> an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern )  
> won't be
> difficult to implement without disrupting javax.comm compatibility.
>
> One concern is how to deal with the device identity - but there's  
> no general
> way of dealing with this at this time, devices may or may not offer  
> identity
> discovery.
>
>> Jim
>
> --vt
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From vt at freehold.crocodile.org  Fri Jun 23 11:28:29 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Fri, 23 Jun 2006 10:28:29 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
	<CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
Message-ID: <20060623172829.GA5335@freehold.crocodile.org>

Hello Joachim,

> I would like to repeat that your request is best addressed to the POSSIX
> standardization group - or maybe the BSD/Linux maintainers. If you
> convince the BSD or Linux guys to add this kind of functionality (they can
> as most of there VCP drivers are open source), there is a certain chance
> that other vendors will pick it up. I assure you that RXTX will happily
> provide this functionality once it's possible - I'm sure there is more
> than one maintainer that would love to add it.

I realize this thing is bigger than RxTx itself, and I'm afraid it's too
global not to cause people to laugh before they think about it :)

> Having this concept penetrate the market may take some years though.

Well, I'm sure it'll get there, the only question is - when.

> SHORT: The solution you would like to see could be added to the API but it
> can not be implemented (at least not on the platforms I know).

I guess I'm concerned about the abstraction more than I'm concerned about
the implementation at this point.
  
> There are currently no hooks in the kernel that allow you to discover  
> "the device" or even the "means of connection" based on an existing  
> "device file descriptor" ie COM-port or /dev/... entry.

Well, I'm not so sure you need to keep the literal mapping from /dev
namespace to your device namespace. As long as you can consistently offer a
virtual serial device on top of a virtual serial port, it may be irrelevant
whether you can map it into /dev. The mapping is going be schitzofrenic
anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the
representation...

> The name mapping of the device is handled by the virtual com port driver
> of the device. Unless you are suggesting RXTX should reimplement virtual
> com port drivers for all usb/serial bridges out there your request is
> understandable from a users viewpoint but simply not realizable.

It's not so much a request but rather an offer of participation. I run a few
projects actively using serial communications, as well as USB device
drivers, in different degrees of readiness (Servomaster, Haywire, DIY
Zoning) - and it would be a perfect playground.

You mentioned above that this task is about two things: a) abstraction b)
implementation. I could start the abstraction part of it without changing
the current CommAPI, on top of it, as an adapter. Even if the removable
device semantics are not implemented, but offered, this is already a step
forward.

> It's like asking that the Socket api should identify the computer behind
> an IP address (ie by its Ethernet address). While this COULD be
> implemented in TCP/IP, it IS not, and hence there is no point adding such
> a function to the Socket API.

Thank you for bringing up this example - I guess this is just about the same
thing that I'd like to see. Socket transparently provides you with the
input/output streams, at the same time offering protocol level specifics to
you.

> The current trend for USB/Bluetooth/Irda/etc connected devices is going
> away from serial port abstraction towards RPC (ie the drivers provide a
> device specific or device class specific driver that provides an
> application level api to the device functions). The line level protocol is
> often not even published.

I can't say I'm that happy with it. The best (or, rather, worst) example is
suchlike support for the Phidget servo controller - zealous Linux developers
implemented kernel module support for it, completely hijacking a possibility
of using it on a different level (it's somewhat fixed by now, thankfully).

I believe that whenever an abstraction is offered, it must be made optional
and/or pluggable so it can be replaced by something more suited to the task.

The nature of Java applications is such that they'd probably care much more
about Java API offered, than about no matter how rich application level api
that is offered outside of Java. I've dealt with JNI adapters in the past,
and whereas they can be made reasonably stable, the very fact that you are
forced to deal with things that are not on the critical timing/memory path
and could've been done much easier in Java causes endless grief.

> Joachim

--vt


From lyon at docjava.com  Sat Jun 24 04:54:12 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Sat, 24 Jun 2006 06:54:12 -0400
Subject: [Rxtx] jsr
In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
	<CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
	<20060623172829.GA5335@freehold.crocodile.org>
Message-ID: <p060204a3c0c2c9dde4f8@[192.168.1.152]>

Hi All,
I have had some off-list discussion with Trent.
Opening up a JSR with Sun, as per Peters' suggestion
seems like a reasonable idea, to us.

Does anyone having any concerns about the JSR process
that they would like to raise?

Thanks!
  - Doug



From the.grey.lantern at gmail.com  Sat Jun 24 18:15:26 2006
From: the.grey.lantern at gmail.com (Craig Nicoll)
Date: Sun, 25 Jun 2006 01:15:26 +0100
Subject: [Rxtx] Cannot create virtual serial port
Message-ID: <a1221cc50606241715g2d1e2af6r747347dd4c20e997@mail.gmail.com>

Hello,

This is my first post on this mailing list and I hope someone can help me.

I am having great difficult establishing a virtual serial port for the
Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia
7600.

Every time I try to run the SendMessage program that comes with SMSLib, I
get the following exception: gnu.io.NoSuchPortException

The port names I have tried are:
rfcomm0
rfcomm
/dev/rfcomm0
/dev/rfcomm

This is what I have done so far:
Modified /etc/bluetooth/rfcomm.conf to include the address of my phone:

rfcomm0 {
# Automatically bind the device at startup
bind no;

# Bluetooth address of the device
device 00:0e:6d:7a:98:43;

# RFCOMM channel for the connection
channel 1;

# Description of the connection
comment "Example Bluetooth device";
}

I also tried running the following command: rfcomm bind /dev/rfcomm0

I have searched the mailing list archives and found this post where someone
had a very similar problem to me:
http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried
changing the system properties as suggested and it made no difference.

I have also been scouring Google all day to no avail.

I would be incredibly grateful if anyone could give me some tips.

Thank you,

Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060625/cfa6df35/attachment-0004.html

From tjarvi at qbang.org  Sun Jun 25 19:56:08 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT)
Subject: [Rxtx] Pending release
Message-ID: <Pine.LNX.4.61.0606251942460.15744@www>


With frustration, I was unable to get to the pending release this weekend.
The release should be comming this next week once things calm down.
The source is in CVS except for a fix for multiple ports in windows.

I had planned on doing the release this weekend but that was disrupted by 
my transportation failing in a spectacular fashion.

--
Trent Jarvi
tjarvi at qbang.org


From Pawan.Kharbanda at dot.state.co.us  Tue Jun 27 22:28:51 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 27 Jun 2006 22:28:51 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>

 Trent, 
   I have an application running in a cluster in linux environment and I
am using RXTX2.1.7 (final) with JDK1.5. The application opens and closes
serial comm ports every 30 seconds and exchanges datas. I have
experienced some of my Comm Ports are left hanging (I can see the
LCK..cufXX lock files under /var/lock folder). On putting the debugs I
found out that, it is stuck at a native call line 809 in RXTXPort.java
class (Please see the code snippet below). Can you help me explain what
this method does in the native code? Am I getting into some thread
deadlocks? Thanks in advance.

Pawan Kharbanda 


public void removeEventListener()
	{
		if (debug)
			z.reportln( "RXTXPort:removeEventListener()
called");
		waitForTheNativeCodeSilly();
		//if( monThread != null && monThread.isAlive() )
		if( monThreadisInterrupted == true )
		{
			z.reportln( "	RXTXPort:removeEventListener()
already interrupted");
			monThread = null;
			SPEventListener = null;
			return;
		}
		else if( monThread != null && monThread.isAlive() )
		{
			if (debug)
				z.reportln( "
RXTXPort:Interrupt=true");
			monThreadisInterrupted=true;
			/*
			   Notify all threads in this PID that something
is up
			   They will call back to see if its their
thread
			   using isInterrupted().
			*/
			if (debug)
				z.reportln( "	RXTXPort:calling
interruptEventLoop");
// LINE 809			interruptEventLoop( ); It never returns
out of this 
			
			if (debug)
				z.reportln( "	RXTXPort:calling
monThread.join()");
			try {
				monThread.join(1000);
			} catch (Exception ex) {
				/* yikes */
				ex.printStackTrace();
			}
			if (debug)
				z.reportln( "	RXTXPort:waiting on
isAlive()");
			while( monThread.isAlive() )
			{
				if ( debug )
					z.reportln( "	MonThread is
still alive!");
				try {
					monThread.join(1000);
					Thread.sleep( 1000 );
				} catch( Exception e ){} 
				//monThread.stop();
			}
			
		}
		if (debug)
			z.reportln( "	RXTXPort:calling gc()");
		monThread = null;
		SPEventListener = null;
		MonitorThreadLock = false;
		MonitorThreadAlive=false;
		monThreadisInterrupted=true;
		z.reportln( "RXTXPort:removeEventListener() returning");
	} 

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Sunday, June 25, 2006 7:56 PM
To: rxtx at qbang.org
Subject: [Rxtx] Pending release


With frustration, I was unable to get to the pending release this
weekend.
The release should be comming this next week once things calm down.
The source is in CVS except for a fix for multiple ports in windows.

I had planned on doing the release this weekend but that was disrupted
by my transportation failing in a spectacular fashion.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Wed Jun 28 04:17:29 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 28 Jun 2006 04:17:29 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606280406330.9561@www>



Hi Pawan

You may have found a deadlock but I've not seen on recently on linux.

If you can, please update from CVS.  This will have some close fixes. 
I'm running with the same code as is in CVS.  It is not perfect but I've 
not seen anything like you mention.  Be sure to set timeouts and 
thresholds on the port.  It may be that the port is waiting on pending io 
that never happens.  I think the CVS patches deal with this also but it 
looks like your in a better test environment to know for sure.

The exploded vehicle mentioned below is expected to be fixed today.  It 
was just a ninja small radiator hose.  The pressure test afterwards 
created its own set of problems.  Until this is resolved, I'm spending 
most of my free time commuting by bicycle.

On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>   I have an application running in a cluster in linux environment and I
> am using RXTX2.1.7 (final) with JDK1.5. The application opens and closes
> serial comm ports every 30 seconds and exchanges datas. I have
> experienced some of my Comm Ports are left hanging (I can see the
> LCK..cufXX lock files under /var/lock folder). On putting the debugs I
> found out that, it is stuck at a native call line 809 in RXTXPort.java
> class (Please see the code snippet below). Can you help me explain what
> this method does in the native code? Am I getting into some thread
> deadlocks? Thanks in advance.
>
> Pawan Kharbanda
>
>
> public void removeEventListener()
> 	{
> 		if (debug)
> 			z.reportln( "RXTXPort:removeEventListener()
> called");
> 		waitForTheNativeCodeSilly();
> 		//if( monThread != null && monThread.isAlive() )
> 		if( monThreadisInterrupted == true )
> 		{
> 			z.reportln( "	RXTXPort:removeEventListener()
> already interrupted");
> 			monThread = null;
> 			SPEventListener = null;
> 			return;
> 		}
> 		else if( monThread != null && monThread.isAlive() )
> 		{
> 			if (debug)
> 				z.reportln( "
> RXTXPort:Interrupt=true");
> 			monThreadisInterrupted=true;
> 			/*
> 			   Notify all threads in this PID that something
> is up
> 			   They will call back to see if its their
> thread
> 			   using isInterrupted().
> 			*/
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> interruptEventLoop");
> // LINE 809			interruptEventLoop( ); It never returns
> out of this
>
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> monThread.join()");
> 			try {
> 				monThread.join(1000);
> 			} catch (Exception ex) {
> 				/* yikes */
> 				ex.printStackTrace();
> 			}
> 			if (debug)
> 				z.reportln( "	RXTXPort:waiting on
> isAlive()");
> 			while( monThread.isAlive() )
> 			{
> 				if ( debug )
> 					z.reportln( "	MonThread is
> still alive!");
> 				try {
> 					monThread.join(1000);
> 					Thread.sleep( 1000 );
> 				} catch( Exception e ){}
> 				//monThread.stop();
> 			}
>
> 		}
> 		if (debug)
> 			z.reportln( "	RXTXPort:calling gc()");
> 		monThread = null;
> 		SPEventListener = null;
> 		MonitorThreadLock = false;
> 		MonitorThreadAlive=false;
> 		monThreadisInterrupted=true;
> 		z.reportln( "RXTXPort:removeEventListener() returning");
> 	}
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Sunday, June 25, 2006 7:56 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] Pending release
>
>
> With frustration, I was unable to get to the pending release this
> weekend.
> The release should be comming this next week once things calm down.
> The source is in CVS except for a fix for multiple ports in windows.
>
> I had planned on doing the release this weekend but that was disrupted
> by my transportation failing in a spectacular fashion.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From Pawan.Kharbanda at dot.state.co.us  Wed Jun 28 12:11:06 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Wed, 28 Jun 2006 12:11:06 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>

Trent,
    Again thanks for the reply. First of all I have Receive timeouts set
on all communications including Max no of bytes to expect during the
call. I have noticed the problem is during "closing the connection". I
am not sure if the RXTX is 100% thread-safe yet. There seems to be a
glitch in the native calls. I am sure I have the latest code I did the
update on the Version 2.1.7 from CVS, is this where the latest updates
are located, I have noticed another version in CVS "rxtx-devel".

Regards
Pawan Kharbanda

    

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Wednesday, June 28, 2006 4:17 AM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports



Hi Pawan

You may have found a deadlock but I've not seen on recently on linux.

If you can, please update from CVS.  This will have some close fixes. 
I'm running with the same code as is in CVS.  It is not perfect but I've
not seen anything like you mention.  Be sure to set timeouts and
thresholds on the port.  It may be that the port is waiting on pending
io that never happens.  I think the CVS patches deal with this also but
it looks like your in a better test environment to know for sure.

The exploded vehicle mentioned below is expected to be fixed today.  It
was just a ninja small radiator hose.  The pressure test afterwards
created its own set of problems.  Until this is resolved, I'm spending
most of my free time commuting by bicycle.

On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>   I have an application running in a cluster in linux environment and 
> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and 
> closes serial comm ports every 30 seconds and exchanges datas. I have 
> experienced some of my Comm Ports are left hanging (I can see the 
> LCK..cufXX lock files under /var/lock folder). On putting the debugs I

> found out that, it is stuck at a native call line 809 in RXTXPort.java

> class (Please see the code snippet below). Can you help me explain 
> what this method does in the native code? Am I getting into some 
> thread deadlocks? Thanks in advance.
>
> Pawan Kharbanda
>
>
> public void removeEventListener()
> 	{
> 		if (debug)
> 			z.reportln( "RXTXPort:removeEventListener()
called");
> 		waitForTheNativeCodeSilly();
> 		//if( monThread != null && monThread.isAlive() )
> 		if( monThreadisInterrupted == true )
> 		{
> 			z.reportln( "	RXTXPort:removeEventListener()
> already interrupted");
> 			monThread = null;
> 			SPEventListener = null;
> 			return;
> 		}
> 		else if( monThread != null && monThread.isAlive() )
> 		{
> 			if (debug)
> 				z.reportln( "
> RXTXPort:Interrupt=true");
> 			monThreadisInterrupted=true;
> 			/*
> 			   Notify all threads in this PID that something
is up
> 			   They will call back to see if its their
thread
> 			   using isInterrupted().
> 			*/
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> interruptEventLoop");
> // LINE 809			interruptEventLoop( ); It never returns
> out of this
>
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> monThread.join()");
> 			try {
> 				monThread.join(1000);
> 			} catch (Exception ex) {
> 				/* yikes */
> 				ex.printStackTrace();
> 			}
> 			if (debug)
> 				z.reportln( "	RXTXPort:waiting on
> isAlive()");
> 			while( monThread.isAlive() )
> 			{
> 				if ( debug )
> 					z.reportln( "	MonThread is
> still alive!");
> 				try {
> 					monThread.join(1000);
> 					Thread.sleep( 1000 );
> 				} catch( Exception e ){}
> 				//monThread.stop();
> 			}
>
> 		}
> 		if (debug)
> 			z.reportln( "	RXTXPort:calling gc()");
> 		monThread = null;
> 		SPEventListener = null;
> 		MonitorThreadLock = false;
> 		MonitorThreadAlive=false;
> 		monThreadisInterrupted=true;
> 		z.reportln( "RXTXPort:removeEventListener() returning");
> 	}
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf

> Of Trent Jarvi
> Sent: Sunday, June 25, 2006 7:56 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] Pending release
>
>
> With frustration, I was unable to get to the pending release this 
> weekend.
> The release should be comming this next week once things calm down.
> The source is in CVS except for a fix for multiple ports in windows.
>
> I had planned on doing the release this weekend but that was disrupted

> by my transportation failing in a spectacular fashion.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Wed Jun 28 12:26:21 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 28 Jun 2006 12:26:21 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606281222420.9561@www>


Hi Pawan

If you did a cvs update from the 2.1-7 tar ball, you have the current 
version.  All rxtx in CVS is under rxtx-devel.  The 2.1-7 just has -r
commapi-0-0-1.

You may well have found something.  I have seen win32 fail on closing 
ports but not linux that I can think of.  Your use is much different than 
I normally see too.

Could you give us more information on how we would reproduce this and the 
frequency?


On Wed, 28 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>    Again thanks for the reply. First of all I have Receive timeouts set
> on all communications including Max no of bytes to expect during the
> call. I have noticed the problem is during "closing the connection". I
> am not sure if the RXTX is 100% thread-safe yet. There seems to be a
> glitch in the native calls. I am sure I have the latest code I did the
> update on the Version 2.1.7 from CVS, is this where the latest updates
> are located, I have noticed another version in CVS "rxtx-devel".
>
> Regards
> Pawan Kharbanda
>
>
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Wednesday, June 28, 2006 4:17 AM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] Locked Ports
>
>
>
> Hi Pawan
>
> You may have found a deadlock but I've not seen on recently on linux.
>
> If you can, please update from CVS.  This will have some close fixes.
> I'm running with the same code as is in CVS.  It is not perfect but I've
> not seen anything like you mention.  Be sure to set timeouts and
> thresholds on the port.  It may be that the port is waiting on pending
> io that never happens.  I think the CVS patches deal with this also but
> it looks like your in a better test environment to know for sure.
>
> The exploded vehicle mentioned below is expected to be fixed today.  It
> was just a ninja small radiator hose.  The pressure test afterwards
> created its own set of problems.  Until this is resolved, I'm spending
> most of my free time commuting by bicycle.
>
> On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:
>
>> Trent,
>>   I have an application running in a cluster in linux environment and
>> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and
>> closes serial comm ports every 30 seconds and exchanges datas. I have
>> experienced some of my Comm Ports are left hanging (I can see the
>> LCK..cufXX lock files under /var/lock folder). On putting the debugs I
>
>> found out that, it is stuck at a native call line 809 in RXTXPort.java
>
>> class (Please see the code snippet below). Can you help me explain
>> what this method does in the native code? Am I getting into some
>> thread deadlocks? Thanks in advance.
>>
>> Pawan Kharbanda
>>
>>
>> public void removeEventListener()
>> 	{
>> 		if (debug)
>> 			z.reportln( "RXTXPort:removeEventListener()
> called");
>> 		waitForTheNativeCodeSilly();
>> 		//if( monThread != null && monThread.isAlive() )
>> 		if( monThreadisInterrupted == true )
>> 		{
>> 			z.reportln( "	RXTXPort:removeEventListener()
>> already interrupted");
>> 			monThread = null;
>> 			SPEventListener = null;
>> 			return;
>> 		}
>> 		else if( monThread != null && monThread.isAlive() )
>> 		{
>> 			if (debug)
>> 				z.reportln( "
>> RXTXPort:Interrupt=true");
>> 			monThreadisInterrupted=true;
>> 			/*
>> 			   Notify all threads in this PID that something
> is up
>> 			   They will call back to see if its their
> thread
>> 			   using isInterrupted().
>> 			*/
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> interruptEventLoop");
>> // LINE 809			interruptEventLoop( ); It never returns
>> out of this
>>
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> monThread.join()");
>> 			try {
>> 				monThread.join(1000);
>> 			} catch (Exception ex) {
>> 				/* yikes */
>> 				ex.printStackTrace();
>> 			}
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:waiting on
>> isAlive()");
>> 			while( monThread.isAlive() )
>> 			{
>> 				if ( debug )
>> 					z.reportln( "	MonThread is
>> still alive!");
>> 				try {
>> 					monThread.join(1000);
>> 					Thread.sleep( 1000 );
>> 				} catch( Exception e ){}
>> 				//monThread.stop();
>> 			}
>>
>> 		}
>> 		if (debug)
>> 			z.reportln( "	RXTXPort:calling gc()");
>> 		monThread = null;
>> 		SPEventListener = null;
>> 		MonitorThreadLock = false;
>> 		MonitorThreadAlive=false;
>> 		monThreadisInterrupted=true;
>> 		z.reportln( "RXTXPort:removeEventListener() returning");
>> 	}
>>
>> -----Original Message-----
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
>
>> Of Trent Jarvi
>> Sent: Sunday, June 25, 2006 7:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] Pending release
>>
>>
>> With frustration, I was unable to get to the pending release this
>> weekend.
>> The release should be comming this next week once things calm down.
>> The source is in CVS except for a fix for multiple ports in windows.
>>
>> I had planned on doing the release this weekend but that was disrupted
>
>> by my transportation failing in a spectacular fashion.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From Pawan.Kharbanda at dot.state.co.us  Wed Jun 28 15:42:49 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Wed, 28 Jun 2006 15:42:49 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>

Trent,
    I will try to explain how I am setup and will try to write you a
Sample code little later to reproduce this. On our system we have
DigiBoxes installed on the 2 Linux servers. Both of them have RXTX2.1-7
version installed with the JRE(1.5) and both the machines have the same
port mappings in gnu.io.rxtx.properties (Currently in the production
system I have 64 ports). This is how the system works:

1) A thick Map based client initiates a Action on the Device on the
field. One of the Thread Workers(Asynchronous Call) in the Cluster picks
up the request. 
2) Once the worker gets the request it locks the Device and
Communication port in the DB's(These are our persistent locks, because
most of the devices do one to one communication with the serial ports).
After that the worker (or Comm Server) opens up the connection and after
exchanging the information calls the "Close" and returns.
3) Once the connection is closed , the DB lock is removed on the comm
port and is made available to accept future calls. Here is where the
glitch is the Serial Comm Close method never returns due to the
deadlock. 

I have noticed that the deadlocks are very inconsistent, sometime it
happens right away as soon as Application server starts and sometimes I
don't see any deadlocks for days, but it happens for sure. 

Here is how you can test if you have resources/ test environment. Write
a program and try to open/close  different ports(I will say have a
minimum of four) randomly and very frequently(may be 30 seconds), I am
pretty sure you will see the deadlocks and it happens in the native call
to interrptEventLoop in RXTXPort.java in removeEventListener() method
call.

Also I have noticed that the JVM carshes (without any memrory errors or
JVM errors. Its just not there) when native call is made to eventLoop()
in run() method in MonitorThread inner class. I am still investigating
why this is happening, but at this point I can just tell you the
location. You might have a question How I am so sure about the location?
My application is configured with Log4J and I have enabled the debugs on
the RXTXPort.java, so every time my JVM dies I see these logs at the end
of the file.

"2006-06-28 15:27:15,183 INFO  [STDOUT] RXTXPort:RXTXPort(/dev/cub01)
called
2006-06-28 15:27:15,218 INFO  [STDOUT]
RXTXPort:MontitorThread:MonitorThread()
2006-06-28 15:27:15,219 INFO  [STDOUT] RXTXPort:MontitorThread:run()"

I surely do have a luxury of a testing environment(ports, devices etc.)
and can help you fix these problems? Please advise me how we can resolve
these issues.

Thanks 
Pawan Kharbanda
303-478-2991





-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Wednesday, June 28, 2006 12:26 PM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports


Hi Pawan

If you did a cvs update from the 2.1-7 tar ball, you have the current
version.  All rxtx in CVS is under rxtx-devel.  The 2.1-7 just has -r
commapi-0-0-1.

You may well have found something.  I have seen win32 fail on closing
ports but not linux that I can think of.  Your use is much different
than I normally see too.

Could you give us more information on how we would reproduce this and
the frequency?


On Wed, 28 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>    Again thanks for the reply. First of all I have Receive timeouts
set
> on all communications including Max no of bytes to expect during the
> call. I have noticed the problem is during "closing the connection". I
> am not sure if the RXTX is 100% thread-safe yet. There seems to be a
> glitch in the native calls. I am sure I have the latest code I did the
> update on the Version 2.1.7 from CVS, is this where the latest updates
> are located, I have noticed another version in CVS "rxtx-devel".
>
> Regards
> Pawan Kharbanda
>
>
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Wednesday, June 28, 2006 4:17 AM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] Locked Ports
>
>
>
> Hi Pawan
>
> You may have found a deadlock but I've not seen on recently on linux.
>
> If you can, please update from CVS.  This will have some close fixes.
> I'm running with the same code as is in CVS.  It is not perfect but
I've
> not seen anything like you mention.  Be sure to set timeouts and
> thresholds on the port.  It may be that the port is waiting on pending
> io that never happens.  I think the CVS patches deal with this also
but
> it looks like your in a better test environment to know for sure.
>
> The exploded vehicle mentioned below is expected to be fixed today.
It
> was just a ninja small radiator hose.  The pressure test afterwards
> created its own set of problems.  Until this is resolved, I'm spending
> most of my free time commuting by bicycle.
>
> On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:
>
>> Trent,
>>   I have an application running in a cluster in linux environment and
>> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and
>> closes serial comm ports every 30 seconds and exchanges datas. I have
>> experienced some of my Comm Ports are left hanging (I can see the
>> LCK..cufXX lock files under /var/lock folder). On putting the debugs
I
>
>> found out that, it is stuck at a native call line 809 in
RXTXPort.java
>
>> class (Please see the code snippet below). Can you help me explain
>> what this method does in the native code? Am I getting into some
>> thread deadlocks? Thanks in advance.
>>
>> Pawan Kharbanda
>>
>>
>> public void removeEventListener()
>> 	{
>> 		if (debug)
>> 			z.reportln( "RXTXPort:removeEventListener()
> called");
>> 		waitForTheNativeCodeSilly();
>> 		//if( monThread != null && monThread.isAlive() )
>> 		if( monThreadisInterrupted == true )
>> 		{
>> 			z.reportln( "	RXTXPort:removeEventListener()
>> already interrupted");
>> 			monThread = null;
>> 			SPEventListener = null;
>> 			return;
>> 		}
>> 		else if( monThread != null && monThread.isAlive() )
>> 		{
>> 			if (debug)
>> 				z.reportln( "
>> RXTXPort:Interrupt=true");
>> 			monThreadisInterrupted=true;
>> 			/*
>> 			   Notify all threads in this PID that something
> is up
>> 			   They will call back to see if its their
> thread
>> 			   using isInterrupted().
>> 			*/
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> interruptEventLoop");
>> // LINE 809			interruptEventLoop( ); It never returns
>> out of this
>>
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> monThread.join()");
>> 			try {
>> 				monThread.join(1000);
>> 			} catch (Exception ex) {
>> 				/* yikes */
>> 				ex.printStackTrace();
>> 			}
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:waiting on
>> isAlive()");
>> 			while( monThread.isAlive() )
>> 			{
>> 				if ( debug )
>> 					z.reportln( "	MonThread is
>> still alive!");
>> 				try {
>> 					monThread.join(1000);
>> 					Thread.sleep( 1000 );
>> 				} catch( Exception e ){}
>> 				//monThread.stop();
>> 			}
>>
>> 		}
>> 		if (debug)
>> 			z.reportln( "	RXTXPort:calling gc()");
>> 		monThread = null;
>> 		SPEventListener = null;
>> 		MonitorThreadLock = false;
>> 		MonitorThreadAlive=false;
>> 		monThreadisInterrupted=true;
>> 		z.reportln( "RXTXPort:removeEventListener() returning");
>> 	}
>>
>> -----Original Message-----
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On
Behalf
>
>> Of Trent Jarvi
>> Sent: Sunday, June 25, 2006 7:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] Pending release
>>
>>
>> With frustration, I was unable to get to the pending release this
>> weekend.
>> The release should be comming this next week once things calm down.
>> The source is in CVS except for a fix for multiple ports in windows.
>>
>> I had planned on doing the release this weekend but that was
disrupted
>
>> by my transportation failing in a spectacular fashion.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx 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 khattar31 at yahoo.com  Wed Jun 28 22:04:59 2006
From: khattar31 at yahoo.com (rahul khattar)
Date: Wed, 28 Jun 2006 21:04:59 -0700 (PDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
Message-ID: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>

Hi All,

I was looking at the src file on the last release.
I did notice a missing header file while trying to
compile the parallelport.dll. Would somebody be kind
enoughf to share the missing header file:
gnu_io_LPRPort.h

I am using MinGw to compile the same from Parinya
(which is an execellent tool)


Regards,
Rahul Khattar

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Thu Jun 29 03:43:53 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 03:43:53 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>
References: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606290341210.9561@www>

On Wed, 28 Jun 2006, rahul khattar wrote:

> Hi All,
>
> I was looking at the src file on the last release.
> I did notice a missing header file while trying to
> compile the parallelport.dll. Would somebody be kind
> enoughf to share the missing header file:
> gnu_io_LPRPort.h
>
> I am using MinGw to compile the same from Parinya
> (which is an execellent tool)
>

Hi Rahul

The gnu.io_LPRPort.h file is generated with javah.  You can see the 
command in the Makefile I presume.  You do not need rxtxParallel.dll to 
use w32 serial btw.

--
Trent Jarvi
tjarvi at qbang.org


From khattar31 at yahoo.com  Thu Jun 29 04:47:01 2006
From: khattar31 at yahoo.com (rahul khattar)
Date: Thu, 29 Jun 2006 03:47:01 -0700 (PDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606290341210.9561@www>
Message-ID: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>

Hi Trent 
I did notice this file is required in the source file
ParallelImp.c
on line 38

Attached the O/P 

Regards,
Rahul Khattar




--- Trent Jarvi <tjarvi at qbang.org> wrote:

> On Wed, 28 Jun 2006, rahul khattar wrote:
> 
> > Hi All,
> >
> > I was looking at the src file on the last release.
> > I did notice a missing header file while trying to
> > compile the parallelport.dll. Would somebody be
> kind
> > enoughf to share the missing header file:
> > gnu_io_LPRPort.h
> >
> > I am using MinGw to compile the same from Parinya
> > (which is an execellent tool)
> >
> 
> Hi Rahul
> 
> The gnu.io_LPRPort.h file is generated with javah. 
> You can see the 
> command in the Makefile I presume.  You do not need
> rxtxParallel.dll to 
> use w32 serial btw.
> 
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Error.zip
Type: application/x-zip-compressed
Size: 1746 bytes
Desc: 2948039066-Error.zip
Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060629/a5b6f783/Error-0013.bin

From tjarvi at qbang.org  Thu Jun 29 06:16:24 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 06:16:24 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606290614530.9561@www>

On Thu, 29 Jun 2006, rahul khattar wrote:

> Hi Trent
> I did notice this file is required in the source file
> ParallelImp.c
> on line 38
>
> Attached the O/P
>

The command to generate the .h file will be something like:

javah -classpath . -jni gnu.io.LPRPort

The makefile should have this.  There are several approaches to creating 
or using makefiles so I have no idea which one you used if any.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Thu Jun 29 06:20:51 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 06:20:51 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606290616420.9561@www>

> Here is how you can test if you have resources/ test environment. Write
> a program and try to open/close  different ports(I will say have a
> minimum of four) randomly and very frequently(may be 30 seconds), I am
> pretty sure you will see the deadlocks and it happens in the native call
> to interrptEventLoop in RXTXPort.java in removeEventListener() method
> call.

Hi Pawan

I'll try to find a way to reproduce this.  One thing to note is that you 
are using different kernel drivers (digi) to perform this task.  So I 
probably will not be able to reproduce the exact same environment.

In general, multiport kernel drivers have been tested far less than 
typical serial drivers.  This may or may not be an issue.

--
Trent Jarvi
tjarvi at qbang.org



From jhaysonn at gmail.com  Thu Jun 29 12:29:13 2006
From: jhaysonn at gmail.com (jhaysonn pathak)
Date: Thu, 29 Jun 2006 14:29:13 -0400
Subject: [Rxtx] RXTX install
Message-ID: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>

Hi Guys,

I'm doing trying to write a generative piece of Sonic Art using an EEG
plugged into a mac runnning Max/MSP.  I just recently discovered RXTX
drivers in my search for a piece of software that might give me more
output options for my EEG (I'm using the CEO from MindPeak).  I found
Bioera which uses RXTX drivers.  Thing is - I can't figure out how to
install RXTX correctly.

After I build the 'libSerial.jnilib' target inside of
'LibSerial.pbproj' I can't find the libSerial.jnilib file that
accompanies the RXTXcomm.jar nor do I know where to put them.

I also don't understand this part at the bottom of the OS X instructions at all:

"AFTER INSTALLATION VERY IMPORTANT
	check existence of the folder /var/spool/uucp
	if you don't have it create it with command
	sudo mkdir /var/spool/uucp
	permissions should be: drwxrwxr-x
	if they are not do command
	sudo chmod 775 /var/spool/uucp

	YOU should be a member of the uucp group
	you can check it with command
		niutil -readprop / /groups/uucp users
	you should see your name in output of the niutil command
	if you don't do following:
		sudo niutil -appendprop / /groups/uucp users <yourname>
			substitute  <yourname> with your user's name
			for example if your user name is peter:
				sudo niutil -appendprop / /groups/uucp users peter

	NOTES: RXTX.pkg should create uucp folder and insert your name  in
uucp group automatically"



I really appreciate any help that you guys can offer.  I've been
struggling with this for a while now as part of a research grant that
I was awarded.  Thanks again for the help.

Jhaysonn Pathak


From naranjo.manuel at gmail.com  Thu Jun 29 07:19:15 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 10:19:15 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606290614530.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www>
Message-ID: <44A3D353.6010605@gmail.com>

Speaking about Windows Support, I had seen that inside the 
rxtx-2.1-7-bins-r2 package inside Windows directory it says:
"i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will 
not make harm to anyone, and i'm almost sure that someone has noticed it 
before.
Cheers,
Manuel


From joachim at buechse.de  Thu Jun 29 13:25:16 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 29 Jun 2006 21:25:16 +0200
Subject: [Rxtx] RXTX install
In-Reply-To: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>
References: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>
Message-ID: <2A003E42-97E1-4237-8438-646BDE2E3961@buechse.de>

Hello Jhaysonn,

I assume you are trying to use the javax.comm version of RXTX.

Please use "cvs up" to update your download to the latest version of  
the repository. The latest version does not use lock files, so the  
mentioned process is no longer needed. Updating with CVS will also  
provide you with a new README.OSX file that should be simpler to  
understand.

You will find LibSerialUniversal.xcodeproj in MACOSX_IDE/Xcode. Put  
comm.jar (downloaded from Sun) into MACOSX_IDE/Xcode. Compile the  
library. You will find RXTXcomm.jar and librxtxSerial.jnilib in  
MACOSX_IDE/Xcode/build/Default

Best regards,
Joachim
---
Joachim B?chse
Softwarel?sungen und Beratung
Hadlaubsteig 2
CH-8006 Z?rich


On 29.06.2006, at 20:29, jhaysonn pathak wrote:

> Hi Guys,
>
> I'm doing trying to write a generative piece of Sonic Art using an EEG
> plugged into a mac runnning Max/MSP.  I just recently discovered RXTX
> drivers in my search for a piece of software that might give me more
> output options for my EEG (I'm using the CEO from MindPeak).  I found
> Bioera which uses RXTX drivers.  Thing is - I can't figure out how to
> install RXTX correctly.
>
> After I build the 'libSerial.jnilib' target inside of
> 'LibSerial.pbproj' I can't find the libSerial.jnilib file that
> accompanies the RXTXcomm.jar nor do I know where to put them.
>
> I also don't understand this part at the bottom of the OS X  
> instructions at all:
>
> "AFTER INSTALLATION VERY IMPORTANT
> 	check existence of the folder /var/spool/uucp
> 	if you don't have it create it with command
> 	sudo mkdir /var/spool/uucp
> 	permissions should be: drwxrwxr-x
> 	if they are not do command
> 	sudo chmod 775 /var/spool/uucp
>
> 	YOU should be a member of the uucp group
> 	you can check it with command
> 		niutil -readprop / /groups/uucp users
> 	you should see your name in output of the niutil command
> 	if you don't do following:
> 		sudo niutil -appendprop / /groups/uucp users <yourname>
> 			substitute  <yourname> with your user's name
> 			for example if your user name is peter:
> 				sudo niutil -appendprop / /groups/uucp users peter
>
> 	NOTES: RXTX.pkg should create uucp folder and insert your name  in
> uucp group automatically"
>
>
>
> I really appreciate any help that you guys can offer.  I've been
> struggling with this for a while now as part of a research grant that
> I was awarded.  Thanks again for the help.
>
> Jhaysonn Pathak
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From tjarvi at qbang.org  Thu Jun 29 19:30:00 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 19:30:00 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A3D353.6010605@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
Message-ID: <Pine.LNX.4.61.0606291923000.9561@www>

On Thu, 29 Jun 2006, Manuel Naranjo wrote:

> Speaking about Windows Support, I had seen that inside the
> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
> not make harm to anyone, and i'm almost sure that someone has noticed it
> before.

Hi Manuel

         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
     47421  01-30-06 00:23 
rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
     77759  03-01-06 12:01 
rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README


It looks normal to me.  There are no fancy tools used there :)

--
Trent Jarvi
tjarvi at qbang.org

From naranjo.manuel at gmail.com  Thu Jun 29 19:38:16 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 22:38:16 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606291923000.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com> <Pine.LNX.4.61.0606291923000.9561@www>
Message-ID: <44A48088.2040407@gmail.com>

> On Thu, 29 Jun 2006, Manuel Naranjo wrote:
> 
>> Speaking about Windows Support, I had seen that inside the
>> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
>> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
>> not make harm to anyone, and i'm almost sure that someone has noticed it
>> before.
> 
> Hi Manuel
> 
>         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
>         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
>     47421  01-30-06 00:23 
> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
>     77759  03-01-06 12:01 
> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
>       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README
> 
> 
> It looks normal to me.  There are no fancy tools used there :)
> 
Hi Trent:
Is not the i368 representing the name of the Architecture?? If so the 
name should start with i386 it will not break any system, is simply miss
written, I saw that and wanted to report it. It a silly thing.
Ohh I forgoten I must congratulate you for your GREAT libray, I was able 
to make an .exe with JSmooth that launches an application that uses RXTX 
with out the need to install RXTX on users system :). The .exe tells JVM 
where to find the RXTX Library and Binaries. I tried with Sun's Java 
Comm but it was imposible.
Regards,
Manuel


From tjarvi at qbang.org  Thu Jun 29 19:52:45 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 19:52:45 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A48088.2040407@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
	<Pine.LNX.4.61.0606291923000.9561@www> <44A48088.2040407@gmail.com>
Message-ID: <Pine.LNX.4.61.0606291945060.9561@www>

On Thu, 29 Jun 2006, Manuel Naranjo wrote:

>> On Thu, 29 Jun 2006, Manuel Naranjo wrote:
>>
>>> Speaking about Windows Support, I had seen that inside the
>>> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
>>> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
>>> not make harm to anyone, and i'm almost sure that someone has noticed it
>>> before.
>>
>> Hi Manuel
>>
>>         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
>>         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
>>     47421  01-30-06 00:23
>> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
>>     77759  03-01-06 12:01
>> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
>>       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README
>>
>>
>> It looks normal to me.  There are no fancy tools used there :)
>>
> Hi Trent:
> Is not the i368 representing the name of the Architecture?? If so the
> name should start with i386 it will not break any system, is simply miss
> written, I saw that and wanted to report it. It a silly thing.
> Ohh I forgoten I must congratulate you for your GREAT libray, I was able
> to make an .exe with JSmooth that launches an application that uses RXTX
> with out the need to install RXTX on users system :). The .exe tells JVM
> where to find the RXTX Library and Binaries. I tried with Sun's Java
> Comm but it was imposible.

Hi Manuel

The compiler uses only the i386 instruction set for windows.  I doubt 
there will be any measurable advantages with going to later instruction 
sets.  In theory rxtx would run on a 386 but I doubt anyone does that.

So it looks odd but is not a typo.

We could compile to i686 but don't.  The compiler used does not appear to 
be a problem yet so I don't see any point in changing it.  Right now, we 
could not compile 64 bit windows binaries.  gcc/mingw/... do not support 
them that I know of.  People will have to compile those with closed source 
tools on their own until an option is available.

--
Trent Jarvi
tjarvi at qbang.org

From naranjo.manuel at gmail.com  Thu Jun 29 20:00:48 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 23:00:48 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606291945060.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com>	<Pine.LNX.4.61.0606291923000.9561@www>
	<44A48088.2040407@gmail.com> <Pine.LNX.4.61.0606291945060.9561@www>
Message-ID: <44A485D0.7050202@gmail.com>

Trent you did not get my point
The folder says 368 three hundred sixty eight, when
it should say 386 three hundred eighty six. Is simply a miss writting.
Regards,
Manuel


From tjarvi at qbang.org  Thu Jun 29 20:12:15 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 20:12:15 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A485D0.7050202@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
	<Pine.LNX.4.61.0606291923000.9561@www> <44A48088.2040407@gmail.com>
	<Pine.LNX.4.61.0606291945060.9561@www> <44A485D0.7050202@gmail.com>
Message-ID: <Pine.LNX.4.61.0606292008061.9561@www>


On Thu, 29 Jun 2006, Manuel Naranjo wrote:

> Trent you did not get my point
> The folder says 368 three hundred sixty eight, when
> it should say 386 three hundred eighty six. Is simply a miss writting.

hehe..  OK.  My bad.  It's been a long day.

Nevermind :)

--
Trent Jarvi
tjarvi at qbang.org




From naranjo.manuel at gmail.com  Thu Jun 29 20:18:44 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 23:18:44 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606292008061.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com>	<Pine.LNX.4.61.0606291923000.9561@www>
	<44A48088.2040407@gmail.com>	<Pine.LNX.4.61.0606291945060.9561@www>
	<44A485D0.7050202@gmail.com> <Pine.LNX.4.61.0606292008061.9561@www>
Message-ID: <44A48A04.9040401@gmail.com>

Don't worry Trent.
About 64 bits compilation, I would like to colaborate, I have a Pc with 
64 bits, the only problem is that i do not have windows 64 bits 
installed :(.




From Pawan.Kharbanda at dot.state.co.us  Fri Jun 30 08:49:52 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 30 Jun 2006 08:49:52 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E996@hqexchange3.dot.state.co.us>

Trent,  
    Can you explain what the interruptedEventLoop() native method is
doing is there a possibility that method is somehow getting into the
infinite loop(there are 2 while loops without any break statements).
This might be a very basic question how can I debug the native code(or
print the debug statements).  Again thanks for the help. 

Pawan Kharbanda

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Thursday, June 29, 2006 6:21 AM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports

> Here is how you can test if you have resources/ test environment. 
> Write a program and try to open/close  different ports(I will say have

> a minimum of four) randomly and very frequently(may be 30 seconds), I 
> am pretty sure you will see the deadlocks and it happens in the native

> call to interrptEventLoop in RXTXPort.java in removeEventListener() 
> method call.

Hi Pawan

I'll try to find a way to reproduce this.  One thing to note is that you
are using different kernel drivers (digi) to perform this task.  So I
probably will not be able to reproduce the exact same environment.

In general, multiport kernel drivers have been tested far less than
typical serial drivers.  This may or may not be an issue.

--
Trent Jarvi
tjarvi at qbang.org

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From cpine at wrsystems.com  Thu Jun 29 15:17:12 2006
From: cpine at wrsystems.com (Chris Pine)
Date: Thu, 29 Jun 2006 17:17:12 -0400
Subject: [Rxtx]  Controlling Individual Signals DTR and RTS
Message-ID: <MAIL4FJo0S8ACLEBajJ000005cf@mail4.wrsystems.com>

Dear Moussa Ba,
	I hope I am not being too forward, but we are having the exact same
issue with needing to control DTR from RXTX in Linux.  Did you ever have any
luck figuring it out?

Thank you very much for your time,

Chris Pine




From tjarvi at qbang.org  Thu Jun  1 11:13:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 11:13:40 -0600 (MDT)
Subject: [Rxtx] custom baud rate win32
In-Reply-To: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606011107210.30220@www>


Hi Daren

I can't imagine that 1953 is possibly the actual value on the UART.  Maybe 
if your baud base is very high with a custom serial board.  More likely, 
the driver just remembers that what you asked for and did something else.

I'll have more to say on the dcb->BaudRate after I try some things here. 
I have managed to do something like that in the past as a quick hack but 
it was for 14400.  I may have used the CBR_14400.

If we can't access this through the win32 API with protected mode, there 
is another layer of complication.  With real mode, it would be easy.
With protected mode, I assume there would have to be some kernel driver or 
a hook I'm not aware of to access the MCR directly (bang a memory 
addresss).



On Thu, 1 Jun 2006, Daren wrote:

> Trent,
> I have managed to successfully open the port at this speed using Realterm
> (available on sourceforge). From memory this uses DLPortIO.
>
> Using portmon.exe with realterm, even there it says that the port has opened
> at 1953.
>
> I changed termios.c:560 to
> dcb->BaudRate        = 1953 ;
>
> and it still opens the port at 9600.
>
> Daren
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Trent Jarvi
> Sent: Thursday, 1 June 2006 1:44 PM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] custom baud rate win32
>
> On Thu, 1 Jun 2006, Daren wrote:
>
>> Hi all,
>>
>> I downloaded 2.1.7-pre16 and managed to build it and get it going. I made
>> the changes as suggested by Peter Smith in an old post, by adding his code
>> to SerialImpl.c, uncommenting the TIOCGSERIAL and TIOCSSERIAL, and
> defining
>> ASYNC_SPD_CUST which is equal to 0x0030 (according to linus header
> files)..
>>
>>
>> Still not working, it opens the port at 9600 according to portmon.exe .
> Has
>> anyone managed to get this going at a custom rate?
>>
>> Here is the post I'm referring to:
>> http://marc.theaimsgroup.com/?l=rxtx&m=106270038110713&w=2
>>
>>
>> Thanks,
>> Daren
>>
>> ________________________________________
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
>> Daren
>> Sent: Wednesday, 31 May 2006 10:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] (no subject)
>>
>> Hi All,
>> I have been using rxtx for a little while and needed to get it working at
>> 1953, like a past user in the mailing list, who seemed to have got it
>> working by changing some C code.
>>
>> I wanted to build rxtx myself with these changes but don't know where to
>> start. I have windows here and FC4 at home. I downloaded cygwin and
> mingw32,
>> each build works by building a rxtxSerial.dll file that is ~11k smaller
> than
>> the original, and I always get the following error when testing the dll:
>>
>> Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at
>> PC=0x8077655
>> Function=[Unknown.]
>> Library=C:\opt\java\j2sdk1.4.2\jre\bin\client\jvm.dll
>>
>> NOTE: We are unable to locate the function name symbol for the error
>>      just occurred. Please refer to release documentation for possible
>>      reason and solutions.
>>
>>
>> Current Java thread:
>> 	at gnu.io.RXTXPort.open(Native Method)
>> 	- locked <0x1002c800> (a gnu.io.RXTXPort)
>> 	at gnu.io.RXTXPort.<init>(RXTXPort.java:84)
>>
>> Anyone know what im doing wrong?
>>
>>
>>
>>
>
> Hi Daren
>
> You are running into the same rats nest I'm looking at now.
>
> With win32 and specific custom baud rates, I'm not sure how this will go.
> I've got the Linux custom baud rates working very nicely.  I did much like
> the post you linked.  In fact I had forgot about that post.  You probably
> noticed that it becomes a bunch of dirt roads going noplace fast in
> termios.c for w32.
>
> I'm probably only going to get 14400, 28800, 128000 and 256000 working
> with the next release on w32.  I'll look a little further.  If you have an
> example w32 that works at 1953 I'd really like to hear.  Thats an unusual
> baud rate.
>
> Assuming a baud_base of 128000, your divisor will be 65 or 66.
>
> 128000/66=1939 -14
> 128000/65=1969 +13
>
> One thing I've been wondering about with linux is which would be the right
> answer in cases like this.  Right now it would just go with a baud base of
> 65 and ignore the modulus details.
>
> It appears to be a general trend for kernel developers to hide these
> details thinking that they can come up with a general solution.  Then they
> run out of time.  Perahps the solution is to help out but there are
> ultiple OS's rxtx supports making that nontrivial.
>
> If you look at current linux kernels, the 'tricks' above have been marked
> deprecated with no replacement.  Windows has some hard defines and then
> ancient near magic.  I've not looked at Solaris via Open Solaris yet but
> doubt there is a solution at all.
>
> What I'd try since you have the equipment and the monitor software is to
> hardcode the dcb->Baud in termios.c to 1953 (no define) and see what the
> w32 kernel does with it.  I think if you toss a baud rate at the driver it
> will try to come close.  You may try comming closer to a real baudrate
> based upon the 128000 baud base as shown above.
>
> If it works, it is worth looking at the rest of the ping/pong logic then.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
>
>
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From doug at dupreeinc.com  Thu Jun  1 13:22:13 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 12:22:13 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011107210.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
Message-ID: <447F3E65.1020809@dupreeinc.com>

Hello,

I am still trying to get this startup a little faster so I turned on the 
debug of a few of the classes.  The COM ports are scanned really fast 
and the delay occurs during the LPT scan.  The console output looks like 
this:

    ...
      LPT1
      LPT2
      LPT3
     valid port prefixes:
      LPT
    LPT1 LPT
    1 1
    LPT2 LPT
    2 2                                                                 
      * <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
    CommPortIdentifier:addPortName(LPT2)
    CommPortIdentifier:AddIdentifierToList()
    LPT3 LPT
    3 3
    CommPortIdentifier:addPortName(LPT3)
    CommPortIdentifier:AddIdentifierToList()
    CommPortIdentifier:AddIdentifierToList() index.next
    Leaving registerValidPorts()
    Have not implemented native_psmisc_report_owner(PortName)); in
    CommPortIdentifier
    CommPortIdentifier:getPortIdentifier(COM3)
    CommPortIdentifier:open(densConnect, 30000)
    RXTXCommDriver:getCommPort(COM3,1)
    ...

It would seem to me that if I removed the code for port scanning of LPT 
ports I could solve this problem. I would much prefer to use unmodified 
code if at all possible.  Do any of you have alternate suggestions?

Thank you for your time.

Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/cf433ee7/attachment-0014.html

From tjarvi at qbang.org  Thu Jun  1 13:52:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 13:52:06 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F3E65.1020809@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011348380.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I am still trying to get this startup a little faster so I turned on the 
> debug of a few of the classes.  The COM ports are scanned really fast and the 
> delay occurs during the LPT scan.  The console output looks like this:
>
>   ...
>     LPT1
>     LPT2
>     LPT3
>    valid port prefixes:
>     LPT
>   LPT1 LPT
>   1 1
>   LPT2 LPT
>   2 2                                                                      * 
> <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>   CommPortIdentifier:addPortName(LPT2)
>   CommPortIdentifier:AddIdentifierToList()
>   LPT3 LPT
>   3 3
>   CommPortIdentifier:addPortName(LPT3)
>   CommPortIdentifier:AddIdentifierToList()
>   CommPortIdentifier:AddIdentifierToList() index.next
>   Leaving registerValidPorts()
>   Have not implemented native_psmisc_report_owner(PortName)); in
>   CommPortIdentifier
>   CommPortIdentifier:getPortIdentifier(COM3)
>   CommPortIdentifier:open(densConnect, 30000)
>   RXTXCommDriver:getCommPort(COM3,1)
>   ...
>
> It would seem to me that if I removed the code for port scanning of LPT ports 
> I could solve this problem. I would much prefer to use unmodified code if at 
> all possible.  Do any of you have alternate suggestions?
>
> Thank you for your time.
>
> Doug
>


Does commenting out the LPT enumeration actually help?  There can often be 
differences between debug information printed and whats really going on. 
When you combine various environments the debug info can even come out in 
the wrong order.

I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
I do not think this problem is universal.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Thu Jun  1 14:29:44 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:29:44 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4E38.2060004@dupreeinc.com>

I will give it a try.  One thing to note on this PC is it has no LPT 
Parallel ports.

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
>>Hello,
>>
>>I am still trying to get this startup a little faster so I turned on the 
>>debug of a few of the classes.  The COM ports are scanned really fast and the 
>>delay occurs during the LPT scan.  The console output looks like this:
>>
>>  ...
>>    LPT1
>>    LPT2
>>    LPT3
>>   valid port prefixes:
>>    LPT
>>  LPT1 LPT
>>  1 1
>>  LPT2 LPT
>>  2 2                                                                      * 
>><<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>>  CommPortIdentifier:addPortName(LPT2)
>>  CommPortIdentifier:AddIdentifierToList()
>>  LPT3 LPT
>>  3 3
>>  CommPortIdentifier:addPortName(LPT3)
>>  CommPortIdentifier:AddIdentifierToList()
>>  CommPortIdentifier:AddIdentifierToList() index.next
>>  Leaving registerValidPorts()
>>  Have not implemented native_psmisc_report_owner(PortName)); in
>>  CommPortIdentifier
>>  CommPortIdentifier:getPortIdentifier(COM3)
>>  CommPortIdentifier:open(densConnect, 30000)
>>  RXTXCommDriver:getCommPort(COM3,1)
>>  ...
>>
>>It would seem to me that if I removed the code for port scanning of LPT ports 
>>I could solve this problem. I would much prefer to use unmodified code if at 
>>all possible.  Do any of you have alternate suggestions?
>>
>>Thank you for your time.
>>
>>Doug
>>
>>    
>>
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/dd31fed5/attachment-0014.html

From doug at dupreeinc.com  Thu Jun  1 14:36:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:36:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4FC8.9080106@dupreeinc.com>

Trent,

I commented out the section in RegisterScannedPorts() that adds the 
three LPT ports to the CandidateDeviceNames string array.  The 
application started immediately.  This is probably not the way to do 
this, but it was quick ,dirty, and worked.

It would be nice if there was a way to pole the OS to see if there is 
even a port there, though I guess this is what this code is suppose to do...

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
> ...
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From lynn at swcp.com  Thu Jun  1 14:49:34 2006
From: lynn at swcp.com (lynn@swcp.com)
Date: Thu, 1 Jun 2006 20:49:34 -0000
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>,
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <twig.1149194974.97617@swcp.com>

Perhaps we could add an argument to port enumeration where if not specified,
you get the default behavior that looks for everything.  With a new
constructor that has an argument(or more) you could optionally declare it to
not inspect printer ports.

Existing code would work as it always has.  New code could be smarter.

Lynn



Doug Thistlethwaite <doug at dupreeinc.com> said:

> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
> >On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
> >
> >  
> >
> > ...
> >
> >
> >Does commenting out the LPT enumeration actually help?  There can often be 
> >differences between debug information printed and whats really going on. 
> >When you combine various environments the debug info can even come out in 
> >the wrong order.
> >
> >I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
> >I do not think this problem is universal.
> >
> >--
> >Trent Jarvi
> >tjarvi at qbang.org
> >_______________________________________________
> >Rxtx mailing list
> >Rxtx at qbang.org
> >http://mailman.qbang.org/mailman/listinfo/rxtx
> >
> >
> >  
> >
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



-- 





From jredman at ergotech.com  Thu Jun  1 15:20:20 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 01 Jun 2006 15:20:20 -0600
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
Message-ID: <447F5A14.6010803@ergotech.com>

Doug,

If you specifically request ports, eg:

-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

or
 
-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

Depending upon the version  (Windows is COM1:COM2, etc. I assume).

Does it still enumerate the parallel ports?

Jim

Doug Thistlethwaite wrote:
> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
>> On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>
>>  
>>
>> ...
>>
>>
>> Does commenting out the LPT enumeration actually help?  There can often be 
>> differences between debug information printed and whats really going on. 
>> When you combine various environments the debug info can even come out in 
>> the wrong order.
>>
>> I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>> I do not think this problem is universal.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>>
>>  
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  1 16:49:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:49:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6EF4.7080709@dupreeinc.com>

I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
folder.  I created this file and added the following to the file:

gnu.io.rxtx.SerialPorts=COM3

and I get the following error on the console:
CommPortIdentifier:static initialization()
RXTXCommDriver {}
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
RXTXCommDriver:
    Jar version = RXTX-2.1-7
    native lib Version = RXTX-2.1-7
RXTXCommDriver:initialize()
checking for system-known ports of type 1
checking registry for ports of type 1

RXTXCommDriver:addSpecifiedPorts()
Exception in thread "main" java.lang.ExceptionInInitializerError
    at 
densconnect.SerialConnection.openConnection(SerialConnection.java:136)
    at densconnect.DensTalk.<init>(DensTalk.java:165)
    at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
    at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
    at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
    at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
Caused by: java.lang.NullPointerException
    at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
CommPortIdentifier:addPortName(COM3)
CommPortIdentifier:AddIdentifierToList()
CommPortIdentifier:AddIdentifierToList() null
...


It looks like it  read COM3 from the file, but it had the above 
exception that killed it.  The strange this is this error is from 
RXTXCommDriver initialize function (if statement line):

        OS = System.getProperty("os.name");
                System.out.println("OS NAME: " + OS);
        if(OS.toLowerCase().indexOf("linux") == -1)

OS is returning null, thus the error.

If the file is not present, it scans the ports and reads the OS.

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>Doug Thistlethwaite wrote:
>  
>
>>Trent,
>>
>>I commented out the section in RegisterScannedPorts() that adds the 
>>three LPT ports to the CandidateDeviceNames string array.  The 
>>application started immediately.  This is probably not the way to do 
>>this, but it was quick ,dirty, and worked.
>>
>>It would be nice if there was a way to pole the OS to see if there is 
>>even a port there, though I guess this is what this code is suppose to do...
>>
>>Doug
>>
>>Trent Jarvi wrote:
>>
>>    
>>
>>>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>>
>>> 
>>>
>>>...
>>>
>>>
>>>Does commenting out the LPT enumeration actually help?  There can often be 
>>>differences between debug information printed and whats really going on. 
>>>When you combine various environments the debug info can even come out in 
>>>the wrong order.
>>>
>>>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>>>I do not think this problem is universal.
>>>
>>>--
>>>Trent Jarvi
>>>tjarvi at qbang.org
>>>_______________________________________________
>>>Rxtx mailing list
>>>Rxtx at qbang.org
>>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>>
>>>
>>> 
>>>
>>>      
>>>
>>_______________________________________________
>>Rxtx mailing list
>>Rxtx at qbang.org
>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>    
>>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/bf4cca0e/attachment-0014.html

From doug at dupreeinc.com  Thu Jun  1 16:51:26 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:51:26 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6F6E.5060603@dupreeinc.com>

Jim,

I did not try your suggestion as I do not understand where I would put 
these command line parameters (it that is what they are).  It appears 
that using the properties file should do that same thing...

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>
>  
>


From doug at dupreeinc.com  Thu Jun  1 17:56:19 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 16:56:19 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
Message-ID: <447F7EA3.6050400@dupreeinc.com>

I think there is an error in the registerSpecifiedPorts() method.  When 
I have a gnu.io.rxtx.properties file in the ext directory, this function 
kills the System class  IF I call System.getProperty("os.name") before 
the call  to registerSpecifiedPorts(), it returns the os name, after the 
call, it returns null.  I have not played much with properties, except 
for reading them, so I don't really understand the code.

Doug



From doug at dupreeinc.com  Thu Jun  1 18:11:14 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 17:11:14 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F7EA3.6050400@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com>
Message-ID: <447F8222.3060402@dupreeinc.com>

Ok, I just hacked this thing up and got it to read the 
gnu.io.rxtx.properties file.

I commented out the line:
System.setProperties(p); in the method registerSpecifiedPorts() in 
RXTXCommDriver class.  I really don't understand that much about 
properties, but this call kills the System class.

I used the following in the gnu.io.rxtx.properties file:

gnu.io.rxtx.SerialPorts=COM3
gnu.io.rxtx.ParallelPorts=null

This allows the application to open very quickly without any errors.  
Whomever coded this class or somebody who understands properties should 
look at this method and make sure it is doing what they expect.

Doug




Doug Thistlethwaite wrote:

>I think there is an error in the registerSpecifiedPorts() method.  When 
>I have a gnu.io.rxtx.properties file in the ext directory, this function 
>kills the System class  IF I call System.getProperty("os.name") before 
>the call  to registerSpecifiedPorts(), it returns the os name, after the 
>call, it returns null.  I have not played much with properties, except 
>for reading them, so I don't really understand the code.
>
>Doug
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From tjarvi at qbang.org  Thu Jun  1 18:32:50 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 18:32:50 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F6EF4.7080709@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com> <447F6EF4.7080709@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011831510.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
> folder.  I created this file and added the following to the file:
>
> gnu.io.rxtx.SerialPorts=COM3
>
> and I get the following error on the console:
> CommPortIdentifier:static initialization()
> RXTXCommDriver {}
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
> RXTXCommDriver:
>   Jar version = RXTX-2.1-7
>   native lib Version = RXTX-2.1-7
> RXTXCommDriver:initialize()
> checking for system-known ports of type 1
> checking registry for ports of type 1
>
> RXTXCommDriver:addSpecifiedPorts()
> Exception in thread "main" java.lang.ExceptionInInitializerError
>   at densconnect.SerialConnection.openConnection(SerialConnection.java:136)
>   at densconnect.DensTalk.<init>(DensTalk.java:165)
>   at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
>   at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
>   at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
>   at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
> Caused by: java.lang.NullPointerException
>   at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
> CommPortIdentifier:addPortName(COM3)
> CommPortIdentifier:AddIdentifierToList()
> CommPortIdentifier:AddIdentifierToList() null
> ...
>
>

There is a solution for this bug.

http://bugzilla.qbang.org/show_bug.cgi?id=54

We have been horribly slow at getting the next round of patches in but 
they are comming.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  2 00:58:02 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 08:58:02 +0200
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F8222.3060402@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
Message-ID: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>

Hi Doug,

you wrote in an earlier message, that you would prefer an unchanged  
version. What about simply removing the RXTX parallel lib from the  
ext directory. This does not fix the bug, but it should fix your  
problem.

In general I think it is not a good idea to put the RXTX files in a  
system wide location. Putting the libs in the application folder and  
including the .jar in the application classpath (or application jar)  
is all that is required.

Regards,
Joachim

On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:

> Ok, I just hacked this thing up and got it to read the
> gnu.io.rxtx.properties file.
>
> I commented out the line:
> System.setProperties(p); in the method registerSpecifiedPorts() in
> RXTXCommDriver class.  I really don't understand that much about
> properties, but this call kills the System class.
>
> I used the following in the gnu.io.rxtx.properties file:
>
> gnu.io.rxtx.SerialPorts=COM3
> gnu.io.rxtx.ParallelPorts=null
>
> This allows the application to open very quickly without any errors.
> Whomever coded this class or somebody who understands properties  
> should
> look at this method and make sure it is doing what they expect.
>
> Doug
>
>
>
>
> Doug Thistlethwaite wrote:
>
>> I think there is an error in the registerSpecifiedPorts() method.   
>> When
>> I have a gnu.io.rxtx.properties file in the ext directory, this  
>> function
>> kills the System class  IF I call System.getProperty("os.name")  
>> before
>> the call  to registerSpecifiedPorts(), it returns the os name,  
>> after the
>> call, it returns null.  I have not played much with properties,  
>> except
>> for reading them, so I don't really understand the code.
>>
>> 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 antonio.luis at iscte.pt  Fri Jun  2 02:42:28 2006
From: antonio.luis at iscte.pt (=?ISO-8859-1?Q?Ant=F3nio_Lopes?=)
Date: Fri, 02 Jun 2006 09:42:28 +0100
Subject: [Rxtx] Exception when closing serial port
Message-ID: <447FF9F4.7060209@iscte.pt>

Hello everyone,
I've been using RXTX in a Java application in my Pocket PC.
The communication through the (bluetooth) serial port is working perfectly.

However, when I disconnect the app and close the serial port, sometimes I get 
the following error:

"1149237595000: RXTXPort:close detected bad File Descriptor"

The problem is that after this error occurs, the app is no longer able to 
connect to the serial port and I have to soft-reset the device in order to be 
able to connect to it again.

Any ideas on how to solve this issue?

Any help is appreciated.
Thanks,
regards,
-- 
Ant?nio Lopes

@contact: antonio.luis at iscte.pt
@work: ADETTI - ISCTE
@web: http://antonio.lopes.googlepages.com


From paul.klissner at sun.com  Fri Jun  2 02:44:34 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 01:44:34 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to RXTX
	again
Message-ID: <447FFA72.6040807@sun.com>

After looking into javax.comm 3.1 and what it would take to re-engineer it
to be compatible with RXTX platform libraries, I've decided, due my group's
priorities, complexity of the effort vs. benefit, and limited resources, 
to re-post
javax.comm 2.0 binaries on Sun's software download server, unsupported,
with disclaimers, as it was previously.

I don't think there will be any snags doing this from the standpoint of Sun
management or legality.  I will try to have it  posted there in the next 
week
or two, depending on how fast we can get it pushed through the process.

I'd like to think of this as a stop gap measure... ie. a compromise, 
where, at some
point in the not too distant future RXTX implements their own version of the
Java side of the API, as is normally done by javax.extension porters. 
That way
we avoid uncomfortable dependencies in the future.  And that really is 
the Java
development model.

Since RXTX already has the back-end code, porting the java code shouldn't
be a gargantuan effort at all, and RXTX will be in full control of the 
code top
to bottom. I think RXTX can do at least as good a job as the original 
coder.
Prepping 2.0 to be open sourced is more trouble than it is worth. ie. I 
don't
think the current implementation warrants it.

Ultimately, it would be nice to see someone open up a JSR and re-architect
the comm. API to overcome some of it's current design flaws (ie. be more
adaptable to modern platforms, more pluggable, better defined SPI, better
port ownership handling, etc...). A superior architecture would allow for
better collaboration in the future and better interchangeability of 
components
among projects.

Sun's 3.1 version of javax.comm, which is Sun's currently supported version,
has changes pertaining mostly to Sun platform-specific portmapping and has
some minor additional interactions with our back end code, but generally
has little bearing on RXTX. 

Paul



From joachim at buechse.de  Fri Jun  2 04:00:19 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 12:00:19 +0200
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
	RXTX again
In-Reply-To: <447FFA72.6040807@sun.com>
References: <447FFA72.6040807@sun.com>
Message-ID: <1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>

Good day Paul!

A clean architecture with loadable drivers and reusable code would be  
very beneficial for the future, I think everybody agrees. However  
this could be several years into the future. In the meantime, there  
is a real existing problem with IO support on Java. I have the strong  
feeling that most programmers want to code against one specification  
(javax.comm) and be able to replace the underlying implementation via  
a "plugin" on platforms where the SUN implementation is not  
sufficient. RXTX could be just this plugin (reusing very close to 0%  
of the javax.comm implementation but 100% of its API).

I want to propose an API addition and implementation change that will  
take less then 2 hours of manpower to implement and create a solution  
that can bridge the years until javax.comm has been based on a new  
architecture.

Looking at the javax.comm api at http://java.sun.com/products/ 
javacomm/reference/api/index.html I would like to propose the following:

The only entry point to javax.comm is CommPortIdentifier. It has 3  
static methods plus the constructor.

1) define one additional Interface

public interface CommProvider {
    CommPortIdentifier getPortIdentifier(CommPort port);
    CommPortIdentifier getPortIdentifier(String portName);
    Enumeration getPortIdentifiers ();
}

2) add one method to CommPortIdentifier

   public static setCustomCommProvider (CommProvider);

3) change the three static methods of CommPortIdentifier to dispatch  
to the CommProvider if it is set

4) change the constructor of CommPortIdentifier to

   public CommPortIdentifier(...) {
      if (isProviderSet && this.getClass() ==  
javax.comm.CommPortIdentifier) {
          throw new RuntimeException("illegal creation of  
CommPortIndentifier, custom CommProvider is in use");
      }

5) (this is optional, but would be very nice) automatically set a  
custom CommProvider if it is found on the classpath or defined via a  
system property.


The above 1) - 4) can be implemented in less than 1hour. 5) may take  
another hour. I agree that this is not the most elegant design, but  
it would solve a lot of problems with very little effort. It would  
certainly allow RXTX to move forward. If the javax.comm API needs to  
be redesigned completely this addition will not hurt, as people will  
move to the new API anyway and javax.comm 3.0 was so far never  
included in the main distribution.

Best regards,
Joachim

On 02.06.2006, at 10:44, Paul Klissner wrote:

> After looking into javax.comm 3.1 and what it would take to re- 
> engineer it
> to be compatible with RXTX platform libraries, I've decided, due my  
> group's
> priorities, complexity of the effort vs. benefit, and limited  
> resources,
> to re-post
> javax.comm 2.0 binaries on Sun's software download server,  
> unsupported,
> with disclaimers, as it was previously.
>
> I don't think there will be any snags doing this from the  
> standpoint of Sun
> management or legality.  I will try to have it  posted there in the  
> next
> week
> or two, depending on how fast we can get it pushed through the  
> process.
>
> I'd like to think of this as a stop gap measure... ie. a compromise,
> where, at some
> point in the not too distant future RXTX implements their own  
> version of the
> Java side of the API, as is normally done by javax.extension porters.
> That way
> we avoid uncomfortable dependencies in the future.  And that really is
> the Java
> development model.
>
> Since RXTX already has the back-end code, porting the java code  
> shouldn't
> be a gargantuan effort at all, and RXTX will be in full control of the
> code top
> to bottom. I think RXTX can do at least as good a job as the original
> coder.
> Prepping 2.0 to be open sourced is more trouble than it is worth.  
> ie. I
> don't
> think the current implementation warrants it.
>
> Ultimately, it would be nice to see someone open up a JSR and re- 
> architect
> the comm. API to overcome some of it's current design flaws (ie. be  
> more
> adaptable to modern platforms, more pluggable, better defined SPI,  
> better
> port ownership handling, etc...). A superior architecture would  
> allow for
> better collaboration in the future and better interchangeability of
> components
> among projects.
>
> Sun's 3.1 version of javax.comm, which is Sun's currently supported  
> version,
> has changes pertaining mostly to Sun platform-specific portmapping  
> and has
> some minor additional interactions with our back end code, but  
> generally
> has little bearing on RXTX.
>
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Fri Jun  2 09:10:13 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Fri, 2 Jun 2006 09:10:13 -0600 (MDT)
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <447FFA72.6040807@sun.com>
References: <447FFA72.6040807@sun.com>
Message-ID: <Pine.LNX.4.61.0606020906400.15971@www>

On Fri, 2 Jun 2006, Paul Klissner wrote:

> After looking into javax.comm 3.1 and what it would take to re-engineer it
> to be compatible with RXTX platform libraries, I've decided, due my group's
> priorities, complexity of the effort vs. benefit, and limited resources,
> to re-post
> javax.comm 2.0 binaries on Sun's software download server, unsupported,
> with disclaimers, as it was previously.
>

Hi Paul

To address users' immediate needs, we can release rxtx 2.0-7 (final) to 
match the 2.0 binaries from Sun when they are offered for download.

We can discuss potential long term solutions after that.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Fri Jun  2 10:20:09 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 02 Jun 2006 09:20:09 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
	<9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
Message-ID: <44806539.8080902@dupreeinc.com>

Thanks for the suggestion, I will give it a try.

Doug

Joachim Buechse wrote:

>Hi Doug,
>
>you wrote in an earlier message, that you would prefer an unchanged  
>version. What about simply removing the RXTX parallel lib from the  
>ext directory. This does not fix the bug, but it should fix your  
>problem.
>
>In general I think it is not a good idea to put the RXTX files in a  
>system wide location. Putting the libs in the application folder and  
>including the .jar in the application classpath (or application jar)  
>is all that is required.
>
>Regards,
>Joachim
>
>On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:
>
>  
>
>>Ok, I just hacked this thing up and got it to read the
>>gnu.io.rxtx.properties file.
>>
>>I commented out the line:
>>System.setProperties(p); in the method registerSpecifiedPorts() in
>>RXTXCommDriver class.  I really don't understand that much about
>>properties, but this call kills the System class.
>>
>>I used the following in the gnu.io.rxtx.properties file:
>>
>>gnu.io.rxtx.SerialPorts=COM3
>>gnu.io.rxtx.ParallelPorts=null
>>
>>This allows the application to open very quickly without any errors.
>>Whomever coded this class or somebody who understands properties  
>>should
>>look at this method and make sure it is doing what they expect.
>>
>>Doug
>>
>>
>>
>>
>>Doug Thistlethwaite wrote:
>>
>>    
>>
>>>I think there is an error in the registerSpecifiedPorts() method.   
>>>When
>>>I have a gnu.io.rxtx.properties file in the ext directory, this  
>>>function
>>>kills the System class  IF I call System.getProperty("os.name")  
>>>before
>>>the call  to registerSpecifiedPorts(), it returns the os name,  
>>>after the
>>>call, it returns null.  I have not played much with properties,  
>>>except
>>>for reading them, so I don't really understand the code.
>>>
>>>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
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060602/c8892a46/attachment-0014.html

From paul.klissner at sun.com  Fri Jun  2 12:09:26 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 11:09:26 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
Message-ID: <44807ED6.8000903@sun.com>

Joachim Buechse wrote:
> Good day Paul!
>
> A clean architecture with loadable drivers and reusable code would be  
> very beneficial for the future, I think everybody agrees. However  
> this could be several years into the future. In the meantime, there  
> is a real existing problem with IO support on Java. I have the strong  
> feeling that most programmers want to code against one specification  
> (javax.comm) and be able to replace the underlying implementation via  
> a "plugin" on platforms where the SUN implementation is not  
> sufficient. RXTX could be just this plugin (reusing very close to 0%  
> of the javax.comm implementation but 100% of its API).
>
> I want to propose an API addition and implementation change that will  
> take less then 2 hours of manpower to implement and create a solution  
> that can bridge the years until javax.comm has been based on a new  
> architecture.
>
> Looking at the javax.comm api at http://java.sun.com/products/ 
> javacomm/reference/api/index.html I would like to propose the following:
>
> The only entry point to javax.comm is CommPortIdentifier. It has 3  
> static methods plus the constructor.
>
> 1) define one additional Interface
>
> public interface CommProvider {
>     CommPortIdentifier getPortIdentifier(CommPort port);
>     CommPortIdentifier getPortIdentifier(String portName);
>     Enumeration getPortIdentifiers ();
> }
>
> 2) add one method to CommPortIdentifier
>
>    public static setCustomCommProvider (CommProvider);
>
> 3) change the three static methods of CommPortIdentifier to dispatch  
> to the CommProvider if it is set
>
> 4) change the constructor of CommPortIdentifier to
>
>    public CommPortIdentifier(...) {
>       if (isProviderSet && this.getClass() ==  
> javax.comm.CommPortIdentifier) {
>           throw new RuntimeException("illegal creation of  
> CommPortIndentifier, custom CommProvider is in use");
>       }
>
> 5) (this is optional, but would be very nice) automatically set a  
> custom CommProvider if it is found on the classpath or defined via a  
> system property.
>
>
> The above 1) - 4) can be implemented in less than 1hour. 5) may take  
> another hour. I agree that this is not the most elegant design, but  
> it would solve a lot of problems with very little effort. It would  
> certainly allow RXTX to move forward. If the javax.comm API needs to  
> be redesigned completely this addition will not hurt, as people will  
> move to the new API anyway and javax.comm 3.0 was so far never  
> included in the main distribution.
>
> Best regards,
> Joachi
I'm afraid modifying the interface classes isn't my call.  There was 
actually
a TCK written and one of the tests was to ensure that the interface classes
match the spec.  Thus my hands have already been tied since this project
was essentially grandfathered into the JCP.

That's why we need to open a new JSR and find someone who wants
to be the spec lead, and go in with a new reference implementation.
I'm not sure why it would have to take years, since this isn't bleeding edge
technology and there are only so many things that can be done with it,
and we already have practical experience about many functional aspects
that we could cite precedence on.

As it becomes clear that the specification is being accepted completely
or by-and-large by the community, nothing would stop people from
starting adapting to the new API (using the reference implementation or
porting it) and using it in their projects prior to it's final community and
JCP approval, since approval is required only to make it official and
get the "100% pure java" certification for platform ports.

You have one idea already.  Why don't you implement it, solicit some
design feedback from Sun and the RXTX, and create a functional
implementation that addresses the needs of the community, then
we can document it and open a JSR.  That's it.  It should march through
the approval stages reasonably quickly I would imagine, and meantime
RXTX could start using it.

Paul




From doug at dupreeinc.com  Fri Jun  2 12:45:01 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 02 Jun 2006 11:45:01 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
	<9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
Message-ID: <4480872D.6000605@dupreeinc.com>

Joachim,

Thank you for the suggestion.  I restored the jar file to the one I 
downloaded, moved the dll files into the project directory, and added 
the jar to the classpath.  The SerialDemo program that was included with 
the Sun commapi started in 12 seconds instead of the 58 seconds when the 
parallel dll is present.  I did get the startup time to about a second 
by modifying the java code and adding the properties file but this is 
probably not a good idea.

Doug

Joachim Buechse wrote:

>Hi Doug,
>
>you wrote in an earlier message, that you would prefer an unchanged  
>version. What about simply removing the RXTX parallel lib from the  
>ext directory. This does not fix the bug, but it should fix your  
>problem.
>
>In general I think it is not a good idea to put the RXTX files in a  
>system wide location. Putting the libs in the application folder and  
>including the .jar in the application classpath (or application jar)  
>is all that is required.
>
>Regards,
>Joachim
>
>On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:
>
>  
>
>>Ok, I just hacked this thing up and got it to read the
>>gnu.io.rxtx.properties file.
>>
>>I commented out the line:
>>System.setProperties(p); in the method registerSpecifiedPorts() in
>>RXTXCommDriver class.  I really don't understand that much about
>>properties, but this call kills the System class.
>>
>>I used the following in the gnu.io.rxtx.properties file:
>>
>>gnu.io.rxtx.SerialPorts=COM3
>>gnu.io.rxtx.ParallelPorts=null
>>
>>This allows the application to open very quickly without any errors.
>>Whomever coded this class or somebody who understands properties  
>>should
>>look at this method and make sure it is doing what they expect.
>>
>>Doug
>>
>>
>>
>>
>>Doug Thistlethwaite wrote:
>>
>>    
>>
>>>I think there is an error in the registerSpecifiedPorts() method.   
>>>When
>>>I have a gnu.io.rxtx.properties file in the ext directory, this  
>>>function
>>>kills the System class  IF I call System.getProperty("os.name")  
>>>before
>>>the call  to registerSpecifiedPorts(), it returns the os name,  
>>>after the
>>>call, it returns null.  I have not played much with properties,  
>>>except
>>>for reading them, so I don't really understand the code.
>>>
>>>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
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060602/3c0e420f/attachment-0014.html

From joachim at buechse.de  Fri Jun  2 13:46:36 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 21:46:36 +0200
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
	RXTX again
In-Reply-To: <44807ED6.8000903@sun.com>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
	<44807ED6.8000903@sun.com>
Message-ID: <6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>

Hello Paul,

of course, the basic change I suggested could be done "hidden".  The  
CommProvider interface could live somewhere in sun.xyz.*
The setCustomCommProvider method would not be in CommPortIdentifier  
but also somewhere in sun.xyz.* This would be an unofficial feature,  
the official interface stays exactly the same. However RXTX (and  
others) could access the hidden interface.

Don't get me wrong, I don't want to harass you into making changes  
you don't like (which probably wouldn't work anyway;-). But I'm a  
long time Java programmer and seeing the state of cross platform  
serial support for Java makes me feel really sad. In fact, when I  
started to look into Java serial port programming some months ago I  
was very surprised that javax.comm never made it into the JDK.

I'm sorry that I did not contribute my feedback to the JSR for  
javax.comm 3.0. However at the time I didn't do serial port  
programming in Java. I agree that a new JSR should be opened - I'm  
not an expert on JSRs or the JCP process, but from looking quickly  
over the progress of some JSRs I would be very surprised if we can  
have a new version in less then a year. In the meanwhile some people  
will start using javax.comm 3.0 (which can not be supported by RXTX),  
some will use javax.comm 2.0 (which means the 2.0.7 release of RXTX  
still needs to be maintained). This may get even worse if eg Apple  
decides to port and include javax.comm 3.0 at which point it may get  
very tricky to write a cross platform Java application.

All of this simply means, that we are loosing a lot of man-power that  
could otherwise be invested in building a clean solution and/or to  
add features that are becoming more and more important (USB events...).

In the automation / machine control universe Java makes a lot of  
sense. Right now many people are migrating to Linux or from  
propietary systems (even DOS) to Windows. Writing the control/ 
configuration applications in Java is the kings way to unify the code  
base.

Best regards,
Joachim


On 02.06.2006, at 20:09, Paul Klissner wrote:

> Joachim Buechse wrote:
>> Good day Paul!
>>
>> A clean architecture with loadable drivers and reusable code would be
>> very beneficial for the future, I think everybody agrees. However
>> this could be several years into the future. In the meantime, there
>> is a real existing problem with IO support on Java. I have the strong
>> feeling that most programmers want to code against one specification
>> (javax.comm) and be able to replace the underlying implementation via
>> a "plugin" on platforms where the SUN implementation is not
>> sufficient. RXTX could be just this plugin (reusing very close to 0%
>> of the javax.comm implementation but 100% of its API).
>>
>> I want to propose an API addition and implementation change that will
>> take less then 2 hours of manpower to implement and create a solution
>> that can bridge the years until javax.comm has been based on a new
>> architecture.
>>
>> Looking at the javax.comm api at http://java.sun.com/products/
>> javacomm/reference/api/index.html I would like to propose the  
>> following:
>>
>> The only entry point to javax.comm is CommPortIdentifier. It has 3
>> static methods plus the constructor.
>>
>> 1) define one additional Interface
>>
>> public interface CommProvider {
>>     CommPortIdentifier getPortIdentifier(CommPort port);
>>     CommPortIdentifier getPortIdentifier(String portName);
>>     Enumeration getPortIdentifiers ();
>> }
>>
>> 2) add one method to CommPortIdentifier
>>
>>    public static setCustomCommProvider (CommProvider);
>>
>> 3) change the three static methods of CommPortIdentifier to dispatch
>> to the CommProvider if it is set
>>
>> 4) change the constructor of CommPortIdentifier to
>>
>>    public CommPortIdentifier(...) {
>>       if (isProviderSet && this.getClass() ==
>> javax.comm.CommPortIdentifier) {
>>           throw new RuntimeException("illegal creation of
>> CommPortIndentifier, custom CommProvider is in use");
>>       }
>>
>> 5) (this is optional, but would be very nice) automatically set a
>> custom CommProvider if it is found on the classpath or defined via a
>> system property.
>>
>>
>> The above 1) - 4) can be implemented in less than 1hour. 5) may take
>> another hour. I agree that this is not the most elegant design, but
>> it would solve a lot of problems with very little effort. It would
>> certainly allow RXTX to move forward. If the javax.comm API needs to
>> be redesigned completely this addition will not hurt, as people will
>> move to the new API anyway and javax.comm 3.0 was so far never
>> included in the main distribution.
>>
>> Best regards,
>> Joachi
> I'm afraid modifying the interface classes isn't my call.  There was
> actually
> a TCK written and one of the tests was to ensure that the interface  
> classes
> match the spec.  Thus my hands have already been tied since this  
> project
> was essentially grandfathered into the JCP.
>
> That's why we need to open a new JSR and find someone who wants
> to be the spec lead, and go in with a new reference implementation.
> I'm not sure why it would have to take years, since this isn't  
> bleeding edge
> technology and there are only so many things that can be done with it,
> and we already have practical experience about many functional aspects
> that we could cite precedence on.
>
> As it becomes clear that the specification is being accepted  
> completely
> or by-and-large by the community, nothing would stop people from
> starting adapting to the new API (using the reference  
> implementation or
> porting it) and using it in their projects prior to it's final  
> community and
> JCP approval, since approval is required only to make it official and
> get the "100% pure java" certification for platform ports.
>
> You have one idea already.  Why don't you implement it, solicit some
> design feedback from Sun and the RXTX, and create a functional
> implementation that addresses the needs of the community, then
> we can document it and open a JSR.  That's it.  It should march  
> through
> the approval stages reasonably quickly I would imagine, and meantime
> RXTX could start using it.
>
> Paul
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From paul.klissner at sun.com  Fri Jun  2 14:38:49 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 13:38:49 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
	<44807ED6.8000903@sun.com>
	<6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>
Message-ID: <4480A1D9.5060106@sun.com>

Joachim Buechse wrote:
> Hello Paul,
>
> of course, the basic change I suggested could be done "hidden".  The  
> CommProvider interface could live somewhere in sun.xyz.*
> The setCustomCommProvider method would not be in CommPortIdentifier  
> but also somewhere in sun.xyz.* This would be an unofficial feature,  
> the official interface stays exactly the same. However RXTX (and  
> others) could access the hidden interface.
>
> Don't get me wrong, I don't want to harass you into making changes  
> you don't like (which probably wouldn't work anyway;-). But I'm a  
> long time Java programmer and seeing the state of cross platform  
> serial support for Java makes me feel really sad. In fact, when I  
> started to look into Java serial port programming some months ago I  
> was very surprised that javax.comm never made it into the JDK.
>
> I'm sorry that I did not contribute my feedback to the JSR for  
> javax.comm 3.0. 
There was no JSR for 3.0, because we didn't have the resources to make 
the commitment.
Yet Sun needed to add support for platform-dependent port name mapping, 
which had to
be done 'under the hood', since the API isn't designed to handle that in 
a pluggable way.
But these quick fixes aren't the right approach, they just kick the dog 
down the road,
setting bad precedent, inviting confusion and more intractable problems 
(such as the
one plaguing us now).

My changes could have been layered better, it was a trade off between 
achieving an
ideal architecture, trying to find internal reviewers, and meet the 
needs of big customers
in a timely way.  Thus my namespace changes collided with RXTX's 
dependencies.
I was unaware of Jagane's rogue agreement made with the RXTX community 7 
years ago,
before Jagane left Sun.  I think this was a wag-the-dog situation.

Now it is time to do it right, and I don't think it is going to be as 
much trouble as people
some people fear. If RXTX wants to sponsor the JSR and seed a new spec, 
Sun can join
the Expert Group.  And we'd be largely in agreement, since we're not 
talking about
humongous changes, and looking for mutually beneficial changes. The core 
API is already
largely proved and tested.
> However at the time I didn't do serial port  
> programming in Java. I agree that a new JSR should be opened - I'm  
> not an expert on JSRs or the JCP process, but from looking quickly  
> over the progress of some JSRs I would be very surprised if we can  
> have a new version in less then a year. 
*Approved*  But that doesn't mean the spec couldn't be 99.9% stable 
before that.  Once
the delta rate declines and changes approach nil, people could start 
adapting to the API in
advance of formal approval.   It isn't going to be drawn out like 
javax.usb, which was new
technology, a very complex API, and involved precedent setting corporate 
disputes and
policy issues to resolve.

> In the meanwhile some people  
> will start using javax.comm 3.0 (which can not be supported by RXTX),  
> some will use javax.comm 2.0 (which means the 2.0.7 release of RXTX  
> still needs to be maintained). This may get even worse if eg Apple  
> decides to port and include javax.comm 3.0 at which point it may get  
> very tricky to write a cross platform Java application.
>   
The interfaces haven't changed since 1.0.  If we open a JSR ,we can 
contact Apple and
allow them to be on the E.G., if they want.  That might make the JSR a 
bit more drawn out,
but then we'd arrive ultimately arrive at a best-of-all-worlds API that 
most people would
accept, perhaps forever, and arrive at a respectable set of compromises.

-Paul

> All of this simply means, that we are loosing a lot of man-power that  
> could otherwise be invested in building a clean solution and/or to  
> add features that are becoming more and more important (USB events...).
>
> In the automation / machine control universe Java makes a lot of  
> sense. Right now many people are migrating to Linux or from  
> propietary systems (even DOS) to Windows. Writing the control/ 
> configuration applications in Java is the kings way to unify the code  
> base.
>
> Best regards,
> Joachim
>
>
> On 02.06.2006, at 20:09, Paul Klissner wrote:
>
>   
>> Joachim Buechse wrote:
>>     
>>> Good day Paul!
>>>
>>> A clean architecture with loadable drivers and reusable code would be
>>> very beneficial for the future, I think everybody agrees. However
>>> this could be several years into the future. In the meantime, there
>>> is a real existing problem with IO support on Java. I have the strong
>>> feeling that most programmers want to code against one specification
>>> (javax.comm) and be able to replace the underlying implementation via
>>> a "plugin" on platforms where the SUN implementation is not
>>> sufficient. RXTX could be just this plugin (reusing very close to 0%
>>> of the javax.comm implementation but 100% of its API).
>>>
>>> I want to propose an API addition and implementation change that will
>>> take less then 2 hours of manpower to implement and create a solution
>>> that can bridge the years until javax.comm has been based on a new
>>> architecture.
>>>
>>> Looking at the javax.comm api at http://java.sun.com/products/
>>> javacomm/reference/api/index.html I would like to propose the  
>>> following:
>>>
>>> The only entry point to javax.comm is CommPortIdentifier. It has 3
>>> static methods plus the constructor.
>>>
>>> 1) define one additional Interface
>>>
>>> public interface CommProvider {
>>>     CommPortIdentifier getPortIdentifier(CommPort port);
>>>     CommPortIdentifier getPortIdentifier(String portName);
>>>     Enumeration getPortIdentifiers ();
>>> }
>>>
>>> 2) add one method to CommPortIdentifier
>>>
>>>    public static setCustomCommProvider (CommProvider);
>>>
>>> 3) change the three static methods of CommPortIdentifier to dispatch
>>> to the CommProvider if it is set
>>>
>>> 4) change the constructor of CommPortIdentifier to
>>>
>>>    public CommPortIdentifier(...) {
>>>       if (isProviderSet && this.getClass() ==
>>> javax.comm.CommPortIdentifier) {
>>>           throw new RuntimeException("illegal creation of
>>> CommPortIndentifier, custom CommProvider is in use");
>>>       }
>>>
>>> 5) (this is optional, but would be very nice) automatically set a
>>> custom CommProvider if it is found on the classpath or defined via a
>>> system property.
>>>
>>>
>>> The above 1) - 4) can be implemented in less than 1hour. 5) may take
>>> another hour. I agree that this is not the most elegant design, but
>>> it would solve a lot of problems with very little effort. It would
>>> certainly allow RXTX to move forward. If the javax.comm API needs to
>>> be redesigned completely this addition will not hurt, as people will
>>> move to the new API anyway and javax.comm 3.0 was so far never
>>> included in the main distribution.
>>>
>>> Best regards,
>>> Joachi
>>>       
>> I'm afraid modifying the interface classes isn't my call.  There was
>> actually
>> a TCK written and one of the tests was to ensure that the interface  
>> classes
>> match the spec.  Thus my hands have already been tied since this  
>> project
>> was essentially grandfathered into the JCP.
>>
>> That's why we need to open a new JSR and find someone who wants
>> to be the spec lead, and go in with a new reference implementation.
>> I'm not sure why it would have to take years, since this isn't  
>> bleeding edge
>> technology and there are only so many things that can be done with it,
>> and we already have practical experience about many functional aspects
>> that we could cite precedence on.
>>
>> As it becomes clear that the specification is being accepted  
>> completely
>> or by-and-large by the community, nothing would stop people from
>> starting adapting to the new API (using the reference  
>> implementation or
>> porting it) and using it in their projects prior to it's final  
>> community and
>> JCP approval, since approval is required only to make it official and
>> get the "100% pure java" certification for platform ports.
>>
>> You have one idea already.  Why don't you implement it, solicit some
>> design feedback from Sun and the RXTX, and create a functional
>> implementation that addresses the needs of the community, then
>> we can document it and open a JSR.  That's it.  It should march  
>> through
>> the approval stages reasonably quickly I would imagine, and meantime
>> RXTX could start using it.
>>
>> Paul
>>
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at 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  Sat Jun  3 18:15:24 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 18:15:24 -0600 (MDT)
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
Message-ID: <Pine.LNX.4.61.0606031715100.10890@www>


The attached patch allows baud rates of 14400, 28800, 128000 and 256000.

That was my goal.

[import standard disclaimer]

But I took some time to look a little further.  I got custom baud rates 
working enough that someone (perhaps me) can properly fix them in the 
future.  Proof of concept.

As an undocumented bonus, you can toss random baudrates (say 1953), at the 
API and it will set it to something close to that on windows and linux. 
Solaris should say the baud rate is not supported but I have not tested it 
yet.  Mac OS X behavior is unknown at this point.  Just dont expect 
correct behavior at ~8192-9009 baudrates or baudrates less than 20 on 
windows; these baud rates overlap with defines in win32termios.h.  I 
conveniently closed my eyes there.  Try another value close.  On Linux, a 
baud base and divisor are guestimated and set.  On windows, we wave pixie 
dust over the kernel driver and hope.  Do not expect pixie dust and 
guestimates to be the same on windows and linux.  They may well round to 
different values in yet to be tested ways.  There are only so many 
divisors.  If it isn't working, try a little higher or lower.

In the example of 1953 for instance, there is no divisor for commodity 
hardware that comes to that baudrate.  We just come close on one side or 
the other.  If tools tell you they got 1953 exactly, the tools may be 
questionable and just reading values not directly related to the actual 
hardware settings.

These fixes have been tested on Linux and Windows while using an 
oscilloscope to confirm they change relative to known baudrates at 9600, 
14400*, 19200, 28800* (and 1800, 1953** and 2400).

* = previously unsupported.
** = still not supported but probably works from what I saw.

There could be future discussion in this area.  For now this is working 
for almost all unusual baud rate demands.  Cleaning up the custom baud 
rate should be easier with a working starting point.  Baud bases other 
than 128000 have not been characterized.  Yes.. this overlapps with two of 
the baud rates enabled.

Feedback and ideas are welcome.

--
Trent Jarvi
tjarvi at qbang.org
-------------- next part --------------
Index: SerialImp.c
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v
retrieving revision 1.46.2.187
diff -u -r1.46.2.187 SerialImp.c
--- SerialImp.c	29 Jan 2006 22:19:04 -0000	1.46.2.187
+++ SerialImp.c	3 Jun 2006 23:12:40 -0000
@@ -793,6 +793,19 @@
 		result &= ~TIOCM_DTR;
 		ioctl( fd, TIOCMSET, &result );
 	}
+	/*
+	   B38400 is a special case in Linux for custom baud rates.
+
+	   We just treat this as a custom speed for now.  If you take this ifdef
+	   out and select baud rates 38400 then 28800 then 38400, you will get
+	   a final baud rate of 28800 because you did not update the divisor.
+
+	   See the next ifdef below for the divisor.
+	*/
+#if defined(TIOCGSERIAL)
+	if ( cspeed == B38400 )
+		cspeed = 38400;
+#endif /* TIOCGSERIAL */
 	if(     cfsetispeed( &ttyset, cspeed ) < 0 ||
 		cfsetospeed( &ttyset, cspeed ) < 0 )
 	{
@@ -814,6 +827,7 @@
 		*/
 
 #if defined(TIOCGSERIAL)
+		ioctl( fd, TIOCGSERIAL, &sstruct );
 		sstruct.custom_divisor = ( sstruct.baud_base/cspeed );
 		cspeed = B38400;
 #endif /* TIOCGSERIAL */
@@ -827,7 +841,7 @@
 #if defined(TIOCSSERIAL)
 		/*  It is assumed Win32 does this for us */
 		if (	sstruct.baud_base < 1 ||
-			ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
+		ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
 		{
 			return( 1 );
 		}
Index: termios.c
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v
retrieving revision 1.9.2.56
diff -u -r1.9.2.56 termios.c
--- termios.c	16 Jan 2006 02:50:32 -0000	1.9.2.56
+++ termios.c	3 Jun 2006 23:12:40 -0000
@@ -323,8 +323,8 @@
 		case CBR_3500000:	return( B3500000 );
 		case CBR_4000000:	return( B4000000 );
 		default:
-			set_errno(EINVAL );
-			return -1;
+			/* assume custom baudrate */
+			return( Baud );
 	}
 }
 
@@ -361,12 +361,13 @@
 		case B9600:	ret = CBR_9600;		break;
 		case B14400:	ret = CBR_14400;	break;
 		case B19200:	ret = CBR_19200;	break;
+		case B28800:	ret = CBR_28800;	break;
 		case B38400:	ret = CBR_38400;	break;
 		case B57600:	ret = CBR_57600;	break;
 		case B115200:	ret = CBR_115200;	break;
 		case B128000:	ret = CBR_128000;	break;
-		case B256000: 	ret = CBR_256000;	break;
 		case B230400:	ret = CBR_230400;	break;
+		case B256000: 	ret = CBR_256000;	break;
 		case B460800:	ret = CBR_460800;	break;
 		case B500000:	ret = CBR_500000;	break;
 		case B576000:	ret = CBR_576000;	break;
@@ -381,10 +382,8 @@
 		case B4000000:	ret = CBR_4000000;	break;
 	
 		default:
-			fprintf( stderr, "B_to_CBR: invalid baudrate: %#o\n",
-				Baud );
-			set_errno( EINVAL );
-			return -1;
+			/* assume custom baudrate */
+			return Baud;
 	}
 	LEAVE( "B_to_CBR" );
 	return ret;
@@ -708,12 +707,9 @@
 	ENTER( "init_serial_struct" );
 
 	/*
-	FIXME
-
-	This needs to use inb() to read the actual baud_base
-	and divisor from the UART registers.  Question is how
-	far do we take this?
-
+	use of custom_divisor and baud_base requires access to
+	kernel space.  The kernel does try its best if you just
+	toss a baud rate at it though.
 	*/
 
 	sstruct->custom_divisor = 0;
@@ -1678,16 +1674,17 @@
 {
 	char message[80];
 	ENTER( "cfsetospeed" );
+	/* clear baudrate */
+	s_termios->c_cflag &= ~CBAUD;
 	if ( speed & ~CBAUD )
 	{
 		sprintf( message, "cfsetospeed: not speed: %#o\n", speed );
 		report( message );
-		return 0;
+		/* continue assuming its a custom baudrate */
+		s_termios->c_cflag |= B38400;  /* use 38400 during custom */
+		s_termios->c_cflag |= CBAUDEX; /* use CBAUDEX for custom */
 	}
-	s_termios->c_ispeed = s_termios->c_ospeed = speed;
-	/* clear baudrate */
-	s_termios->c_cflag &= ~CBAUD;
-	if( speed )
+	else if( speed )
 	{
 		s_termios->c_cflag |= speed;
 	}
@@ -1696,6 +1693,7 @@
 		/* PC blows up with speed 0 handled in Java */
 		s_termios->c_cflag |= B9600;
 	}
+	s_termios->c_ispeed = s_termios->c_ospeed = speed;
 	LEAVE( "cfsetospeed" );
 	return 1;
 }
@@ -1767,25 +1765,6 @@
 }
 
 /*----------------------------------------------------------
-serial_struct_to_DCB()
-
-   accept:      
-   perform:     
-   return:      
-   exceptions:  
-   win32api:     None
-   comments:    
-----------------------------------------------------------*/
-int serial_struct_to_DCB( struct serial_struct *sstruct, DCB *dcb )
-{
-	/* 5 Baud rate fix
-	sstruct.baud_base
-	sstruct.custom_divisor = ( sstruct.baud_base/cspeed );
-	*/
-	return(0);
-}
-
-/*----------------------------------------------------------
 termios_to_DCB()
 
    accept:      
@@ -1798,7 +1777,8 @@
 int termios_to_DCB( struct termios *s_termios, DCB *dcb )
 {
 	ENTER( "termios_to_DCB" );
-	s_termios->c_ispeed = s_termios->c_ospeed = s_termios->c_cflag & CBAUD;
+	if ( !(s_termios->c_cflag & CBAUDEX) )
+		s_termios->c_ispeed = s_termios->c_ospeed = s_termios->c_cflag & CBAUD;
 	dcb->BaudRate        = B_to_CBR( s_termios->c_ispeed );
 	dcb->ByteSize = termios_to_bytesize( s_termios->c_cflag );
 
@@ -2863,11 +2843,6 @@
 			GetCommState( index->hComm, dcb );
 
 			index->sstruct = va_arg( ap, struct serial_struct * );
-			if ( serial_struct_to_DCB( index->sstruct, dcb ) < 0 )
-			{
-				va_end( ap );
-				return -1;
-			}
 
 			report( "TIOCSSERIAL\n" );
 			free(dcb);
Index: win32termios.h
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v
retrieving revision 1.5.2.28
diff -u -r1.5.2.28 win32termios.h
--- win32termios.h	30 Jun 2005 20:23:26 -0000	1.5.2.28
+++ win32termios.h	3 Jun 2006 23:12:40 -0000
@@ -279,7 +279,7 @@
 #define XTABS	01000000 /* Hmm.. Linux/i386 considers this part of TABDLY.. */
 
 /* c_cflag bit meaning */
-# define CBAUD	0010017
+#define  CBAUD  0030017
 #define  B0	0000000		/* hang up */
 #define  B50	0000001
 #define  B75	0000002
@@ -312,13 +312,16 @@
 #define  B3500000 0010016
 #define  B4000000 0010017
 
-/* glue for unsupported linux speeds see also SerialImp.h */
-/* hosed */
-
-#define B14400		1010001
-#define B28800		1010002
-#define B128000		1010003
-#define B256000		1010004
+/*
+	glue for unsupported linux speeds see also SerialImp.h 
+	custom baud rates around 8192-9000 will not work because
+	of these.
+*/
+
+#define B14400		0020001
+#define B28800		0020002
+#define B128000		0020003
+#define B256000		0020004
 
 #define EXTA B19200
 #define EXTB B38400
@@ -356,8 +359,10 @@
 
 /* glue for unsupported windows speeds */
 
-#define CBR_230400	230400
 #define CBR_28800	28800
+#define CBR_128000	128000
+#define CBR_230400	230400
+#define CBR_256000	256000
 #define CBR_460800	460800
 #define CBR_500000	500000
 #define CBR_576000	576000

From impakt01 at optusnet.com.au  Sat Jun  3 18:30:37 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 10:30:37 +1000
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
In-Reply-To: <Pine.LNX.4.61.0606031715100.10890@www>
Message-ID: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>

Hi Trent,
I'd love to try the patch but I can't get the latest build compiling, only
pre16. 

Can you attach the rxtxSerial.dll file with this patch?

Also, I hardcoded 1953 in a couple more places last night on pre16 and it
managed to open the port at the right speed, but stopped receiving anything
after 100-150 bytes, even though more data was getting sent to the port.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 10:15 AM
To: rxtx at qbang.org
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.


The attached patch allows baud rates of 14400, 28800, 128000 and 256000.

That was my goal.

[import standard disclaimer]

But I took some time to look a little further.  I got custom baud rates 
working enough that someone (perhaps me) can properly fix them in the 
future.  Proof of concept.

As an undocumented bonus, you can toss random baudrates (say 1953), at the 
API and it will set it to something close to that on windows and linux. 
Solaris should say the baud rate is not supported but I have not tested it 
yet.  Mac OS X behavior is unknown at this point.  Just dont expect 
correct behavior at ~8192-9009 baudrates or baudrates less than 20 on 
windows; these baud rates overlap with defines in win32termios.h.  I 
conveniently closed my eyes there.  Try another value close.  On Linux, a 
baud base and divisor are guestimated and set.  On windows, we wave pixie 
dust over the kernel driver and hope.  Do not expect pixie dust and 
guestimates to be the same on windows and linux.  They may well round to 
different values in yet to be tested ways.  There are only so many 
divisors.  If it isn't working, try a little higher or lower.

In the example of 1953 for instance, there is no divisor for commodity 
hardware that comes to that baudrate.  We just come close on one side or 
the other.  If tools tell you they got 1953 exactly, the tools may be 
questionable and just reading values not directly related to the actual 
hardware settings.

These fixes have been tested on Linux and Windows while using an 
oscilloscope to confirm they change relative to known baudrates at 9600, 
14400*, 19200, 28800* (and 1800, 1953** and 2400).

* = previously unsupported.
** = still not supported but probably works from what I saw.

There could be future discussion in this area.  For now this is working 
for almost all unusual baud rate demands.  Cleaning up the custom baud 
rate should be easier with a working starting point.  Baud bases other 
than 128000 have not been characterized.  Yes.. this overlapps with two of 
the baud rates enabled.

Feedback and ideas are welcome.

--
Trent Jarvi
tjarvi at qbang.org



From tjarvi at qbang.org  Sat Jun  3 19:05:11 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 19:05:11 -0600 (MDT)
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
In-Reply-To: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>
References: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606031840400.10890@www>

On Sun, 4 Jun 2006, Daren wrote:

> Hi Trent,
> I'd love to try the patch but I can't get the latest build compiling, only
> pre16.
>
> Can you attach the rxtxSerial.dll file with this patch?
>
> Also, I hardcoded 1953 in a couple more places last night on pre16 and it
> managed to open the port at the right speed, but stopped receiving anything
> after 100-150 bytes, even though more data was getting sent to the port.
>


ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing

I dont think they will hang.  But I was just testing via loopback/break 
out box/scope.

I'll be putting about 10 patches and another set of binaries in that 
directory shortly.  For now the binaries should just have the baud_rate 
fix.

I'll announce all the patches at once.  but wont be releasing 2.1-8 right 
away.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Sat Jun  3 21:00:01 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 21:00:01 -0600 (MDT)
Subject: [Rxtx] CVS for 2.1 should have everything
Message-ID: <Pine.LNX.4.61.0606032056190.10890@www>


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org


From impakt01 at optusnet.com.au  Sat Jun  3 21:08:14 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 13:08:14 +1000
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <Pine.LNX.4.61.0606032056190.10890@www>
Message-ID: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>

Hi Trent,
I tried the latest dll and it opens the port, receives 100-200 bytes and
then stops receiving anything else..

I'll keep playing with it.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 1:00 PM
To: rxtx at qbang.org
Subject: [Rxtx] CVS for 2.1 should have everything


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From impakt01 at optusnet.com.au  Sat Jun  3 21:22:41 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 13:22:41 +1000
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
Message-ID: <200606040322.k543MqW1008455@mail12.syd.optusnet.com.au>

Played with it, problem, with a while loop in my code, working great now

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Daren
Sent: Sunday, 4 June 2006 1:08 PM
To: 'RXTX Developers and Users'
Subject: Re: [Rxtx] CVS for 2.1 should have everything

Hi Trent,
I tried the latest dll and it opens the port, receives 100-200 bytes and
then stops receiving anything else..

I'll keep playing with it.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 1:00 PM
To: rxtx at qbang.org
Subject: [Rxtx] CVS for 2.1 should have everything


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Sat Jun  3 21:35:41 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 21:35:41 -0600 (MDT)
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
References: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606032131140.10890@www>

On Sun, 4 Jun 2006, Daren wrote:

> Hi Trent,
> I tried the latest dll and it opens the port, receives 100-200 bytes and
> then stops receiving anything else..
>
> I'll keep playing with it.
>
> Daren

The difference may be that I'm talking to something at the exact same baud 
rate (loopback).

You may also try setting the baudrate to ~1933 and ~1973 to force the 
guesses one way or the other.  If you are on windows, we are not doing 
anything fancy in the end.  Thats the kernel guessing.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sun Jun  4 04:12:09 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sun, 4 Jun 2006 12:12:09 +0200
Subject: [Rxtx] Update of OSX installer, Readme, etc
Message-ID: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>

Good day,

after the latest changes a lot of OS X specific files should be  
updated. Especially the installer!

- The "MaxOSX" readme file on the root level is outdated (ie  
CodeWarrior information). Maybe we could even rename it to README.OSX  
to be in line with README.IPAQ, README.SCO (Trent do you mind copying/ 
renaming ,v files in the repository?).

- The lock files are no longer used and hence the user group magic  
and lock folder creation should be removed from the installer.

- MACOSX_IDE/ForPackageMaker/Resources/ReadMe.rtf and Welcome.rtf  
need to be updated.

- I suggest to replace the current installation instruction for OS X:  
Installation should occur into the application directory, not in the  
Java-VM directory. This simplifies things a lot, as the Mac Installer  
can be removed completely.

- The xcodeproject's build settings need to be updated to generate  
JAVA 1.1 format class files.


Dimitry: do you have time to tackle this? I could do it, but as this  
is "your baby" I thought you may prefer to do it yourself.

Regards,
Joachim



From dmarkman at mac.com  Sun Jun  4 11:27:53 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Sun, 4 Jun 2006 13:27:53 -0400
Subject: [Rxtx] Update of OSX installer, Readme, etc
In-Reply-To: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
References: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
Message-ID: <26E7A202-962B-4C19-93B6-29426C467249@mac.com>

Joachim,
unfortunately I don't have time right now to do that
so if you can do that, please do

it's not only my baby
it's yours too :-)

thanks


On Jun 4, 2006, at 6:12 AM, Joachim Buechse wrote:

> Good day,
>
> after the latest changes a lot of OS X specific files should be
> updated. Especially the installer!
>
> - The "MaxOSX" readme file on the root level is outdated (ie
> CodeWarrior information). Maybe we could even rename it to README.OSX
> to be in line with README.IPAQ, README.SCO (Trent do you mind copying/
> renaming ,v files in the repository?).
>
> - The lock files are no longer used and hence the user group magic
> and lock folder creation should be removed from the installer.
>
> - MACOSX_IDE/ForPackageMaker/Resources/ReadMe.rtf and Welcome.rtf
> need to be updated.
>
> - I suggest to replace the current installation instruction for OS X:
> Installation should occur into the application directory, not in the
> Java-VM directory. This simplifies things a lot, as the Mac Installer
> can be removed completely.
>
> - The xcodeproject's build settings need to be updated to generate
> JAVA 1.1 format class files.
>
>
> Dimitry: do you have time to tackle this? I could do it, but as this
> is "your baby" I thought you may prefer to do it yourself.
>
> Regards,
> Joachim
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman



From tjarvi at qbang.org  Sun Jun  4 13:54:02 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 4 Jun 2006 13:54:02 -0600 (MDT)
Subject: [Rxtx] Update of OSX installer, Readme, etc
In-Reply-To: <26E7A202-962B-4C19-93B6-29426C467249@mac.com>
References: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
	<26E7A202-962B-4C19-93B6-29426C467249@mac.com>
Message-ID: <Pine.LNX.4.61.0606041353040.22522@www>

On Sun, 4 Jun 2006, Dmitry Markman wrote:

> Joachim,
> unfortunately I don't have time right now to do that
> so if you can do that, please do
>
> it's not only my baby
> it's yours too :-)
>

I've given Joachim cvs access.  He has shown good work in bugzilla.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Mon Jun  5 10:08:32 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 5 Jun 2006 18:08:32 +0200
Subject: [Rxtx] Build process changes for Mac OS X
Message-ID: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>

Good day,

I have cleaned up some outdated Mac OSX specific build files in the  
repository.

There was not a lot left of the readme file "MacOSX" after cleaning  
it up, so I decided to rename it README.OSX to be in harmony with the  
other files in the directory (ie README.IPAQ, README.SCO, ...)

I added an (uncompressed) XCode 2.3 project file/structure  
with .cvsignore files that will ignore the user specific settings.  
This should work "out of the box" for OSX10.4. Users of 10.2/10.3 may  
have to switch the build settings.

[It's kind of tricky to choose "the right" setting. Afaik there is no  
way to compile a universal binary that will work on 10.3 or before.  
So it's either UniversalBinary OR Legacy. Maybe we should have  
different build targets for these different targets?? I would like to  
get some feedback from the Mac developers on this list regarding the  
subject].

Besides other things the OSX installer is no longer required. Since  
the next version (2.1.8) will no longer use lockfiles on OSX, the  
group/permission magic is no longer required and hence there remains  
basicly no work for the installer - other than copying 2 files to the  
VM extension directory. Then again, this is not the best way to  
install RXTX. So I removed the installer completely without modifying  
it, this should simplify a "resurrection" should it ever get necessary.

I had problems with the (compressed, ie sit.hqx) legacy project files  
on the latest installation of OSX (javac 1.5 creating non JDK1.1  
class files and some minor problems). To reduce potential confusion  
for newcomers I decided to remove them. This means that there is no  
longer a simple way to build RXTX for OSX 10.0 and 10.1 (I deeply  
apologize if anyone still relied on this ... well the files are in  
the Attiq).

Best regards,
Joachim


From joachim at buechse.de  Mon Jun  5 10:16:37 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 5 Jun 2006 18:16:37 +0200
Subject: [Rxtx] RXTX and lockfiles on OSX [it is fixed now]
Message-ID: <7D2C4418-9397-4B59-8091-9FDE4ED67836@buechse.de>

Quite a number of people contacted me in the last couple of weeks  
because of problems installing RXTX on OSX. I told you to wait for  
the "official" fix. Well, it has been fixed.

So if you were among the people waiting for the solution, you can now  
download the source rxtx-2.1-7r2.zip from the website. Once unpacked  
dont forget to use "cvs up" to update the files to the latest  
version. You can then open MACOSX_IDE/XCode/ 
LibSerialUniversal.xcodeproj with XCode 2.3 and build the libraries  
that no longer try to create lock files.

Regards,
Joachim


From brian at mbari.org  Mon Jun  5 10:52:43 2006
From: brian at mbari.org (Brian Schlining)
Date: Mon, 5 Jun 2006 09:52:43 -0700
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
Message-ID: <78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>

Hi Joachim,

> [It's kind of tricky to choose "the right" setting. Afaik there is no
> way to compile a universal binary that will work on 10.3 or before.
> So it's either UniversalBinary OR Legacy. Maybe we should have
> different build targets for these different targets?? I would like to
> get some feedback from the Mac developers on this list regarding the
> subject].

I imagine most developers will be compiling on 10.4 (It's the nature  
of the coder...gotta have the latest and greatest) and deploying to  
both 10.3 and 10.4; both of which will run Universal Binaries (see  
http://forums.macrumors.com/showthread.php?t=205348). So it sounds  
like you've covered the majority of users. Still, you know someone's  
going to pipe up about needing RXTX on 10.2 so it would be nice to  
have a target to make a PPC only build.

Just my 2 cents

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/1cac8c39/attachment-0014.html

From dmarkman at mac.com  Mon Jun  5 13:47:50 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Mon, 5 Jun 2006 15:47:50 -0400
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
Message-ID: <686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>

I don't think it will be a problem to run universal binary
on 10.2
however if binary has some calls that aren't implemented in 10.2
then you'll have a problem


On Jun 5, 2006, at 12:52 PM, Brian Schlining wrote:

> Hi Joachim,
>
>> [It's kind of tricky to choose "the right" setting. Afaik there is no
>> way to compile a universal binary that will work on 10.3 or before.
>> So it's either UniversalBinary OR Legacy. Maybe we should have
>> different build targets for these different targets?? I would like to
>> get some feedback from the Mac developers on this list regarding the
>> subject].
>
> I imagine most developers will be compiling on 10.4 (It's the  
> nature of the coder...gotta have the latest and greatest) and  
> deploying to both 10.3 and 10.4; both of which will run Universal  
> Binaries (see http://forums.macrumors.com/showthread.php?t=205348).  
> So it sounds like you've covered the majority of users. Still, you  
> know someone's going to pipe up about needing RXTX on 10.2 so it  
> would be nice to have a target to make a PPC only build.
>
> Just my 2 cents
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/9fafc878/attachment-0014.html

From brian at mbari.org  Mon Jun  5 14:52:41 2006
From: brian at mbari.org (Brian Schlining)
Date: Mon, 5 Jun 2006 13:52:41 -0700
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
Message-ID: <E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>

Hi Dmitry,

> I don't think it will be a problem to run universal binary
> on 10.2
> however if binary has some calls that aren't implemented in 10.2
> then you'll have a problem

You're right...I stand corrected.

Note however, to deploy a universal binary to 10.2 RXTX will need to  
use the 10.2 SDK to build the PPC side. (see http:// 
developer.apple.com/documentation/DeveloperTools/Conceptual/ 
cross_development/UniversalBinaries/chapter_4_section_1.html). I  
haven't been paying close attention to the new locking mechanism used  
by RXTX on the Mac...does 10.2 support it?

Joachim, which SDK will you be using by default for building the Mac  
PPC binaries?

>> Hi Joachim,
>>
>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>> is no
>>> way to compile a universal binary that will work on 10.3 or before.
>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>> different build targets for these different targets?? I would  
>>> like to
>>> get some feedback from the Mac developers on this list regarding the
>>> subject].
>>
>> I imagine most developers will be compiling on 10.4 (It's the  
>> nature of the coder...gotta have the latest and greatest) and  
>> deploying to both 10.3 and 10.4; both of which will run Universal  
>> Binaries (see http://forums.macrumors.com/showthread.php? 
>> t=205348). So it sounds like you've covered the majority of users.  
>> Still, you know someone's going to pipe up about needing RXTX on  
>> 10.2 so it would be nice to have a target to make a PPC only build.

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/153bf50e/attachment-0014.html

From dmarkman at mac.com  Mon Jun  5 19:02:04 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Mon, 5 Jun 2006 21:02:04 -0400
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
Message-ID: <7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>

if Joachim didn't change xcode project setting

/Developer/SDKs/MacOSX10.4u.sdk is used to build universal binary

so it's quite possible that it won't run properly on 10.2

so we have to change the building process, so ppc part will be built
with
/Developer/SDKs/MacOSX10.2.8.sdk

and finally to use lipo utility to build universal binaries

Joachim, did you use some specific locking API that wasn't implemented

in MacOSX10.2.8.sdk?

thanks


On Jun 5, 2006, at 4:52 PM, Brian Schlining wrote:

> Hi Dmitry,
>
>> I don't think it will be a problem to run universal binary
>> on 10.2
>> however if binary has some calls that aren't implemented in 10.2
>> then you'll have a problem
>
> You're right...I stand corrected.
>
> Note however, to deploy a universal binary to 10.2 RXTX will need  
> to use the 10.2 SDK to build the PPC side. (see http:// 
> developer.apple.com/documentation/DeveloperTools/Conceptual/ 
> cross_development/UniversalBinaries/chapter_4_section_1.html). I  
> haven't been paying close attention to the new locking mechanism  
> used by RXTX on the Mac...does 10.2 support it?
>
> Joachim, which SDK will you be using by default for building the  
> Mac PPC binaries?
>
>>> Hi Joachim,
>>>
>>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>>> is no
>>>> way to compile a universal binary that will work on 10.3 or before.
>>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>>> different build targets for these different targets?? I would  
>>>> like to
>>>> get some feedback from the Mac developers on this list regarding  
>>>> the
>>>> subject].
>>>
>>> I imagine most developers will be compiling on 10.4 (It's the  
>>> nature of the coder...gotta have the latest and greatest) and  
>>> deploying to both 10.3 and 10.4; both of which will run Universal  
>>> Binaries (see http://forums.macrumors.com/showthread.php? 
>>> t=205348). So it sounds like you've covered the majority of  
>>> users. Still, you know someone's going to pipe up about needing  
>>> RXTX on 10.2 so it would be nice to have a target to make a PPC  
>>> only build.
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/84790f80/attachment-0014.html

From joachim at buechse.de  Tue Jun  6 02:40:47 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 6 Jun 2006 10:40:47 +0200
Subject: [Rxtx] Building on OS X, Impl Changes
In-Reply-To: <7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
Message-ID: <CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>

Good day!

What's in the XCode project setting?
----------

The xcode project remained pretty much the same as before. I excluded  
the user specific files from CVS and changed some settings. I kept  
all the built targets (you shouldn't change what you don't understand;-)

Currently we the following build targets:
    RXTXComm (java files)
    librxtxParallel.jnilib (usefull on the Mac???)
    libI2C.jnilib (not yet working in RXTX)
    libRS485.jnilib (not yet working in RXTX)
    librxtxSerial.jnilib (1)
    librxtxSerial.jnilib Dynamic (2)
    rxtxSerial (3)
We also have the following build configurations for each target:
    Development
    Default
    Deployment

What was changed in the xcode project from previous versions:
- java.souce=1.3 and java.target=1.1 in RXTXComm settings
- removed copying of build products into installer directory
- removed "(Upgraded)" from build target names

What remains to be changed:
- choosing a "non-debug" Build-configuration as default
- potentially removing "Default"/"Development" Build-configurations
- reducing the number of build targets
- creating 10.2 compatible universal binaries

I suggest, that the build configurations should be reduced to 2  
(Debug/Deployment), possibly even 1 (Debug).
I have not yet found the deeper meaning of the build targets(1)(2) 
(3), it seems to me like they should be reduced into one "doing the  
right thing" or maybe into two "rxtxSerial.jnilib Legacy" (back to  
10.2, universal if possible) and "rxtxSerial.jnilib 10.4 
+" (universal, 10.4+).

Should the code work on 10.2?
----------

Absolutely. The code should work on NextStep, in fact on any BSD  
unix. I would go as far as saying, this code should work on any  
POSSIX based unix. All that was added is the call "ioctl(fd,  
TIOCEXCL)" to request excusivity of the port:

http://gemma.apple.com/documentation/DeviceDrivers/Conceptual/ 
WorkingWSerial/WWSerial_SerialDevs/chapter_2_section_8.html

It is not yet "the perfect solution". Normally an open /dev/tty  
(listen for incomming connection) should be "preemptable" by opening  
a /dev/cu (outgoing connection) for the same port. This is not yet  
implemented as it needs calls outside of POSSIX on OSX.

On "classic" systems (like NextStep) this worked based on the  
"carried detect line". open() on /dev/tty.xxx would block until the  
carrier detect signal was raised. As the device was not "opened"  
opening /dev/cu.xxx worked without a hitch. When they ported to the  
Mac this broke. On Macs the "carier detect" is usually not wired.  
Furthermore FAX modems did no longer raise the line. So the OSX  
implementor defined a new call, which is documented here:

http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00045.html

Best regards,
Joachim




On 06.06.2006, at 03:02, Dmitry Markman wrote:

> if Joachim didn't change xcode project setting
>
> /Developer/SDKs/MacOSX10.4u.sdk is used to build universal binary
>
> so it's quite possible that it won't run properly on 10.2
>
> so we have to change the building process, so ppc part will be built
> with
> /Developer/SDKs/MacOSX10.2.8.sdk
>
> and finally to use lipo utility to build universal binaries
>
> Joachim, did you use some specific locking API that wasn't implemented
>
> in MacOSX10.2.8.sdk?
>
> thanks
>
>
> On Jun 5, 2006, at 4:52 PM, Brian Schlining wrote:
>
>> Hi Dmitry,
>>
>>> I don't think it will be a problem to run universal binary
>>> on 10.2
>>> however if binary has some calls that aren't implemented in 10.2
>>> then you'll have a problem
>>
>> You're right...I stand corrected.
>>
>> Note however, to deploy a universal binary to 10.2 RXTX will need  
>> to use the 10.2 SDK to build the PPC side. (see http:// 
>> developer.apple.com/documentation/DeveloperTools/Conceptual/ 
>> cross_development/UniversalBinaries/chapter_4_section_1.html). I  
>> haven't been paying close attention to the new locking mechanism  
>> used by RXTX on the Mac...does 10.2 support it?
>>
>> Joachim, which SDK will you be using by default for building the  
>> Mac PPC binaries?
>>
>>>> Hi Joachim,
>>>>
>>>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>>>> is no
>>>>> way to compile a universal binary that will work on 10.3 or  
>>>>> before.
>>>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>>>> different build targets for these different targets?? I would  
>>>>> like to
>>>>> get some feedback from the Mac developers on this list  
>>>>> regarding the
>>>>> subject].
>>>>
>>>> I imagine most developers will be compiling on 10.4 (It's the  
>>>> nature of the coder...gotta have the latest and greatest) and  
>>>> deploying to both 10.3 and 10.4; both of which will run  
>>>> Universal Binaries (see http://forums.macrumors.com/ 
>>>> showthread.php?t=205348). So it sounds like you've covered the  
>>>> majority of users. Still, you know someone's going to pipe up  
>>>> about needing RXTX on 10.2 so it would be nice to have a target  
>>>> to make a PPC only build.
>>
>> Brian Schlining
>> Software Engineer
>> http://www.mbari.org
>>
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> Dmitry Markman
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Tue Jun  6 07:01:06 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 6 Jun 2006 15:01:06 +0200
Subject: [Rxtx] Serial port code for OS X, future steps
In-Reply-To: <CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
	<CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
Message-ID: <8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>

I posted the "wrong link". There is a correction here:

    http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00059.html

In fact, the 2.1.7 implementation of RXTX has quite some deficiencies  
on OSX. I have tried to supply some patches that don't interfere to  
much with the existing RXTX code base, but there are limits to what  
can be done with local patches.

There are some very intrusive changes that should be done. Ie proper  
mapping of /dev/tty <-> /dev/cu handling to correct behaviour of  
CommPortOwnershipListener (http://java.sun.com/products/javacomm/ 
reference/api/index.html). I dont think this can be done with  
patches. Hence I think, RXTX should be rewritten from scratch de- 
unifying the native code base (and implementing thread safe code on  
the Java side).


How "should" /dev/tty vs /dev/cu be implemented?

=====
The Unix contract is this: An open /dev/tty.xxx port (incomming)  
should be interrupted/auto-closed when opening /dev/cu.xxx (outgoing)  
[if /dev/tty.xxx is not currently handling a communication].  /dev/ 
cu.xxx and /dev/tty.xxx refer to the same device, so owning  
"exclusively" should block both. This should be respected across all  
applications native or Java.

This contract is realizable on OSX with the existing javax.comm  
interface while also respecting (to the biggest part) the contract  
defined by javax.comm.PortOwnershipListener.

The one point where the suggested implementation "breaks" the  
javax.comm contract, is by the fact that one can loose a /dev/tty  
port without calling close. However, the only option I see is to  
always open serial ports "non-exclusively" which would outrule Java  
as a platform for (dormant) applications waiting for incoming  
connections/faxes/etc. There could be a system property to choose the  
intended behavior.
=====

Here is how it could be done on OSX:

Calling port=ComportIdentifier.open("/dev/cu.xxx") opens and owns the  
port exclusively until port.close() is called.
- Java applications listening with a PortOwnershipListener should get  
a PORT_OWNED event reasonably soon.
- Any further attempt by a Java or native application to open "/dev/ 
cu.xxx" or "/dev/tty.xxx" fails.
- /dev/cu.xxx is for "outgoing" connections, so receiving  
PORT_OWNERSHIP_REQUESTED makes little to no sense. With native  
applications it can not be implemented. For Java applications it  
could be implemented (by a hidden communication channel). I think  
it's not worth bothering. If anyone is willing to give up a port to  
others he should use /dev/tty.xxx instead of /dev/cu.xxx.

Registering a PortOwnershipListener on "/dev/cu.xxx" without opening  
it, uses /dev/tty.xxx (native open()) non-exclusively and polls its  
state. PORT_OWNED and PORT_UNOWNED can be produced.

Calling port=ComportIdentifier.open("/dev/tty.xxx") should open the  
port non-exclusively.
- Adding a SerialPortEventListener and reading from the port could be  
allowed while keeping it non-exclusive.
- When port.getOutputStream() is called, the state should be changed  
to an "exclusive" ownership. This may be configurable via a system  
property.
- To return to the non-exclusive state the port must be closed and  
reopened.
- While non-exclusively opened, opening the corresponding /dev/cu.xxx  
produces a PORT_OWNERSHIP_REQUESTED event. Which should be responded  
by closing the port from within the callback (as described in  
java.comm.PortOwnershipListener). If there is a pending read, it will  
return after the listener finishes (with -1 or "0 bytes read").
- Calling write() on the /dev/tty.xxx after somebody opened /dev/ 
cu.xxx will fail with a descriptive IOException.
- Calling read() on the /dev/tty.xxx after somebody opened /dev/ 
cu.xxx will fail with a descriptive IOException (or potentially  
block, see side notes below).

CommPortIdentifier.getCurrentOwner() can be implemented by an  
external call to lsof.

CommPortIdentifier.isCurrentlyOwned() can be implemented by trying an  
open on the /dev/tty.
- It returns true if the port is currently held "exclusively".
- Whether it should also return true on /dev/tty if /dev/tty is  
already opened non-exclusively might be a system property option. In  
general, having several applications waiting for incoming connections  
on the same port will require an application level "arbitration"  
protocol...

[[side note1: One interesting question is, what happens if the  
process holding /dev/tty non-exclusively ignores  
PORT_OWNERSHIP_REQUESTED. Ie after "loosing" a non-exclusively opened  
"dev/tty.xxx" port to another process. One possible implementation  
is, that the port is "regained" when the other process gives up the  
port. This would mean that in the meanwhile read() returns no data,  
and any changes to the configuration of the port are stored but not  
forwarded. I guess, the safe (and simple) way to do this is to make  
the close() mandatory (ie setting the port into an "awaiting_close"  
state which produces IOExceptions to any other call than close). ]]

[[side note2:  Another interesting question is, what should happen if  
several applications open the same /dev/tty.xxx port "non- 
exclusively" and start to change the settings of the device.]]

Regards,
Joachim



On 06.06.2006, at 10:40, Joachim Buechse wrote:

> Should the code work on 10.2?
> ----------
>
> Absolutely. The code should work on NextStep, in fact on any BSD
> unix. I would go as far as saying, this code should work on any
> POSSIX based unix. All that was added is the call "ioctl(fd,
> TIOCEXCL)" to request excusivity of the port:
>
> http://gemma.apple.com/documentation/DeviceDrivers/Conceptual/
> WorkingWSerial/WWSerial_SerialDevs/chapter_2_section_8.html
>
> It is not yet "the perfect solution". Normally an open /dev/tty
> (listen for incomming connection) should be "preemptable" by opening
> a /dev/cu (outgoing connection) for the same port. This is not yet
> implemented as it needs calls outside of POSSIX on OSX.
>
> On "classic" systems (like NextStep) this worked based on the
> "carried detect line". open() on /dev/tty.xxx would block until the
> carrier detect signal was raised. As the device was not "opened"
> opening /dev/cu.xxx worked without a hitch. When they ported to the
> Mac this broke. On Macs the "carier detect" is usually not wired.
> Furthermore FAX modems did no longer raise the line. So the OSX
> implementor defined a new call, which is documented here:
>
> http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00045.html
>
> Best regards,
> Joachim



From sds at dcs.gla.ac.uk  Tue Jun  6 11:22:45 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Tue, 06 Jun 2006 18:22:45 +0100
Subject: [Rxtx] Correct compile flag for HP iPAQ hx4700 running Familiar
	Linux?
Message-ID: <1149614565.19496.10.camel@addu>

Hi,

I'd like to use RXTX 2.1 on my HP iPAQ hx4700. The iPAQ is running
Familiar Linux 0.8.2 (as I recall), with Blackdown Java 1.3.1.

I can compile and run a test program which uses RXTX on my i686 machine,
and it works fine. But I can't seem to get things working quite right on
my PDA.

I compile the code on the laptop with the following commands:
	./configure --host=arm-gnu-linux && make
... as suggested in a post to this list, albeit some time ago. This
compiles, I transfer the files, set up LD_LIBRARY_PATH and CLASSPATH
variables, and get the following error on the PDA:

sds at ipaq-pxa-2:~# java Test
java.lang.UnsatisfiedLinkError: /usr/local/lib/ext/librxtxSerial.so: /usr/local/lib/ext/librxtxSerial.so: cannot open shared object file: No such file or directory thrown while loading gnu.io.RXTXCommDriver
Exception in thread "main"
java.lang.UnsatisfiedLinkError: /usr/local/lib/ext/librxtxSerial.so: /usr/local/lib/ext/librxtxSerial.so: cannot open shared object file: No such file or directory
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1382)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1290)
        at java.lang.Runtime.loadLibrary0(Runtime.java:749)
        at java.lang.System.loadLibrary(System.java:820)
        at
gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:83)
        at Test.<init>(Test.java:9)
        at Test.main(Test.java:32)
sds at ipaq-pxa-2:~# 

Note that I'm copying the files to /usr/local/lib/ext/ along with the
RXTXcomm.jar file, purely to keep things separate from the rest of the
system while testing. The location of the .so files doesn't seem to have
any bearing on whether "java Test" will succeed or not. The contents of
this directory are:

sds at ipaq-pxa-2:~$ ls /usr/local/lib/ext/
RXTXcomm.jar              librxtxParallel-2.1-7.so  librxtxRS485.so
librxtxSerial-2.1-7.so
librxtxI2C-2.1-7.so       librxtxParallel.so        librxtxRaw-2.1-7.so
librxtxSerial.so
librxtxI2C.so             librxtxRS485-2.1-7.so     librxtxRaw.so
sds at ipaq-pxa-2:~$

Test.java fails on the first real line of code I'm using to test that
things are working, prior to real development, and was carefully pinched
from the web:
Enumeration portIdentifiers = CommPortIdentifier.getPortIdentifiers();


I assume that I've gotten my --host flag wrong way back up there at
the ./configure step. But if that's the case, what should I set it to?
Or am I missing something more obvious?


Cheers,
Stephen Strowes,
University of Glasgow.




From tjarvi at qbang.org  Tue Jun  6 13:39:41 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 6 Jun 2006 13:39:41 -0600 (MDT)
Subject: [Rxtx] Serial port code for OS X, future steps
In-Reply-To: <8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
	<CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
	<8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>
Message-ID: <Pine.LNX.4.61.0606061315070.9856@www>


>>
There are some very intrusive changes that should be done. Ie proper
mapping of /dev/tty <-> /dev/cu handling to correct behaviour of
CommPortOwnershipListener (http://java.sun.com/products/javacomm/
reference/api/index.html). I dont think this can be done with
patches. Hence I think, RXTX should be rewritten from scratch de-
unifying the native code base (and implementing thread safe code on
the Java side).
<<

This appears to be a very small amount of functionality for a total 
rewrite.  The port ownership only needs maybe 3 native calls if it is done 
with native calls at all.

Those features which are not part of the Unix standard(s) can be special 
cased.  I'm not sure /dev/cu is standard.  We can look.  I know linux 
deprecated /dev/cua years ago.

Thread safe Java code is not a platform specific issue.

--
Trent Jarvi
tjarvi at qbang.org


From sds at dcs.gla.ac.uk  Wed Jun  7 12:36:43 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Wed, 07 Jun 2006 19:36:43 +0100
Subject: [Rxtx] Expected RXTX behaviour?
In-Reply-To: <1149703900.30891.19.camel@addu>
References: <1149703900.30891.19.camel@addu>
Message-ID: <1149705403.30891.25.camel@addu>

Apologies, caught the problem. Had to append '\r' to the end of the AT
string. A non obvious but stupid mistake... :-)

Final quick question though: How might I stop the echoing of
outputStream data back into the inputStream? I still see the ATI
commands on the inputStream, along with the output from the device.


Cheers,
S.



On Wed, 2006-06-07 at 19:11 +0100, Stephen Strowes wrote:
> Hi,
> 
> I managed to get RXTX to compile for my iPAQ following my previous post
> to this list. Quick query though:
> 
> I want to be able to issue AT commands to a device, and interpret the
> responses. For this, I assume I do the following, in psuedo-form:
> 
> 	CommPortIdentifier.getPortIdentifiers();
> 	// find the correct device id
> 	serialPort= (SerialPort)portID.open("Test");
> 	// Set parameters and flow control
> 	outputStream= serialPort.getOutputStream();
> 	inputStream=  serialPort.getInputStream();
> 
> ... following this, I spawn a thread to respond to DATA_AVAILABLE events
> on serialPort with inputStream, and occasionally write and flush an
> "ATI" onto the outputStream. Nothing complex, I just want to see it
> work.
> 
> I would have expected inputStream to give the same information back from
> an "ATI" command as minicom provides, but instead inputStream only sees
> the "ATI" I put onto the outputStream.
> 
> Have I missed something?
> 
> 
> Cheers,
> S.
> 



From sds at dcs.gla.ac.uk  Wed Jun  7 12:11:40 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Wed, 07 Jun 2006 19:11:40 +0100
Subject: [Rxtx] Expected RXTX behaviour?
Message-ID: <1149703900.30891.19.camel@addu>

Hi,

I managed to get RXTX to compile for my iPAQ following my previous post
to this list. Quick query though:

I want to be able to issue AT commands to a device, and interpret the
responses. For this, I assume I do the following, in psuedo-form:

	CommPortIdentifier.getPortIdentifiers();
	// find the correct device id
	serialPort= (SerialPort)portID.open("Test");
	// Set parameters and flow control
	outputStream= serialPort.getOutputStream();
	inputStream=  serialPort.getInputStream();

... following this, I spawn a thread to respond to DATA_AVAILABLE events
on serialPort with inputStream, and occasionally write and flush an
"ATI" onto the outputStream. Nothing complex, I just want to see it
work.

I would have expected inputStream to give the same information back from
an "ATI" command as minicom provides, but instead inputStream only sees
the "ATI" I put onto the outputStream.

Have I missed something?


Cheers,
S.




From joachim at buechse.de  Wed Jun  7 09:02:13 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 7 Jun 2006 17:02:13 +0200
Subject: [Rxtx] Update of build process for OSX (XCode project)
Message-ID: <62EC47B1-46BD-4ECA-B9EC-C4061D147CDA@buechse.de>

With the help of Dmitry Markman and Brian Schilling I have updated  
(and largely simplifed) the XCode project file for Mac OS X.

Changes:
- compiles a universal binary library with intel=OSX10.4+, ppc=OSX10.2 
+ support
- compiles the Java sources into a JRE1.1 compatible, compressed jar.

Please test on your configuration, especially if you have computers  
running 10.2/10.3 or intel.

Best regards,
Joachim


From joachim at buechse.de  Wed Jun  7 14:36:37 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 7 Jun 2006 22:36:37 +0200
Subject: [Rxtx] Expected RXTX behaviour?
In-Reply-To: <1149705403.30891.25.camel@addu>
References: <1149703900.30891.19.camel@addu> <1149705403.30891.25.camel@addu>
Message-ID: <D3AD6EAF-27BB-455E-9697-86C1121920C3@buechse.de>

Echoing is a feature of the modem. Try ATE0 which works with most  
"rockwell" compatible modems.

Regards,
Joachim


On 07.06.2006, at 20:36, Stephen Strowes wrote:

> Apologies, caught the problem. Had to append '\r' to the end of the AT
> string. A non obvious but stupid mistake... :-)
>
> Final quick question though: How might I stop the echoing of
> outputStream data back into the inputStream? I still see the ATI
> commands on the inputStream, along with the output from the device.
>
>
> Cheers,
> S.
>
>
>
> On Wed, 2006-06-07 at 19:11 +0100, Stephen Strowes wrote:
>> Hi,
>>
>> I managed to get RXTX to compile for my iPAQ following my previous  
>> post
>> to this list. Quick query though:
>>
>> I want to be able to issue AT commands to a device, and interpret the
>> responses. For this, I assume I do the following, in psuedo-form:
>>
>> 	CommPortIdentifier.getPortIdentifiers();
>> 	// find the correct device id
>> 	serialPort= (SerialPort)portID.open("Test");
>> 	// Set parameters and flow control
>> 	outputStream= serialPort.getOutputStream();
>> 	inputStream=  serialPort.getInputStream();
>>
>> ... following this, I spawn a thread to respond to DATA_AVAILABLE  
>> events
>> on serialPort with inputStream, and occasionally write and flush an
>> "ATI" onto the outputStream. Nothing complex, I just want to see it
>> work.
>>
>> I would have expected inputStream to give the same information  
>> back from
>> an "ATI" command as minicom provides, but instead inputStream only  
>> sees
>> the "ATI" I put onto the outputStream.
>>
>> Have I missed something?
>>
>>
>> Cheers,
>> S.
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From g_petrini at yahoo.it  Thu Jun  8 01:41:58 2006
From: g_petrini at yahoo.it (Giacomo Petrini)
Date: Thu, 8 Jun 2006 09:41:58 +0200 (CEST)
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from FieldTalk
Message-ID: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>

Hi,
I'm evaluating the library for the modbus protocol
from FieldTalk
(http://www.modbusdriver.com/fieldtalk/.
I'm using J2SE 5.0 and RXTX 2.1 on win XP.
The problem is that the modbus lib has a method (the
openProtocol method, but maybe there are others) tha
throws the
javax.comm.UnsupportedCommOperationException.
Now, in RXTX 2.1 the namespace has changed in gnu.io,
so the modbus library doesn't work anymore (it look
for things in javax.comm). I've already sent an email
to fieldtalk to see if they are aware of the problem.
The solution should be to use JavaComm + RXTX 2.0. But
I've read somewhere that JavaComm 2.0 does not work
with Java 5.0 and JavaComm 3.0 does not work with RXTX
2.0 so I don't know what to do.

Any ideas?

Thanks Jack

PS: can you make a CC to my personal email
(g_petrini at yahoo.it) too please?

Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 


From rxtx at tapastda.co.uk  Thu Jun  8 02:27:57 2006
From: rxtx at tapastda.co.uk (rxtx@tapastda.co.uk)
Date: Thu, 08 Jun 2006 09:27:57 +0100
Subject: [Rxtx] Win XP and Infrared based serial port
Message-ID: <4487DF8D.5050807@tapastda.co.uk>

I'm attempting to use RXTX 2.1.7 on Win XP with J2SE 5.0 to communicate with a
GSM mobile using a COM port. A peculiarity that I've seen is that whilst I can
communicate successfully with a mobile which uses an infrared based COM port
using the SUN provided javax.comm (v2.0) I cannot use RXTX because it fails to
read anything from the port (i.e. read timeout always occurs returning zero bytes).

I assumed that this could be the result of flow control problems and thus I've
tried setting either software or hardware based flow control on the port however
this has no affect.

Can you suggest any other port configuration changes which might be required to
make such a port work with RXTX.

Thanks
Stu
-- 
Stuart
Tapastda Limited


From tjarvi at qbang.org  Thu Jun  8 05:17:12 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 8 Jun 2006 05:17:12 -0600 (MDT)
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from
	FieldTalk
In-Reply-To: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
References: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606080504480.9856@www>

On Thu, 8 Jun 2006, Giacomo Petrini wrote:

> Hi,
> I'm evaluating the library for the modbus protocol
> from FieldTalk
> (http://www.modbusdriver.com/fieldtalk/.
> I'm using J2SE 5.0 and RXTX 2.1 on win XP.
> The problem is that the modbus lib has a method (the
> openProtocol method, but maybe there are others) tha
> throws the
> javax.comm.UnsupportedCommOperationException.
> Now, in RXTX 2.1 the namespace has changed in gnu.io,
> so the modbus library doesn't work anymore (it look
> for things in javax.comm). I've already sent an email
> to fieldtalk to see if they are aware of the problem.
> The solution should be to use JavaComm + RXTX 2.0. But
> I've read somewhere that JavaComm 2.0 does not work
> with Java 5.0 and JavaComm 3.0 does not work with RXTX
> 2.0 so I don't know what to do.
>
> Any ideas?
>
> Thanks Jack
>


Hi Jack

There are plans for Sun to rerelease JavaComm 2.0 mentioned in the rxtx 
mail-list archives.  When this happens rxtx will release a current rxtx 
2.0 library that works with it.

There are no dates promised by either side but rxtx will do it as soon as 
possible after Sun's rerelease.  Just to give you a feel for the time 
frame, this started last year and no significant progress has been made. 
There have been friendly talks pointing towards solutions (rerelease 2.0) 
but that does not get your application working today.  rxtx is preparing 
for its second release in gnu.io since then.

--
Trent Jarvi
tjarvi at qbang.org




From jredman at ergotech.com  Thu Jun  8 08:47:23 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 08 Jun 2006 08:47:23 -0600
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from
	FieldTalk
In-Reply-To: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
References: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
Message-ID: <4488387B.6040903@ergotech.com>

You could always try a different library, eg.

http://sourceforge.net/projects/jamod

I've only used the slave side since we have our own implementation of 
Modbus Client (and a host of other PLC protocols).  However the client 
side seems to be pretty well supported and fairly widely used.  Since 
the source is there you could change to gnu.io.

I think I should take more of an interest in this issue.  We generally 
run 1.4.2 on Linux, but also have some J9 and old platforms that we 
support that are basically Personal Java.  5.0 on Linux has some 
horrible MDI bugs, to the point of being unusable.   Sounds as though we 
are going to have code compatibility problems across these platforms.

Jim


Giacomo Petrini wrote:
> Hi,
> I'm evaluating the library for the modbus protocol
> from FieldTalk
> (http://www.modbusdriver.com/fieldtalk/.
> I'm using J2SE 5.0 and RXTX 2.1 on win XP.
> The problem is that the modbus lib has a method (the
> openProtocol method, but maybe there are others) tha
> throws the
> javax.comm.UnsupportedCommOperationException.
> Now, in RXTX 2.1 the namespace has changed in gnu.io,
> so the modbus library doesn't work anymore (it look
> for things in javax.comm). I've already sent an email
> to fieldtalk to see if they are aware of the problem.
> The solution should be to use JavaComm + RXTX 2.0. But
> I've read somewhere that JavaComm 2.0 does not work
> with Java 5.0 and JavaComm 3.0 does not work with RXTX
> 2.0 so I don't know what to do.
> 
> Any ideas?
> 
> Thanks Jack
> 
> PS: can you make a CC to my personal email
> (g_petrini at yahoo.it) too please?
> 
> Chiacchiera con i tuoi amici in tempo reale! 
>  http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  8 18:17:23 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 08 Jun 2006 17:17:23 -0700
Subject: [Rxtx] rxtx access is denied error
Message-ID: <4488BE13.2050706@dupreeinc.com>

Hello,

I have been trying to replace the commapi from sun with rxtx for a 
project that communicates with a serial port that is a USB-Serial 
interface.  To be exact, I am using the FTDI VCP driver with one of 
their modules connected to a windows XP system.

I have the RXTX package working pretty well as long as nothing goes wrong.

If a user disconnects the USB port while my java application is running, 
my application goes into an endless loop with lots of messages in the  
errors stream  like the ones below:

    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(481):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.


I believe when this happens the COM port completely disappears and the 
rxtx driver has a heart attack.  Obviously, the user should not do this, 
but my application needs to ideally, correct the situation or as a worse 
case, terminate with a little dignity.  Currently, I have not figured 
out how to catch this error.

The closest I have come is to trap an exception to my input stream read  
that says "No error in readByte"  This error appears to be outside of 
the endless loop of the errors listed above.

Does anybody have an idea of how to identify and trap this error?  Any 
suggestions on how to gracefully recover from it would be greatly 
appreciated!

Thank you for your time,

Doug Thistlethwaite




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060608/9cfca302/attachment-0014.html

From tjarvi at qbang.org  Thu Jun  8 20:54:17 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 8 Jun 2006 20:54:17 -0600 (MDT)
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <4488BE13.2050706@dupreeinc.com>
References: <4488BE13.2050706@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606082022580.1323@www>

On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I have been trying to replace the commapi from sun with rxtx for a project 
> that communicates with a serial port that is a USB-Serial interface.  To be 
> exact, I am using the FTDI VCP driver with one of their modules connected to 
> a windows XP system.
>
> I have the RXTX package working pretty well as long as nothing goes wrong.
>
> If a user disconnects the USB port while my java application is running, my 
> application goes into an endless loop with lots of messages in the  errors 
> stream  like the ones below:
>
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(481):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>
>
> I believe when this happens the COM port completely disappears and the rxtx 
> driver has a heart attack.  Obviously, the user should not do this, but my 
> application needs to ideally, correct the situation or as a worse case, 
> terminate with a little dignity.  Currently, I have not figured out how to 
> catch this error.
>
> The closest I have come is to trap an exception to my input stream read  that 
> says "No error in readByte"  This error appears to be outside of the endless 
> loop of the errors listed above.
>
> Does anybody have an idea of how to identify and trap this error?  Any 
> suggestions on how to gracefully recover from it would be greatly 
> appreciated!
>

Hi Doug

Sadly I don't have a quick solution for you.

Termios has no knowlage about the JVM so it wont be throwing exceptions 
you can catch.

We can return error and set the error number to something reasonable that 
results in an exception.  The No Error message simply means we did not set 
an error number in termios.c.  Those are the line numbers in the code you 
see.  SerialImp.c realizes it errored but does not know much more yet. 
Everything touching the file descriptor is going to error after the port 
is gone presumably.

We don't currently have a plan in place for vanishing (or appearing) com 
ports.

Another example of what we need to think about is what happens if you 
start your application and then plug in the dongle?  Or what if you unplug 
and then plug it in again?

So in each of these three cases, what would the behavior of the (yet to 
be) correct implementation do?

How will the enumerated ports be handled during these changes?

There can also be hints from the OS that could be taken into 
consideration.

We can probably get some exceptions thrown that make sense and null the 
file descriptor when it happens to prevent io attempts.  That would be a 
crude way to let applications know something strange has happened.

Is anyone else tinkering with this problem?

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  9 01:31:29 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 9 Jun 2006 09:31:29 +0200
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <Pine.LNX.4.61.0606082022580.1323@www>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
Message-ID: <AC6EDDDD-0A64-401F-B16B-E484788CDF4A@buechse.de>

Hello Trent,

I am not tinkering with this on the Source Level - but I think it  
should work pretty much the same way as it currently does in OSX.  
When the port goes away you get an IOException thrown for any read/ 
write. It will no longer be in the list of ports from  
CommPortIdentifier.getPortIdentifiers(). When a port (re-)appears it  
is added to the list. It's up to the application to re-check the list  
from time to time.

On Windows you can't do much better then that, because the ports  
don't have useful names. Which USB "virtual com port" is on which  
COMx depends on the order the devices were added. So reconnecting to  
the same device may mean connecting to another port.

Regarding the exception thrown: it would be nice to use an  
IOException subclass but the Exception message should definetly be  
informative also as most applications may want to keep compatibility  
with javax.comm.

Regards,
Joachim


On 09.06.2006, at 04:54, Trent Jarvi wrote:

> On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:
>
>> Hello,
>>
>> I have been trying to replace the commapi from sun with rxtx for a  
>> project
>> that communicates with a serial port that is a USB-Serial  
>> interface.  To be
>> exact, I am using the FTDI VCP driver with one of their modules  
>> connected to
>> a windows XP system.
>>
>> I have the RXTX package working pretty well as long as nothing  
>> goes wrong.
>>
>> If a user disconnects the USB port while my java application is  
>> running, my
>> application goes into an endless loop with lots of messages in  
>> the  errors
>> stream  like the ones below:
>>
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (481):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>
>>
>> I believe when this happens the COM port completely disappears and  
>> the rxtx
>> driver has a heart attack.  Obviously, the user should not do  
>> this, but my
>> application needs to ideally, correct the situation or as a worse  
>> case,
>> terminate with a little dignity.  Currently, I have not figured  
>> out how to
>> catch this error.
>>
>> The closest I have come is to trap an exception to my input stream  
>> read  that
>> says "No error in readByte"  This error appears to be outside of  
>> the endless
>> loop of the errors listed above.
>>
>> Does anybody have an idea of how to identify and trap this error?   
>> Any
>> suggestions on how to gracefully recover from it would be greatly
>> appreciated!
>>
>
> Hi Doug
>
> Sadly I don't have a quick solution for you.
>
> Termios has no knowlage about the JVM so it wont be throwing  
> exceptions
> you can catch.
>
> We can return error and set the error number to something  
> reasonable that
> results in an exception.  The No Error message simply means we did  
> not set
> an error number in termios.c.  Those are the line numbers in the  
> code you
> see.  SerialImp.c realizes it errored but does not know much more yet.
> Everything touching the file descriptor is going to error after the  
> port
> is gone presumably.
>
> We don't currently have a plan in place for vanishing (or  
> appearing) com
> ports.
>
> Another example of what we need to think about is what happens if you
> start your application and then plug in the dongle?  Or what if you  
> unplug
> and then plug it in again?
>
> So in each of these three cases, what would the behavior of the  
> (yet to
> be) correct implementation do?
>
> How will the enumerated ports be handled during these changes?
>
> There can also be hints from the OS that could be taken into
> consideration.
>
> We can probably get some exceptions thrown that make sense and null  
> the
> file descriptor when it happens to prevent io attempts.  That would  
> be a
> crude way to let applications know something strange has happened.
>
> Is anyone else tinkering with this problem?
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From doug at dupreeinc.com  Fri Jun  9 13:09:58 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 09 Jun 2006 12:09:58 -0700
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <Pine.LNX.4.61.0606082022580.1323@www>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
Message-ID: <4489C786.9050504@dupreeinc.com>


Ideally, it would be nice if it would throw an exception and terminate 
the loop.  I am still trying to figure out how to detect the condition 
and recover form it in some form...  I am getting the "No error in 
readByte" exception in my serialEvent() method after an input stream 
read.  It appears to me that the only graceful recovery is to close the 
port and then reopen it when it becomes available.  I can pass the event 
up to the update method in my main frame, but I still can't close the 
port from within that thread.  Any suggestions on how to pass this event 
to a location where the port can be safely closed?

Re: Slow startup in windows XP
I have been looking into this a little closer and have found out the 
following:
System Windows XP Pro 3GHz dual core with 1GB RAM and NO parallel port.
Starting the SerialDemo included with the commapi using the rxtx instead 
of javax.comm takes 60 seconds.
Starting the SerialDemo using rxrx with the rxtxParallel.dll file 
removed takes about 20 seconds.
Modify initialize in RXRXCommDriver.java to not test the parallel ports 
takes less than 1 second.

It would be nice if the initialize routine could detect the presence of 
rxtxParallel.dll file and just skip the whole process if not present.  
Is there an easy way to check for the presence of this file without 
running the parallel port test?

Doug


 

Trent Jarvi wrote:

>On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:
>...
>  
>
>
>Hi Doug
>
>Sadly I don't have a quick solution for you.
>
>Termios has no knowlage about the JVM so it wont be throwing exceptions 
>you can catch.
>
>We can return error and set the error number to something reasonable that 
>results in an exception.  The No Error message simply means we did not set 
>an error number in termios.c.  Those are the line numbers in the code you 
>see.  SerialImp.c realizes it errored but does not know much more yet. 
>Everything touching the file descriptor is going to error after the port 
>is gone presumably.
>
>We don't currently have a plan in place for vanishing (or appearing) com 
>ports.
>
>Another example of what we need to think about is what happens if you 
>start your application and then plug in the dongle?  Or what if you unplug 
>and then plug it in again?
>
>So in each of these three cases, what would the behavior of the (yet to 
>be) correct implementation do?
>
>How will the enumerated ports be handled during these changes?
>
>There can also be hints from the OS that could be taken into 
>consideration.
>
>We can probably get some exceptions thrown that make sense and null the 
>file descriptor when it happens to prevent io attempts.  That would be a 
>crude way to let applications know something strange has happened.
>
>Is anyone else tinkering with this problem?
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060609/911ed787/attachment-0014.html

From Ugo.Landini at Sun.COM  Fri Jun  2 14:23:47 2006
From: Ugo.Landini at Sun.COM (Ugo Landini)
Date: Fri, 02 Jun 2006 22:23:47 +0200
Subject: [Rxtx] OSX 10.4.7 and usb
Message-ID: <44809E53.2070905@sun.com>

Hi, I have installed the library and the native libraries on OSX 10.4.7. 
Then I have run this simple code:

...
while (portList.hasMoreElements()) {
             portId = (CommPortIdentifier) portList.nextElement();
             System.out.println("-> " + portId.getName() + " Port Type:" 
+ portId.getPortType());
...

and the output is:

Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7

Ports found:
-> /dev/tty.Bluetooth-PDA-Sync Port Type:1
-> /dev/cu.Bluetooth-PDA-Sync Port Type:1
-> /dev/tty.Bluetooth-Modem Port Type:1
-> /dev/cu.Bluetooth-Modem Port Type:1

I can't see any USB ports... with javax.comm on linux I could see the 
/dev/ttyUSB stuff, but that's not the case with OSX. Any idea?

tia

uL


From tod at todbot.com  Sun Jun 11 12:04:37 2006
From: tod at todbot.com (Tod E. Kurt)
Date: Sun, 11 Jun 2006 11:04:37 -0700
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <44809E53.2070905@sun.com>
References: <44809E53.2070905@sun.com>
Message-ID: <E2EB14A1-20A7-4611-8F1A-E3D2ABE41F48@todbot.com>

A dumb question, but: do you have the USB serial adapters plugged  
in?  They only show up in /dev when plugged in.  Also, you can verify  
they exist independent of RXTX by doing something like "ls -l /dev/ 
cu.*".

On Jun 2, 2006, at 1:23 PM, Ugo Landini wrote:

> Hi, I have installed the library and the native libraries on OSX  
> 10.4.7.
> Then I have run this simple code:
>
> ...
> while (portList.hasMoreElements()) {
>              portId = (CommPortIdentifier) portList.nextElement();
>              System.out.println("-> " + portId.getName() + " Port  
> Type:"
> + portId.getPortType());
> ...
>
> and the output is:
>
> Experimental:  JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
>
> Ports found:
> -> /dev/tty.Bluetooth-PDA-Sync Port Type:1
> -> /dev/cu.Bluetooth-PDA-Sync Port Type:1
> -> /dev/tty.Bluetooth-Modem Port Type:1
> -> /dev/cu.Bluetooth-Modem Port Type:1
>
> I can't see any USB ports... with javax.comm on linux I could see the
> /dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>
> tia
>
> uL
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>



From lyon at docjava.com  Sun Jun 11 12:14:50 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Sun, 11 Jun 2006 14:14:50 -0400
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <44809E53.2070905@sun.com>
References: <44809E53.2070905@sun.com>
Message-ID: <p06020444c0b20de7d248@[192.168.1.152]>

>Hi Ugo,

Do you have any USB serial ports (like the keyspan 19-HS) plugged
into the mac?
Thanks!
  - DL


>Hi, I have installed the library and the native libraries on OSX 10.4.7.
>Then I have run this simple code:
>
>...
>while (portList.hasMoreElements()) {
>              portId = (CommPortIdentifier) portList.nextElement();
>              System.out.println("-> " + portId.getName() + " Port Type:"
>+ portId.getPortType());
>...
>
>and the output is:
>
>Experimental:  JNI_OnLoad called.
>Stable Library
>=========================================
>Native lib Version = RXTX-2.1-7
>Java lib Version   = RXTX-2.1-7
>
>Ports found:
>-> /dev/tty.Bluetooth-PDA-Sync Port Type:1
>-> /dev/cu.Bluetooth-PDA-Sync Port Type:1
>-> /dev/tty.Bluetooth-Modem Port Type:1
>-> /dev/cu.Bluetooth-Modem Port Type:1
>
>I can't see any USB ports... with javax.comm on linux I could see the
>/dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>
>tia
>
>uL
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx



From dmarkman at mac.com  Sun Jun 11 14:30:27 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Sun, 11 Jun 2006 16:30:27 -0400
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <p06020444c0b20de7d248@[192.168.1.152]>
References: <44809E53.2070905@sun.com> <p06020444c0b20de7d248@[192.168.1.152]>
Message-ID: <B9C1606B-4339-4564-A175-FE83DFFA7D76@mac.com>

afaik
10.4.7 wasn't released yet
it will soon, no doubts


On Jun 11, 2006, at 2:14 PM, Dr. Douglas Lyon wrote:

>> Hi Ugo,
>
> Do you have any USB serial ports (like the keyspan 19-HS) plugged
> into the mac?
> Thanks!
>   - DL
>
>
>> Hi, I have installed the library and the native libraries on OSX  
>> 10.4.7.
>> Then I have run this simple code:
>>
>> ...
>> while (portList.hasMoreElements()) {
>>              portId = (CommPortIdentifier) portList.nextElement();
>>              System.out.println("-> " + portId.getName() + " Port  
>> Type:"
>> + portId.getPortType());
>> ...
>>
>> and the output is:
>>
>> Experimental:  JNI_OnLoad called.
>> Stable Library
>> =========================================
>> Native lib Version = RXTX-2.1-7
>> Java lib Version   = RXTX-2.1-7
>>
>> Ports found:
>> -> /dev/tty.Bluetooth-PDA-Sync Port Type:1
>> -> /dev/cu.Bluetooth-PDA-Sync Port Type:1
>> -> /dev/tty.Bluetooth-Modem Port Type:1
>> -> /dev/cu.Bluetooth-Modem Port Type:1
>>
>> I can't see any USB ports... with javax.comm on linux I could see the
>> /dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>>
>> tia
>>
>> uL
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman



From tjarvi at qbang.org  Sun Jun 11 18:52:59 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 11 Jun 2006 18:52:59 -0600 (MDT)
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <4489C786.9050504@dupreeinc.com>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
	<4489C786.9050504@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606111845430.7274@www>

On Fri, 9 Jun 2006, Doug Thistlethwaite wrote:

>
> Ideally, it would be nice if it would throw an exception and terminate the 
> loop.  I am still trying to figure out how to detect the condition and 
> recover form it in some form...  I am getting the "No error in readByte" 
> exception in my serialEvent() method after an input stream read.  It appears 
> to me that the only graceful recovery is to close the port and then reopen it 
> when it becomes available.  I can pass the event up to the update method in 
> my main frame, but I still can't close the port from within that thread.  Any 
> suggestions on how to pass this event to a location where the port can be 
> safely closed?
>

I've gone through and cleaned up the termios.c layer.  I need to get to a 
windows machine with a USB dongle and see where the ioctl() is being 
called.  Probably the eventLoop.  But all of the ioctls should probably 
result in an IOException during this condition.

I'll probably finish this up Monday night when I can borrow a USB 
dongle.

There is no point in putting the code into CVS yet.  If you are tinkering 
I can mail the patch.  I think we will want to make a couple fixes in 
SerialImp.c to handle errors before it's ready.

--
Trent Jarvi
tjarvi at qbang.org



From bob_tai2001 at yahoo.com  Mon Jun 12 09:42:14 2006
From: bob_tai2001 at yahoo.com (Bob Tai)
Date: Mon, 12 Jun 2006 08:42:14 -0700 (PDT)
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to RXTX
	again
Message-ID: <20060612154214.58219.qmail@web32804.mail.mud.yahoo.com>


thank you Paul, Joachim, Trent and everyone try to
workout the java comm and Rxtx situation.  At least
now I have something that is solid enough to make my
decision.  

thank you,
     Bob

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From Ralph.Buchfelder at gmx.net  Mon Jun 12 15:30:20 2006
From: Ralph.Buchfelder at gmx.net (Ralph Buchfelder)
Date: Mon, 12 Jun 2006 23:30:20 +0200
Subject: [Rxtx] rxtx binaries or porting to XSCALE Windows Mobile 2003 / 2005
Message-ID: <448DDCEC.7090506@gmx.net>

dear group,

i have been carefully reading your homepage, wiki and archives
but there seems to be no detailled information on porting to Windows 
Mobile/CE.

as far as i understood from the 'porting' section you can do porting to 
winCE. but how? do i only need to obtain the sourcecode (which one?) and 
compile this in Microsoft eMbedded Visual C++ for ARM/Xscale?
Any other ways?


unfortunately i must admit that i do have little linux skills but i have 
made my way through gcc and makefiles. right now i need to implement com 
  communication in a J2ME application and found your website as >the< 
solution.

best regards
Ralph Buchfelder

University of Regensburg
Department of Geography

PS: i dont care about Javacomm compliancy (ie. 2.0 or 2.1) - i just need 
a working serial port API in IBM J9 VM.


From paul.klissner at sun.com  Wed Jun 14 18:12:58 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Wed, 14 Jun 2006 17:12:58 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
Message-ID: <4490A60A.9090305@sun.com>

Hello RxTx community,

I finally think I have a compromise in place that will stand in the gap.

If you go to http://www.sun.com and search for javax.comm, you'll
get taken to a download page, where now users can get a copy of the
comm.jar file out of 2.0.3, along with just a license and a README.

I trust this will suffice until such time as RxTx decided to implement
their own java classes or we can get a JSR going to mitigate some
of the problems (the readme in the comm.jar 2.0.3 zip file
contains my thoughts on that).

Thanks,
Paul



From tjarvi at qbang.org  Wed Jun 14 21:15:35 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 14 Jun 2006 21:15:35 -0600 (MDT)
Subject: [Rxtx] rxtx-2.0-7 (final) src is in CVS
Message-ID: <Pine.LNX.4.61.0606142100500.2742@www>


I wasn't expecting to be working on rxtx 2.0 tonight :)

Thanks go out to Paul Klissner for his work in making the coming release 
of rxtx-2.0-7 possible for users that require package javax.comm on many 
platforms.

Most people know that rxtx 2.0 is for use with Sun's CommAPI 2.0 for 
Solaris or the Generic CommAPI 2.0-3 available for download at Sun.  If 
you need javax.comm packages on many platforms, you are probably 
interested.  If you use rxtx 2.1 in package gnu.io, then you are not going 
to care much.

I've tried to update the rxtx 2.0 src directory in preparation for 
rxtx-2.0-7 (final).  Linux should compile.  Windows will compile if you 
generate your own .def files (I'll generate these tomorrow).  If you have 
some time to do basic testing of the source, I'd appreciate it.  The 
source should be good but you may find classes not found.  This source is 
a backport from rxtx 2.1.

I wanted to get things started so anyone interested on Mac OS X could get 
a head start.

All of this is in CVS.  http://www.rxtx.org/cvs.html

I suspect we will have binaries for testing in a couple days if you are 
unable to compile.   Consider this a smoke test.

--
Trent Jarvi
tjarvi at qbang.org


From legolas.w at gmail.com  Wed Jun 14 22:04:28 2006
From: legolas.w at gmail.com (Legolas Woodland)
Date: Wed, 14 Jun 2006 21:04:28 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <4490A60A.9090305@sun.com>
References: <4490A60A.9090305@sun.com>
Message-ID: <87ee9b170606142104p745fcef0vea622fbc8f528bfc@mail.gmail.com>

is there anything new in this version of javax.comm ?
thanks


On 6/14/06, Paul Klissner <paul.klissner at sun.com> wrote:
>
> Hello RxTx community,
>
> I finally think I have a compromise in place that will stand in the gap.
>
> If you go to http://www.sun.com and search for javax.comm, you'll
> get taken to a download page, where now users can get a copy of the
> comm.jar file out of 2.0.3, along with just a license and a README.
>
> I trust this will suffice until such time as RxTx decided to implement
> their own java classes or we can get a JSR going to mitigate some
> of the problems (the readme in the comm.jar 2.0.3 zip file
> contains my thoughts on that).
>
> Thanks,
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060614/5ff4dfbc/attachment-0014.html

From joachim at buechse.de  Thu Jun 15 07:22:48 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 15 Jun 2006 15:22:48 +0200
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
Message-ID: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>

Good day!

Some of my users report problems using RXTX 2.1.7 on Windows98 to  
communicate with an FTDI FT245BM chip (using their latest VCP  
driver). Either no ports are being shown (ie returned form  
CommPortIdentifier.getPortIdentifiers()) or the transfers fail.

Did anyone run into similar Problems with Win98??

Best regards,
Joachim



From ajmas at sympatico.ca  Thu Jun 15 08:12:28 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Thu, 15 Jun 2006 10:12:28 -0400
Subject: [Rxtx] API change question
Message-ID: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

How closely do you follow the Java Communication API spec? The reason I ask is because I would be interested in augmenting the CommPortIdentifier class to include a getDisplayName() method. By default it would return the same value as getName(), but would provide the possibility of displaying a 'user friendly' name, for platforms where the display name is not the same as the device name. An example of this is on MacOS X, where currently the names seem to be of the form /dev/cu.* and /dev/tty.*, yet what the expects to see is simply the part after the full-stop. Although I could move this logic into the Java code, it would be nice to see it transparent to the Java code.

Andre




From ajmas at sympatico.ca  Thu Jun 15 08:16:22 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Thu, 15 Jun 2006 10:16:22 -0400
Subject: [Rxtx] Package to use
Message-ID: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

While the Java API spec refers to javax.comm, I see that only gnu.io is provide by the rxtx project. Should our projects refer to the gnu.io package or the javax.comm API?

Andre



From joachim at buechse.de  Thu Jun 15 08:45:05 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 15 Jun 2006 16:45:05 +0200
Subject: [Rxtx] API change question
In-Reply-To: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>

Hello Andre,

the /dev/cu and /dev/tty have different semantics on OS X. It is much  
more than a simply naming issue to unify them, see my recent mail to  
the list...

Best regards,
Joachim


On 15.06.2006, at 16:12, Andre-John Mas wrote:

> Hi,
>
> How closely do you follow the Java Communication API spec? The  
> reason I ask is because I would be interested in augmenting the  
> CommPortIdentifier class to include a getDisplayName() method. By  
> default it would return the same value as getName(), but would  
> provide the possibility of displaying a 'user friendly' name, for  
> platforms where the display name is not the same as the device  
> name. An example of this is on MacOS X, where currently the names  
> seem to be of the form /dev/cu.* and /dev/tty.*, yet what the  
> expects to see is simply the part after the full-stop. Although I  
> could move this logic into the Java code, it would be nice to see  
> it transparent to the Java code.
>
> Andre
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From lyon at docjava.com  Thu Jun 15 10:16:29 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Thu, 15 Jun 2006 12:16:29 -0400
Subject: [Rxtx] cu.modem != /dev/ttya on mac.
In-Reply-To: <763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
	<763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>
Message-ID: <p0602046cc0b7378a95b0@[192.168.1.152]>

>Hi All,

I think that Joachim is correct. For the longest time,
I have been trying to figure out how to direct dial using
the cu.modem on the mac under os x.

As a less-than-optimal approach to auto-dialing, I have used
a keyspan USB 19HS adapter, along with an external modem, to
obtain the dialing feature.

Ideally, it would be better to dial with the built-in modem...but that did not
always seem to work, for some reason. Have others had some experience with
using the built in modem for dialing on the mac?

Thanks!
  - Doug


>Hello Andre,
>
>the /dev/cu and /dev/tty have different semantics on OS X. It is much?
>more than a simply naming issue to unify them, see my recent mail to?
>the list...
>
>Best regards,
>Joachim
>



From doug at dupreeinc.com  Thu Jun 15 14:52:50 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 15 Jun 2006 13:52:50 -0700
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
In-Reply-To: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
References: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
Message-ID: <4491C8A2.8090108@dupreeinc.com>

Hi Joachim,

I have been doing a lot with the new FTDI driver with win XP and have 
not had that particular problem.  I did notice that the new driver 
(dated May19th, 2006) is only for XP, Server 2003, and 2000.  Are they 
trying to use the 2.00.00 drivers or the old 1.09.06 version.  I am 
using a FT232R based module, but it uses the same drivers and I assume 
it would have the same problems.  Let me know which driver they are 
using and I can load up a 98 system here and see if  I can duplicate the 
problem.

Doug

Joachim Buechse wrote:

>Good day!
>
>Some of my users report problems using RXTX 2.1.7 on Windows98 to  
>communicate with an FTDI FT245BM chip (using their latest VCP  
>driver). Either no ports are being shown (ie returned form  
>CommPortIdentifier.getPortIdentifiers()) or the transfers fail.
>
>Did anyone run into similar Problems with Win98??
>
>Best regards,
>Joachim
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From matthewhepp at yahoo.com  Thu Jun 15 17:34:47 2006
From: matthewhepp at yahoo.com (Matthew Hepp)
Date: Thu, 15 Jun 2006 16:34:47 -0700 (PDT)
Subject: [Rxtx] Wither the XCode project?
Message-ID: <20060615233447.48064.qmail@web50311.mail.yahoo.com>

Either I don't know how to properly use CVS (entirely possibl), or the XCode
project is not making through the update properly. Doing a "cvs update" against
2.1-7 creates an XCode folder in MACOSX_IDE, and therein a
LibSerialUniversal.xcodeproj, but trying to open it yields a "Unable to Open
Project - Project rxtx-devel/MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj
cannot be opened because it is missing its project.pbxproj file" error. Showing
package contents reveals just the cvs-related files. Perhaps this is why
previous xcode projects have been saved as an sit.hqx - to retain the resource
fork?

Can someone point me in the right direction?

Thanks,

Matt

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Thu Jun 15 19:53:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 19:53:06 -0600 (MDT)
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
In-Reply-To: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
References: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
Message-ID: <Pine.LNX.4.61.0606151944070.23137@www>

On Thu, 15 Jun 2006, Joachim Buechse wrote:

> Good day!
>
> Some of my users report problems using RXTX 2.1.7 on Windows98 to
> communicate with an FTDI FT245BM chip (using their latest VCP
> driver). Either no ports are being shown (ie returned form
> CommPortIdentifier.getPortIdentifiers()) or the transfers fail.
>
> Did anyone run into similar Problems with Win98??
>

Hi Joachim

It has been a long time since I've tested win98.  I know rxtx-2.1-7pre16 
did get testing on win98 with ~jdk 1.3 though.  I wonder if jdks are still 
tested on that platform.

With win98 you usually have older boxes.  They can be short on CPU and 
memory.  Enumeration should work but I could picture runtime performance 
issues on win98.

The enumeration problems could result from other copies of your 
application if various states of decay still holding onto the port.  When 
things go wrong, people also like to open other terminal software to see 
whats going on which can interfere.  You can't open a windows port with 
two apps.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Thu Jun 15 20:08:53 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 20:08:53 -0600 (MDT)
Subject: [Rxtx] API change question
In-Reply-To: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606151954270.23137@www>

On Thu, 15 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> How closely do you follow the Java Communication API spec?

I can explain how this worked in the past.  How we do it in the future is 
open for discussion.

In the past we have tried to follow it as close as possible in gnu.io 
(rxtx 2.1).  We have added extensions but try to discourage their use. 
The extensions are clearly marked as such in the source code and javadocs.

rxtx 2.0 was intended to be a strict implementation of part of the spec. 
We let Sun's interfaces decide what methods can be called. There are 
differences not covered by the spec such as default values.  Thats not 
intentional but rather hard to avoid.

--
Trent Jarvi
tjarvi at qbang.org





From tjarvi at qbang.org  Thu Jun 15 21:09:11 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 21:09:11 -0600 (MDT)
Subject: [Rxtx] Package to use
In-Reply-To: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606152026120.23137@www>

On Thu, 15 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> While the Java API spec refers to javax.comm, I see that only gnu.io is 
> provide by the rxtx project. Should our projects refer to the gnu.io 
> package or the javax.comm API?
>

Hi Andre

Lets see if I can give a fair and balanced answer to that.

If you are starting a new project and want to use RXTX, I would recommend 
using gnu.io.  The community support for gnu.io will not be going away 
anytime soon.  You can switch between gnu.io (2.1) and javax.comm (2.0) 
fairly easily.  They are not intended to be incompatible.  You just change 
package names and libs.

You can also consider the combination of rxtx 2.0 with Sun's commapi 
2.0-3.  This is considered a stop-gap measure by Sun for previous users of 
that combination.  Together rxtx 2.0 and Sun CommAPI 2.0 work in namespace 
javax.comm for programmers.

Finally, you can opt to just use Sun's oferrings in CommAPI 3.0 without 
rxtx.  That would be in namespace javax.comm also.  CommAPI 3.0 may be 
of more interest to you if you are looking at POS with Sun computers. 
Rxtx does not currently support the changes in CommAPI 3.0 or have firm 
plans to do so.  That does not mean we wouldn't implement them.  It just 
means nobody has contributed code yet.

You can't combine rxtx with CommAPI 3.0 for technical reasons that wont 
likely be fixed soon.

It's up to you as far as what you use.  We like to provide the freedom so 
you can choose.  Realistically, we will be supporting gnu.io mainly 
because we have some control over that name space and can support it.

Things may happen in the future that enable rxtx to provide more support 
in the javax namespace but that has not happened yet.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun 16 00:33:06 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 08:33:06 +0200
Subject: [Rxtx] Wither the XCode project?
In-Reply-To: <20060615233447.48064.qmail@web50311.mail.yahoo.com>
References: <20060615233447.48064.qmail@web50311.mail.yahoo.com>
Message-ID: <D30D660F-A49B-464E-AE4C-6B4563893682@buechse.de>

Hello Matthew,

could you please send me the contents of your

   rxtx-devel/CVS
   rxtx-devel/MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj/CVS

directories as a zip to my personal email address. This should  
indicate why the file is not checked out. I can see that it exists on  
the correct branch in the repository, so something must have gone  
wrong during the "cvs update"...

Best regards,
Joachim

On 16.06.2006, at 01:34, Matthew Hepp wrote:

> Either I don't know how to properly use CVS (entirely possibl), or  
> the XCode
> project is not making through the update properly. Doing a "cvs  
> update" against
> 2.1-7 creates an XCode folder in MACOSX_IDE, and therein a
> LibSerialUniversal.xcodeproj, but trying to open it yields a  
> "Unable to Open
> Project - Project rxtx-devel/MACOSX_IDE/XCode/ 
> LibSerialUniversal.xcodeproj
> cannot be opened because it is missing its project.pbxproj file"  
> error. Showing
> package contents reveals just the cvs-related files. Perhaps this  
> is why
> previous xcode projects have been saved as an sit.hqx - to retain  
> the resource
> fork?
>
> Can someone point me in the right direction?



From joachim at buechse.de  Fri Jun 16 10:41:20 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 18:41:20 +0200
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <p06230903c0b88613dca6@[10.0.1.7]>
References: <p06230903c0b88613dca6@[10.0.1.7]>
Message-ID: <03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>

Hello Bob,

until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was  
behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if  
Trent has migrated all recent changes from 2.1 to 2.0.

I have added the XCode project and updated documentation only to the  
gnu.io branch. Once the 2.0 implementation is up to date I will copy  
over the documentation/build files make them work.

Best regards,
Joachim

On 16.06.2006, at 18:07, Bob Jacobsen wrote:

> I'm one of the developers for the JMRI project, which provides  
> model railroad software in Java.  We've been using RXTX to provide  
> serial port access on MacOS X and Linux; we use the old javax.comm  
> 2.0 on Windows, OS/2 and Solaris.  Because of that, we need to stay  
> with RXTX 2.0, not 2.1
>
> We've been using the 2.0-pre17 installer for a long time, but it's  
> not compatible with Intel macs.
>
> Can you point me to where I can find the right files for RXTX 2.0  
> to package with the program?
>
> The current situation is confusing to me.  I've been pointed to  
> recent 2.1 versions (but we need the javax.comm names), to an even  
> older installer, etc.  I've been reading that some versions require  
> an installer, and others don't, but I haven't been able to figure  
> out which (if any) of those are where in CVS.
>
> I'd really appreciate a clear statement of what files to use and  
> what to do with them that I can pass on to our users.
>
> I'm more than happy to put files in the local classpath, have users  
> run an installer, or anything else.  Whatever is easiest for you.
>
> Thanks!  I really appreciate all that you do to keep RXTX working.
>
> Bob
> -- 
> Bob Jacobsen +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG



From joachim at buechse.de  Fri Jun 16 09:59:28 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 17:59:28 +0200
Subject: [Rxtx] Wither the XCode project?
In-Reply-To: <20060616150240.49464.qmail@web50309.mail.yahoo.com>
References: <20060616150240.49464.qmail@web50309.mail.yahoo.com>
Message-ID: <D9935E05-2B83-488D-86DD-42599E229052@buechse.de>

Hello Matthew,

you have checked out the trunk (which is the 2.0.7 javax.comm.xxx  
release). For rxtx-2.1.7 (gnu.io.xxx release) you need to check out  
the branch

      commapi-0-0-1

The easiest way to do this is to download the rxtx src archive,  
unpack it and then do a cvs up inside the decompressed tree.  
Optionally you could do a

      cvs co -r commapi-0-0-1

but this will take much longer!

Best regards,
Joachim

When you do a cvs status it will show the sticky tag.

41:~/jdevelop/rxtx-2.1-7r2 joachim$ cvs status README.OSX
===================================================================
File: README.OSX        Status: Up-to-date

    Working revision:    1.1.2.1
    Repository revision: 1.1.2.1 /usr/local/cvsroot/rxtx-devel/Attic/ 
README.OSX,v
    Sticky Tag:          commapi-0-0-1 (branch: 1.1.2)
    Sticky Date:         (none)
    Sticky Options:      (none)




On 16.06.2006, at 17:02, Matthew Hepp wrote:

> %cvs status README.MACOSX
> ===================================================================
> File: README.MACOSX     Status: Up-to-date
>
>    Working revision:    1.1
>    Repository revision: 1.1     /usr/local/cvsroot/rxtx-devel/ 
> README.MACOSX,v
>    Sticky Tag:          (none)
>    Sticky Date:         (none)
>    Sticky Options:      (none)



From tjarvi at qbang.org  Fri Jun 16 16:31:18 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Fri, 16 Jun 2006 16:31:18 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
Message-ID: <Pine.LNX.4.61.0606161630030.14139@www>

On Fri, 16 Jun 2006, Joachim Buechse wrote:

> Hello Bob,
>
> until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was
> behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if
> Trent has migrated all recent changes from 2.1 to 2.0.
>

The src/ directory and configure.in/configure files should be fine.  I 
have not touched the Mac OS X directories.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sat Jun 17 02:39:55 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sat, 17 Jun 2006 10:39:55 +0200
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <Pine.LNX.4.61.0606161630030.14139@www>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
Message-ID: <350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>

Hello Trent,

apparently the IOEXCL changes have not made it into 2.0. I will add  
them to achieve a minimal diff between 2.0 and 2.1.

One other thing that bugs me for a while...

Shouldn't we replace "if !defined(TIOCSERGETLSR) && !defined(WIN32)"  
by a definition of its own "if defined(DRAINTHREAD)"? I think this  
would make the code clearer for people starting to read it.

Regards,
Joachim


On 17.06.2006, at 00:31, Trent Jarvi wrote:

> On Fri, 16 Jun 2006, Joachim Buechse wrote:
>
>> Hello Bob,
>>
>> until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was
>> behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if
>> Trent has migrated all recent changes from 2.1 to 2.0.
>>
>
> The src/ directory and configure.in/configure files should be fine.  I
> have not touched the Mac OS X directories.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From tropicsu at hotmail.com  Sat Jun 17 09:32:48 2006
From: tropicsu at hotmail.com (Yoke K)
Date: Sat, 17 Jun 2006 15:32:48 +0000
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
Message-ID: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>

Hi,

I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to work with 
MAC OS X.
I am using iTegno 3000 - USB GPRS Modem.

Files in /dev and a symbolic link as follows:

crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 -> tty.usbserial

In my SendMessage.java, I have this line:
CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");

Appreciate any help ?

- Jon


Errors as follows:

>>INFO: SMSLib API for Java / v1.2.2
>>INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>INFO: JRE Version: 1.5.0_06
>>INFO: JRE Impl Version: 1.5.0_06-64
>>INFO: O/S: Mac OS X / ppc / 10.4.6
>>INFO: Using Wavecom (Generic) AT handler.

SendMessage(): Send a message.
  Using SMSLib API for Java v1.2.2

Connecting ..... :
>>INFO: CSerialDriver(): Connecting...
Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
>>INFO: CSerialDriver(): Disconnecting...
gnu.io.NoSuchPortException
        at 
gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:218)
        at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
        at org.smslib.CService.connect(CService.java:197)
        at SendMessage.main(SendMessage.java:38)

_________________________________________________________________
Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/



From tjarvi at qbang.org  Sat Jun 17 10:12:30 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 10:12:30 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
	<350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
Message-ID: <Pine.LNX.4.61.0606171010060.14139@www>

On Sat, 17 Jun 2006, Joachim Buechse wrote:

> Hello Trent,
>
> apparently the IOEXCL changes have not made it into 2.0. I will add
> them to achieve a minimal diff between 2.0 and 2.1.
>

Hi Joachim

As I recall the IOEXCL change was after 2.1-7.  I was just syncing with 
2.1-7.  We can release 2.1-8 and 2.0-8 with the same changes.

> One other thing that bugs me for a while...
>
> Shouldn't we replace "if !defined(TIOCSERGETLSR) && !defined(WIN32)"
> by a definition of its own "if defined(DRAINTHREAD)"? I think this
> would make the code clearer for people starting to read it.
>


Sure.  We can do that for -8.  The TIOCSERGETLSR code should be a special 
case not the expected.  I think only Linux uses it.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Sat Jun 17 10:48:21 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 10:48:21 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <Pine.LNX.4.61.0606171010060.14139@www>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
	<350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
	<Pine.LNX.4.61.0606171010060.14139@www>
Message-ID: <Pine.LNX.4.61.0606171047310.14139@www>

On Sat, 17 Jun 2006, Trent Jarvi wrote:

> On Sat, 17 Jun 2006, Joachim Buechse wrote:
>
>> Hello Trent,
>>
>> apparently the IOEXCL changes have not made it into 2.0. I will add
>> them to achieve a minimal diff between 2.0 and 2.1.
>>
>
> Hi Joachim
>
> As I recall the IOEXCL change was after 2.1-7.  I was just syncing with
> 2.1-7.  We can release 2.1-8 and 2.0-8 with the same changes.
>

We could just move to 2.1-8 and 2.0-8.

--
Trent Jarvi
tjarvi at qbang.org


From brian.t.lamb at gmail.com  Tue Jun 13 13:54:13 2006
From: brian.t.lamb at gmail.com (Brian Lamb)
Date: Tue, 13 Jun 2006 15:54:13 -0400
Subject: [Rxtx] Windows XP Installation
Message-ID: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>

I've not installed Java packages on Windows before and am unsure how to
proceed. All the documentation I've seen provides detailed instructions on
how to install on Linux or Solaris. I was wondering how to install rxtx on
Windows XP.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060613/6f68cd5c/attachment-0014.html

From tjarvi at qbang.org  Sat Jun 17 13:57:03 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 13:57:03 -0600 (MDT)
Subject: [Rxtx] Windows XP Installation
In-Reply-To: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>
References: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0606171356120.14139@www>

On Tue, 13 Jun 2006, Brian Lamb wrote:

> I've not installed Java packages on Windows before and am unsure how to
> proceed. All the documentation I've seen provides detailed instructions on
> how to install on Linux or Solaris. I was wondering how to install rxtx on
> Windows XP.
>

Hi Brian

Which rxtx version are you trying to install?

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sun Jun 18 10:41:44 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sun, 18 Jun 2006 18:41:44 +0200
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
References: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
Message-ID: <8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>

Hello Jon,

 From OSX's standpoint a symbolic link is not a device (as far as I  
know). What stops you from using tty.usbserial? Did you try hard- 
linking?

Regards,
Joachim

On 17.06.2006, at 17:32, Yoke K wrote:
> Hi,
>
> I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to  
> work with
> MAC OS X.
> I am using iTegno 3000 - USB GPRS Modem.
>
> Files in /dev and a symbolic link as follows:
>
> crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
> crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
> lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->  
> tty.usbserial
>
> In my SendMessage.java, I have this line:
> CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
>
> Appreciate any help ?
>
> - Jon
>
>
> Errors as follows:
>
>>> INFO: SMSLib API for Java / v1.2.2
>>> INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>> INFO: JRE Version: 1.5.0_06
>>> INFO: JRE Impl Version: 1.5.0_06-64
>>> INFO: O/S: Mac OS X / ppc / 10.4.6
>>> INFO: Using Wavecom (Generic) AT handler.
>
> SendMessage(): Send a message.
>   Using SMSLib API for Java v1.2.2
>
> Connecting ..... :
>>> INFO: CSerialDriver(): Connecting...
> Experimental:  JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
>>> INFO: CSerialDriver(): Disconnecting...
> gnu.io.NoSuchPortException
>         at
> gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java: 
> 218)
>         at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
>         at org.smslib.CService.connect(CService.java:197)
>         at SendMessage.main(SendMessage.java:38)
>
> _________________________________________________________________
> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Sun Jun 18 10:56:55 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 12:56:55 -0400
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>
References: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
	<8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>
Message-ID: <7B6834E3-F41D-46B6-B979-55466BC73859@sympatico.ca>

Have you been able to get any other software to talk with your
modem? What port is it using? Have tried using the cu.usbserial
instead?

Andre

On 18-Jun-06, at 12:41 , Joachim Buechse wrote:

> Hello Jon,
>
>  From OSX's standpoint a symbolic link is not a device (as far as I
> know). What stops you from using tty.usbserial? Did you try hard-
> linking?
>
> Regards,
> Joachim
>
> On 17.06.2006, at 17:32, Yoke K wrote:
>> Hi,
>>
>> I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to
>> work with
>> MAC OS X.
>> I am using iTegno 3000 - USB GPRS Modem.
>>
>> Files in /dev and a symbolic link as follows:
>>
>> crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
>> crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
>> lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->
>> tty.usbserial
>>
>> In my SendMessage.java, I have this line:
>> CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
>>
>> Appreciate any help ?
>>
>> - Jon
>>
>>
>> Errors as follows:
>>
>>>> INFO: SMSLib API for Java / v1.2.2
>>>> INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>>> INFO: JRE Version: 1.5.0_06
>>>> INFO: JRE Impl Version: 1.5.0_06-64
>>>> INFO: O/S: Mac OS X / ppc / 10.4.6
>>>> INFO: Using Wavecom (Generic) AT handler.
>>
>> SendMessage(): Send a message.
>>   Using SMSLib API for Java v1.2.2
>>
>> Connecting ..... :
>>>> INFO: CSerialDriver(): Connecting...
>> Experimental:  JNI_OnLoad called.
>> Stable Library
>> =========================================
>> Native lib Version = RXTX-2.1-7
>> Java lib Version   = RXTX-2.1-7
>>>> INFO: CSerialDriver(): Disconnecting...
>> gnu.io.NoSuchPortException
>>         at
>> gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:
>> 218)
>>         at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
>>         at org.smslib.CService.connect(CService.java:197)
>>         at SendMessage.main(SendMessage.java:38)
>>
>> _________________________________________________________________
>> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Sun Jun 18 17:33:08 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 19:33:08 -0400
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
Message-ID: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>

Hi,

I am have a program that I wrote in Java to communicate with a  
Bluetooth GPS device. I am
trying to get this working on my Mac, but I keep getting told that:

gnu.io.PortInUseException: Unknown Application

but

portIdentifier.isCurrentlyOwned()

returns false and when I do lsof on the device I am trying to connect  
to, I see no application
using it. As the same time if I go to the command line and use  
minicom I have no issues. The
exception happens with this call:

CommPort commPort = portIdentifier.open(null,0);

Any suggestions?

Andre


From ajmas at sympatico.ca  Sun Jun 18 17:45:11 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 19:45:11 -0400
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
Message-ID: <30245B30-682D-4EAE-8084-8227B719F10D@sympatico.ca>

BTW My code snippet is:

     private InputStream connectToSerial () throws IOException,  
Exception
     {
         InputStream in = null;

         Enumeration portEnum = CommPortIdentifier.getPortIdentifiers();
         while ( portEnum.hasMoreElements() )
         {
             CommPortIdentifier portIdentifier = (CommPortIdentifier)  
portEnum.nextElement();
             System.out.println(portIdentifier.getName() + " - " +  
portIdentifier.getPortType() );
         }

         CommPortIdentifier portIdentifier =  
CommPortIdentifier.getPortIdentifier("/dev/cu.BTGPS-SPPslave-1");
         System.out.println("current owner: " +  
portIdentifier.getCurrentOwner());
         if ( portIdentifier.isCurrentlyOwned() )
         {
             System.out.println("Error: Port is currently in use");
             return null;
         }
         else
         {
             CommPort commPort = portIdentifier.open(this.getClass 
().getName(),2000);

             if ( commPort instanceof SerialPort )
             {
                 SerialPort serialPort = (SerialPort) commPort;
                 serialPort.setSerialPortParams 
(4800,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE 
);
                 in = serialPort.getInputStream();

                 return in;
             }
             else
             {
                 System.out.println("Error: Only serial ports are  
handled.");
             }
         }


         return in;
     }


On 18-Jun-06, at 19:33 , Andr?-John Mas wrote:

> Hi,
>
> I am have a program that I wrote in Java to communicate with a
> Bluetooth GPS device. I am
> trying to get this working on my Mac, but I keep getting told that:
>
> gnu.io.PortInUseException: Unknown Application
>
> but
>
> portIdentifier.isCurrentlyOwned()
>
> returns false and when I do lsof on the device I am trying to connect
> to, I see no application
> using it. As the same time if I go to the command line and use
> minicom I have no issues. The
> exception happens with this call:
>
> CommPort commPort = portIdentifier.open(null,0);
>
> Any suggestions?
>
> Andre
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From joachim at buechse.de  Mon Jun 19 05:54:49 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 13:54:49 +0200
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de>

This is most likely due to a problem with lock files. If you have  
downloaded the binaries of 2.17 rxtx will try to create non-standard  
lock files on OSX. We have since changed the code to use OSX device  
locking - however the binaries have not been updated yet. The 2.18  
release fixing this issue is due shortly.

Regards,
Joachim

On 19.06.2006, at 01:33, Andr?-John Mas wrote:

> Hi,
>
> I am have a program that I wrote in Java to communicate with a
> Bluetooth GPS device. I am
> trying to get this working on my Mac, but I keep getting told that:
>
> gnu.io.PortInUseException: Unknown Application
>
> but
>
> portIdentifier.isCurrentlyOwned()
>
> returns false and when I do lsof on the device I am trying to connect
> to, I see no application
> using it. As the same time if I go to the command line and use
> minicom I have no issues. The
> exception happens with this call:
>
> CommPort commPort = portIdentifier.open(null,0);
>
> Any suggestions?
>
> Andre
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From joachim at buechse.de  Mon Jun 19 06:44:27 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 14:44:27 +0200
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <4490A60A.9090305@sun.com>
References: <4490A60A.9090305@sun.com>
Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>

Hello Paul,

I just downloaded the "generic" javax.comm version now available. A  
first check indicates, that it was compiled with a JDK 1.4 javac  
without setting the target classfile version. In other words in can  
not be loaded by 1.1-1.3 VMs (or PersonalJava).

Do you see any chance to provide a version compiled with classfile  
format 45.3 (ie JVM1.1).

---
52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose  
javax.comm.SerialPort | head -5
Compiled from "SerialPort.java"
public abstract class javax.comm.SerialPort extends javax.comm.CommPort
   SourceFile: "SerialPort.java"
   minor version: 0
   major version: 48
---

Best regards,
Joachim


On 15.06.2006, at 02:12, Paul Klissner wrote:

> Hello RxTx community,
>
> I finally think I have a compromise in place that will stand in the  
> gap.
>
> If you go to http://www.sun.com and search for javax.comm, you'll
> get taken to a download page, where now users can get a copy of the
> comm.jar file out of 2.0.3, along with just a license and a README.
>
> I trust this will suffice until such time as RxTx decided to implement
> their own java classes or we can get a JSR going to mitigate some
> of the problems (the readme in the comm.jar 2.0.3 zip file
> contains my thoughts on that).
>
> Thanks,
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Mon Jun 19 09:11:45 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Mon, 19 Jun 2006 11:11:45 -0400
Subject: [Rxtx] Examples added to Wiki
Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

I have added a couple of examples to the Wiki:

http://rxtx.qbang.org/wiki/index.php/Examples

If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :)

Andre



From paul.klissner at sun.com  Mon Jun 19 10:42:47 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Mon, 19 Jun 2006 09:42:47 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>
References: <4490A60A.9090305@sun.com>
	<03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>
Message-ID: <4496D407.1090609@sun.com>

Joachim Buechse wrote:
> Hello Paul,
> 
> I just downloaded the "generic" javax.comm version now available. A  
> first check indicates, that it was compiled with a JDK 1.4 javac  
> without setting the target classfile version. In other words in can  
> not be loaded by 1.1-1.3 VMs (or PersonalJava).
> 
> Do you see any chance to provide a version compiled with classfile  
> format 45.3 (ie JVM1.1).
> 
> ---
> 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose  
> javax.comm.SerialPort | head -5
> Compiled from "SerialPort.java"
> public abstract class javax.comm.SerialPort extends javax.comm.CommPort
>    SourceFile: "SerialPort.java"
>    minor version: 0
>    major version: 48
> ---

I cannot promise when I can do that. Since we thought we were done
with javax.comm, the build environment got moved around, and right
now it doesn't even compile in it's new home.  I tried and it was
not cooperative at all. I was never impressed with that workspace
(in fact far far from it, it is a mess, which is why I migrated 3.0
to ant and never looked back).  It will take some real determination
for me to rebuild it, and frankly, right now I'm swamped.  If I can
find a bit of time over the next few weeks to do it, and it isn't
too bad an ordeal, I will.

Posting that will give me an excuse to post javax.comm 3.0, Update 2 as
well, while I'm working with the people who put content up on our
download center.  The only reason for a new update to 3.0 is that
I've changed the distribution to provide ispt (Interactive Serial
Port Tool), such that it can be launched as soon as the zip file
is unpacked, via a provided script.  ISPT is a command line
interactive tool for  manipulating one or two serial port,
sending data, managing events, etc... I've found it to be so useful
for doing certain kinds of validation  that I assume others will
find it useful to.  ISPT is already in 3.0u1, but one has to set
up their own classpath and launch it and since few people ever read
the documentation most won't know about it.  I've added the ability
to set stop bits and parity since 3.0u1 too.  But I digress.

Paul


From joachim at buechse.de  Mon Jun 19 11:01:28 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 19:01:28 +0200
Subject: [Rxtx] load mechanism of 2.0x
Message-ID: <CFD1440C-21AA-4D3B-9EA6-270D0FF9D6FC@buechse.de>

Good day,

I am trying to figure out, how the 2.0x distribution interacts with  
Suns implementation of javax.comm.CommPortIdentifier.

1) Apparently one can put javax.comm.properties in {java.home}/lib
2) The javax.comm package also reacts to -Djavax.comm.properties="...."

Looking at the javap output it also seems like CommPortIdentifier  
tries to find it's jar file and load the properties from there??


What I'm really looking for is a solution that allows using  
javax.comm with RXTX without modifying the VM installation. So I  
would prefer not to use 1) but I can't figure out how to use 2).

Any hints are welcome,
Joachim



From bob_tai2001 at yahoo.com  Mon Jun 19 15:00:35 2006
From: bob_tai2001 at yahoo.com (Bob Tai)
Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT)
Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place
	to start?
Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>

Hi, 

I got  rxtx Windows 2000 installed.  I did not use the
"best" way ... I just follow the insturuction and dump
the necessary files into the jre... I know it's "best"
idea, I got lazy didn't want to change my setting to
my Eclipse and classpath.

I was able to modify SimpleWrite.java to print on my
AddMaster serial printer.  I think I am ready to code!
But I need to make sure I can handle exceptions and so
on.  I notice the \samples\NullDriver\  has two files
seems to have some of the require method done, should
I start coding from those file?  I like the idea it
has the "time out" and basic exceptions done.   I am
slowly digging into the samples, but if you think any
of the code from Sun is good to checkout please let me
know.

btw, http://rxtx.qbang.org/wiki/index.php/Examples/
was very helpful, wish there are more examples.

thank you,

    Bob


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Mon Jun 19 15:55:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT)
Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good
 place to start?
In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>
References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606191542260.14139@www>

> I am
> slowly digging into the samples, but if you think any
> of the code from Sun is good to checkout please let me
> know.
>

I think NullDriver.java was an example stub driver for implementing 
something like rxtx.  It has been a while.  Unless they have been updated, 
you will find the examples are very dated.  You can look at how they use 
the port but avoid the GUI and hard coded variables (number of ports for 
instance).

There was no Swing and nobody knew what requirements today's compilers 
would make on code.  The examples worked fine with jdk 1.1 but times have 
changed.

--
Trent Jarvi
tjarvi at qbang.org


From tropicsu at hotmail.com  Mon Jun 19 19:49:08 2006
From: tropicsu at hotmail.com (Yoke K)
Date: Tue, 20 Jun 2006 01:49:08 +0000
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
Message-ID: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>

An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/fa588f00/attachment-0005.html

From ajmas at sympatico.ca  Mon Jun 19 21:14:37 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Mon, 19 Jun 2006 23:14:37 -0400
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>
References: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>
Message-ID: <CA22AB2A-5712-458B-9984-68477C6042AF@sympatico.ca>

Regarding the PortInUseException, I had a similar issue and got
this response from the mailing list:

   http://mailman.qbang.org/pipermail/rxtx/Week-of- 
Mon-20060619/062838.html

Andre
On 19-Jun-06, at 21:49 , Yoke K wrote:

> Hi Andre, Joachim
>
> I have tried using /dev/tty.usbserial and also /dev/cu.usbserial  
> and it also reported error as  "gnu.io.PortInUseException".
>
> The iTegno modem works in windows environment. As I moving around  
> using my ibook and I need to get it work on MAC OS as well.
>
> >> INFO: SMSLib API for Java / v1.2.2
> >> INFO: Using port: /dev/tty.usbserial @ 115200 baud.
> >> INFO: JRE Version: 1.5.0_06
> >> INFO: JRE Impl Version: 1.5.0_06-64
> >> INFO: O/S: Mac OS X / ppc / 10.4.6
> >> INFO: Using Wavecom (Generic) AT handler.
>
> SendMessage(): Send a message.
> Using SMSLib API for Java v1.2.2
>
> Connecting ..... :
> >> INFO: CSerialDriver(): Connecting...
> Experimental: JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version = RXTX-2.1-7
> >> INFO: CSerialDriver(): Disconnecting...
> gnu.io.PortInUseException: Unknown Application
> at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354)
> at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1)
> at org.smslib.CService.connect(CService.java:197)
> at SendMessage.main(SendMessage.java:38)
>
> Thanks.
>
> - Jon
>
>
>
>
> ====================
>
> Hello Jon,
>
> From OSX's standpoint a symbolic link is not a device (as far as I
> know). What stops you from using tty.usbserial? Did you try hard-
> linking?
>
> Regards,
> Joachim
>
>
>
> From:  "Yoke K" <tropicsu at hotmail.com>
> To:  rxtx at qbang.org
> Subject:  RXTX-2.1-7 / MAC OS X / NoSuchPortException
> Date:  Sat, 17 Jun 2006 15:32:48 +0000
> >Hi,
> >
> >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to
> >work with MAC OS X.
> >I am using iTegno 3000 - USB GPRS Modem.
> >
> >Files in /dev and a symbolic link as follows:
> >
> >crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
> >crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
> >lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->
> >tty.usbserial
> >
> >In my SendMessage.java, I have this line:
> >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
> >
> >Appreciate any help ?
> >
> >- Jon
> >
> >
> >Errors as follows:
> >
> >>>INFO: SMSLib API for Java / v1.2.2
> >>>INFO: Using port: /dev/ttyS1 @ 56000 baud.
> >>>INFO: JRE Version: 1.5.0_06
> >>>INFO: JRE Impl Version: 1.5.0_06-64
> >>>INFO: O/S: Mac OS X / ppc / 10.4.6
> >>>INFO: Using Wavecom (Generic) AT handler.
> >
> >SendMessage(): Send a message.
> >  Using SMSLib API for Java v1.2.2
> >
> >Connecting ..... :
> >>>INFO: CSerialDriver(): Connecting...
> >Experimental:  JNI_OnLoad called.
> >Stable Library
> >=========================================
> >Native lib Version = RXTX-2.1-7
> >Java lib Version   = RXTX-2.1-7
> >>>INFO: CSerialDriver(): Disconnecting...
> >gnu.io.NoSuchPortException
> >        at
> >gnu.io.CommPortIdentifier.getPortIdentifier 
> (CommPortIdentifier.java:218)
> >        at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
> >        at org.smslib.CService.connect(CService.java:197)
> >        at SendMessage.main(SendMessage.java:38)
> >
> >_________________________________________________________________
> >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
> >
>
> Find love online with MSN Personals
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Tue Jun 20 02:35:24 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 10:35:24 +0200
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>

Hello everybody,

I have been fighting a bit with the javax.comm version of RXTX the  
last days. I am working on the README .OSX now and try to figure out  
which should be the "suggested" installation.

The facts:
------

- the "generic" comm.jar version of javax.comm which has been made re- 
available tries to load com.sun.comm.SolarisDriver
- this classname can be overridden ONLY by putting a file  
javax.comm.properties in {java.home}/lib
- if it is not overridden and SolarisDriver.class is not found  
CommPortIdentifier will be disfunctional (in particual it is not  
possible to add CommPort's via CommPortIdentifier.add).
- the license distributed with comm.jar does not allow the  
modification/addition of classes in javax.comm (however no mention of  
com.sun...)


What really bothers me is to suggest putting this config file in the  
"global" vm installation. This is particularly ugly on the Mac as  
there are several VM installations and the file may be forgotten.  
Additionally it may create versioning problems. I prefer an  
installation where all files are local to the application (even  
comm.jar).

In my opinion the ideal situation would be:
------

1) The author of a program compiles against javax.comm.
2a) For platforms supported by Sun the user is free to use the 3.0  
comm.jar download from Sun
2b) For platforms not supported by Sun the user adds RXTXComm.jar to  
the classpath of the application (and librxtxSerial.jnilib to the  
application directory). Also he will need the 2.0.3 generic comm.jar  
from Sun.
3) Nobody messes with the global VM installation.

Of course 2a) and 2b) could be handled by the author of the program  
via an appropriate installer. The author could also decide to always  
use RXTX and include the generic javax.comm classes as well as the  
RXTX classes in his application jar. [If he further uses an explicit  
call to System.load() he may even include the jnilib(s) in the jar,  
extract it (based on the platform name) at runtime to a temp file and  
load it from there.]


Suggested solution:
------

We only need to put the following class in the classpath BEFORE Suns  
comm.jar

   package com.sun.comm;
   public class SolarisDriver extends gnu.io.RXTXCommDriver {
   }

This is not "the pure art" (TM). It depends on an implementation  
detail of the generic driver. However, so does the  
javax.comm.properties file - as we have seen when Sun released 3.0.  
It has the following advantages:

- The "generic" javax.comm implementation will happily load this  
class as its primary driver.
- No javax.comm.properties file is required.
- This does not violate the javax.comm license agreement as there is  
no mention of the "com.sun.comm" package in this license agreement at  
all.
- Authors packaging comm.jar with their application can strip out all  
com.sun.comm classes from comm.jar


Please comment!

Joachim



From joachim at buechse.de  Tue Jun 20 02:50:36 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 10:50:36 +0200
Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar
Message-ID: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>

There has been some discussions about the best way to install RXTX  
and where to place files.

I suggest that,

- we include the native libraries for the most common operating  
systems (in a special version of) RXTXcomm.jar
- we add loader code which tries to extract and load the platform  
specific binary at runtime
- on failure the current mechanism remains as a fallback

Wether the current mechanism should have priority (ie loadLibrary  
before load) remains to be discussed.


The advantages of this solution are
  - users of RXTX do not need to worry about java/platform specific  
file placement.
  - authors of applications may fully merge RXTX into their  
application jar (which provides a double-clickable application for  
Windows and OSX, Linux?).

Please comment,
Joachim

PS: Of course the suggested solution is already possible today,  
however relatively few programmers know how to correctly extract a  
binary resource file via the class loader and load it as a native  
library.


From tjarvi at qbang.org  Tue Jun 20 03:58:12 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT)
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
Message-ID: <Pine.LNX.4.61.0606200335190.14139@www>

> 2a) For platforms supported by Sun the user is free to use the 3.0
> comm.jar download from Sun
> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to
> the classpath of the application (and librxtxSerial.jnilib to the
> application directory). Also he will need the 2.0.3 generic comm.jar
> from Sun.

As there are no plans to support CommAPI 3.0 due to the limitations in its 
implementation mentioned before, I would not recommend projects use Sun's 
3.0 comm.jar.  They will lose the freedom to chose their low level 
implementation by being locked into vendor specific modifications.

Projects should chose between platform neutrality in CommAPI 2.0 and 
reduced platform neutrality in commapi 3.0.  Projects should also strongly 
consider the fact that the 2.0 comm.jar targets only a reduced number of 
JVMs.

Projects can go with rxtx 2.1 or other packages but should probably only 
consider using Sun CommAPI with rxtx if they did so in the past.  They 
should take steps to no longer depend upon this option being available.

> Suggested solution:
> ------
>
> We only need to put the following class in the classpath BEFORE Suns
> comm.jar
>
>   package com.sun.comm;
>   public class SolarisDriver extends gnu.io.RXTXCommDriver {
>   }
>
> This is not "the pure art" (TM). It depends on an implementation
> detail of the generic driver. However, so does the
> javax.comm.properties file - as we have seen when Sun released 3.0.
> It has the following advantages:
>
> - The "generic" javax.comm implementation will happily load this
> class as its primary driver.
> - No javax.comm.properties file is required.
> - This does not violate the javax.comm license agreement as there is
> no mention of the "com.sun.comm" package in this license agreement at
> all.
> - Authors packaging comm.jar with their application can strip out all
> com.sun.comm classes from comm.jar
>

I would not encourage people to place packages in the com.sun.comm 
namespace.  Authors using Sun's commapi 2.0 should just realize it is 
greatly limited in practical utility and consider moving to something that 
isn't being rescued from EOL.

The primary focus of this release is projects previously depending upon 
Sun CommAPI + RXTX.  There are no plans at this time to provide future 
support in this arrangement due to technical incompatabilities we have no 
control over in commapi 3.0 and limited utility of Sun's generic comm.jar 
in commapi 2.0 offered.  Projects should be aware of this so they can make 
appropriate plans.

--
Trent Jarvi
tjarvi at qbang.org


From paul.klissner at sun.com  Tue Jun 20 05:24:00 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Tue, 20 Jun 2006 04:24:00 -0700
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
In-Reply-To: <Pine.LNX.4.61.0606200335190.14139@www>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
	<Pine.LNX.4.61.0606200335190.14139@www>
Message-ID: <4497DAD0.10803@sun.com>

Trent Jarvi wrote:
>> 2a) For platforms supported by Sun the user is free to use the 3.0
>> comm.jar download from Sun
>> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to
>> the classpath of the application (and librxtxSerial.jnilib to the
>> application directory). Also he will need the 2.0.3 generic comm.jar
>> from Sun.
> 
> As there are no plans to support CommAPI 3.0 due to the limitations in its 
> implementation mentioned before, I would not recommend projects use Sun's 
> 3.0 comm.jar.  They will lose the freedom to chose their low level 
> implementation by being locked into vendor specific modifications.
> 
> Projects should chose between platform neutrality in CommAPI 2.0 and 
> reduced platform neutrality in commapi 3.0.  Projects should also strongly 
> consider the fact that the 2.0 comm.jar targets only a reduced number of 
> JVMs.

Well, that's a little ambiguous because the API is the same
either way.  We're talking about Sun's implementation vs.
other implementations.
> 
> Projects can go with rxtx 2.1 or other packages but should probably only 
> consider using Sun CommAPI with rxtx if they did so in the past.  They 
> should take steps to no longer depend upon this option being available.

3.0 is platform centric because there is a need to add some
platform awareness to Sun's implementation, and the choices
for how to do that are limited by the constraints of the API,
as mentioned in the javax.comm 2.0.3 comm.jar download's README.

I am really advocating getting a JSR open (http://www.jcp.org)
to push a new comm API that is more pluggable, platform neutral
and addresses some of the deficiencies of the current API. Then
we can achieve the optimal of platform neutrality while
simulataneously allowing the API to flexibly adapt to
heterogeneous environments.

This is not a question of attitude, this is an issue of resources,
time and commitment.  The current owners of javax.comm within
Sun would like nothing better than to see the ideal reached for
the API and a model that will extend well beyond the foreseeable
future and work for the industry overall.



> 
>> Suggested solution:
>> ------
>>
>> We only need to put the following class in the classpath BEFORE Suns
>> comm.jar
>>
>>   package com.sun.comm;
>>   public class SolarisDriver extends gnu.io.RXTXCommDriver {
>>   }
>>
>> This is not "the pure art" (TM). It depends on an implementation
>> detail of the generic driver. However, so does the
>> javax.comm.properties file - as we have seen when Sun released 3.0.
>> It has the following advantages:
>>
>> - The "generic" javax.comm implementation will happily load this
>> class as its primary driver.
>> - No javax.comm.properties file is required.
>> - This does not violate the javax.comm license agreement as there is
>> no mention of the "com.sun.comm" package in this license agreement at
>> all.
>> - Authors packaging comm.jar with their application can strip out all
>> com.sun.comm classes from comm.jar
>>
> 
> I would not encourage people to place packages in the com.sun.comm 
> namespace.  Authors using Sun's commapi 2.0 should just realize it is 
> greatly limited in practical utility and consider moving to something that 
> isn't being rescued from EOL.
> 
> The primary focus of this release is projects previously depending upon 
> Sun CommAPI + RXTX.  There are no plans at this time to provide future 
> support in this arrangement due to technical incompatabilities we have no 
> control over in commapi 3.0 and limited utility of Sun's generic comm.jar 
> in commapi 2.0 offered.  Projects should be aware of this so they can make 
> appropriate plans.

Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86,
or need the powerful portmapping features in javax.com 3.0, or would like to
acquire the Interactive Serial Port Test utility.

-Paul


From paul.klissner at sun.com  Tue Jun 20 05:33:44 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Tue, 20 Jun 2006 04:33:44 -0700
Subject: [Rxtx] Suggested installation RXTX 2.0x...
In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
Message-ID: <4497DD18.70207@sun.com>

Joachim Buechse wrote:
> Hello everybody,
> 
> I have been fighting a bit with the javax.comm version of RXTX the  
> last days. I am working on the README .OSX now and try to figure out  
> which should be the "suggested" installation.
> 
> The facts:
> ------
> 
> - the "generic" comm.jar version of javax.comm which has been made re- 
> available tries to load com.sun.comm.SolarisDriver
> - this classname can be overridden ONLY by putting a file  
> javax.comm.properties in {java.home}/lib
> - if it is not overridden and SolarisDriver.class is not found  
> CommPortIdentifier will be disfunctional (in particual it is not  
> possible to add CommPort's via CommPortIdentifier.add).
> - the license distributed with comm.jar does not allow the  
> modification/addition of classes in javax.comm (however no mention of  
> com.sun...)
> 
> 
> What really bothers me is to suggest putting this config file in the  
> "global" vm installation. This is particularly ugly on the Mac as  
> there are several VM installations and the file may be forgotten.  
> Additionally it may create versioning problems. I prefer an  
> installation where all files are local to the application (even  
> comm.jar).
> 
> In my opinion the ideal situation would be:
> ------
> 
> 1) The author of a program compiles against javax.comm.
> 2a) For platforms supported by Sun the user is free to use the 3.0  
> comm.jar download from Sun
> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to  
> the classpath of the application (and librxtxSerial.jnilib to the  
> application directory). Also he will need the 2.0.3 generic comm.jar  
> from Sun.
> 3) Nobody messes with the global VM installation.
> 
> Of course 2a) and 2b) could be handled by the author of the program  
> via an appropriate installer. The author could also decide to always  
> use RXTX and include the generic javax.comm classes as well as the  
> RXTX classes in his application jar. [If he further uses an explicit  
> call to System.load() he may even include the jnilib(s) in the jar,  
> extract it (based on the platform name) at runtime to a temp file and  
> load it from there.]
> 

This was how the Sun implementation originated (I did not write
that code).  I completely agree, and I fixed the whole conf file
locating mechanism in 3.0 to avoid the problems youmentioned.
However, I was unaware of how RxTx was using Sun's implementation,
so I didn't architect it in such a way as to avoid namespace pollution
in the native space in for the backend provider.  In retrospect,
I should have done that differently just as a design principle,
but at this point I don't have the spare cycles to get that all
re-factored.  Further, I'm loathe to do it, because the whole
thing will still be an under-the-hood hack due to the constraints
of the API itself.

Paul





From brian at mbari.org  Tue Jun 20 10:23:54 2006
From: brian at mbari.org (Brian Schlining)
Date: Tue, 20 Jun 2006 09:23:54 -0700
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>


Hi Joachim,

> There has been some discussions about the best way to install RXTX
> and where to place files.
>
> I suggest that,
>
> - we include the native libraries for the most common operating
> systems (in a special version of) RXTXcomm.jar
> - we add loader code which tries to extract and load the platform
> specific binary at runtime
> - on failure the current mechanism remains as a fallback

I like your suggestion. However, my understanding is that in general  
the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH  
(Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to  
be loaded by the JVM. The alternative is to point to your native lib  
directory using -Djava.library.path=/my/dir/with/native/libs when you  
launch the JVM. So, I'm very interested to know how you're planning  
to work around this.

> PS: Of course the suggested solution is already possible today,
> however relatively few programmers know how to correctly extract a
> binary resource file via the class loader and load it as a native
> library.

So how do you use it to dynamically load a native lib? I've read that  
you can't really modify the java.library.path after the JVM has been  
launched. (http://forum.java.sun.com/thread.jspa? 
threadID=627890&tstart=90)

Thanks

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0014.html

From joachim at buechse.de  Tue Jun 20 09:20:29 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 17:20:29 +0200
Subject: [Rxtx] 2.0x in sync with 2.1x
Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>

I have added most of the changes from the 2.1 branch to the 2.0 branch.

This includes
  - correction of illegal javadoc comments
  - implementation errors in handling of Thread.interrupt in  
RXTXPort.java
  - MacOS X locking without lock files/special user groups
  - XCode project which builds a universal binary library
  - updated documentation for OSX

I have done some minimal testing (only G4).
[Trent: there are still some changes you made for specific baud  
rates. I will not sync this, as I can not test them. From my  
perspective we are ready for 2.08/2.18]

The updated documentation can be found in the file README.OSX. Here  
it is:

------------------------ Required files -----------------------

To use or compile RXTX 2.0.x you need to downlad the "generic"  
version (2.0.3)
of the javax.comm implementation from Sun. The zip you download  
contains an
archive comm.jar which is required:

- To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar

- To run the app you will need comm.jar in the classpath or in  
{java.lib.path}


------------------------ Installation on MacOSX -----------------------

WARNING: Please read this section until the end.

---
Preparation
---

You may want to spare your users the burden of modifying the global VM
installation. OSX has several different VM versions installed by  
default and
regular users will be unable to figure out which version will load your
application.

If you provide the class

package com.sun.comm;
public class SolarisDriver extends gnu.io.RXTXCommDriver {
}

and make sure, that it is present in the classpath before Suns  
"generic" comm.jar
your users can skip the following step:

Create a file named
    javax.comm.properties
in the directory
    /System/Library/Frameworks/JavaVM.framework/Home/lib/
which contains (only) the following line (no leading space):
    Driver=gnu.io.RXTXCommDriver



----
The unsafe way of using RXTX on OS X:
----

RXTX can be installed by putting the files
   libSerial.jnilib
   RXTXcomm.jar
   comm.jar
into the folder
   /Library/Java/Extensions

This is NOT RECOMMENDED as it creates versioning conflicts among  
applications.
However you may be forced to install it this way if an application  
was written
for Windows or Linux, requires RXTX and you are not able to change  
its starter.


----
The safe way of using RXTX on OS X:
----

Make sure that you have no (older) version of RXTX installed in
   /Library/Java/Extensions
   /System/Library/Java/Extensions
   /usr/lib/java

Put
   libSerial.jnilib
in the directory of the application (the JavaVM will find it there). Add
   RXTXComm.jar
   comm.jar
to the application classpath or include the classes in the  
application jar.
(Some applications already include the RXTX classes in their  
application jar,
in which case only the file libSerial.jnilib is required).


----
History
----

Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation  
of lockfiles
required special permissions for the user executing an application  
based on RXTX.
To simplify the setup RXTX came with an installer modifying group  
permissions
and installing RXTX in the global location /Library/Java/Extensions.  
However
this was prune to versioning conflicts and is no longer recommended.

--------------------- Build instructions for OSX XCode  
-------------------

contributed by Joachim Buechse <joachim at buechse.de>
original version by Dmitry Markman <dmarkman at mac.com>

System requirements for building:
MacOSX 10.4
XCode 2.3

   open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj
   choose libSerial.jnilib target
   build

After the build you will find RXTXcomm.jar and libSerial.jnilib files  
in the
directory build/Development.

In case you can't find RXTXcomm.jar build the RXTXcomm target manually.
In case of (serious) problems feel free to contact joachim at buechse.de .



From tjarvi at qbang.org  Tue Jun 20 22:01:45 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT)
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
Message-ID: <Pine.LNX.4.61.0606202127270.14139@www>

> ---
> Preparation
> ---
>
> You may want to spare your users the burden of modifying the global VM
> installation. OSX has several different VM versions installed by
> default and
> regular users will be unable to figure out which version will load your
> application.
>
> If you provide the class
>
> package com.sun.comm;
> public class SolarisDriver extends gnu.io.RXTXCommDriver {
> }
>
> and make sure, that it is present in the classpath before Suns
> "generic" comm.jar
> your users can skip the following step:

Hi Joachim

With regards to the above, I have not seen that we have Sun's OK to 
promote that.  I'm not very comfortable with the distribution 
documentation advocating this without Sun agreeing.

I see your point but I'd rather not actively promote putting classes in 
Sun's namespace without permission if you don't mind.  This isn't about 
what is in a license.

I'll go through the code tomorrow night.  It was a late night at work 
today.  There is also a w32 fix comming for people opening and closing 
multiple ports.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Wed Jun 21 01:56:45 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 21 Jun 2006 09:56:45 +0200
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <Pine.LNX.4.61.0606202127270.14139@www>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
	<Pine.LNX.4.61.0606202127270.14139@www>
Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>

Hello Trent,

I guess we will not get an explicit OK from Sun for such a hack. I  
think Paul has made it pretty clear, that he does not have the  
resources to modify the 2.x or 3.x code for the needs of RXTX. I'm  
not thrilled but OK with the current API. Hence I dont agree with  
Paul's idea to start a new JSR to fix the implementation - but that's  
mainly because I dont have the time to push it. According to their  
Readme Sun sees no business case in having cross platform support for  
javax.comm - that is sad but it's none of my business. However I  
prefer to program versus javax.comm in my projects as this gives an  
advanced user the chance to exchange the provider without access to  
the code.

I interpret Pauls reponse to my original "Request for comment" as a  
quiet acceptance of the hack I propose (he did respond, but not at  
all to the sun.comm namespace suggestion). This is certainly not  
something we should put into RXTXcomm.jar but hinting a work around  
for implementation errors should be allowed. That's why I've choosen  
the wording "You may want to spare" and "If you provide". The company  
I worked for has choosen similar hacks for years to fix bugs in swing  
for JDK1.1 applications. Those hacks were usually included in their  
own swingpatch.jar.

Having said all that - I do not take it as an insult if you remove  
the paragraph from the Readme. I appreciate that you notified me  
before. It would be interesting to hear some more opinions from the  
list members...

Best regards,
Joachim


On 21.06.2006, at 06:01, Trent Jarvi wrote:

>> ---
>> Preparation
>> ---
>>
>> You may want to spare your users the burden of modifying the  
>> global VM
>> installation. OSX has several different VM versions installed by
>> default and
>> regular users will be unable to figure out which version will load  
>> your
>> application.
>>
>> If you provide the class
>>
>> package com.sun.comm;
>> public class SolarisDriver extends gnu.io.RXTXCommDriver {
>> }
>>
>> and make sure, that it is present in the classpath before Suns
>> "generic" comm.jar
>> your users can skip the following step:
>
> Hi Joachim
>
> With regards to the above, I have not seen that we have Sun's OK to
> promote that.  I'm not very comfortable with the distribution
> documentation advocating this without Sun agreeing.
>
> I see your point but I'd rather not actively promote putting  
> classes in
> Sun's namespace without permission if you don't mind.  This isn't  
> about
> what is in a license.
>
> I'll go through the code tomorrow night.  It was a late night at work
> today.  There is also a w32 fix comming for people opening and closing
> multiple ports.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Wed Jun 21 02:03:33 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 21 Jun 2006 10:03:33 +0200
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
	<6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
Message-ID: <BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>

See System.load(String) [it's also mentioned under the URL you posted].

Regards,
Joachim


On 20.06.2006, at 18:23, Brian Schlining wrote:

> So how do you use it to dynamically load a native lib? I've read  
> that you can't really modify the java.library.path after the JVM  
> has been launched. (http://forum.java.sun.com/thread.jspa? 
> threadID=627890&tstart=90)
>
> Thanks
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From baris.ozkan at elikasu.com.tr  Wed Jun 21 07:58:06 2006
From: baris.ozkan at elikasu.com.tr (Baris)
Date: Wed, 21 Jun 2006 16:58:06 +0300
Subject: [Rxtx] RS 232 ..additional parameters
Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>

Hi,
 
Currently i am developing an application that requires to connect to a
remote rs232 device through  a dialup connection.
 
My problem is that the communication needs several more connection
parameters (i extracted that information from the vendor's dll , listed at
the end of the message)
 
I explored rxtx API and src files and could not find methods to set a
majority  of the parameters.
Am i missing any point or does rxtx is limited to soem standard set of
functionality(e.g. commAPI)? How  is it possible ,if i want to put some
extensions(???) to current rxtx implementation?
 
I am not very good at rs232 programming so excuse me if this message  is
boring one.
 
Thanx
 
Baris Ozkan
 
 
A Listing of Parameters:
 
 
typedef struct _DCB {

DWORD DCBlength; /* sizeof(DCB) */

DWORD BaudRate; /* Baudrate at which running */

DWORD fBinary: 1; /* Binary Mode (skip EOF check) */

DWORD fParity: 1; /* Enable parity checking */

DWORD fOutxCtsFlow:1; /* CTS handshaking on output */

DWORD fOutxDsrFlow:1; /* DSR handshaking on output */

DWORD fDtrControl:2; /* DTR Flow control */

DWORD fDsrSensitivity:1; /* DSR Sensitivity */

DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */

DWORD fOutX: 1; /* Enable output X-ON/X-OFF */

DWORD fInX: 1; /* Enable input X-ON/X-OFF */

DWORD fErrorChar: 1; /* Enable Err Replacement */

DWORD fNull: 1; /* Enable Null stripping */

DWORD fRtsControl:2; /* Rts Flow control */

DWORD fAbortOnError:1; /* Abort all reads and writes on Error */

DWORD fDummy2:17; /* Reserved */

WORD wReserved; /* Not currently used */

WORD XonLim; /* Transmit X-ON threshold */

WORD XoffLim; /* Transmit X-OFF threshold */

BYTE ByteSize; /* Number of bits/byte, 4-8 */

BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */

BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */

char XonChar; /* Tx and Rx X-ON character */

char XoffChar; /* Tx and Rx X-OFF character */

char ErrorChar; /* Error replacement char */

char EofChar; /* End of Input character */

char EvtChar; /* Received Event character */

WORD wReserved1; /* Fill for now. */

} DCB, *LPDCB;

typedef struct _COMMTIMEOUTS {

DWORD ReadIntervalTimeout; /* Maximum time between read chars. */

DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */

DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */

DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */

DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */

} COMMTIMEOUTS,*LPCOMMTIMEOUTS;

dcb.fOutX = FALSE;

dcb.fInX = FALSE;

dcb.fOutxCtsFlow = FALSE;

dcb.fBinary = TRUE;

dcb.fRtsControl = RTS_CONTROL_ENABLE;

SetCommState(hComm , &dcb ); 

COMMTIMEOUTS commTimeOut;

GetCommTimeouts(hComm, &commTimeOut );

commTimeOut.WriteTotalTimeoutMultiplier = 1; 

commTimeOut.WriteTotalTimeoutConstant = 18; 

// commTimeOut.ReadIntervalTimeout = 28; 

commTimeOut.ReadIntervalTimeout = 0; 

// commTimeOut.ReadTotalTimeoutMultiplier = 184; 

commTimeOut.ReadTotalTimeoutMultiplier = 300; 

// commTimeOut.ReadTotalTimeoutConstant = 1200;

commTimeOut.ReadTotalTimeoutConstant = 1200;

SetCommTimeouts(hComm, &commTimeOut);

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0014.html

From ajmas at sympatico.ca  Wed Jun 21 08:14:26 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Wed, 21 Jun 2006 10:14:26 -0400
Subject: [Rxtx] When is 2.18 planned for?
Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

Just curious as to know if there is a target date for 2.18?

Andre



From brian at mbari.org  Wed Jun 21 09:36:00 2006
From: brian at mbari.org (Brian Schlining)
Date: Wed, 21 Jun 2006 08:36:00 -0700
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
	<6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
	<BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>
Message-ID: <A21C9BC0-7894-4B08-AC82-44E11AB3D461@mbari.org>

Ha!!

I suppose I should read my own postings. ;-)

Thanks
B

On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote:

> See System.load(String) [it's also mentioned under the URL you  
> posted].
>
> Regards,
> Joachim
>
>
> On 20.06.2006, at 18:23, Brian Schlining wrote:
>
>> So how do you use it to dynamically load a native lib? I've read
>> that you can't really modify the java.library.path after the JVM
>> has been launched. (http://forum.java.sun.com/thread.jspa?
>> threadID=627890&tstart=90)

Brian Schlining
Software Engineer
http://www.mbari.org




From ajmas at sympatico.ca  Wed Jun 21 16:41:28 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Wed, 21 Jun 2006 18:41:28 -0400
Subject: [Rxtx] CVS build question
Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X:

 The JCL extension to RxTx requires comm.jar
 If you intend to use RxTx for commapi support comm.jar
 needs to be located in  /System/Library/Frameworks/JavaVM.framework/
  Versions/1.5/Home/lib/ext/comm.jar

I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me.

On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native).

Andre






From tjarvi at qbang.org  Wed Jun 21 18:00:04 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT)
Subject: [Rxtx] CVS build question
In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606211756310.14139@www>

On Wed, 21 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> Is the CVS repository meant to build for gnu.io or javax.comm? I ask 
> this, because I see the following when calling ./configure from MacOS X:
>
> The JCL extension to RxTx requires comm.jar
> If you intend to use RxTx for commapi support comm.jar
> needs to be located in  /System/Library/Frameworks/JavaVM.framework/
>  Versions/1.5/Home/lib/ext/comm.jar
>
> I am wanting to build for the gnu.io package, since I want to jump ahead 
> and see if the changes, intended for 2.18 for MacOS X, work for me.
>
> On a side note /Library/Java/Extensions should be included as a valid 
> search path for the JAR, since this is where Apple recommends placing 
> third party extensions (both Java and native).
>

rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel"
rxtx 2.0 src is obtained with "cvs checkout rxtx-devel"

rxtx 2.1 is a complete package in namespace gnu.io
rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 18:02:23 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT)
Subject: [Rxtx] When is 2.18 planned for?
In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606211800180.14139@www>

On Wed, 21 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> Just curious as to know if there is a target date for 2.18?
>

Hi Andre

"When it is ready" :)

Probably this weekend.  Maybe sooner.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 18:10:18 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT)
Subject: [Rxtx] RS 232 ..additional parameters
In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>
References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>
Message-ID: <Pine.LNX.4.61.0606211805010.14139@www>

On Wed, 21 Jun 2006, Baris wrote:

> Hi,
>
> Currently i am developing an application that requires to connect to a
> remote rs232 device through  a dialup connection.
>
> My problem is that the communication needs several more connection
> parameters (i extracted that information from the vendor's dll , listed at
> the end of the message)
>
> I explored rxtx API and src files and could not find methods to set a
> majority  of the parameters.
> Am i missing any point or does rxtx is limited to soem standard set of
> functionality(e.g. commAPI)? How  is it possible ,if i want to put some
> extensions(???) to current rxtx implementation?
>
> I am not very good at rs232 programming so excuse me if this message  is
> boring one.
>
> Thanx
>

Hi Baris

> typedef struct _DCB {
> typedef struct _COMMTIMEOUTS {

These are all handled in termios.c.  It is possible to add extensions to 
rxtx 2.1.  It may well be that the defaults are the same for the variables 
not covered by the existing API.  You can dump the DCB and COMMTIMEOUTS 
from inside termios.c to compare.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 20:23:30 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT)
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
	<Pine.LNX.4.61.0606202127270.14139@www>
	<789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>
Message-ID: <Pine.LNX.4.61.0606212012210.14139@www>

> I'm
> not thrilled but OK with the current API. Hence I dont agree with
> Paul's idea to start a new JSR to fix the implementation - but that's
> mainly because I dont have the time to push it. According to their
> Readme Sun sees no business case in having cross platform support for
> javax.comm - that is sad but it's none of my business. However I
> prefer to program versus javax.comm in my projects as this gives an
> advanced user the chance to exchange the provider without access to
> the code.

Hi Joachim

With regards to the JSR, I think that would be Doug's call.  The effort I 
put in would have to be on my own time which would not be a great deal.  I 
could help things go smoothly but thats not the same as pushing something 
through.

--
Trent Jarvi
tjarvi at qbang.org



From vt at freehold.crocodile.org  Wed Jun 21 21:05:22 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Wed, 21 Jun 2006 20:05:22 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
Message-ID: <449A08F2.3020106@freehold.crocodile.org>

Hello all,

I know this question may belong to JSR lists, but since all interested 
parties are here, I thought I just ask this question here, again...

A while ago I run into a problem and wrote a rant, here: 
http://servomaster.sourceforge.net/dev/serial-usb.html
At the time of writing I didn't think of adding another possible 
solution - changing the CommAPI specs to support removable devices. 
Apparently, Serial/USB bridges are here to stay, and this issue has to 
be addressed.

Wonder if anything changed since, and any abstractions for supporting 
removable devices made it into current or future Java CommAPI drafts - 
Paul, any comments?

--vt



From joachim at buechse.de  Thu Jun 22 01:59:54 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 22 Jun 2006 09:59:54 +0200
Subject: [Rxtx] CVS build question
In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de>

Hello Andre,

I am not sure how well the configure/make mechanism will work on OSX.  
I know that a while ago some contributors tried to get configure/make  
working on OSX but from comments I found in the readmes this work was  
only partially successfull. For compilation on OSX we have used the  
ProjectBuilder/XCode projects you can find in MACOSX_IDE.

Regarding the  ./configure comment:
RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config  
file javax.comm.properties. The later MUST reside in {java.home}/lib.  
As the two only work together putting comm.jar into  /Library/Java/ 
Extensions  and hence making it available to all current and future  
VM installations will only add to confusion.

Regards,
Joachim

On 22.06.2006, at 00:41, Andre-John Mas wrote:

> Hi,
>
> Is the CVS repository meant to build for gnu.io or javax.comm? I  
> ask this, because I see the following when calling ./configure from  
> MacOS X:
>
>  The JCL extension to RxTx requires comm.jar
>  If you intend to use RxTx for commapi support comm.jar
>  needs to be located in  /System/Library/Frameworks/JavaVM.framework/
>   Versions/1.5/Home/lib/ext/comm.jar
>
> I am wanting to build for the gnu.io package, since I want to jump  
> ahead and see if the changes, intended for 2.18 for MacOS X, work  
> for me.
>
> On a side note /Library/Java/Extensions should be included as a  
> valid search path for the JAR, since this is where Apple recommends  
> placing third party extensions (both Java and native).
>
> Andre
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Thu Jun 22 02:51:05 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 22 Jun 2006 10:51:05 +0200
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449A08F2.3020106@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>

Hello Vadim,

I think that your rant is to the point. However it is a bit like  
saying that Windows is at the source of email degradation and the  
only solution is to have users switch to safer operating systems.

I don't see how javax.comm or RXTX can address the problems you  
mention. Of course it would be super cool if javax.comm could magicly  
find the "matching" usb-device and query it's configuration via the  
usb protocol - however this magic (mapping /dev/xyz to its underlying  
USB device) is not supported by any kernel APIs I am aware of. It  
could be supported via POSSIX ioctl calls but then you should address  
your rant to the POSSIX group...

So for the time beeing it's either up to the virtual comm port driver  
to provide a usefull name under /dev/ or to the user choosing the  
right port to use. One example of a smart(er) com port driver is the  
KDDI driver for OSX, which will create device names like "/dev/ 
cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- 
encoded into the bridge chip. The same driver for windows also has  
some options allowing it in theory to recreate the same COMx every  
time a device is plugged/unplugged.

For most industrial applications however it will be up to the user to  
choose the right port (without getting a lot of help doing so).

Probing serial ports can go wrong, that's right. However any serial  
device developper would be well adviced to implement a basic set of  
Hayes AT modem commands (be it a modem or not). Especially AT I0.  
Anyone failing to do so risks that the users favourite TCP/PPP/FAX  
application or stack will kill the device in short time.

Best regards,
Joachim


On 22.06.2006, at 05:05, Vadim Tkachenko wrote:

> Hello all,
>
> I know this question may belong to JSR lists, but since all interested
> parties are here, I thought I just ask this question here, again...
>
> A while ago I run into a problem and wrote a rant, here:
> http://servomaster.sourceforge.net/dev/serial-usb.html
> At the time of writing I didn't think of adding another possible
> solution - changing the CommAPI specs to support removable devices.
> Apparently, Serial/USB bridges are here to stay, and this issue has to
> be addressed.
>
> Wonder if anything changed since, and any abstractions for supporting
> removable devices made it into current or future Java CommAPI drafts -
> Paul, any comments?
>
> --vt
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From vt at freehold.crocodile.org  Thu Jun 22 13:16:03 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 12:16:03 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
Message-ID: <20060622191603.GA17487@freehold.crocodile.org>

Hello Joachim,

> I think that your rant is to the point. However it is a bit like  
> saying that Windows is at the source of email degradation and the  
> only solution is to have users switch to safer operating systems.

I guess the problem is that the rant itself is obsolete and has to be
updated according to latest developments. At the time of writing there
weren't that many bridges around, and the trend didn't manifest itself as it
does now.

> I don't see how javax.comm or RXTX can address the problems you  
> mention.

I would agree that javax.comm won't be able to address the problem, at least
in the short run. As for RxTx - well, nobody prevents it from being a
superset of CommAPI specification, right? RxTx being the de-facto standard
for quite a few platforms, I'd daresay the standard may follow.

> Of course it would be super cool if javax.comm could magicly find the
> "matching" usb-device and query it's configuration via the usb protocol -
> however this magic (mapping /dev/xyz to its underlying USB device) is not
> supported by any kernel APIs I am aware of. It could be supported via
> POSSIX ioctl calls but then you should address your rant to the POSSIX
> group...

As a matter of fact, my bigger concern is addressing the fact that a serial
device can now be removable. This hasn't been the case before, and it
clearly is now. Regarding the above, well, I guess if we accept this fact,
we also need to accept the fact that we need at least rudimentary means of
identification of a serial device. For the USB case, it would usually be the
vendor/product ID, plus possible serial number - but it is irrelevant what
exactly the identifying information is, as long as it allows to identify the
device.

A paradigm shift is required, this is what I wanted to say. Serial devices
can be removed and replaced, it's now our turn to learn to deal with it.

> Joachim

--vt


From jredman at ergotech.com  Thu Jun 22 13:41:44 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 13:41:44 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
Message-ID: <449AF278.6000903@ergotech.com>


Vadim Tkachenko wrote:
> A paradigm shift is required, this is what I wanted to say. Serial devices
> can be removed and replaced, it's now our turn to learn to deal with it.

The removal if the serial port hardly significantly different from the 
removal of the device attached to the serial port.   Different, 
slightly, but not a "paradigm shift".

And yes, someone could unplug a USB serial device and plug it into a 
different USB port so that it has a different name/number, but they 
could do that with the device itself, move it from com1 to com2.

Am I missing something?

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 13:57:27 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 12:57:27 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449AF278.6000903@ergotech.com>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
Message-ID: <20060622195727.GA20247@freehold.crocodile.org>

On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote:
> 
> Vadim Tkachenko wrote:
> > A paradigm shift is required, this is what I wanted to say. Serial devices
> > can be removed and replaced, it's now our turn to learn to deal with it.
> 
> The removal if the serial port hardly significantly different from the 
> removal of the device attached to the serial port.   Different, 
> slightly, but not a "paradigm shift".
> 
> And yes, someone could unplug a USB serial device and plug it into a 
> different USB port so that it has a different name/number, but they 
> could do that with the device itself, move it from com1 to com2.
> 
> Am I missing something?

Yes, the fact that they could unplug a device A and plug a device B. With
the introduction of the concept of removability, the notion of the serial
port itself is not as important anymore, but the notion of the unique device
identifier is.

Consider a situation: long running system (enterprise HVAC, tens of nodes,
tens of thousands square feet area, hundreds of thousand dollars worth of
equipment being conditioned, can't shut down), serial/usb device fails, is
replaced by an identical device with a different serial #.

A little bit farfetched, but hopefully highlighting the point I'm trying to
make.

> Jim

--vt


From jredman at ergotech.com  Thu Jun 22 14:37:38 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 14:37:38 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>	<20060622191603.GA17487@freehold.crocodile.org>	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
Message-ID: <449AFF92.8080003@ergotech.com>


Vadim Tkachenko wrote:
>>
>> Am I missing something?
> 
> Yes, the fact that they could unplug a device A and plug a device B. With
> the introduction of the concept of removability, the notion of the serial
> port itself is not as important anymore, but the notion of the unique device
> identifier is.

Serial devices are always removable.  I could unplug _serial_ device A 
and plug in _serial_ device B.  We have systems running with two RS485 
ports, one talks to a Modbus PLC network one to a number of drives on a 
proprietary protocol.  If you plug the wrong DB9 into the wrong port the 
application doesn't work.

If you dangle a USB 485 converter on the end of the DB9 you've just 
moved the problem from RS485 to USB, but the problem/effect is the same.

> 
> Consider a situation: long running system (enterprise HVAC, tens of nodes,
> tens of thousands square feet area, hundreds of thousand dollars worth of
> equipment being conditioned, can't shut down), serial/usb device fails, is
> replaced by an identical device with a different serial #.
> 
> A little bit farfetched, but hopefully highlighting the point I'm trying to
> make.

Nothing's changed.  If I had a 4 port ISA board and plugged it into my 
new shiny '386 machine.  I could have com ports 9-12.  If I took a board 
off the shelf and didn't set the jumpers, I would have com ports 3-6.

The problem's the same.  If you replace with identical product then the 
com ports  will be the same - no software changes required.  If you 
replace one piece of hardware with hardware from a different 
manufacturer, then the naming/numbering may change.  You're physically 
changing the system, so may reasonably expect to have to make a software 
change.  RXTX actually handles this situation quite well with the -D 
command line option.  (My experience has generally been that the port 
number depends more on the USB port used than the hardware - so the 
chances are even with a hardware change the port number/name will be the 
same.)

Slightly Off Topic - there is a reason why industrial users will pay a 
premium for continued availability of hardware.  Yes you can mail-order 
a $10 USB converter and it will work, but there's no guarantee that the 
next time you buy the same part number from the same vendor it will be 
the same.  The industrial vendors will charge you $100+ for the same 
item, but it will be the same every time you buy it for the next 5 to 10 
years.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 14:37:19 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 13:37:19 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
Message-ID: <20060622203719.GA22521@freehold.crocodile.org>

Hello again,

And while I'm at it, why don't just say this: give me one good reason to
write 3+ different ways of handling removable devices, one for USB, one for
FireWire, one for serial...

I understand very well that this goes way beyond the scope of RxTx and
CommAPI and will require cooperation between them and javax.usb and whatever
JSR is responsible for FireWire implementation - but the end result is well
worth it. Abstract out and generalize arrival/departure/monitoring/discovery
API, provide protocol specific extensions for each, live happily ever after.

--vt


On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote:
> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote:
> > 
> > Vadim Tkachenko wrote:
> > > A paradigm shift is required, this is what I wanted to say. Serial devices
> > > can be removed and replaced, it's now our turn to learn to deal with it.
> > 
> > The removal if the serial port hardly significantly different from the 
> > removal of the device attached to the serial port.   Different, 
> > slightly, but not a "paradigm shift".
> > 
> > And yes, someone could unplug a USB serial device and plug it into a 
> > different USB port so that it has a different name/number, but they 
> > could do that with the device itself, move it from com1 to com2.
> > 
> > Am I missing something?
> 
> Yes, the fact that they could unplug a device A and plug a device B. With
> the introduction of the concept of removability, the notion of the serial
> port itself is not as important anymore, but the notion of the unique device
> identifier is.
> 
> Consider a situation: long running system (enterprise HVAC, tens of nodes,
> tens of thousands square feet area, hundreds of thousand dollars worth of
> equipment being conditioned, can't shut down), serial/usb device fails, is
> replaced by an identical device with a different serial #.
> 
> A little bit farfetched, but hopefully highlighting the point I'm trying to
> make.
> 
> > Jim
> 
> --vt
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx


From jredman at ergotech.com  Thu Jun 22 15:13:49 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 15:13:49 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>	<20060622191603.GA17487@freehold.crocodile.org>	<449AF278.6000903@ergotech.com>	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
Message-ID: <449B080D.9080208@ergotech.com>


Vadim Tkachenko wrote:
> Hello again,
> 
> And while I'm at it, why don't just say this: give me one good reason to
> write 3+ different ways of handling removable devices, one for USB, one for
> FireWire, one for serial...

You don't, they're all the same "I have lost communication with my 
serial device".

The only thing you could really do is improve error reporting by knowing 
the exact sub-system.  ("Device X which is/was attached to USB port Y is 
no longer functioning, please check the USB ports, the device, the 
cables and anything else you can think of that may be a cause of 
failure.")  That just requires an intelligent description of the port.

> I understand very well that this goes way beyond the scope of RxTx and
> CommAPI and will require cooperation between them and javax.usb and whatever
> JSR is responsible for FireWire implementation - but the end result is well
> worth it. Abstract out and generalize arrival/departure/monitoring/discovery
> API, provide protocol specific extensions for each, live happily ever after.

There's a huge list of pseudo-serial devices each with a different set 
of requirements, Bluetooth, RFC 2217, a host of proprietary systems, 
etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I 
have no clue how you'd implement them in a general/cross platform sense.

You haven't convinced me (and only me, others may see something that I 
don't, I'm not speaking for them) that this mechanism can be implemented 
in any practical sense.  That is, that the implementation could be wide 
enough to be consider generally available in RXTX regardless of the 
serial port implementation, platform, etc..  However, if you can come up 
with a general design and a reference implementation for one subsystem, 
I'd like to see it and might get on board.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 15:40:55 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 14:40:55 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449B080D.9080208@ergotech.com>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
Message-ID: <20060622214055.GA25497@freehold.crocodile.org>

On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote:
> 
> Vadim Tkachenko wrote:
> > Hello again,
> > 
> > And while I'm at it, why don't just say this: give me one good reason to
> > write 3+ different ways of handling removable devices, one for USB, one for
> > FireWire, one for serial...
> 
> You don't, they're all the same "I have lost communication with my 
> serial device".

"I have lost communication with my ${protocol} device".

> The only thing you could really do is improve error reporting by knowing 
> the exact sub-system.  ("Device X which is/was attached to USB port Y is 
> no longer functioning, please check the USB ports, the device, the 
> cables and anything else you can think of that may be a cause of 
> failure.")

"Device ${id} which is/was attached to ${protocol} port ${port} is no longer
functioning, please check the ${protocol} ports, the device, the
${protocol_media} and anything else you can think of that may be a cause of
failure".

>  That just requires an intelligent description of the port.

Agree absolutely.

> > I understand very well that this goes way beyond the scope of RxTx and
> > CommAPI and will require cooperation between them and javax.usb and whatever
> > JSR is responsible for FireWire implementation - but the end result is well
> > worth it. Abstract out and generalize arrival/departure/monitoring/discovery
> > API, provide protocol specific extensions for each, live happily ever after.
> 
> There's a huge list of pseudo-serial devices each with a different set 
> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, 
> etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I 
> have no clue how you'd implement them in a general/cross platform sense.

That's because some of the protocols were created decades ago when
autoconfiguration wasn't even conceived, much less practical. RS232/RS485
don't have a clue about identity discovery, and even capabilities discovery
beyond obvious 8N1 etc.

I agree that today all these protocols have generally incompatible
strategies for handling the situations I'm trying to address, but there's
nothing that says it's not an oversight. Besides, we're dealing with the
devices at a level of abstraction that allows some simplifications and
generalizations, at least part of the time - unless it's the protocol
specific features we're dealing with.

> You haven't convinced me (and only me, others may see something that I 
> don't, I'm not speaking for them) that this mechanism can be implemented 
> in any practical sense.  That is, that the implementation could be wide 
> enough to be consider generally available in RXTX regardless of the 
> serial port implementation, platform, etc..  However, if you can come up 
> with a general design and a reference implementation for one subsystem, 
> I'd like to see it and might get on board.

Actually, I wasn't even thinking about all this stuff when I wrote the first
message on the subject :) Now that you mention it - well, I'm not sure I can
chew the piece I just tried to bite in reasonable amount of time.

How do you eat an elephant? One bite at a time. If we could agree that a
small step in the specification is acceptable at this time, and express
further intentions, things may start happening.

To put it succinctly:

- Concept of a "port" should be augmented with a concept of a "device". A
device may be attached to a port in an implicit or explicit way.
- Implicitly connected device is exactly what the current scope of the
specification covers. No new functionality is offered.
- Explicitly connected device supports detachable device semantics, just as
other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a
few).
- The input and output streams are not properties of a port now, but
properties of the device attached to the port.
- A mechanism to allow listening for device arrivals and departures must be
made available.

That's it, off the top of my head.

I understand that this goes completely against current javax.comm specs, but
an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be
difficult to implement without disrupting javax.comm compatibility.

One concern is how to deal with the device identity - but there's no general
way of dealing with this at this time, devices may or may not offer identity
discovery.

> Jim

--vt


From joachim at buechse.de  Fri Jun 23 02:12:43 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 23 Jun 2006 10:12:43 +0200
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
Message-ID: <CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>

Hello++ Vadim,

I would like to repeat that your request is best addressed to the  
POSSIX standardization group - or maybe the BSD/Linux maintainers. If  
you convince the BSD or Linux guys to add this kind of functionality  
(they can as most of there VCP drivers are open source), there is a  
certain chance that other vendors will pick it up. I assure you that  
RXTX will happily provide this functionality once it's possible - I'm  
sure there is more than one maintainer that would love to add it.  
Having this concept penetrate the market may take some years though.

SHORT: The solution you would like to see could be added to the API  
but it can not be implemented (at least not on the platforms I know).  
There are currently no hooks in the kernel that allow you to discover  
"the device" or even the "means of connection" based on an existing  
"device file descriptor" ie COM-port or /dev/... entry. The name  
mapping of the device is handled by the virtual com port driver of  
the device. Unless you are suggesting RXTX should reimplement virtual  
com port drivers for all usb/serial bridges out there your request is  
understandable from a users viewpoint but simply not realizable. It's  
like asking that the Socket api should identify the computer behind  
an IP address (ie by its Ethernet address). While this COULD be  
implemented in TCP/IP, it IS not, and hence there is no point adding  
such a function to the Socket API.

The current trend for USB/Bluetooth/Irda/etc connected devices is  
going away from serial port abstraction towards RPC (ie the drivers  
provide a device specific or device class specific driver that  
provides an application level api to the device functions). The line  
level protocol is often not even published.

Best regards,
Joachim

On 22.06.2006, at 23:40, Vadim Tkachenko wrote:

> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote:
>>
>> Vadim Tkachenko wrote:
>>> Hello again,
>>>
>>> And while I'm at it, why don't just say this: give me one good  
>>> reason to
>>> write 3+ different ways of handling removable devices, one for  
>>> USB, one for
>>> FireWire, one for serial...
>>
>> You don't, they're all the same "I have lost communication with my
>> serial device".
>
> "I have lost communication with my ${protocol} device".
>
>> The only thing you could really do is improve error reporting by  
>> knowing
>> the exact sub-system.  ("Device X which is/was attached to USB  
>> port Y is
>> no longer functioning, please check the USB ports, the device, the
>> cables and anything else you can think of that may be a cause of
>> failure.")
>
> "Device ${id} which is/was attached to ${protocol} port ${port} is  
> no longer
> functioning, please check the ${protocol} ports, the device, the
> ${protocol_media} and anything else you can think of that may be a  
> cause of
> failure".
>
>>  That just requires an intelligent description of the port.
>
> Agree absolutely.
>
>>> I understand very well that this goes way beyond the scope of  
>>> RxTx and
>>> CommAPI and will require cooperation between them and javax.usb  
>>> and whatever
>>> JSR is responsible for FireWire implementation - but the end  
>>> result is well
>>> worth it. Abstract out and generalize arrival/departure/ 
>>> monitoring/discovery
>>> API, provide protocol specific extensions for each, live happily  
>>> ever after.
>>
>> There's a huge list of pseudo-serial devices each with a different  
>> set
>> of requirements, Bluetooth, RFC 2217, a host of proprietary systems,
>> etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I
>> have no clue how you'd implement them in a general/cross platform  
>> sense.
>
> That's because some of the protocols were created decades ago when
> autoconfiguration wasn't even conceived, much less practical. RS232/ 
> RS485
> don't have a clue about identity discovery, and even capabilities  
> discovery
> beyond obvious 8N1 etc.
>
> I agree that today all these protocols have generally incompatible
> strategies for handling the situations I'm trying to address, but  
> there's
> nothing that says it's not an oversight. Besides, we're dealing  
> with the
> devices at a level of abstraction that allows some simplifications and
> generalizations, at least part of the time - unless it's the protocol
> specific features we're dealing with.
>
>> You haven't convinced me (and only me, others may see something  
>> that I
>> don't, I'm not speaking for them) that this mechanism can be  
>> implemented
>> in any practical sense.  That is, that the implementation could be  
>> wide
>> enough to be consider generally available in RXTX regardless of the
>> serial port implementation, platform, etc..  However, if you can  
>> come up
>> with a general design and a reference implementation for one  
>> subsystem,
>> I'd like to see it and might get on board.
>
> Actually, I wasn't even thinking about all this stuff when I wrote  
> the first
> message on the subject :) Now that you mention it - well, I'm not  
> sure I can
> chew the piece I just tried to bite in reasonable amount of time.
>
> How do you eat an elephant? One bite at a time. If we could agree  
> that a
> small step in the specification is acceptable at this time, and  
> express
> further intentions, things may start happening.
>
> To put it succinctly:
>
> - Concept of a "port" should be augmented with a concept of a  
> "device". A
> device may be attached to a port in an implicit or explicit way.
> - Implicitly connected device is exactly what the current scope of the
> specification covers. No new functionality is offered.
> - Explicitly connected device supports detachable device semantics,  
> just as
> other protocols do (USB, FireWire, Wireless USB, Bluetooth, to  
> mention a
> few).
> - The input and output streams are not properties of a port now, but
> properties of the device attached to the port.
> - A mechanism to allow listening for device arrivals and departures  
> must be
> made available.
>
> That's it, off the top of my head.
>
> I understand that this goes completely against current javax.comm  
> specs, but
> an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern )  
> won't be
> difficult to implement without disrupting javax.comm compatibility.
>
> One concern is how to deal with the device identity - but there's  
> no general
> way of dealing with this at this time, devices may or may not offer  
> identity
> discovery.
>
>> Jim
>
> --vt
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From vt at freehold.crocodile.org  Fri Jun 23 11:28:29 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Fri, 23 Jun 2006 10:28:29 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
	<CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
Message-ID: <20060623172829.GA5335@freehold.crocodile.org>

Hello Joachim,

> I would like to repeat that your request is best addressed to the POSSIX
> standardization group - or maybe the BSD/Linux maintainers. If you
> convince the BSD or Linux guys to add this kind of functionality (they can
> as most of there VCP drivers are open source), there is a certain chance
> that other vendors will pick it up. I assure you that RXTX will happily
> provide this functionality once it's possible - I'm sure there is more
> than one maintainer that would love to add it.

I realize this thing is bigger than RxTx itself, and I'm afraid it's too
global not to cause people to laugh before they think about it :)

> Having this concept penetrate the market may take some years though.

Well, I'm sure it'll get there, the only question is - when.

> SHORT: The solution you would like to see could be added to the API but it
> can not be implemented (at least not on the platforms I know).

I guess I'm concerned about the abstraction more than I'm concerned about
the implementation at this point.
  
> There are currently no hooks in the kernel that allow you to discover  
> "the device" or even the "means of connection" based on an existing  
> "device file descriptor" ie COM-port or /dev/... entry.

Well, I'm not so sure you need to keep the literal mapping from /dev
namespace to your device namespace. As long as you can consistently offer a
virtual serial device on top of a virtual serial port, it may be irrelevant
whether you can map it into /dev. The mapping is going be schitzofrenic
anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the
representation...

> The name mapping of the device is handled by the virtual com port driver
> of the device. Unless you are suggesting RXTX should reimplement virtual
> com port drivers for all usb/serial bridges out there your request is
> understandable from a users viewpoint but simply not realizable.

It's not so much a request but rather an offer of participation. I run a few
projects actively using serial communications, as well as USB device
drivers, in different degrees of readiness (Servomaster, Haywire, DIY
Zoning) - and it would be a perfect playground.

You mentioned above that this task is about two things: a) abstraction b)
implementation. I could start the abstraction part of it without changing
the current CommAPI, on top of it, as an adapter. Even if the removable
device semantics are not implemented, but offered, this is already a step
forward.

> It's like asking that the Socket api should identify the computer behind
> an IP address (ie by its Ethernet address). While this COULD be
> implemented in TCP/IP, it IS not, and hence there is no point adding such
> a function to the Socket API.

Thank you for bringing up this example - I guess this is just about the same
thing that I'd like to see. Socket transparently provides you with the
input/output streams, at the same time offering protocol level specifics to
you.

> The current trend for USB/Bluetooth/Irda/etc connected devices is going
> away from serial port abstraction towards RPC (ie the drivers provide a
> device specific or device class specific driver that provides an
> application level api to the device functions). The line level protocol is
> often not even published.

I can't say I'm that happy with it. The best (or, rather, worst) example is
suchlike support for the Phidget servo controller - zealous Linux developers
implemented kernel module support for it, completely hijacking a possibility
of using it on a different level (it's somewhat fixed by now, thankfully).

I believe that whenever an abstraction is offered, it must be made optional
and/or pluggable so it can be replaced by something more suited to the task.

The nature of Java applications is such that they'd probably care much more
about Java API offered, than about no matter how rich application level api
that is offered outside of Java. I've dealt with JNI adapters in the past,
and whereas they can be made reasonably stable, the very fact that you are
forced to deal with things that are not on the critical timing/memory path
and could've been done much easier in Java causes endless grief.

> Joachim

--vt


From lyon at docjava.com  Sat Jun 24 04:54:12 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Sat, 24 Jun 2006 06:54:12 -0400
Subject: [Rxtx] jsr
In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
	<CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
	<20060623172829.GA5335@freehold.crocodile.org>
Message-ID: <p060204a3c0c2c9dde4f8@[192.168.1.152]>

Hi All,
I have had some off-list discussion with Trent.
Opening up a JSR with Sun, as per Peters' suggestion
seems like a reasonable idea, to us.

Does anyone having any concerns about the JSR process
that they would like to raise?

Thanks!
  - Doug



From the.grey.lantern at gmail.com  Sat Jun 24 18:15:26 2006
From: the.grey.lantern at gmail.com (Craig Nicoll)
Date: Sun, 25 Jun 2006 01:15:26 +0100
Subject: [Rxtx] Cannot create virtual serial port
Message-ID: <a1221cc50606241715g2d1e2af6r747347dd4c20e997@mail.gmail.com>

Hello,

This is my first post on this mailing list and I hope someone can help me.

I am having great difficult establishing a virtual serial port for the
Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia
7600.

Every time I try to run the SendMessage program that comes with SMSLib, I
get the following exception: gnu.io.NoSuchPortException

The port names I have tried are:
rfcomm0
rfcomm
/dev/rfcomm0
/dev/rfcomm

This is what I have done so far:
Modified /etc/bluetooth/rfcomm.conf to include the address of my phone:

rfcomm0 {
# Automatically bind the device at startup
bind no;

# Bluetooth address of the device
device 00:0e:6d:7a:98:43;

# RFCOMM channel for the connection
channel 1;

# Description of the connection
comment "Example Bluetooth device";
}

I also tried running the following command: rfcomm bind /dev/rfcomm0

I have searched the mailing list archives and found this post where someone
had a very similar problem to me:
http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried
changing the system properties as suggested and it made no difference.

I have also been scouring Google all day to no avail.

I would be incredibly grateful if anyone could give me some tips.

Thank you,

Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060625/cfa6df35/attachment-0005.html

From tjarvi at qbang.org  Sun Jun 25 19:56:08 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT)
Subject: [Rxtx] Pending release
Message-ID: <Pine.LNX.4.61.0606251942460.15744@www>


With frustration, I was unable to get to the pending release this weekend.
The release should be comming this next week once things calm down.
The source is in CVS except for a fix for multiple ports in windows.

I had planned on doing the release this weekend but that was disrupted by 
my transportation failing in a spectacular fashion.

--
Trent Jarvi
tjarvi at qbang.org


From Pawan.Kharbanda at dot.state.co.us  Tue Jun 27 22:28:51 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 27 Jun 2006 22:28:51 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>

 Trent, 
   I have an application running in a cluster in linux environment and I
am using RXTX2.1.7 (final) with JDK1.5. The application opens and closes
serial comm ports every 30 seconds and exchanges datas. I have
experienced some of my Comm Ports are left hanging (I can see the
LCK..cufXX lock files under /var/lock folder). On putting the debugs I
found out that, it is stuck at a native call line 809 in RXTXPort.java
class (Please see the code snippet below). Can you help me explain what
this method does in the native code? Am I getting into some thread
deadlocks? Thanks in advance.

Pawan Kharbanda 


public void removeEventListener()
	{
		if (debug)
			z.reportln( "RXTXPort:removeEventListener()
called");
		waitForTheNativeCodeSilly();
		//if( monThread != null && monThread.isAlive() )
		if( monThreadisInterrupted == true )
		{
			z.reportln( "	RXTXPort:removeEventListener()
already interrupted");
			monThread = null;
			SPEventListener = null;
			return;
		}
		else if( monThread != null && monThread.isAlive() )
		{
			if (debug)
				z.reportln( "
RXTXPort:Interrupt=true");
			monThreadisInterrupted=true;
			/*
			   Notify all threads in this PID that something
is up
			   They will call back to see if its their
thread
			   using isInterrupted().
			*/
			if (debug)
				z.reportln( "	RXTXPort:calling
interruptEventLoop");
// LINE 809			interruptEventLoop( ); It never returns
out of this 
			
			if (debug)
				z.reportln( "	RXTXPort:calling
monThread.join()");
			try {
				monThread.join(1000);
			} catch (Exception ex) {
				/* yikes */
				ex.printStackTrace();
			}
			if (debug)
				z.reportln( "	RXTXPort:waiting on
isAlive()");
			while( monThread.isAlive() )
			{
				if ( debug )
					z.reportln( "	MonThread is
still alive!");
				try {
					monThread.join(1000);
					Thread.sleep( 1000 );
				} catch( Exception e ){} 
				//monThread.stop();
			}
			
		}
		if (debug)
			z.reportln( "	RXTXPort:calling gc()");
		monThread = null;
		SPEventListener = null;
		MonitorThreadLock = false;
		MonitorThreadAlive=false;
		monThreadisInterrupted=true;
		z.reportln( "RXTXPort:removeEventListener() returning");
	} 

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Sunday, June 25, 2006 7:56 PM
To: rxtx at qbang.org
Subject: [Rxtx] Pending release


With frustration, I was unable to get to the pending release this
weekend.
The release should be comming this next week once things calm down.
The source is in CVS except for a fix for multiple ports in windows.

I had planned on doing the release this weekend but that was disrupted
by my transportation failing in a spectacular fashion.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Wed Jun 28 04:17:29 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 28 Jun 2006 04:17:29 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606280406330.9561@www>



Hi Pawan

You may have found a deadlock but I've not seen on recently on linux.

If you can, please update from CVS.  This will have some close fixes. 
I'm running with the same code as is in CVS.  It is not perfect but I've 
not seen anything like you mention.  Be sure to set timeouts and 
thresholds on the port.  It may be that the port is waiting on pending io 
that never happens.  I think the CVS patches deal with this also but it 
looks like your in a better test environment to know for sure.

The exploded vehicle mentioned below is expected to be fixed today.  It 
was just a ninja small radiator hose.  The pressure test afterwards 
created its own set of problems.  Until this is resolved, I'm spending 
most of my free time commuting by bicycle.

On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>   I have an application running in a cluster in linux environment and I
> am using RXTX2.1.7 (final) with JDK1.5. The application opens and closes
> serial comm ports every 30 seconds and exchanges datas. I have
> experienced some of my Comm Ports are left hanging (I can see the
> LCK..cufXX lock files under /var/lock folder). On putting the debugs I
> found out that, it is stuck at a native call line 809 in RXTXPort.java
> class (Please see the code snippet below). Can you help me explain what
> this method does in the native code? Am I getting into some thread
> deadlocks? Thanks in advance.
>
> Pawan Kharbanda
>
>
> public void removeEventListener()
> 	{
> 		if (debug)
> 			z.reportln( "RXTXPort:removeEventListener()
> called");
> 		waitForTheNativeCodeSilly();
> 		//if( monThread != null && monThread.isAlive() )
> 		if( monThreadisInterrupted == true )
> 		{
> 			z.reportln( "	RXTXPort:removeEventListener()
> already interrupted");
> 			monThread = null;
> 			SPEventListener = null;
> 			return;
> 		}
> 		else if( monThread != null && monThread.isAlive() )
> 		{
> 			if (debug)
> 				z.reportln( "
> RXTXPort:Interrupt=true");
> 			monThreadisInterrupted=true;
> 			/*
> 			   Notify all threads in this PID that something
> is up
> 			   They will call back to see if its their
> thread
> 			   using isInterrupted().
> 			*/
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> interruptEventLoop");
> // LINE 809			interruptEventLoop( ); It never returns
> out of this
>
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> monThread.join()");
> 			try {
> 				monThread.join(1000);
> 			} catch (Exception ex) {
> 				/* yikes */
> 				ex.printStackTrace();
> 			}
> 			if (debug)
> 				z.reportln( "	RXTXPort:waiting on
> isAlive()");
> 			while( monThread.isAlive() )
> 			{
> 				if ( debug )
> 					z.reportln( "	MonThread is
> still alive!");
> 				try {
> 					monThread.join(1000);
> 					Thread.sleep( 1000 );
> 				} catch( Exception e ){}
> 				//monThread.stop();
> 			}
>
> 		}
> 		if (debug)
> 			z.reportln( "	RXTXPort:calling gc()");
> 		monThread = null;
> 		SPEventListener = null;
> 		MonitorThreadLock = false;
> 		MonitorThreadAlive=false;
> 		monThreadisInterrupted=true;
> 		z.reportln( "RXTXPort:removeEventListener() returning");
> 	}
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Sunday, June 25, 2006 7:56 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] Pending release
>
>
> With frustration, I was unable to get to the pending release this
> weekend.
> The release should be comming this next week once things calm down.
> The source is in CVS except for a fix for multiple ports in windows.
>
> I had planned on doing the release this weekend but that was disrupted
> by my transportation failing in a spectacular fashion.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From Pawan.Kharbanda at dot.state.co.us  Wed Jun 28 12:11:06 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Wed, 28 Jun 2006 12:11:06 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>

Trent,
    Again thanks for the reply. First of all I have Receive timeouts set
on all communications including Max no of bytes to expect during the
call. I have noticed the problem is during "closing the connection". I
am not sure if the RXTX is 100% thread-safe yet. There seems to be a
glitch in the native calls. I am sure I have the latest code I did the
update on the Version 2.1.7 from CVS, is this where the latest updates
are located, I have noticed another version in CVS "rxtx-devel".

Regards
Pawan Kharbanda

    

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Wednesday, June 28, 2006 4:17 AM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports



Hi Pawan

You may have found a deadlock but I've not seen on recently on linux.

If you can, please update from CVS.  This will have some close fixes. 
I'm running with the same code as is in CVS.  It is not perfect but I've
not seen anything like you mention.  Be sure to set timeouts and
thresholds on the port.  It may be that the port is waiting on pending
io that never happens.  I think the CVS patches deal with this also but
it looks like your in a better test environment to know for sure.

The exploded vehicle mentioned below is expected to be fixed today.  It
was just a ninja small radiator hose.  The pressure test afterwards
created its own set of problems.  Until this is resolved, I'm spending
most of my free time commuting by bicycle.

On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>   I have an application running in a cluster in linux environment and 
> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and 
> closes serial comm ports every 30 seconds and exchanges datas. I have 
> experienced some of my Comm Ports are left hanging (I can see the 
> LCK..cufXX lock files under /var/lock folder). On putting the debugs I

> found out that, it is stuck at a native call line 809 in RXTXPort.java

> class (Please see the code snippet below). Can you help me explain 
> what this method does in the native code? Am I getting into some 
> thread deadlocks? Thanks in advance.
>
> Pawan Kharbanda
>
>
> public void removeEventListener()
> 	{
> 		if (debug)
> 			z.reportln( "RXTXPort:removeEventListener()
called");
> 		waitForTheNativeCodeSilly();
> 		//if( monThread != null && monThread.isAlive() )
> 		if( monThreadisInterrupted == true )
> 		{
> 			z.reportln( "	RXTXPort:removeEventListener()
> already interrupted");
> 			monThread = null;
> 			SPEventListener = null;
> 			return;
> 		}
> 		else if( monThread != null && monThread.isAlive() )
> 		{
> 			if (debug)
> 				z.reportln( "
> RXTXPort:Interrupt=true");
> 			monThreadisInterrupted=true;
> 			/*
> 			   Notify all threads in this PID that something
is up
> 			   They will call back to see if its their
thread
> 			   using isInterrupted().
> 			*/
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> interruptEventLoop");
> // LINE 809			interruptEventLoop( ); It never returns
> out of this
>
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> monThread.join()");
> 			try {
> 				monThread.join(1000);
> 			} catch (Exception ex) {
> 				/* yikes */
> 				ex.printStackTrace();
> 			}
> 			if (debug)
> 				z.reportln( "	RXTXPort:waiting on
> isAlive()");
> 			while( monThread.isAlive() )
> 			{
> 				if ( debug )
> 					z.reportln( "	MonThread is
> still alive!");
> 				try {
> 					monThread.join(1000);
> 					Thread.sleep( 1000 );
> 				} catch( Exception e ){}
> 				//monThread.stop();
> 			}
>
> 		}
> 		if (debug)
> 			z.reportln( "	RXTXPort:calling gc()");
> 		monThread = null;
> 		SPEventListener = null;
> 		MonitorThreadLock = false;
> 		MonitorThreadAlive=false;
> 		monThreadisInterrupted=true;
> 		z.reportln( "RXTXPort:removeEventListener() returning");
> 	}
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf

> Of Trent Jarvi
> Sent: Sunday, June 25, 2006 7:56 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] Pending release
>
>
> With frustration, I was unable to get to the pending release this 
> weekend.
> The release should be comming this next week once things calm down.
> The source is in CVS except for a fix for multiple ports in windows.
>
> I had planned on doing the release this weekend but that was disrupted

> by my transportation failing in a spectacular fashion.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Wed Jun 28 12:26:21 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 28 Jun 2006 12:26:21 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606281222420.9561@www>


Hi Pawan

If you did a cvs update from the 2.1-7 tar ball, you have the current 
version.  All rxtx in CVS is under rxtx-devel.  The 2.1-7 just has -r
commapi-0-0-1.

You may well have found something.  I have seen win32 fail on closing 
ports but not linux that I can think of.  Your use is much different than 
I normally see too.

Could you give us more information on how we would reproduce this and the 
frequency?


On Wed, 28 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>    Again thanks for the reply. First of all I have Receive timeouts set
> on all communications including Max no of bytes to expect during the
> call. I have noticed the problem is during "closing the connection". I
> am not sure if the RXTX is 100% thread-safe yet. There seems to be a
> glitch in the native calls. I am sure I have the latest code I did the
> update on the Version 2.1.7 from CVS, is this where the latest updates
> are located, I have noticed another version in CVS "rxtx-devel".
>
> Regards
> Pawan Kharbanda
>
>
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Wednesday, June 28, 2006 4:17 AM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] Locked Ports
>
>
>
> Hi Pawan
>
> You may have found a deadlock but I've not seen on recently on linux.
>
> If you can, please update from CVS.  This will have some close fixes.
> I'm running with the same code as is in CVS.  It is not perfect but I've
> not seen anything like you mention.  Be sure to set timeouts and
> thresholds on the port.  It may be that the port is waiting on pending
> io that never happens.  I think the CVS patches deal with this also but
> it looks like your in a better test environment to know for sure.
>
> The exploded vehicle mentioned below is expected to be fixed today.  It
> was just a ninja small radiator hose.  The pressure test afterwards
> created its own set of problems.  Until this is resolved, I'm spending
> most of my free time commuting by bicycle.
>
> On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:
>
>> Trent,
>>   I have an application running in a cluster in linux environment and
>> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and
>> closes serial comm ports every 30 seconds and exchanges datas. I have
>> experienced some of my Comm Ports are left hanging (I can see the
>> LCK..cufXX lock files under /var/lock folder). On putting the debugs I
>
>> found out that, it is stuck at a native call line 809 in RXTXPort.java
>
>> class (Please see the code snippet below). Can you help me explain
>> what this method does in the native code? Am I getting into some
>> thread deadlocks? Thanks in advance.
>>
>> Pawan Kharbanda
>>
>>
>> public void removeEventListener()
>> 	{
>> 		if (debug)
>> 			z.reportln( "RXTXPort:removeEventListener()
> called");
>> 		waitForTheNativeCodeSilly();
>> 		//if( monThread != null && monThread.isAlive() )
>> 		if( monThreadisInterrupted == true )
>> 		{
>> 			z.reportln( "	RXTXPort:removeEventListener()
>> already interrupted");
>> 			monThread = null;
>> 			SPEventListener = null;
>> 			return;
>> 		}
>> 		else if( monThread != null && monThread.isAlive() )
>> 		{
>> 			if (debug)
>> 				z.reportln( "
>> RXTXPort:Interrupt=true");
>> 			monThreadisInterrupted=true;
>> 			/*
>> 			   Notify all threads in this PID that something
> is up
>> 			   They will call back to see if its their
> thread
>> 			   using isInterrupted().
>> 			*/
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> interruptEventLoop");
>> // LINE 809			interruptEventLoop( ); It never returns
>> out of this
>>
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> monThread.join()");
>> 			try {
>> 				monThread.join(1000);
>> 			} catch (Exception ex) {
>> 				/* yikes */
>> 				ex.printStackTrace();
>> 			}
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:waiting on
>> isAlive()");
>> 			while( monThread.isAlive() )
>> 			{
>> 				if ( debug )
>> 					z.reportln( "	MonThread is
>> still alive!");
>> 				try {
>> 					monThread.join(1000);
>> 					Thread.sleep( 1000 );
>> 				} catch( Exception e ){}
>> 				//monThread.stop();
>> 			}
>>
>> 		}
>> 		if (debug)
>> 			z.reportln( "	RXTXPort:calling gc()");
>> 		monThread = null;
>> 		SPEventListener = null;
>> 		MonitorThreadLock = false;
>> 		MonitorThreadAlive=false;
>> 		monThreadisInterrupted=true;
>> 		z.reportln( "RXTXPort:removeEventListener() returning");
>> 	}
>>
>> -----Original Message-----
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
>
>> Of Trent Jarvi
>> Sent: Sunday, June 25, 2006 7:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] Pending release
>>
>>
>> With frustration, I was unable to get to the pending release this
>> weekend.
>> The release should be comming this next week once things calm down.
>> The source is in CVS except for a fix for multiple ports in windows.
>>
>> I had planned on doing the release this weekend but that was disrupted
>
>> by my transportation failing in a spectacular fashion.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From Pawan.Kharbanda at dot.state.co.us  Wed Jun 28 15:42:49 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Wed, 28 Jun 2006 15:42:49 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>

Trent,
    I will try to explain how I am setup and will try to write you a
Sample code little later to reproduce this. On our system we have
DigiBoxes installed on the 2 Linux servers. Both of them have RXTX2.1-7
version installed with the JRE(1.5) and both the machines have the same
port mappings in gnu.io.rxtx.properties (Currently in the production
system I have 64 ports). This is how the system works:

1) A thick Map based client initiates a Action on the Device on the
field. One of the Thread Workers(Asynchronous Call) in the Cluster picks
up the request. 
2) Once the worker gets the request it locks the Device and
Communication port in the DB's(These are our persistent locks, because
most of the devices do one to one communication with the serial ports).
After that the worker (or Comm Server) opens up the connection and after
exchanging the information calls the "Close" and returns.
3) Once the connection is closed , the DB lock is removed on the comm
port and is made available to accept future calls. Here is where the
glitch is the Serial Comm Close method never returns due to the
deadlock. 

I have noticed that the deadlocks are very inconsistent, sometime it
happens right away as soon as Application server starts and sometimes I
don't see any deadlocks for days, but it happens for sure. 

Here is how you can test if you have resources/ test environment. Write
a program and try to open/close  different ports(I will say have a
minimum of four) randomly and very frequently(may be 30 seconds), I am
pretty sure you will see the deadlocks and it happens in the native call
to interrptEventLoop in RXTXPort.java in removeEventListener() method
call.

Also I have noticed that the JVM carshes (without any memrory errors or
JVM errors. Its just not there) when native call is made to eventLoop()
in run() method in MonitorThread inner class. I am still investigating
why this is happening, but at this point I can just tell you the
location. You might have a question How I am so sure about the location?
My application is configured with Log4J and I have enabled the debugs on
the RXTXPort.java, so every time my JVM dies I see these logs at the end
of the file.

"2006-06-28 15:27:15,183 INFO  [STDOUT] RXTXPort:RXTXPort(/dev/cub01)
called
2006-06-28 15:27:15,218 INFO  [STDOUT]
RXTXPort:MontitorThread:MonitorThread()
2006-06-28 15:27:15,219 INFO  [STDOUT] RXTXPort:MontitorThread:run()"

I surely do have a luxury of a testing environment(ports, devices etc.)
and can help you fix these problems? Please advise me how we can resolve
these issues.

Thanks 
Pawan Kharbanda
303-478-2991





-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Wednesday, June 28, 2006 12:26 PM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports


Hi Pawan

If you did a cvs update from the 2.1-7 tar ball, you have the current
version.  All rxtx in CVS is under rxtx-devel.  The 2.1-7 just has -r
commapi-0-0-1.

You may well have found something.  I have seen win32 fail on closing
ports but not linux that I can think of.  Your use is much different
than I normally see too.

Could you give us more information on how we would reproduce this and
the frequency?


On Wed, 28 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>    Again thanks for the reply. First of all I have Receive timeouts
set
> on all communications including Max no of bytes to expect during the
> call. I have noticed the problem is during "closing the connection". I
> am not sure if the RXTX is 100% thread-safe yet. There seems to be a
> glitch in the native calls. I am sure I have the latest code I did the
> update on the Version 2.1.7 from CVS, is this where the latest updates
> are located, I have noticed another version in CVS "rxtx-devel".
>
> Regards
> Pawan Kharbanda
>
>
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Wednesday, June 28, 2006 4:17 AM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] Locked Ports
>
>
>
> Hi Pawan
>
> You may have found a deadlock but I've not seen on recently on linux.
>
> If you can, please update from CVS.  This will have some close fixes.
> I'm running with the same code as is in CVS.  It is not perfect but
I've
> not seen anything like you mention.  Be sure to set timeouts and
> thresholds on the port.  It may be that the port is waiting on pending
> io that never happens.  I think the CVS patches deal with this also
but
> it looks like your in a better test environment to know for sure.
>
> The exploded vehicle mentioned below is expected to be fixed today.
It
> was just a ninja small radiator hose.  The pressure test afterwards
> created its own set of problems.  Until this is resolved, I'm spending
> most of my free time commuting by bicycle.
>
> On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:
>
>> Trent,
>>   I have an application running in a cluster in linux environment and
>> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and
>> closes serial comm ports every 30 seconds and exchanges datas. I have
>> experienced some of my Comm Ports are left hanging (I can see the
>> LCK..cufXX lock files under /var/lock folder). On putting the debugs
I
>
>> found out that, it is stuck at a native call line 809 in
RXTXPort.java
>
>> class (Please see the code snippet below). Can you help me explain
>> what this method does in the native code? Am I getting into some
>> thread deadlocks? Thanks in advance.
>>
>> Pawan Kharbanda
>>
>>
>> public void removeEventListener()
>> 	{
>> 		if (debug)
>> 			z.reportln( "RXTXPort:removeEventListener()
> called");
>> 		waitForTheNativeCodeSilly();
>> 		//if( monThread != null && monThread.isAlive() )
>> 		if( monThreadisInterrupted == true )
>> 		{
>> 			z.reportln( "	RXTXPort:removeEventListener()
>> already interrupted");
>> 			monThread = null;
>> 			SPEventListener = null;
>> 			return;
>> 		}
>> 		else if( monThread != null && monThread.isAlive() )
>> 		{
>> 			if (debug)
>> 				z.reportln( "
>> RXTXPort:Interrupt=true");
>> 			monThreadisInterrupted=true;
>> 			/*
>> 			   Notify all threads in this PID that something
> is up
>> 			   They will call back to see if its their
> thread
>> 			   using isInterrupted().
>> 			*/
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> interruptEventLoop");
>> // LINE 809			interruptEventLoop( ); It never returns
>> out of this
>>
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> monThread.join()");
>> 			try {
>> 				monThread.join(1000);
>> 			} catch (Exception ex) {
>> 				/* yikes */
>> 				ex.printStackTrace();
>> 			}
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:waiting on
>> isAlive()");
>> 			while( monThread.isAlive() )
>> 			{
>> 				if ( debug )
>> 					z.reportln( "	MonThread is
>> still alive!");
>> 				try {
>> 					monThread.join(1000);
>> 					Thread.sleep( 1000 );
>> 				} catch( Exception e ){}
>> 				//monThread.stop();
>> 			}
>>
>> 		}
>> 		if (debug)
>> 			z.reportln( "	RXTXPort:calling gc()");
>> 		monThread = null;
>> 		SPEventListener = null;
>> 		MonitorThreadLock = false;
>> 		MonitorThreadAlive=false;
>> 		monThreadisInterrupted=true;
>> 		z.reportln( "RXTXPort:removeEventListener() returning");
>> 	}
>>
>> -----Original Message-----
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On
Behalf
>
>> Of Trent Jarvi
>> Sent: Sunday, June 25, 2006 7:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] Pending release
>>
>>
>> With frustration, I was unable to get to the pending release this
>> weekend.
>> The release should be comming this next week once things calm down.
>> The source is in CVS except for a fix for multiple ports in windows.
>>
>> I had planned on doing the release this weekend but that was
disrupted
>
>> by my transportation failing in a spectacular fashion.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx 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 khattar31 at yahoo.com  Wed Jun 28 22:04:59 2006
From: khattar31 at yahoo.com (rahul khattar)
Date: Wed, 28 Jun 2006 21:04:59 -0700 (PDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
Message-ID: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>

Hi All,

I was looking at the src file on the last release.
I did notice a missing header file while trying to
compile the parallelport.dll. Would somebody be kind
enoughf to share the missing header file:
gnu_io_LPRPort.h

I am using MinGw to compile the same from Parinya
(which is an execellent tool)


Regards,
Rahul Khattar

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Thu Jun 29 03:43:53 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 03:43:53 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>
References: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606290341210.9561@www>

On Wed, 28 Jun 2006, rahul khattar wrote:

> Hi All,
>
> I was looking at the src file on the last release.
> I did notice a missing header file while trying to
> compile the parallelport.dll. Would somebody be kind
> enoughf to share the missing header file:
> gnu_io_LPRPort.h
>
> I am using MinGw to compile the same from Parinya
> (which is an execellent tool)
>

Hi Rahul

The gnu.io_LPRPort.h file is generated with javah.  You can see the 
command in the Makefile I presume.  You do not need rxtxParallel.dll to 
use w32 serial btw.

--
Trent Jarvi
tjarvi at qbang.org


From khattar31 at yahoo.com  Thu Jun 29 04:47:01 2006
From: khattar31 at yahoo.com (rahul khattar)
Date: Thu, 29 Jun 2006 03:47:01 -0700 (PDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606290341210.9561@www>
Message-ID: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>

Hi Trent 
I did notice this file is required in the source file
ParallelImp.c
on line 38

Attached the O/P 

Regards,
Rahul Khattar




--- Trent Jarvi <tjarvi at qbang.org> wrote:

> On Wed, 28 Jun 2006, rahul khattar wrote:
> 
> > Hi All,
> >
> > I was looking at the src file on the last release.
> > I did notice a missing header file while trying to
> > compile the parallelport.dll. Would somebody be
> kind
> > enoughf to share the missing header file:
> > gnu_io_LPRPort.h
> >
> > I am using MinGw to compile the same from Parinya
> > (which is an execellent tool)
> >
> 
> Hi Rahul
> 
> The gnu.io_LPRPort.h file is generated with javah. 
> You can see the 
> command in the Makefile I presume.  You do not need
> rxtxParallel.dll to 
> use w32 serial btw.
> 
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Error.zip
Type: application/x-zip-compressed
Size: 1746 bytes
Desc: 2948039066-Error.zip
Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060629/a5b6f783/Error-0014.bin

From tjarvi at qbang.org  Thu Jun 29 06:16:24 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 06:16:24 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606290614530.9561@www>

On Thu, 29 Jun 2006, rahul khattar wrote:

> Hi Trent
> I did notice this file is required in the source file
> ParallelImp.c
> on line 38
>
> Attached the O/P
>

The command to generate the .h file will be something like:

javah -classpath . -jni gnu.io.LPRPort

The makefile should have this.  There are several approaches to creating 
or using makefiles so I have no idea which one you used if any.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Thu Jun 29 06:20:51 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 06:20:51 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606290616420.9561@www>

> Here is how you can test if you have resources/ test environment. Write
> a program and try to open/close  different ports(I will say have a
> minimum of four) randomly and very frequently(may be 30 seconds), I am
> pretty sure you will see the deadlocks and it happens in the native call
> to interrptEventLoop in RXTXPort.java in removeEventListener() method
> call.

Hi Pawan

I'll try to find a way to reproduce this.  One thing to note is that you 
are using different kernel drivers (digi) to perform this task.  So I 
probably will not be able to reproduce the exact same environment.

In general, multiport kernel drivers have been tested far less than 
typical serial drivers.  This may or may not be an issue.

--
Trent Jarvi
tjarvi at qbang.org



From jhaysonn at gmail.com  Thu Jun 29 12:29:13 2006
From: jhaysonn at gmail.com (jhaysonn pathak)
Date: Thu, 29 Jun 2006 14:29:13 -0400
Subject: [Rxtx] RXTX install
Message-ID: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>

Hi Guys,

I'm doing trying to write a generative piece of Sonic Art using an EEG
plugged into a mac runnning Max/MSP.  I just recently discovered RXTX
drivers in my search for a piece of software that might give me more
output options for my EEG (I'm using the CEO from MindPeak).  I found
Bioera which uses RXTX drivers.  Thing is - I can't figure out how to
install RXTX correctly.

After I build the 'libSerial.jnilib' target inside of
'LibSerial.pbproj' I can't find the libSerial.jnilib file that
accompanies the RXTXcomm.jar nor do I know where to put them.

I also don't understand this part at the bottom of the OS X instructions at all:

"AFTER INSTALLATION VERY IMPORTANT
	check existence of the folder /var/spool/uucp
	if you don't have it create it with command
	sudo mkdir /var/spool/uucp
	permissions should be: drwxrwxr-x
	if they are not do command
	sudo chmod 775 /var/spool/uucp

	YOU should be a member of the uucp group
	you can check it with command
		niutil -readprop / /groups/uucp users
	you should see your name in output of the niutil command
	if you don't do following:
		sudo niutil -appendprop / /groups/uucp users <yourname>
			substitute  <yourname> with your user's name
			for example if your user name is peter:
				sudo niutil -appendprop / /groups/uucp users peter

	NOTES: RXTX.pkg should create uucp folder and insert your name  in
uucp group automatically"



I really appreciate any help that you guys can offer.  I've been
struggling with this for a while now as part of a research grant that
I was awarded.  Thanks again for the help.

Jhaysonn Pathak


From naranjo.manuel at gmail.com  Thu Jun 29 07:19:15 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 10:19:15 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606290614530.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www>
Message-ID: <44A3D353.6010605@gmail.com>

Speaking about Windows Support, I had seen that inside the 
rxtx-2.1-7-bins-r2 package inside Windows directory it says:
"i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will 
not make harm to anyone, and i'm almost sure that someone has noticed it 
before.
Cheers,
Manuel


From joachim at buechse.de  Thu Jun 29 13:25:16 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 29 Jun 2006 21:25:16 +0200
Subject: [Rxtx] RXTX install
In-Reply-To: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>
References: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>
Message-ID: <2A003E42-97E1-4237-8438-646BDE2E3961@buechse.de>

Hello Jhaysonn,

I assume you are trying to use the javax.comm version of RXTX.

Please use "cvs up" to update your download to the latest version of  
the repository. The latest version does not use lock files, so the  
mentioned process is no longer needed. Updating with CVS will also  
provide you with a new README.OSX file that should be simpler to  
understand.

You will find LibSerialUniversal.xcodeproj in MACOSX_IDE/Xcode. Put  
comm.jar (downloaded from Sun) into MACOSX_IDE/Xcode. Compile the  
library. You will find RXTXcomm.jar and librxtxSerial.jnilib in  
MACOSX_IDE/Xcode/build/Default

Best regards,
Joachim
---
Joachim B?chse
Softwarel?sungen und Beratung
Hadlaubsteig 2
CH-8006 Z?rich


On 29.06.2006, at 20:29, jhaysonn pathak wrote:

> Hi Guys,
>
> I'm doing trying to write a generative piece of Sonic Art using an EEG
> plugged into a mac runnning Max/MSP.  I just recently discovered RXTX
> drivers in my search for a piece of software that might give me more
> output options for my EEG (I'm using the CEO from MindPeak).  I found
> Bioera which uses RXTX drivers.  Thing is - I can't figure out how to
> install RXTX correctly.
>
> After I build the 'libSerial.jnilib' target inside of
> 'LibSerial.pbproj' I can't find the libSerial.jnilib file that
> accompanies the RXTXcomm.jar nor do I know where to put them.
>
> I also don't understand this part at the bottom of the OS X  
> instructions at all:
>
> "AFTER INSTALLATION VERY IMPORTANT
> 	check existence of the folder /var/spool/uucp
> 	if you don't have it create it with command
> 	sudo mkdir /var/spool/uucp
> 	permissions should be: drwxrwxr-x
> 	if they are not do command
> 	sudo chmod 775 /var/spool/uucp
>
> 	YOU should be a member of the uucp group
> 	you can check it with command
> 		niutil -readprop / /groups/uucp users
> 	you should see your name in output of the niutil command
> 	if you don't do following:
> 		sudo niutil -appendprop / /groups/uucp users <yourname>
> 			substitute  <yourname> with your user's name
> 			for example if your user name is peter:
> 				sudo niutil -appendprop / /groups/uucp users peter
>
> 	NOTES: RXTX.pkg should create uucp folder and insert your name  in
> uucp group automatically"
>
>
>
> I really appreciate any help that you guys can offer.  I've been
> struggling with this for a while now as part of a research grant that
> I was awarded.  Thanks again for the help.
>
> Jhaysonn Pathak
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From tjarvi at qbang.org  Thu Jun 29 19:30:00 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 19:30:00 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A3D353.6010605@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
Message-ID: <Pine.LNX.4.61.0606291923000.9561@www>

On Thu, 29 Jun 2006, Manuel Naranjo wrote:

> Speaking about Windows Support, I had seen that inside the
> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
> not make harm to anyone, and i'm almost sure that someone has noticed it
> before.

Hi Manuel

         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
     47421  01-30-06 00:23 
rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
     77759  03-01-06 12:01 
rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README


It looks normal to me.  There are no fancy tools used there :)

--
Trent Jarvi
tjarvi at qbang.org

From naranjo.manuel at gmail.com  Thu Jun 29 19:38:16 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 22:38:16 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606291923000.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com> <Pine.LNX.4.61.0606291923000.9561@www>
Message-ID: <44A48088.2040407@gmail.com>

> On Thu, 29 Jun 2006, Manuel Naranjo wrote:
> 
>> Speaking about Windows Support, I had seen that inside the
>> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
>> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
>> not make harm to anyone, and i'm almost sure that someone has noticed it
>> before.
> 
> Hi Manuel
> 
>         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
>         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
>     47421  01-30-06 00:23 
> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
>     77759  03-01-06 12:01 
> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
>       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README
> 
> 
> It looks normal to me.  There are no fancy tools used there :)
> 
Hi Trent:
Is not the i368 representing the name of the Architecture?? If so the 
name should start with i386 it will not break any system, is simply miss
written, I saw that and wanted to report it. It a silly thing.
Ohh I forgoten I must congratulate you for your GREAT libray, I was able 
to make an .exe with JSmooth that launches an application that uses RXTX 
with out the need to install RXTX on users system :). The .exe tells JVM 
where to find the RXTX Library and Binaries. I tried with Sun's Java 
Comm but it was imposible.
Regards,
Manuel


From tjarvi at qbang.org  Thu Jun 29 19:52:45 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 19:52:45 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A48088.2040407@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
	<Pine.LNX.4.61.0606291923000.9561@www> <44A48088.2040407@gmail.com>
Message-ID: <Pine.LNX.4.61.0606291945060.9561@www>

On Thu, 29 Jun 2006, Manuel Naranjo wrote:

>> On Thu, 29 Jun 2006, Manuel Naranjo wrote:
>>
>>> Speaking about Windows Support, I had seen that inside the
>>> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
>>> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
>>> not make harm to anyone, and i'm almost sure that someone has noticed it
>>> before.
>>
>> Hi Manuel
>>
>>         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
>>         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
>>     47421  01-30-06 00:23
>> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
>>     77759  03-01-06 12:01
>> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
>>       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README
>>
>>
>> It looks normal to me.  There are no fancy tools used there :)
>>
> Hi Trent:
> Is not the i368 representing the name of the Architecture?? If so the
> name should start with i386 it will not break any system, is simply miss
> written, I saw that and wanted to report it. It a silly thing.
> Ohh I forgoten I must congratulate you for your GREAT libray, I was able
> to make an .exe with JSmooth that launches an application that uses RXTX
> with out the need to install RXTX on users system :). The .exe tells JVM
> where to find the RXTX Library and Binaries. I tried with Sun's Java
> Comm but it was imposible.

Hi Manuel

The compiler uses only the i386 instruction set for windows.  I doubt 
there will be any measurable advantages with going to later instruction 
sets.  In theory rxtx would run on a 386 but I doubt anyone does that.

So it looks odd but is not a typo.

We could compile to i686 but don't.  The compiler used does not appear to 
be a problem yet so I don't see any point in changing it.  Right now, we 
could not compile 64 bit windows binaries.  gcc/mingw/... do not support 
them that I know of.  People will have to compile those with closed source 
tools on their own until an option is available.

--
Trent Jarvi
tjarvi at qbang.org

From naranjo.manuel at gmail.com  Thu Jun 29 20:00:48 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 23:00:48 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606291945060.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com>	<Pine.LNX.4.61.0606291923000.9561@www>
	<44A48088.2040407@gmail.com> <Pine.LNX.4.61.0606291945060.9561@www>
Message-ID: <44A485D0.7050202@gmail.com>

Trent you did not get my point
The folder says 368 three hundred sixty eight, when
it should say 386 three hundred eighty six. Is simply a miss writting.
Regards,
Manuel


From tjarvi at qbang.org  Thu Jun 29 20:12:15 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 20:12:15 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A485D0.7050202@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
	<Pine.LNX.4.61.0606291923000.9561@www> <44A48088.2040407@gmail.com>
	<Pine.LNX.4.61.0606291945060.9561@www> <44A485D0.7050202@gmail.com>
Message-ID: <Pine.LNX.4.61.0606292008061.9561@www>


On Thu, 29 Jun 2006, Manuel Naranjo wrote:

> Trent you did not get my point
> The folder says 368 three hundred sixty eight, when
> it should say 386 three hundred eighty six. Is simply a miss writting.

hehe..  OK.  My bad.  It's been a long day.

Nevermind :)

--
Trent Jarvi
tjarvi at qbang.org




From naranjo.manuel at gmail.com  Thu Jun 29 20:18:44 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 23:18:44 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606292008061.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com>	<Pine.LNX.4.61.0606291923000.9561@www>
	<44A48088.2040407@gmail.com>	<Pine.LNX.4.61.0606291945060.9561@www>
	<44A485D0.7050202@gmail.com> <Pine.LNX.4.61.0606292008061.9561@www>
Message-ID: <44A48A04.9040401@gmail.com>

Don't worry Trent.
About 64 bits compilation, I would like to colaborate, I have a Pc with 
64 bits, the only problem is that i do not have windows 64 bits 
installed :(.




From Pawan.Kharbanda at dot.state.co.us  Fri Jun 30 08:49:52 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 30 Jun 2006 08:49:52 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E996@hqexchange3.dot.state.co.us>

Trent,  
    Can you explain what the interruptedEventLoop() native method is
doing is there a possibility that method is somehow getting into the
infinite loop(there are 2 while loops without any break statements).
This might be a very basic question how can I debug the native code(or
print the debug statements).  Again thanks for the help. 

Pawan Kharbanda

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Thursday, June 29, 2006 6:21 AM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports

> Here is how you can test if you have resources/ test environment. 
> Write a program and try to open/close  different ports(I will say have

> a minimum of four) randomly and very frequently(may be 30 seconds), I 
> am pretty sure you will see the deadlocks and it happens in the native

> call to interrptEventLoop in RXTXPort.java in removeEventListener() 
> method call.

Hi Pawan

I'll try to find a way to reproduce this.  One thing to note is that you
are using different kernel drivers (digi) to perform this task.  So I
probably will not be able to reproduce the exact same environment.

In general, multiport kernel drivers have been tested far less than
typical serial drivers.  This may or may not be an issue.

--
Trent Jarvi
tjarvi at qbang.org

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From cpine at wrsystems.com  Thu Jun 29 15:17:12 2006
From: cpine at wrsystems.com (Chris Pine)
Date: Thu, 29 Jun 2006 17:17:12 -0400
Subject: [Rxtx]  Controlling Individual Signals DTR and RTS
Message-ID: <MAIL4FJo0S8ACLEBajJ000005cf@mail4.wrsystems.com>

Dear Moussa Ba,
	I hope I am not being too forward, but we are having the exact same
issue with needing to control DTR from RXTX in Linux.  Did you ever have any
luck figuring it out?

Thank you very much for your time,

Chris Pine




From tjarvi at qbang.org  Thu Jun  1 11:13:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 11:13:40 -0600 (MDT)
Subject: [Rxtx] custom baud rate win32
In-Reply-To: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606011107210.30220@www>


Hi Daren

I can't imagine that 1953 is possibly the actual value on the UART.  Maybe 
if your baud base is very high with a custom serial board.  More likely, 
the driver just remembers that what you asked for and did something else.

I'll have more to say on the dcb->BaudRate after I try some things here. 
I have managed to do something like that in the past as a quick hack but 
it was for 14400.  I may have used the CBR_14400.

If we can't access this through the win32 API with protected mode, there 
is another layer of complication.  With real mode, it would be easy.
With protected mode, I assume there would have to be some kernel driver or 
a hook I'm not aware of to access the MCR directly (bang a memory 
addresss).



On Thu, 1 Jun 2006, Daren wrote:

> Trent,
> I have managed to successfully open the port at this speed using Realterm
> (available on sourceforge). From memory this uses DLPortIO.
>
> Using portmon.exe with realterm, even there it says that the port has opened
> at 1953.
>
> I changed termios.c:560 to
> dcb->BaudRate        = 1953 ;
>
> and it still opens the port at 9600.
>
> Daren
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Trent Jarvi
> Sent: Thursday, 1 June 2006 1:44 PM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] custom baud rate win32
>
> On Thu, 1 Jun 2006, Daren wrote:
>
>> Hi all,
>>
>> I downloaded 2.1.7-pre16 and managed to build it and get it going. I made
>> the changes as suggested by Peter Smith in an old post, by adding his code
>> to SerialImpl.c, uncommenting the TIOCGSERIAL and TIOCSSERIAL, and
> defining
>> ASYNC_SPD_CUST which is equal to 0x0030 (according to linus header
> files)..
>>
>>
>> Still not working, it opens the port at 9600 according to portmon.exe .
> Has
>> anyone managed to get this going at a custom rate?
>>
>> Here is the post I'm referring to:
>> http://marc.theaimsgroup.com/?l=rxtx&m=106270038110713&w=2
>>
>>
>> Thanks,
>> Daren
>>
>> ________________________________________
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
>> Daren
>> Sent: Wednesday, 31 May 2006 10:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] (no subject)
>>
>> Hi All,
>> I have been using rxtx for a little while and needed to get it working at
>> 1953, like a past user in the mailing list, who seemed to have got it
>> working by changing some C code.
>>
>> I wanted to build rxtx myself with these changes but don't know where to
>> start. I have windows here and FC4 at home. I downloaded cygwin and
> mingw32,
>> each build works by building a rxtxSerial.dll file that is ~11k smaller
> than
>> the original, and I always get the following error when testing the dll:
>>
>> Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at
>> PC=0x8077655
>> Function=[Unknown.]
>> Library=C:\opt\java\j2sdk1.4.2\jre\bin\client\jvm.dll
>>
>> NOTE: We are unable to locate the function name symbol for the error
>>      just occurred. Please refer to release documentation for possible
>>      reason and solutions.
>>
>>
>> Current Java thread:
>> 	at gnu.io.RXTXPort.open(Native Method)
>> 	- locked <0x1002c800> (a gnu.io.RXTXPort)
>> 	at gnu.io.RXTXPort.<init>(RXTXPort.java:84)
>>
>> Anyone know what im doing wrong?
>>
>>
>>
>>
>
> Hi Daren
>
> You are running into the same rats nest I'm looking at now.
>
> With win32 and specific custom baud rates, I'm not sure how this will go.
> I've got the Linux custom baud rates working very nicely.  I did much like
> the post you linked.  In fact I had forgot about that post.  You probably
> noticed that it becomes a bunch of dirt roads going noplace fast in
> termios.c for w32.
>
> I'm probably only going to get 14400, 28800, 128000 and 256000 working
> with the next release on w32.  I'll look a little further.  If you have an
> example w32 that works at 1953 I'd really like to hear.  Thats an unusual
> baud rate.
>
> Assuming a baud_base of 128000, your divisor will be 65 or 66.
>
> 128000/66=1939 -14
> 128000/65=1969 +13
>
> One thing I've been wondering about with linux is which would be the right
> answer in cases like this.  Right now it would just go with a baud base of
> 65 and ignore the modulus details.
>
> It appears to be a general trend for kernel developers to hide these
> details thinking that they can come up with a general solution.  Then they
> run out of time.  Perahps the solution is to help out but there are
> ultiple OS's rxtx supports making that nontrivial.
>
> If you look at current linux kernels, the 'tricks' above have been marked
> deprecated with no replacement.  Windows has some hard defines and then
> ancient near magic.  I've not looked at Solaris via Open Solaris yet but
> doubt there is a solution at all.
>
> What I'd try since you have the equipment and the monitor software is to
> hardcode the dcb->Baud in termios.c to 1953 (no define) and see what the
> w32 kernel does with it.  I think if you toss a baud rate at the driver it
> will try to come close.  You may try comming closer to a real baudrate
> based upon the 128000 baud base as shown above.
>
> If it works, it is worth looking at the rest of the ping/pong logic then.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
>
>
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From doug at dupreeinc.com  Thu Jun  1 13:22:13 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 12:22:13 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011107210.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
Message-ID: <447F3E65.1020809@dupreeinc.com>

Hello,

I am still trying to get this startup a little faster so I turned on the 
debug of a few of the classes.  The COM ports are scanned really fast 
and the delay occurs during the LPT scan.  The console output looks like 
this:

    ...
      LPT1
      LPT2
      LPT3
     valid port prefixes:
      LPT
    LPT1 LPT
    1 1
    LPT2 LPT
    2 2                                                                 
      * <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
    CommPortIdentifier:addPortName(LPT2)
    CommPortIdentifier:AddIdentifierToList()
    LPT3 LPT
    3 3
    CommPortIdentifier:addPortName(LPT3)
    CommPortIdentifier:AddIdentifierToList()
    CommPortIdentifier:AddIdentifierToList() index.next
    Leaving registerValidPorts()
    Have not implemented native_psmisc_report_owner(PortName)); in
    CommPortIdentifier
    CommPortIdentifier:getPortIdentifier(COM3)
    CommPortIdentifier:open(densConnect, 30000)
    RXTXCommDriver:getCommPort(COM3,1)
    ...

It would seem to me that if I removed the code for port scanning of LPT 
ports I could solve this problem. I would much prefer to use unmodified 
code if at all possible.  Do any of you have alternate suggestions?

Thank you for your time.

Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/cf433ee7/attachment-0015.html

From tjarvi at qbang.org  Thu Jun  1 13:52:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 13:52:06 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F3E65.1020809@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011348380.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I am still trying to get this startup a little faster so I turned on the 
> debug of a few of the classes.  The COM ports are scanned really fast and the 
> delay occurs during the LPT scan.  The console output looks like this:
>
>   ...
>     LPT1
>     LPT2
>     LPT3
>    valid port prefixes:
>     LPT
>   LPT1 LPT
>   1 1
>   LPT2 LPT
>   2 2                                                                      * 
> <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>   CommPortIdentifier:addPortName(LPT2)
>   CommPortIdentifier:AddIdentifierToList()
>   LPT3 LPT
>   3 3
>   CommPortIdentifier:addPortName(LPT3)
>   CommPortIdentifier:AddIdentifierToList()
>   CommPortIdentifier:AddIdentifierToList() index.next
>   Leaving registerValidPorts()
>   Have not implemented native_psmisc_report_owner(PortName)); in
>   CommPortIdentifier
>   CommPortIdentifier:getPortIdentifier(COM3)
>   CommPortIdentifier:open(densConnect, 30000)
>   RXTXCommDriver:getCommPort(COM3,1)
>   ...
>
> It would seem to me that if I removed the code for port scanning of LPT ports 
> I could solve this problem. I would much prefer to use unmodified code if at 
> all possible.  Do any of you have alternate suggestions?
>
> Thank you for your time.
>
> Doug
>


Does commenting out the LPT enumeration actually help?  There can often be 
differences between debug information printed and whats really going on. 
When you combine various environments the debug info can even come out in 
the wrong order.

I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
I do not think this problem is universal.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Thu Jun  1 14:29:44 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:29:44 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4E38.2060004@dupreeinc.com>

I will give it a try.  One thing to note on this PC is it has no LPT 
Parallel ports.

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
>>Hello,
>>
>>I am still trying to get this startup a little faster so I turned on the 
>>debug of a few of the classes.  The COM ports are scanned really fast and the 
>>delay occurs during the LPT scan.  The console output looks like this:
>>
>>  ...
>>    LPT1
>>    LPT2
>>    LPT3
>>   valid port prefixes:
>>    LPT
>>  LPT1 LPT
>>  1 1
>>  LPT2 LPT
>>  2 2                                                                      * 
>><<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>>  CommPortIdentifier:addPortName(LPT2)
>>  CommPortIdentifier:AddIdentifierToList()
>>  LPT3 LPT
>>  3 3
>>  CommPortIdentifier:addPortName(LPT3)
>>  CommPortIdentifier:AddIdentifierToList()
>>  CommPortIdentifier:AddIdentifierToList() index.next
>>  Leaving registerValidPorts()
>>  Have not implemented native_psmisc_report_owner(PortName)); in
>>  CommPortIdentifier
>>  CommPortIdentifier:getPortIdentifier(COM3)
>>  CommPortIdentifier:open(densConnect, 30000)
>>  RXTXCommDriver:getCommPort(COM3,1)
>>  ...
>>
>>It would seem to me that if I removed the code for port scanning of LPT ports 
>>I could solve this problem. I would much prefer to use unmodified code if at 
>>all possible.  Do any of you have alternate suggestions?
>>
>>Thank you for your time.
>>
>>Doug
>>
>>    
>>
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/dd31fed5/attachment-0015.html

From doug at dupreeinc.com  Thu Jun  1 14:36:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:36:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4FC8.9080106@dupreeinc.com>

Trent,

I commented out the section in RegisterScannedPorts() that adds the 
three LPT ports to the CandidateDeviceNames string array.  The 
application started immediately.  This is probably not the way to do 
this, but it was quick ,dirty, and worked.

It would be nice if there was a way to pole the OS to see if there is 
even a port there, though I guess this is what this code is suppose to do...

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
> ...
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From lynn at swcp.com  Thu Jun  1 14:49:34 2006
From: lynn at swcp.com (lynn@swcp.com)
Date: Thu, 1 Jun 2006 20:49:34 -0000
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>,
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <twig.1149194974.97617@swcp.com>

Perhaps we could add an argument to port enumeration where if not specified,
you get the default behavior that looks for everything.  With a new
constructor that has an argument(or more) you could optionally declare it to
not inspect printer ports.

Existing code would work as it always has.  New code could be smarter.

Lynn



Doug Thistlethwaite <doug at dupreeinc.com> said:

> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
> >On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
> >
> >  
> >
> > ...
> >
> >
> >Does commenting out the LPT enumeration actually help?  There can often be 
> >differences between debug information printed and whats really going on. 
> >When you combine various environments the debug info can even come out in 
> >the wrong order.
> >
> >I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
> >I do not think this problem is universal.
> >
> >--
> >Trent Jarvi
> >tjarvi at qbang.org
> >_______________________________________________
> >Rxtx mailing list
> >Rxtx at qbang.org
> >http://mailman.qbang.org/mailman/listinfo/rxtx
> >
> >
> >  
> >
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



-- 





From jredman at ergotech.com  Thu Jun  1 15:20:20 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 01 Jun 2006 15:20:20 -0600
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
Message-ID: <447F5A14.6010803@ergotech.com>

Doug,

If you specifically request ports, eg:

-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

or
 
-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

Depending upon the version  (Windows is COM1:COM2, etc. I assume).

Does it still enumerate the parallel ports?

Jim

Doug Thistlethwaite wrote:
> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
>> On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>
>>  
>>
>> ...
>>
>>
>> Does commenting out the LPT enumeration actually help?  There can often be 
>> differences between debug information printed and whats really going on. 
>> When you combine various environments the debug info can even come out in 
>> the wrong order.
>>
>> I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>> I do not think this problem is universal.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>>
>>  
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  1 16:49:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:49:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6EF4.7080709@dupreeinc.com>

I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
folder.  I created this file and added the following to the file:

gnu.io.rxtx.SerialPorts=COM3

and I get the following error on the console:
CommPortIdentifier:static initialization()
RXTXCommDriver {}
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
RXTXCommDriver:
    Jar version = RXTX-2.1-7
    native lib Version = RXTX-2.1-7
RXTXCommDriver:initialize()
checking for system-known ports of type 1
checking registry for ports of type 1

RXTXCommDriver:addSpecifiedPorts()
Exception in thread "main" java.lang.ExceptionInInitializerError
    at 
densconnect.SerialConnection.openConnection(SerialConnection.java:136)
    at densconnect.DensTalk.<init>(DensTalk.java:165)
    at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
    at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
    at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
    at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
Caused by: java.lang.NullPointerException
    at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
CommPortIdentifier:addPortName(COM3)
CommPortIdentifier:AddIdentifierToList()
CommPortIdentifier:AddIdentifierToList() null
...


It looks like it  read COM3 from the file, but it had the above 
exception that killed it.  The strange this is this error is from 
RXTXCommDriver initialize function (if statement line):

        OS = System.getProperty("os.name");
                System.out.println("OS NAME: " + OS);
        if(OS.toLowerCase().indexOf("linux") == -1)

OS is returning null, thus the error.

If the file is not present, it scans the ports and reads the OS.

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>Doug Thistlethwaite wrote:
>  
>
>>Trent,
>>
>>I commented out the section in RegisterScannedPorts() that adds the 
>>three LPT ports to the CandidateDeviceNames string array.  The 
>>application started immediately.  This is probably not the way to do 
>>this, but it was quick ,dirty, and worked.
>>
>>It would be nice if there was a way to pole the OS to see if there is 
>>even a port there, though I guess this is what this code is suppose to do...
>>
>>Doug
>>
>>Trent Jarvi wrote:
>>
>>    
>>
>>>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>>
>>> 
>>>
>>>...
>>>
>>>
>>>Does commenting out the LPT enumeration actually help?  There can often be 
>>>differences between debug information printed and whats really going on. 
>>>When you combine various environments the debug info can even come out in 
>>>the wrong order.
>>>
>>>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>>>I do not think this problem is universal.
>>>
>>>--
>>>Trent Jarvi
>>>tjarvi at qbang.org
>>>_______________________________________________
>>>Rxtx mailing list
>>>Rxtx at qbang.org
>>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>>
>>>
>>> 
>>>
>>>      
>>>
>>_______________________________________________
>>Rxtx mailing list
>>Rxtx at qbang.org
>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>    
>>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/bf4cca0e/attachment-0015.html

From doug at dupreeinc.com  Thu Jun  1 16:51:26 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:51:26 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6F6E.5060603@dupreeinc.com>

Jim,

I did not try your suggestion as I do not understand where I would put 
these command line parameters (it that is what they are).  It appears 
that using the properties file should do that same thing...

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>
>  
>


From doug at dupreeinc.com  Thu Jun  1 17:56:19 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 16:56:19 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
Message-ID: <447F7EA3.6050400@dupreeinc.com>

I think there is an error in the registerSpecifiedPorts() method.  When 
I have a gnu.io.rxtx.properties file in the ext directory, this function 
kills the System class  IF I call System.getProperty("os.name") before 
the call  to registerSpecifiedPorts(), it returns the os name, after the 
call, it returns null.  I have not played much with properties, except 
for reading them, so I don't really understand the code.

Doug



From doug at dupreeinc.com  Thu Jun  1 18:11:14 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 17:11:14 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F7EA3.6050400@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com>
Message-ID: <447F8222.3060402@dupreeinc.com>

Ok, I just hacked this thing up and got it to read the 
gnu.io.rxtx.properties file.

I commented out the line:
System.setProperties(p); in the method registerSpecifiedPorts() in 
RXTXCommDriver class.  I really don't understand that much about 
properties, but this call kills the System class.

I used the following in the gnu.io.rxtx.properties file:

gnu.io.rxtx.SerialPorts=COM3
gnu.io.rxtx.ParallelPorts=null

This allows the application to open very quickly without any errors.  
Whomever coded this class or somebody who understands properties should 
look at this method and make sure it is doing what they expect.

Doug




Doug Thistlethwaite wrote:

>I think there is an error in the registerSpecifiedPorts() method.  When 
>I have a gnu.io.rxtx.properties file in the ext directory, this function 
>kills the System class  IF I call System.getProperty("os.name") before 
>the call  to registerSpecifiedPorts(), it returns the os name, after the 
>call, it returns null.  I have not played much with properties, except 
>for reading them, so I don't really understand the code.
>
>Doug
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From tjarvi at qbang.org  Thu Jun  1 18:32:50 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 18:32:50 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F6EF4.7080709@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com> <447F6EF4.7080709@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011831510.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
> folder.  I created this file and added the following to the file:
>
> gnu.io.rxtx.SerialPorts=COM3
>
> and I get the following error on the console:
> CommPortIdentifier:static initialization()
> RXTXCommDriver {}
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
> RXTXCommDriver:
>   Jar version = RXTX-2.1-7
>   native lib Version = RXTX-2.1-7
> RXTXCommDriver:initialize()
> checking for system-known ports of type 1
> checking registry for ports of type 1
>
> RXTXCommDriver:addSpecifiedPorts()
> Exception in thread "main" java.lang.ExceptionInInitializerError
>   at densconnect.SerialConnection.openConnection(SerialConnection.java:136)
>   at densconnect.DensTalk.<init>(DensTalk.java:165)
>   at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
>   at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
>   at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
>   at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
> Caused by: java.lang.NullPointerException
>   at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
> CommPortIdentifier:addPortName(COM3)
> CommPortIdentifier:AddIdentifierToList()
> CommPortIdentifier:AddIdentifierToList() null
> ...
>
>

There is a solution for this bug.

http://bugzilla.qbang.org/show_bug.cgi?id=54

We have been horribly slow at getting the next round of patches in but 
they are comming.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  2 00:58:02 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 08:58:02 +0200
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F8222.3060402@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
Message-ID: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>

Hi Doug,

you wrote in an earlier message, that you would prefer an unchanged  
version. What about simply removing the RXTX parallel lib from the  
ext directory. This does not fix the bug, but it should fix your  
problem.

In general I think it is not a good idea to put the RXTX files in a  
system wide location. Putting the libs in the application folder and  
including the .jar in the application classpath (or application jar)  
is all that is required.

Regards,
Joachim

On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:

> Ok, I just hacked this thing up and got it to read the
> gnu.io.rxtx.properties file.
>
> I commented out the line:
> System.setProperties(p); in the method registerSpecifiedPorts() in
> RXTXCommDriver class.  I really don't understand that much about
> properties, but this call kills the System class.
>
> I used the following in the gnu.io.rxtx.properties file:
>
> gnu.io.rxtx.SerialPorts=COM3
> gnu.io.rxtx.ParallelPorts=null
>
> This allows the application to open very quickly without any errors.
> Whomever coded this class or somebody who understands properties  
> should
> look at this method and make sure it is doing what they expect.
>
> Doug
>
>
>
>
> Doug Thistlethwaite wrote:
>
>> I think there is an error in the registerSpecifiedPorts() method.   
>> When
>> I have a gnu.io.rxtx.properties file in the ext directory, this  
>> function
>> kills the System class  IF I call System.getProperty("os.name")  
>> before
>> the call  to registerSpecifiedPorts(), it returns the os name,  
>> after the
>> call, it returns null.  I have not played much with properties,  
>> except
>> for reading them, so I don't really understand the code.
>>
>> 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 antonio.luis at iscte.pt  Fri Jun  2 02:42:28 2006
From: antonio.luis at iscte.pt (=?ISO-8859-1?Q?Ant=F3nio_Lopes?=)
Date: Fri, 02 Jun 2006 09:42:28 +0100
Subject: [Rxtx] Exception when closing serial port
Message-ID: <447FF9F4.7060209@iscte.pt>

Hello everyone,
I've been using RXTX in a Java application in my Pocket PC.
The communication through the (bluetooth) serial port is working perfectly.

However, when I disconnect the app and close the serial port, sometimes I get 
the following error:

"1149237595000: RXTXPort:close detected bad File Descriptor"

The problem is that after this error occurs, the app is no longer able to 
connect to the serial port and I have to soft-reset the device in order to be 
able to connect to it again.

Any ideas on how to solve this issue?

Any help is appreciated.
Thanks,
regards,
-- 
Ant?nio Lopes

@contact: antonio.luis at iscte.pt
@work: ADETTI - ISCTE
@web: http://antonio.lopes.googlepages.com


From paul.klissner at sun.com  Fri Jun  2 02:44:34 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 01:44:34 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to RXTX
	again
Message-ID: <447FFA72.6040807@sun.com>

After looking into javax.comm 3.1 and what it would take to re-engineer it
to be compatible with RXTX platform libraries, I've decided, due my group's
priorities, complexity of the effort vs. benefit, and limited resources, 
to re-post
javax.comm 2.0 binaries on Sun's software download server, unsupported,
with disclaimers, as it was previously.

I don't think there will be any snags doing this from the standpoint of Sun
management or legality.  I will try to have it  posted there in the next 
week
or two, depending on how fast we can get it pushed through the process.

I'd like to think of this as a stop gap measure... ie. a compromise, 
where, at some
point in the not too distant future RXTX implements their own version of the
Java side of the API, as is normally done by javax.extension porters. 
That way
we avoid uncomfortable dependencies in the future.  And that really is 
the Java
development model.

Since RXTX already has the back-end code, porting the java code shouldn't
be a gargantuan effort at all, and RXTX will be in full control of the 
code top
to bottom. I think RXTX can do at least as good a job as the original 
coder.
Prepping 2.0 to be open sourced is more trouble than it is worth. ie. I 
don't
think the current implementation warrants it.

Ultimately, it would be nice to see someone open up a JSR and re-architect
the comm. API to overcome some of it's current design flaws (ie. be more
adaptable to modern platforms, more pluggable, better defined SPI, better
port ownership handling, etc...). A superior architecture would allow for
better collaboration in the future and better interchangeability of 
components
among projects.

Sun's 3.1 version of javax.comm, which is Sun's currently supported version,
has changes pertaining mostly to Sun platform-specific portmapping and has
some minor additional interactions with our back end code, but generally
has little bearing on RXTX. 

Paul



From joachim at buechse.de  Fri Jun  2 04:00:19 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 12:00:19 +0200
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
	RXTX again
In-Reply-To: <447FFA72.6040807@sun.com>
References: <447FFA72.6040807@sun.com>
Message-ID: <1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>

Good day Paul!

A clean architecture with loadable drivers and reusable code would be  
very beneficial for the future, I think everybody agrees. However  
this could be several years into the future. In the meantime, there  
is a real existing problem with IO support on Java. I have the strong  
feeling that most programmers want to code against one specification  
(javax.comm) and be able to replace the underlying implementation via  
a "plugin" on platforms where the SUN implementation is not  
sufficient. RXTX could be just this plugin (reusing very close to 0%  
of the javax.comm implementation but 100% of its API).

I want to propose an API addition and implementation change that will  
take less then 2 hours of manpower to implement and create a solution  
that can bridge the years until javax.comm has been based on a new  
architecture.

Looking at the javax.comm api at http://java.sun.com/products/ 
javacomm/reference/api/index.html I would like to propose the following:

The only entry point to javax.comm is CommPortIdentifier. It has 3  
static methods plus the constructor.

1) define one additional Interface

public interface CommProvider {
    CommPortIdentifier getPortIdentifier(CommPort port);
    CommPortIdentifier getPortIdentifier(String portName);
    Enumeration getPortIdentifiers ();
}

2) add one method to CommPortIdentifier

   public static setCustomCommProvider (CommProvider);

3) change the three static methods of CommPortIdentifier to dispatch  
to the CommProvider if it is set

4) change the constructor of CommPortIdentifier to

   public CommPortIdentifier(...) {
      if (isProviderSet && this.getClass() ==  
javax.comm.CommPortIdentifier) {
          throw new RuntimeException("illegal creation of  
CommPortIndentifier, custom CommProvider is in use");
      }

5) (this is optional, but would be very nice) automatically set a  
custom CommProvider if it is found on the classpath or defined via a  
system property.


The above 1) - 4) can be implemented in less than 1hour. 5) may take  
another hour. I agree that this is not the most elegant design, but  
it would solve a lot of problems with very little effort. It would  
certainly allow RXTX to move forward. If the javax.comm API needs to  
be redesigned completely this addition will not hurt, as people will  
move to the new API anyway and javax.comm 3.0 was so far never  
included in the main distribution.

Best regards,
Joachim

On 02.06.2006, at 10:44, Paul Klissner wrote:

> After looking into javax.comm 3.1 and what it would take to re- 
> engineer it
> to be compatible with RXTX platform libraries, I've decided, due my  
> group's
> priorities, complexity of the effort vs. benefit, and limited  
> resources,
> to re-post
> javax.comm 2.0 binaries on Sun's software download server,  
> unsupported,
> with disclaimers, as it was previously.
>
> I don't think there will be any snags doing this from the  
> standpoint of Sun
> management or legality.  I will try to have it  posted there in the  
> next
> week
> or two, depending on how fast we can get it pushed through the  
> process.
>
> I'd like to think of this as a stop gap measure... ie. a compromise,
> where, at some
> point in the not too distant future RXTX implements their own  
> version of the
> Java side of the API, as is normally done by javax.extension porters.
> That way
> we avoid uncomfortable dependencies in the future.  And that really is
> the Java
> development model.
>
> Since RXTX already has the back-end code, porting the java code  
> shouldn't
> be a gargantuan effort at all, and RXTX will be in full control of the
> code top
> to bottom. I think RXTX can do at least as good a job as the original
> coder.
> Prepping 2.0 to be open sourced is more trouble than it is worth.  
> ie. I
> don't
> think the current implementation warrants it.
>
> Ultimately, it would be nice to see someone open up a JSR and re- 
> architect
> the comm. API to overcome some of it's current design flaws (ie. be  
> more
> adaptable to modern platforms, more pluggable, better defined SPI,  
> better
> port ownership handling, etc...). A superior architecture would  
> allow for
> better collaboration in the future and better interchangeability of
> components
> among projects.
>
> Sun's 3.1 version of javax.comm, which is Sun's currently supported  
> version,
> has changes pertaining mostly to Sun platform-specific portmapping  
> and has
> some minor additional interactions with our back end code, but  
> generally
> has little bearing on RXTX.
>
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Fri Jun  2 09:10:13 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Fri, 2 Jun 2006 09:10:13 -0600 (MDT)
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <447FFA72.6040807@sun.com>
References: <447FFA72.6040807@sun.com>
Message-ID: <Pine.LNX.4.61.0606020906400.15971@www>

On Fri, 2 Jun 2006, Paul Klissner wrote:

> After looking into javax.comm 3.1 and what it would take to re-engineer it
> to be compatible with RXTX platform libraries, I've decided, due my group's
> priorities, complexity of the effort vs. benefit, and limited resources,
> to re-post
> javax.comm 2.0 binaries on Sun's software download server, unsupported,
> with disclaimers, as it was previously.
>

Hi Paul

To address users' immediate needs, we can release rxtx 2.0-7 (final) to 
match the 2.0 binaries from Sun when they are offered for download.

We can discuss potential long term solutions after that.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Fri Jun  2 10:20:09 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 02 Jun 2006 09:20:09 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
	<9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
Message-ID: <44806539.8080902@dupreeinc.com>

Thanks for the suggestion, I will give it a try.

Doug

Joachim Buechse wrote:

>Hi Doug,
>
>you wrote in an earlier message, that you would prefer an unchanged  
>version. What about simply removing the RXTX parallel lib from the  
>ext directory. This does not fix the bug, but it should fix your  
>problem.
>
>In general I think it is not a good idea to put the RXTX files in a  
>system wide location. Putting the libs in the application folder and  
>including the .jar in the application classpath (or application jar)  
>is all that is required.
>
>Regards,
>Joachim
>
>On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:
>
>  
>
>>Ok, I just hacked this thing up and got it to read the
>>gnu.io.rxtx.properties file.
>>
>>I commented out the line:
>>System.setProperties(p); in the method registerSpecifiedPorts() in
>>RXTXCommDriver class.  I really don't understand that much about
>>properties, but this call kills the System class.
>>
>>I used the following in the gnu.io.rxtx.properties file:
>>
>>gnu.io.rxtx.SerialPorts=COM3
>>gnu.io.rxtx.ParallelPorts=null
>>
>>This allows the application to open very quickly without any errors.
>>Whomever coded this class or somebody who understands properties  
>>should
>>look at this method and make sure it is doing what they expect.
>>
>>Doug
>>
>>
>>
>>
>>Doug Thistlethwaite wrote:
>>
>>    
>>
>>>I think there is an error in the registerSpecifiedPorts() method.   
>>>When
>>>I have a gnu.io.rxtx.properties file in the ext directory, this  
>>>function
>>>kills the System class  IF I call System.getProperty("os.name")  
>>>before
>>>the call  to registerSpecifiedPorts(), it returns the os name,  
>>>after the
>>>call, it returns null.  I have not played much with properties,  
>>>except
>>>for reading them, so I don't really understand the code.
>>>
>>>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
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060602/c8892a46/attachment-0015.html

From paul.klissner at sun.com  Fri Jun  2 12:09:26 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 11:09:26 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
Message-ID: <44807ED6.8000903@sun.com>

Joachim Buechse wrote:
> Good day Paul!
>
> A clean architecture with loadable drivers and reusable code would be  
> very beneficial for the future, I think everybody agrees. However  
> this could be several years into the future. In the meantime, there  
> is a real existing problem with IO support on Java. I have the strong  
> feeling that most programmers want to code against one specification  
> (javax.comm) and be able to replace the underlying implementation via  
> a "plugin" on platforms where the SUN implementation is not  
> sufficient. RXTX could be just this plugin (reusing very close to 0%  
> of the javax.comm implementation but 100% of its API).
>
> I want to propose an API addition and implementation change that will  
> take less then 2 hours of manpower to implement and create a solution  
> that can bridge the years until javax.comm has been based on a new  
> architecture.
>
> Looking at the javax.comm api at http://java.sun.com/products/ 
> javacomm/reference/api/index.html I would like to propose the following:
>
> The only entry point to javax.comm is CommPortIdentifier. It has 3  
> static methods plus the constructor.
>
> 1) define one additional Interface
>
> public interface CommProvider {
>     CommPortIdentifier getPortIdentifier(CommPort port);
>     CommPortIdentifier getPortIdentifier(String portName);
>     Enumeration getPortIdentifiers ();
> }
>
> 2) add one method to CommPortIdentifier
>
>    public static setCustomCommProvider (CommProvider);
>
> 3) change the three static methods of CommPortIdentifier to dispatch  
> to the CommProvider if it is set
>
> 4) change the constructor of CommPortIdentifier to
>
>    public CommPortIdentifier(...) {
>       if (isProviderSet && this.getClass() ==  
> javax.comm.CommPortIdentifier) {
>           throw new RuntimeException("illegal creation of  
> CommPortIndentifier, custom CommProvider is in use");
>       }
>
> 5) (this is optional, but would be very nice) automatically set a  
> custom CommProvider if it is found on the classpath or defined via a  
> system property.
>
>
> The above 1) - 4) can be implemented in less than 1hour. 5) may take  
> another hour. I agree that this is not the most elegant design, but  
> it would solve a lot of problems with very little effort. It would  
> certainly allow RXTX to move forward. If the javax.comm API needs to  
> be redesigned completely this addition will not hurt, as people will  
> move to the new API anyway and javax.comm 3.0 was so far never  
> included in the main distribution.
>
> Best regards,
> Joachi
I'm afraid modifying the interface classes isn't my call.  There was 
actually
a TCK written and one of the tests was to ensure that the interface classes
match the spec.  Thus my hands have already been tied since this project
was essentially grandfathered into the JCP.

That's why we need to open a new JSR and find someone who wants
to be the spec lead, and go in with a new reference implementation.
I'm not sure why it would have to take years, since this isn't bleeding edge
technology and there are only so many things that can be done with it,
and we already have practical experience about many functional aspects
that we could cite precedence on.

As it becomes clear that the specification is being accepted completely
or by-and-large by the community, nothing would stop people from
starting adapting to the new API (using the reference implementation or
porting it) and using it in their projects prior to it's final community and
JCP approval, since approval is required only to make it official and
get the "100% pure java" certification for platform ports.

You have one idea already.  Why don't you implement it, solicit some
design feedback from Sun and the RXTX, and create a functional
implementation that addresses the needs of the community, then
we can document it and open a JSR.  That's it.  It should march through
the approval stages reasonably quickly I would imagine, and meantime
RXTX could start using it.

Paul




From doug at dupreeinc.com  Fri Jun  2 12:45:01 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 02 Jun 2006 11:45:01 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
	<9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
Message-ID: <4480872D.6000605@dupreeinc.com>

Joachim,

Thank you for the suggestion.  I restored the jar file to the one I 
downloaded, moved the dll files into the project directory, and added 
the jar to the classpath.  The SerialDemo program that was included with 
the Sun commapi started in 12 seconds instead of the 58 seconds when the 
parallel dll is present.  I did get the startup time to about a second 
by modifying the java code and adding the properties file but this is 
probably not a good idea.

Doug

Joachim Buechse wrote:

>Hi Doug,
>
>you wrote in an earlier message, that you would prefer an unchanged  
>version. What about simply removing the RXTX parallel lib from the  
>ext directory. This does not fix the bug, but it should fix your  
>problem.
>
>In general I think it is not a good idea to put the RXTX files in a  
>system wide location. Putting the libs in the application folder and  
>including the .jar in the application classpath (or application jar)  
>is all that is required.
>
>Regards,
>Joachim
>
>On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:
>
>  
>
>>Ok, I just hacked this thing up and got it to read the
>>gnu.io.rxtx.properties file.
>>
>>I commented out the line:
>>System.setProperties(p); in the method registerSpecifiedPorts() in
>>RXTXCommDriver class.  I really don't understand that much about
>>properties, but this call kills the System class.
>>
>>I used the following in the gnu.io.rxtx.properties file:
>>
>>gnu.io.rxtx.SerialPorts=COM3
>>gnu.io.rxtx.ParallelPorts=null
>>
>>This allows the application to open very quickly without any errors.
>>Whomever coded this class or somebody who understands properties  
>>should
>>look at this method and make sure it is doing what they expect.
>>
>>Doug
>>
>>
>>
>>
>>Doug Thistlethwaite wrote:
>>
>>    
>>
>>>I think there is an error in the registerSpecifiedPorts() method.   
>>>When
>>>I have a gnu.io.rxtx.properties file in the ext directory, this  
>>>function
>>>kills the System class  IF I call System.getProperty("os.name")  
>>>before
>>>the call  to registerSpecifiedPorts(), it returns the os name,  
>>>after the
>>>call, it returns null.  I have not played much with properties,  
>>>except
>>>for reading them, so I don't really understand the code.
>>>
>>>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
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060602/3c0e420f/attachment-0015.html

From joachim at buechse.de  Fri Jun  2 13:46:36 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 21:46:36 +0200
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
	RXTX again
In-Reply-To: <44807ED6.8000903@sun.com>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
	<44807ED6.8000903@sun.com>
Message-ID: <6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>

Hello Paul,

of course, the basic change I suggested could be done "hidden".  The  
CommProvider interface could live somewhere in sun.xyz.*
The setCustomCommProvider method would not be in CommPortIdentifier  
but also somewhere in sun.xyz.* This would be an unofficial feature,  
the official interface stays exactly the same. However RXTX (and  
others) could access the hidden interface.

Don't get me wrong, I don't want to harass you into making changes  
you don't like (which probably wouldn't work anyway;-). But I'm a  
long time Java programmer and seeing the state of cross platform  
serial support for Java makes me feel really sad. In fact, when I  
started to look into Java serial port programming some months ago I  
was very surprised that javax.comm never made it into the JDK.

I'm sorry that I did not contribute my feedback to the JSR for  
javax.comm 3.0. However at the time I didn't do serial port  
programming in Java. I agree that a new JSR should be opened - I'm  
not an expert on JSRs or the JCP process, but from looking quickly  
over the progress of some JSRs I would be very surprised if we can  
have a new version in less then a year. In the meanwhile some people  
will start using javax.comm 3.0 (which can not be supported by RXTX),  
some will use javax.comm 2.0 (which means the 2.0.7 release of RXTX  
still needs to be maintained). This may get even worse if eg Apple  
decides to port and include javax.comm 3.0 at which point it may get  
very tricky to write a cross platform Java application.

All of this simply means, that we are loosing a lot of man-power that  
could otherwise be invested in building a clean solution and/or to  
add features that are becoming more and more important (USB events...).

In the automation / machine control universe Java makes a lot of  
sense. Right now many people are migrating to Linux or from  
propietary systems (even DOS) to Windows. Writing the control/ 
configuration applications in Java is the kings way to unify the code  
base.

Best regards,
Joachim


On 02.06.2006, at 20:09, Paul Klissner wrote:

> Joachim Buechse wrote:
>> Good day Paul!
>>
>> A clean architecture with loadable drivers and reusable code would be
>> very beneficial for the future, I think everybody agrees. However
>> this could be several years into the future. In the meantime, there
>> is a real existing problem with IO support on Java. I have the strong
>> feeling that most programmers want to code against one specification
>> (javax.comm) and be able to replace the underlying implementation via
>> a "plugin" on platforms where the SUN implementation is not
>> sufficient. RXTX could be just this plugin (reusing very close to 0%
>> of the javax.comm implementation but 100% of its API).
>>
>> I want to propose an API addition and implementation change that will
>> take less then 2 hours of manpower to implement and create a solution
>> that can bridge the years until javax.comm has been based on a new
>> architecture.
>>
>> Looking at the javax.comm api at http://java.sun.com/products/
>> javacomm/reference/api/index.html I would like to propose the  
>> following:
>>
>> The only entry point to javax.comm is CommPortIdentifier. It has 3
>> static methods plus the constructor.
>>
>> 1) define one additional Interface
>>
>> public interface CommProvider {
>>     CommPortIdentifier getPortIdentifier(CommPort port);
>>     CommPortIdentifier getPortIdentifier(String portName);
>>     Enumeration getPortIdentifiers ();
>> }
>>
>> 2) add one method to CommPortIdentifier
>>
>>    public static setCustomCommProvider (CommProvider);
>>
>> 3) change the three static methods of CommPortIdentifier to dispatch
>> to the CommProvider if it is set
>>
>> 4) change the constructor of CommPortIdentifier to
>>
>>    public CommPortIdentifier(...) {
>>       if (isProviderSet && this.getClass() ==
>> javax.comm.CommPortIdentifier) {
>>           throw new RuntimeException("illegal creation of
>> CommPortIndentifier, custom CommProvider is in use");
>>       }
>>
>> 5) (this is optional, but would be very nice) automatically set a
>> custom CommProvider if it is found on the classpath or defined via a
>> system property.
>>
>>
>> The above 1) - 4) can be implemented in less than 1hour. 5) may take
>> another hour. I agree that this is not the most elegant design, but
>> it would solve a lot of problems with very little effort. It would
>> certainly allow RXTX to move forward. If the javax.comm API needs to
>> be redesigned completely this addition will not hurt, as people will
>> move to the new API anyway and javax.comm 3.0 was so far never
>> included in the main distribution.
>>
>> Best regards,
>> Joachi
> I'm afraid modifying the interface classes isn't my call.  There was
> actually
> a TCK written and one of the tests was to ensure that the interface  
> classes
> match the spec.  Thus my hands have already been tied since this  
> project
> was essentially grandfathered into the JCP.
>
> That's why we need to open a new JSR and find someone who wants
> to be the spec lead, and go in with a new reference implementation.
> I'm not sure why it would have to take years, since this isn't  
> bleeding edge
> technology and there are only so many things that can be done with it,
> and we already have practical experience about many functional aspects
> that we could cite precedence on.
>
> As it becomes clear that the specification is being accepted  
> completely
> or by-and-large by the community, nothing would stop people from
> starting adapting to the new API (using the reference  
> implementation or
> porting it) and using it in their projects prior to it's final  
> community and
> JCP approval, since approval is required only to make it official and
> get the "100% pure java" certification for platform ports.
>
> You have one idea already.  Why don't you implement it, solicit some
> design feedback from Sun and the RXTX, and create a functional
> implementation that addresses the needs of the community, then
> we can document it and open a JSR.  That's it.  It should march  
> through
> the approval stages reasonably quickly I would imagine, and meantime
> RXTX could start using it.
>
> Paul
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From paul.klissner at sun.com  Fri Jun  2 14:38:49 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 13:38:49 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
	<44807ED6.8000903@sun.com>
	<6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>
Message-ID: <4480A1D9.5060106@sun.com>

Joachim Buechse wrote:
> Hello Paul,
>
> of course, the basic change I suggested could be done "hidden".  The  
> CommProvider interface could live somewhere in sun.xyz.*
> The setCustomCommProvider method would not be in CommPortIdentifier  
> but also somewhere in sun.xyz.* This would be an unofficial feature,  
> the official interface stays exactly the same. However RXTX (and  
> others) could access the hidden interface.
>
> Don't get me wrong, I don't want to harass you into making changes  
> you don't like (which probably wouldn't work anyway;-). But I'm a  
> long time Java programmer and seeing the state of cross platform  
> serial support for Java makes me feel really sad. In fact, when I  
> started to look into Java serial port programming some months ago I  
> was very surprised that javax.comm never made it into the JDK.
>
> I'm sorry that I did not contribute my feedback to the JSR for  
> javax.comm 3.0. 
There was no JSR for 3.0, because we didn't have the resources to make 
the commitment.
Yet Sun needed to add support for platform-dependent port name mapping, 
which had to
be done 'under the hood', since the API isn't designed to handle that in 
a pluggable way.
But these quick fixes aren't the right approach, they just kick the dog 
down the road,
setting bad precedent, inviting confusion and more intractable problems 
(such as the
one plaguing us now).

My changes could have been layered better, it was a trade off between 
achieving an
ideal architecture, trying to find internal reviewers, and meet the 
needs of big customers
in a timely way.  Thus my namespace changes collided with RXTX's 
dependencies.
I was unaware of Jagane's rogue agreement made with the RXTX community 7 
years ago,
before Jagane left Sun.  I think this was a wag-the-dog situation.

Now it is time to do it right, and I don't think it is going to be as 
much trouble as people
some people fear. If RXTX wants to sponsor the JSR and seed a new spec, 
Sun can join
the Expert Group.  And we'd be largely in agreement, since we're not 
talking about
humongous changes, and looking for mutually beneficial changes. The core 
API is already
largely proved and tested.
> However at the time I didn't do serial port  
> programming in Java. I agree that a new JSR should be opened - I'm  
> not an expert on JSRs or the JCP process, but from looking quickly  
> over the progress of some JSRs I would be very surprised if we can  
> have a new version in less then a year. 
*Approved*  But that doesn't mean the spec couldn't be 99.9% stable 
before that.  Once
the delta rate declines and changes approach nil, people could start 
adapting to the API in
advance of formal approval.   It isn't going to be drawn out like 
javax.usb, which was new
technology, a very complex API, and involved precedent setting corporate 
disputes and
policy issues to resolve.

> In the meanwhile some people  
> will start using javax.comm 3.0 (which can not be supported by RXTX),  
> some will use javax.comm 2.0 (which means the 2.0.7 release of RXTX  
> still needs to be maintained). This may get even worse if eg Apple  
> decides to port and include javax.comm 3.0 at which point it may get  
> very tricky to write a cross platform Java application.
>   
The interfaces haven't changed since 1.0.  If we open a JSR ,we can 
contact Apple and
allow them to be on the E.G., if they want.  That might make the JSR a 
bit more drawn out,
but then we'd arrive ultimately arrive at a best-of-all-worlds API that 
most people would
accept, perhaps forever, and arrive at a respectable set of compromises.

-Paul

> All of this simply means, that we are loosing a lot of man-power that  
> could otherwise be invested in building a clean solution and/or to  
> add features that are becoming more and more important (USB events...).
>
> In the automation / machine control universe Java makes a lot of  
> sense. Right now many people are migrating to Linux or from  
> propietary systems (even DOS) to Windows. Writing the control/ 
> configuration applications in Java is the kings way to unify the code  
> base.
>
> Best regards,
> Joachim
>
>
> On 02.06.2006, at 20:09, Paul Klissner wrote:
>
>   
>> Joachim Buechse wrote:
>>     
>>> Good day Paul!
>>>
>>> A clean architecture with loadable drivers and reusable code would be
>>> very beneficial for the future, I think everybody agrees. However
>>> this could be several years into the future. In the meantime, there
>>> is a real existing problem with IO support on Java. I have the strong
>>> feeling that most programmers want to code against one specification
>>> (javax.comm) and be able to replace the underlying implementation via
>>> a "plugin" on platforms where the SUN implementation is not
>>> sufficient. RXTX could be just this plugin (reusing very close to 0%
>>> of the javax.comm implementation but 100% of its API).
>>>
>>> I want to propose an API addition and implementation change that will
>>> take less then 2 hours of manpower to implement and create a solution
>>> that can bridge the years until javax.comm has been based on a new
>>> architecture.
>>>
>>> Looking at the javax.comm api at http://java.sun.com/products/
>>> javacomm/reference/api/index.html I would like to propose the  
>>> following:
>>>
>>> The only entry point to javax.comm is CommPortIdentifier. It has 3
>>> static methods plus the constructor.
>>>
>>> 1) define one additional Interface
>>>
>>> public interface CommProvider {
>>>     CommPortIdentifier getPortIdentifier(CommPort port);
>>>     CommPortIdentifier getPortIdentifier(String portName);
>>>     Enumeration getPortIdentifiers ();
>>> }
>>>
>>> 2) add one method to CommPortIdentifier
>>>
>>>    public static setCustomCommProvider (CommProvider);
>>>
>>> 3) change the three static methods of CommPortIdentifier to dispatch
>>> to the CommProvider if it is set
>>>
>>> 4) change the constructor of CommPortIdentifier to
>>>
>>>    public CommPortIdentifier(...) {
>>>       if (isProviderSet && this.getClass() ==
>>> javax.comm.CommPortIdentifier) {
>>>           throw new RuntimeException("illegal creation of
>>> CommPortIndentifier, custom CommProvider is in use");
>>>       }
>>>
>>> 5) (this is optional, but would be very nice) automatically set a
>>> custom CommProvider if it is found on the classpath or defined via a
>>> system property.
>>>
>>>
>>> The above 1) - 4) can be implemented in less than 1hour. 5) may take
>>> another hour. I agree that this is not the most elegant design, but
>>> it would solve a lot of problems with very little effort. It would
>>> certainly allow RXTX to move forward. If the javax.comm API needs to
>>> be redesigned completely this addition will not hurt, as people will
>>> move to the new API anyway and javax.comm 3.0 was so far never
>>> included in the main distribution.
>>>
>>> Best regards,
>>> Joachi
>>>       
>> I'm afraid modifying the interface classes isn't my call.  There was
>> actually
>> a TCK written and one of the tests was to ensure that the interface  
>> classes
>> match the spec.  Thus my hands have already been tied since this  
>> project
>> was essentially grandfathered into the JCP.
>>
>> That's why we need to open a new JSR and find someone who wants
>> to be the spec lead, and go in with a new reference implementation.
>> I'm not sure why it would have to take years, since this isn't  
>> bleeding edge
>> technology and there are only so many things that can be done with it,
>> and we already have practical experience about many functional aspects
>> that we could cite precedence on.
>>
>> As it becomes clear that the specification is being accepted  
>> completely
>> or by-and-large by the community, nothing would stop people from
>> starting adapting to the new API (using the reference  
>> implementation or
>> porting it) and using it in their projects prior to it's final  
>> community and
>> JCP approval, since approval is required only to make it official and
>> get the "100% pure java" certification for platform ports.
>>
>> You have one idea already.  Why don't you implement it, solicit some
>> design feedback from Sun and the RXTX, and create a functional
>> implementation that addresses the needs of the community, then
>> we can document it and open a JSR.  That's it.  It should march  
>> through
>> the approval stages reasonably quickly I would imagine, and meantime
>> RXTX could start using it.
>>
>> Paul
>>
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at 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  Sat Jun  3 18:15:24 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 18:15:24 -0600 (MDT)
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
Message-ID: <Pine.LNX.4.61.0606031715100.10890@www>


The attached patch allows baud rates of 14400, 28800, 128000 and 256000.

That was my goal.

[import standard disclaimer]

But I took some time to look a little further.  I got custom baud rates 
working enough that someone (perhaps me) can properly fix them in the 
future.  Proof of concept.

As an undocumented bonus, you can toss random baudrates (say 1953), at the 
API and it will set it to something close to that on windows and linux. 
Solaris should say the baud rate is not supported but I have not tested it 
yet.  Mac OS X behavior is unknown at this point.  Just dont expect 
correct behavior at ~8192-9009 baudrates or baudrates less than 20 on 
windows; these baud rates overlap with defines in win32termios.h.  I 
conveniently closed my eyes there.  Try another value close.  On Linux, a 
baud base and divisor are guestimated and set.  On windows, we wave pixie 
dust over the kernel driver and hope.  Do not expect pixie dust and 
guestimates to be the same on windows and linux.  They may well round to 
different values in yet to be tested ways.  There are only so many 
divisors.  If it isn't working, try a little higher or lower.

In the example of 1953 for instance, there is no divisor for commodity 
hardware that comes to that baudrate.  We just come close on one side or 
the other.  If tools tell you they got 1953 exactly, the tools may be 
questionable and just reading values not directly related to the actual 
hardware settings.

These fixes have been tested on Linux and Windows while using an 
oscilloscope to confirm they change relative to known baudrates at 9600, 
14400*, 19200, 28800* (and 1800, 1953** and 2400).

* = previously unsupported.
** = still not supported but probably works from what I saw.

There could be future discussion in this area.  For now this is working 
for almost all unusual baud rate demands.  Cleaning up the custom baud 
rate should be easier with a working starting point.  Baud bases other 
than 128000 have not been characterized.  Yes.. this overlapps with two of 
the baud rates enabled.

Feedback and ideas are welcome.

--
Trent Jarvi
tjarvi at qbang.org
-------------- next part --------------
Index: SerialImp.c
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v
retrieving revision 1.46.2.187
diff -u -r1.46.2.187 SerialImp.c
--- SerialImp.c	29 Jan 2006 22:19:04 -0000	1.46.2.187
+++ SerialImp.c	3 Jun 2006 23:12:40 -0000
@@ -793,6 +793,19 @@
 		result &= ~TIOCM_DTR;
 		ioctl( fd, TIOCMSET, &result );
 	}
+	/*
+	   B38400 is a special case in Linux for custom baud rates.
+
+	   We just treat this as a custom speed for now.  If you take this ifdef
+	   out and select baud rates 38400 then 28800 then 38400, you will get
+	   a final baud rate of 28800 because you did not update the divisor.
+
+	   See the next ifdef below for the divisor.
+	*/
+#if defined(TIOCGSERIAL)
+	if ( cspeed == B38400 )
+		cspeed = 38400;
+#endif /* TIOCGSERIAL */
 	if(     cfsetispeed( &ttyset, cspeed ) < 0 ||
 		cfsetospeed( &ttyset, cspeed ) < 0 )
 	{
@@ -814,6 +827,7 @@
 		*/
 
 #if defined(TIOCGSERIAL)
+		ioctl( fd, TIOCGSERIAL, &sstruct );
 		sstruct.custom_divisor = ( sstruct.baud_base/cspeed );
 		cspeed = B38400;
 #endif /* TIOCGSERIAL */
@@ -827,7 +841,7 @@
 #if defined(TIOCSSERIAL)
 		/*  It is assumed Win32 does this for us */
 		if (	sstruct.baud_base < 1 ||
-			ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
+		ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
 		{
 			return( 1 );
 		}
Index: termios.c
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v
retrieving revision 1.9.2.56
diff -u -r1.9.2.56 termios.c
--- termios.c	16 Jan 2006 02:50:32 -0000	1.9.2.56
+++ termios.c	3 Jun 2006 23:12:40 -0000
@@ -323,8 +323,8 @@
 		case CBR_3500000:	return( B3500000 );
 		case CBR_4000000:	return( B4000000 );
 		default:
-			set_errno(EINVAL );
-			return -1;
+			/* assume custom baudrate */
+			return( Baud );
 	}
 }
 
@@ -361,12 +361,13 @@
 		case B9600:	ret = CBR_9600;		break;
 		case B14400:	ret = CBR_14400;	break;
 		case B19200:	ret = CBR_19200;	break;
+		case B28800:	ret = CBR_28800;	break;
 		case B38400:	ret = CBR_38400;	break;
 		case B57600:	ret = CBR_57600;	break;
 		case B115200:	ret = CBR_115200;	break;
 		case B128000:	ret = CBR_128000;	break;
-		case B256000: 	ret = CBR_256000;	break;
 		case B230400:	ret = CBR_230400;	break;
+		case B256000: 	ret = CBR_256000;	break;
 		case B460800:	ret = CBR_460800;	break;
 		case B500000:	ret = CBR_500000;	break;
 		case B576000:	ret = CBR_576000;	break;
@@ -381,10 +382,8 @@
 		case B4000000:	ret = CBR_4000000;	break;
 	
 		default:
-			fprintf( stderr, "B_to_CBR: invalid baudrate: %#o\n",
-				Baud );
-			set_errno( EINVAL );
-			return -1;
+			/* assume custom baudrate */
+			return Baud;
 	}
 	LEAVE( "B_to_CBR" );
 	return ret;
@@ -708,12 +707,9 @@
 	ENTER( "init_serial_struct" );
 
 	/*
-	FIXME
-
-	This needs to use inb() to read the actual baud_base
-	and divisor from the UART registers.  Question is how
-	far do we take this?
-
+	use of custom_divisor and baud_base requires access to
+	kernel space.  The kernel does try its best if you just
+	toss a baud rate at it though.
 	*/
 
 	sstruct->custom_divisor = 0;
@@ -1678,16 +1674,17 @@
 {
 	char message[80];
 	ENTER( "cfsetospeed" );
+	/* clear baudrate */
+	s_termios->c_cflag &= ~CBAUD;
 	if ( speed & ~CBAUD )
 	{
 		sprintf( message, "cfsetospeed: not speed: %#o\n", speed );
 		report( message );
-		return 0;
+		/* continue assuming its a custom baudrate */
+		s_termios->c_cflag |= B38400;  /* use 38400 during custom */
+		s_termios->c_cflag |= CBAUDEX; /* use CBAUDEX for custom */
 	}
-	s_termios->c_ispeed = s_termios->c_ospeed = speed;
-	/* clear baudrate */
-	s_termios->c_cflag &= ~CBAUD;
-	if( speed )
+	else if( speed )
 	{
 		s_termios->c_cflag |= speed;
 	}
@@ -1696,6 +1693,7 @@
 		/* PC blows up with speed 0 handled in Java */
 		s_termios->c_cflag |= B9600;
 	}
+	s_termios->c_ispeed = s_termios->c_ospeed = speed;
 	LEAVE( "cfsetospeed" );
 	return 1;
 }
@@ -1767,25 +1765,6 @@
 }
 
 /*----------------------------------------------------------
-serial_struct_to_DCB()
-
-   accept:      
-   perform:     
-   return:      
-   exceptions:  
-   win32api:     None
-   comments:    
-----------------------------------------------------------*/
-int serial_struct_to_DCB( struct serial_struct *sstruct, DCB *dcb )
-{
-	/* 5 Baud rate fix
-	sstruct.baud_base
-	sstruct.custom_divisor = ( sstruct.baud_base/cspeed );
-	*/
-	return(0);
-}
-
-/*----------------------------------------------------------
 termios_to_DCB()
 
    accept:      
@@ -1798,7 +1777,8 @@
 int termios_to_DCB( struct termios *s_termios, DCB *dcb )
 {
 	ENTER( "termios_to_DCB" );
-	s_termios->c_ispeed = s_termios->c_ospeed = s_termios->c_cflag & CBAUD;
+	if ( !(s_termios->c_cflag & CBAUDEX) )
+		s_termios->c_ispeed = s_termios->c_ospeed = s_termios->c_cflag & CBAUD;
 	dcb->BaudRate        = B_to_CBR( s_termios->c_ispeed );
 	dcb->ByteSize = termios_to_bytesize( s_termios->c_cflag );
 
@@ -2863,11 +2843,6 @@
 			GetCommState( index->hComm, dcb );
 
 			index->sstruct = va_arg( ap, struct serial_struct * );
-			if ( serial_struct_to_DCB( index->sstruct, dcb ) < 0 )
-			{
-				va_end( ap );
-				return -1;
-			}
 
 			report( "TIOCSSERIAL\n" );
 			free(dcb);
Index: win32termios.h
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v
retrieving revision 1.5.2.28
diff -u -r1.5.2.28 win32termios.h
--- win32termios.h	30 Jun 2005 20:23:26 -0000	1.5.2.28
+++ win32termios.h	3 Jun 2006 23:12:40 -0000
@@ -279,7 +279,7 @@
 #define XTABS	01000000 /* Hmm.. Linux/i386 considers this part of TABDLY.. */
 
 /* c_cflag bit meaning */
-# define CBAUD	0010017
+#define  CBAUD  0030017
 #define  B0	0000000		/* hang up */
 #define  B50	0000001
 #define  B75	0000002
@@ -312,13 +312,16 @@
 #define  B3500000 0010016
 #define  B4000000 0010017
 
-/* glue for unsupported linux speeds see also SerialImp.h */
-/* hosed */
-
-#define B14400		1010001
-#define B28800		1010002
-#define B128000		1010003
-#define B256000		1010004
+/*
+	glue for unsupported linux speeds see also SerialImp.h 
+	custom baud rates around 8192-9000 will not work because
+	of these.
+*/
+
+#define B14400		0020001
+#define B28800		0020002
+#define B128000		0020003
+#define B256000		0020004
 
 #define EXTA B19200
 #define EXTB B38400
@@ -356,8 +359,10 @@
 
 /* glue for unsupported windows speeds */
 
-#define CBR_230400	230400
 #define CBR_28800	28800
+#define CBR_128000	128000
+#define CBR_230400	230400
+#define CBR_256000	256000
 #define CBR_460800	460800
 #define CBR_500000	500000
 #define CBR_576000	576000

From impakt01 at optusnet.com.au  Sat Jun  3 18:30:37 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 10:30:37 +1000
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
In-Reply-To: <Pine.LNX.4.61.0606031715100.10890@www>
Message-ID: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>

Hi Trent,
I'd love to try the patch but I can't get the latest build compiling, only
pre16. 

Can you attach the rxtxSerial.dll file with this patch?

Also, I hardcoded 1953 in a couple more places last night on pre16 and it
managed to open the port at the right speed, but stopped receiving anything
after 100-150 bytes, even though more data was getting sent to the port.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 10:15 AM
To: rxtx at qbang.org
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.


The attached patch allows baud rates of 14400, 28800, 128000 and 256000.

That was my goal.

[import standard disclaimer]

But I took some time to look a little further.  I got custom baud rates 
working enough that someone (perhaps me) can properly fix them in the 
future.  Proof of concept.

As an undocumented bonus, you can toss random baudrates (say 1953), at the 
API and it will set it to something close to that on windows and linux. 
Solaris should say the baud rate is not supported but I have not tested it 
yet.  Mac OS X behavior is unknown at this point.  Just dont expect 
correct behavior at ~8192-9009 baudrates or baudrates less than 20 on 
windows; these baud rates overlap with defines in win32termios.h.  I 
conveniently closed my eyes there.  Try another value close.  On Linux, a 
baud base and divisor are guestimated and set.  On windows, we wave pixie 
dust over the kernel driver and hope.  Do not expect pixie dust and 
guestimates to be the same on windows and linux.  They may well round to 
different values in yet to be tested ways.  There are only so many 
divisors.  If it isn't working, try a little higher or lower.

In the example of 1953 for instance, there is no divisor for commodity 
hardware that comes to that baudrate.  We just come close on one side or 
the other.  If tools tell you they got 1953 exactly, the tools may be 
questionable and just reading values not directly related to the actual 
hardware settings.

These fixes have been tested on Linux and Windows while using an 
oscilloscope to confirm they change relative to known baudrates at 9600, 
14400*, 19200, 28800* (and 1800, 1953** and 2400).

* = previously unsupported.
** = still not supported but probably works from what I saw.

There could be future discussion in this area.  For now this is working 
for almost all unusual baud rate demands.  Cleaning up the custom baud 
rate should be easier with a working starting point.  Baud bases other 
than 128000 have not been characterized.  Yes.. this overlapps with two of 
the baud rates enabled.

Feedback and ideas are welcome.

--
Trent Jarvi
tjarvi at qbang.org



From tjarvi at qbang.org  Sat Jun  3 19:05:11 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 19:05:11 -0600 (MDT)
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
In-Reply-To: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>
References: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606031840400.10890@www>

On Sun, 4 Jun 2006, Daren wrote:

> Hi Trent,
> I'd love to try the patch but I can't get the latest build compiling, only
> pre16.
>
> Can you attach the rxtxSerial.dll file with this patch?
>
> Also, I hardcoded 1953 in a couple more places last night on pre16 and it
> managed to open the port at the right speed, but stopped receiving anything
> after 100-150 bytes, even though more data was getting sent to the port.
>


ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing

I dont think they will hang.  But I was just testing via loopback/break 
out box/scope.

I'll be putting about 10 patches and another set of binaries in that 
directory shortly.  For now the binaries should just have the baud_rate 
fix.

I'll announce all the patches at once.  but wont be releasing 2.1-8 right 
away.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Sat Jun  3 21:00:01 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 21:00:01 -0600 (MDT)
Subject: [Rxtx] CVS for 2.1 should have everything
Message-ID: <Pine.LNX.4.61.0606032056190.10890@www>


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org


From impakt01 at optusnet.com.au  Sat Jun  3 21:08:14 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 13:08:14 +1000
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <Pine.LNX.4.61.0606032056190.10890@www>
Message-ID: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>

Hi Trent,
I tried the latest dll and it opens the port, receives 100-200 bytes and
then stops receiving anything else..

I'll keep playing with it.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 1:00 PM
To: rxtx at qbang.org
Subject: [Rxtx] CVS for 2.1 should have everything


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From impakt01 at optusnet.com.au  Sat Jun  3 21:22:41 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 13:22:41 +1000
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
Message-ID: <200606040322.k543MqW1008455@mail12.syd.optusnet.com.au>

Played with it, problem, with a while loop in my code, working great now

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Daren
Sent: Sunday, 4 June 2006 1:08 PM
To: 'RXTX Developers and Users'
Subject: Re: [Rxtx] CVS for 2.1 should have everything

Hi Trent,
I tried the latest dll and it opens the port, receives 100-200 bytes and
then stops receiving anything else..

I'll keep playing with it.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 1:00 PM
To: rxtx at qbang.org
Subject: [Rxtx] CVS for 2.1 should have everything


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Sat Jun  3 21:35:41 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 21:35:41 -0600 (MDT)
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
References: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606032131140.10890@www>

On Sun, 4 Jun 2006, Daren wrote:

> Hi Trent,
> I tried the latest dll and it opens the port, receives 100-200 bytes and
> then stops receiving anything else..
>
> I'll keep playing with it.
>
> Daren

The difference may be that I'm talking to something at the exact same baud 
rate (loopback).

You may also try setting the baudrate to ~1933 and ~1973 to force the 
guesses one way or the other.  If you are on windows, we are not doing 
anything fancy in the end.  Thats the kernel guessing.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sun Jun  4 04:12:09 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sun, 4 Jun 2006 12:12:09 +0200
Subject: [Rxtx] Update of OSX installer, Readme, etc
Message-ID: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>

Good day,

after the latest changes a lot of OS X specific files should be  
updated. Especially the installer!

- The "MaxOSX" readme file on the root level is outdated (ie  
CodeWarrior information). Maybe we could even rename it to README.OSX  
to be in line with README.IPAQ, README.SCO (Trent do you mind copying/ 
renaming ,v files in the repository?).

- The lock files are no longer used and hence the user group magic  
and lock folder creation should be removed from the installer.

- MACOSX_IDE/ForPackageMaker/Resources/ReadMe.rtf and Welcome.rtf  
need to be updated.

- I suggest to replace the current installation instruction for OS X:  
Installation should occur into the application directory, not in the  
Java-VM directory. This simplifies things a lot, as the Mac Installer  
can be removed completely.

- The xcodeproject's build settings need to be updated to generate  
JAVA 1.1 format class files.


Dimitry: do you have time to tackle this? I could do it, but as this  
is "your baby" I thought you may prefer to do it yourself.

Regards,
Joachim



From dmarkman at mac.com  Sun Jun  4 11:27:53 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Sun, 4 Jun 2006 13:27:53 -0400
Subject: [Rxtx] Update of OSX installer, Readme, etc
In-Reply-To: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
References: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
Message-ID: <26E7A202-962B-4C19-93B6-29426C467249@mac.com>

Joachim,
unfortunately I don't have time right now to do that
so if you can do that, please do

it's not only my baby
it's yours too :-)

thanks


On Jun 4, 2006, at 6:12 AM, Joachim Buechse wrote:

> Good day,
>
> after the latest changes a lot of OS X specific files should be
> updated. Especially the installer!
>
> - The "MaxOSX" readme file on the root level is outdated (ie
> CodeWarrior information). Maybe we could even rename it to README.OSX
> to be in line with README.IPAQ, README.SCO (Trent do you mind copying/
> renaming ,v files in the repository?).
>
> - The lock files are no longer used and hence the user group magic
> and lock folder creation should be removed from the installer.
>
> - MACOSX_IDE/ForPackageMaker/Resources/ReadMe.rtf and Welcome.rtf
> need to be updated.
>
> - I suggest to replace the current installation instruction for OS X:
> Installation should occur into the application directory, not in the
> Java-VM directory. This simplifies things a lot, as the Mac Installer
> can be removed completely.
>
> - The xcodeproject's build settings need to be updated to generate
> JAVA 1.1 format class files.
>
>
> Dimitry: do you have time to tackle this? I could do it, but as this
> is "your baby" I thought you may prefer to do it yourself.
>
> Regards,
> Joachim
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman



From tjarvi at qbang.org  Sun Jun  4 13:54:02 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 4 Jun 2006 13:54:02 -0600 (MDT)
Subject: [Rxtx] Update of OSX installer, Readme, etc
In-Reply-To: <26E7A202-962B-4C19-93B6-29426C467249@mac.com>
References: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
	<26E7A202-962B-4C19-93B6-29426C467249@mac.com>
Message-ID: <Pine.LNX.4.61.0606041353040.22522@www>

On Sun, 4 Jun 2006, Dmitry Markman wrote:

> Joachim,
> unfortunately I don't have time right now to do that
> so if you can do that, please do
>
> it's not only my baby
> it's yours too :-)
>

I've given Joachim cvs access.  He has shown good work in bugzilla.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Mon Jun  5 10:08:32 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 5 Jun 2006 18:08:32 +0200
Subject: [Rxtx] Build process changes for Mac OS X
Message-ID: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>

Good day,

I have cleaned up some outdated Mac OSX specific build files in the  
repository.

There was not a lot left of the readme file "MacOSX" after cleaning  
it up, so I decided to rename it README.OSX to be in harmony with the  
other files in the directory (ie README.IPAQ, README.SCO, ...)

I added an (uncompressed) XCode 2.3 project file/structure  
with .cvsignore files that will ignore the user specific settings.  
This should work "out of the box" for OSX10.4. Users of 10.2/10.3 may  
have to switch the build settings.

[It's kind of tricky to choose "the right" setting. Afaik there is no  
way to compile a universal binary that will work on 10.3 or before.  
So it's either UniversalBinary OR Legacy. Maybe we should have  
different build targets for these different targets?? I would like to  
get some feedback from the Mac developers on this list regarding the  
subject].

Besides other things the OSX installer is no longer required. Since  
the next version (2.1.8) will no longer use lockfiles on OSX, the  
group/permission magic is no longer required and hence there remains  
basicly no work for the installer - other than copying 2 files to the  
VM extension directory. Then again, this is not the best way to  
install RXTX. So I removed the installer completely without modifying  
it, this should simplify a "resurrection" should it ever get necessary.

I had problems with the (compressed, ie sit.hqx) legacy project files  
on the latest installation of OSX (javac 1.5 creating non JDK1.1  
class files and some minor problems). To reduce potential confusion  
for newcomers I decided to remove them. This means that there is no  
longer a simple way to build RXTX for OSX 10.0 and 10.1 (I deeply  
apologize if anyone still relied on this ... well the files are in  
the Attiq).

Best regards,
Joachim


From joachim at buechse.de  Mon Jun  5 10:16:37 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 5 Jun 2006 18:16:37 +0200
Subject: [Rxtx] RXTX and lockfiles on OSX [it is fixed now]
Message-ID: <7D2C4418-9397-4B59-8091-9FDE4ED67836@buechse.de>

Quite a number of people contacted me in the last couple of weeks  
because of problems installing RXTX on OSX. I told you to wait for  
the "official" fix. Well, it has been fixed.

So if you were among the people waiting for the solution, you can now  
download the source rxtx-2.1-7r2.zip from the website. Once unpacked  
dont forget to use "cvs up" to update the files to the latest  
version. You can then open MACOSX_IDE/XCode/ 
LibSerialUniversal.xcodeproj with XCode 2.3 and build the libraries  
that no longer try to create lock files.

Regards,
Joachim


From brian at mbari.org  Mon Jun  5 10:52:43 2006
From: brian at mbari.org (Brian Schlining)
Date: Mon, 5 Jun 2006 09:52:43 -0700
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
Message-ID: <78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>

Hi Joachim,

> [It's kind of tricky to choose "the right" setting. Afaik there is no
> way to compile a universal binary that will work on 10.3 or before.
> So it's either UniversalBinary OR Legacy. Maybe we should have
> different build targets for these different targets?? I would like to
> get some feedback from the Mac developers on this list regarding the
> subject].

I imagine most developers will be compiling on 10.4 (It's the nature  
of the coder...gotta have the latest and greatest) and deploying to  
both 10.3 and 10.4; both of which will run Universal Binaries (see  
http://forums.macrumors.com/showthread.php?t=205348). So it sounds  
like you've covered the majority of users. Still, you know someone's  
going to pipe up about needing RXTX on 10.2 so it would be nice to  
have a target to make a PPC only build.

Just my 2 cents

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/1cac8c39/attachment-0015.html

From dmarkman at mac.com  Mon Jun  5 13:47:50 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Mon, 5 Jun 2006 15:47:50 -0400
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
Message-ID: <686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>

I don't think it will be a problem to run universal binary
on 10.2
however if binary has some calls that aren't implemented in 10.2
then you'll have a problem


On Jun 5, 2006, at 12:52 PM, Brian Schlining wrote:

> Hi Joachim,
>
>> [It's kind of tricky to choose "the right" setting. Afaik there is no
>> way to compile a universal binary that will work on 10.3 or before.
>> So it's either UniversalBinary OR Legacy. Maybe we should have
>> different build targets for these different targets?? I would like to
>> get some feedback from the Mac developers on this list regarding the
>> subject].
>
> I imagine most developers will be compiling on 10.4 (It's the  
> nature of the coder...gotta have the latest and greatest) and  
> deploying to both 10.3 and 10.4; both of which will run Universal  
> Binaries (see http://forums.macrumors.com/showthread.php?t=205348).  
> So it sounds like you've covered the majority of users. Still, you  
> know someone's going to pipe up about needing RXTX on 10.2 so it  
> would be nice to have a target to make a PPC only build.
>
> Just my 2 cents
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/9fafc878/attachment-0015.html

From brian at mbari.org  Mon Jun  5 14:52:41 2006
From: brian at mbari.org (Brian Schlining)
Date: Mon, 5 Jun 2006 13:52:41 -0700
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
Message-ID: <E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>

Hi Dmitry,

> I don't think it will be a problem to run universal binary
> on 10.2
> however if binary has some calls that aren't implemented in 10.2
> then you'll have a problem

You're right...I stand corrected.

Note however, to deploy a universal binary to 10.2 RXTX will need to  
use the 10.2 SDK to build the PPC side. (see http:// 
developer.apple.com/documentation/DeveloperTools/Conceptual/ 
cross_development/UniversalBinaries/chapter_4_section_1.html). I  
haven't been paying close attention to the new locking mechanism used  
by RXTX on the Mac...does 10.2 support it?

Joachim, which SDK will you be using by default for building the Mac  
PPC binaries?

>> Hi Joachim,
>>
>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>> is no
>>> way to compile a universal binary that will work on 10.3 or before.
>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>> different build targets for these different targets?? I would  
>>> like to
>>> get some feedback from the Mac developers on this list regarding the
>>> subject].
>>
>> I imagine most developers will be compiling on 10.4 (It's the  
>> nature of the coder...gotta have the latest and greatest) and  
>> deploying to both 10.3 and 10.4; both of which will run Universal  
>> Binaries (see http://forums.macrumors.com/showthread.php? 
>> t=205348). So it sounds like you've covered the majority of users.  
>> Still, you know someone's going to pipe up about needing RXTX on  
>> 10.2 so it would be nice to have a target to make a PPC only build.

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/153bf50e/attachment-0015.html

From dmarkman at mac.com  Mon Jun  5 19:02:04 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Mon, 5 Jun 2006 21:02:04 -0400
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
Message-ID: <7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>

if Joachim didn't change xcode project setting

/Developer/SDKs/MacOSX10.4u.sdk is used to build universal binary

so it's quite possible that it won't run properly on 10.2

so we have to change the building process, so ppc part will be built
with
/Developer/SDKs/MacOSX10.2.8.sdk

and finally to use lipo utility to build universal binaries

Joachim, did you use some specific locking API that wasn't implemented

in MacOSX10.2.8.sdk?

thanks


On Jun 5, 2006, at 4:52 PM, Brian Schlining wrote:

> Hi Dmitry,
>
>> I don't think it will be a problem to run universal binary
>> on 10.2
>> however if binary has some calls that aren't implemented in 10.2
>> then you'll have a problem
>
> You're right...I stand corrected.
>
> Note however, to deploy a universal binary to 10.2 RXTX will need  
> to use the 10.2 SDK to build the PPC side. (see http:// 
> developer.apple.com/documentation/DeveloperTools/Conceptual/ 
> cross_development/UniversalBinaries/chapter_4_section_1.html). I  
> haven't been paying close attention to the new locking mechanism  
> used by RXTX on the Mac...does 10.2 support it?
>
> Joachim, which SDK will you be using by default for building the  
> Mac PPC binaries?
>
>>> Hi Joachim,
>>>
>>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>>> is no
>>>> way to compile a universal binary that will work on 10.3 or before.
>>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>>> different build targets for these different targets?? I would  
>>>> like to
>>>> get some feedback from the Mac developers on this list regarding  
>>>> the
>>>> subject].
>>>
>>> I imagine most developers will be compiling on 10.4 (It's the  
>>> nature of the coder...gotta have the latest and greatest) and  
>>> deploying to both 10.3 and 10.4; both of which will run Universal  
>>> Binaries (see http://forums.macrumors.com/showthread.php? 
>>> t=205348). So it sounds like you've covered the majority of  
>>> users. Still, you know someone's going to pipe up about needing  
>>> RXTX on 10.2 so it would be nice to have a target to make a PPC  
>>> only build.
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/84790f80/attachment-0015.html

From joachim at buechse.de  Tue Jun  6 02:40:47 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 6 Jun 2006 10:40:47 +0200
Subject: [Rxtx] Building on OS X, Impl Changes
In-Reply-To: <7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
Message-ID: <CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>

Good day!

What's in the XCode project setting?
----------

The xcode project remained pretty much the same as before. I excluded  
the user specific files from CVS and changed some settings. I kept  
all the built targets (you shouldn't change what you don't understand;-)

Currently we the following build targets:
    RXTXComm (java files)
    librxtxParallel.jnilib (usefull on the Mac???)
    libI2C.jnilib (not yet working in RXTX)
    libRS485.jnilib (not yet working in RXTX)
    librxtxSerial.jnilib (1)
    librxtxSerial.jnilib Dynamic (2)
    rxtxSerial (3)
We also have the following build configurations for each target:
    Development
    Default
    Deployment

What was changed in the xcode project from previous versions:
- java.souce=1.3 and java.target=1.1 in RXTXComm settings
- removed copying of build products into installer directory
- removed "(Upgraded)" from build target names

What remains to be changed:
- choosing a "non-debug" Build-configuration as default
- potentially removing "Default"/"Development" Build-configurations
- reducing the number of build targets
- creating 10.2 compatible universal binaries

I suggest, that the build configurations should be reduced to 2  
(Debug/Deployment), possibly even 1 (Debug).
I have not yet found the deeper meaning of the build targets(1)(2) 
(3), it seems to me like they should be reduced into one "doing the  
right thing" or maybe into two "rxtxSerial.jnilib Legacy" (back to  
10.2, universal if possible) and "rxtxSerial.jnilib 10.4 
+" (universal, 10.4+).

Should the code work on 10.2?
----------

Absolutely. The code should work on NextStep, in fact on any BSD  
unix. I would go as far as saying, this code should work on any  
POSSIX based unix. All that was added is the call "ioctl(fd,  
TIOCEXCL)" to request excusivity of the port:

http://gemma.apple.com/documentation/DeviceDrivers/Conceptual/ 
WorkingWSerial/WWSerial_SerialDevs/chapter_2_section_8.html

It is not yet "the perfect solution". Normally an open /dev/tty  
(listen for incomming connection) should be "preemptable" by opening  
a /dev/cu (outgoing connection) for the same port. This is not yet  
implemented as it needs calls outside of POSSIX on OSX.

On "classic" systems (like NextStep) this worked based on the  
"carried detect line". open() on /dev/tty.xxx would block until the  
carrier detect signal was raised. As the device was not "opened"  
opening /dev/cu.xxx worked without a hitch. When they ported to the  
Mac this broke. On Macs the "carier detect" is usually not wired.  
Furthermore FAX modems did no longer raise the line. So the OSX  
implementor defined a new call, which is documented here:

http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00045.html

Best regards,
Joachim




On 06.06.2006, at 03:02, Dmitry Markman wrote:

> if Joachim didn't change xcode project setting
>
> /Developer/SDKs/MacOSX10.4u.sdk is used to build universal binary
>
> so it's quite possible that it won't run properly on 10.2
>
> so we have to change the building process, so ppc part will be built
> with
> /Developer/SDKs/MacOSX10.2.8.sdk
>
> and finally to use lipo utility to build universal binaries
>
> Joachim, did you use some specific locking API that wasn't implemented
>
> in MacOSX10.2.8.sdk?
>
> thanks
>
>
> On Jun 5, 2006, at 4:52 PM, Brian Schlining wrote:
>
>> Hi Dmitry,
>>
>>> I don't think it will be a problem to run universal binary
>>> on 10.2
>>> however if binary has some calls that aren't implemented in 10.2
>>> then you'll have a problem
>>
>> You're right...I stand corrected.
>>
>> Note however, to deploy a universal binary to 10.2 RXTX will need  
>> to use the 10.2 SDK to build the PPC side. (see http:// 
>> developer.apple.com/documentation/DeveloperTools/Conceptual/ 
>> cross_development/UniversalBinaries/chapter_4_section_1.html). I  
>> haven't been paying close attention to the new locking mechanism  
>> used by RXTX on the Mac...does 10.2 support it?
>>
>> Joachim, which SDK will you be using by default for building the  
>> Mac PPC binaries?
>>
>>>> Hi Joachim,
>>>>
>>>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>>>> is no
>>>>> way to compile a universal binary that will work on 10.3 or  
>>>>> before.
>>>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>>>> different build targets for these different targets?? I would  
>>>>> like to
>>>>> get some feedback from the Mac developers on this list  
>>>>> regarding the
>>>>> subject].
>>>>
>>>> I imagine most developers will be compiling on 10.4 (It's the  
>>>> nature of the coder...gotta have the latest and greatest) and  
>>>> deploying to both 10.3 and 10.4; both of which will run  
>>>> Universal Binaries (see http://forums.macrumors.com/ 
>>>> showthread.php?t=205348). So it sounds like you've covered the  
>>>> majority of users. Still, you know someone's going to pipe up  
>>>> about needing RXTX on 10.2 so it would be nice to have a target  
>>>> to make a PPC only build.
>>
>> Brian Schlining
>> Software Engineer
>> http://www.mbari.org
>>
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> Dmitry Markman
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Tue Jun  6 07:01:06 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 6 Jun 2006 15:01:06 +0200
Subject: [Rxtx] Serial port code for OS X, future steps
In-Reply-To: <CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
	<CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
Message-ID: <8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>

I posted the "wrong link". There is a correction here:

    http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00059.html

In fact, the 2.1.7 implementation of RXTX has quite some deficiencies  
on OSX. I have tried to supply some patches that don't interfere to  
much with the existing RXTX code base, but there are limits to what  
can be done with local patches.

There are some very intrusive changes that should be done. Ie proper  
mapping of /dev/tty <-> /dev/cu handling to correct behaviour of  
CommPortOwnershipListener (http://java.sun.com/products/javacomm/ 
reference/api/index.html). I dont think this can be done with  
patches. Hence I think, RXTX should be rewritten from scratch de- 
unifying the native code base (and implementing thread safe code on  
the Java side).


How "should" /dev/tty vs /dev/cu be implemented?

=====
The Unix contract is this: An open /dev/tty.xxx port (incomming)  
should be interrupted/auto-closed when opening /dev/cu.xxx (outgoing)  
[if /dev/tty.xxx is not currently handling a communication].  /dev/ 
cu.xxx and /dev/tty.xxx refer to the same device, so owning  
"exclusively" should block both. This should be respected across all  
applications native or Java.

This contract is realizable on OSX with the existing javax.comm  
interface while also respecting (to the biggest part) the contract  
defined by javax.comm.PortOwnershipListener.

The one point where the suggested implementation "breaks" the  
javax.comm contract, is by the fact that one can loose a /dev/tty  
port without calling close. However, the only option I see is to  
always open serial ports "non-exclusively" which would outrule Java  
as a platform for (dormant) applications waiting for incoming  
connections/faxes/etc. There could be a system property to choose the  
intended behavior.
=====

Here is how it could be done on OSX:

Calling port=ComportIdentifier.open("/dev/cu.xxx") opens and owns the  
port exclusively until port.close() is called.
- Java applications listening with a PortOwnershipListener should get  
a PORT_OWNED event reasonably soon.
- Any further attempt by a Java or native application to open "/dev/ 
cu.xxx" or "/dev/tty.xxx" fails.
- /dev/cu.xxx is for "outgoing" connections, so receiving  
PORT_OWNERSHIP_REQUESTED makes little to no sense. With native  
applications it can not be implemented. For Java applications it  
could be implemented (by a hidden communication channel). I think  
it's not worth bothering. If anyone is willing to give up a port to  
others he should use /dev/tty.xxx instead of /dev/cu.xxx.

Registering a PortOwnershipListener on "/dev/cu.xxx" without opening  
it, uses /dev/tty.xxx (native open()) non-exclusively and polls its  
state. PORT_OWNED and PORT_UNOWNED can be produced.

Calling port=ComportIdentifier.open("/dev/tty.xxx") should open the  
port non-exclusively.
- Adding a SerialPortEventListener and reading from the port could be  
allowed while keeping it non-exclusive.
- When port.getOutputStream() is called, the state should be changed  
to an "exclusive" ownership. This may be configurable via a system  
property.
- To return to the non-exclusive state the port must be closed and  
reopened.
- While non-exclusively opened, opening the corresponding /dev/cu.xxx  
produces a PORT_OWNERSHIP_REQUESTED event. Which should be responded  
by closing the port from within the callback (as described in  
java.comm.PortOwnershipListener). If there is a pending read, it will  
return after the listener finishes (with -1 or "0 bytes read").
- Calling write() on the /dev/tty.xxx after somebody opened /dev/ 
cu.xxx will fail with a descriptive IOException.
- Calling read() on the /dev/tty.xxx after somebody opened /dev/ 
cu.xxx will fail with a descriptive IOException (or potentially  
block, see side notes below).

CommPortIdentifier.getCurrentOwner() can be implemented by an  
external call to lsof.

CommPortIdentifier.isCurrentlyOwned() can be implemented by trying an  
open on the /dev/tty.
- It returns true if the port is currently held "exclusively".
- Whether it should also return true on /dev/tty if /dev/tty is  
already opened non-exclusively might be a system property option. In  
general, having several applications waiting for incoming connections  
on the same port will require an application level "arbitration"  
protocol...

[[side note1: One interesting question is, what happens if the  
process holding /dev/tty non-exclusively ignores  
PORT_OWNERSHIP_REQUESTED. Ie after "loosing" a non-exclusively opened  
"dev/tty.xxx" port to another process. One possible implementation  
is, that the port is "regained" when the other process gives up the  
port. This would mean that in the meanwhile read() returns no data,  
and any changes to the configuration of the port are stored but not  
forwarded. I guess, the safe (and simple) way to do this is to make  
the close() mandatory (ie setting the port into an "awaiting_close"  
state which produces IOExceptions to any other call than close). ]]

[[side note2:  Another interesting question is, what should happen if  
several applications open the same /dev/tty.xxx port "non- 
exclusively" and start to change the settings of the device.]]

Regards,
Joachim



On 06.06.2006, at 10:40, Joachim Buechse wrote:

> Should the code work on 10.2?
> ----------
>
> Absolutely. The code should work on NextStep, in fact on any BSD
> unix. I would go as far as saying, this code should work on any
> POSSIX based unix. All that was added is the call "ioctl(fd,
> TIOCEXCL)" to request excusivity of the port:
>
> http://gemma.apple.com/documentation/DeviceDrivers/Conceptual/
> WorkingWSerial/WWSerial_SerialDevs/chapter_2_section_8.html
>
> It is not yet "the perfect solution". Normally an open /dev/tty
> (listen for incomming connection) should be "preemptable" by opening
> a /dev/cu (outgoing connection) for the same port. This is not yet
> implemented as it needs calls outside of POSSIX on OSX.
>
> On "classic" systems (like NextStep) this worked based on the
> "carried detect line". open() on /dev/tty.xxx would block until the
> carrier detect signal was raised. As the device was not "opened"
> opening /dev/cu.xxx worked without a hitch. When they ported to the
> Mac this broke. On Macs the "carier detect" is usually not wired.
> Furthermore FAX modems did no longer raise the line. So the OSX
> implementor defined a new call, which is documented here:
>
> http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00045.html
>
> Best regards,
> Joachim



From sds at dcs.gla.ac.uk  Tue Jun  6 11:22:45 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Tue, 06 Jun 2006 18:22:45 +0100
Subject: [Rxtx] Correct compile flag for HP iPAQ hx4700 running Familiar
	Linux?
Message-ID: <1149614565.19496.10.camel@addu>

Hi,

I'd like to use RXTX 2.1 on my HP iPAQ hx4700. The iPAQ is running
Familiar Linux 0.8.2 (as I recall), with Blackdown Java 1.3.1.

I can compile and run a test program which uses RXTX on my i686 machine,
and it works fine. But I can't seem to get things working quite right on
my PDA.

I compile the code on the laptop with the following commands:
	./configure --host=arm-gnu-linux && make
... as suggested in a post to this list, albeit some time ago. This
compiles, I transfer the files, set up LD_LIBRARY_PATH and CLASSPATH
variables, and get the following error on the PDA:

sds at ipaq-pxa-2:~# java Test
java.lang.UnsatisfiedLinkError: /usr/local/lib/ext/librxtxSerial.so: /usr/local/lib/ext/librxtxSerial.so: cannot open shared object file: No such file or directory thrown while loading gnu.io.RXTXCommDriver
Exception in thread "main"
java.lang.UnsatisfiedLinkError: /usr/local/lib/ext/librxtxSerial.so: /usr/local/lib/ext/librxtxSerial.so: cannot open shared object file: No such file or directory
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1382)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1290)
        at java.lang.Runtime.loadLibrary0(Runtime.java:749)
        at java.lang.System.loadLibrary(System.java:820)
        at
gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:83)
        at Test.<init>(Test.java:9)
        at Test.main(Test.java:32)
sds at ipaq-pxa-2:~# 

Note that I'm copying the files to /usr/local/lib/ext/ along with the
RXTXcomm.jar file, purely to keep things separate from the rest of the
system while testing. The location of the .so files doesn't seem to have
any bearing on whether "java Test" will succeed or not. The contents of
this directory are:

sds at ipaq-pxa-2:~$ ls /usr/local/lib/ext/
RXTXcomm.jar              librxtxParallel-2.1-7.so  librxtxRS485.so
librxtxSerial-2.1-7.so
librxtxI2C-2.1-7.so       librxtxParallel.so        librxtxRaw-2.1-7.so
librxtxSerial.so
librxtxI2C.so             librxtxRS485-2.1-7.so     librxtxRaw.so
sds at ipaq-pxa-2:~$

Test.java fails on the first real line of code I'm using to test that
things are working, prior to real development, and was carefully pinched
from the web:
Enumeration portIdentifiers = CommPortIdentifier.getPortIdentifiers();


I assume that I've gotten my --host flag wrong way back up there at
the ./configure step. But if that's the case, what should I set it to?
Or am I missing something more obvious?


Cheers,
Stephen Strowes,
University of Glasgow.




From tjarvi at qbang.org  Tue Jun  6 13:39:41 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 6 Jun 2006 13:39:41 -0600 (MDT)
Subject: [Rxtx] Serial port code for OS X, future steps
In-Reply-To: <8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
	<CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
	<8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>
Message-ID: <Pine.LNX.4.61.0606061315070.9856@www>


>>
There are some very intrusive changes that should be done. Ie proper
mapping of /dev/tty <-> /dev/cu handling to correct behaviour of
CommPortOwnershipListener (http://java.sun.com/products/javacomm/
reference/api/index.html). I dont think this can be done with
patches. Hence I think, RXTX should be rewritten from scratch de-
unifying the native code base (and implementing thread safe code on
the Java side).
<<

This appears to be a very small amount of functionality for a total 
rewrite.  The port ownership only needs maybe 3 native calls if it is done 
with native calls at all.

Those features which are not part of the Unix standard(s) can be special 
cased.  I'm not sure /dev/cu is standard.  We can look.  I know linux 
deprecated /dev/cua years ago.

Thread safe Java code is not a platform specific issue.

--
Trent Jarvi
tjarvi at qbang.org


From sds at dcs.gla.ac.uk  Wed Jun  7 12:36:43 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Wed, 07 Jun 2006 19:36:43 +0100
Subject: [Rxtx] Expected RXTX behaviour?
In-Reply-To: <1149703900.30891.19.camel@addu>
References: <1149703900.30891.19.camel@addu>
Message-ID: <1149705403.30891.25.camel@addu>

Apologies, caught the problem. Had to append '\r' to the end of the AT
string. A non obvious but stupid mistake... :-)

Final quick question though: How might I stop the echoing of
outputStream data back into the inputStream? I still see the ATI
commands on the inputStream, along with the output from the device.


Cheers,
S.



On Wed, 2006-06-07 at 19:11 +0100, Stephen Strowes wrote:
> Hi,
> 
> I managed to get RXTX to compile for my iPAQ following my previous post
> to this list. Quick query though:
> 
> I want to be able to issue AT commands to a device, and interpret the
> responses. For this, I assume I do the following, in psuedo-form:
> 
> 	CommPortIdentifier.getPortIdentifiers();
> 	// find the correct device id
> 	serialPort= (SerialPort)portID.open("Test");
> 	// Set parameters and flow control
> 	outputStream= serialPort.getOutputStream();
> 	inputStream=  serialPort.getInputStream();
> 
> ... following this, I spawn a thread to respond to DATA_AVAILABLE events
> on serialPort with inputStream, and occasionally write and flush an
> "ATI" onto the outputStream. Nothing complex, I just want to see it
> work.
> 
> I would have expected inputStream to give the same information back from
> an "ATI" command as minicom provides, but instead inputStream only sees
> the "ATI" I put onto the outputStream.
> 
> Have I missed something?
> 
> 
> Cheers,
> S.
> 



From sds at dcs.gla.ac.uk  Wed Jun  7 12:11:40 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Wed, 07 Jun 2006 19:11:40 +0100
Subject: [Rxtx] Expected RXTX behaviour?
Message-ID: <1149703900.30891.19.camel@addu>

Hi,

I managed to get RXTX to compile for my iPAQ following my previous post
to this list. Quick query though:

I want to be able to issue AT commands to a device, and interpret the
responses. For this, I assume I do the following, in psuedo-form:

	CommPortIdentifier.getPortIdentifiers();
	// find the correct device id
	serialPort= (SerialPort)portID.open("Test");
	// Set parameters and flow control
	outputStream= serialPort.getOutputStream();
	inputStream=  serialPort.getInputStream();

... following this, I spawn a thread to respond to DATA_AVAILABLE events
on serialPort with inputStream, and occasionally write and flush an
"ATI" onto the outputStream. Nothing complex, I just want to see it
work.

I would have expected inputStream to give the same information back from
an "ATI" command as minicom provides, but instead inputStream only sees
the "ATI" I put onto the outputStream.

Have I missed something?


Cheers,
S.




From joachim at buechse.de  Wed Jun  7 09:02:13 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 7 Jun 2006 17:02:13 +0200
Subject: [Rxtx] Update of build process for OSX (XCode project)
Message-ID: <62EC47B1-46BD-4ECA-B9EC-C4061D147CDA@buechse.de>

With the help of Dmitry Markman and Brian Schilling I have updated  
(and largely simplifed) the XCode project file for Mac OS X.

Changes:
- compiles a universal binary library with intel=OSX10.4+, ppc=OSX10.2 
+ support
- compiles the Java sources into a JRE1.1 compatible, compressed jar.

Please test on your configuration, especially if you have computers  
running 10.2/10.3 or intel.

Best regards,
Joachim


From joachim at buechse.de  Wed Jun  7 14:36:37 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 7 Jun 2006 22:36:37 +0200
Subject: [Rxtx] Expected RXTX behaviour?
In-Reply-To: <1149705403.30891.25.camel@addu>
References: <1149703900.30891.19.camel@addu> <1149705403.30891.25.camel@addu>
Message-ID: <D3AD6EAF-27BB-455E-9697-86C1121920C3@buechse.de>

Echoing is a feature of the modem. Try ATE0 which works with most  
"rockwell" compatible modems.

Regards,
Joachim


On 07.06.2006, at 20:36, Stephen Strowes wrote:

> Apologies, caught the problem. Had to append '\r' to the end of the AT
> string. A non obvious but stupid mistake... :-)
>
> Final quick question though: How might I stop the echoing of
> outputStream data back into the inputStream? I still see the ATI
> commands on the inputStream, along with the output from the device.
>
>
> Cheers,
> S.
>
>
>
> On Wed, 2006-06-07 at 19:11 +0100, Stephen Strowes wrote:
>> Hi,
>>
>> I managed to get RXTX to compile for my iPAQ following my previous  
>> post
>> to this list. Quick query though:
>>
>> I want to be able to issue AT commands to a device, and interpret the
>> responses. For this, I assume I do the following, in psuedo-form:
>>
>> 	CommPortIdentifier.getPortIdentifiers();
>> 	// find the correct device id
>> 	serialPort= (SerialPort)portID.open("Test");
>> 	// Set parameters and flow control
>> 	outputStream= serialPort.getOutputStream();
>> 	inputStream=  serialPort.getInputStream();
>>
>> ... following this, I spawn a thread to respond to DATA_AVAILABLE  
>> events
>> on serialPort with inputStream, and occasionally write and flush an
>> "ATI" onto the outputStream. Nothing complex, I just want to see it
>> work.
>>
>> I would have expected inputStream to give the same information  
>> back from
>> an "ATI" command as minicom provides, but instead inputStream only  
>> sees
>> the "ATI" I put onto the outputStream.
>>
>> Have I missed something?
>>
>>
>> Cheers,
>> S.
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From g_petrini at yahoo.it  Thu Jun  8 01:41:58 2006
From: g_petrini at yahoo.it (Giacomo Petrini)
Date: Thu, 8 Jun 2006 09:41:58 +0200 (CEST)
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from FieldTalk
Message-ID: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>

Hi,
I'm evaluating the library for the modbus protocol
from FieldTalk
(http://www.modbusdriver.com/fieldtalk/.
I'm using J2SE 5.0 and RXTX 2.1 on win XP.
The problem is that the modbus lib has a method (the
openProtocol method, but maybe there are others) tha
throws the
javax.comm.UnsupportedCommOperationException.
Now, in RXTX 2.1 the namespace has changed in gnu.io,
so the modbus library doesn't work anymore (it look
for things in javax.comm). I've already sent an email
to fieldtalk to see if they are aware of the problem.
The solution should be to use JavaComm + RXTX 2.0. But
I've read somewhere that JavaComm 2.0 does not work
with Java 5.0 and JavaComm 3.0 does not work with RXTX
2.0 so I don't know what to do.

Any ideas?

Thanks Jack

PS: can you make a CC to my personal email
(g_petrini at yahoo.it) too please?

Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 


From rxtx at tapastda.co.uk  Thu Jun  8 02:27:57 2006
From: rxtx at tapastda.co.uk (rxtx@tapastda.co.uk)
Date: Thu, 08 Jun 2006 09:27:57 +0100
Subject: [Rxtx] Win XP and Infrared based serial port
Message-ID: <4487DF8D.5050807@tapastda.co.uk>

I'm attempting to use RXTX 2.1.7 on Win XP with J2SE 5.0 to communicate with a
GSM mobile using a COM port. A peculiarity that I've seen is that whilst I can
communicate successfully with a mobile which uses an infrared based COM port
using the SUN provided javax.comm (v2.0) I cannot use RXTX because it fails to
read anything from the port (i.e. read timeout always occurs returning zero bytes).

I assumed that this could be the result of flow control problems and thus I've
tried setting either software or hardware based flow control on the port however
this has no affect.

Can you suggest any other port configuration changes which might be required to
make such a port work with RXTX.

Thanks
Stu
-- 
Stuart
Tapastda Limited


From tjarvi at qbang.org  Thu Jun  8 05:17:12 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 8 Jun 2006 05:17:12 -0600 (MDT)
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from
	FieldTalk
In-Reply-To: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
References: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606080504480.9856@www>

On Thu, 8 Jun 2006, Giacomo Petrini wrote:

> Hi,
> I'm evaluating the library for the modbus protocol
> from FieldTalk
> (http://www.modbusdriver.com/fieldtalk/.
> I'm using J2SE 5.0 and RXTX 2.1 on win XP.
> The problem is that the modbus lib has a method (the
> openProtocol method, but maybe there are others) tha
> throws the
> javax.comm.UnsupportedCommOperationException.
> Now, in RXTX 2.1 the namespace has changed in gnu.io,
> so the modbus library doesn't work anymore (it look
> for things in javax.comm). I've already sent an email
> to fieldtalk to see if they are aware of the problem.
> The solution should be to use JavaComm + RXTX 2.0. But
> I've read somewhere that JavaComm 2.0 does not work
> with Java 5.0 and JavaComm 3.0 does not work with RXTX
> 2.0 so I don't know what to do.
>
> Any ideas?
>
> Thanks Jack
>


Hi Jack

There are plans for Sun to rerelease JavaComm 2.0 mentioned in the rxtx 
mail-list archives.  When this happens rxtx will release a current rxtx 
2.0 library that works with it.

There are no dates promised by either side but rxtx will do it as soon as 
possible after Sun's rerelease.  Just to give you a feel for the time 
frame, this started last year and no significant progress has been made. 
There have been friendly talks pointing towards solutions (rerelease 2.0) 
but that does not get your application working today.  rxtx is preparing 
for its second release in gnu.io since then.

--
Trent Jarvi
tjarvi at qbang.org




From jredman at ergotech.com  Thu Jun  8 08:47:23 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 08 Jun 2006 08:47:23 -0600
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from
	FieldTalk
In-Reply-To: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
References: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
Message-ID: <4488387B.6040903@ergotech.com>

You could always try a different library, eg.

http://sourceforge.net/projects/jamod

I've only used the slave side since we have our own implementation of 
Modbus Client (and a host of other PLC protocols).  However the client 
side seems to be pretty well supported and fairly widely used.  Since 
the source is there you could change to gnu.io.

I think I should take more of an interest in this issue.  We generally 
run 1.4.2 on Linux, but also have some J9 and old platforms that we 
support that are basically Personal Java.  5.0 on Linux has some 
horrible MDI bugs, to the point of being unusable.   Sounds as though we 
are going to have code compatibility problems across these platforms.

Jim


Giacomo Petrini wrote:
> Hi,
> I'm evaluating the library for the modbus protocol
> from FieldTalk
> (http://www.modbusdriver.com/fieldtalk/.
> I'm using J2SE 5.0 and RXTX 2.1 on win XP.
> The problem is that the modbus lib has a method (the
> openProtocol method, but maybe there are others) tha
> throws the
> javax.comm.UnsupportedCommOperationException.
> Now, in RXTX 2.1 the namespace has changed in gnu.io,
> so the modbus library doesn't work anymore (it look
> for things in javax.comm). I've already sent an email
> to fieldtalk to see if they are aware of the problem.
> The solution should be to use JavaComm + RXTX 2.0. But
> I've read somewhere that JavaComm 2.0 does not work
> with Java 5.0 and JavaComm 3.0 does not work with RXTX
> 2.0 so I don't know what to do.
> 
> Any ideas?
> 
> Thanks Jack
> 
> PS: can you make a CC to my personal email
> (g_petrini at yahoo.it) too please?
> 
> Chiacchiera con i tuoi amici in tempo reale! 
>  http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  8 18:17:23 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 08 Jun 2006 17:17:23 -0700
Subject: [Rxtx] rxtx access is denied error
Message-ID: <4488BE13.2050706@dupreeinc.com>

Hello,

I have been trying to replace the commapi from sun with rxtx for a 
project that communicates with a serial port that is a USB-Serial 
interface.  To be exact, I am using the FTDI VCP driver with one of 
their modules connected to a windows XP system.

I have the RXTX package working pretty well as long as nothing goes wrong.

If a user disconnects the USB port while my java application is running, 
my application goes into an endless loop with lots of messages in the  
errors stream  like the ones below:

    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(481):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.


I believe when this happens the COM port completely disappears and the 
rxtx driver has a heart attack.  Obviously, the user should not do this, 
but my application needs to ideally, correct the situation or as a worse 
case, terminate with a little dignity.  Currently, I have not figured 
out how to catch this error.

The closest I have come is to trap an exception to my input stream read  
that says "No error in readByte"  This error appears to be outside of 
the endless loop of the errors listed above.

Does anybody have an idea of how to identify and trap this error?  Any 
suggestions on how to gracefully recover from it would be greatly 
appreciated!

Thank you for your time,

Doug Thistlethwaite




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060608/9cfca302/attachment-0015.html

From tjarvi at qbang.org  Thu Jun  8 20:54:17 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 8 Jun 2006 20:54:17 -0600 (MDT)
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <4488BE13.2050706@dupreeinc.com>
References: <4488BE13.2050706@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606082022580.1323@www>

On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I have been trying to replace the commapi from sun with rxtx for a project 
> that communicates with a serial port that is a USB-Serial interface.  To be 
> exact, I am using the FTDI VCP driver with one of their modules connected to 
> a windows XP system.
>
> I have the RXTX package working pretty well as long as nothing goes wrong.
>
> If a user disconnects the USB port while my java application is running, my 
> application goes into an endless loop with lots of messages in the  errors 
> stream  like the ones below:
>
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(481):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>
>
> I believe when this happens the COM port completely disappears and the rxtx 
> driver has a heart attack.  Obviously, the user should not do this, but my 
> application needs to ideally, correct the situation or as a worse case, 
> terminate with a little dignity.  Currently, I have not figured out how to 
> catch this error.
>
> The closest I have come is to trap an exception to my input stream read  that 
> says "No error in readByte"  This error appears to be outside of the endless 
> loop of the errors listed above.
>
> Does anybody have an idea of how to identify and trap this error?  Any 
> suggestions on how to gracefully recover from it would be greatly 
> appreciated!
>

Hi Doug

Sadly I don't have a quick solution for you.

Termios has no knowlage about the JVM so it wont be throwing exceptions 
you can catch.

We can return error and set the error number to something reasonable that 
results in an exception.  The No Error message simply means we did not set 
an error number in termios.c.  Those are the line numbers in the code you 
see.  SerialImp.c realizes it errored but does not know much more yet. 
Everything touching the file descriptor is going to error after the port 
is gone presumably.

We don't currently have a plan in place for vanishing (or appearing) com 
ports.

Another example of what we need to think about is what happens if you 
start your application and then plug in the dongle?  Or what if you unplug 
and then plug it in again?

So in each of these three cases, what would the behavior of the (yet to 
be) correct implementation do?

How will the enumerated ports be handled during these changes?

There can also be hints from the OS that could be taken into 
consideration.

We can probably get some exceptions thrown that make sense and null the 
file descriptor when it happens to prevent io attempts.  That would be a 
crude way to let applications know something strange has happened.

Is anyone else tinkering with this problem?

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  9 01:31:29 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 9 Jun 2006 09:31:29 +0200
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <Pine.LNX.4.61.0606082022580.1323@www>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
Message-ID: <AC6EDDDD-0A64-401F-B16B-E484788CDF4A@buechse.de>

Hello Trent,

I am not tinkering with this on the Source Level - but I think it  
should work pretty much the same way as it currently does in OSX.  
When the port goes away you get an IOException thrown for any read/ 
write. It will no longer be in the list of ports from  
CommPortIdentifier.getPortIdentifiers(). When a port (re-)appears it  
is added to the list. It's up to the application to re-check the list  
from time to time.

On Windows you can't do much better then that, because the ports  
don't have useful names. Which USB "virtual com port" is on which  
COMx depends on the order the devices were added. So reconnecting to  
the same device may mean connecting to another port.

Regarding the exception thrown: it would be nice to use an  
IOException subclass but the Exception message should definetly be  
informative also as most applications may want to keep compatibility  
with javax.comm.

Regards,
Joachim


On 09.06.2006, at 04:54, Trent Jarvi wrote:

> On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:
>
>> Hello,
>>
>> I have been trying to replace the commapi from sun with rxtx for a  
>> project
>> that communicates with a serial port that is a USB-Serial  
>> interface.  To be
>> exact, I am using the FTDI VCP driver with one of their modules  
>> connected to
>> a windows XP system.
>>
>> I have the RXTX package working pretty well as long as nothing  
>> goes wrong.
>>
>> If a user disconnects the USB port while my java application is  
>> running, my
>> application goes into an endless loop with lots of messages in  
>> the  errors
>> stream  like the ones below:
>>
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (481):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>
>>
>> I believe when this happens the COM port completely disappears and  
>> the rxtx
>> driver has a heart attack.  Obviously, the user should not do  
>> this, but my
>> application needs to ideally, correct the situation or as a worse  
>> case,
>> terminate with a little dignity.  Currently, I have not figured  
>> out how to
>> catch this error.
>>
>> The closest I have come is to trap an exception to my input stream  
>> read  that
>> says "No error in readByte"  This error appears to be outside of  
>> the endless
>> loop of the errors listed above.
>>
>> Does anybody have an idea of how to identify and trap this error?   
>> Any
>> suggestions on how to gracefully recover from it would be greatly
>> appreciated!
>>
>
> Hi Doug
>
> Sadly I don't have a quick solution for you.
>
> Termios has no knowlage about the JVM so it wont be throwing  
> exceptions
> you can catch.
>
> We can return error and set the error number to something  
> reasonable that
> results in an exception.  The No Error message simply means we did  
> not set
> an error number in termios.c.  Those are the line numbers in the  
> code you
> see.  SerialImp.c realizes it errored but does not know much more yet.
> Everything touching the file descriptor is going to error after the  
> port
> is gone presumably.
>
> We don't currently have a plan in place for vanishing (or  
> appearing) com
> ports.
>
> Another example of what we need to think about is what happens if you
> start your application and then plug in the dongle?  Or what if you  
> unplug
> and then plug it in again?
>
> So in each of these three cases, what would the behavior of the  
> (yet to
> be) correct implementation do?
>
> How will the enumerated ports be handled during these changes?
>
> There can also be hints from the OS that could be taken into
> consideration.
>
> We can probably get some exceptions thrown that make sense and null  
> the
> file descriptor when it happens to prevent io attempts.  That would  
> be a
> crude way to let applications know something strange has happened.
>
> Is anyone else tinkering with this problem?
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From doug at dupreeinc.com  Fri Jun  9 13:09:58 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 09 Jun 2006 12:09:58 -0700
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <Pine.LNX.4.61.0606082022580.1323@www>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
Message-ID: <4489C786.9050504@dupreeinc.com>


Ideally, it would be nice if it would throw an exception and terminate 
the loop.  I am still trying to figure out how to detect the condition 
and recover form it in some form...  I am getting the "No error in 
readByte" exception in my serialEvent() method after an input stream 
read.  It appears to me that the only graceful recovery is to close the 
port and then reopen it when it becomes available.  I can pass the event 
up to the update method in my main frame, but I still can't close the 
port from within that thread.  Any suggestions on how to pass this event 
to a location where the port can be safely closed?

Re: Slow startup in windows XP
I have been looking into this a little closer and have found out the 
following:
System Windows XP Pro 3GHz dual core with 1GB RAM and NO parallel port.
Starting the SerialDemo included with the commapi using the rxtx instead 
of javax.comm takes 60 seconds.
Starting the SerialDemo using rxrx with the rxtxParallel.dll file 
removed takes about 20 seconds.
Modify initialize in RXRXCommDriver.java to not test the parallel ports 
takes less than 1 second.

It would be nice if the initialize routine could detect the presence of 
rxtxParallel.dll file and just skip the whole process if not present.  
Is there an easy way to check for the presence of this file without 
running the parallel port test?

Doug


 

Trent Jarvi wrote:

>On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:
>...
>  
>
>
>Hi Doug
>
>Sadly I don't have a quick solution for you.
>
>Termios has no knowlage about the JVM so it wont be throwing exceptions 
>you can catch.
>
>We can return error and set the error number to something reasonable that 
>results in an exception.  The No Error message simply means we did not set 
>an error number in termios.c.  Those are the line numbers in the code you 
>see.  SerialImp.c realizes it errored but does not know much more yet. 
>Everything touching the file descriptor is going to error after the port 
>is gone presumably.
>
>We don't currently have a plan in place for vanishing (or appearing) com 
>ports.
>
>Another example of what we need to think about is what happens if you 
>start your application and then plug in the dongle?  Or what if you unplug 
>and then plug it in again?
>
>So in each of these three cases, what would the behavior of the (yet to 
>be) correct implementation do?
>
>How will the enumerated ports be handled during these changes?
>
>There can also be hints from the OS that could be taken into 
>consideration.
>
>We can probably get some exceptions thrown that make sense and null the 
>file descriptor when it happens to prevent io attempts.  That would be a 
>crude way to let applications know something strange has happened.
>
>Is anyone else tinkering with this problem?
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060609/911ed787/attachment-0015.html

From Ugo.Landini at Sun.COM  Fri Jun  2 14:23:47 2006
From: Ugo.Landini at Sun.COM (Ugo Landini)
Date: Fri, 02 Jun 2006 22:23:47 +0200
Subject: [Rxtx] OSX 10.4.7 and usb
Message-ID: <44809E53.2070905@sun.com>

Hi, I have installed the library and the native libraries on OSX 10.4.7. 
Then I have run this simple code:

...
while (portList.hasMoreElements()) {
             portId = (CommPortIdentifier) portList.nextElement();
             System.out.println("-> " + portId.getName() + " Port Type:" 
+ portId.getPortType());
...

and the output is:

Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7

Ports found:
-> /dev/tty.Bluetooth-PDA-Sync Port Type:1
-> /dev/cu.Bluetooth-PDA-Sync Port Type:1
-> /dev/tty.Bluetooth-Modem Port Type:1
-> /dev/cu.Bluetooth-Modem Port Type:1

I can't see any USB ports... with javax.comm on linux I could see the 
/dev/ttyUSB stuff, but that's not the case with OSX. Any idea?

tia

uL


From tod at todbot.com  Sun Jun 11 12:04:37 2006
From: tod at todbot.com (Tod E. Kurt)
Date: Sun, 11 Jun 2006 11:04:37 -0700
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <44809E53.2070905@sun.com>
References: <44809E53.2070905@sun.com>
Message-ID: <E2EB14A1-20A7-4611-8F1A-E3D2ABE41F48@todbot.com>

A dumb question, but: do you have the USB serial adapters plugged  
in?  They only show up in /dev when plugged in.  Also, you can verify  
they exist independent of RXTX by doing something like "ls -l /dev/ 
cu.*".

On Jun 2, 2006, at 1:23 PM, Ugo Landini wrote:

> Hi, I have installed the library and the native libraries on OSX  
> 10.4.7.
> Then I have run this simple code:
>
> ...
> while (portList.hasMoreElements()) {
>              portId = (CommPortIdentifier) portList.nextElement();
>              System.out.println("-> " + portId.getName() + " Port  
> Type:"
> + portId.getPortType());
> ...
>
> and the output is:
>
> Experimental:  JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
>
> Ports found:
> -> /dev/tty.Bluetooth-PDA-Sync Port Type:1
> -> /dev/cu.Bluetooth-PDA-Sync Port Type:1
> -> /dev/tty.Bluetooth-Modem Port Type:1
> -> /dev/cu.Bluetooth-Modem Port Type:1
>
> I can't see any USB ports... with javax.comm on linux I could see the
> /dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>
> tia
>
> uL
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>



From lyon at docjava.com  Sun Jun 11 12:14:50 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Sun, 11 Jun 2006 14:14:50 -0400
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <44809E53.2070905@sun.com>
References: <44809E53.2070905@sun.com>
Message-ID: <p06020444c0b20de7d248@[192.168.1.152]>

>Hi Ugo,

Do you have any USB serial ports (like the keyspan 19-HS) plugged
into the mac?
Thanks!
  - DL


>Hi, I have installed the library and the native libraries on OSX 10.4.7.
>Then I have run this simple code:
>
>...
>while (portList.hasMoreElements()) {
>              portId = (CommPortIdentifier) portList.nextElement();
>              System.out.println("-> " + portId.getName() + " Port Type:"
>+ portId.getPortType());
>...
>
>and the output is:
>
>Experimental:  JNI_OnLoad called.
>Stable Library
>=========================================
>Native lib Version = RXTX-2.1-7
>Java lib Version   = RXTX-2.1-7
>
>Ports found:
>-> /dev/tty.Bluetooth-PDA-Sync Port Type:1
>-> /dev/cu.Bluetooth-PDA-Sync Port Type:1
>-> /dev/tty.Bluetooth-Modem Port Type:1
>-> /dev/cu.Bluetooth-Modem Port Type:1
>
>I can't see any USB ports... with javax.comm on linux I could see the
>/dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>
>tia
>
>uL
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx



From dmarkman at mac.com  Sun Jun 11 14:30:27 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Sun, 11 Jun 2006 16:30:27 -0400
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <p06020444c0b20de7d248@[192.168.1.152]>
References: <44809E53.2070905@sun.com> <p06020444c0b20de7d248@[192.168.1.152]>
Message-ID: <B9C1606B-4339-4564-A175-FE83DFFA7D76@mac.com>

afaik
10.4.7 wasn't released yet
it will soon, no doubts


On Jun 11, 2006, at 2:14 PM, Dr. Douglas Lyon wrote:

>> Hi Ugo,
>
> Do you have any USB serial ports (like the keyspan 19-HS) plugged
> into the mac?
> Thanks!
>   - DL
>
>
>> Hi, I have installed the library and the native libraries on OSX  
>> 10.4.7.
>> Then I have run this simple code:
>>
>> ...
>> while (portList.hasMoreElements()) {
>>              portId = (CommPortIdentifier) portList.nextElement();
>>              System.out.println("-> " + portId.getName() + " Port  
>> Type:"
>> + portId.getPortType());
>> ...
>>
>> and the output is:
>>
>> Experimental:  JNI_OnLoad called.
>> Stable Library
>> =========================================
>> Native lib Version = RXTX-2.1-7
>> Java lib Version   = RXTX-2.1-7
>>
>> Ports found:
>> -> /dev/tty.Bluetooth-PDA-Sync Port Type:1
>> -> /dev/cu.Bluetooth-PDA-Sync Port Type:1
>> -> /dev/tty.Bluetooth-Modem Port Type:1
>> -> /dev/cu.Bluetooth-Modem Port Type:1
>>
>> I can't see any USB ports... with javax.comm on linux I could see the
>> /dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>>
>> tia
>>
>> uL
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman



From tjarvi at qbang.org  Sun Jun 11 18:52:59 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 11 Jun 2006 18:52:59 -0600 (MDT)
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <4489C786.9050504@dupreeinc.com>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
	<4489C786.9050504@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606111845430.7274@www>

On Fri, 9 Jun 2006, Doug Thistlethwaite wrote:

>
> Ideally, it would be nice if it would throw an exception and terminate the 
> loop.  I am still trying to figure out how to detect the condition and 
> recover form it in some form...  I am getting the "No error in readByte" 
> exception in my serialEvent() method after an input stream read.  It appears 
> to me that the only graceful recovery is to close the port and then reopen it 
> when it becomes available.  I can pass the event up to the update method in 
> my main frame, but I still can't close the port from within that thread.  Any 
> suggestions on how to pass this event to a location where the port can be 
> safely closed?
>

I've gone through and cleaned up the termios.c layer.  I need to get to a 
windows machine with a USB dongle and see where the ioctl() is being 
called.  Probably the eventLoop.  But all of the ioctls should probably 
result in an IOException during this condition.

I'll probably finish this up Monday night when I can borrow a USB 
dongle.

There is no point in putting the code into CVS yet.  If you are tinkering 
I can mail the patch.  I think we will want to make a couple fixes in 
SerialImp.c to handle errors before it's ready.

--
Trent Jarvi
tjarvi at qbang.org



From bob_tai2001 at yahoo.com  Mon Jun 12 09:42:14 2006
From: bob_tai2001 at yahoo.com (Bob Tai)
Date: Mon, 12 Jun 2006 08:42:14 -0700 (PDT)
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to RXTX
	again
Message-ID: <20060612154214.58219.qmail@web32804.mail.mud.yahoo.com>


thank you Paul, Joachim, Trent and everyone try to
workout the java comm and Rxtx situation.  At least
now I have something that is solid enough to make my
decision.  

thank you,
     Bob

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From Ralph.Buchfelder at gmx.net  Mon Jun 12 15:30:20 2006
From: Ralph.Buchfelder at gmx.net (Ralph Buchfelder)
Date: Mon, 12 Jun 2006 23:30:20 +0200
Subject: [Rxtx] rxtx binaries or porting to XSCALE Windows Mobile 2003 / 2005
Message-ID: <448DDCEC.7090506@gmx.net>

dear group,

i have been carefully reading your homepage, wiki and archives
but there seems to be no detailled information on porting to Windows 
Mobile/CE.

as far as i understood from the 'porting' section you can do porting to 
winCE. but how? do i only need to obtain the sourcecode (which one?) and 
compile this in Microsoft eMbedded Visual C++ for ARM/Xscale?
Any other ways?


unfortunately i must admit that i do have little linux skills but i have 
made my way through gcc and makefiles. right now i need to implement com 
  communication in a J2ME application and found your website as >the< 
solution.

best regards
Ralph Buchfelder

University of Regensburg
Department of Geography

PS: i dont care about Javacomm compliancy (ie. 2.0 or 2.1) - i just need 
a working serial port API in IBM J9 VM.


From paul.klissner at sun.com  Wed Jun 14 18:12:58 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Wed, 14 Jun 2006 17:12:58 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
Message-ID: <4490A60A.9090305@sun.com>

Hello RxTx community,

I finally think I have a compromise in place that will stand in the gap.

If you go to http://www.sun.com and search for javax.comm, you'll
get taken to a download page, where now users can get a copy of the
comm.jar file out of 2.0.3, along with just a license and a README.

I trust this will suffice until such time as RxTx decided to implement
their own java classes or we can get a JSR going to mitigate some
of the problems (the readme in the comm.jar 2.0.3 zip file
contains my thoughts on that).

Thanks,
Paul



From tjarvi at qbang.org  Wed Jun 14 21:15:35 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 14 Jun 2006 21:15:35 -0600 (MDT)
Subject: [Rxtx] rxtx-2.0-7 (final) src is in CVS
Message-ID: <Pine.LNX.4.61.0606142100500.2742@www>


I wasn't expecting to be working on rxtx 2.0 tonight :)

Thanks go out to Paul Klissner for his work in making the coming release 
of rxtx-2.0-7 possible for users that require package javax.comm on many 
platforms.

Most people know that rxtx 2.0 is for use with Sun's CommAPI 2.0 for 
Solaris or the Generic CommAPI 2.0-3 available for download at Sun.  If 
you need javax.comm packages on many platforms, you are probably 
interested.  If you use rxtx 2.1 in package gnu.io, then you are not going 
to care much.

I've tried to update the rxtx 2.0 src directory in preparation for 
rxtx-2.0-7 (final).  Linux should compile.  Windows will compile if you 
generate your own .def files (I'll generate these tomorrow).  If you have 
some time to do basic testing of the source, I'd appreciate it.  The 
source should be good but you may find classes not found.  This source is 
a backport from rxtx 2.1.

I wanted to get things started so anyone interested on Mac OS X could get 
a head start.

All of this is in CVS.  http://www.rxtx.org/cvs.html

I suspect we will have binaries for testing in a couple days if you are 
unable to compile.   Consider this a smoke test.

--
Trent Jarvi
tjarvi at qbang.org


From legolas.w at gmail.com  Wed Jun 14 22:04:28 2006
From: legolas.w at gmail.com (Legolas Woodland)
Date: Wed, 14 Jun 2006 21:04:28 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <4490A60A.9090305@sun.com>
References: <4490A60A.9090305@sun.com>
Message-ID: <87ee9b170606142104p745fcef0vea622fbc8f528bfc@mail.gmail.com>

is there anything new in this version of javax.comm ?
thanks


On 6/14/06, Paul Klissner <paul.klissner at sun.com> wrote:
>
> Hello RxTx community,
>
> I finally think I have a compromise in place that will stand in the gap.
>
> If you go to http://www.sun.com and search for javax.comm, you'll
> get taken to a download page, where now users can get a copy of the
> comm.jar file out of 2.0.3, along with just a license and a README.
>
> I trust this will suffice until such time as RxTx decided to implement
> their own java classes or we can get a JSR going to mitigate some
> of the problems (the readme in the comm.jar 2.0.3 zip file
> contains my thoughts on that).
>
> Thanks,
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060614/5ff4dfbc/attachment-0015.html

From joachim at buechse.de  Thu Jun 15 07:22:48 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 15 Jun 2006 15:22:48 +0200
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
Message-ID: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>

Good day!

Some of my users report problems using RXTX 2.1.7 on Windows98 to  
communicate with an FTDI FT245BM chip (using their latest VCP  
driver). Either no ports are being shown (ie returned form  
CommPortIdentifier.getPortIdentifiers()) or the transfers fail.

Did anyone run into similar Problems with Win98??

Best regards,
Joachim



From ajmas at sympatico.ca  Thu Jun 15 08:12:28 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Thu, 15 Jun 2006 10:12:28 -0400
Subject: [Rxtx] API change question
Message-ID: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

How closely do you follow the Java Communication API spec? The reason I ask is because I would be interested in augmenting the CommPortIdentifier class to include a getDisplayName() method. By default it would return the same value as getName(), but would provide the possibility of displaying a 'user friendly' name, for platforms where the display name is not the same as the device name. An example of this is on MacOS X, where currently the names seem to be of the form /dev/cu.* and /dev/tty.*, yet what the expects to see is simply the part after the full-stop. Although I could move this logic into the Java code, it would be nice to see it transparent to the Java code.

Andre




From ajmas at sympatico.ca  Thu Jun 15 08:16:22 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Thu, 15 Jun 2006 10:16:22 -0400
Subject: [Rxtx] Package to use
Message-ID: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

While the Java API spec refers to javax.comm, I see that only gnu.io is provide by the rxtx project. Should our projects refer to the gnu.io package or the javax.comm API?

Andre



From joachim at buechse.de  Thu Jun 15 08:45:05 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 15 Jun 2006 16:45:05 +0200
Subject: [Rxtx] API change question
In-Reply-To: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>

Hello Andre,

the /dev/cu and /dev/tty have different semantics on OS X. It is much  
more than a simply naming issue to unify them, see my recent mail to  
the list...

Best regards,
Joachim


On 15.06.2006, at 16:12, Andre-John Mas wrote:

> Hi,
>
> How closely do you follow the Java Communication API spec? The  
> reason I ask is because I would be interested in augmenting the  
> CommPortIdentifier class to include a getDisplayName() method. By  
> default it would return the same value as getName(), but would  
> provide the possibility of displaying a 'user friendly' name, for  
> platforms where the display name is not the same as the device  
> name. An example of this is on MacOS X, where currently the names  
> seem to be of the form /dev/cu.* and /dev/tty.*, yet what the  
> expects to see is simply the part after the full-stop. Although I  
> could move this logic into the Java code, it would be nice to see  
> it transparent to the Java code.
>
> Andre
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From lyon at docjava.com  Thu Jun 15 10:16:29 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Thu, 15 Jun 2006 12:16:29 -0400
Subject: [Rxtx] cu.modem != /dev/ttya on mac.
In-Reply-To: <763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
	<763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>
Message-ID: <p0602046cc0b7378a95b0@[192.168.1.152]>

>Hi All,

I think that Joachim is correct. For the longest time,
I have been trying to figure out how to direct dial using
the cu.modem on the mac under os x.

As a less-than-optimal approach to auto-dialing, I have used
a keyspan USB 19HS adapter, along with an external modem, to
obtain the dialing feature.

Ideally, it would be better to dial with the built-in modem...but that did not
always seem to work, for some reason. Have others had some experience with
using the built in modem for dialing on the mac?

Thanks!
  - Doug


>Hello Andre,
>
>the /dev/cu and /dev/tty have different semantics on OS X. It is much?
>more than a simply naming issue to unify them, see my recent mail to?
>the list...
>
>Best regards,
>Joachim
>



From doug at dupreeinc.com  Thu Jun 15 14:52:50 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 15 Jun 2006 13:52:50 -0700
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
In-Reply-To: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
References: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
Message-ID: <4491C8A2.8090108@dupreeinc.com>

Hi Joachim,

I have been doing a lot with the new FTDI driver with win XP and have 
not had that particular problem.  I did notice that the new driver 
(dated May19th, 2006) is only for XP, Server 2003, and 2000.  Are they 
trying to use the 2.00.00 drivers or the old 1.09.06 version.  I am 
using a FT232R based module, but it uses the same drivers and I assume 
it would have the same problems.  Let me know which driver they are 
using and I can load up a 98 system here and see if  I can duplicate the 
problem.

Doug

Joachim Buechse wrote:

>Good day!
>
>Some of my users report problems using RXTX 2.1.7 on Windows98 to  
>communicate with an FTDI FT245BM chip (using their latest VCP  
>driver). Either no ports are being shown (ie returned form  
>CommPortIdentifier.getPortIdentifiers()) or the transfers fail.
>
>Did anyone run into similar Problems with Win98??
>
>Best regards,
>Joachim
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From matthewhepp at yahoo.com  Thu Jun 15 17:34:47 2006
From: matthewhepp at yahoo.com (Matthew Hepp)
Date: Thu, 15 Jun 2006 16:34:47 -0700 (PDT)
Subject: [Rxtx] Wither the XCode project?
Message-ID: <20060615233447.48064.qmail@web50311.mail.yahoo.com>

Either I don't know how to properly use CVS (entirely possibl), or the XCode
project is not making through the update properly. Doing a "cvs update" against
2.1-7 creates an XCode folder in MACOSX_IDE, and therein a
LibSerialUniversal.xcodeproj, but trying to open it yields a "Unable to Open
Project - Project rxtx-devel/MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj
cannot be opened because it is missing its project.pbxproj file" error. Showing
package contents reveals just the cvs-related files. Perhaps this is why
previous xcode projects have been saved as an sit.hqx - to retain the resource
fork?

Can someone point me in the right direction?

Thanks,

Matt

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Thu Jun 15 19:53:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 19:53:06 -0600 (MDT)
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
In-Reply-To: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
References: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
Message-ID: <Pine.LNX.4.61.0606151944070.23137@www>

On Thu, 15 Jun 2006, Joachim Buechse wrote:

> Good day!
>
> Some of my users report problems using RXTX 2.1.7 on Windows98 to
> communicate with an FTDI FT245BM chip (using their latest VCP
> driver). Either no ports are being shown (ie returned form
> CommPortIdentifier.getPortIdentifiers()) or the transfers fail.
>
> Did anyone run into similar Problems with Win98??
>

Hi Joachim

It has been a long time since I've tested win98.  I know rxtx-2.1-7pre16 
did get testing on win98 with ~jdk 1.3 though.  I wonder if jdks are still 
tested on that platform.

With win98 you usually have older boxes.  They can be short on CPU and 
memory.  Enumeration should work but I could picture runtime performance 
issues on win98.

The enumeration problems could result from other copies of your 
application if various states of decay still holding onto the port.  When 
things go wrong, people also like to open other terminal software to see 
whats going on which can interfere.  You can't open a windows port with 
two apps.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Thu Jun 15 20:08:53 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 20:08:53 -0600 (MDT)
Subject: [Rxtx] API change question
In-Reply-To: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606151954270.23137@www>

On Thu, 15 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> How closely do you follow the Java Communication API spec?

I can explain how this worked in the past.  How we do it in the future is 
open for discussion.

In the past we have tried to follow it as close as possible in gnu.io 
(rxtx 2.1).  We have added extensions but try to discourage their use. 
The extensions are clearly marked as such in the source code and javadocs.

rxtx 2.0 was intended to be a strict implementation of part of the spec. 
We let Sun's interfaces decide what methods can be called. There are 
differences not covered by the spec such as default values.  Thats not 
intentional but rather hard to avoid.

--
Trent Jarvi
tjarvi at qbang.org





From tjarvi at qbang.org  Thu Jun 15 21:09:11 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 21:09:11 -0600 (MDT)
Subject: [Rxtx] Package to use
In-Reply-To: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606152026120.23137@www>

On Thu, 15 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> While the Java API spec refers to javax.comm, I see that only gnu.io is 
> provide by the rxtx project. Should our projects refer to the gnu.io 
> package or the javax.comm API?
>

Hi Andre

Lets see if I can give a fair and balanced answer to that.

If you are starting a new project and want to use RXTX, I would recommend 
using gnu.io.  The community support for gnu.io will not be going away 
anytime soon.  You can switch between gnu.io (2.1) and javax.comm (2.0) 
fairly easily.  They are not intended to be incompatible.  You just change 
package names and libs.

You can also consider the combination of rxtx 2.0 with Sun's commapi 
2.0-3.  This is considered a stop-gap measure by Sun for previous users of 
that combination.  Together rxtx 2.0 and Sun CommAPI 2.0 work in namespace 
javax.comm for programmers.

Finally, you can opt to just use Sun's oferrings in CommAPI 3.0 without 
rxtx.  That would be in namespace javax.comm also.  CommAPI 3.0 may be 
of more interest to you if you are looking at POS with Sun computers. 
Rxtx does not currently support the changes in CommAPI 3.0 or have firm 
plans to do so.  That does not mean we wouldn't implement them.  It just 
means nobody has contributed code yet.

You can't combine rxtx with CommAPI 3.0 for technical reasons that wont 
likely be fixed soon.

It's up to you as far as what you use.  We like to provide the freedom so 
you can choose.  Realistically, we will be supporting gnu.io mainly 
because we have some control over that name space and can support it.

Things may happen in the future that enable rxtx to provide more support 
in the javax namespace but that has not happened yet.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun 16 00:33:06 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 08:33:06 +0200
Subject: [Rxtx] Wither the XCode project?
In-Reply-To: <20060615233447.48064.qmail@web50311.mail.yahoo.com>
References: <20060615233447.48064.qmail@web50311.mail.yahoo.com>
Message-ID: <D30D660F-A49B-464E-AE4C-6B4563893682@buechse.de>

Hello Matthew,

could you please send me the contents of your

   rxtx-devel/CVS
   rxtx-devel/MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj/CVS

directories as a zip to my personal email address. This should  
indicate why the file is not checked out. I can see that it exists on  
the correct branch in the repository, so something must have gone  
wrong during the "cvs update"...

Best regards,
Joachim

On 16.06.2006, at 01:34, Matthew Hepp wrote:

> Either I don't know how to properly use CVS (entirely possibl), or  
> the XCode
> project is not making through the update properly. Doing a "cvs  
> update" against
> 2.1-7 creates an XCode folder in MACOSX_IDE, and therein a
> LibSerialUniversal.xcodeproj, but trying to open it yields a  
> "Unable to Open
> Project - Project rxtx-devel/MACOSX_IDE/XCode/ 
> LibSerialUniversal.xcodeproj
> cannot be opened because it is missing its project.pbxproj file"  
> error. Showing
> package contents reveals just the cvs-related files. Perhaps this  
> is why
> previous xcode projects have been saved as an sit.hqx - to retain  
> the resource
> fork?
>
> Can someone point me in the right direction?



From joachim at buechse.de  Fri Jun 16 10:41:20 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 18:41:20 +0200
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <p06230903c0b88613dca6@[10.0.1.7]>
References: <p06230903c0b88613dca6@[10.0.1.7]>
Message-ID: <03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>

Hello Bob,

until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was  
behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if  
Trent has migrated all recent changes from 2.1 to 2.0.

I have added the XCode project and updated documentation only to the  
gnu.io branch. Once the 2.0 implementation is up to date I will copy  
over the documentation/build files make them work.

Best regards,
Joachim

On 16.06.2006, at 18:07, Bob Jacobsen wrote:

> I'm one of the developers for the JMRI project, which provides  
> model railroad software in Java.  We've been using RXTX to provide  
> serial port access on MacOS X and Linux; we use the old javax.comm  
> 2.0 on Windows, OS/2 and Solaris.  Because of that, we need to stay  
> with RXTX 2.0, not 2.1
>
> We've been using the 2.0-pre17 installer for a long time, but it's  
> not compatible with Intel macs.
>
> Can you point me to where I can find the right files for RXTX 2.0  
> to package with the program?
>
> The current situation is confusing to me.  I've been pointed to  
> recent 2.1 versions (but we need the javax.comm names), to an even  
> older installer, etc.  I've been reading that some versions require  
> an installer, and others don't, but I haven't been able to figure  
> out which (if any) of those are where in CVS.
>
> I'd really appreciate a clear statement of what files to use and  
> what to do with them that I can pass on to our users.
>
> I'm more than happy to put files in the local classpath, have users  
> run an installer, or anything else.  Whatever is easiest for you.
>
> Thanks!  I really appreciate all that you do to keep RXTX working.
>
> Bob
> -- 
> Bob Jacobsen +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG



From joachim at buechse.de  Fri Jun 16 09:59:28 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 17:59:28 +0200
Subject: [Rxtx] Wither the XCode project?
In-Reply-To: <20060616150240.49464.qmail@web50309.mail.yahoo.com>
References: <20060616150240.49464.qmail@web50309.mail.yahoo.com>
Message-ID: <D9935E05-2B83-488D-86DD-42599E229052@buechse.de>

Hello Matthew,

you have checked out the trunk (which is the 2.0.7 javax.comm.xxx  
release). For rxtx-2.1.7 (gnu.io.xxx release) you need to check out  
the branch

      commapi-0-0-1

The easiest way to do this is to download the rxtx src archive,  
unpack it and then do a cvs up inside the decompressed tree.  
Optionally you could do a

      cvs co -r commapi-0-0-1

but this will take much longer!

Best regards,
Joachim

When you do a cvs status it will show the sticky tag.

41:~/jdevelop/rxtx-2.1-7r2 joachim$ cvs status README.OSX
===================================================================
File: README.OSX        Status: Up-to-date

    Working revision:    1.1.2.1
    Repository revision: 1.1.2.1 /usr/local/cvsroot/rxtx-devel/Attic/ 
README.OSX,v
    Sticky Tag:          commapi-0-0-1 (branch: 1.1.2)
    Sticky Date:         (none)
    Sticky Options:      (none)




On 16.06.2006, at 17:02, Matthew Hepp wrote:

> %cvs status README.MACOSX
> ===================================================================
> File: README.MACOSX     Status: Up-to-date
>
>    Working revision:    1.1
>    Repository revision: 1.1     /usr/local/cvsroot/rxtx-devel/ 
> README.MACOSX,v
>    Sticky Tag:          (none)
>    Sticky Date:         (none)
>    Sticky Options:      (none)



From tjarvi at qbang.org  Fri Jun 16 16:31:18 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Fri, 16 Jun 2006 16:31:18 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
Message-ID: <Pine.LNX.4.61.0606161630030.14139@www>

On Fri, 16 Jun 2006, Joachim Buechse wrote:

> Hello Bob,
>
> until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was
> behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if
> Trent has migrated all recent changes from 2.1 to 2.0.
>

The src/ directory and configure.in/configure files should be fine.  I 
have not touched the Mac OS X directories.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sat Jun 17 02:39:55 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sat, 17 Jun 2006 10:39:55 +0200
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <Pine.LNX.4.61.0606161630030.14139@www>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
Message-ID: <350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>

Hello Trent,

apparently the IOEXCL changes have not made it into 2.0. I will add  
them to achieve a minimal diff between 2.0 and 2.1.

One other thing that bugs me for a while...

Shouldn't we replace "if !defined(TIOCSERGETLSR) && !defined(WIN32)"  
by a definition of its own "if defined(DRAINTHREAD)"? I think this  
would make the code clearer for people starting to read it.

Regards,
Joachim


On 17.06.2006, at 00:31, Trent Jarvi wrote:

> On Fri, 16 Jun 2006, Joachim Buechse wrote:
>
>> Hello Bob,
>>
>> until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was
>> behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if
>> Trent has migrated all recent changes from 2.1 to 2.0.
>>
>
> The src/ directory and configure.in/configure files should be fine.  I
> have not touched the Mac OS X directories.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From tropicsu at hotmail.com  Sat Jun 17 09:32:48 2006
From: tropicsu at hotmail.com (Yoke K)
Date: Sat, 17 Jun 2006 15:32:48 +0000
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
Message-ID: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>

Hi,

I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to work with 
MAC OS X.
I am using iTegno 3000 - USB GPRS Modem.

Files in /dev and a symbolic link as follows:

crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 -> tty.usbserial

In my SendMessage.java, I have this line:
CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");

Appreciate any help ?

- Jon


Errors as follows:

>>INFO: SMSLib API for Java / v1.2.2
>>INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>INFO: JRE Version: 1.5.0_06
>>INFO: JRE Impl Version: 1.5.0_06-64
>>INFO: O/S: Mac OS X / ppc / 10.4.6
>>INFO: Using Wavecom (Generic) AT handler.

SendMessage(): Send a message.
  Using SMSLib API for Java v1.2.2

Connecting ..... :
>>INFO: CSerialDriver(): Connecting...
Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
>>INFO: CSerialDriver(): Disconnecting...
gnu.io.NoSuchPortException
        at 
gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:218)
        at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
        at org.smslib.CService.connect(CService.java:197)
        at SendMessage.main(SendMessage.java:38)

_________________________________________________________________
Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/



From tjarvi at qbang.org  Sat Jun 17 10:12:30 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 10:12:30 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
	<350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
Message-ID: <Pine.LNX.4.61.0606171010060.14139@www>

On Sat, 17 Jun 2006, Joachim Buechse wrote:

> Hello Trent,
>
> apparently the IOEXCL changes have not made it into 2.0. I will add
> them to achieve a minimal diff between 2.0 and 2.1.
>

Hi Joachim

As I recall the IOEXCL change was after 2.1-7.  I was just syncing with 
2.1-7.  We can release 2.1-8 and 2.0-8 with the same changes.

> One other thing that bugs me for a while...
>
> Shouldn't we replace "if !defined(TIOCSERGETLSR) && !defined(WIN32)"
> by a definition of its own "if defined(DRAINTHREAD)"? I think this
> would make the code clearer for people starting to read it.
>


Sure.  We can do that for -8.  The TIOCSERGETLSR code should be a special 
case not the expected.  I think only Linux uses it.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Sat Jun 17 10:48:21 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 10:48:21 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <Pine.LNX.4.61.0606171010060.14139@www>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
	<350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
	<Pine.LNX.4.61.0606171010060.14139@www>
Message-ID: <Pine.LNX.4.61.0606171047310.14139@www>

On Sat, 17 Jun 2006, Trent Jarvi wrote:

> On Sat, 17 Jun 2006, Joachim Buechse wrote:
>
>> Hello Trent,
>>
>> apparently the IOEXCL changes have not made it into 2.0. I will add
>> them to achieve a minimal diff between 2.0 and 2.1.
>>
>
> Hi Joachim
>
> As I recall the IOEXCL change was after 2.1-7.  I was just syncing with
> 2.1-7.  We can release 2.1-8 and 2.0-8 with the same changes.
>

We could just move to 2.1-8 and 2.0-8.

--
Trent Jarvi
tjarvi at qbang.org


From brian.t.lamb at gmail.com  Tue Jun 13 13:54:13 2006
From: brian.t.lamb at gmail.com (Brian Lamb)
Date: Tue, 13 Jun 2006 15:54:13 -0400
Subject: [Rxtx] Windows XP Installation
Message-ID: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>

I've not installed Java packages on Windows before and am unsure how to
proceed. All the documentation I've seen provides detailed instructions on
how to install on Linux or Solaris. I was wondering how to install rxtx on
Windows XP.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060613/6f68cd5c/attachment-0015.html

From tjarvi at qbang.org  Sat Jun 17 13:57:03 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 13:57:03 -0600 (MDT)
Subject: [Rxtx] Windows XP Installation
In-Reply-To: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>
References: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0606171356120.14139@www>

On Tue, 13 Jun 2006, Brian Lamb wrote:

> I've not installed Java packages on Windows before and am unsure how to
> proceed. All the documentation I've seen provides detailed instructions on
> how to install on Linux or Solaris. I was wondering how to install rxtx on
> Windows XP.
>

Hi Brian

Which rxtx version are you trying to install?

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sun Jun 18 10:41:44 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sun, 18 Jun 2006 18:41:44 +0200
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
References: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
Message-ID: <8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>

Hello Jon,

 From OSX's standpoint a symbolic link is not a device (as far as I  
know). What stops you from using tty.usbserial? Did you try hard- 
linking?

Regards,
Joachim

On 17.06.2006, at 17:32, Yoke K wrote:
> Hi,
>
> I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to  
> work with
> MAC OS X.
> I am using iTegno 3000 - USB GPRS Modem.
>
> Files in /dev and a symbolic link as follows:
>
> crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
> crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
> lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->  
> tty.usbserial
>
> In my SendMessage.java, I have this line:
> CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
>
> Appreciate any help ?
>
> - Jon
>
>
> Errors as follows:
>
>>> INFO: SMSLib API for Java / v1.2.2
>>> INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>> INFO: JRE Version: 1.5.0_06
>>> INFO: JRE Impl Version: 1.5.0_06-64
>>> INFO: O/S: Mac OS X / ppc / 10.4.6
>>> INFO: Using Wavecom (Generic) AT handler.
>
> SendMessage(): Send a message.
>   Using SMSLib API for Java v1.2.2
>
> Connecting ..... :
>>> INFO: CSerialDriver(): Connecting...
> Experimental:  JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
>>> INFO: CSerialDriver(): Disconnecting...
> gnu.io.NoSuchPortException
>         at
> gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java: 
> 218)
>         at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
>         at org.smslib.CService.connect(CService.java:197)
>         at SendMessage.main(SendMessage.java:38)
>
> _________________________________________________________________
> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Sun Jun 18 10:56:55 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 12:56:55 -0400
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>
References: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
	<8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>
Message-ID: <7B6834E3-F41D-46B6-B979-55466BC73859@sympatico.ca>

Have you been able to get any other software to talk with your
modem? What port is it using? Have tried using the cu.usbserial
instead?

Andre

On 18-Jun-06, at 12:41 , Joachim Buechse wrote:

> Hello Jon,
>
>  From OSX's standpoint a symbolic link is not a device (as far as I
> know). What stops you from using tty.usbserial? Did you try hard-
> linking?
>
> Regards,
> Joachim
>
> On 17.06.2006, at 17:32, Yoke K wrote:
>> Hi,
>>
>> I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to
>> work with
>> MAC OS X.
>> I am using iTegno 3000 - USB GPRS Modem.
>>
>> Files in /dev and a symbolic link as follows:
>>
>> crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
>> crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
>> lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->
>> tty.usbserial
>>
>> In my SendMessage.java, I have this line:
>> CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
>>
>> Appreciate any help ?
>>
>> - Jon
>>
>>
>> Errors as follows:
>>
>>>> INFO: SMSLib API for Java / v1.2.2
>>>> INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>>> INFO: JRE Version: 1.5.0_06
>>>> INFO: JRE Impl Version: 1.5.0_06-64
>>>> INFO: O/S: Mac OS X / ppc / 10.4.6
>>>> INFO: Using Wavecom (Generic) AT handler.
>>
>> SendMessage(): Send a message.
>>   Using SMSLib API for Java v1.2.2
>>
>> Connecting ..... :
>>>> INFO: CSerialDriver(): Connecting...
>> Experimental:  JNI_OnLoad called.
>> Stable Library
>> =========================================
>> Native lib Version = RXTX-2.1-7
>> Java lib Version   = RXTX-2.1-7
>>>> INFO: CSerialDriver(): Disconnecting...
>> gnu.io.NoSuchPortException
>>         at
>> gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:
>> 218)
>>         at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
>>         at org.smslib.CService.connect(CService.java:197)
>>         at SendMessage.main(SendMessage.java:38)
>>
>> _________________________________________________________________
>> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Sun Jun 18 17:33:08 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 19:33:08 -0400
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
Message-ID: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>

Hi,

I am have a program that I wrote in Java to communicate with a  
Bluetooth GPS device. I am
trying to get this working on my Mac, but I keep getting told that:

gnu.io.PortInUseException: Unknown Application

but

portIdentifier.isCurrentlyOwned()

returns false and when I do lsof on the device I am trying to connect  
to, I see no application
using it. As the same time if I go to the command line and use  
minicom I have no issues. The
exception happens with this call:

CommPort commPort = portIdentifier.open(null,0);

Any suggestions?

Andre


From ajmas at sympatico.ca  Sun Jun 18 17:45:11 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 19:45:11 -0400
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
Message-ID: <30245B30-682D-4EAE-8084-8227B719F10D@sympatico.ca>

BTW My code snippet is:

     private InputStream connectToSerial () throws IOException,  
Exception
     {
         InputStream in = null;

         Enumeration portEnum = CommPortIdentifier.getPortIdentifiers();
         while ( portEnum.hasMoreElements() )
         {
             CommPortIdentifier portIdentifier = (CommPortIdentifier)  
portEnum.nextElement();
             System.out.println(portIdentifier.getName() + " - " +  
portIdentifier.getPortType() );
         }

         CommPortIdentifier portIdentifier =  
CommPortIdentifier.getPortIdentifier("/dev/cu.BTGPS-SPPslave-1");
         System.out.println("current owner: " +  
portIdentifier.getCurrentOwner());
         if ( portIdentifier.isCurrentlyOwned() )
         {
             System.out.println("Error: Port is currently in use");
             return null;
         }
         else
         {
             CommPort commPort = portIdentifier.open(this.getClass 
().getName(),2000);

             if ( commPort instanceof SerialPort )
             {
                 SerialPort serialPort = (SerialPort) commPort;
                 serialPort.setSerialPortParams 
(4800,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE 
);
                 in = serialPort.getInputStream();

                 return in;
             }
             else
             {
                 System.out.println("Error: Only serial ports are  
handled.");
             }
         }


         return in;
     }


On 18-Jun-06, at 19:33 , Andr?-John Mas wrote:

> Hi,
>
> I am have a program that I wrote in Java to communicate with a
> Bluetooth GPS device. I am
> trying to get this working on my Mac, but I keep getting told that:
>
> gnu.io.PortInUseException: Unknown Application
>
> but
>
> portIdentifier.isCurrentlyOwned()
>
> returns false and when I do lsof on the device I am trying to connect
> to, I see no application
> using it. As the same time if I go to the command line and use
> minicom I have no issues. The
> exception happens with this call:
>
> CommPort commPort = portIdentifier.open(null,0);
>
> Any suggestions?
>
> Andre
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From joachim at buechse.de  Mon Jun 19 05:54:49 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 13:54:49 +0200
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de>

This is most likely due to a problem with lock files. If you have  
downloaded the binaries of 2.17 rxtx will try to create non-standard  
lock files on OSX. We have since changed the code to use OSX device  
locking - however the binaries have not been updated yet. The 2.18  
release fixing this issue is due shortly.

Regards,
Joachim

On 19.06.2006, at 01:33, Andr?-John Mas wrote:

> Hi,
>
> I am have a program that I wrote in Java to communicate with a
> Bluetooth GPS device. I am
> trying to get this working on my Mac, but I keep getting told that:
>
> gnu.io.PortInUseException: Unknown Application
>
> but
>
> portIdentifier.isCurrentlyOwned()
>
> returns false and when I do lsof on the device I am trying to connect
> to, I see no application
> using it. As the same time if I go to the command line and use
> minicom I have no issues. The
> exception happens with this call:
>
> CommPort commPort = portIdentifier.open(null,0);
>
> Any suggestions?
>
> Andre
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From joachim at buechse.de  Mon Jun 19 06:44:27 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 14:44:27 +0200
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <4490A60A.9090305@sun.com>
References: <4490A60A.9090305@sun.com>
Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>

Hello Paul,

I just downloaded the "generic" javax.comm version now available. A  
first check indicates, that it was compiled with a JDK 1.4 javac  
without setting the target classfile version. In other words in can  
not be loaded by 1.1-1.3 VMs (or PersonalJava).

Do you see any chance to provide a version compiled with classfile  
format 45.3 (ie JVM1.1).

---
52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose  
javax.comm.SerialPort | head -5
Compiled from "SerialPort.java"
public abstract class javax.comm.SerialPort extends javax.comm.CommPort
   SourceFile: "SerialPort.java"
   minor version: 0
   major version: 48
---

Best regards,
Joachim


On 15.06.2006, at 02:12, Paul Klissner wrote:

> Hello RxTx community,
>
> I finally think I have a compromise in place that will stand in the  
> gap.
>
> If you go to http://www.sun.com and search for javax.comm, you'll
> get taken to a download page, where now users can get a copy of the
> comm.jar file out of 2.0.3, along with just a license and a README.
>
> I trust this will suffice until such time as RxTx decided to implement
> their own java classes or we can get a JSR going to mitigate some
> of the problems (the readme in the comm.jar 2.0.3 zip file
> contains my thoughts on that).
>
> Thanks,
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Mon Jun 19 09:11:45 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Mon, 19 Jun 2006 11:11:45 -0400
Subject: [Rxtx] Examples added to Wiki
Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

I have added a couple of examples to the Wiki:

http://rxtx.qbang.org/wiki/index.php/Examples

If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :)

Andre



From paul.klissner at sun.com  Mon Jun 19 10:42:47 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Mon, 19 Jun 2006 09:42:47 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>
References: <4490A60A.9090305@sun.com>
	<03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>
Message-ID: <4496D407.1090609@sun.com>

Joachim Buechse wrote:
> Hello Paul,
> 
> I just downloaded the "generic" javax.comm version now available. A  
> first check indicates, that it was compiled with a JDK 1.4 javac  
> without setting the target classfile version. In other words in can  
> not be loaded by 1.1-1.3 VMs (or PersonalJava).
> 
> Do you see any chance to provide a version compiled with classfile  
> format 45.3 (ie JVM1.1).
> 
> ---
> 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose  
> javax.comm.SerialPort | head -5
> Compiled from "SerialPort.java"
> public abstract class javax.comm.SerialPort extends javax.comm.CommPort
>    SourceFile: "SerialPort.java"
>    minor version: 0
>    major version: 48
> ---

I cannot promise when I can do that. Since we thought we were done
with javax.comm, the build environment got moved around, and right
now it doesn't even compile in it's new home.  I tried and it was
not cooperative at all. I was never impressed with that workspace
(in fact far far from it, it is a mess, which is why I migrated 3.0
to ant and never looked back).  It will take some real determination
for me to rebuild it, and frankly, right now I'm swamped.  If I can
find a bit of time over the next few weeks to do it, and it isn't
too bad an ordeal, I will.

Posting that will give me an excuse to post javax.comm 3.0, Update 2 as
well, while I'm working with the people who put content up on our
download center.  The only reason for a new update to 3.0 is that
I've changed the distribution to provide ispt (Interactive Serial
Port Tool), such that it can be launched as soon as the zip file
is unpacked, via a provided script.  ISPT is a command line
interactive tool for  manipulating one or two serial port,
sending data, managing events, etc... I've found it to be so useful
for doing certain kinds of validation  that I assume others will
find it useful to.  ISPT is already in 3.0u1, but one has to set
up their own classpath and launch it and since few people ever read
the documentation most won't know about it.  I've added the ability
to set stop bits and parity since 3.0u1 too.  But I digress.

Paul


From joachim at buechse.de  Mon Jun 19 11:01:28 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 19:01:28 +0200
Subject: [Rxtx] load mechanism of 2.0x
Message-ID: <CFD1440C-21AA-4D3B-9EA6-270D0FF9D6FC@buechse.de>

Good day,

I am trying to figure out, how the 2.0x distribution interacts with  
Suns implementation of javax.comm.CommPortIdentifier.

1) Apparently one can put javax.comm.properties in {java.home}/lib
2) The javax.comm package also reacts to -Djavax.comm.properties="...."

Looking at the javap output it also seems like CommPortIdentifier  
tries to find it's jar file and load the properties from there??


What I'm really looking for is a solution that allows using  
javax.comm with RXTX without modifying the VM installation. So I  
would prefer not to use 1) but I can't figure out how to use 2).

Any hints are welcome,
Joachim



From bob_tai2001 at yahoo.com  Mon Jun 19 15:00:35 2006
From: bob_tai2001 at yahoo.com (Bob Tai)
Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT)
Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place
	to start?
Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>

Hi, 

I got  rxtx Windows 2000 installed.  I did not use the
"best" way ... I just follow the insturuction and dump
the necessary files into the jre... I know it's "best"
idea, I got lazy didn't want to change my setting to
my Eclipse and classpath.

I was able to modify SimpleWrite.java to print on my
AddMaster serial printer.  I think I am ready to code!
But I need to make sure I can handle exceptions and so
on.  I notice the \samples\NullDriver\  has two files
seems to have some of the require method done, should
I start coding from those file?  I like the idea it
has the "time out" and basic exceptions done.   I am
slowly digging into the samples, but if you think any
of the code from Sun is good to checkout please let me
know.

btw, http://rxtx.qbang.org/wiki/index.php/Examples/
was very helpful, wish there are more examples.

thank you,

    Bob


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Mon Jun 19 15:55:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT)
Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good
 place to start?
In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>
References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606191542260.14139@www>

> I am
> slowly digging into the samples, but if you think any
> of the code from Sun is good to checkout please let me
> know.
>

I think NullDriver.java was an example stub driver for implementing 
something like rxtx.  It has been a while.  Unless they have been updated, 
you will find the examples are very dated.  You can look at how they use 
the port but avoid the GUI and hard coded variables (number of ports for 
instance).

There was no Swing and nobody knew what requirements today's compilers 
would make on code.  The examples worked fine with jdk 1.1 but times have 
changed.

--
Trent Jarvi
tjarvi at qbang.org


From tropicsu at hotmail.com  Mon Jun 19 19:49:08 2006
From: tropicsu at hotmail.com (Yoke K)
Date: Tue, 20 Jun 2006 01:49:08 +0000
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
Message-ID: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>

An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/fa588f00/attachment-0006.html

From ajmas at sympatico.ca  Mon Jun 19 21:14:37 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Mon, 19 Jun 2006 23:14:37 -0400
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>
References: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>
Message-ID: <CA22AB2A-5712-458B-9984-68477C6042AF@sympatico.ca>

Regarding the PortInUseException, I had a similar issue and got
this response from the mailing list:

   http://mailman.qbang.org/pipermail/rxtx/Week-of- 
Mon-20060619/062838.html

Andre
On 19-Jun-06, at 21:49 , Yoke K wrote:

> Hi Andre, Joachim
>
> I have tried using /dev/tty.usbserial and also /dev/cu.usbserial  
> and it also reported error as  "gnu.io.PortInUseException".
>
> The iTegno modem works in windows environment. As I moving around  
> using my ibook and I need to get it work on MAC OS as well.
>
> >> INFO: SMSLib API for Java / v1.2.2
> >> INFO: Using port: /dev/tty.usbserial @ 115200 baud.
> >> INFO: JRE Version: 1.5.0_06
> >> INFO: JRE Impl Version: 1.5.0_06-64
> >> INFO: O/S: Mac OS X / ppc / 10.4.6
> >> INFO: Using Wavecom (Generic) AT handler.
>
> SendMessage(): Send a message.
> Using SMSLib API for Java v1.2.2
>
> Connecting ..... :
> >> INFO: CSerialDriver(): Connecting...
> Experimental: JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version = RXTX-2.1-7
> >> INFO: CSerialDriver(): Disconnecting...
> gnu.io.PortInUseException: Unknown Application
> at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354)
> at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1)
> at org.smslib.CService.connect(CService.java:197)
> at SendMessage.main(SendMessage.java:38)
>
> Thanks.
>
> - Jon
>
>
>
>
> ====================
>
> Hello Jon,
>
> From OSX's standpoint a symbolic link is not a device (as far as I
> know). What stops you from using tty.usbserial? Did you try hard-
> linking?
>
> Regards,
> Joachim
>
>
>
> From:  "Yoke K" <tropicsu at hotmail.com>
> To:  rxtx at qbang.org
> Subject:  RXTX-2.1-7 / MAC OS X / NoSuchPortException
> Date:  Sat, 17 Jun 2006 15:32:48 +0000
> >Hi,
> >
> >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to
> >work with MAC OS X.
> >I am using iTegno 3000 - USB GPRS Modem.
> >
> >Files in /dev and a symbolic link as follows:
> >
> >crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
> >crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
> >lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->
> >tty.usbserial
> >
> >In my SendMessage.java, I have this line:
> >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
> >
> >Appreciate any help ?
> >
> >- Jon
> >
> >
> >Errors as follows:
> >
> >>>INFO: SMSLib API for Java / v1.2.2
> >>>INFO: Using port: /dev/ttyS1 @ 56000 baud.
> >>>INFO: JRE Version: 1.5.0_06
> >>>INFO: JRE Impl Version: 1.5.0_06-64
> >>>INFO: O/S: Mac OS X / ppc / 10.4.6
> >>>INFO: Using Wavecom (Generic) AT handler.
> >
> >SendMessage(): Send a message.
> >  Using SMSLib API for Java v1.2.2
> >
> >Connecting ..... :
> >>>INFO: CSerialDriver(): Connecting...
> >Experimental:  JNI_OnLoad called.
> >Stable Library
> >=========================================
> >Native lib Version = RXTX-2.1-7
> >Java lib Version   = RXTX-2.1-7
> >>>INFO: CSerialDriver(): Disconnecting...
> >gnu.io.NoSuchPortException
> >        at
> >gnu.io.CommPortIdentifier.getPortIdentifier 
> (CommPortIdentifier.java:218)
> >        at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
> >        at org.smslib.CService.connect(CService.java:197)
> >        at SendMessage.main(SendMessage.java:38)
> >
> >_________________________________________________________________
> >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
> >
>
> Find love online with MSN Personals
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Tue Jun 20 02:35:24 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 10:35:24 +0200
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>

Hello everybody,

I have been fighting a bit with the javax.comm version of RXTX the  
last days. I am working on the README .OSX now and try to figure out  
which should be the "suggested" installation.

The facts:
------

- the "generic" comm.jar version of javax.comm which has been made re- 
available tries to load com.sun.comm.SolarisDriver
- this classname can be overridden ONLY by putting a file  
javax.comm.properties in {java.home}/lib
- if it is not overridden and SolarisDriver.class is not found  
CommPortIdentifier will be disfunctional (in particual it is not  
possible to add CommPort's via CommPortIdentifier.add).
- the license distributed with comm.jar does not allow the  
modification/addition of classes in javax.comm (however no mention of  
com.sun...)


What really bothers me is to suggest putting this config file in the  
"global" vm installation. This is particularly ugly on the Mac as  
there are several VM installations and the file may be forgotten.  
Additionally it may create versioning problems. I prefer an  
installation where all files are local to the application (even  
comm.jar).

In my opinion the ideal situation would be:
------

1) The author of a program compiles against javax.comm.
2a) For platforms supported by Sun the user is free to use the 3.0  
comm.jar download from Sun
2b) For platforms not supported by Sun the user adds RXTXComm.jar to  
the classpath of the application (and librxtxSerial.jnilib to the  
application directory). Also he will need the 2.0.3 generic comm.jar  
from Sun.
3) Nobody messes with the global VM installation.

Of course 2a) and 2b) could be handled by the author of the program  
via an appropriate installer. The author could also decide to always  
use RXTX and include the generic javax.comm classes as well as the  
RXTX classes in his application jar. [If he further uses an explicit  
call to System.load() he may even include the jnilib(s) in the jar,  
extract it (based on the platform name) at runtime to a temp file and  
load it from there.]


Suggested solution:
------

We only need to put the following class in the classpath BEFORE Suns  
comm.jar

   package com.sun.comm;
   public class SolarisDriver extends gnu.io.RXTXCommDriver {
   }

This is not "the pure art" (TM). It depends on an implementation  
detail of the generic driver. However, so does the  
javax.comm.properties file - as we have seen when Sun released 3.0.  
It has the following advantages:

- The "generic" javax.comm implementation will happily load this  
class as its primary driver.
- No javax.comm.properties file is required.
- This does not violate the javax.comm license agreement as there is  
no mention of the "com.sun.comm" package in this license agreement at  
all.
- Authors packaging comm.jar with their application can strip out all  
com.sun.comm classes from comm.jar


Please comment!

Joachim



From joachim at buechse.de  Tue Jun 20 02:50:36 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 10:50:36 +0200
Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar
Message-ID: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>

There has been some discussions about the best way to install RXTX  
and where to place files.

I suggest that,

- we include the native libraries for the most common operating  
systems (in a special version of) RXTXcomm.jar
- we add loader code which tries to extract and load the platform  
specific binary at runtime
- on failure the current mechanism remains as a fallback

Wether the current mechanism should have priority (ie loadLibrary  
before load) remains to be discussed.


The advantages of this solution are
  - users of RXTX do not need to worry about java/platform specific  
file placement.
  - authors of applications may fully merge RXTX into their  
application jar (which provides a double-clickable application for  
Windows and OSX, Linux?).

Please comment,
Joachim

PS: Of course the suggested solution is already possible today,  
however relatively few programmers know how to correctly extract a  
binary resource file via the class loader and load it as a native  
library.


From tjarvi at qbang.org  Tue Jun 20 03:58:12 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT)
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
Message-ID: <Pine.LNX.4.61.0606200335190.14139@www>

> 2a) For platforms supported by Sun the user is free to use the 3.0
> comm.jar download from Sun
> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to
> the classpath of the application (and librxtxSerial.jnilib to the
> application directory). Also he will need the 2.0.3 generic comm.jar
> from Sun.

As there are no plans to support CommAPI 3.0 due to the limitations in its 
implementation mentioned before, I would not recommend projects use Sun's 
3.0 comm.jar.  They will lose the freedom to chose their low level 
implementation by being locked into vendor specific modifications.

Projects should chose between platform neutrality in CommAPI 2.0 and 
reduced platform neutrality in commapi 3.0.  Projects should also strongly 
consider the fact that the 2.0 comm.jar targets only a reduced number of 
JVMs.

Projects can go with rxtx 2.1 or other packages but should probably only 
consider using Sun CommAPI with rxtx if they did so in the past.  They 
should take steps to no longer depend upon this option being available.

> Suggested solution:
> ------
>
> We only need to put the following class in the classpath BEFORE Suns
> comm.jar
>
>   package com.sun.comm;
>   public class SolarisDriver extends gnu.io.RXTXCommDriver {
>   }
>
> This is not "the pure art" (TM). It depends on an implementation
> detail of the generic driver. However, so does the
> javax.comm.properties file - as we have seen when Sun released 3.0.
> It has the following advantages:
>
> - The "generic" javax.comm implementation will happily load this
> class as its primary driver.
> - No javax.comm.properties file is required.
> - This does not violate the javax.comm license agreement as there is
> no mention of the "com.sun.comm" package in this license agreement at
> all.
> - Authors packaging comm.jar with their application can strip out all
> com.sun.comm classes from comm.jar
>

I would not encourage people to place packages in the com.sun.comm 
namespace.  Authors using Sun's commapi 2.0 should just realize it is 
greatly limited in practical utility and consider moving to something that 
isn't being rescued from EOL.

The primary focus of this release is projects previously depending upon 
Sun CommAPI + RXTX.  There are no plans at this time to provide future 
support in this arrangement due to technical incompatabilities we have no 
control over in commapi 3.0 and limited utility of Sun's generic comm.jar 
in commapi 2.0 offered.  Projects should be aware of this so they can make 
appropriate plans.

--
Trent Jarvi
tjarvi at qbang.org


From paul.klissner at sun.com  Tue Jun 20 05:24:00 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Tue, 20 Jun 2006 04:24:00 -0700
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
In-Reply-To: <Pine.LNX.4.61.0606200335190.14139@www>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
	<Pine.LNX.4.61.0606200335190.14139@www>
Message-ID: <4497DAD0.10803@sun.com>

Trent Jarvi wrote:
>> 2a) For platforms supported by Sun the user is free to use the 3.0
>> comm.jar download from Sun
>> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to
>> the classpath of the application (and librxtxSerial.jnilib to the
>> application directory). Also he will need the 2.0.3 generic comm.jar
>> from Sun.
> 
> As there are no plans to support CommAPI 3.0 due to the limitations in its 
> implementation mentioned before, I would not recommend projects use Sun's 
> 3.0 comm.jar.  They will lose the freedom to chose their low level 
> implementation by being locked into vendor specific modifications.
> 
> Projects should chose between platform neutrality in CommAPI 2.0 and 
> reduced platform neutrality in commapi 3.0.  Projects should also strongly 
> consider the fact that the 2.0 comm.jar targets only a reduced number of 
> JVMs.

Well, that's a little ambiguous because the API is the same
either way.  We're talking about Sun's implementation vs.
other implementations.
> 
> Projects can go with rxtx 2.1 or other packages but should probably only 
> consider using Sun CommAPI with rxtx if they did so in the past.  They 
> should take steps to no longer depend upon this option being available.

3.0 is platform centric because there is a need to add some
platform awareness to Sun's implementation, and the choices
for how to do that are limited by the constraints of the API,
as mentioned in the javax.comm 2.0.3 comm.jar download's README.

I am really advocating getting a JSR open (http://www.jcp.org)
to push a new comm API that is more pluggable, platform neutral
and addresses some of the deficiencies of the current API. Then
we can achieve the optimal of platform neutrality while
simulataneously allowing the API to flexibly adapt to
heterogeneous environments.

This is not a question of attitude, this is an issue of resources,
time and commitment.  The current owners of javax.comm within
Sun would like nothing better than to see the ideal reached for
the API and a model that will extend well beyond the foreseeable
future and work for the industry overall.



> 
>> Suggested solution:
>> ------
>>
>> We only need to put the following class in the classpath BEFORE Suns
>> comm.jar
>>
>>   package com.sun.comm;
>>   public class SolarisDriver extends gnu.io.RXTXCommDriver {
>>   }
>>
>> This is not "the pure art" (TM). It depends on an implementation
>> detail of the generic driver. However, so does the
>> javax.comm.properties file - as we have seen when Sun released 3.0.
>> It has the following advantages:
>>
>> - The "generic" javax.comm implementation will happily load this
>> class as its primary driver.
>> - No javax.comm.properties file is required.
>> - This does not violate the javax.comm license agreement as there is
>> no mention of the "com.sun.comm" package in this license agreement at
>> all.
>> - Authors packaging comm.jar with their application can strip out all
>> com.sun.comm classes from comm.jar
>>
> 
> I would not encourage people to place packages in the com.sun.comm 
> namespace.  Authors using Sun's commapi 2.0 should just realize it is 
> greatly limited in practical utility and consider moving to something that 
> isn't being rescued from EOL.
> 
> The primary focus of this release is projects previously depending upon 
> Sun CommAPI + RXTX.  There are no plans at this time to provide future 
> support in this arrangement due to technical incompatabilities we have no 
> control over in commapi 3.0 and limited utility of Sun's generic comm.jar 
> in commapi 2.0 offered.  Projects should be aware of this so they can make 
> appropriate plans.

Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86,
or need the powerful portmapping features in javax.com 3.0, or would like to
acquire the Interactive Serial Port Test utility.

-Paul


From paul.klissner at sun.com  Tue Jun 20 05:33:44 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Tue, 20 Jun 2006 04:33:44 -0700
Subject: [Rxtx] Suggested installation RXTX 2.0x...
In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
Message-ID: <4497DD18.70207@sun.com>

Joachim Buechse wrote:
> Hello everybody,
> 
> I have been fighting a bit with the javax.comm version of RXTX the  
> last days. I am working on the README .OSX now and try to figure out  
> which should be the "suggested" installation.
> 
> The facts:
> ------
> 
> - the "generic" comm.jar version of javax.comm which has been made re- 
> available tries to load com.sun.comm.SolarisDriver
> - this classname can be overridden ONLY by putting a file  
> javax.comm.properties in {java.home}/lib
> - if it is not overridden and SolarisDriver.class is not found  
> CommPortIdentifier will be disfunctional (in particual it is not  
> possible to add CommPort's via CommPortIdentifier.add).
> - the license distributed with comm.jar does not allow the  
> modification/addition of classes in javax.comm (however no mention of  
> com.sun...)
> 
> 
> What really bothers me is to suggest putting this config file in the  
> "global" vm installation. This is particularly ugly on the Mac as  
> there are several VM installations and the file may be forgotten.  
> Additionally it may create versioning problems. I prefer an  
> installation where all files are local to the application (even  
> comm.jar).
> 
> In my opinion the ideal situation would be:
> ------
> 
> 1) The author of a program compiles against javax.comm.
> 2a) For platforms supported by Sun the user is free to use the 3.0  
> comm.jar download from Sun
> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to  
> the classpath of the application (and librxtxSerial.jnilib to the  
> application directory). Also he will need the 2.0.3 generic comm.jar  
> from Sun.
> 3) Nobody messes with the global VM installation.
> 
> Of course 2a) and 2b) could be handled by the author of the program  
> via an appropriate installer. The author could also decide to always  
> use RXTX and include the generic javax.comm classes as well as the  
> RXTX classes in his application jar. [If he further uses an explicit  
> call to System.load() he may even include the jnilib(s) in the jar,  
> extract it (based on the platform name) at runtime to a temp file and  
> load it from there.]
> 

This was how the Sun implementation originated (I did not write
that code).  I completely agree, and I fixed the whole conf file
locating mechanism in 3.0 to avoid the problems youmentioned.
However, I was unaware of how RxTx was using Sun's implementation,
so I didn't architect it in such a way as to avoid namespace pollution
in the native space in for the backend provider.  In retrospect,
I should have done that differently just as a design principle,
but at this point I don't have the spare cycles to get that all
re-factored.  Further, I'm loathe to do it, because the whole
thing will still be an under-the-hood hack due to the constraints
of the API itself.

Paul





From brian at mbari.org  Tue Jun 20 10:23:54 2006
From: brian at mbari.org (Brian Schlining)
Date: Tue, 20 Jun 2006 09:23:54 -0700
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>


Hi Joachim,

> There has been some discussions about the best way to install RXTX
> and where to place files.
>
> I suggest that,
>
> - we include the native libraries for the most common operating
> systems (in a special version of) RXTXcomm.jar
> - we add loader code which tries to extract and load the platform
> specific binary at runtime
> - on failure the current mechanism remains as a fallback

I like your suggestion. However, my understanding is that in general  
the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH  
(Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to  
be loaded by the JVM. The alternative is to point to your native lib  
directory using -Djava.library.path=/my/dir/with/native/libs when you  
launch the JVM. So, I'm very interested to know how you're planning  
to work around this.

> PS: Of course the suggested solution is already possible today,
> however relatively few programmers know how to correctly extract a
> binary resource file via the class loader and load it as a native
> library.

So how do you use it to dynamically load a native lib? I've read that  
you can't really modify the java.library.path after the JVM has been  
launched. (http://forum.java.sun.com/thread.jspa? 
threadID=627890&tstart=90)

Thanks

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0015.html

From joachim at buechse.de  Tue Jun 20 09:20:29 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 17:20:29 +0200
Subject: [Rxtx] 2.0x in sync with 2.1x
Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>

I have added most of the changes from the 2.1 branch to the 2.0 branch.

This includes
  - correction of illegal javadoc comments
  - implementation errors in handling of Thread.interrupt in  
RXTXPort.java
  - MacOS X locking without lock files/special user groups
  - XCode project which builds a universal binary library
  - updated documentation for OSX

I have done some minimal testing (only G4).
[Trent: there are still some changes you made for specific baud  
rates. I will not sync this, as I can not test them. From my  
perspective we are ready for 2.08/2.18]

The updated documentation can be found in the file README.OSX. Here  
it is:

------------------------ Required files -----------------------

To use or compile RXTX 2.0.x you need to downlad the "generic"  
version (2.0.3)
of the javax.comm implementation from Sun. The zip you download  
contains an
archive comm.jar which is required:

- To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar

- To run the app you will need comm.jar in the classpath or in  
{java.lib.path}


------------------------ Installation on MacOSX -----------------------

WARNING: Please read this section until the end.

---
Preparation
---

You may want to spare your users the burden of modifying the global VM
installation. OSX has several different VM versions installed by  
default and
regular users will be unable to figure out which version will load your
application.

If you provide the class

package com.sun.comm;
public class SolarisDriver extends gnu.io.RXTXCommDriver {
}

and make sure, that it is present in the classpath before Suns  
"generic" comm.jar
your users can skip the following step:

Create a file named
    javax.comm.properties
in the directory
    /System/Library/Frameworks/JavaVM.framework/Home/lib/
which contains (only) the following line (no leading space):
    Driver=gnu.io.RXTXCommDriver



----
The unsafe way of using RXTX on OS X:
----

RXTX can be installed by putting the files
   libSerial.jnilib
   RXTXcomm.jar
   comm.jar
into the folder
   /Library/Java/Extensions

This is NOT RECOMMENDED as it creates versioning conflicts among  
applications.
However you may be forced to install it this way if an application  
was written
for Windows or Linux, requires RXTX and you are not able to change  
its starter.


----
The safe way of using RXTX on OS X:
----

Make sure that you have no (older) version of RXTX installed in
   /Library/Java/Extensions
   /System/Library/Java/Extensions
   /usr/lib/java

Put
   libSerial.jnilib
in the directory of the application (the JavaVM will find it there). Add
   RXTXComm.jar
   comm.jar
to the application classpath or include the classes in the  
application jar.
(Some applications already include the RXTX classes in their  
application jar,
in which case only the file libSerial.jnilib is required).


----
History
----

Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation  
of lockfiles
required special permissions for the user executing an application  
based on RXTX.
To simplify the setup RXTX came with an installer modifying group  
permissions
and installing RXTX in the global location /Library/Java/Extensions.  
However
this was prune to versioning conflicts and is no longer recommended.

--------------------- Build instructions for OSX XCode  
-------------------

contributed by Joachim Buechse <joachim at buechse.de>
original version by Dmitry Markman <dmarkman at mac.com>

System requirements for building:
MacOSX 10.4
XCode 2.3

   open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj
   choose libSerial.jnilib target
   build

After the build you will find RXTXcomm.jar and libSerial.jnilib files  
in the
directory build/Development.

In case you can't find RXTXcomm.jar build the RXTXcomm target manually.
In case of (serious) problems feel free to contact joachim at buechse.de .



From tjarvi at qbang.org  Tue Jun 20 22:01:45 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT)
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
Message-ID: <Pine.LNX.4.61.0606202127270.14139@www>

> ---
> Preparation
> ---
>
> You may want to spare your users the burden of modifying the global VM
> installation. OSX has several different VM versions installed by
> default and
> regular users will be unable to figure out which version will load your
> application.
>
> If you provide the class
>
> package com.sun.comm;
> public class SolarisDriver extends gnu.io.RXTXCommDriver {
> }
>
> and make sure, that it is present in the classpath before Suns
> "generic" comm.jar
> your users can skip the following step:

Hi Joachim

With regards to the above, I have not seen that we have Sun's OK to 
promote that.  I'm not very comfortable with the distribution 
documentation advocating this without Sun agreeing.

I see your point but I'd rather not actively promote putting classes in 
Sun's namespace without permission if you don't mind.  This isn't about 
what is in a license.

I'll go through the code tomorrow night.  It was a late night at work 
today.  There is also a w32 fix comming for people opening and closing 
multiple ports.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Wed Jun 21 01:56:45 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 21 Jun 2006 09:56:45 +0200
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <Pine.LNX.4.61.0606202127270.14139@www>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
	<Pine.LNX.4.61.0606202127270.14139@www>
Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>

Hello Trent,

I guess we will not get an explicit OK from Sun for such a hack. I  
think Paul has made it pretty clear, that he does not have the  
resources to modify the 2.x or 3.x code for the needs of RXTX. I'm  
not thrilled but OK with the current API. Hence I dont agree with  
Paul's idea to start a new JSR to fix the implementation - but that's  
mainly because I dont have the time to push it. According to their  
Readme Sun sees no business case in having cross platform support for  
javax.comm - that is sad but it's none of my business. However I  
prefer to program versus javax.comm in my projects as this gives an  
advanced user the chance to exchange the provider without access to  
the code.

I interpret Pauls reponse to my original "Request for comment" as a  
quiet acceptance of the hack I propose (he did respond, but not at  
all to the sun.comm namespace suggestion). This is certainly not  
something we should put into RXTXcomm.jar but hinting a work around  
for implementation errors should be allowed. That's why I've choosen  
the wording "You may want to spare" and "If you provide". The company  
I worked for has choosen similar hacks for years to fix bugs in swing  
for JDK1.1 applications. Those hacks were usually included in their  
own swingpatch.jar.

Having said all that - I do not take it as an insult if you remove  
the paragraph from the Readme. I appreciate that you notified me  
before. It would be interesting to hear some more opinions from the  
list members...

Best regards,
Joachim


On 21.06.2006, at 06:01, Trent Jarvi wrote:

>> ---
>> Preparation
>> ---
>>
>> You may want to spare your users the burden of modifying the  
>> global VM
>> installation. OSX has several different VM versions installed by
>> default and
>> regular users will be unable to figure out which version will load  
>> your
>> application.
>>
>> If you provide the class
>>
>> package com.sun.comm;
>> public class SolarisDriver extends gnu.io.RXTXCommDriver {
>> }
>>
>> and make sure, that it is present in the classpath before Suns
>> "generic" comm.jar
>> your users can skip the following step:
>
> Hi Joachim
>
> With regards to the above, I have not seen that we have Sun's OK to
> promote that.  I'm not very comfortable with the distribution
> documentation advocating this without Sun agreeing.
>
> I see your point but I'd rather not actively promote putting  
> classes in
> Sun's namespace without permission if you don't mind.  This isn't  
> about
> what is in a license.
>
> I'll go through the code tomorrow night.  It was a late night at work
> today.  There is also a w32 fix comming for people opening and closing
> multiple ports.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Wed Jun 21 02:03:33 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 21 Jun 2006 10:03:33 +0200
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
	<6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
Message-ID: <BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>

See System.load(String) [it's also mentioned under the URL you posted].

Regards,
Joachim


On 20.06.2006, at 18:23, Brian Schlining wrote:

> So how do you use it to dynamically load a native lib? I've read  
> that you can't really modify the java.library.path after the JVM  
> has been launched. (http://forum.java.sun.com/thread.jspa? 
> threadID=627890&tstart=90)
>
> Thanks
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From baris.ozkan at elikasu.com.tr  Wed Jun 21 07:58:06 2006
From: baris.ozkan at elikasu.com.tr (Baris)
Date: Wed, 21 Jun 2006 16:58:06 +0300
Subject: [Rxtx] RS 232 ..additional parameters
Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>

Hi,
 
Currently i am developing an application that requires to connect to a
remote rs232 device through  a dialup connection.
 
My problem is that the communication needs several more connection
parameters (i extracted that information from the vendor's dll , listed at
the end of the message)
 
I explored rxtx API and src files and could not find methods to set a
majority  of the parameters.
Am i missing any point or does rxtx is limited to soem standard set of
functionality(e.g. commAPI)? How  is it possible ,if i want to put some
extensions(???) to current rxtx implementation?
 
I am not very good at rs232 programming so excuse me if this message  is
boring one.
 
Thanx
 
Baris Ozkan
 
 
A Listing of Parameters:
 
 
typedef struct _DCB {

DWORD DCBlength; /* sizeof(DCB) */

DWORD BaudRate; /* Baudrate at which running */

DWORD fBinary: 1; /* Binary Mode (skip EOF check) */

DWORD fParity: 1; /* Enable parity checking */

DWORD fOutxCtsFlow:1; /* CTS handshaking on output */

DWORD fOutxDsrFlow:1; /* DSR handshaking on output */

DWORD fDtrControl:2; /* DTR Flow control */

DWORD fDsrSensitivity:1; /* DSR Sensitivity */

DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */

DWORD fOutX: 1; /* Enable output X-ON/X-OFF */

DWORD fInX: 1; /* Enable input X-ON/X-OFF */

DWORD fErrorChar: 1; /* Enable Err Replacement */

DWORD fNull: 1; /* Enable Null stripping */

DWORD fRtsControl:2; /* Rts Flow control */

DWORD fAbortOnError:1; /* Abort all reads and writes on Error */

DWORD fDummy2:17; /* Reserved */

WORD wReserved; /* Not currently used */

WORD XonLim; /* Transmit X-ON threshold */

WORD XoffLim; /* Transmit X-OFF threshold */

BYTE ByteSize; /* Number of bits/byte, 4-8 */

BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */

BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */

char XonChar; /* Tx and Rx X-ON character */

char XoffChar; /* Tx and Rx X-OFF character */

char ErrorChar; /* Error replacement char */

char EofChar; /* End of Input character */

char EvtChar; /* Received Event character */

WORD wReserved1; /* Fill for now. */

} DCB, *LPDCB;

typedef struct _COMMTIMEOUTS {

DWORD ReadIntervalTimeout; /* Maximum time between read chars. */

DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */

DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */

DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */

DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */

} COMMTIMEOUTS,*LPCOMMTIMEOUTS;

dcb.fOutX = FALSE;

dcb.fInX = FALSE;

dcb.fOutxCtsFlow = FALSE;

dcb.fBinary = TRUE;

dcb.fRtsControl = RTS_CONTROL_ENABLE;

SetCommState(hComm , &dcb ); 

COMMTIMEOUTS commTimeOut;

GetCommTimeouts(hComm, &commTimeOut );

commTimeOut.WriteTotalTimeoutMultiplier = 1; 

commTimeOut.WriteTotalTimeoutConstant = 18; 

// commTimeOut.ReadIntervalTimeout = 28; 

commTimeOut.ReadIntervalTimeout = 0; 

// commTimeOut.ReadTotalTimeoutMultiplier = 184; 

commTimeOut.ReadTotalTimeoutMultiplier = 300; 

// commTimeOut.ReadTotalTimeoutConstant = 1200;

commTimeOut.ReadTotalTimeoutConstant = 1200;

SetCommTimeouts(hComm, &commTimeOut);

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0015.html

From ajmas at sympatico.ca  Wed Jun 21 08:14:26 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Wed, 21 Jun 2006 10:14:26 -0400
Subject: [Rxtx] When is 2.18 planned for?
Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

Just curious as to know if there is a target date for 2.18?

Andre



From brian at mbari.org  Wed Jun 21 09:36:00 2006
From: brian at mbari.org (Brian Schlining)
Date: Wed, 21 Jun 2006 08:36:00 -0700
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
	<6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
	<BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>
Message-ID: <A21C9BC0-7894-4B08-AC82-44E11AB3D461@mbari.org>

Ha!!

I suppose I should read my own postings. ;-)

Thanks
B

On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote:

> See System.load(String) [it's also mentioned under the URL you  
> posted].
>
> Regards,
> Joachim
>
>
> On 20.06.2006, at 18:23, Brian Schlining wrote:
>
>> So how do you use it to dynamically load a native lib? I've read
>> that you can't really modify the java.library.path after the JVM
>> has been launched. (http://forum.java.sun.com/thread.jspa?
>> threadID=627890&tstart=90)

Brian Schlining
Software Engineer
http://www.mbari.org




From ajmas at sympatico.ca  Wed Jun 21 16:41:28 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Wed, 21 Jun 2006 18:41:28 -0400
Subject: [Rxtx] CVS build question
Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X:

 The JCL extension to RxTx requires comm.jar
 If you intend to use RxTx for commapi support comm.jar
 needs to be located in  /System/Library/Frameworks/JavaVM.framework/
  Versions/1.5/Home/lib/ext/comm.jar

I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me.

On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native).

Andre






From tjarvi at qbang.org  Wed Jun 21 18:00:04 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT)
Subject: [Rxtx] CVS build question
In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606211756310.14139@www>

On Wed, 21 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> Is the CVS repository meant to build for gnu.io or javax.comm? I ask 
> this, because I see the following when calling ./configure from MacOS X:
>
> The JCL extension to RxTx requires comm.jar
> If you intend to use RxTx for commapi support comm.jar
> needs to be located in  /System/Library/Frameworks/JavaVM.framework/
>  Versions/1.5/Home/lib/ext/comm.jar
>
> I am wanting to build for the gnu.io package, since I want to jump ahead 
> and see if the changes, intended for 2.18 for MacOS X, work for me.
>
> On a side note /Library/Java/Extensions should be included as a valid 
> search path for the JAR, since this is where Apple recommends placing 
> third party extensions (both Java and native).
>

rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel"
rxtx 2.0 src is obtained with "cvs checkout rxtx-devel"

rxtx 2.1 is a complete package in namespace gnu.io
rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 18:02:23 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT)
Subject: [Rxtx] When is 2.18 planned for?
In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606211800180.14139@www>

On Wed, 21 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> Just curious as to know if there is a target date for 2.18?
>

Hi Andre

"When it is ready" :)

Probably this weekend.  Maybe sooner.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 18:10:18 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT)
Subject: [Rxtx] RS 232 ..additional parameters
In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>
References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>
Message-ID: <Pine.LNX.4.61.0606211805010.14139@www>

On Wed, 21 Jun 2006, Baris wrote:

> Hi,
>
> Currently i am developing an application that requires to connect to a
> remote rs232 device through  a dialup connection.
>
> My problem is that the communication needs several more connection
> parameters (i extracted that information from the vendor's dll , listed at
> the end of the message)
>
> I explored rxtx API and src files and could not find methods to set a
> majority  of the parameters.
> Am i missing any point or does rxtx is limited to soem standard set of
> functionality(e.g. commAPI)? How  is it possible ,if i want to put some
> extensions(???) to current rxtx implementation?
>
> I am not very good at rs232 programming so excuse me if this message  is
> boring one.
>
> Thanx
>

Hi Baris

> typedef struct _DCB {
> typedef struct _COMMTIMEOUTS {

These are all handled in termios.c.  It is possible to add extensions to 
rxtx 2.1.  It may well be that the defaults are the same for the variables 
not covered by the existing API.  You can dump the DCB and COMMTIMEOUTS 
from inside termios.c to compare.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 20:23:30 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT)
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
	<Pine.LNX.4.61.0606202127270.14139@www>
	<789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>
Message-ID: <Pine.LNX.4.61.0606212012210.14139@www>

> I'm
> not thrilled but OK with the current API. Hence I dont agree with
> Paul's idea to start a new JSR to fix the implementation - but that's
> mainly because I dont have the time to push it. According to their
> Readme Sun sees no business case in having cross platform support for
> javax.comm - that is sad but it's none of my business. However I
> prefer to program versus javax.comm in my projects as this gives an
> advanced user the chance to exchange the provider without access to
> the code.

Hi Joachim

With regards to the JSR, I think that would be Doug's call.  The effort I 
put in would have to be on my own time which would not be a great deal.  I 
could help things go smoothly but thats not the same as pushing something 
through.

--
Trent Jarvi
tjarvi at qbang.org



From vt at freehold.crocodile.org  Wed Jun 21 21:05:22 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Wed, 21 Jun 2006 20:05:22 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
Message-ID: <449A08F2.3020106@freehold.crocodile.org>

Hello all,

I know this question may belong to JSR lists, but since all interested 
parties are here, I thought I just ask this question here, again...

A while ago I run into a problem and wrote a rant, here: 
http://servomaster.sourceforge.net/dev/serial-usb.html
At the time of writing I didn't think of adding another possible 
solution - changing the CommAPI specs to support removable devices. 
Apparently, Serial/USB bridges are here to stay, and this issue has to 
be addressed.

Wonder if anything changed since, and any abstractions for supporting 
removable devices made it into current or future Java CommAPI drafts - 
Paul, any comments?

--vt



From joachim at buechse.de  Thu Jun 22 01:59:54 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 22 Jun 2006 09:59:54 +0200
Subject: [Rxtx] CVS build question
In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de>

Hello Andre,

I am not sure how well the configure/make mechanism will work on OSX.  
I know that a while ago some contributors tried to get configure/make  
working on OSX but from comments I found in the readmes this work was  
only partially successfull. For compilation on OSX we have used the  
ProjectBuilder/XCode projects you can find in MACOSX_IDE.

Regarding the  ./configure comment:
RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config  
file javax.comm.properties. The later MUST reside in {java.home}/lib.  
As the two only work together putting comm.jar into  /Library/Java/ 
Extensions  and hence making it available to all current and future  
VM installations will only add to confusion.

Regards,
Joachim

On 22.06.2006, at 00:41, Andre-John Mas wrote:

> Hi,
>
> Is the CVS repository meant to build for gnu.io or javax.comm? I  
> ask this, because I see the following when calling ./configure from  
> MacOS X:
>
>  The JCL extension to RxTx requires comm.jar
>  If you intend to use RxTx for commapi support comm.jar
>  needs to be located in  /System/Library/Frameworks/JavaVM.framework/
>   Versions/1.5/Home/lib/ext/comm.jar
>
> I am wanting to build for the gnu.io package, since I want to jump  
> ahead and see if the changes, intended for 2.18 for MacOS X, work  
> for me.
>
> On a side note /Library/Java/Extensions should be included as a  
> valid search path for the JAR, since this is where Apple recommends  
> placing third party extensions (both Java and native).
>
> Andre
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Thu Jun 22 02:51:05 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 22 Jun 2006 10:51:05 +0200
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449A08F2.3020106@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>

Hello Vadim,

I think that your rant is to the point. However it is a bit like  
saying that Windows is at the source of email degradation and the  
only solution is to have users switch to safer operating systems.

I don't see how javax.comm or RXTX can address the problems you  
mention. Of course it would be super cool if javax.comm could magicly  
find the "matching" usb-device and query it's configuration via the  
usb protocol - however this magic (mapping /dev/xyz to its underlying  
USB device) is not supported by any kernel APIs I am aware of. It  
could be supported via POSSIX ioctl calls but then you should address  
your rant to the POSSIX group...

So for the time beeing it's either up to the virtual comm port driver  
to provide a usefull name under /dev/ or to the user choosing the  
right port to use. One example of a smart(er) com port driver is the  
KDDI driver for OSX, which will create device names like "/dev/ 
cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- 
encoded into the bridge chip. The same driver for windows also has  
some options allowing it in theory to recreate the same COMx every  
time a device is plugged/unplugged.

For most industrial applications however it will be up to the user to  
choose the right port (without getting a lot of help doing so).

Probing serial ports can go wrong, that's right. However any serial  
device developper would be well adviced to implement a basic set of  
Hayes AT modem commands (be it a modem or not). Especially AT I0.  
Anyone failing to do so risks that the users favourite TCP/PPP/FAX  
application or stack will kill the device in short time.

Best regards,
Joachim


On 22.06.2006, at 05:05, Vadim Tkachenko wrote:

> Hello all,
>
> I know this question may belong to JSR lists, but since all interested
> parties are here, I thought I just ask this question here, again...
>
> A while ago I run into a problem and wrote a rant, here:
> http://servomaster.sourceforge.net/dev/serial-usb.html
> At the time of writing I didn't think of adding another possible
> solution - changing the CommAPI specs to support removable devices.
> Apparently, Serial/USB bridges are here to stay, and this issue has to
> be addressed.
>
> Wonder if anything changed since, and any abstractions for supporting
> removable devices made it into current or future Java CommAPI drafts -
> Paul, any comments?
>
> --vt
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From vt at freehold.crocodile.org  Thu Jun 22 13:16:03 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 12:16:03 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
Message-ID: <20060622191603.GA17487@freehold.crocodile.org>

Hello Joachim,

> I think that your rant is to the point. However it is a bit like  
> saying that Windows is at the source of email degradation and the  
> only solution is to have users switch to safer operating systems.

I guess the problem is that the rant itself is obsolete and has to be
updated according to latest developments. At the time of writing there
weren't that many bridges around, and the trend didn't manifest itself as it
does now.

> I don't see how javax.comm or RXTX can address the problems you  
> mention.

I would agree that javax.comm won't be able to address the problem, at least
in the short run. As for RxTx - well, nobody prevents it from being a
superset of CommAPI specification, right? RxTx being the de-facto standard
for quite a few platforms, I'd daresay the standard may follow.

> Of course it would be super cool if javax.comm could magicly find the
> "matching" usb-device and query it's configuration via the usb protocol -
> however this magic (mapping /dev/xyz to its underlying USB device) is not
> supported by any kernel APIs I am aware of. It could be supported via
> POSSIX ioctl calls but then you should address your rant to the POSSIX
> group...

As a matter of fact, my bigger concern is addressing the fact that a serial
device can now be removable. This hasn't been the case before, and it
clearly is now. Regarding the above, well, I guess if we accept this fact,
we also need to accept the fact that we need at least rudimentary means of
identification of a serial device. For the USB case, it would usually be the
vendor/product ID, plus possible serial number - but it is irrelevant what
exactly the identifying information is, as long as it allows to identify the
device.

A paradigm shift is required, this is what I wanted to say. Serial devices
can be removed and replaced, it's now our turn to learn to deal with it.

> Joachim

--vt


From jredman at ergotech.com  Thu Jun 22 13:41:44 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 13:41:44 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
Message-ID: <449AF278.6000903@ergotech.com>


Vadim Tkachenko wrote:
> A paradigm shift is required, this is what I wanted to say. Serial devices
> can be removed and replaced, it's now our turn to learn to deal with it.

The removal if the serial port hardly significantly different from the 
removal of the device attached to the serial port.   Different, 
slightly, but not a "paradigm shift".

And yes, someone could unplug a USB serial device and plug it into a 
different USB port so that it has a different name/number, but they 
could do that with the device itself, move it from com1 to com2.

Am I missing something?

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 13:57:27 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 12:57:27 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449AF278.6000903@ergotech.com>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
Message-ID: <20060622195727.GA20247@freehold.crocodile.org>

On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote:
> 
> Vadim Tkachenko wrote:
> > A paradigm shift is required, this is what I wanted to say. Serial devices
> > can be removed and replaced, it's now our turn to learn to deal with it.
> 
> The removal if the serial port hardly significantly different from the 
> removal of the device attached to the serial port.   Different, 
> slightly, but not a "paradigm shift".
> 
> And yes, someone could unplug a USB serial device and plug it into a 
> different USB port so that it has a different name/number, but they 
> could do that with the device itself, move it from com1 to com2.
> 
> Am I missing something?

Yes, the fact that they could unplug a device A and plug a device B. With
the introduction of the concept of removability, the notion of the serial
port itself is not as important anymore, but the notion of the unique device
identifier is.

Consider a situation: long running system (enterprise HVAC, tens of nodes,
tens of thousands square feet area, hundreds of thousand dollars worth of
equipment being conditioned, can't shut down), serial/usb device fails, is
replaced by an identical device with a different serial #.

A little bit farfetched, but hopefully highlighting the point I'm trying to
make.

> Jim

--vt


From jredman at ergotech.com  Thu Jun 22 14:37:38 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 14:37:38 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>	<20060622191603.GA17487@freehold.crocodile.org>	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
Message-ID: <449AFF92.8080003@ergotech.com>


Vadim Tkachenko wrote:
>>
>> Am I missing something?
> 
> Yes, the fact that they could unplug a device A and plug a device B. With
> the introduction of the concept of removability, the notion of the serial
> port itself is not as important anymore, but the notion of the unique device
> identifier is.

Serial devices are always removable.  I could unplug _serial_ device A 
and plug in _serial_ device B.  We have systems running with two RS485 
ports, one talks to a Modbus PLC network one to a number of drives on a 
proprietary protocol.  If you plug the wrong DB9 into the wrong port the 
application doesn't work.

If you dangle a USB 485 converter on the end of the DB9 you've just 
moved the problem from RS485 to USB, but the problem/effect is the same.

> 
> Consider a situation: long running system (enterprise HVAC, tens of nodes,
> tens of thousands square feet area, hundreds of thousand dollars worth of
> equipment being conditioned, can't shut down), serial/usb device fails, is
> replaced by an identical device with a different serial #.
> 
> A little bit farfetched, but hopefully highlighting the point I'm trying to
> make.

Nothing's changed.  If I had a 4 port ISA board and plugged it into my 
new shiny '386 machine.  I could have com ports 9-12.  If I took a board 
off the shelf and didn't set the jumpers, I would have com ports 3-6.

The problem's the same.  If you replace with identical product then the 
com ports  will be the same - no software changes required.  If you 
replace one piece of hardware with hardware from a different 
manufacturer, then the naming/numbering may change.  You're physically 
changing the system, so may reasonably expect to have to make a software 
change.  RXTX actually handles this situation quite well with the -D 
command line option.  (My experience has generally been that the port 
number depends more on the USB port used than the hardware - so the 
chances are even with a hardware change the port number/name will be the 
same.)

Slightly Off Topic - there is a reason why industrial users will pay a 
premium for continued availability of hardware.  Yes you can mail-order 
a $10 USB converter and it will work, but there's no guarantee that the 
next time you buy the same part number from the same vendor it will be 
the same.  The industrial vendors will charge you $100+ for the same 
item, but it will be the same every time you buy it for the next 5 to 10 
years.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 14:37:19 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 13:37:19 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
Message-ID: <20060622203719.GA22521@freehold.crocodile.org>

Hello again,

And while I'm at it, why don't just say this: give me one good reason to
write 3+ different ways of handling removable devices, one for USB, one for
FireWire, one for serial...

I understand very well that this goes way beyond the scope of RxTx and
CommAPI and will require cooperation between them and javax.usb and whatever
JSR is responsible for FireWire implementation - but the end result is well
worth it. Abstract out and generalize arrival/departure/monitoring/discovery
API, provide protocol specific extensions for each, live happily ever after.

--vt


On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote:
> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote:
> > 
> > Vadim Tkachenko wrote:
> > > A paradigm shift is required, this is what I wanted to say. Serial devices
> > > can be removed and replaced, it's now our turn to learn to deal with it.
> > 
> > The removal if the serial port hardly significantly different from the 
> > removal of the device attached to the serial port.   Different, 
> > slightly, but not a "paradigm shift".
> > 
> > And yes, someone could unplug a USB serial device and plug it into a 
> > different USB port so that it has a different name/number, but they 
> > could do that with the device itself, move it from com1 to com2.
> > 
> > Am I missing something?
> 
> Yes, the fact that they could unplug a device A and plug a device B. With
> the introduction of the concept of removability, the notion of the serial
> port itself is not as important anymore, but the notion of the unique device
> identifier is.
> 
> Consider a situation: long running system (enterprise HVAC, tens of nodes,
> tens of thousands square feet area, hundreds of thousand dollars worth of
> equipment being conditioned, can't shut down), serial/usb device fails, is
> replaced by an identical device with a different serial #.
> 
> A little bit farfetched, but hopefully highlighting the point I'm trying to
> make.
> 
> > Jim
> 
> --vt
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx


From jredman at ergotech.com  Thu Jun 22 15:13:49 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 15:13:49 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>	<20060622191603.GA17487@freehold.crocodile.org>	<449AF278.6000903@ergotech.com>	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
Message-ID: <449B080D.9080208@ergotech.com>


Vadim Tkachenko wrote:
> Hello again,
> 
> And while I'm at it, why don't just say this: give me one good reason to
> write 3+ different ways of handling removable devices, one for USB, one for
> FireWire, one for serial...

You don't, they're all the same "I have lost communication with my 
serial device".

The only thing you could really do is improve error reporting by knowing 
the exact sub-system.  ("Device X which is/was attached to USB port Y is 
no longer functioning, please check the USB ports, the device, the 
cables and anything else you can think of that may be a cause of 
failure.")  That just requires an intelligent description of the port.

> I understand very well that this goes way beyond the scope of RxTx and
> CommAPI and will require cooperation between them and javax.usb and whatever
> JSR is responsible for FireWire implementation - but the end result is well
> worth it. Abstract out and generalize arrival/departure/monitoring/discovery
> API, provide protocol specific extensions for each, live happily ever after.

There's a huge list of pseudo-serial devices each with a different set 
of requirements, Bluetooth, RFC 2217, a host of proprietary systems, 
etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I 
have no clue how you'd implement them in a general/cross platform sense.

You haven't convinced me (and only me, others may see something that I 
don't, I'm not speaking for them) that this mechanism can be implemented 
in any practical sense.  That is, that the implementation could be wide 
enough to be consider generally available in RXTX regardless of the 
serial port implementation, platform, etc..  However, if you can come up 
with a general design and a reference implementation for one subsystem, 
I'd like to see it and might get on board.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 15:40:55 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 14:40:55 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449B080D.9080208@ergotech.com>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
Message-ID: <20060622214055.GA25497@freehold.crocodile.org>

On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote:
> 
> Vadim Tkachenko wrote:
> > Hello again,
> > 
> > And while I'm at it, why don't just say this: give me one good reason to
> > write 3+ different ways of handling removable devices, one for USB, one for
> > FireWire, one for serial...
> 
> You don't, they're all the same "I have lost communication with my 
> serial device".

"I have lost communication with my ${protocol} device".

> The only thing you could really do is improve error reporting by knowing 
> the exact sub-system.  ("Device X which is/was attached to USB port Y is 
> no longer functioning, please check the USB ports, the device, the 
> cables and anything else you can think of that may be a cause of 
> failure.")

"Device ${id} which is/was attached to ${protocol} port ${port} is no longer
functioning, please check the ${protocol} ports, the device, the
${protocol_media} and anything else you can think of that may be a cause of
failure".

>  That just requires an intelligent description of the port.

Agree absolutely.

> > I understand very well that this goes way beyond the scope of RxTx and
> > CommAPI and will require cooperation between them and javax.usb and whatever
> > JSR is responsible for FireWire implementation - but the end result is well
> > worth it. Abstract out and generalize arrival/departure/monitoring/discovery
> > API, provide protocol specific extensions for each, live happily ever after.
> 
> There's a huge list of pseudo-serial devices each with a different set 
> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, 
> etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I 
> have no clue how you'd implement them in a general/cross platform sense.

That's because some of the protocols were created decades ago when
autoconfiguration wasn't even conceived, much less practical. RS232/RS485
don't have a clue about identity discovery, and even capabilities discovery
beyond obvious 8N1 etc.

I agree that today all these protocols have generally incompatible
strategies for handling the situations I'm trying to address, but there's
nothing that says it's not an oversight. Besides, we're dealing with the
devices at a level of abstraction that allows some simplifications and
generalizations, at least part of the time - unless it's the protocol
specific features we're dealing with.

> You haven't convinced me (and only me, others may see something that I 
> don't, I'm not speaking for them) that this mechanism can be implemented 
> in any practical sense.  That is, that the implementation could be wide 
> enough to be consider generally available in RXTX regardless of the 
> serial port implementation, platform, etc..  However, if you can come up 
> with a general design and a reference implementation for one subsystem, 
> I'd like to see it and might get on board.

Actually, I wasn't even thinking about all this stuff when I wrote the first
message on the subject :) Now that you mention it - well, I'm not sure I can
chew the piece I just tried to bite in reasonable amount of time.

How do you eat an elephant? One bite at a time. If we could agree that a
small step in the specification is acceptable at this time, and express
further intentions, things may start happening.

To put it succinctly:

- Concept of a "port" should be augmented with a concept of a "device". A
device may be attached to a port in an implicit or explicit way.
- Implicitly connected device is exactly what the current scope of the
specification covers. No new functionality is offered.
- Explicitly connected device supports detachable device semantics, just as
other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a
few).
- The input and output streams are not properties of a port now, but
properties of the device attached to the port.
- A mechanism to allow listening for device arrivals and departures must be
made available.

That's it, off the top of my head.

I understand that this goes completely against current javax.comm specs, but
an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be
difficult to implement without disrupting javax.comm compatibility.

One concern is how to deal with the device identity - but there's no general
way of dealing with this at this time, devices may or may not offer identity
discovery.

> Jim

--vt


From joachim at buechse.de  Fri Jun 23 02:12:43 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 23 Jun 2006 10:12:43 +0200
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
Message-ID: <CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>

Hello++ Vadim,

I would like to repeat that your request is best addressed to the  
POSSIX standardization group - or maybe the BSD/Linux maintainers. If  
you convince the BSD or Linux guys to add this kind of functionality  
(they can as most of there VCP drivers are open source), there is a  
certain chance that other vendors will pick it up. I assure you that  
RXTX will happily provide this functionality once it's possible - I'm  
sure there is more than one maintainer that would love to add it.  
Having this concept penetrate the market may take some years though.

SHORT: The solution you would like to see could be added to the API  
but it can not be implemented (at least not on the platforms I know).  
There are currently no hooks in the kernel that allow you to discover  
"the device" or even the "means of connection" based on an existing  
"device file descriptor" ie COM-port or /dev/... entry. The name  
mapping of the device is handled by the virtual com port driver of  
the device. Unless you are suggesting RXTX should reimplement virtual  
com port drivers for all usb/serial bridges out there your request is  
understandable from a users viewpoint but simply not realizable. It's  
like asking that the Socket api should identify the computer behind  
an IP address (ie by its Ethernet address). While this COULD be  
implemented in TCP/IP, it IS not, and hence there is no point adding  
such a function to the Socket API.

The current trend for USB/Bluetooth/Irda/etc connected devices is  
going away from serial port abstraction towards RPC (ie the drivers  
provide a device specific or device class specific driver that  
provides an application level api to the device functions). The line  
level protocol is often not even published.

Best regards,
Joachim

On 22.06.2006, at 23:40, Vadim Tkachenko wrote:

> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote:
>>
>> Vadim Tkachenko wrote:
>>> Hello again,
>>>
>>> And while I'm at it, why don't just say this: give me one good  
>>> reason to
>>> write 3+ different ways of handling removable devices, one for  
>>> USB, one for
>>> FireWire, one for serial...
>>
>> You don't, they're all the same "I have lost communication with my
>> serial device".
>
> "I have lost communication with my ${protocol} device".
>
>> The only thing you could really do is improve error reporting by  
>> knowing
>> the exact sub-system.  ("Device X which is/was attached to USB  
>> port Y is
>> no longer functioning, please check the USB ports, the device, the
>> cables and anything else you can think of that may be a cause of
>> failure.")
>
> "Device ${id} which is/was attached to ${protocol} port ${port} is  
> no longer
> functioning, please check the ${protocol} ports, the device, the
> ${protocol_media} and anything else you can think of that may be a  
> cause of
> failure".
>
>>  That just requires an intelligent description of the port.
>
> Agree absolutely.
>
>>> I understand very well that this goes way beyond the scope of  
>>> RxTx and
>>> CommAPI and will require cooperation between them and javax.usb  
>>> and whatever
>>> JSR is responsible for FireWire implementation - but the end  
>>> result is well
>>> worth it. Abstract out and generalize arrival/departure/ 
>>> monitoring/discovery
>>> API, provide protocol specific extensions for each, live happily  
>>> ever after.
>>
>> There's a huge list of pseudo-serial devices each with a different  
>> set
>> of requirements, Bluetooth, RFC 2217, a host of proprietary systems,
>> etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I
>> have no clue how you'd implement them in a general/cross platform  
>> sense.
>
> That's because some of the protocols were created decades ago when
> autoconfiguration wasn't even conceived, much less practical. RS232/ 
> RS485
> don't have a clue about identity discovery, and even capabilities  
> discovery
> beyond obvious 8N1 etc.
>
> I agree that today all these protocols have generally incompatible
> strategies for handling the situations I'm trying to address, but  
> there's
> nothing that says it's not an oversight. Besides, we're dealing  
> with the
> devices at a level of abstraction that allows some simplifications and
> generalizations, at least part of the time - unless it's the protocol
> specific features we're dealing with.
>
>> You haven't convinced me (and only me, others may see something  
>> that I
>> don't, I'm not speaking for them) that this mechanism can be  
>> implemented
>> in any practical sense.  That is, that the implementation could be  
>> wide
>> enough to be consider generally available in RXTX regardless of the
>> serial port implementation, platform, etc..  However, if you can  
>> come up
>> with a general design and a reference implementation for one  
>> subsystem,
>> I'd like to see it and might get on board.
>
> Actually, I wasn't even thinking about all this stuff when I wrote  
> the first
> message on the subject :) Now that you mention it - well, I'm not  
> sure I can
> chew the piece I just tried to bite in reasonable amount of time.
>
> How do you eat an elephant? One bite at a time. If we could agree  
> that a
> small step in the specification is acceptable at this time, and  
> express
> further intentions, things may start happening.
>
> To put it succinctly:
>
> - Concept of a "port" should be augmented with a concept of a  
> "device". A
> device may be attached to a port in an implicit or explicit way.
> - Implicitly connected device is exactly what the current scope of the
> specification covers. No new functionality is offered.
> - Explicitly connected device supports detachable device semantics,  
> just as
> other protocols do (USB, FireWire, Wireless USB, Bluetooth, to  
> mention a
> few).
> - The input and output streams are not properties of a port now, but
> properties of the device attached to the port.
> - A mechanism to allow listening for device arrivals and departures  
> must be
> made available.
>
> That's it, off the top of my head.
>
> I understand that this goes completely against current javax.comm  
> specs, but
> an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern )  
> won't be
> difficult to implement without disrupting javax.comm compatibility.
>
> One concern is how to deal with the device identity - but there's  
> no general
> way of dealing with this at this time, devices may or may not offer  
> identity
> discovery.
>
>> Jim
>
> --vt
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From vt at freehold.crocodile.org  Fri Jun 23 11:28:29 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Fri, 23 Jun 2006 10:28:29 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
	<CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
Message-ID: <20060623172829.GA5335@freehold.crocodile.org>

Hello Joachim,

> I would like to repeat that your request is best addressed to the POSSIX
> standardization group - or maybe the BSD/Linux maintainers. If you
> convince the BSD or Linux guys to add this kind of functionality (they can
> as most of there VCP drivers are open source), there is a certain chance
> that other vendors will pick it up. I assure you that RXTX will happily
> provide this functionality once it's possible - I'm sure there is more
> than one maintainer that would love to add it.

I realize this thing is bigger than RxTx itself, and I'm afraid it's too
global not to cause people to laugh before they think about it :)

> Having this concept penetrate the market may take some years though.

Well, I'm sure it'll get there, the only question is - when.

> SHORT: The solution you would like to see could be added to the API but it
> can not be implemented (at least not on the platforms I know).

I guess I'm concerned about the abstraction more than I'm concerned about
the implementation at this point.
  
> There are currently no hooks in the kernel that allow you to discover  
> "the device" or even the "means of connection" based on an existing  
> "device file descriptor" ie COM-port or /dev/... entry.

Well, I'm not so sure you need to keep the literal mapping from /dev
namespace to your device namespace. As long as you can consistently offer a
virtual serial device on top of a virtual serial port, it may be irrelevant
whether you can map it into /dev. The mapping is going be schitzofrenic
anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the
representation...

> The name mapping of the device is handled by the virtual com port driver
> of the device. Unless you are suggesting RXTX should reimplement virtual
> com port drivers for all usb/serial bridges out there your request is
> understandable from a users viewpoint but simply not realizable.

It's not so much a request but rather an offer of participation. I run a few
projects actively using serial communications, as well as USB device
drivers, in different degrees of readiness (Servomaster, Haywire, DIY
Zoning) - and it would be a perfect playground.

You mentioned above that this task is about two things: a) abstraction b)
implementation. I could start the abstraction part of it without changing
the current CommAPI, on top of it, as an adapter. Even if the removable
device semantics are not implemented, but offered, this is already a step
forward.

> It's like asking that the Socket api should identify the computer behind
> an IP address (ie by its Ethernet address). While this COULD be
> implemented in TCP/IP, it IS not, and hence there is no point adding such
> a function to the Socket API.

Thank you for bringing up this example - I guess this is just about the same
thing that I'd like to see. Socket transparently provides you with the
input/output streams, at the same time offering protocol level specifics to
you.

> The current trend for USB/Bluetooth/Irda/etc connected devices is going
> away from serial port abstraction towards RPC (ie the drivers provide a
> device specific or device class specific driver that provides an
> application level api to the device functions). The line level protocol is
> often not even published.

I can't say I'm that happy with it. The best (or, rather, worst) example is
suchlike support for the Phidget servo controller - zealous Linux developers
implemented kernel module support for it, completely hijacking a possibility
of using it on a different level (it's somewhat fixed by now, thankfully).

I believe that whenever an abstraction is offered, it must be made optional
and/or pluggable so it can be replaced by something more suited to the task.

The nature of Java applications is such that they'd probably care much more
about Java API offered, than about no matter how rich application level api
that is offered outside of Java. I've dealt with JNI adapters in the past,
and whereas they can be made reasonably stable, the very fact that you are
forced to deal with things that are not on the critical timing/memory path
and could've been done much easier in Java causes endless grief.

> Joachim

--vt


From lyon at docjava.com  Sat Jun 24 04:54:12 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Sat, 24 Jun 2006 06:54:12 -0400
Subject: [Rxtx] jsr
In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
	<CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
	<20060623172829.GA5335@freehold.crocodile.org>
Message-ID: <p060204a3c0c2c9dde4f8@[192.168.1.152]>

Hi All,
I have had some off-list discussion with Trent.
Opening up a JSR with Sun, as per Peters' suggestion
seems like a reasonable idea, to us.

Does anyone having any concerns about the JSR process
that they would like to raise?

Thanks!
  - Doug



From the.grey.lantern at gmail.com  Sat Jun 24 18:15:26 2006
From: the.grey.lantern at gmail.com (Craig Nicoll)
Date: Sun, 25 Jun 2006 01:15:26 +0100
Subject: [Rxtx] Cannot create virtual serial port
Message-ID: <a1221cc50606241715g2d1e2af6r747347dd4c20e997@mail.gmail.com>

Hello,

This is my first post on this mailing list and I hope someone can help me.

I am having great difficult establishing a virtual serial port for the
Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia
7600.

Every time I try to run the SendMessage program that comes with SMSLib, I
get the following exception: gnu.io.NoSuchPortException

The port names I have tried are:
rfcomm0
rfcomm
/dev/rfcomm0
/dev/rfcomm

This is what I have done so far:
Modified /etc/bluetooth/rfcomm.conf to include the address of my phone:

rfcomm0 {
# Automatically bind the device at startup
bind no;

# Bluetooth address of the device
device 00:0e:6d:7a:98:43;

# RFCOMM channel for the connection
channel 1;

# Description of the connection
comment "Example Bluetooth device";
}

I also tried running the following command: rfcomm bind /dev/rfcomm0

I have searched the mailing list archives and found this post where someone
had a very similar problem to me:
http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried
changing the system properties as suggested and it made no difference.

I have also been scouring Google all day to no avail.

I would be incredibly grateful if anyone could give me some tips.

Thank you,

Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060625/cfa6df35/attachment-0006.html

From tjarvi at qbang.org  Sun Jun 25 19:56:08 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT)
Subject: [Rxtx] Pending release
Message-ID: <Pine.LNX.4.61.0606251942460.15744@www>


With frustration, I was unable to get to the pending release this weekend.
The release should be comming this next week once things calm down.
The source is in CVS except for a fix for multiple ports in windows.

I had planned on doing the release this weekend but that was disrupted by 
my transportation failing in a spectacular fashion.

--
Trent Jarvi
tjarvi at qbang.org


From Pawan.Kharbanda at dot.state.co.us  Tue Jun 27 22:28:51 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 27 Jun 2006 22:28:51 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>

 Trent, 
   I have an application running in a cluster in linux environment and I
am using RXTX2.1.7 (final) with JDK1.5. The application opens and closes
serial comm ports every 30 seconds and exchanges datas. I have
experienced some of my Comm Ports are left hanging (I can see the
LCK..cufXX lock files under /var/lock folder). On putting the debugs I
found out that, it is stuck at a native call line 809 in RXTXPort.java
class (Please see the code snippet below). Can you help me explain what
this method does in the native code? Am I getting into some thread
deadlocks? Thanks in advance.

Pawan Kharbanda 


public void removeEventListener()
	{
		if (debug)
			z.reportln( "RXTXPort:removeEventListener()
called");
		waitForTheNativeCodeSilly();
		//if( monThread != null && monThread.isAlive() )
		if( monThreadisInterrupted == true )
		{
			z.reportln( "	RXTXPort:removeEventListener()
already interrupted");
			monThread = null;
			SPEventListener = null;
			return;
		}
		else if( monThread != null && monThread.isAlive() )
		{
			if (debug)
				z.reportln( "
RXTXPort:Interrupt=true");
			monThreadisInterrupted=true;
			/*
			   Notify all threads in this PID that something
is up
			   They will call back to see if its their
thread
			   using isInterrupted().
			*/
			if (debug)
				z.reportln( "	RXTXPort:calling
interruptEventLoop");
// LINE 809			interruptEventLoop( ); It never returns
out of this 
			
			if (debug)
				z.reportln( "	RXTXPort:calling
monThread.join()");
			try {
				monThread.join(1000);
			} catch (Exception ex) {
				/* yikes */
				ex.printStackTrace();
			}
			if (debug)
				z.reportln( "	RXTXPort:waiting on
isAlive()");
			while( monThread.isAlive() )
			{
				if ( debug )
					z.reportln( "	MonThread is
still alive!");
				try {
					monThread.join(1000);
					Thread.sleep( 1000 );
				} catch( Exception e ){} 
				//monThread.stop();
			}
			
		}
		if (debug)
			z.reportln( "	RXTXPort:calling gc()");
		monThread = null;
		SPEventListener = null;
		MonitorThreadLock = false;
		MonitorThreadAlive=false;
		monThreadisInterrupted=true;
		z.reportln( "RXTXPort:removeEventListener() returning");
	} 

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Sunday, June 25, 2006 7:56 PM
To: rxtx at qbang.org
Subject: [Rxtx] Pending release


With frustration, I was unable to get to the pending release this
weekend.
The release should be comming this next week once things calm down.
The source is in CVS except for a fix for multiple ports in windows.

I had planned on doing the release this weekend but that was disrupted
by my transportation failing in a spectacular fashion.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Wed Jun 28 04:17:29 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 28 Jun 2006 04:17:29 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606280406330.9561@www>



Hi Pawan

You may have found a deadlock but I've not seen on recently on linux.

If you can, please update from CVS.  This will have some close fixes. 
I'm running with the same code as is in CVS.  It is not perfect but I've 
not seen anything like you mention.  Be sure to set timeouts and 
thresholds on the port.  It may be that the port is waiting on pending io 
that never happens.  I think the CVS patches deal with this also but it 
looks like your in a better test environment to know for sure.

The exploded vehicle mentioned below is expected to be fixed today.  It 
was just a ninja small radiator hose.  The pressure test afterwards 
created its own set of problems.  Until this is resolved, I'm spending 
most of my free time commuting by bicycle.

On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>   I have an application running in a cluster in linux environment and I
> am using RXTX2.1.7 (final) with JDK1.5. The application opens and closes
> serial comm ports every 30 seconds and exchanges datas. I have
> experienced some of my Comm Ports are left hanging (I can see the
> LCK..cufXX lock files under /var/lock folder). On putting the debugs I
> found out that, it is stuck at a native call line 809 in RXTXPort.java
> class (Please see the code snippet below). Can you help me explain what
> this method does in the native code? Am I getting into some thread
> deadlocks? Thanks in advance.
>
> Pawan Kharbanda
>
>
> public void removeEventListener()
> 	{
> 		if (debug)
> 			z.reportln( "RXTXPort:removeEventListener()
> called");
> 		waitForTheNativeCodeSilly();
> 		//if( monThread != null && monThread.isAlive() )
> 		if( monThreadisInterrupted == true )
> 		{
> 			z.reportln( "	RXTXPort:removeEventListener()
> already interrupted");
> 			monThread = null;
> 			SPEventListener = null;
> 			return;
> 		}
> 		else if( monThread != null && monThread.isAlive() )
> 		{
> 			if (debug)
> 				z.reportln( "
> RXTXPort:Interrupt=true");
> 			monThreadisInterrupted=true;
> 			/*
> 			   Notify all threads in this PID that something
> is up
> 			   They will call back to see if its their
> thread
> 			   using isInterrupted().
> 			*/
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> interruptEventLoop");
> // LINE 809			interruptEventLoop( ); It never returns
> out of this
>
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> monThread.join()");
> 			try {
> 				monThread.join(1000);
> 			} catch (Exception ex) {
> 				/* yikes */
> 				ex.printStackTrace();
> 			}
> 			if (debug)
> 				z.reportln( "	RXTXPort:waiting on
> isAlive()");
> 			while( monThread.isAlive() )
> 			{
> 				if ( debug )
> 					z.reportln( "	MonThread is
> still alive!");
> 				try {
> 					monThread.join(1000);
> 					Thread.sleep( 1000 );
> 				} catch( Exception e ){}
> 				//monThread.stop();
> 			}
>
> 		}
> 		if (debug)
> 			z.reportln( "	RXTXPort:calling gc()");
> 		monThread = null;
> 		SPEventListener = null;
> 		MonitorThreadLock = false;
> 		MonitorThreadAlive=false;
> 		monThreadisInterrupted=true;
> 		z.reportln( "RXTXPort:removeEventListener() returning");
> 	}
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Sunday, June 25, 2006 7:56 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] Pending release
>
>
> With frustration, I was unable to get to the pending release this
> weekend.
> The release should be comming this next week once things calm down.
> The source is in CVS except for a fix for multiple ports in windows.
>
> I had planned on doing the release this weekend but that was disrupted
> by my transportation failing in a spectacular fashion.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From Pawan.Kharbanda at dot.state.co.us  Wed Jun 28 12:11:06 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Wed, 28 Jun 2006 12:11:06 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>

Trent,
    Again thanks for the reply. First of all I have Receive timeouts set
on all communications including Max no of bytes to expect during the
call. I have noticed the problem is during "closing the connection". I
am not sure if the RXTX is 100% thread-safe yet. There seems to be a
glitch in the native calls. I am sure I have the latest code I did the
update on the Version 2.1.7 from CVS, is this where the latest updates
are located, I have noticed another version in CVS "rxtx-devel".

Regards
Pawan Kharbanda

    

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Wednesday, June 28, 2006 4:17 AM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports



Hi Pawan

You may have found a deadlock but I've not seen on recently on linux.

If you can, please update from CVS.  This will have some close fixes. 
I'm running with the same code as is in CVS.  It is not perfect but I've
not seen anything like you mention.  Be sure to set timeouts and
thresholds on the port.  It may be that the port is waiting on pending
io that never happens.  I think the CVS patches deal with this also but
it looks like your in a better test environment to know for sure.

The exploded vehicle mentioned below is expected to be fixed today.  It
was just a ninja small radiator hose.  The pressure test afterwards
created its own set of problems.  Until this is resolved, I'm spending
most of my free time commuting by bicycle.

On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>   I have an application running in a cluster in linux environment and 
> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and 
> closes serial comm ports every 30 seconds and exchanges datas. I have 
> experienced some of my Comm Ports are left hanging (I can see the 
> LCK..cufXX lock files under /var/lock folder). On putting the debugs I

> found out that, it is stuck at a native call line 809 in RXTXPort.java

> class (Please see the code snippet below). Can you help me explain 
> what this method does in the native code? Am I getting into some 
> thread deadlocks? Thanks in advance.
>
> Pawan Kharbanda
>
>
> public void removeEventListener()
> 	{
> 		if (debug)
> 			z.reportln( "RXTXPort:removeEventListener()
called");
> 		waitForTheNativeCodeSilly();
> 		//if( monThread != null && monThread.isAlive() )
> 		if( monThreadisInterrupted == true )
> 		{
> 			z.reportln( "	RXTXPort:removeEventListener()
> already interrupted");
> 			monThread = null;
> 			SPEventListener = null;
> 			return;
> 		}
> 		else if( monThread != null && monThread.isAlive() )
> 		{
> 			if (debug)
> 				z.reportln( "
> RXTXPort:Interrupt=true");
> 			monThreadisInterrupted=true;
> 			/*
> 			   Notify all threads in this PID that something
is up
> 			   They will call back to see if its their
thread
> 			   using isInterrupted().
> 			*/
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> interruptEventLoop");
> // LINE 809			interruptEventLoop( ); It never returns
> out of this
>
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> monThread.join()");
> 			try {
> 				monThread.join(1000);
> 			} catch (Exception ex) {
> 				/* yikes */
> 				ex.printStackTrace();
> 			}
> 			if (debug)
> 				z.reportln( "	RXTXPort:waiting on
> isAlive()");
> 			while( monThread.isAlive() )
> 			{
> 				if ( debug )
> 					z.reportln( "	MonThread is
> still alive!");
> 				try {
> 					monThread.join(1000);
> 					Thread.sleep( 1000 );
> 				} catch( Exception e ){}
> 				//monThread.stop();
> 			}
>
> 		}
> 		if (debug)
> 			z.reportln( "	RXTXPort:calling gc()");
> 		monThread = null;
> 		SPEventListener = null;
> 		MonitorThreadLock = false;
> 		MonitorThreadAlive=false;
> 		monThreadisInterrupted=true;
> 		z.reportln( "RXTXPort:removeEventListener() returning");
> 	}
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf

> Of Trent Jarvi
> Sent: Sunday, June 25, 2006 7:56 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] Pending release
>
>
> With frustration, I was unable to get to the pending release this 
> weekend.
> The release should be comming this next week once things calm down.
> The source is in CVS except for a fix for multiple ports in windows.
>
> I had planned on doing the release this weekend but that was disrupted

> by my transportation failing in a spectacular fashion.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Wed Jun 28 12:26:21 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 28 Jun 2006 12:26:21 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606281222420.9561@www>


Hi Pawan

If you did a cvs update from the 2.1-7 tar ball, you have the current 
version.  All rxtx in CVS is under rxtx-devel.  The 2.1-7 just has -r
commapi-0-0-1.

You may well have found something.  I have seen win32 fail on closing 
ports but not linux that I can think of.  Your use is much different than 
I normally see too.

Could you give us more information on how we would reproduce this and the 
frequency?


On Wed, 28 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>    Again thanks for the reply. First of all I have Receive timeouts set
> on all communications including Max no of bytes to expect during the
> call. I have noticed the problem is during "closing the connection". I
> am not sure if the RXTX is 100% thread-safe yet. There seems to be a
> glitch in the native calls. I am sure I have the latest code I did the
> update on the Version 2.1.7 from CVS, is this where the latest updates
> are located, I have noticed another version in CVS "rxtx-devel".
>
> Regards
> Pawan Kharbanda
>
>
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Wednesday, June 28, 2006 4:17 AM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] Locked Ports
>
>
>
> Hi Pawan
>
> You may have found a deadlock but I've not seen on recently on linux.
>
> If you can, please update from CVS.  This will have some close fixes.
> I'm running with the same code as is in CVS.  It is not perfect but I've
> not seen anything like you mention.  Be sure to set timeouts and
> thresholds on the port.  It may be that the port is waiting on pending
> io that never happens.  I think the CVS patches deal with this also but
> it looks like your in a better test environment to know for sure.
>
> The exploded vehicle mentioned below is expected to be fixed today.  It
> was just a ninja small radiator hose.  The pressure test afterwards
> created its own set of problems.  Until this is resolved, I'm spending
> most of my free time commuting by bicycle.
>
> On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:
>
>> Trent,
>>   I have an application running in a cluster in linux environment and
>> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and
>> closes serial comm ports every 30 seconds and exchanges datas. I have
>> experienced some of my Comm Ports are left hanging (I can see the
>> LCK..cufXX lock files under /var/lock folder). On putting the debugs I
>
>> found out that, it is stuck at a native call line 809 in RXTXPort.java
>
>> class (Please see the code snippet below). Can you help me explain
>> what this method does in the native code? Am I getting into some
>> thread deadlocks? Thanks in advance.
>>
>> Pawan Kharbanda
>>
>>
>> public void removeEventListener()
>> 	{
>> 		if (debug)
>> 			z.reportln( "RXTXPort:removeEventListener()
> called");
>> 		waitForTheNativeCodeSilly();
>> 		//if( monThread != null && monThread.isAlive() )
>> 		if( monThreadisInterrupted == true )
>> 		{
>> 			z.reportln( "	RXTXPort:removeEventListener()
>> already interrupted");
>> 			monThread = null;
>> 			SPEventListener = null;
>> 			return;
>> 		}
>> 		else if( monThread != null && monThread.isAlive() )
>> 		{
>> 			if (debug)
>> 				z.reportln( "
>> RXTXPort:Interrupt=true");
>> 			monThreadisInterrupted=true;
>> 			/*
>> 			   Notify all threads in this PID that something
> is up
>> 			   They will call back to see if its their
> thread
>> 			   using isInterrupted().
>> 			*/
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> interruptEventLoop");
>> // LINE 809			interruptEventLoop( ); It never returns
>> out of this
>>
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> monThread.join()");
>> 			try {
>> 				monThread.join(1000);
>> 			} catch (Exception ex) {
>> 				/* yikes */
>> 				ex.printStackTrace();
>> 			}
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:waiting on
>> isAlive()");
>> 			while( monThread.isAlive() )
>> 			{
>> 				if ( debug )
>> 					z.reportln( "	MonThread is
>> still alive!");
>> 				try {
>> 					monThread.join(1000);
>> 					Thread.sleep( 1000 );
>> 				} catch( Exception e ){}
>> 				//monThread.stop();
>> 			}
>>
>> 		}
>> 		if (debug)
>> 			z.reportln( "	RXTXPort:calling gc()");
>> 		monThread = null;
>> 		SPEventListener = null;
>> 		MonitorThreadLock = false;
>> 		MonitorThreadAlive=false;
>> 		monThreadisInterrupted=true;
>> 		z.reportln( "RXTXPort:removeEventListener() returning");
>> 	}
>>
>> -----Original Message-----
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
>
>> Of Trent Jarvi
>> Sent: Sunday, June 25, 2006 7:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] Pending release
>>
>>
>> With frustration, I was unable to get to the pending release this
>> weekend.
>> The release should be comming this next week once things calm down.
>> The source is in CVS except for a fix for multiple ports in windows.
>>
>> I had planned on doing the release this weekend but that was disrupted
>
>> by my transportation failing in a spectacular fashion.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From Pawan.Kharbanda at dot.state.co.us  Wed Jun 28 15:42:49 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Wed, 28 Jun 2006 15:42:49 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>

Trent,
    I will try to explain how I am setup and will try to write you a
Sample code little later to reproduce this. On our system we have
DigiBoxes installed on the 2 Linux servers. Both of them have RXTX2.1-7
version installed with the JRE(1.5) and both the machines have the same
port mappings in gnu.io.rxtx.properties (Currently in the production
system I have 64 ports). This is how the system works:

1) A thick Map based client initiates a Action on the Device on the
field. One of the Thread Workers(Asynchronous Call) in the Cluster picks
up the request. 
2) Once the worker gets the request it locks the Device and
Communication port in the DB's(These are our persistent locks, because
most of the devices do one to one communication with the serial ports).
After that the worker (or Comm Server) opens up the connection and after
exchanging the information calls the "Close" and returns.
3) Once the connection is closed , the DB lock is removed on the comm
port and is made available to accept future calls. Here is where the
glitch is the Serial Comm Close method never returns due to the
deadlock. 

I have noticed that the deadlocks are very inconsistent, sometime it
happens right away as soon as Application server starts and sometimes I
don't see any deadlocks for days, but it happens for sure. 

Here is how you can test if you have resources/ test environment. Write
a program and try to open/close  different ports(I will say have a
minimum of four) randomly and very frequently(may be 30 seconds), I am
pretty sure you will see the deadlocks and it happens in the native call
to interrptEventLoop in RXTXPort.java in removeEventListener() method
call.

Also I have noticed that the JVM carshes (without any memrory errors or
JVM errors. Its just not there) when native call is made to eventLoop()
in run() method in MonitorThread inner class. I am still investigating
why this is happening, but at this point I can just tell you the
location. You might have a question How I am so sure about the location?
My application is configured with Log4J and I have enabled the debugs on
the RXTXPort.java, so every time my JVM dies I see these logs at the end
of the file.

"2006-06-28 15:27:15,183 INFO  [STDOUT] RXTXPort:RXTXPort(/dev/cub01)
called
2006-06-28 15:27:15,218 INFO  [STDOUT]
RXTXPort:MontitorThread:MonitorThread()
2006-06-28 15:27:15,219 INFO  [STDOUT] RXTXPort:MontitorThread:run()"

I surely do have a luxury of a testing environment(ports, devices etc.)
and can help you fix these problems? Please advise me how we can resolve
these issues.

Thanks 
Pawan Kharbanda
303-478-2991





-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Wednesday, June 28, 2006 12:26 PM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports


Hi Pawan

If you did a cvs update from the 2.1-7 tar ball, you have the current
version.  All rxtx in CVS is under rxtx-devel.  The 2.1-7 just has -r
commapi-0-0-1.

You may well have found something.  I have seen win32 fail on closing
ports but not linux that I can think of.  Your use is much different
than I normally see too.

Could you give us more information on how we would reproduce this and
the frequency?


On Wed, 28 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>    Again thanks for the reply. First of all I have Receive timeouts
set
> on all communications including Max no of bytes to expect during the
> call. I have noticed the problem is during "closing the connection". I
> am not sure if the RXTX is 100% thread-safe yet. There seems to be a
> glitch in the native calls. I am sure I have the latest code I did the
> update on the Version 2.1.7 from CVS, is this where the latest updates
> are located, I have noticed another version in CVS "rxtx-devel".
>
> Regards
> Pawan Kharbanda
>
>
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Wednesday, June 28, 2006 4:17 AM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] Locked Ports
>
>
>
> Hi Pawan
>
> You may have found a deadlock but I've not seen on recently on linux.
>
> If you can, please update from CVS.  This will have some close fixes.
> I'm running with the same code as is in CVS.  It is not perfect but
I've
> not seen anything like you mention.  Be sure to set timeouts and
> thresholds on the port.  It may be that the port is waiting on pending
> io that never happens.  I think the CVS patches deal with this also
but
> it looks like your in a better test environment to know for sure.
>
> The exploded vehicle mentioned below is expected to be fixed today.
It
> was just a ninja small radiator hose.  The pressure test afterwards
> created its own set of problems.  Until this is resolved, I'm spending
> most of my free time commuting by bicycle.
>
> On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:
>
>> Trent,
>>   I have an application running in a cluster in linux environment and
>> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and
>> closes serial comm ports every 30 seconds and exchanges datas. I have
>> experienced some of my Comm Ports are left hanging (I can see the
>> LCK..cufXX lock files under /var/lock folder). On putting the debugs
I
>
>> found out that, it is stuck at a native call line 809 in
RXTXPort.java
>
>> class (Please see the code snippet below). Can you help me explain
>> what this method does in the native code? Am I getting into some
>> thread deadlocks? Thanks in advance.
>>
>> Pawan Kharbanda
>>
>>
>> public void removeEventListener()
>> 	{
>> 		if (debug)
>> 			z.reportln( "RXTXPort:removeEventListener()
> called");
>> 		waitForTheNativeCodeSilly();
>> 		//if( monThread != null && monThread.isAlive() )
>> 		if( monThreadisInterrupted == true )
>> 		{
>> 			z.reportln( "	RXTXPort:removeEventListener()
>> already interrupted");
>> 			monThread = null;
>> 			SPEventListener = null;
>> 			return;
>> 		}
>> 		else if( monThread != null && monThread.isAlive() )
>> 		{
>> 			if (debug)
>> 				z.reportln( "
>> RXTXPort:Interrupt=true");
>> 			monThreadisInterrupted=true;
>> 			/*
>> 			   Notify all threads in this PID that something
> is up
>> 			   They will call back to see if its their
> thread
>> 			   using isInterrupted().
>> 			*/
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> interruptEventLoop");
>> // LINE 809			interruptEventLoop( ); It never returns
>> out of this
>>
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> monThread.join()");
>> 			try {
>> 				monThread.join(1000);
>> 			} catch (Exception ex) {
>> 				/* yikes */
>> 				ex.printStackTrace();
>> 			}
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:waiting on
>> isAlive()");
>> 			while( monThread.isAlive() )
>> 			{
>> 				if ( debug )
>> 					z.reportln( "	MonThread is
>> still alive!");
>> 				try {
>> 					monThread.join(1000);
>> 					Thread.sleep( 1000 );
>> 				} catch( Exception e ){}
>> 				//monThread.stop();
>> 			}
>>
>> 		}
>> 		if (debug)
>> 			z.reportln( "	RXTXPort:calling gc()");
>> 		monThread = null;
>> 		SPEventListener = null;
>> 		MonitorThreadLock = false;
>> 		MonitorThreadAlive=false;
>> 		monThreadisInterrupted=true;
>> 		z.reportln( "RXTXPort:removeEventListener() returning");
>> 	}
>>
>> -----Original Message-----
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On
Behalf
>
>> Of Trent Jarvi
>> Sent: Sunday, June 25, 2006 7:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] Pending release
>>
>>
>> With frustration, I was unable to get to the pending release this
>> weekend.
>> The release should be comming this next week once things calm down.
>> The source is in CVS except for a fix for multiple ports in windows.
>>
>> I had planned on doing the release this weekend but that was
disrupted
>
>> by my transportation failing in a spectacular fashion.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx 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 khattar31 at yahoo.com  Wed Jun 28 22:04:59 2006
From: khattar31 at yahoo.com (rahul khattar)
Date: Wed, 28 Jun 2006 21:04:59 -0700 (PDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
Message-ID: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>

Hi All,

I was looking at the src file on the last release.
I did notice a missing header file while trying to
compile the parallelport.dll. Would somebody be kind
enoughf to share the missing header file:
gnu_io_LPRPort.h

I am using MinGw to compile the same from Parinya
(which is an execellent tool)


Regards,
Rahul Khattar

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Thu Jun 29 03:43:53 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 03:43:53 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>
References: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606290341210.9561@www>

On Wed, 28 Jun 2006, rahul khattar wrote:

> Hi All,
>
> I was looking at the src file on the last release.
> I did notice a missing header file while trying to
> compile the parallelport.dll. Would somebody be kind
> enoughf to share the missing header file:
> gnu_io_LPRPort.h
>
> I am using MinGw to compile the same from Parinya
> (which is an execellent tool)
>

Hi Rahul

The gnu.io_LPRPort.h file is generated with javah.  You can see the 
command in the Makefile I presume.  You do not need rxtxParallel.dll to 
use w32 serial btw.

--
Trent Jarvi
tjarvi at qbang.org


From khattar31 at yahoo.com  Thu Jun 29 04:47:01 2006
From: khattar31 at yahoo.com (rahul khattar)
Date: Thu, 29 Jun 2006 03:47:01 -0700 (PDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606290341210.9561@www>
Message-ID: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>

Hi Trent 
I did notice this file is required in the source file
ParallelImp.c
on line 38

Attached the O/P 

Regards,
Rahul Khattar




--- Trent Jarvi <tjarvi at qbang.org> wrote:

> On Wed, 28 Jun 2006, rahul khattar wrote:
> 
> > Hi All,
> >
> > I was looking at the src file on the last release.
> > I did notice a missing header file while trying to
> > compile the parallelport.dll. Would somebody be
> kind
> > enoughf to share the missing header file:
> > gnu_io_LPRPort.h
> >
> > I am using MinGw to compile the same from Parinya
> > (which is an execellent tool)
> >
> 
> Hi Rahul
> 
> The gnu.io_LPRPort.h file is generated with javah. 
> You can see the 
> command in the Makefile I presume.  You do not need
> rxtxParallel.dll to 
> use w32 serial btw.
> 
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Error.zip
Type: application/x-zip-compressed
Size: 1746 bytes
Desc: 2948039066-Error.zip
Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060629/a5b6f783/Error-0015.bin

From tjarvi at qbang.org  Thu Jun 29 06:16:24 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 06:16:24 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606290614530.9561@www>

On Thu, 29 Jun 2006, rahul khattar wrote:

> Hi Trent
> I did notice this file is required in the source file
> ParallelImp.c
> on line 38
>
> Attached the O/P
>

The command to generate the .h file will be something like:

javah -classpath . -jni gnu.io.LPRPort

The makefile should have this.  There are several approaches to creating 
or using makefiles so I have no idea which one you used if any.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Thu Jun 29 06:20:51 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 06:20:51 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606290616420.9561@www>

> Here is how you can test if you have resources/ test environment. Write
> a program and try to open/close  different ports(I will say have a
> minimum of four) randomly and very frequently(may be 30 seconds), I am
> pretty sure you will see the deadlocks and it happens in the native call
> to interrptEventLoop in RXTXPort.java in removeEventListener() method
> call.

Hi Pawan

I'll try to find a way to reproduce this.  One thing to note is that you 
are using different kernel drivers (digi) to perform this task.  So I 
probably will not be able to reproduce the exact same environment.

In general, multiport kernel drivers have been tested far less than 
typical serial drivers.  This may or may not be an issue.

--
Trent Jarvi
tjarvi at qbang.org



From jhaysonn at gmail.com  Thu Jun 29 12:29:13 2006
From: jhaysonn at gmail.com (jhaysonn pathak)
Date: Thu, 29 Jun 2006 14:29:13 -0400
Subject: [Rxtx] RXTX install
Message-ID: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>

Hi Guys,

I'm doing trying to write a generative piece of Sonic Art using an EEG
plugged into a mac runnning Max/MSP.  I just recently discovered RXTX
drivers in my search for a piece of software that might give me more
output options for my EEG (I'm using the CEO from MindPeak).  I found
Bioera which uses RXTX drivers.  Thing is - I can't figure out how to
install RXTX correctly.

After I build the 'libSerial.jnilib' target inside of
'LibSerial.pbproj' I can't find the libSerial.jnilib file that
accompanies the RXTXcomm.jar nor do I know where to put them.

I also don't understand this part at the bottom of the OS X instructions at all:

"AFTER INSTALLATION VERY IMPORTANT
	check existence of the folder /var/spool/uucp
	if you don't have it create it with command
	sudo mkdir /var/spool/uucp
	permissions should be: drwxrwxr-x
	if they are not do command
	sudo chmod 775 /var/spool/uucp

	YOU should be a member of the uucp group
	you can check it with command
		niutil -readprop / /groups/uucp users
	you should see your name in output of the niutil command
	if you don't do following:
		sudo niutil -appendprop / /groups/uucp users <yourname>
			substitute  <yourname> with your user's name
			for example if your user name is peter:
				sudo niutil -appendprop / /groups/uucp users peter

	NOTES: RXTX.pkg should create uucp folder and insert your name  in
uucp group automatically"



I really appreciate any help that you guys can offer.  I've been
struggling with this for a while now as part of a research grant that
I was awarded.  Thanks again for the help.

Jhaysonn Pathak


From naranjo.manuel at gmail.com  Thu Jun 29 07:19:15 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 10:19:15 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606290614530.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www>
Message-ID: <44A3D353.6010605@gmail.com>

Speaking about Windows Support, I had seen that inside the 
rxtx-2.1-7-bins-r2 package inside Windows directory it says:
"i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will 
not make harm to anyone, and i'm almost sure that someone has noticed it 
before.
Cheers,
Manuel


From joachim at buechse.de  Thu Jun 29 13:25:16 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 29 Jun 2006 21:25:16 +0200
Subject: [Rxtx] RXTX install
In-Reply-To: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>
References: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>
Message-ID: <2A003E42-97E1-4237-8438-646BDE2E3961@buechse.de>

Hello Jhaysonn,

I assume you are trying to use the javax.comm version of RXTX.

Please use "cvs up" to update your download to the latest version of  
the repository. The latest version does not use lock files, so the  
mentioned process is no longer needed. Updating with CVS will also  
provide you with a new README.OSX file that should be simpler to  
understand.

You will find LibSerialUniversal.xcodeproj in MACOSX_IDE/Xcode. Put  
comm.jar (downloaded from Sun) into MACOSX_IDE/Xcode. Compile the  
library. You will find RXTXcomm.jar and librxtxSerial.jnilib in  
MACOSX_IDE/Xcode/build/Default

Best regards,
Joachim
---
Joachim B?chse
Softwarel?sungen und Beratung
Hadlaubsteig 2
CH-8006 Z?rich


On 29.06.2006, at 20:29, jhaysonn pathak wrote:

> Hi Guys,
>
> I'm doing trying to write a generative piece of Sonic Art using an EEG
> plugged into a mac runnning Max/MSP.  I just recently discovered RXTX
> drivers in my search for a piece of software that might give me more
> output options for my EEG (I'm using the CEO from MindPeak).  I found
> Bioera which uses RXTX drivers.  Thing is - I can't figure out how to
> install RXTX correctly.
>
> After I build the 'libSerial.jnilib' target inside of
> 'LibSerial.pbproj' I can't find the libSerial.jnilib file that
> accompanies the RXTXcomm.jar nor do I know where to put them.
>
> I also don't understand this part at the bottom of the OS X  
> instructions at all:
>
> "AFTER INSTALLATION VERY IMPORTANT
> 	check existence of the folder /var/spool/uucp
> 	if you don't have it create it with command
> 	sudo mkdir /var/spool/uucp
> 	permissions should be: drwxrwxr-x
> 	if they are not do command
> 	sudo chmod 775 /var/spool/uucp
>
> 	YOU should be a member of the uucp group
> 	you can check it with command
> 		niutil -readprop / /groups/uucp users
> 	you should see your name in output of the niutil command
> 	if you don't do following:
> 		sudo niutil -appendprop / /groups/uucp users <yourname>
> 			substitute  <yourname> with your user's name
> 			for example if your user name is peter:
> 				sudo niutil -appendprop / /groups/uucp users peter
>
> 	NOTES: RXTX.pkg should create uucp folder and insert your name  in
> uucp group automatically"
>
>
>
> I really appreciate any help that you guys can offer.  I've been
> struggling with this for a while now as part of a research grant that
> I was awarded.  Thanks again for the help.
>
> Jhaysonn Pathak
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From tjarvi at qbang.org  Thu Jun 29 19:30:00 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 19:30:00 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A3D353.6010605@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
Message-ID: <Pine.LNX.4.61.0606291923000.9561@www>

On Thu, 29 Jun 2006, Manuel Naranjo wrote:

> Speaking about Windows Support, I had seen that inside the
> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
> not make harm to anyone, and i'm almost sure that someone has noticed it
> before.

Hi Manuel

         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
     47421  01-30-06 00:23 
rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
     77759  03-01-06 12:01 
rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README


It looks normal to me.  There are no fancy tools used there :)

--
Trent Jarvi
tjarvi at qbang.org

From naranjo.manuel at gmail.com  Thu Jun 29 19:38:16 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 22:38:16 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606291923000.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com> <Pine.LNX.4.61.0606291923000.9561@www>
Message-ID: <44A48088.2040407@gmail.com>

> On Thu, 29 Jun 2006, Manuel Naranjo wrote:
> 
>> Speaking about Windows Support, I had seen that inside the
>> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
>> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
>> not make harm to anyone, and i'm almost sure that someone has noticed it
>> before.
> 
> Hi Manuel
> 
>         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
>         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
>     47421  01-30-06 00:23 
> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
>     77759  03-01-06 12:01 
> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
>       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README
> 
> 
> It looks normal to me.  There are no fancy tools used there :)
> 
Hi Trent:
Is not the i368 representing the name of the Architecture?? If so the 
name should start with i386 it will not break any system, is simply miss
written, I saw that and wanted to report it. It a silly thing.
Ohh I forgoten I must congratulate you for your GREAT libray, I was able 
to make an .exe with JSmooth that launches an application that uses RXTX 
with out the need to install RXTX on users system :). The .exe tells JVM 
where to find the RXTX Library and Binaries. I tried with Sun's Java 
Comm but it was imposible.
Regards,
Manuel


From tjarvi at qbang.org  Thu Jun 29 19:52:45 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 19:52:45 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A48088.2040407@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
	<Pine.LNX.4.61.0606291923000.9561@www> <44A48088.2040407@gmail.com>
Message-ID: <Pine.LNX.4.61.0606291945060.9561@www>

On Thu, 29 Jun 2006, Manuel Naranjo wrote:

>> On Thu, 29 Jun 2006, Manuel Naranjo wrote:
>>
>>> Speaking about Windows Support, I had seen that inside the
>>> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
>>> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
>>> not make harm to anyone, and i'm almost sure that someone has noticed it
>>> before.
>>
>> Hi Manuel
>>
>>         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
>>         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
>>     47421  01-30-06 00:23
>> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
>>     77759  03-01-06 12:01
>> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
>>       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README
>>
>>
>> It looks normal to me.  There are no fancy tools used there :)
>>
> Hi Trent:
> Is not the i368 representing the name of the Architecture?? If so the
> name should start with i386 it will not break any system, is simply miss
> written, I saw that and wanted to report it. It a silly thing.
> Ohh I forgoten I must congratulate you for your GREAT libray, I was able
> to make an .exe with JSmooth that launches an application that uses RXTX
> with out the need to install RXTX on users system :). The .exe tells JVM
> where to find the RXTX Library and Binaries. I tried with Sun's Java
> Comm but it was imposible.

Hi Manuel

The compiler uses only the i386 instruction set for windows.  I doubt 
there will be any measurable advantages with going to later instruction 
sets.  In theory rxtx would run on a 386 but I doubt anyone does that.

So it looks odd but is not a typo.

We could compile to i686 but don't.  The compiler used does not appear to 
be a problem yet so I don't see any point in changing it.  Right now, we 
could not compile 64 bit windows binaries.  gcc/mingw/... do not support 
them that I know of.  People will have to compile those with closed source 
tools on their own until an option is available.

--
Trent Jarvi
tjarvi at qbang.org

From naranjo.manuel at gmail.com  Thu Jun 29 20:00:48 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 23:00:48 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606291945060.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com>	<Pine.LNX.4.61.0606291923000.9561@www>
	<44A48088.2040407@gmail.com> <Pine.LNX.4.61.0606291945060.9561@www>
Message-ID: <44A485D0.7050202@gmail.com>

Trent you did not get my point
The folder says 368 three hundred sixty eight, when
it should say 386 three hundred eighty six. Is simply a miss writting.
Regards,
Manuel


From tjarvi at qbang.org  Thu Jun 29 20:12:15 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 20:12:15 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A485D0.7050202@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
	<Pine.LNX.4.61.0606291923000.9561@www> <44A48088.2040407@gmail.com>
	<Pine.LNX.4.61.0606291945060.9561@www> <44A485D0.7050202@gmail.com>
Message-ID: <Pine.LNX.4.61.0606292008061.9561@www>


On Thu, 29 Jun 2006, Manuel Naranjo wrote:

> Trent you did not get my point
> The folder says 368 three hundred sixty eight, when
> it should say 386 three hundred eighty six. Is simply a miss writting.

hehe..  OK.  My bad.  It's been a long day.

Nevermind :)

--
Trent Jarvi
tjarvi at qbang.org




From naranjo.manuel at gmail.com  Thu Jun 29 20:18:44 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 23:18:44 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606292008061.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com>	<Pine.LNX.4.61.0606291923000.9561@www>
	<44A48088.2040407@gmail.com>	<Pine.LNX.4.61.0606291945060.9561@www>
	<44A485D0.7050202@gmail.com> <Pine.LNX.4.61.0606292008061.9561@www>
Message-ID: <44A48A04.9040401@gmail.com>

Don't worry Trent.
About 64 bits compilation, I would like to colaborate, I have a Pc with 
64 bits, the only problem is that i do not have windows 64 bits 
installed :(.




From Pawan.Kharbanda at dot.state.co.us  Fri Jun 30 08:49:52 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 30 Jun 2006 08:49:52 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E996@hqexchange3.dot.state.co.us>

Trent,  
    Can you explain what the interruptedEventLoop() native method is
doing is there a possibility that method is somehow getting into the
infinite loop(there are 2 while loops without any break statements).
This might be a very basic question how can I debug the native code(or
print the debug statements).  Again thanks for the help. 

Pawan Kharbanda

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Thursday, June 29, 2006 6:21 AM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports

> Here is how you can test if you have resources/ test environment. 
> Write a program and try to open/close  different ports(I will say have

> a minimum of four) randomly and very frequently(may be 30 seconds), I 
> am pretty sure you will see the deadlocks and it happens in the native

> call to interrptEventLoop in RXTXPort.java in removeEventListener() 
> method call.

Hi Pawan

I'll try to find a way to reproduce this.  One thing to note is that you
are using different kernel drivers (digi) to perform this task.  So I
probably will not be able to reproduce the exact same environment.

In general, multiport kernel drivers have been tested far less than
typical serial drivers.  This may or may not be an issue.

--
Trent Jarvi
tjarvi at qbang.org

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From cpine at wrsystems.com  Thu Jun 29 15:17:12 2006
From: cpine at wrsystems.com (Chris Pine)
Date: Thu, 29 Jun 2006 17:17:12 -0400
Subject: [Rxtx]  Controlling Individual Signals DTR and RTS
Message-ID: <MAIL4FJo0S8ACLEBajJ000005cf@mail4.wrsystems.com>

Dear Moussa Ba,
	I hope I am not being too forward, but we are having the exact same
issue with needing to control DTR from RXTX in Linux.  Did you ever have any
luck figuring it out?

Thank you very much for your time,

Chris Pine




From tjarvi at qbang.org  Thu Jun  1 11:13:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 11:13:40 -0600 (MDT)
Subject: [Rxtx] custom baud rate win32
In-Reply-To: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606011107210.30220@www>


Hi Daren

I can't imagine that 1953 is possibly the actual value on the UART.  Maybe 
if your baud base is very high with a custom serial board.  More likely, 
the driver just remembers that what you asked for and did something else.

I'll have more to say on the dcb->BaudRate after I try some things here. 
I have managed to do something like that in the past as a quick hack but 
it was for 14400.  I may have used the CBR_14400.

If we can't access this through the win32 API with protected mode, there 
is another layer of complication.  With real mode, it would be easy.
With protected mode, I assume there would have to be some kernel driver or 
a hook I'm not aware of to access the MCR directly (bang a memory 
addresss).



On Thu, 1 Jun 2006, Daren wrote:

> Trent,
> I have managed to successfully open the port at this speed using Realterm
> (available on sourceforge). From memory this uses DLPortIO.
>
> Using portmon.exe with realterm, even there it says that the port has opened
> at 1953.
>
> I changed termios.c:560 to
> dcb->BaudRate        = 1953 ;
>
> and it still opens the port at 9600.
>
> Daren
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Trent Jarvi
> Sent: Thursday, 1 June 2006 1:44 PM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] custom baud rate win32
>
> On Thu, 1 Jun 2006, Daren wrote:
>
>> Hi all,
>>
>> I downloaded 2.1.7-pre16 and managed to build it and get it going. I made
>> the changes as suggested by Peter Smith in an old post, by adding his code
>> to SerialImpl.c, uncommenting the TIOCGSERIAL and TIOCSSERIAL, and
> defining
>> ASYNC_SPD_CUST which is equal to 0x0030 (according to linus header
> files)..
>>
>>
>> Still not working, it opens the port at 9600 according to portmon.exe .
> Has
>> anyone managed to get this going at a custom rate?
>>
>> Here is the post I'm referring to:
>> http://marc.theaimsgroup.com/?l=rxtx&m=106270038110713&w=2
>>
>>
>> Thanks,
>> Daren
>>
>> ________________________________________
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
>> Daren
>> Sent: Wednesday, 31 May 2006 10:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] (no subject)
>>
>> Hi All,
>> I have been using rxtx for a little while and needed to get it working at
>> 1953, like a past user in the mailing list, who seemed to have got it
>> working by changing some C code.
>>
>> I wanted to build rxtx myself with these changes but don't know where to
>> start. I have windows here and FC4 at home. I downloaded cygwin and
> mingw32,
>> each build works by building a rxtxSerial.dll file that is ~11k smaller
> than
>> the original, and I always get the following error when testing the dll:
>>
>> Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at
>> PC=0x8077655
>> Function=[Unknown.]
>> Library=C:\opt\java\j2sdk1.4.2\jre\bin\client\jvm.dll
>>
>> NOTE: We are unable to locate the function name symbol for the error
>>      just occurred. Please refer to release documentation for possible
>>      reason and solutions.
>>
>>
>> Current Java thread:
>> 	at gnu.io.RXTXPort.open(Native Method)
>> 	- locked <0x1002c800> (a gnu.io.RXTXPort)
>> 	at gnu.io.RXTXPort.<init>(RXTXPort.java:84)
>>
>> Anyone know what im doing wrong?
>>
>>
>>
>>
>
> Hi Daren
>
> You are running into the same rats nest I'm looking at now.
>
> With win32 and specific custom baud rates, I'm not sure how this will go.
> I've got the Linux custom baud rates working very nicely.  I did much like
> the post you linked.  In fact I had forgot about that post.  You probably
> noticed that it becomes a bunch of dirt roads going noplace fast in
> termios.c for w32.
>
> I'm probably only going to get 14400, 28800, 128000 and 256000 working
> with the next release on w32.  I'll look a little further.  If you have an
> example w32 that works at 1953 I'd really like to hear.  Thats an unusual
> baud rate.
>
> Assuming a baud_base of 128000, your divisor will be 65 or 66.
>
> 128000/66=1939 -14
> 128000/65=1969 +13
>
> One thing I've been wondering about with linux is which would be the right
> answer in cases like this.  Right now it would just go with a baud base of
> 65 and ignore the modulus details.
>
> It appears to be a general trend for kernel developers to hide these
> details thinking that they can come up with a general solution.  Then they
> run out of time.  Perahps the solution is to help out but there are
> ultiple OS's rxtx supports making that nontrivial.
>
> If you look at current linux kernels, the 'tricks' above have been marked
> deprecated with no replacement.  Windows has some hard defines and then
> ancient near magic.  I've not looked at Solaris via Open Solaris yet but
> doubt there is a solution at all.
>
> What I'd try since you have the equipment and the monitor software is to
> hardcode the dcb->Baud in termios.c to 1953 (no define) and see what the
> w32 kernel does with it.  I think if you toss a baud rate at the driver it
> will try to come close.  You may try comming closer to a real baudrate
> based upon the 128000 baud base as shown above.
>
> If it works, it is worth looking at the rest of the ping/pong logic then.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
>
>
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From doug at dupreeinc.com  Thu Jun  1 13:22:13 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 12:22:13 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011107210.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
Message-ID: <447F3E65.1020809@dupreeinc.com>

Hello,

I am still trying to get this startup a little faster so I turned on the 
debug of a few of the classes.  The COM ports are scanned really fast 
and the delay occurs during the LPT scan.  The console output looks like 
this:

    ...
      LPT1
      LPT2
      LPT3
     valid port prefixes:
      LPT
    LPT1 LPT
    1 1
    LPT2 LPT
    2 2                                                                 
      * <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
    CommPortIdentifier:addPortName(LPT2)
    CommPortIdentifier:AddIdentifierToList()
    LPT3 LPT
    3 3
    CommPortIdentifier:addPortName(LPT3)
    CommPortIdentifier:AddIdentifierToList()
    CommPortIdentifier:AddIdentifierToList() index.next
    Leaving registerValidPorts()
    Have not implemented native_psmisc_report_owner(PortName)); in
    CommPortIdentifier
    CommPortIdentifier:getPortIdentifier(COM3)
    CommPortIdentifier:open(densConnect, 30000)
    RXTXCommDriver:getCommPort(COM3,1)
    ...

It would seem to me that if I removed the code for port scanning of LPT 
ports I could solve this problem. I would much prefer to use unmodified 
code if at all possible.  Do any of you have alternate suggestions?

Thank you for your time.

Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/cf433ee7/attachment-0016.html

From tjarvi at qbang.org  Thu Jun  1 13:52:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 13:52:06 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F3E65.1020809@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011348380.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I am still trying to get this startup a little faster so I turned on the 
> debug of a few of the classes.  The COM ports are scanned really fast and the 
> delay occurs during the LPT scan.  The console output looks like this:
>
>   ...
>     LPT1
>     LPT2
>     LPT3
>    valid port prefixes:
>     LPT
>   LPT1 LPT
>   1 1
>   LPT2 LPT
>   2 2                                                                      * 
> <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>   CommPortIdentifier:addPortName(LPT2)
>   CommPortIdentifier:AddIdentifierToList()
>   LPT3 LPT
>   3 3
>   CommPortIdentifier:addPortName(LPT3)
>   CommPortIdentifier:AddIdentifierToList()
>   CommPortIdentifier:AddIdentifierToList() index.next
>   Leaving registerValidPorts()
>   Have not implemented native_psmisc_report_owner(PortName)); in
>   CommPortIdentifier
>   CommPortIdentifier:getPortIdentifier(COM3)
>   CommPortIdentifier:open(densConnect, 30000)
>   RXTXCommDriver:getCommPort(COM3,1)
>   ...
>
> It would seem to me that if I removed the code for port scanning of LPT ports 
> I could solve this problem. I would much prefer to use unmodified code if at 
> all possible.  Do any of you have alternate suggestions?
>
> Thank you for your time.
>
> Doug
>


Does commenting out the LPT enumeration actually help?  There can often be 
differences between debug information printed and whats really going on. 
When you combine various environments the debug info can even come out in 
the wrong order.

I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
I do not think this problem is universal.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Thu Jun  1 14:29:44 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:29:44 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4E38.2060004@dupreeinc.com>

I will give it a try.  One thing to note on this PC is it has no LPT 
Parallel ports.

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
>>Hello,
>>
>>I am still trying to get this startup a little faster so I turned on the 
>>debug of a few of the classes.  The COM ports are scanned really fast and the 
>>delay occurs during the LPT scan.  The console output looks like this:
>>
>>  ...
>>    LPT1
>>    LPT2
>>    LPT3
>>   valid port prefixes:
>>    LPT
>>  LPT1 LPT
>>  1 1
>>  LPT2 LPT
>>  2 2                                                                      * 
>><<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>>  CommPortIdentifier:addPortName(LPT2)
>>  CommPortIdentifier:AddIdentifierToList()
>>  LPT3 LPT
>>  3 3
>>  CommPortIdentifier:addPortName(LPT3)
>>  CommPortIdentifier:AddIdentifierToList()
>>  CommPortIdentifier:AddIdentifierToList() index.next
>>  Leaving registerValidPorts()
>>  Have not implemented native_psmisc_report_owner(PortName)); in
>>  CommPortIdentifier
>>  CommPortIdentifier:getPortIdentifier(COM3)
>>  CommPortIdentifier:open(densConnect, 30000)
>>  RXTXCommDriver:getCommPort(COM3,1)
>>  ...
>>
>>It would seem to me that if I removed the code for port scanning of LPT ports 
>>I could solve this problem. I would much prefer to use unmodified code if at 
>>all possible.  Do any of you have alternate suggestions?
>>
>>Thank you for your time.
>>
>>Doug
>>
>>    
>>
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/dd31fed5/attachment-0016.html

From doug at dupreeinc.com  Thu Jun  1 14:36:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:36:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4FC8.9080106@dupreeinc.com>

Trent,

I commented out the section in RegisterScannedPorts() that adds the 
three LPT ports to the CandidateDeviceNames string array.  The 
application started immediately.  This is probably not the way to do 
this, but it was quick ,dirty, and worked.

It would be nice if there was a way to pole the OS to see if there is 
even a port there, though I guess this is what this code is suppose to do...

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
> ...
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From lynn at swcp.com  Thu Jun  1 14:49:34 2006
From: lynn at swcp.com (lynn@swcp.com)
Date: Thu, 1 Jun 2006 20:49:34 -0000
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>,
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <twig.1149194974.97617@swcp.com>

Perhaps we could add an argument to port enumeration where if not specified,
you get the default behavior that looks for everything.  With a new
constructor that has an argument(or more) you could optionally declare it to
not inspect printer ports.

Existing code would work as it always has.  New code could be smarter.

Lynn



Doug Thistlethwaite <doug at dupreeinc.com> said:

> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
> >On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
> >
> >  
> >
> > ...
> >
> >
> >Does commenting out the LPT enumeration actually help?  There can often be 
> >differences between debug information printed and whats really going on. 
> >When you combine various environments the debug info can even come out in 
> >the wrong order.
> >
> >I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
> >I do not think this problem is universal.
> >
> >--
> >Trent Jarvi
> >tjarvi at qbang.org
> >_______________________________________________
> >Rxtx mailing list
> >Rxtx at qbang.org
> >http://mailman.qbang.org/mailman/listinfo/rxtx
> >
> >
> >  
> >
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



-- 





From jredman at ergotech.com  Thu Jun  1 15:20:20 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 01 Jun 2006 15:20:20 -0600
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
Message-ID: <447F5A14.6010803@ergotech.com>

Doug,

If you specifically request ports, eg:

-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

or
 
-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

Depending upon the version  (Windows is COM1:COM2, etc. I assume).

Does it still enumerate the parallel ports?

Jim

Doug Thistlethwaite wrote:
> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
>> On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>
>>  
>>
>> ...
>>
>>
>> Does commenting out the LPT enumeration actually help?  There can often be 
>> differences between debug information printed and whats really going on. 
>> When you combine various environments the debug info can even come out in 
>> the wrong order.
>>
>> I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>> I do not think this problem is universal.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>>
>>  
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  1 16:49:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:49:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6EF4.7080709@dupreeinc.com>

I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
folder.  I created this file and added the following to the file:

gnu.io.rxtx.SerialPorts=COM3

and I get the following error on the console:
CommPortIdentifier:static initialization()
RXTXCommDriver {}
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
RXTXCommDriver:
    Jar version = RXTX-2.1-7
    native lib Version = RXTX-2.1-7
RXTXCommDriver:initialize()
checking for system-known ports of type 1
checking registry for ports of type 1

RXTXCommDriver:addSpecifiedPorts()
Exception in thread "main" java.lang.ExceptionInInitializerError
    at 
densconnect.SerialConnection.openConnection(SerialConnection.java:136)
    at densconnect.DensTalk.<init>(DensTalk.java:165)
    at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
    at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
    at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
    at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
Caused by: java.lang.NullPointerException
    at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
CommPortIdentifier:addPortName(COM3)
CommPortIdentifier:AddIdentifierToList()
CommPortIdentifier:AddIdentifierToList() null
...


It looks like it  read COM3 from the file, but it had the above 
exception that killed it.  The strange this is this error is from 
RXTXCommDriver initialize function (if statement line):

        OS = System.getProperty("os.name");
                System.out.println("OS NAME: " + OS);
        if(OS.toLowerCase().indexOf("linux") == -1)

OS is returning null, thus the error.

If the file is not present, it scans the ports and reads the OS.

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>Doug Thistlethwaite wrote:
>  
>
>>Trent,
>>
>>I commented out the section in RegisterScannedPorts() that adds the 
>>three LPT ports to the CandidateDeviceNames string array.  The 
>>application started immediately.  This is probably not the way to do 
>>this, but it was quick ,dirty, and worked.
>>
>>It would be nice if there was a way to pole the OS to see if there is 
>>even a port there, though I guess this is what this code is suppose to do...
>>
>>Doug
>>
>>Trent Jarvi wrote:
>>
>>    
>>
>>>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>>
>>> 
>>>
>>>...
>>>
>>>
>>>Does commenting out the LPT enumeration actually help?  There can often be 
>>>differences between debug information printed and whats really going on. 
>>>When you combine various environments the debug info can even come out in 
>>>the wrong order.
>>>
>>>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>>>I do not think this problem is universal.
>>>
>>>--
>>>Trent Jarvi
>>>tjarvi at qbang.org
>>>_______________________________________________
>>>Rxtx mailing list
>>>Rxtx at qbang.org
>>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>>
>>>
>>> 
>>>
>>>      
>>>
>>_______________________________________________
>>Rxtx mailing list
>>Rxtx at qbang.org
>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>    
>>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/bf4cca0e/attachment-0016.html

From doug at dupreeinc.com  Thu Jun  1 16:51:26 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:51:26 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6F6E.5060603@dupreeinc.com>

Jim,

I did not try your suggestion as I do not understand where I would put 
these command line parameters (it that is what they are).  It appears 
that using the properties file should do that same thing...

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>
>  
>


From doug at dupreeinc.com  Thu Jun  1 17:56:19 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 16:56:19 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
Message-ID: <447F7EA3.6050400@dupreeinc.com>

I think there is an error in the registerSpecifiedPorts() method.  When 
I have a gnu.io.rxtx.properties file in the ext directory, this function 
kills the System class  IF I call System.getProperty("os.name") before 
the call  to registerSpecifiedPorts(), it returns the os name, after the 
call, it returns null.  I have not played much with properties, except 
for reading them, so I don't really understand the code.

Doug



From doug at dupreeinc.com  Thu Jun  1 18:11:14 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 17:11:14 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F7EA3.6050400@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com>
Message-ID: <447F8222.3060402@dupreeinc.com>

Ok, I just hacked this thing up and got it to read the 
gnu.io.rxtx.properties file.

I commented out the line:
System.setProperties(p); in the method registerSpecifiedPorts() in 
RXTXCommDriver class.  I really don't understand that much about 
properties, but this call kills the System class.

I used the following in the gnu.io.rxtx.properties file:

gnu.io.rxtx.SerialPorts=COM3
gnu.io.rxtx.ParallelPorts=null

This allows the application to open very quickly without any errors.  
Whomever coded this class or somebody who understands properties should 
look at this method and make sure it is doing what they expect.

Doug




Doug Thistlethwaite wrote:

>I think there is an error in the registerSpecifiedPorts() method.  When 
>I have a gnu.io.rxtx.properties file in the ext directory, this function 
>kills the System class  IF I call System.getProperty("os.name") before 
>the call  to registerSpecifiedPorts(), it returns the os name, after the 
>call, it returns null.  I have not played much with properties, except 
>for reading them, so I don't really understand the code.
>
>Doug
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From tjarvi at qbang.org  Thu Jun  1 18:32:50 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 18:32:50 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F6EF4.7080709@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com> <447F6EF4.7080709@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011831510.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
> folder.  I created this file and added the following to the file:
>
> gnu.io.rxtx.SerialPorts=COM3
>
> and I get the following error on the console:
> CommPortIdentifier:static initialization()
> RXTXCommDriver {}
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
> RXTXCommDriver:
>   Jar version = RXTX-2.1-7
>   native lib Version = RXTX-2.1-7
> RXTXCommDriver:initialize()
> checking for system-known ports of type 1
> checking registry for ports of type 1
>
> RXTXCommDriver:addSpecifiedPorts()
> Exception in thread "main" java.lang.ExceptionInInitializerError
>   at densconnect.SerialConnection.openConnection(SerialConnection.java:136)
>   at densconnect.DensTalk.<init>(DensTalk.java:165)
>   at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
>   at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
>   at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
>   at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
> Caused by: java.lang.NullPointerException
>   at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
> CommPortIdentifier:addPortName(COM3)
> CommPortIdentifier:AddIdentifierToList()
> CommPortIdentifier:AddIdentifierToList() null
> ...
>
>

There is a solution for this bug.

http://bugzilla.qbang.org/show_bug.cgi?id=54

We have been horribly slow at getting the next round of patches in but 
they are comming.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  2 00:58:02 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 08:58:02 +0200
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F8222.3060402@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
Message-ID: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>

Hi Doug,

you wrote in an earlier message, that you would prefer an unchanged  
version. What about simply removing the RXTX parallel lib from the  
ext directory. This does not fix the bug, but it should fix your  
problem.

In general I think it is not a good idea to put the RXTX files in a  
system wide location. Putting the libs in the application folder and  
including the .jar in the application classpath (or application jar)  
is all that is required.

Regards,
Joachim

On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:

> Ok, I just hacked this thing up and got it to read the
> gnu.io.rxtx.properties file.
>
> I commented out the line:
> System.setProperties(p); in the method registerSpecifiedPorts() in
> RXTXCommDriver class.  I really don't understand that much about
> properties, but this call kills the System class.
>
> I used the following in the gnu.io.rxtx.properties file:
>
> gnu.io.rxtx.SerialPorts=COM3
> gnu.io.rxtx.ParallelPorts=null
>
> This allows the application to open very quickly without any errors.
> Whomever coded this class or somebody who understands properties  
> should
> look at this method and make sure it is doing what they expect.
>
> Doug
>
>
>
>
> Doug Thistlethwaite wrote:
>
>> I think there is an error in the registerSpecifiedPorts() method.   
>> When
>> I have a gnu.io.rxtx.properties file in the ext directory, this  
>> function
>> kills the System class  IF I call System.getProperty("os.name")  
>> before
>> the call  to registerSpecifiedPorts(), it returns the os name,  
>> after the
>> call, it returns null.  I have not played much with properties,  
>> except
>> for reading them, so I don't really understand the code.
>>
>> 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 antonio.luis at iscte.pt  Fri Jun  2 02:42:28 2006
From: antonio.luis at iscte.pt (=?ISO-8859-1?Q?Ant=F3nio_Lopes?=)
Date: Fri, 02 Jun 2006 09:42:28 +0100
Subject: [Rxtx] Exception when closing serial port
Message-ID: <447FF9F4.7060209@iscte.pt>

Hello everyone,
I've been using RXTX in a Java application in my Pocket PC.
The communication through the (bluetooth) serial port is working perfectly.

However, when I disconnect the app and close the serial port, sometimes I get 
the following error:

"1149237595000: RXTXPort:close detected bad File Descriptor"

The problem is that after this error occurs, the app is no longer able to 
connect to the serial port and I have to soft-reset the device in order to be 
able to connect to it again.

Any ideas on how to solve this issue?

Any help is appreciated.
Thanks,
regards,
-- 
Ant?nio Lopes

@contact: antonio.luis at iscte.pt
@work: ADETTI - ISCTE
@web: http://antonio.lopes.googlepages.com


From paul.klissner at sun.com  Fri Jun  2 02:44:34 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 01:44:34 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to RXTX
	again
Message-ID: <447FFA72.6040807@sun.com>

After looking into javax.comm 3.1 and what it would take to re-engineer it
to be compatible with RXTX platform libraries, I've decided, due my group's
priorities, complexity of the effort vs. benefit, and limited resources, 
to re-post
javax.comm 2.0 binaries on Sun's software download server, unsupported,
with disclaimers, as it was previously.

I don't think there will be any snags doing this from the standpoint of Sun
management or legality.  I will try to have it  posted there in the next 
week
or two, depending on how fast we can get it pushed through the process.

I'd like to think of this as a stop gap measure... ie. a compromise, 
where, at some
point in the not too distant future RXTX implements their own version of the
Java side of the API, as is normally done by javax.extension porters. 
That way
we avoid uncomfortable dependencies in the future.  And that really is 
the Java
development model.

Since RXTX already has the back-end code, porting the java code shouldn't
be a gargantuan effort at all, and RXTX will be in full control of the 
code top
to bottom. I think RXTX can do at least as good a job as the original 
coder.
Prepping 2.0 to be open sourced is more trouble than it is worth. ie. I 
don't
think the current implementation warrants it.

Ultimately, it would be nice to see someone open up a JSR and re-architect
the comm. API to overcome some of it's current design flaws (ie. be more
adaptable to modern platforms, more pluggable, better defined SPI, better
port ownership handling, etc...). A superior architecture would allow for
better collaboration in the future and better interchangeability of 
components
among projects.

Sun's 3.1 version of javax.comm, which is Sun's currently supported version,
has changes pertaining mostly to Sun platform-specific portmapping and has
some minor additional interactions with our back end code, but generally
has little bearing on RXTX. 

Paul



From joachim at buechse.de  Fri Jun  2 04:00:19 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 12:00:19 +0200
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
	RXTX again
In-Reply-To: <447FFA72.6040807@sun.com>
References: <447FFA72.6040807@sun.com>
Message-ID: <1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>

Good day Paul!

A clean architecture with loadable drivers and reusable code would be  
very beneficial for the future, I think everybody agrees. However  
this could be several years into the future. In the meantime, there  
is a real existing problem with IO support on Java. I have the strong  
feeling that most programmers want to code against one specification  
(javax.comm) and be able to replace the underlying implementation via  
a "plugin" on platforms where the SUN implementation is not  
sufficient. RXTX could be just this plugin (reusing very close to 0%  
of the javax.comm implementation but 100% of its API).

I want to propose an API addition and implementation change that will  
take less then 2 hours of manpower to implement and create a solution  
that can bridge the years until javax.comm has been based on a new  
architecture.

Looking at the javax.comm api at http://java.sun.com/products/ 
javacomm/reference/api/index.html I would like to propose the following:

The only entry point to javax.comm is CommPortIdentifier. It has 3  
static methods plus the constructor.

1) define one additional Interface

public interface CommProvider {
    CommPortIdentifier getPortIdentifier(CommPort port);
    CommPortIdentifier getPortIdentifier(String portName);
    Enumeration getPortIdentifiers ();
}

2) add one method to CommPortIdentifier

   public static setCustomCommProvider (CommProvider);

3) change the three static methods of CommPortIdentifier to dispatch  
to the CommProvider if it is set

4) change the constructor of CommPortIdentifier to

   public CommPortIdentifier(...) {
      if (isProviderSet && this.getClass() ==  
javax.comm.CommPortIdentifier) {
          throw new RuntimeException("illegal creation of  
CommPortIndentifier, custom CommProvider is in use");
      }

5) (this is optional, but would be very nice) automatically set a  
custom CommProvider if it is found on the classpath or defined via a  
system property.


The above 1) - 4) can be implemented in less than 1hour. 5) may take  
another hour. I agree that this is not the most elegant design, but  
it would solve a lot of problems with very little effort. It would  
certainly allow RXTX to move forward. If the javax.comm API needs to  
be redesigned completely this addition will not hurt, as people will  
move to the new API anyway and javax.comm 3.0 was so far never  
included in the main distribution.

Best regards,
Joachim

On 02.06.2006, at 10:44, Paul Klissner wrote:

> After looking into javax.comm 3.1 and what it would take to re- 
> engineer it
> to be compatible with RXTX platform libraries, I've decided, due my  
> group's
> priorities, complexity of the effort vs. benefit, and limited  
> resources,
> to re-post
> javax.comm 2.0 binaries on Sun's software download server,  
> unsupported,
> with disclaimers, as it was previously.
>
> I don't think there will be any snags doing this from the  
> standpoint of Sun
> management or legality.  I will try to have it  posted there in the  
> next
> week
> or two, depending on how fast we can get it pushed through the  
> process.
>
> I'd like to think of this as a stop gap measure... ie. a compromise,
> where, at some
> point in the not too distant future RXTX implements their own  
> version of the
> Java side of the API, as is normally done by javax.extension porters.
> That way
> we avoid uncomfortable dependencies in the future.  And that really is
> the Java
> development model.
>
> Since RXTX already has the back-end code, porting the java code  
> shouldn't
> be a gargantuan effort at all, and RXTX will be in full control of the
> code top
> to bottom. I think RXTX can do at least as good a job as the original
> coder.
> Prepping 2.0 to be open sourced is more trouble than it is worth.  
> ie. I
> don't
> think the current implementation warrants it.
>
> Ultimately, it would be nice to see someone open up a JSR and re- 
> architect
> the comm. API to overcome some of it's current design flaws (ie. be  
> more
> adaptable to modern platforms, more pluggable, better defined SPI,  
> better
> port ownership handling, etc...). A superior architecture would  
> allow for
> better collaboration in the future and better interchangeability of
> components
> among projects.
>
> Sun's 3.1 version of javax.comm, which is Sun's currently supported  
> version,
> has changes pertaining mostly to Sun platform-specific portmapping  
> and has
> some minor additional interactions with our back end code, but  
> generally
> has little bearing on RXTX.
>
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Fri Jun  2 09:10:13 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Fri, 2 Jun 2006 09:10:13 -0600 (MDT)
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <447FFA72.6040807@sun.com>
References: <447FFA72.6040807@sun.com>
Message-ID: <Pine.LNX.4.61.0606020906400.15971@www>

On Fri, 2 Jun 2006, Paul Klissner wrote:

> After looking into javax.comm 3.1 and what it would take to re-engineer it
> to be compatible with RXTX platform libraries, I've decided, due my group's
> priorities, complexity of the effort vs. benefit, and limited resources,
> to re-post
> javax.comm 2.0 binaries on Sun's software download server, unsupported,
> with disclaimers, as it was previously.
>

Hi Paul

To address users' immediate needs, we can release rxtx 2.0-7 (final) to 
match the 2.0 binaries from Sun when they are offered for download.

We can discuss potential long term solutions after that.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Fri Jun  2 10:20:09 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 02 Jun 2006 09:20:09 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
	<9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
Message-ID: <44806539.8080902@dupreeinc.com>

Thanks for the suggestion, I will give it a try.

Doug

Joachim Buechse wrote:

>Hi Doug,
>
>you wrote in an earlier message, that you would prefer an unchanged  
>version. What about simply removing the RXTX parallel lib from the  
>ext directory. This does not fix the bug, but it should fix your  
>problem.
>
>In general I think it is not a good idea to put the RXTX files in a  
>system wide location. Putting the libs in the application folder and  
>including the .jar in the application classpath (or application jar)  
>is all that is required.
>
>Regards,
>Joachim
>
>On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:
>
>  
>
>>Ok, I just hacked this thing up and got it to read the
>>gnu.io.rxtx.properties file.
>>
>>I commented out the line:
>>System.setProperties(p); in the method registerSpecifiedPorts() in
>>RXTXCommDriver class.  I really don't understand that much about
>>properties, but this call kills the System class.
>>
>>I used the following in the gnu.io.rxtx.properties file:
>>
>>gnu.io.rxtx.SerialPorts=COM3
>>gnu.io.rxtx.ParallelPorts=null
>>
>>This allows the application to open very quickly without any errors.
>>Whomever coded this class or somebody who understands properties  
>>should
>>look at this method and make sure it is doing what they expect.
>>
>>Doug
>>
>>
>>
>>
>>Doug Thistlethwaite wrote:
>>
>>    
>>
>>>I think there is an error in the registerSpecifiedPorts() method.   
>>>When
>>>I have a gnu.io.rxtx.properties file in the ext directory, this  
>>>function
>>>kills the System class  IF I call System.getProperty("os.name")  
>>>before
>>>the call  to registerSpecifiedPorts(), it returns the os name,  
>>>after the
>>>call, it returns null.  I have not played much with properties,  
>>>except
>>>for reading them, so I don't really understand the code.
>>>
>>>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
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060602/c8892a46/attachment-0016.html

From paul.klissner at sun.com  Fri Jun  2 12:09:26 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 11:09:26 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
Message-ID: <44807ED6.8000903@sun.com>

Joachim Buechse wrote:
> Good day Paul!
>
> A clean architecture with loadable drivers and reusable code would be  
> very beneficial for the future, I think everybody agrees. However  
> this could be several years into the future. In the meantime, there  
> is a real existing problem with IO support on Java. I have the strong  
> feeling that most programmers want to code against one specification  
> (javax.comm) and be able to replace the underlying implementation via  
> a "plugin" on platforms where the SUN implementation is not  
> sufficient. RXTX could be just this plugin (reusing very close to 0%  
> of the javax.comm implementation but 100% of its API).
>
> I want to propose an API addition and implementation change that will  
> take less then 2 hours of manpower to implement and create a solution  
> that can bridge the years until javax.comm has been based on a new  
> architecture.
>
> Looking at the javax.comm api at http://java.sun.com/products/ 
> javacomm/reference/api/index.html I would like to propose the following:
>
> The only entry point to javax.comm is CommPortIdentifier. It has 3  
> static methods plus the constructor.
>
> 1) define one additional Interface
>
> public interface CommProvider {
>     CommPortIdentifier getPortIdentifier(CommPort port);
>     CommPortIdentifier getPortIdentifier(String portName);
>     Enumeration getPortIdentifiers ();
> }
>
> 2) add one method to CommPortIdentifier
>
>    public static setCustomCommProvider (CommProvider);
>
> 3) change the three static methods of CommPortIdentifier to dispatch  
> to the CommProvider if it is set
>
> 4) change the constructor of CommPortIdentifier to
>
>    public CommPortIdentifier(...) {
>       if (isProviderSet && this.getClass() ==  
> javax.comm.CommPortIdentifier) {
>           throw new RuntimeException("illegal creation of  
> CommPortIndentifier, custom CommProvider is in use");
>       }
>
> 5) (this is optional, but would be very nice) automatically set a  
> custom CommProvider if it is found on the classpath or defined via a  
> system property.
>
>
> The above 1) - 4) can be implemented in less than 1hour. 5) may take  
> another hour. I agree that this is not the most elegant design, but  
> it would solve a lot of problems with very little effort. It would  
> certainly allow RXTX to move forward. If the javax.comm API needs to  
> be redesigned completely this addition will not hurt, as people will  
> move to the new API anyway and javax.comm 3.0 was so far never  
> included in the main distribution.
>
> Best regards,
> Joachi
I'm afraid modifying the interface classes isn't my call.  There was 
actually
a TCK written and one of the tests was to ensure that the interface classes
match the spec.  Thus my hands have already been tied since this project
was essentially grandfathered into the JCP.

That's why we need to open a new JSR and find someone who wants
to be the spec lead, and go in with a new reference implementation.
I'm not sure why it would have to take years, since this isn't bleeding edge
technology and there are only so many things that can be done with it,
and we already have practical experience about many functional aspects
that we could cite precedence on.

As it becomes clear that the specification is being accepted completely
or by-and-large by the community, nothing would stop people from
starting adapting to the new API (using the reference implementation or
porting it) and using it in their projects prior to it's final community and
JCP approval, since approval is required only to make it official and
get the "100% pure java" certification for platform ports.

You have one idea already.  Why don't you implement it, solicit some
design feedback from Sun and the RXTX, and create a functional
implementation that addresses the needs of the community, then
we can document it and open a JSR.  That's it.  It should march through
the approval stages reasonably quickly I would imagine, and meantime
RXTX could start using it.

Paul




From doug at dupreeinc.com  Fri Jun  2 12:45:01 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 02 Jun 2006 11:45:01 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
	<9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
Message-ID: <4480872D.6000605@dupreeinc.com>

Joachim,

Thank you for the suggestion.  I restored the jar file to the one I 
downloaded, moved the dll files into the project directory, and added 
the jar to the classpath.  The SerialDemo program that was included with 
the Sun commapi started in 12 seconds instead of the 58 seconds when the 
parallel dll is present.  I did get the startup time to about a second 
by modifying the java code and adding the properties file but this is 
probably not a good idea.

Doug

Joachim Buechse wrote:

>Hi Doug,
>
>you wrote in an earlier message, that you would prefer an unchanged  
>version. What about simply removing the RXTX parallel lib from the  
>ext directory. This does not fix the bug, but it should fix your  
>problem.
>
>In general I think it is not a good idea to put the RXTX files in a  
>system wide location. Putting the libs in the application folder and  
>including the .jar in the application classpath (or application jar)  
>is all that is required.
>
>Regards,
>Joachim
>
>On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:
>
>  
>
>>Ok, I just hacked this thing up and got it to read the
>>gnu.io.rxtx.properties file.
>>
>>I commented out the line:
>>System.setProperties(p); in the method registerSpecifiedPorts() in
>>RXTXCommDriver class.  I really don't understand that much about
>>properties, but this call kills the System class.
>>
>>I used the following in the gnu.io.rxtx.properties file:
>>
>>gnu.io.rxtx.SerialPorts=COM3
>>gnu.io.rxtx.ParallelPorts=null
>>
>>This allows the application to open very quickly without any errors.
>>Whomever coded this class or somebody who understands properties  
>>should
>>look at this method and make sure it is doing what they expect.
>>
>>Doug
>>
>>
>>
>>
>>Doug Thistlethwaite wrote:
>>
>>    
>>
>>>I think there is an error in the registerSpecifiedPorts() method.   
>>>When
>>>I have a gnu.io.rxtx.properties file in the ext directory, this  
>>>function
>>>kills the System class  IF I call System.getProperty("os.name")  
>>>before
>>>the call  to registerSpecifiedPorts(), it returns the os name,  
>>>after the
>>>call, it returns null.  I have not played much with properties,  
>>>except
>>>for reading them, so I don't really understand the code.
>>>
>>>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
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060602/3c0e420f/attachment-0016.html

From joachim at buechse.de  Fri Jun  2 13:46:36 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 21:46:36 +0200
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
	RXTX again
In-Reply-To: <44807ED6.8000903@sun.com>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
	<44807ED6.8000903@sun.com>
Message-ID: <6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>

Hello Paul,

of course, the basic change I suggested could be done "hidden".  The  
CommProvider interface could live somewhere in sun.xyz.*
The setCustomCommProvider method would not be in CommPortIdentifier  
but also somewhere in sun.xyz.* This would be an unofficial feature,  
the official interface stays exactly the same. However RXTX (and  
others) could access the hidden interface.

Don't get me wrong, I don't want to harass you into making changes  
you don't like (which probably wouldn't work anyway;-). But I'm a  
long time Java programmer and seeing the state of cross platform  
serial support for Java makes me feel really sad. In fact, when I  
started to look into Java serial port programming some months ago I  
was very surprised that javax.comm never made it into the JDK.

I'm sorry that I did not contribute my feedback to the JSR for  
javax.comm 3.0. However at the time I didn't do serial port  
programming in Java. I agree that a new JSR should be opened - I'm  
not an expert on JSRs or the JCP process, but from looking quickly  
over the progress of some JSRs I would be very surprised if we can  
have a new version in less then a year. In the meanwhile some people  
will start using javax.comm 3.0 (which can not be supported by RXTX),  
some will use javax.comm 2.0 (which means the 2.0.7 release of RXTX  
still needs to be maintained). This may get even worse if eg Apple  
decides to port and include javax.comm 3.0 at which point it may get  
very tricky to write a cross platform Java application.

All of this simply means, that we are loosing a lot of man-power that  
could otherwise be invested in building a clean solution and/or to  
add features that are becoming more and more important (USB events...).

In the automation / machine control universe Java makes a lot of  
sense. Right now many people are migrating to Linux or from  
propietary systems (even DOS) to Windows. Writing the control/ 
configuration applications in Java is the kings way to unify the code  
base.

Best regards,
Joachim


On 02.06.2006, at 20:09, Paul Klissner wrote:

> Joachim Buechse wrote:
>> Good day Paul!
>>
>> A clean architecture with loadable drivers and reusable code would be
>> very beneficial for the future, I think everybody agrees. However
>> this could be several years into the future. In the meantime, there
>> is a real existing problem with IO support on Java. I have the strong
>> feeling that most programmers want to code against one specification
>> (javax.comm) and be able to replace the underlying implementation via
>> a "plugin" on platforms where the SUN implementation is not
>> sufficient. RXTX could be just this plugin (reusing very close to 0%
>> of the javax.comm implementation but 100% of its API).
>>
>> I want to propose an API addition and implementation change that will
>> take less then 2 hours of manpower to implement and create a solution
>> that can bridge the years until javax.comm has been based on a new
>> architecture.
>>
>> Looking at the javax.comm api at http://java.sun.com/products/
>> javacomm/reference/api/index.html I would like to propose the  
>> following:
>>
>> The only entry point to javax.comm is CommPortIdentifier. It has 3
>> static methods plus the constructor.
>>
>> 1) define one additional Interface
>>
>> public interface CommProvider {
>>     CommPortIdentifier getPortIdentifier(CommPort port);
>>     CommPortIdentifier getPortIdentifier(String portName);
>>     Enumeration getPortIdentifiers ();
>> }
>>
>> 2) add one method to CommPortIdentifier
>>
>>    public static setCustomCommProvider (CommProvider);
>>
>> 3) change the three static methods of CommPortIdentifier to dispatch
>> to the CommProvider if it is set
>>
>> 4) change the constructor of CommPortIdentifier to
>>
>>    public CommPortIdentifier(...) {
>>       if (isProviderSet && this.getClass() ==
>> javax.comm.CommPortIdentifier) {
>>           throw new RuntimeException("illegal creation of
>> CommPortIndentifier, custom CommProvider is in use");
>>       }
>>
>> 5) (this is optional, but would be very nice) automatically set a
>> custom CommProvider if it is found on the classpath or defined via a
>> system property.
>>
>>
>> The above 1) - 4) can be implemented in less than 1hour. 5) may take
>> another hour. I agree that this is not the most elegant design, but
>> it would solve a lot of problems with very little effort. It would
>> certainly allow RXTX to move forward. If the javax.comm API needs to
>> be redesigned completely this addition will not hurt, as people will
>> move to the new API anyway and javax.comm 3.0 was so far never
>> included in the main distribution.
>>
>> Best regards,
>> Joachi
> I'm afraid modifying the interface classes isn't my call.  There was
> actually
> a TCK written and one of the tests was to ensure that the interface  
> classes
> match the spec.  Thus my hands have already been tied since this  
> project
> was essentially grandfathered into the JCP.
>
> That's why we need to open a new JSR and find someone who wants
> to be the spec lead, and go in with a new reference implementation.
> I'm not sure why it would have to take years, since this isn't  
> bleeding edge
> technology and there are only so many things that can be done with it,
> and we already have practical experience about many functional aspects
> that we could cite precedence on.
>
> As it becomes clear that the specification is being accepted  
> completely
> or by-and-large by the community, nothing would stop people from
> starting adapting to the new API (using the reference  
> implementation or
> porting it) and using it in their projects prior to it's final  
> community and
> JCP approval, since approval is required only to make it official and
> get the "100% pure java" certification for platform ports.
>
> You have one idea already.  Why don't you implement it, solicit some
> design feedback from Sun and the RXTX, and create a functional
> implementation that addresses the needs of the community, then
> we can document it and open a JSR.  That's it.  It should march  
> through
> the approval stages reasonably quickly I would imagine, and meantime
> RXTX could start using it.
>
> Paul
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From paul.klissner at sun.com  Fri Jun  2 14:38:49 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 13:38:49 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
	<44807ED6.8000903@sun.com>
	<6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>
Message-ID: <4480A1D9.5060106@sun.com>

Joachim Buechse wrote:
> Hello Paul,
>
> of course, the basic change I suggested could be done "hidden".  The  
> CommProvider interface could live somewhere in sun.xyz.*
> The setCustomCommProvider method would not be in CommPortIdentifier  
> but also somewhere in sun.xyz.* This would be an unofficial feature,  
> the official interface stays exactly the same. However RXTX (and  
> others) could access the hidden interface.
>
> Don't get me wrong, I don't want to harass you into making changes  
> you don't like (which probably wouldn't work anyway;-). But I'm a  
> long time Java programmer and seeing the state of cross platform  
> serial support for Java makes me feel really sad. In fact, when I  
> started to look into Java serial port programming some months ago I  
> was very surprised that javax.comm never made it into the JDK.
>
> I'm sorry that I did not contribute my feedback to the JSR for  
> javax.comm 3.0. 
There was no JSR for 3.0, because we didn't have the resources to make 
the commitment.
Yet Sun needed to add support for platform-dependent port name mapping, 
which had to
be done 'under the hood', since the API isn't designed to handle that in 
a pluggable way.
But these quick fixes aren't the right approach, they just kick the dog 
down the road,
setting bad precedent, inviting confusion and more intractable problems 
(such as the
one plaguing us now).

My changes could have been layered better, it was a trade off between 
achieving an
ideal architecture, trying to find internal reviewers, and meet the 
needs of big customers
in a timely way.  Thus my namespace changes collided with RXTX's 
dependencies.
I was unaware of Jagane's rogue agreement made with the RXTX community 7 
years ago,
before Jagane left Sun.  I think this was a wag-the-dog situation.

Now it is time to do it right, and I don't think it is going to be as 
much trouble as people
some people fear. If RXTX wants to sponsor the JSR and seed a new spec, 
Sun can join
the Expert Group.  And we'd be largely in agreement, since we're not 
talking about
humongous changes, and looking for mutually beneficial changes. The core 
API is already
largely proved and tested.
> However at the time I didn't do serial port  
> programming in Java. I agree that a new JSR should be opened - I'm  
> not an expert on JSRs or the JCP process, but from looking quickly  
> over the progress of some JSRs I would be very surprised if we can  
> have a new version in less then a year. 
*Approved*  But that doesn't mean the spec couldn't be 99.9% stable 
before that.  Once
the delta rate declines and changes approach nil, people could start 
adapting to the API in
advance of formal approval.   It isn't going to be drawn out like 
javax.usb, which was new
technology, a very complex API, and involved precedent setting corporate 
disputes and
policy issues to resolve.

> In the meanwhile some people  
> will start using javax.comm 3.0 (which can not be supported by RXTX),  
> some will use javax.comm 2.0 (which means the 2.0.7 release of RXTX  
> still needs to be maintained). This may get even worse if eg Apple  
> decides to port and include javax.comm 3.0 at which point it may get  
> very tricky to write a cross platform Java application.
>   
The interfaces haven't changed since 1.0.  If we open a JSR ,we can 
contact Apple and
allow them to be on the E.G., if they want.  That might make the JSR a 
bit more drawn out,
but then we'd arrive ultimately arrive at a best-of-all-worlds API that 
most people would
accept, perhaps forever, and arrive at a respectable set of compromises.

-Paul

> All of this simply means, that we are loosing a lot of man-power that  
> could otherwise be invested in building a clean solution and/or to  
> add features that are becoming more and more important (USB events...).
>
> In the automation / machine control universe Java makes a lot of  
> sense. Right now many people are migrating to Linux or from  
> propietary systems (even DOS) to Windows. Writing the control/ 
> configuration applications in Java is the kings way to unify the code  
> base.
>
> Best regards,
> Joachim
>
>
> On 02.06.2006, at 20:09, Paul Klissner wrote:
>
>   
>> Joachim Buechse wrote:
>>     
>>> Good day Paul!
>>>
>>> A clean architecture with loadable drivers and reusable code would be
>>> very beneficial for the future, I think everybody agrees. However
>>> this could be several years into the future. In the meantime, there
>>> is a real existing problem with IO support on Java. I have the strong
>>> feeling that most programmers want to code against one specification
>>> (javax.comm) and be able to replace the underlying implementation via
>>> a "plugin" on platforms where the SUN implementation is not
>>> sufficient. RXTX could be just this plugin (reusing very close to 0%
>>> of the javax.comm implementation but 100% of its API).
>>>
>>> I want to propose an API addition and implementation change that will
>>> take less then 2 hours of manpower to implement and create a solution
>>> that can bridge the years until javax.comm has been based on a new
>>> architecture.
>>>
>>> Looking at the javax.comm api at http://java.sun.com/products/
>>> javacomm/reference/api/index.html I would like to propose the  
>>> following:
>>>
>>> The only entry point to javax.comm is CommPortIdentifier. It has 3
>>> static methods plus the constructor.
>>>
>>> 1) define one additional Interface
>>>
>>> public interface CommProvider {
>>>     CommPortIdentifier getPortIdentifier(CommPort port);
>>>     CommPortIdentifier getPortIdentifier(String portName);
>>>     Enumeration getPortIdentifiers ();
>>> }
>>>
>>> 2) add one method to CommPortIdentifier
>>>
>>>    public static setCustomCommProvider (CommProvider);
>>>
>>> 3) change the three static methods of CommPortIdentifier to dispatch
>>> to the CommProvider if it is set
>>>
>>> 4) change the constructor of CommPortIdentifier to
>>>
>>>    public CommPortIdentifier(...) {
>>>       if (isProviderSet && this.getClass() ==
>>> javax.comm.CommPortIdentifier) {
>>>           throw new RuntimeException("illegal creation of
>>> CommPortIndentifier, custom CommProvider is in use");
>>>       }
>>>
>>> 5) (this is optional, but would be very nice) automatically set a
>>> custom CommProvider if it is found on the classpath or defined via a
>>> system property.
>>>
>>>
>>> The above 1) - 4) can be implemented in less than 1hour. 5) may take
>>> another hour. I agree that this is not the most elegant design, but
>>> it would solve a lot of problems with very little effort. It would
>>> certainly allow RXTX to move forward. If the javax.comm API needs to
>>> be redesigned completely this addition will not hurt, as people will
>>> move to the new API anyway and javax.comm 3.0 was so far never
>>> included in the main distribution.
>>>
>>> Best regards,
>>> Joachi
>>>       
>> I'm afraid modifying the interface classes isn't my call.  There was
>> actually
>> a TCK written and one of the tests was to ensure that the interface  
>> classes
>> match the spec.  Thus my hands have already been tied since this  
>> project
>> was essentially grandfathered into the JCP.
>>
>> That's why we need to open a new JSR and find someone who wants
>> to be the spec lead, and go in with a new reference implementation.
>> I'm not sure why it would have to take years, since this isn't  
>> bleeding edge
>> technology and there are only so many things that can be done with it,
>> and we already have practical experience about many functional aspects
>> that we could cite precedence on.
>>
>> As it becomes clear that the specification is being accepted  
>> completely
>> or by-and-large by the community, nothing would stop people from
>> starting adapting to the new API (using the reference  
>> implementation or
>> porting it) and using it in their projects prior to it's final  
>> community and
>> JCP approval, since approval is required only to make it official and
>> get the "100% pure java" certification for platform ports.
>>
>> You have one idea already.  Why don't you implement it, solicit some
>> design feedback from Sun and the RXTX, and create a functional
>> implementation that addresses the needs of the community, then
>> we can document it and open a JSR.  That's it.  It should march  
>> through
>> the approval stages reasonably quickly I would imagine, and meantime
>> RXTX could start using it.
>>
>> Paul
>>
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at 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  Sat Jun  3 18:15:24 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 18:15:24 -0600 (MDT)
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
Message-ID: <Pine.LNX.4.61.0606031715100.10890@www>


The attached patch allows baud rates of 14400, 28800, 128000 and 256000.

That was my goal.

[import standard disclaimer]

But I took some time to look a little further.  I got custom baud rates 
working enough that someone (perhaps me) can properly fix them in the 
future.  Proof of concept.

As an undocumented bonus, you can toss random baudrates (say 1953), at the 
API and it will set it to something close to that on windows and linux. 
Solaris should say the baud rate is not supported but I have not tested it 
yet.  Mac OS X behavior is unknown at this point.  Just dont expect 
correct behavior at ~8192-9009 baudrates or baudrates less than 20 on 
windows; these baud rates overlap with defines in win32termios.h.  I 
conveniently closed my eyes there.  Try another value close.  On Linux, a 
baud base and divisor are guestimated and set.  On windows, we wave pixie 
dust over the kernel driver and hope.  Do not expect pixie dust and 
guestimates to be the same on windows and linux.  They may well round to 
different values in yet to be tested ways.  There are only so many 
divisors.  If it isn't working, try a little higher or lower.

In the example of 1953 for instance, there is no divisor for commodity 
hardware that comes to that baudrate.  We just come close on one side or 
the other.  If tools tell you they got 1953 exactly, the tools may be 
questionable and just reading values not directly related to the actual 
hardware settings.

These fixes have been tested on Linux and Windows while using an 
oscilloscope to confirm they change relative to known baudrates at 9600, 
14400*, 19200, 28800* (and 1800, 1953** and 2400).

* = previously unsupported.
** = still not supported but probably works from what I saw.

There could be future discussion in this area.  For now this is working 
for almost all unusual baud rate demands.  Cleaning up the custom baud 
rate should be easier with a working starting point.  Baud bases other 
than 128000 have not been characterized.  Yes.. this overlapps with two of 
the baud rates enabled.

Feedback and ideas are welcome.

--
Trent Jarvi
tjarvi at qbang.org
-------------- next part --------------
Index: SerialImp.c
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v
retrieving revision 1.46.2.187
diff -u -r1.46.2.187 SerialImp.c
--- SerialImp.c	29 Jan 2006 22:19:04 -0000	1.46.2.187
+++ SerialImp.c	3 Jun 2006 23:12:40 -0000
@@ -793,6 +793,19 @@
 		result &= ~TIOCM_DTR;
 		ioctl( fd, TIOCMSET, &result );
 	}
+	/*
+	   B38400 is a special case in Linux for custom baud rates.
+
+	   We just treat this as a custom speed for now.  If you take this ifdef
+	   out and select baud rates 38400 then 28800 then 38400, you will get
+	   a final baud rate of 28800 because you did not update the divisor.
+
+	   See the next ifdef below for the divisor.
+	*/
+#if defined(TIOCGSERIAL)
+	if ( cspeed == B38400 )
+		cspeed = 38400;
+#endif /* TIOCGSERIAL */
 	if(     cfsetispeed( &ttyset, cspeed ) < 0 ||
 		cfsetospeed( &ttyset, cspeed ) < 0 )
 	{
@@ -814,6 +827,7 @@
 		*/
 
 #if defined(TIOCGSERIAL)
+		ioctl( fd, TIOCGSERIAL, &sstruct );
 		sstruct.custom_divisor = ( sstruct.baud_base/cspeed );
 		cspeed = B38400;
 #endif /* TIOCGSERIAL */
@@ -827,7 +841,7 @@
 #if defined(TIOCSSERIAL)
 		/*  It is assumed Win32 does this for us */
 		if (	sstruct.baud_base < 1 ||
-			ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
+		ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
 		{
 			return( 1 );
 		}
Index: termios.c
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v
retrieving revision 1.9.2.56
diff -u -r1.9.2.56 termios.c
--- termios.c	16 Jan 2006 02:50:32 -0000	1.9.2.56
+++ termios.c	3 Jun 2006 23:12:40 -0000
@@ -323,8 +323,8 @@
 		case CBR_3500000:	return( B3500000 );
 		case CBR_4000000:	return( B4000000 );
 		default:
-			set_errno(EINVAL );
-			return -1;
+			/* assume custom baudrate */
+			return( Baud );
 	}
 }
 
@@ -361,12 +361,13 @@
 		case B9600:	ret = CBR_9600;		break;
 		case B14400:	ret = CBR_14400;	break;
 		case B19200:	ret = CBR_19200;	break;
+		case B28800:	ret = CBR_28800;	break;
 		case B38400:	ret = CBR_38400;	break;
 		case B57600:	ret = CBR_57600;	break;
 		case B115200:	ret = CBR_115200;	break;
 		case B128000:	ret = CBR_128000;	break;
-		case B256000: 	ret = CBR_256000;	break;
 		case B230400:	ret = CBR_230400;	break;
+		case B256000: 	ret = CBR_256000;	break;
 		case B460800:	ret = CBR_460800;	break;
 		case B500000:	ret = CBR_500000;	break;
 		case B576000:	ret = CBR_576000;	break;
@@ -381,10 +382,8 @@
 		case B4000000:	ret = CBR_4000000;	break;
 	
 		default:
-			fprintf( stderr, "B_to_CBR: invalid baudrate: %#o\n",
-				Baud );
-			set_errno( EINVAL );
-			return -1;
+			/* assume custom baudrate */
+			return Baud;
 	}
 	LEAVE( "B_to_CBR" );
 	return ret;
@@ -708,12 +707,9 @@
 	ENTER( "init_serial_struct" );
 
 	/*
-	FIXME
-
-	This needs to use inb() to read the actual baud_base
-	and divisor from the UART registers.  Question is how
-	far do we take this?
-
+	use of custom_divisor and baud_base requires access to
+	kernel space.  The kernel does try its best if you just
+	toss a baud rate at it though.
 	*/
 
 	sstruct->custom_divisor = 0;
@@ -1678,16 +1674,17 @@
 {
 	char message[80];
 	ENTER( "cfsetospeed" );
+	/* clear baudrate */
+	s_termios->c_cflag &= ~CBAUD;
 	if ( speed & ~CBAUD )
 	{
 		sprintf( message, "cfsetospeed: not speed: %#o\n", speed );
 		report( message );
-		return 0;
+		/* continue assuming its a custom baudrate */
+		s_termios->c_cflag |= B38400;  /* use 38400 during custom */
+		s_termios->c_cflag |= CBAUDEX; /* use CBAUDEX for custom */
 	}
-	s_termios->c_ispeed = s_termios->c_ospeed = speed;
-	/* clear baudrate */
-	s_termios->c_cflag &= ~CBAUD;
-	if( speed )
+	else if( speed )
 	{
 		s_termios->c_cflag |= speed;
 	}
@@ -1696,6 +1693,7 @@
 		/* PC blows up with speed 0 handled in Java */
 		s_termios->c_cflag |= B9600;
 	}
+	s_termios->c_ispeed = s_termios->c_ospeed = speed;
 	LEAVE( "cfsetospeed" );
 	return 1;
 }
@@ -1767,25 +1765,6 @@
 }
 
 /*----------------------------------------------------------
-serial_struct_to_DCB()
-
-   accept:      
-   perform:     
-   return:      
-   exceptions:  
-   win32api:     None
-   comments:    
-----------------------------------------------------------*/
-int serial_struct_to_DCB( struct serial_struct *sstruct, DCB *dcb )
-{
-	/* 5 Baud rate fix
-	sstruct.baud_base
-	sstruct.custom_divisor = ( sstruct.baud_base/cspeed );
-	*/
-	return(0);
-}
-
-/*----------------------------------------------------------
 termios_to_DCB()
 
    accept:      
@@ -1798,7 +1777,8 @@
 int termios_to_DCB( struct termios *s_termios, DCB *dcb )
 {
 	ENTER( "termios_to_DCB" );
-	s_termios->c_ispeed = s_termios->c_ospeed = s_termios->c_cflag & CBAUD;
+	if ( !(s_termios->c_cflag & CBAUDEX) )
+		s_termios->c_ispeed = s_termios->c_ospeed = s_termios->c_cflag & CBAUD;
 	dcb->BaudRate        = B_to_CBR( s_termios->c_ispeed );
 	dcb->ByteSize = termios_to_bytesize( s_termios->c_cflag );
 
@@ -2863,11 +2843,6 @@
 			GetCommState( index->hComm, dcb );
 
 			index->sstruct = va_arg( ap, struct serial_struct * );
-			if ( serial_struct_to_DCB( index->sstruct, dcb ) < 0 )
-			{
-				va_end( ap );
-				return -1;
-			}
 
 			report( "TIOCSSERIAL\n" );
 			free(dcb);
Index: win32termios.h
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v
retrieving revision 1.5.2.28
diff -u -r1.5.2.28 win32termios.h
--- win32termios.h	30 Jun 2005 20:23:26 -0000	1.5.2.28
+++ win32termios.h	3 Jun 2006 23:12:40 -0000
@@ -279,7 +279,7 @@
 #define XTABS	01000000 /* Hmm.. Linux/i386 considers this part of TABDLY.. */
 
 /* c_cflag bit meaning */
-# define CBAUD	0010017
+#define  CBAUD  0030017
 #define  B0	0000000		/* hang up */
 #define  B50	0000001
 #define  B75	0000002
@@ -312,13 +312,16 @@
 #define  B3500000 0010016
 #define  B4000000 0010017
 
-/* glue for unsupported linux speeds see also SerialImp.h */
-/* hosed */
-
-#define B14400		1010001
-#define B28800		1010002
-#define B128000		1010003
-#define B256000		1010004
+/*
+	glue for unsupported linux speeds see also SerialImp.h 
+	custom baud rates around 8192-9000 will not work because
+	of these.
+*/
+
+#define B14400		0020001
+#define B28800		0020002
+#define B128000		0020003
+#define B256000		0020004
 
 #define EXTA B19200
 #define EXTB B38400
@@ -356,8 +359,10 @@
 
 /* glue for unsupported windows speeds */
 
-#define CBR_230400	230400
 #define CBR_28800	28800
+#define CBR_128000	128000
+#define CBR_230400	230400
+#define CBR_256000	256000
 #define CBR_460800	460800
 #define CBR_500000	500000
 #define CBR_576000	576000

From impakt01 at optusnet.com.au  Sat Jun  3 18:30:37 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 10:30:37 +1000
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
In-Reply-To: <Pine.LNX.4.61.0606031715100.10890@www>
Message-ID: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>

Hi Trent,
I'd love to try the patch but I can't get the latest build compiling, only
pre16. 

Can you attach the rxtxSerial.dll file with this patch?

Also, I hardcoded 1953 in a couple more places last night on pre16 and it
managed to open the port at the right speed, but stopped receiving anything
after 100-150 bytes, even though more data was getting sent to the port.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 10:15 AM
To: rxtx at qbang.org
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.


The attached patch allows baud rates of 14400, 28800, 128000 and 256000.

That was my goal.

[import standard disclaimer]

But I took some time to look a little further.  I got custom baud rates 
working enough that someone (perhaps me) can properly fix them in the 
future.  Proof of concept.

As an undocumented bonus, you can toss random baudrates (say 1953), at the 
API and it will set it to something close to that on windows and linux. 
Solaris should say the baud rate is not supported but I have not tested it 
yet.  Mac OS X behavior is unknown at this point.  Just dont expect 
correct behavior at ~8192-9009 baudrates or baudrates less than 20 on 
windows; these baud rates overlap with defines in win32termios.h.  I 
conveniently closed my eyes there.  Try another value close.  On Linux, a 
baud base and divisor are guestimated and set.  On windows, we wave pixie 
dust over the kernel driver and hope.  Do not expect pixie dust and 
guestimates to be the same on windows and linux.  They may well round to 
different values in yet to be tested ways.  There are only so many 
divisors.  If it isn't working, try a little higher or lower.

In the example of 1953 for instance, there is no divisor for commodity 
hardware that comes to that baudrate.  We just come close on one side or 
the other.  If tools tell you they got 1953 exactly, the tools may be 
questionable and just reading values not directly related to the actual 
hardware settings.

These fixes have been tested on Linux and Windows while using an 
oscilloscope to confirm they change relative to known baudrates at 9600, 
14400*, 19200, 28800* (and 1800, 1953** and 2400).

* = previously unsupported.
** = still not supported but probably works from what I saw.

There could be future discussion in this area.  For now this is working 
for almost all unusual baud rate demands.  Cleaning up the custom baud 
rate should be easier with a working starting point.  Baud bases other 
than 128000 have not been characterized.  Yes.. this overlapps with two of 
the baud rates enabled.

Feedback and ideas are welcome.

--
Trent Jarvi
tjarvi at qbang.org



From tjarvi at qbang.org  Sat Jun  3 19:05:11 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 19:05:11 -0600 (MDT)
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
In-Reply-To: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>
References: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606031840400.10890@www>

On Sun, 4 Jun 2006, Daren wrote:

> Hi Trent,
> I'd love to try the patch but I can't get the latest build compiling, only
> pre16.
>
> Can you attach the rxtxSerial.dll file with this patch?
>
> Also, I hardcoded 1953 in a couple more places last night on pre16 and it
> managed to open the port at the right speed, but stopped receiving anything
> after 100-150 bytes, even though more data was getting sent to the port.
>


ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing

I dont think they will hang.  But I was just testing via loopback/break 
out box/scope.

I'll be putting about 10 patches and another set of binaries in that 
directory shortly.  For now the binaries should just have the baud_rate 
fix.

I'll announce all the patches at once.  but wont be releasing 2.1-8 right 
away.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Sat Jun  3 21:00:01 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 21:00:01 -0600 (MDT)
Subject: [Rxtx] CVS for 2.1 should have everything
Message-ID: <Pine.LNX.4.61.0606032056190.10890@www>


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org


From impakt01 at optusnet.com.au  Sat Jun  3 21:08:14 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 13:08:14 +1000
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <Pine.LNX.4.61.0606032056190.10890@www>
Message-ID: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>

Hi Trent,
I tried the latest dll and it opens the port, receives 100-200 bytes and
then stops receiving anything else..

I'll keep playing with it.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 1:00 PM
To: rxtx at qbang.org
Subject: [Rxtx] CVS for 2.1 should have everything


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From impakt01 at optusnet.com.au  Sat Jun  3 21:22:41 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 13:22:41 +1000
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
Message-ID: <200606040322.k543MqW1008455@mail12.syd.optusnet.com.au>

Played with it, problem, with a while loop in my code, working great now

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Daren
Sent: Sunday, 4 June 2006 1:08 PM
To: 'RXTX Developers and Users'
Subject: Re: [Rxtx] CVS for 2.1 should have everything

Hi Trent,
I tried the latest dll and it opens the port, receives 100-200 bytes and
then stops receiving anything else..

I'll keep playing with it.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 1:00 PM
To: rxtx at qbang.org
Subject: [Rxtx] CVS for 2.1 should have everything


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Sat Jun  3 21:35:41 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 21:35:41 -0600 (MDT)
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
References: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606032131140.10890@www>

On Sun, 4 Jun 2006, Daren wrote:

> Hi Trent,
> I tried the latest dll and it opens the port, receives 100-200 bytes and
> then stops receiving anything else..
>
> I'll keep playing with it.
>
> Daren

The difference may be that I'm talking to something at the exact same baud 
rate (loopback).

You may also try setting the baudrate to ~1933 and ~1973 to force the 
guesses one way or the other.  If you are on windows, we are not doing 
anything fancy in the end.  Thats the kernel guessing.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sun Jun  4 04:12:09 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sun, 4 Jun 2006 12:12:09 +0200
Subject: [Rxtx] Update of OSX installer, Readme, etc
Message-ID: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>

Good day,

after the latest changes a lot of OS X specific files should be  
updated. Especially the installer!

- The "MaxOSX" readme file on the root level is outdated (ie  
CodeWarrior information). Maybe we could even rename it to README.OSX  
to be in line with README.IPAQ, README.SCO (Trent do you mind copying/ 
renaming ,v files in the repository?).

- The lock files are no longer used and hence the user group magic  
and lock folder creation should be removed from the installer.

- MACOSX_IDE/ForPackageMaker/Resources/ReadMe.rtf and Welcome.rtf  
need to be updated.

- I suggest to replace the current installation instruction for OS X:  
Installation should occur into the application directory, not in the  
Java-VM directory. This simplifies things a lot, as the Mac Installer  
can be removed completely.

- The xcodeproject's build settings need to be updated to generate  
JAVA 1.1 format class files.


Dimitry: do you have time to tackle this? I could do it, but as this  
is "your baby" I thought you may prefer to do it yourself.

Regards,
Joachim



From dmarkman at mac.com  Sun Jun  4 11:27:53 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Sun, 4 Jun 2006 13:27:53 -0400
Subject: [Rxtx] Update of OSX installer, Readme, etc
In-Reply-To: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
References: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
Message-ID: <26E7A202-962B-4C19-93B6-29426C467249@mac.com>

Joachim,
unfortunately I don't have time right now to do that
so if you can do that, please do

it's not only my baby
it's yours too :-)

thanks


On Jun 4, 2006, at 6:12 AM, Joachim Buechse wrote:

> Good day,
>
> after the latest changes a lot of OS X specific files should be
> updated. Especially the installer!
>
> - The "MaxOSX" readme file on the root level is outdated (ie
> CodeWarrior information). Maybe we could even rename it to README.OSX
> to be in line with README.IPAQ, README.SCO (Trent do you mind copying/
> renaming ,v files in the repository?).
>
> - The lock files are no longer used and hence the user group magic
> and lock folder creation should be removed from the installer.
>
> - MACOSX_IDE/ForPackageMaker/Resources/ReadMe.rtf and Welcome.rtf
> need to be updated.
>
> - I suggest to replace the current installation instruction for OS X:
> Installation should occur into the application directory, not in the
> Java-VM directory. This simplifies things a lot, as the Mac Installer
> can be removed completely.
>
> - The xcodeproject's build settings need to be updated to generate
> JAVA 1.1 format class files.
>
>
> Dimitry: do you have time to tackle this? I could do it, but as this
> is "your baby" I thought you may prefer to do it yourself.
>
> Regards,
> Joachim
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman



From tjarvi at qbang.org  Sun Jun  4 13:54:02 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 4 Jun 2006 13:54:02 -0600 (MDT)
Subject: [Rxtx] Update of OSX installer, Readme, etc
In-Reply-To: <26E7A202-962B-4C19-93B6-29426C467249@mac.com>
References: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
	<26E7A202-962B-4C19-93B6-29426C467249@mac.com>
Message-ID: <Pine.LNX.4.61.0606041353040.22522@www>

On Sun, 4 Jun 2006, Dmitry Markman wrote:

> Joachim,
> unfortunately I don't have time right now to do that
> so if you can do that, please do
>
> it's not only my baby
> it's yours too :-)
>

I've given Joachim cvs access.  He has shown good work in bugzilla.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Mon Jun  5 10:08:32 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 5 Jun 2006 18:08:32 +0200
Subject: [Rxtx] Build process changes for Mac OS X
Message-ID: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>

Good day,

I have cleaned up some outdated Mac OSX specific build files in the  
repository.

There was not a lot left of the readme file "MacOSX" after cleaning  
it up, so I decided to rename it README.OSX to be in harmony with the  
other files in the directory (ie README.IPAQ, README.SCO, ...)

I added an (uncompressed) XCode 2.3 project file/structure  
with .cvsignore files that will ignore the user specific settings.  
This should work "out of the box" for OSX10.4. Users of 10.2/10.3 may  
have to switch the build settings.

[It's kind of tricky to choose "the right" setting. Afaik there is no  
way to compile a universal binary that will work on 10.3 or before.  
So it's either UniversalBinary OR Legacy. Maybe we should have  
different build targets for these different targets?? I would like to  
get some feedback from the Mac developers on this list regarding the  
subject].

Besides other things the OSX installer is no longer required. Since  
the next version (2.1.8) will no longer use lockfiles on OSX, the  
group/permission magic is no longer required and hence there remains  
basicly no work for the installer - other than copying 2 files to the  
VM extension directory. Then again, this is not the best way to  
install RXTX. So I removed the installer completely without modifying  
it, this should simplify a "resurrection" should it ever get necessary.

I had problems with the (compressed, ie sit.hqx) legacy project files  
on the latest installation of OSX (javac 1.5 creating non JDK1.1  
class files and some minor problems). To reduce potential confusion  
for newcomers I decided to remove them. This means that there is no  
longer a simple way to build RXTX for OSX 10.0 and 10.1 (I deeply  
apologize if anyone still relied on this ... well the files are in  
the Attiq).

Best regards,
Joachim


From joachim at buechse.de  Mon Jun  5 10:16:37 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 5 Jun 2006 18:16:37 +0200
Subject: [Rxtx] RXTX and lockfiles on OSX [it is fixed now]
Message-ID: <7D2C4418-9397-4B59-8091-9FDE4ED67836@buechse.de>

Quite a number of people contacted me in the last couple of weeks  
because of problems installing RXTX on OSX. I told you to wait for  
the "official" fix. Well, it has been fixed.

So if you were among the people waiting for the solution, you can now  
download the source rxtx-2.1-7r2.zip from the website. Once unpacked  
dont forget to use "cvs up" to update the files to the latest  
version. You can then open MACOSX_IDE/XCode/ 
LibSerialUniversal.xcodeproj with XCode 2.3 and build the libraries  
that no longer try to create lock files.

Regards,
Joachim


From brian at mbari.org  Mon Jun  5 10:52:43 2006
From: brian at mbari.org (Brian Schlining)
Date: Mon, 5 Jun 2006 09:52:43 -0700
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
Message-ID: <78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>

Hi Joachim,

> [It's kind of tricky to choose "the right" setting. Afaik there is no
> way to compile a universal binary that will work on 10.3 or before.
> So it's either UniversalBinary OR Legacy. Maybe we should have
> different build targets for these different targets?? I would like to
> get some feedback from the Mac developers on this list regarding the
> subject].

I imagine most developers will be compiling on 10.4 (It's the nature  
of the coder...gotta have the latest and greatest) and deploying to  
both 10.3 and 10.4; both of which will run Universal Binaries (see  
http://forums.macrumors.com/showthread.php?t=205348). So it sounds  
like you've covered the majority of users. Still, you know someone's  
going to pipe up about needing RXTX on 10.2 so it would be nice to  
have a target to make a PPC only build.

Just my 2 cents

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/1cac8c39/attachment-0016.html

From dmarkman at mac.com  Mon Jun  5 13:47:50 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Mon, 5 Jun 2006 15:47:50 -0400
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
Message-ID: <686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>

I don't think it will be a problem to run universal binary
on 10.2
however if binary has some calls that aren't implemented in 10.2
then you'll have a problem


On Jun 5, 2006, at 12:52 PM, Brian Schlining wrote:

> Hi Joachim,
>
>> [It's kind of tricky to choose "the right" setting. Afaik there is no
>> way to compile a universal binary that will work on 10.3 or before.
>> So it's either UniversalBinary OR Legacy. Maybe we should have
>> different build targets for these different targets?? I would like to
>> get some feedback from the Mac developers on this list regarding the
>> subject].
>
> I imagine most developers will be compiling on 10.4 (It's the  
> nature of the coder...gotta have the latest and greatest) and  
> deploying to both 10.3 and 10.4; both of which will run Universal  
> Binaries (see http://forums.macrumors.com/showthread.php?t=205348).  
> So it sounds like you've covered the majority of users. Still, you  
> know someone's going to pipe up about needing RXTX on 10.2 so it  
> would be nice to have a target to make a PPC only build.
>
> Just my 2 cents
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/9fafc878/attachment-0016.html

From brian at mbari.org  Mon Jun  5 14:52:41 2006
From: brian at mbari.org (Brian Schlining)
Date: Mon, 5 Jun 2006 13:52:41 -0700
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
Message-ID: <E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>

Hi Dmitry,

> I don't think it will be a problem to run universal binary
> on 10.2
> however if binary has some calls that aren't implemented in 10.2
> then you'll have a problem

You're right...I stand corrected.

Note however, to deploy a universal binary to 10.2 RXTX will need to  
use the 10.2 SDK to build the PPC side. (see http:// 
developer.apple.com/documentation/DeveloperTools/Conceptual/ 
cross_development/UniversalBinaries/chapter_4_section_1.html). I  
haven't been paying close attention to the new locking mechanism used  
by RXTX on the Mac...does 10.2 support it?

Joachim, which SDK will you be using by default for building the Mac  
PPC binaries?

>> Hi Joachim,
>>
>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>> is no
>>> way to compile a universal binary that will work on 10.3 or before.
>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>> different build targets for these different targets?? I would  
>>> like to
>>> get some feedback from the Mac developers on this list regarding the
>>> subject].
>>
>> I imagine most developers will be compiling on 10.4 (It's the  
>> nature of the coder...gotta have the latest and greatest) and  
>> deploying to both 10.3 and 10.4; both of which will run Universal  
>> Binaries (see http://forums.macrumors.com/showthread.php? 
>> t=205348). So it sounds like you've covered the majority of users.  
>> Still, you know someone's going to pipe up about needing RXTX on  
>> 10.2 so it would be nice to have a target to make a PPC only build.

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/153bf50e/attachment-0016.html

From dmarkman at mac.com  Mon Jun  5 19:02:04 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Mon, 5 Jun 2006 21:02:04 -0400
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
Message-ID: <7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>

if Joachim didn't change xcode project setting

/Developer/SDKs/MacOSX10.4u.sdk is used to build universal binary

so it's quite possible that it won't run properly on 10.2

so we have to change the building process, so ppc part will be built
with
/Developer/SDKs/MacOSX10.2.8.sdk

and finally to use lipo utility to build universal binaries

Joachim, did you use some specific locking API that wasn't implemented

in MacOSX10.2.8.sdk?

thanks


On Jun 5, 2006, at 4:52 PM, Brian Schlining wrote:

> Hi Dmitry,
>
>> I don't think it will be a problem to run universal binary
>> on 10.2
>> however if binary has some calls that aren't implemented in 10.2
>> then you'll have a problem
>
> You're right...I stand corrected.
>
> Note however, to deploy a universal binary to 10.2 RXTX will need  
> to use the 10.2 SDK to build the PPC side. (see http:// 
> developer.apple.com/documentation/DeveloperTools/Conceptual/ 
> cross_development/UniversalBinaries/chapter_4_section_1.html). I  
> haven't been paying close attention to the new locking mechanism  
> used by RXTX on the Mac...does 10.2 support it?
>
> Joachim, which SDK will you be using by default for building the  
> Mac PPC binaries?
>
>>> Hi Joachim,
>>>
>>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>>> is no
>>>> way to compile a universal binary that will work on 10.3 or before.
>>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>>> different build targets for these different targets?? I would  
>>>> like to
>>>> get some feedback from the Mac developers on this list regarding  
>>>> the
>>>> subject].
>>>
>>> I imagine most developers will be compiling on 10.4 (It's the  
>>> nature of the coder...gotta have the latest and greatest) and  
>>> deploying to both 10.3 and 10.4; both of which will run Universal  
>>> Binaries (see http://forums.macrumors.com/showthread.php? 
>>> t=205348). So it sounds like you've covered the majority of  
>>> users. Still, you know someone's going to pipe up about needing  
>>> RXTX on 10.2 so it would be nice to have a target to make a PPC  
>>> only build.
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/84790f80/attachment-0016.html

From joachim at buechse.de  Tue Jun  6 02:40:47 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 6 Jun 2006 10:40:47 +0200
Subject: [Rxtx] Building on OS X, Impl Changes
In-Reply-To: <7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
Message-ID: <CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>

Good day!

What's in the XCode project setting?
----------

The xcode project remained pretty much the same as before. I excluded  
the user specific files from CVS and changed some settings. I kept  
all the built targets (you shouldn't change what you don't understand;-)

Currently we the following build targets:
    RXTXComm (java files)
    librxtxParallel.jnilib (usefull on the Mac???)
    libI2C.jnilib (not yet working in RXTX)
    libRS485.jnilib (not yet working in RXTX)
    librxtxSerial.jnilib (1)
    librxtxSerial.jnilib Dynamic (2)
    rxtxSerial (3)
We also have the following build configurations for each target:
    Development
    Default
    Deployment

What was changed in the xcode project from previous versions:
- java.souce=1.3 and java.target=1.1 in RXTXComm settings
- removed copying of build products into installer directory
- removed "(Upgraded)" from build target names

What remains to be changed:
- choosing a "non-debug" Build-configuration as default
- potentially removing "Default"/"Development" Build-configurations
- reducing the number of build targets
- creating 10.2 compatible universal binaries

I suggest, that the build configurations should be reduced to 2  
(Debug/Deployment), possibly even 1 (Debug).
I have not yet found the deeper meaning of the build targets(1)(2) 
(3), it seems to me like they should be reduced into one "doing the  
right thing" or maybe into two "rxtxSerial.jnilib Legacy" (back to  
10.2, universal if possible) and "rxtxSerial.jnilib 10.4 
+" (universal, 10.4+).

Should the code work on 10.2?
----------

Absolutely. The code should work on NextStep, in fact on any BSD  
unix. I would go as far as saying, this code should work on any  
POSSIX based unix. All that was added is the call "ioctl(fd,  
TIOCEXCL)" to request excusivity of the port:

http://gemma.apple.com/documentation/DeviceDrivers/Conceptual/ 
WorkingWSerial/WWSerial_SerialDevs/chapter_2_section_8.html

It is not yet "the perfect solution". Normally an open /dev/tty  
(listen for incomming connection) should be "preemptable" by opening  
a /dev/cu (outgoing connection) for the same port. This is not yet  
implemented as it needs calls outside of POSSIX on OSX.

On "classic" systems (like NextStep) this worked based on the  
"carried detect line". open() on /dev/tty.xxx would block until the  
carrier detect signal was raised. As the device was not "opened"  
opening /dev/cu.xxx worked without a hitch. When they ported to the  
Mac this broke. On Macs the "carier detect" is usually not wired.  
Furthermore FAX modems did no longer raise the line. So the OSX  
implementor defined a new call, which is documented here:

http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00045.html

Best regards,
Joachim




On 06.06.2006, at 03:02, Dmitry Markman wrote:

> if Joachim didn't change xcode project setting
>
> /Developer/SDKs/MacOSX10.4u.sdk is used to build universal binary
>
> so it's quite possible that it won't run properly on 10.2
>
> so we have to change the building process, so ppc part will be built
> with
> /Developer/SDKs/MacOSX10.2.8.sdk
>
> and finally to use lipo utility to build universal binaries
>
> Joachim, did you use some specific locking API that wasn't implemented
>
> in MacOSX10.2.8.sdk?
>
> thanks
>
>
> On Jun 5, 2006, at 4:52 PM, Brian Schlining wrote:
>
>> Hi Dmitry,
>>
>>> I don't think it will be a problem to run universal binary
>>> on 10.2
>>> however if binary has some calls that aren't implemented in 10.2
>>> then you'll have a problem
>>
>> You're right...I stand corrected.
>>
>> Note however, to deploy a universal binary to 10.2 RXTX will need  
>> to use the 10.2 SDK to build the PPC side. (see http:// 
>> developer.apple.com/documentation/DeveloperTools/Conceptual/ 
>> cross_development/UniversalBinaries/chapter_4_section_1.html). I  
>> haven't been paying close attention to the new locking mechanism  
>> used by RXTX on the Mac...does 10.2 support it?
>>
>> Joachim, which SDK will you be using by default for building the  
>> Mac PPC binaries?
>>
>>>> Hi Joachim,
>>>>
>>>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>>>> is no
>>>>> way to compile a universal binary that will work on 10.3 or  
>>>>> before.
>>>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>>>> different build targets for these different targets?? I would  
>>>>> like to
>>>>> get some feedback from the Mac developers on this list  
>>>>> regarding the
>>>>> subject].
>>>>
>>>> I imagine most developers will be compiling on 10.4 (It's the  
>>>> nature of the coder...gotta have the latest and greatest) and  
>>>> deploying to both 10.3 and 10.4; both of which will run  
>>>> Universal Binaries (see http://forums.macrumors.com/ 
>>>> showthread.php?t=205348). So it sounds like you've covered the  
>>>> majority of users. Still, you know someone's going to pipe up  
>>>> about needing RXTX on 10.2 so it would be nice to have a target  
>>>> to make a PPC only build.
>>
>> Brian Schlining
>> Software Engineer
>> http://www.mbari.org
>>
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> Dmitry Markman
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Tue Jun  6 07:01:06 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 6 Jun 2006 15:01:06 +0200
Subject: [Rxtx] Serial port code for OS X, future steps
In-Reply-To: <CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
	<CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
Message-ID: <8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>

I posted the "wrong link". There is a correction here:

    http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00059.html

In fact, the 2.1.7 implementation of RXTX has quite some deficiencies  
on OSX. I have tried to supply some patches that don't interfere to  
much with the existing RXTX code base, but there are limits to what  
can be done with local patches.

There are some very intrusive changes that should be done. Ie proper  
mapping of /dev/tty <-> /dev/cu handling to correct behaviour of  
CommPortOwnershipListener (http://java.sun.com/products/javacomm/ 
reference/api/index.html). I dont think this can be done with  
patches. Hence I think, RXTX should be rewritten from scratch de- 
unifying the native code base (and implementing thread safe code on  
the Java side).


How "should" /dev/tty vs /dev/cu be implemented?

=====
The Unix contract is this: An open /dev/tty.xxx port (incomming)  
should be interrupted/auto-closed when opening /dev/cu.xxx (outgoing)  
[if /dev/tty.xxx is not currently handling a communication].  /dev/ 
cu.xxx and /dev/tty.xxx refer to the same device, so owning  
"exclusively" should block both. This should be respected across all  
applications native or Java.

This contract is realizable on OSX with the existing javax.comm  
interface while also respecting (to the biggest part) the contract  
defined by javax.comm.PortOwnershipListener.

The one point where the suggested implementation "breaks" the  
javax.comm contract, is by the fact that one can loose a /dev/tty  
port without calling close. However, the only option I see is to  
always open serial ports "non-exclusively" which would outrule Java  
as a platform for (dormant) applications waiting for incoming  
connections/faxes/etc. There could be a system property to choose the  
intended behavior.
=====

Here is how it could be done on OSX:

Calling port=ComportIdentifier.open("/dev/cu.xxx") opens and owns the  
port exclusively until port.close() is called.
- Java applications listening with a PortOwnershipListener should get  
a PORT_OWNED event reasonably soon.
- Any further attempt by a Java or native application to open "/dev/ 
cu.xxx" or "/dev/tty.xxx" fails.
- /dev/cu.xxx is for "outgoing" connections, so receiving  
PORT_OWNERSHIP_REQUESTED makes little to no sense. With native  
applications it can not be implemented. For Java applications it  
could be implemented (by a hidden communication channel). I think  
it's not worth bothering. If anyone is willing to give up a port to  
others he should use /dev/tty.xxx instead of /dev/cu.xxx.

Registering a PortOwnershipListener on "/dev/cu.xxx" without opening  
it, uses /dev/tty.xxx (native open()) non-exclusively and polls its  
state. PORT_OWNED and PORT_UNOWNED can be produced.

Calling port=ComportIdentifier.open("/dev/tty.xxx") should open the  
port non-exclusively.
- Adding a SerialPortEventListener and reading from the port could be  
allowed while keeping it non-exclusive.
- When port.getOutputStream() is called, the state should be changed  
to an "exclusive" ownership. This may be configurable via a system  
property.
- To return to the non-exclusive state the port must be closed and  
reopened.
- While non-exclusively opened, opening the corresponding /dev/cu.xxx  
produces a PORT_OWNERSHIP_REQUESTED event. Which should be responded  
by closing the port from within the callback (as described in  
java.comm.PortOwnershipListener). If there is a pending read, it will  
return after the listener finishes (with -1 or "0 bytes read").
- Calling write() on the /dev/tty.xxx after somebody opened /dev/ 
cu.xxx will fail with a descriptive IOException.
- Calling read() on the /dev/tty.xxx after somebody opened /dev/ 
cu.xxx will fail with a descriptive IOException (or potentially  
block, see side notes below).

CommPortIdentifier.getCurrentOwner() can be implemented by an  
external call to lsof.

CommPortIdentifier.isCurrentlyOwned() can be implemented by trying an  
open on the /dev/tty.
- It returns true if the port is currently held "exclusively".
- Whether it should also return true on /dev/tty if /dev/tty is  
already opened non-exclusively might be a system property option. In  
general, having several applications waiting for incoming connections  
on the same port will require an application level "arbitration"  
protocol...

[[side note1: One interesting question is, what happens if the  
process holding /dev/tty non-exclusively ignores  
PORT_OWNERSHIP_REQUESTED. Ie after "loosing" a non-exclusively opened  
"dev/tty.xxx" port to another process. One possible implementation  
is, that the port is "regained" when the other process gives up the  
port. This would mean that in the meanwhile read() returns no data,  
and any changes to the configuration of the port are stored but not  
forwarded. I guess, the safe (and simple) way to do this is to make  
the close() mandatory (ie setting the port into an "awaiting_close"  
state which produces IOExceptions to any other call than close). ]]

[[side note2:  Another interesting question is, what should happen if  
several applications open the same /dev/tty.xxx port "non- 
exclusively" and start to change the settings of the device.]]

Regards,
Joachim



On 06.06.2006, at 10:40, Joachim Buechse wrote:

> Should the code work on 10.2?
> ----------
>
> Absolutely. The code should work on NextStep, in fact on any BSD
> unix. I would go as far as saying, this code should work on any
> POSSIX based unix. All that was added is the call "ioctl(fd,
> TIOCEXCL)" to request excusivity of the port:
>
> http://gemma.apple.com/documentation/DeviceDrivers/Conceptual/
> WorkingWSerial/WWSerial_SerialDevs/chapter_2_section_8.html
>
> It is not yet "the perfect solution". Normally an open /dev/tty
> (listen for incomming connection) should be "preemptable" by opening
> a /dev/cu (outgoing connection) for the same port. This is not yet
> implemented as it needs calls outside of POSSIX on OSX.
>
> On "classic" systems (like NextStep) this worked based on the
> "carried detect line". open() on /dev/tty.xxx would block until the
> carrier detect signal was raised. As the device was not "opened"
> opening /dev/cu.xxx worked without a hitch. When they ported to the
> Mac this broke. On Macs the "carier detect" is usually not wired.
> Furthermore FAX modems did no longer raise the line. So the OSX
> implementor defined a new call, which is documented here:
>
> http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00045.html
>
> Best regards,
> Joachim



From sds at dcs.gla.ac.uk  Tue Jun  6 11:22:45 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Tue, 06 Jun 2006 18:22:45 +0100
Subject: [Rxtx] Correct compile flag for HP iPAQ hx4700 running Familiar
	Linux?
Message-ID: <1149614565.19496.10.camel@addu>

Hi,

I'd like to use RXTX 2.1 on my HP iPAQ hx4700. The iPAQ is running
Familiar Linux 0.8.2 (as I recall), with Blackdown Java 1.3.1.

I can compile and run a test program which uses RXTX on my i686 machine,
and it works fine. But I can't seem to get things working quite right on
my PDA.

I compile the code on the laptop with the following commands:
	./configure --host=arm-gnu-linux && make
... as suggested in a post to this list, albeit some time ago. This
compiles, I transfer the files, set up LD_LIBRARY_PATH and CLASSPATH
variables, and get the following error on the PDA:

sds at ipaq-pxa-2:~# java Test
java.lang.UnsatisfiedLinkError: /usr/local/lib/ext/librxtxSerial.so: /usr/local/lib/ext/librxtxSerial.so: cannot open shared object file: No such file or directory thrown while loading gnu.io.RXTXCommDriver
Exception in thread "main"
java.lang.UnsatisfiedLinkError: /usr/local/lib/ext/librxtxSerial.so: /usr/local/lib/ext/librxtxSerial.so: cannot open shared object file: No such file or directory
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1382)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1290)
        at java.lang.Runtime.loadLibrary0(Runtime.java:749)
        at java.lang.System.loadLibrary(System.java:820)
        at
gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:83)
        at Test.<init>(Test.java:9)
        at Test.main(Test.java:32)
sds at ipaq-pxa-2:~# 

Note that I'm copying the files to /usr/local/lib/ext/ along with the
RXTXcomm.jar file, purely to keep things separate from the rest of the
system while testing. The location of the .so files doesn't seem to have
any bearing on whether "java Test" will succeed or not. The contents of
this directory are:

sds at ipaq-pxa-2:~$ ls /usr/local/lib/ext/
RXTXcomm.jar              librxtxParallel-2.1-7.so  librxtxRS485.so
librxtxSerial-2.1-7.so
librxtxI2C-2.1-7.so       librxtxParallel.so        librxtxRaw-2.1-7.so
librxtxSerial.so
librxtxI2C.so             librxtxRS485-2.1-7.so     librxtxRaw.so
sds at ipaq-pxa-2:~$

Test.java fails on the first real line of code I'm using to test that
things are working, prior to real development, and was carefully pinched
from the web:
Enumeration portIdentifiers = CommPortIdentifier.getPortIdentifiers();


I assume that I've gotten my --host flag wrong way back up there at
the ./configure step. But if that's the case, what should I set it to?
Or am I missing something more obvious?


Cheers,
Stephen Strowes,
University of Glasgow.




From tjarvi at qbang.org  Tue Jun  6 13:39:41 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 6 Jun 2006 13:39:41 -0600 (MDT)
Subject: [Rxtx] Serial port code for OS X, future steps
In-Reply-To: <8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
	<CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
	<8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>
Message-ID: <Pine.LNX.4.61.0606061315070.9856@www>


>>
There are some very intrusive changes that should be done. Ie proper
mapping of /dev/tty <-> /dev/cu handling to correct behaviour of
CommPortOwnershipListener (http://java.sun.com/products/javacomm/
reference/api/index.html). I dont think this can be done with
patches. Hence I think, RXTX should be rewritten from scratch de-
unifying the native code base (and implementing thread safe code on
the Java side).
<<

This appears to be a very small amount of functionality for a total 
rewrite.  The port ownership only needs maybe 3 native calls if it is done 
with native calls at all.

Those features which are not part of the Unix standard(s) can be special 
cased.  I'm not sure /dev/cu is standard.  We can look.  I know linux 
deprecated /dev/cua years ago.

Thread safe Java code is not a platform specific issue.

--
Trent Jarvi
tjarvi at qbang.org


From sds at dcs.gla.ac.uk  Wed Jun  7 12:36:43 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Wed, 07 Jun 2006 19:36:43 +0100
Subject: [Rxtx] Expected RXTX behaviour?
In-Reply-To: <1149703900.30891.19.camel@addu>
References: <1149703900.30891.19.camel@addu>
Message-ID: <1149705403.30891.25.camel@addu>

Apologies, caught the problem. Had to append '\r' to the end of the AT
string. A non obvious but stupid mistake... :-)

Final quick question though: How might I stop the echoing of
outputStream data back into the inputStream? I still see the ATI
commands on the inputStream, along with the output from the device.


Cheers,
S.



On Wed, 2006-06-07 at 19:11 +0100, Stephen Strowes wrote:
> Hi,
> 
> I managed to get RXTX to compile for my iPAQ following my previous post
> to this list. Quick query though:
> 
> I want to be able to issue AT commands to a device, and interpret the
> responses. For this, I assume I do the following, in psuedo-form:
> 
> 	CommPortIdentifier.getPortIdentifiers();
> 	// find the correct device id
> 	serialPort= (SerialPort)portID.open("Test");
> 	// Set parameters and flow control
> 	outputStream= serialPort.getOutputStream();
> 	inputStream=  serialPort.getInputStream();
> 
> ... following this, I spawn a thread to respond to DATA_AVAILABLE events
> on serialPort with inputStream, and occasionally write and flush an
> "ATI" onto the outputStream. Nothing complex, I just want to see it
> work.
> 
> I would have expected inputStream to give the same information back from
> an "ATI" command as minicom provides, but instead inputStream only sees
> the "ATI" I put onto the outputStream.
> 
> Have I missed something?
> 
> 
> Cheers,
> S.
> 



From sds at dcs.gla.ac.uk  Wed Jun  7 12:11:40 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Wed, 07 Jun 2006 19:11:40 +0100
Subject: [Rxtx] Expected RXTX behaviour?
Message-ID: <1149703900.30891.19.camel@addu>

Hi,

I managed to get RXTX to compile for my iPAQ following my previous post
to this list. Quick query though:

I want to be able to issue AT commands to a device, and interpret the
responses. For this, I assume I do the following, in psuedo-form:

	CommPortIdentifier.getPortIdentifiers();
	// find the correct device id
	serialPort= (SerialPort)portID.open("Test");
	// Set parameters and flow control
	outputStream= serialPort.getOutputStream();
	inputStream=  serialPort.getInputStream();

... following this, I spawn a thread to respond to DATA_AVAILABLE events
on serialPort with inputStream, and occasionally write and flush an
"ATI" onto the outputStream. Nothing complex, I just want to see it
work.

I would have expected inputStream to give the same information back from
an "ATI" command as minicom provides, but instead inputStream only sees
the "ATI" I put onto the outputStream.

Have I missed something?


Cheers,
S.




From joachim at buechse.de  Wed Jun  7 09:02:13 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 7 Jun 2006 17:02:13 +0200
Subject: [Rxtx] Update of build process for OSX (XCode project)
Message-ID: <62EC47B1-46BD-4ECA-B9EC-C4061D147CDA@buechse.de>

With the help of Dmitry Markman and Brian Schilling I have updated  
(and largely simplifed) the XCode project file for Mac OS X.

Changes:
- compiles a universal binary library with intel=OSX10.4+, ppc=OSX10.2 
+ support
- compiles the Java sources into a JRE1.1 compatible, compressed jar.

Please test on your configuration, especially if you have computers  
running 10.2/10.3 or intel.

Best regards,
Joachim


From joachim at buechse.de  Wed Jun  7 14:36:37 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 7 Jun 2006 22:36:37 +0200
Subject: [Rxtx] Expected RXTX behaviour?
In-Reply-To: <1149705403.30891.25.camel@addu>
References: <1149703900.30891.19.camel@addu> <1149705403.30891.25.camel@addu>
Message-ID: <D3AD6EAF-27BB-455E-9697-86C1121920C3@buechse.de>

Echoing is a feature of the modem. Try ATE0 which works with most  
"rockwell" compatible modems.

Regards,
Joachim


On 07.06.2006, at 20:36, Stephen Strowes wrote:

> Apologies, caught the problem. Had to append '\r' to the end of the AT
> string. A non obvious but stupid mistake... :-)
>
> Final quick question though: How might I stop the echoing of
> outputStream data back into the inputStream? I still see the ATI
> commands on the inputStream, along with the output from the device.
>
>
> Cheers,
> S.
>
>
>
> On Wed, 2006-06-07 at 19:11 +0100, Stephen Strowes wrote:
>> Hi,
>>
>> I managed to get RXTX to compile for my iPAQ following my previous  
>> post
>> to this list. Quick query though:
>>
>> I want to be able to issue AT commands to a device, and interpret the
>> responses. For this, I assume I do the following, in psuedo-form:
>>
>> 	CommPortIdentifier.getPortIdentifiers();
>> 	// find the correct device id
>> 	serialPort= (SerialPort)portID.open("Test");
>> 	// Set parameters and flow control
>> 	outputStream= serialPort.getOutputStream();
>> 	inputStream=  serialPort.getInputStream();
>>
>> ... following this, I spawn a thread to respond to DATA_AVAILABLE  
>> events
>> on serialPort with inputStream, and occasionally write and flush an
>> "ATI" onto the outputStream. Nothing complex, I just want to see it
>> work.
>>
>> I would have expected inputStream to give the same information  
>> back from
>> an "ATI" command as minicom provides, but instead inputStream only  
>> sees
>> the "ATI" I put onto the outputStream.
>>
>> Have I missed something?
>>
>>
>> Cheers,
>> S.
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From g_petrini at yahoo.it  Thu Jun  8 01:41:58 2006
From: g_petrini at yahoo.it (Giacomo Petrini)
Date: Thu, 8 Jun 2006 09:41:58 +0200 (CEST)
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from FieldTalk
Message-ID: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>

Hi,
I'm evaluating the library for the modbus protocol
from FieldTalk
(http://www.modbusdriver.com/fieldtalk/.
I'm using J2SE 5.0 and RXTX 2.1 on win XP.
The problem is that the modbus lib has a method (the
openProtocol method, but maybe there are others) tha
throws the
javax.comm.UnsupportedCommOperationException.
Now, in RXTX 2.1 the namespace has changed in gnu.io,
so the modbus library doesn't work anymore (it look
for things in javax.comm). I've already sent an email
to fieldtalk to see if they are aware of the problem.
The solution should be to use JavaComm + RXTX 2.0. But
I've read somewhere that JavaComm 2.0 does not work
with Java 5.0 and JavaComm 3.0 does not work with RXTX
2.0 so I don't know what to do.

Any ideas?

Thanks Jack

PS: can you make a CC to my personal email
(g_petrini at yahoo.it) too please?

Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 


From rxtx at tapastda.co.uk  Thu Jun  8 02:27:57 2006
From: rxtx at tapastda.co.uk (rxtx@tapastda.co.uk)
Date: Thu, 08 Jun 2006 09:27:57 +0100
Subject: [Rxtx] Win XP and Infrared based serial port
Message-ID: <4487DF8D.5050807@tapastda.co.uk>

I'm attempting to use RXTX 2.1.7 on Win XP with J2SE 5.0 to communicate with a
GSM mobile using a COM port. A peculiarity that I've seen is that whilst I can
communicate successfully with a mobile which uses an infrared based COM port
using the SUN provided javax.comm (v2.0) I cannot use RXTX because it fails to
read anything from the port (i.e. read timeout always occurs returning zero bytes).

I assumed that this could be the result of flow control problems and thus I've
tried setting either software or hardware based flow control on the port however
this has no affect.

Can you suggest any other port configuration changes which might be required to
make such a port work with RXTX.

Thanks
Stu
-- 
Stuart
Tapastda Limited


From tjarvi at qbang.org  Thu Jun  8 05:17:12 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 8 Jun 2006 05:17:12 -0600 (MDT)
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from
	FieldTalk
In-Reply-To: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
References: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606080504480.9856@www>

On Thu, 8 Jun 2006, Giacomo Petrini wrote:

> Hi,
> I'm evaluating the library for the modbus protocol
> from FieldTalk
> (http://www.modbusdriver.com/fieldtalk/.
> I'm using J2SE 5.0 and RXTX 2.1 on win XP.
> The problem is that the modbus lib has a method (the
> openProtocol method, but maybe there are others) tha
> throws the
> javax.comm.UnsupportedCommOperationException.
> Now, in RXTX 2.1 the namespace has changed in gnu.io,
> so the modbus library doesn't work anymore (it look
> for things in javax.comm). I've already sent an email
> to fieldtalk to see if they are aware of the problem.
> The solution should be to use JavaComm + RXTX 2.0. But
> I've read somewhere that JavaComm 2.0 does not work
> with Java 5.0 and JavaComm 3.0 does not work with RXTX
> 2.0 so I don't know what to do.
>
> Any ideas?
>
> Thanks Jack
>


Hi Jack

There are plans for Sun to rerelease JavaComm 2.0 mentioned in the rxtx 
mail-list archives.  When this happens rxtx will release a current rxtx 
2.0 library that works with it.

There are no dates promised by either side but rxtx will do it as soon as 
possible after Sun's rerelease.  Just to give you a feel for the time 
frame, this started last year and no significant progress has been made. 
There have been friendly talks pointing towards solutions (rerelease 2.0) 
but that does not get your application working today.  rxtx is preparing 
for its second release in gnu.io since then.

--
Trent Jarvi
tjarvi at qbang.org




From jredman at ergotech.com  Thu Jun  8 08:47:23 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 08 Jun 2006 08:47:23 -0600
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from
	FieldTalk
In-Reply-To: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
References: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
Message-ID: <4488387B.6040903@ergotech.com>

You could always try a different library, eg.

http://sourceforge.net/projects/jamod

I've only used the slave side since we have our own implementation of 
Modbus Client (and a host of other PLC protocols).  However the client 
side seems to be pretty well supported and fairly widely used.  Since 
the source is there you could change to gnu.io.

I think I should take more of an interest in this issue.  We generally 
run 1.4.2 on Linux, but also have some J9 and old platforms that we 
support that are basically Personal Java.  5.0 on Linux has some 
horrible MDI bugs, to the point of being unusable.   Sounds as though we 
are going to have code compatibility problems across these platforms.

Jim


Giacomo Petrini wrote:
> Hi,
> I'm evaluating the library for the modbus protocol
> from FieldTalk
> (http://www.modbusdriver.com/fieldtalk/.
> I'm using J2SE 5.0 and RXTX 2.1 on win XP.
> The problem is that the modbus lib has a method (the
> openProtocol method, but maybe there are others) tha
> throws the
> javax.comm.UnsupportedCommOperationException.
> Now, in RXTX 2.1 the namespace has changed in gnu.io,
> so the modbus library doesn't work anymore (it look
> for things in javax.comm). I've already sent an email
> to fieldtalk to see if they are aware of the problem.
> The solution should be to use JavaComm + RXTX 2.0. But
> I've read somewhere that JavaComm 2.0 does not work
> with Java 5.0 and JavaComm 3.0 does not work with RXTX
> 2.0 so I don't know what to do.
> 
> Any ideas?
> 
> Thanks Jack
> 
> PS: can you make a CC to my personal email
> (g_petrini at yahoo.it) too please?
> 
> Chiacchiera con i tuoi amici in tempo reale! 
>  http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  8 18:17:23 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 08 Jun 2006 17:17:23 -0700
Subject: [Rxtx] rxtx access is denied error
Message-ID: <4488BE13.2050706@dupreeinc.com>

Hello,

I have been trying to replace the commapi from sun with rxtx for a 
project that communicates with a serial port that is a USB-Serial 
interface.  To be exact, I am using the FTDI VCP driver with one of 
their modules connected to a windows XP system.

I have the RXTX package working pretty well as long as nothing goes wrong.

If a user disconnects the USB port while my java application is running, 
my application goes into an endless loop with lots of messages in the  
errors stream  like the ones below:

    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(481):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.


I believe when this happens the COM port completely disappears and the 
rxtx driver has a heart attack.  Obviously, the user should not do this, 
but my application needs to ideally, correct the situation or as a worse 
case, terminate with a little dignity.  Currently, I have not figured 
out how to catch this error.

The closest I have come is to trap an exception to my input stream read  
that says "No error in readByte"  This error appears to be outside of 
the endless loop of the errors listed above.

Does anybody have an idea of how to identify and trap this error?  Any 
suggestions on how to gracefully recover from it would be greatly 
appreciated!

Thank you for your time,

Doug Thistlethwaite




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060608/9cfca302/attachment-0016.html

From tjarvi at qbang.org  Thu Jun  8 20:54:17 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 8 Jun 2006 20:54:17 -0600 (MDT)
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <4488BE13.2050706@dupreeinc.com>
References: <4488BE13.2050706@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606082022580.1323@www>

On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I have been trying to replace the commapi from sun with rxtx for a project 
> that communicates with a serial port that is a USB-Serial interface.  To be 
> exact, I am using the FTDI VCP driver with one of their modules connected to 
> a windows XP system.
>
> I have the RXTX package working pretty well as long as nothing goes wrong.
>
> If a user disconnects the USB port while my java application is running, my 
> application goes into an endless loop with lots of messages in the  errors 
> stream  like the ones below:
>
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(481):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>
>
> I believe when this happens the COM port completely disappears and the rxtx 
> driver has a heart attack.  Obviously, the user should not do this, but my 
> application needs to ideally, correct the situation or as a worse case, 
> terminate with a little dignity.  Currently, I have not figured out how to 
> catch this error.
>
> The closest I have come is to trap an exception to my input stream read  that 
> says "No error in readByte"  This error appears to be outside of the endless 
> loop of the errors listed above.
>
> Does anybody have an idea of how to identify and trap this error?  Any 
> suggestions on how to gracefully recover from it would be greatly 
> appreciated!
>

Hi Doug

Sadly I don't have a quick solution for you.

Termios has no knowlage about the JVM so it wont be throwing exceptions 
you can catch.

We can return error and set the error number to something reasonable that 
results in an exception.  The No Error message simply means we did not set 
an error number in termios.c.  Those are the line numbers in the code you 
see.  SerialImp.c realizes it errored but does not know much more yet. 
Everything touching the file descriptor is going to error after the port 
is gone presumably.

We don't currently have a plan in place for vanishing (or appearing) com 
ports.

Another example of what we need to think about is what happens if you 
start your application and then plug in the dongle?  Or what if you unplug 
and then plug it in again?

So in each of these three cases, what would the behavior of the (yet to 
be) correct implementation do?

How will the enumerated ports be handled during these changes?

There can also be hints from the OS that could be taken into 
consideration.

We can probably get some exceptions thrown that make sense and null the 
file descriptor when it happens to prevent io attempts.  That would be a 
crude way to let applications know something strange has happened.

Is anyone else tinkering with this problem?

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  9 01:31:29 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 9 Jun 2006 09:31:29 +0200
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <Pine.LNX.4.61.0606082022580.1323@www>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
Message-ID: <AC6EDDDD-0A64-401F-B16B-E484788CDF4A@buechse.de>

Hello Trent,

I am not tinkering with this on the Source Level - but I think it  
should work pretty much the same way as it currently does in OSX.  
When the port goes away you get an IOException thrown for any read/ 
write. It will no longer be in the list of ports from  
CommPortIdentifier.getPortIdentifiers(). When a port (re-)appears it  
is added to the list. It's up to the application to re-check the list  
from time to time.

On Windows you can't do much better then that, because the ports  
don't have useful names. Which USB "virtual com port" is on which  
COMx depends on the order the devices were added. So reconnecting to  
the same device may mean connecting to another port.

Regarding the exception thrown: it would be nice to use an  
IOException subclass but the Exception message should definetly be  
informative also as most applications may want to keep compatibility  
with javax.comm.

Regards,
Joachim


On 09.06.2006, at 04:54, Trent Jarvi wrote:

> On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:
>
>> Hello,
>>
>> I have been trying to replace the commapi from sun with rxtx for a  
>> project
>> that communicates with a serial port that is a USB-Serial  
>> interface.  To be
>> exact, I am using the FTDI VCP driver with one of their modules  
>> connected to
>> a windows XP system.
>>
>> I have the RXTX package working pretty well as long as nothing  
>> goes wrong.
>>
>> If a user disconnects the USB port while my java application is  
>> running, my
>> application goes into an endless loop with lots of messages in  
>> the  errors
>> stream  like the ones below:
>>
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (481):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>
>>
>> I believe when this happens the COM port completely disappears and  
>> the rxtx
>> driver has a heart attack.  Obviously, the user should not do  
>> this, but my
>> application needs to ideally, correct the situation or as a worse  
>> case,
>> terminate with a little dignity.  Currently, I have not figured  
>> out how to
>> catch this error.
>>
>> The closest I have come is to trap an exception to my input stream  
>> read  that
>> says "No error in readByte"  This error appears to be outside of  
>> the endless
>> loop of the errors listed above.
>>
>> Does anybody have an idea of how to identify and trap this error?   
>> Any
>> suggestions on how to gracefully recover from it would be greatly
>> appreciated!
>>
>
> Hi Doug
>
> Sadly I don't have a quick solution for you.
>
> Termios has no knowlage about the JVM so it wont be throwing  
> exceptions
> you can catch.
>
> We can return error and set the error number to something  
> reasonable that
> results in an exception.  The No Error message simply means we did  
> not set
> an error number in termios.c.  Those are the line numbers in the  
> code you
> see.  SerialImp.c realizes it errored but does not know much more yet.
> Everything touching the file descriptor is going to error after the  
> port
> is gone presumably.
>
> We don't currently have a plan in place for vanishing (or  
> appearing) com
> ports.
>
> Another example of what we need to think about is what happens if you
> start your application and then plug in the dongle?  Or what if you  
> unplug
> and then plug it in again?
>
> So in each of these three cases, what would the behavior of the  
> (yet to
> be) correct implementation do?
>
> How will the enumerated ports be handled during these changes?
>
> There can also be hints from the OS that could be taken into
> consideration.
>
> We can probably get some exceptions thrown that make sense and null  
> the
> file descriptor when it happens to prevent io attempts.  That would  
> be a
> crude way to let applications know something strange has happened.
>
> Is anyone else tinkering with this problem?
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From doug at dupreeinc.com  Fri Jun  9 13:09:58 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 09 Jun 2006 12:09:58 -0700
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <Pine.LNX.4.61.0606082022580.1323@www>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
Message-ID: <4489C786.9050504@dupreeinc.com>


Ideally, it would be nice if it would throw an exception and terminate 
the loop.  I am still trying to figure out how to detect the condition 
and recover form it in some form...  I am getting the "No error in 
readByte" exception in my serialEvent() method after an input stream 
read.  It appears to me that the only graceful recovery is to close the 
port and then reopen it when it becomes available.  I can pass the event 
up to the update method in my main frame, but I still can't close the 
port from within that thread.  Any suggestions on how to pass this event 
to a location where the port can be safely closed?

Re: Slow startup in windows XP
I have been looking into this a little closer and have found out the 
following:
System Windows XP Pro 3GHz dual core with 1GB RAM and NO parallel port.
Starting the SerialDemo included with the commapi using the rxtx instead 
of javax.comm takes 60 seconds.
Starting the SerialDemo using rxrx with the rxtxParallel.dll file 
removed takes about 20 seconds.
Modify initialize in RXRXCommDriver.java to not test the parallel ports 
takes less than 1 second.

It would be nice if the initialize routine could detect the presence of 
rxtxParallel.dll file and just skip the whole process if not present.  
Is there an easy way to check for the presence of this file without 
running the parallel port test?

Doug


 

Trent Jarvi wrote:

>On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:
>...
>  
>
>
>Hi Doug
>
>Sadly I don't have a quick solution for you.
>
>Termios has no knowlage about the JVM so it wont be throwing exceptions 
>you can catch.
>
>We can return error and set the error number to something reasonable that 
>results in an exception.  The No Error message simply means we did not set 
>an error number in termios.c.  Those are the line numbers in the code you 
>see.  SerialImp.c realizes it errored but does not know much more yet. 
>Everything touching the file descriptor is going to error after the port 
>is gone presumably.
>
>We don't currently have a plan in place for vanishing (or appearing) com 
>ports.
>
>Another example of what we need to think about is what happens if you 
>start your application and then plug in the dongle?  Or what if you unplug 
>and then plug it in again?
>
>So in each of these three cases, what would the behavior of the (yet to 
>be) correct implementation do?
>
>How will the enumerated ports be handled during these changes?
>
>There can also be hints from the OS that could be taken into 
>consideration.
>
>We can probably get some exceptions thrown that make sense and null the 
>file descriptor when it happens to prevent io attempts.  That would be a 
>crude way to let applications know something strange has happened.
>
>Is anyone else tinkering with this problem?
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060609/911ed787/attachment-0016.html

From Ugo.Landini at Sun.COM  Fri Jun  2 14:23:47 2006
From: Ugo.Landini at Sun.COM (Ugo Landini)
Date: Fri, 02 Jun 2006 22:23:47 +0200
Subject: [Rxtx] OSX 10.4.7 and usb
Message-ID: <44809E53.2070905@sun.com>

Hi, I have installed the library and the native libraries on OSX 10.4.7. 
Then I have run this simple code:

...
while (portList.hasMoreElements()) {
             portId = (CommPortIdentifier) portList.nextElement();
             System.out.println("-> " + portId.getName() + " Port Type:" 
+ portId.getPortType());
...

and the output is:

Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7

Ports found:
-> /dev/tty.Bluetooth-PDA-Sync Port Type:1
-> /dev/cu.Bluetooth-PDA-Sync Port Type:1
-> /dev/tty.Bluetooth-Modem Port Type:1
-> /dev/cu.Bluetooth-Modem Port Type:1

I can't see any USB ports... with javax.comm on linux I could see the 
/dev/ttyUSB stuff, but that's not the case with OSX. Any idea?

tia

uL


From tod at todbot.com  Sun Jun 11 12:04:37 2006
From: tod at todbot.com (Tod E. Kurt)
Date: Sun, 11 Jun 2006 11:04:37 -0700
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <44809E53.2070905@sun.com>
References: <44809E53.2070905@sun.com>
Message-ID: <E2EB14A1-20A7-4611-8F1A-E3D2ABE41F48@todbot.com>

A dumb question, but: do you have the USB serial adapters plugged  
in?  They only show up in /dev when plugged in.  Also, you can verify  
they exist independent of RXTX by doing something like "ls -l /dev/ 
cu.*".

On Jun 2, 2006, at 1:23 PM, Ugo Landini wrote:

> Hi, I have installed the library and the native libraries on OSX  
> 10.4.7.
> Then I have run this simple code:
>
> ...
> while (portList.hasMoreElements()) {
>              portId = (CommPortIdentifier) portList.nextElement();
>              System.out.println("-> " + portId.getName() + " Port  
> Type:"
> + portId.getPortType());
> ...
>
> and the output is:
>
> Experimental:  JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
>
> Ports found:
> -> /dev/tty.Bluetooth-PDA-Sync Port Type:1
> -> /dev/cu.Bluetooth-PDA-Sync Port Type:1
> -> /dev/tty.Bluetooth-Modem Port Type:1
> -> /dev/cu.Bluetooth-Modem Port Type:1
>
> I can't see any USB ports... with javax.comm on linux I could see the
> /dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>
> tia
>
> uL
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>



From lyon at docjava.com  Sun Jun 11 12:14:50 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Sun, 11 Jun 2006 14:14:50 -0400
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <44809E53.2070905@sun.com>
References: <44809E53.2070905@sun.com>
Message-ID: <p06020444c0b20de7d248@[192.168.1.152]>

>Hi Ugo,

Do you have any USB serial ports (like the keyspan 19-HS) plugged
into the mac?
Thanks!
  - DL


>Hi, I have installed the library and the native libraries on OSX 10.4.7.
>Then I have run this simple code:
>
>...
>while (portList.hasMoreElements()) {
>              portId = (CommPortIdentifier) portList.nextElement();
>              System.out.println("-> " + portId.getName() + " Port Type:"
>+ portId.getPortType());
>...
>
>and the output is:
>
>Experimental:  JNI_OnLoad called.
>Stable Library
>=========================================
>Native lib Version = RXTX-2.1-7
>Java lib Version   = RXTX-2.1-7
>
>Ports found:
>-> /dev/tty.Bluetooth-PDA-Sync Port Type:1
>-> /dev/cu.Bluetooth-PDA-Sync Port Type:1
>-> /dev/tty.Bluetooth-Modem Port Type:1
>-> /dev/cu.Bluetooth-Modem Port Type:1
>
>I can't see any USB ports... with javax.comm on linux I could see the
>/dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>
>tia
>
>uL
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx



From dmarkman at mac.com  Sun Jun 11 14:30:27 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Sun, 11 Jun 2006 16:30:27 -0400
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <p06020444c0b20de7d248@[192.168.1.152]>
References: <44809E53.2070905@sun.com> <p06020444c0b20de7d248@[192.168.1.152]>
Message-ID: <B9C1606B-4339-4564-A175-FE83DFFA7D76@mac.com>

afaik
10.4.7 wasn't released yet
it will soon, no doubts


On Jun 11, 2006, at 2:14 PM, Dr. Douglas Lyon wrote:

>> Hi Ugo,
>
> Do you have any USB serial ports (like the keyspan 19-HS) plugged
> into the mac?
> Thanks!
>   - DL
>
>
>> Hi, I have installed the library and the native libraries on OSX  
>> 10.4.7.
>> Then I have run this simple code:
>>
>> ...
>> while (portList.hasMoreElements()) {
>>              portId = (CommPortIdentifier) portList.nextElement();
>>              System.out.println("-> " + portId.getName() + " Port  
>> Type:"
>> + portId.getPortType());
>> ...
>>
>> and the output is:
>>
>> Experimental:  JNI_OnLoad called.
>> Stable Library
>> =========================================
>> Native lib Version = RXTX-2.1-7
>> Java lib Version   = RXTX-2.1-7
>>
>> Ports found:
>> -> /dev/tty.Bluetooth-PDA-Sync Port Type:1
>> -> /dev/cu.Bluetooth-PDA-Sync Port Type:1
>> -> /dev/tty.Bluetooth-Modem Port Type:1
>> -> /dev/cu.Bluetooth-Modem Port Type:1
>>
>> I can't see any USB ports... with javax.comm on linux I could see the
>> /dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>>
>> tia
>>
>> uL
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman



From tjarvi at qbang.org  Sun Jun 11 18:52:59 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 11 Jun 2006 18:52:59 -0600 (MDT)
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <4489C786.9050504@dupreeinc.com>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
	<4489C786.9050504@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606111845430.7274@www>

On Fri, 9 Jun 2006, Doug Thistlethwaite wrote:

>
> Ideally, it would be nice if it would throw an exception and terminate the 
> loop.  I am still trying to figure out how to detect the condition and 
> recover form it in some form...  I am getting the "No error in readByte" 
> exception in my serialEvent() method after an input stream read.  It appears 
> to me that the only graceful recovery is to close the port and then reopen it 
> when it becomes available.  I can pass the event up to the update method in 
> my main frame, but I still can't close the port from within that thread.  Any 
> suggestions on how to pass this event to a location where the port can be 
> safely closed?
>

I've gone through and cleaned up the termios.c layer.  I need to get to a 
windows machine with a USB dongle and see where the ioctl() is being 
called.  Probably the eventLoop.  But all of the ioctls should probably 
result in an IOException during this condition.

I'll probably finish this up Monday night when I can borrow a USB 
dongle.

There is no point in putting the code into CVS yet.  If you are tinkering 
I can mail the patch.  I think we will want to make a couple fixes in 
SerialImp.c to handle errors before it's ready.

--
Trent Jarvi
tjarvi at qbang.org



From bob_tai2001 at yahoo.com  Mon Jun 12 09:42:14 2006
From: bob_tai2001 at yahoo.com (Bob Tai)
Date: Mon, 12 Jun 2006 08:42:14 -0700 (PDT)
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to RXTX
	again
Message-ID: <20060612154214.58219.qmail@web32804.mail.mud.yahoo.com>


thank you Paul, Joachim, Trent and everyone try to
workout the java comm and Rxtx situation.  At least
now I have something that is solid enough to make my
decision.  

thank you,
     Bob

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From Ralph.Buchfelder at gmx.net  Mon Jun 12 15:30:20 2006
From: Ralph.Buchfelder at gmx.net (Ralph Buchfelder)
Date: Mon, 12 Jun 2006 23:30:20 +0200
Subject: [Rxtx] rxtx binaries or porting to XSCALE Windows Mobile 2003 / 2005
Message-ID: <448DDCEC.7090506@gmx.net>

dear group,

i have been carefully reading your homepage, wiki and archives
but there seems to be no detailled information on porting to Windows 
Mobile/CE.

as far as i understood from the 'porting' section you can do porting to 
winCE. but how? do i only need to obtain the sourcecode (which one?) and 
compile this in Microsoft eMbedded Visual C++ for ARM/Xscale?
Any other ways?


unfortunately i must admit that i do have little linux skills but i have 
made my way through gcc and makefiles. right now i need to implement com 
  communication in a J2ME application and found your website as >the< 
solution.

best regards
Ralph Buchfelder

University of Regensburg
Department of Geography

PS: i dont care about Javacomm compliancy (ie. 2.0 or 2.1) - i just need 
a working serial port API in IBM J9 VM.


From paul.klissner at sun.com  Wed Jun 14 18:12:58 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Wed, 14 Jun 2006 17:12:58 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
Message-ID: <4490A60A.9090305@sun.com>

Hello RxTx community,

I finally think I have a compromise in place that will stand in the gap.

If you go to http://www.sun.com and search for javax.comm, you'll
get taken to a download page, where now users can get a copy of the
comm.jar file out of 2.0.3, along with just a license and a README.

I trust this will suffice until such time as RxTx decided to implement
their own java classes or we can get a JSR going to mitigate some
of the problems (the readme in the comm.jar 2.0.3 zip file
contains my thoughts on that).

Thanks,
Paul



From tjarvi at qbang.org  Wed Jun 14 21:15:35 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 14 Jun 2006 21:15:35 -0600 (MDT)
Subject: [Rxtx] rxtx-2.0-7 (final) src is in CVS
Message-ID: <Pine.LNX.4.61.0606142100500.2742@www>


I wasn't expecting to be working on rxtx 2.0 tonight :)

Thanks go out to Paul Klissner for his work in making the coming release 
of rxtx-2.0-7 possible for users that require package javax.comm on many 
platforms.

Most people know that rxtx 2.0 is for use with Sun's CommAPI 2.0 for 
Solaris or the Generic CommAPI 2.0-3 available for download at Sun.  If 
you need javax.comm packages on many platforms, you are probably 
interested.  If you use rxtx 2.1 in package gnu.io, then you are not going 
to care much.

I've tried to update the rxtx 2.0 src directory in preparation for 
rxtx-2.0-7 (final).  Linux should compile.  Windows will compile if you 
generate your own .def files (I'll generate these tomorrow).  If you have 
some time to do basic testing of the source, I'd appreciate it.  The 
source should be good but you may find classes not found.  This source is 
a backport from rxtx 2.1.

I wanted to get things started so anyone interested on Mac OS X could get 
a head start.

All of this is in CVS.  http://www.rxtx.org/cvs.html

I suspect we will have binaries for testing in a couple days if you are 
unable to compile.   Consider this a smoke test.

--
Trent Jarvi
tjarvi at qbang.org


From legolas.w at gmail.com  Wed Jun 14 22:04:28 2006
From: legolas.w at gmail.com (Legolas Woodland)
Date: Wed, 14 Jun 2006 21:04:28 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <4490A60A.9090305@sun.com>
References: <4490A60A.9090305@sun.com>
Message-ID: <87ee9b170606142104p745fcef0vea622fbc8f528bfc@mail.gmail.com>

is there anything new in this version of javax.comm ?
thanks


On 6/14/06, Paul Klissner <paul.klissner at sun.com> wrote:
>
> Hello RxTx community,
>
> I finally think I have a compromise in place that will stand in the gap.
>
> If you go to http://www.sun.com and search for javax.comm, you'll
> get taken to a download page, where now users can get a copy of the
> comm.jar file out of 2.0.3, along with just a license and a README.
>
> I trust this will suffice until such time as RxTx decided to implement
> their own java classes or we can get a JSR going to mitigate some
> of the problems (the readme in the comm.jar 2.0.3 zip file
> contains my thoughts on that).
>
> Thanks,
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060614/5ff4dfbc/attachment-0016.html

From joachim at buechse.de  Thu Jun 15 07:22:48 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 15 Jun 2006 15:22:48 +0200
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
Message-ID: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>

Good day!

Some of my users report problems using RXTX 2.1.7 on Windows98 to  
communicate with an FTDI FT245BM chip (using their latest VCP  
driver). Either no ports are being shown (ie returned form  
CommPortIdentifier.getPortIdentifiers()) or the transfers fail.

Did anyone run into similar Problems with Win98??

Best regards,
Joachim



From ajmas at sympatico.ca  Thu Jun 15 08:12:28 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Thu, 15 Jun 2006 10:12:28 -0400
Subject: [Rxtx] API change question
Message-ID: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

How closely do you follow the Java Communication API spec? The reason I ask is because I would be interested in augmenting the CommPortIdentifier class to include a getDisplayName() method. By default it would return the same value as getName(), but would provide the possibility of displaying a 'user friendly' name, for platforms where the display name is not the same as the device name. An example of this is on MacOS X, where currently the names seem to be of the form /dev/cu.* and /dev/tty.*, yet what the expects to see is simply the part after the full-stop. Although I could move this logic into the Java code, it would be nice to see it transparent to the Java code.

Andre




From ajmas at sympatico.ca  Thu Jun 15 08:16:22 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Thu, 15 Jun 2006 10:16:22 -0400
Subject: [Rxtx] Package to use
Message-ID: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

While the Java API spec refers to javax.comm, I see that only gnu.io is provide by the rxtx project. Should our projects refer to the gnu.io package or the javax.comm API?

Andre



From joachim at buechse.de  Thu Jun 15 08:45:05 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 15 Jun 2006 16:45:05 +0200
Subject: [Rxtx] API change question
In-Reply-To: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>

Hello Andre,

the /dev/cu and /dev/tty have different semantics on OS X. It is much  
more than a simply naming issue to unify them, see my recent mail to  
the list...

Best regards,
Joachim


On 15.06.2006, at 16:12, Andre-John Mas wrote:

> Hi,
>
> How closely do you follow the Java Communication API spec? The  
> reason I ask is because I would be interested in augmenting the  
> CommPortIdentifier class to include a getDisplayName() method. By  
> default it would return the same value as getName(), but would  
> provide the possibility of displaying a 'user friendly' name, for  
> platforms where the display name is not the same as the device  
> name. An example of this is on MacOS X, where currently the names  
> seem to be of the form /dev/cu.* and /dev/tty.*, yet what the  
> expects to see is simply the part after the full-stop. Although I  
> could move this logic into the Java code, it would be nice to see  
> it transparent to the Java code.
>
> Andre
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From lyon at docjava.com  Thu Jun 15 10:16:29 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Thu, 15 Jun 2006 12:16:29 -0400
Subject: [Rxtx] cu.modem != /dev/ttya on mac.
In-Reply-To: <763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
	<763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>
Message-ID: <p0602046cc0b7378a95b0@[192.168.1.152]>

>Hi All,

I think that Joachim is correct. For the longest time,
I have been trying to figure out how to direct dial using
the cu.modem on the mac under os x.

As a less-than-optimal approach to auto-dialing, I have used
a keyspan USB 19HS adapter, along with an external modem, to
obtain the dialing feature.

Ideally, it would be better to dial with the built-in modem...but that did not
always seem to work, for some reason. Have others had some experience with
using the built in modem for dialing on the mac?

Thanks!
  - Doug


>Hello Andre,
>
>the /dev/cu and /dev/tty have different semantics on OS X. It is much?
>more than a simply naming issue to unify them, see my recent mail to?
>the list...
>
>Best regards,
>Joachim
>



From doug at dupreeinc.com  Thu Jun 15 14:52:50 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 15 Jun 2006 13:52:50 -0700
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
In-Reply-To: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
References: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
Message-ID: <4491C8A2.8090108@dupreeinc.com>

Hi Joachim,

I have been doing a lot with the new FTDI driver with win XP and have 
not had that particular problem.  I did notice that the new driver 
(dated May19th, 2006) is only for XP, Server 2003, and 2000.  Are they 
trying to use the 2.00.00 drivers or the old 1.09.06 version.  I am 
using a FT232R based module, but it uses the same drivers and I assume 
it would have the same problems.  Let me know which driver they are 
using and I can load up a 98 system here and see if  I can duplicate the 
problem.

Doug

Joachim Buechse wrote:

>Good day!
>
>Some of my users report problems using RXTX 2.1.7 on Windows98 to  
>communicate with an FTDI FT245BM chip (using their latest VCP  
>driver). Either no ports are being shown (ie returned form  
>CommPortIdentifier.getPortIdentifiers()) or the transfers fail.
>
>Did anyone run into similar Problems with Win98??
>
>Best regards,
>Joachim
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From matthewhepp at yahoo.com  Thu Jun 15 17:34:47 2006
From: matthewhepp at yahoo.com (Matthew Hepp)
Date: Thu, 15 Jun 2006 16:34:47 -0700 (PDT)
Subject: [Rxtx] Wither the XCode project?
Message-ID: <20060615233447.48064.qmail@web50311.mail.yahoo.com>

Either I don't know how to properly use CVS (entirely possibl), or the XCode
project is not making through the update properly. Doing a "cvs update" against
2.1-7 creates an XCode folder in MACOSX_IDE, and therein a
LibSerialUniversal.xcodeproj, but trying to open it yields a "Unable to Open
Project - Project rxtx-devel/MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj
cannot be opened because it is missing its project.pbxproj file" error. Showing
package contents reveals just the cvs-related files. Perhaps this is why
previous xcode projects have been saved as an sit.hqx - to retain the resource
fork?

Can someone point me in the right direction?

Thanks,

Matt

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Thu Jun 15 19:53:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 19:53:06 -0600 (MDT)
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
In-Reply-To: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
References: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
Message-ID: <Pine.LNX.4.61.0606151944070.23137@www>

On Thu, 15 Jun 2006, Joachim Buechse wrote:

> Good day!
>
> Some of my users report problems using RXTX 2.1.7 on Windows98 to
> communicate with an FTDI FT245BM chip (using their latest VCP
> driver). Either no ports are being shown (ie returned form
> CommPortIdentifier.getPortIdentifiers()) or the transfers fail.
>
> Did anyone run into similar Problems with Win98??
>

Hi Joachim

It has been a long time since I've tested win98.  I know rxtx-2.1-7pre16 
did get testing on win98 with ~jdk 1.3 though.  I wonder if jdks are still 
tested on that platform.

With win98 you usually have older boxes.  They can be short on CPU and 
memory.  Enumeration should work but I could picture runtime performance 
issues on win98.

The enumeration problems could result from other copies of your 
application if various states of decay still holding onto the port.  When 
things go wrong, people also like to open other terminal software to see 
whats going on which can interfere.  You can't open a windows port with 
two apps.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Thu Jun 15 20:08:53 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 20:08:53 -0600 (MDT)
Subject: [Rxtx] API change question
In-Reply-To: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606151954270.23137@www>

On Thu, 15 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> How closely do you follow the Java Communication API spec?

I can explain how this worked in the past.  How we do it in the future is 
open for discussion.

In the past we have tried to follow it as close as possible in gnu.io 
(rxtx 2.1).  We have added extensions but try to discourage their use. 
The extensions are clearly marked as such in the source code and javadocs.

rxtx 2.0 was intended to be a strict implementation of part of the spec. 
We let Sun's interfaces decide what methods can be called. There are 
differences not covered by the spec such as default values.  Thats not 
intentional but rather hard to avoid.

--
Trent Jarvi
tjarvi at qbang.org





From tjarvi at qbang.org  Thu Jun 15 21:09:11 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 21:09:11 -0600 (MDT)
Subject: [Rxtx] Package to use
In-Reply-To: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606152026120.23137@www>

On Thu, 15 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> While the Java API spec refers to javax.comm, I see that only gnu.io is 
> provide by the rxtx project. Should our projects refer to the gnu.io 
> package or the javax.comm API?
>

Hi Andre

Lets see if I can give a fair and balanced answer to that.

If you are starting a new project and want to use RXTX, I would recommend 
using gnu.io.  The community support for gnu.io will not be going away 
anytime soon.  You can switch between gnu.io (2.1) and javax.comm (2.0) 
fairly easily.  They are not intended to be incompatible.  You just change 
package names and libs.

You can also consider the combination of rxtx 2.0 with Sun's commapi 
2.0-3.  This is considered a stop-gap measure by Sun for previous users of 
that combination.  Together rxtx 2.0 and Sun CommAPI 2.0 work in namespace 
javax.comm for programmers.

Finally, you can opt to just use Sun's oferrings in CommAPI 3.0 without 
rxtx.  That would be in namespace javax.comm also.  CommAPI 3.0 may be 
of more interest to you if you are looking at POS with Sun computers. 
Rxtx does not currently support the changes in CommAPI 3.0 or have firm 
plans to do so.  That does not mean we wouldn't implement them.  It just 
means nobody has contributed code yet.

You can't combine rxtx with CommAPI 3.0 for technical reasons that wont 
likely be fixed soon.

It's up to you as far as what you use.  We like to provide the freedom so 
you can choose.  Realistically, we will be supporting gnu.io mainly 
because we have some control over that name space and can support it.

Things may happen in the future that enable rxtx to provide more support 
in the javax namespace but that has not happened yet.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun 16 00:33:06 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 08:33:06 +0200
Subject: [Rxtx] Wither the XCode project?
In-Reply-To: <20060615233447.48064.qmail@web50311.mail.yahoo.com>
References: <20060615233447.48064.qmail@web50311.mail.yahoo.com>
Message-ID: <D30D660F-A49B-464E-AE4C-6B4563893682@buechse.de>

Hello Matthew,

could you please send me the contents of your

   rxtx-devel/CVS
   rxtx-devel/MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj/CVS

directories as a zip to my personal email address. This should  
indicate why the file is not checked out. I can see that it exists on  
the correct branch in the repository, so something must have gone  
wrong during the "cvs update"...

Best regards,
Joachim

On 16.06.2006, at 01:34, Matthew Hepp wrote:

> Either I don't know how to properly use CVS (entirely possibl), or  
> the XCode
> project is not making through the update properly. Doing a "cvs  
> update" against
> 2.1-7 creates an XCode folder in MACOSX_IDE, and therein a
> LibSerialUniversal.xcodeproj, but trying to open it yields a  
> "Unable to Open
> Project - Project rxtx-devel/MACOSX_IDE/XCode/ 
> LibSerialUniversal.xcodeproj
> cannot be opened because it is missing its project.pbxproj file"  
> error. Showing
> package contents reveals just the cvs-related files. Perhaps this  
> is why
> previous xcode projects have been saved as an sit.hqx - to retain  
> the resource
> fork?
>
> Can someone point me in the right direction?



From joachim at buechse.de  Fri Jun 16 10:41:20 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 18:41:20 +0200
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <p06230903c0b88613dca6@[10.0.1.7]>
References: <p06230903c0b88613dca6@[10.0.1.7]>
Message-ID: <03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>

Hello Bob,

until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was  
behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if  
Trent has migrated all recent changes from 2.1 to 2.0.

I have added the XCode project and updated documentation only to the  
gnu.io branch. Once the 2.0 implementation is up to date I will copy  
over the documentation/build files make them work.

Best regards,
Joachim

On 16.06.2006, at 18:07, Bob Jacobsen wrote:

> I'm one of the developers for the JMRI project, which provides  
> model railroad software in Java.  We've been using RXTX to provide  
> serial port access on MacOS X and Linux; we use the old javax.comm  
> 2.0 on Windows, OS/2 and Solaris.  Because of that, we need to stay  
> with RXTX 2.0, not 2.1
>
> We've been using the 2.0-pre17 installer for a long time, but it's  
> not compatible with Intel macs.
>
> Can you point me to where I can find the right files for RXTX 2.0  
> to package with the program?
>
> The current situation is confusing to me.  I've been pointed to  
> recent 2.1 versions (but we need the javax.comm names), to an even  
> older installer, etc.  I've been reading that some versions require  
> an installer, and others don't, but I haven't been able to figure  
> out which (if any) of those are where in CVS.
>
> I'd really appreciate a clear statement of what files to use and  
> what to do with them that I can pass on to our users.
>
> I'm more than happy to put files in the local classpath, have users  
> run an installer, or anything else.  Whatever is easiest for you.
>
> Thanks!  I really appreciate all that you do to keep RXTX working.
>
> Bob
> -- 
> Bob Jacobsen +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG



From joachim at buechse.de  Fri Jun 16 09:59:28 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 17:59:28 +0200
Subject: [Rxtx] Wither the XCode project?
In-Reply-To: <20060616150240.49464.qmail@web50309.mail.yahoo.com>
References: <20060616150240.49464.qmail@web50309.mail.yahoo.com>
Message-ID: <D9935E05-2B83-488D-86DD-42599E229052@buechse.de>

Hello Matthew,

you have checked out the trunk (which is the 2.0.7 javax.comm.xxx  
release). For rxtx-2.1.7 (gnu.io.xxx release) you need to check out  
the branch

      commapi-0-0-1

The easiest way to do this is to download the rxtx src archive,  
unpack it and then do a cvs up inside the decompressed tree.  
Optionally you could do a

      cvs co -r commapi-0-0-1

but this will take much longer!

Best regards,
Joachim

When you do a cvs status it will show the sticky tag.

41:~/jdevelop/rxtx-2.1-7r2 joachim$ cvs status README.OSX
===================================================================
File: README.OSX        Status: Up-to-date

    Working revision:    1.1.2.1
    Repository revision: 1.1.2.1 /usr/local/cvsroot/rxtx-devel/Attic/ 
README.OSX,v
    Sticky Tag:          commapi-0-0-1 (branch: 1.1.2)
    Sticky Date:         (none)
    Sticky Options:      (none)




On 16.06.2006, at 17:02, Matthew Hepp wrote:

> %cvs status README.MACOSX
> ===================================================================
> File: README.MACOSX     Status: Up-to-date
>
>    Working revision:    1.1
>    Repository revision: 1.1     /usr/local/cvsroot/rxtx-devel/ 
> README.MACOSX,v
>    Sticky Tag:          (none)
>    Sticky Date:         (none)
>    Sticky Options:      (none)



From tjarvi at qbang.org  Fri Jun 16 16:31:18 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Fri, 16 Jun 2006 16:31:18 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
Message-ID: <Pine.LNX.4.61.0606161630030.14139@www>

On Fri, 16 Jun 2006, Joachim Buechse wrote:

> Hello Bob,
>
> until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was
> behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if
> Trent has migrated all recent changes from 2.1 to 2.0.
>

The src/ directory and configure.in/configure files should be fine.  I 
have not touched the Mac OS X directories.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sat Jun 17 02:39:55 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sat, 17 Jun 2006 10:39:55 +0200
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <Pine.LNX.4.61.0606161630030.14139@www>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
Message-ID: <350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>

Hello Trent,

apparently the IOEXCL changes have not made it into 2.0. I will add  
them to achieve a minimal diff between 2.0 and 2.1.

One other thing that bugs me for a while...

Shouldn't we replace "if !defined(TIOCSERGETLSR) && !defined(WIN32)"  
by a definition of its own "if defined(DRAINTHREAD)"? I think this  
would make the code clearer for people starting to read it.

Regards,
Joachim


On 17.06.2006, at 00:31, Trent Jarvi wrote:

> On Fri, 16 Jun 2006, Joachim Buechse wrote:
>
>> Hello Bob,
>>
>> until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was
>> behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if
>> Trent has migrated all recent changes from 2.1 to 2.0.
>>
>
> The src/ directory and configure.in/configure files should be fine.  I
> have not touched the Mac OS X directories.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From tropicsu at hotmail.com  Sat Jun 17 09:32:48 2006
From: tropicsu at hotmail.com (Yoke K)
Date: Sat, 17 Jun 2006 15:32:48 +0000
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
Message-ID: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>

Hi,

I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to work with 
MAC OS X.
I am using iTegno 3000 - USB GPRS Modem.

Files in /dev and a symbolic link as follows:

crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 -> tty.usbserial

In my SendMessage.java, I have this line:
CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");

Appreciate any help ?

- Jon


Errors as follows:

>>INFO: SMSLib API for Java / v1.2.2
>>INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>INFO: JRE Version: 1.5.0_06
>>INFO: JRE Impl Version: 1.5.0_06-64
>>INFO: O/S: Mac OS X / ppc / 10.4.6
>>INFO: Using Wavecom (Generic) AT handler.

SendMessage(): Send a message.
  Using SMSLib API for Java v1.2.2

Connecting ..... :
>>INFO: CSerialDriver(): Connecting...
Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
>>INFO: CSerialDriver(): Disconnecting...
gnu.io.NoSuchPortException
        at 
gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:218)
        at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
        at org.smslib.CService.connect(CService.java:197)
        at SendMessage.main(SendMessage.java:38)

_________________________________________________________________
Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/



From tjarvi at qbang.org  Sat Jun 17 10:12:30 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 10:12:30 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
	<350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
Message-ID: <Pine.LNX.4.61.0606171010060.14139@www>

On Sat, 17 Jun 2006, Joachim Buechse wrote:

> Hello Trent,
>
> apparently the IOEXCL changes have not made it into 2.0. I will add
> them to achieve a minimal diff between 2.0 and 2.1.
>

Hi Joachim

As I recall the IOEXCL change was after 2.1-7.  I was just syncing with 
2.1-7.  We can release 2.1-8 and 2.0-8 with the same changes.

> One other thing that bugs me for a while...
>
> Shouldn't we replace "if !defined(TIOCSERGETLSR) && !defined(WIN32)"
> by a definition of its own "if defined(DRAINTHREAD)"? I think this
> would make the code clearer for people starting to read it.
>


Sure.  We can do that for -8.  The TIOCSERGETLSR code should be a special 
case not the expected.  I think only Linux uses it.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Sat Jun 17 10:48:21 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 10:48:21 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <Pine.LNX.4.61.0606171010060.14139@www>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
	<350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
	<Pine.LNX.4.61.0606171010060.14139@www>
Message-ID: <Pine.LNX.4.61.0606171047310.14139@www>

On Sat, 17 Jun 2006, Trent Jarvi wrote:

> On Sat, 17 Jun 2006, Joachim Buechse wrote:
>
>> Hello Trent,
>>
>> apparently the IOEXCL changes have not made it into 2.0. I will add
>> them to achieve a minimal diff between 2.0 and 2.1.
>>
>
> Hi Joachim
>
> As I recall the IOEXCL change was after 2.1-7.  I was just syncing with
> 2.1-7.  We can release 2.1-8 and 2.0-8 with the same changes.
>

We could just move to 2.1-8 and 2.0-8.

--
Trent Jarvi
tjarvi at qbang.org


From brian.t.lamb at gmail.com  Tue Jun 13 13:54:13 2006
From: brian.t.lamb at gmail.com (Brian Lamb)
Date: Tue, 13 Jun 2006 15:54:13 -0400
Subject: [Rxtx] Windows XP Installation
Message-ID: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>

I've not installed Java packages on Windows before and am unsure how to
proceed. All the documentation I've seen provides detailed instructions on
how to install on Linux or Solaris. I was wondering how to install rxtx on
Windows XP.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060613/6f68cd5c/attachment-0016.html

From tjarvi at qbang.org  Sat Jun 17 13:57:03 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 13:57:03 -0600 (MDT)
Subject: [Rxtx] Windows XP Installation
In-Reply-To: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>
References: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0606171356120.14139@www>

On Tue, 13 Jun 2006, Brian Lamb wrote:

> I've not installed Java packages on Windows before and am unsure how to
> proceed. All the documentation I've seen provides detailed instructions on
> how to install on Linux or Solaris. I was wondering how to install rxtx on
> Windows XP.
>

Hi Brian

Which rxtx version are you trying to install?

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sun Jun 18 10:41:44 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sun, 18 Jun 2006 18:41:44 +0200
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
References: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
Message-ID: <8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>

Hello Jon,

 From OSX's standpoint a symbolic link is not a device (as far as I  
know). What stops you from using tty.usbserial? Did you try hard- 
linking?

Regards,
Joachim

On 17.06.2006, at 17:32, Yoke K wrote:
> Hi,
>
> I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to  
> work with
> MAC OS X.
> I am using iTegno 3000 - USB GPRS Modem.
>
> Files in /dev and a symbolic link as follows:
>
> crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
> crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
> lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->  
> tty.usbserial
>
> In my SendMessage.java, I have this line:
> CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
>
> Appreciate any help ?
>
> - Jon
>
>
> Errors as follows:
>
>>> INFO: SMSLib API for Java / v1.2.2
>>> INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>> INFO: JRE Version: 1.5.0_06
>>> INFO: JRE Impl Version: 1.5.0_06-64
>>> INFO: O/S: Mac OS X / ppc / 10.4.6
>>> INFO: Using Wavecom (Generic) AT handler.
>
> SendMessage(): Send a message.
>   Using SMSLib API for Java v1.2.2
>
> Connecting ..... :
>>> INFO: CSerialDriver(): Connecting...
> Experimental:  JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
>>> INFO: CSerialDriver(): Disconnecting...
> gnu.io.NoSuchPortException
>         at
> gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java: 
> 218)
>         at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
>         at org.smslib.CService.connect(CService.java:197)
>         at SendMessage.main(SendMessage.java:38)
>
> _________________________________________________________________
> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Sun Jun 18 10:56:55 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 12:56:55 -0400
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>
References: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
	<8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>
Message-ID: <7B6834E3-F41D-46B6-B979-55466BC73859@sympatico.ca>

Have you been able to get any other software to talk with your
modem? What port is it using? Have tried using the cu.usbserial
instead?

Andre

On 18-Jun-06, at 12:41 , Joachim Buechse wrote:

> Hello Jon,
>
>  From OSX's standpoint a symbolic link is not a device (as far as I
> know). What stops you from using tty.usbserial? Did you try hard-
> linking?
>
> Regards,
> Joachim
>
> On 17.06.2006, at 17:32, Yoke K wrote:
>> Hi,
>>
>> I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to
>> work with
>> MAC OS X.
>> I am using iTegno 3000 - USB GPRS Modem.
>>
>> Files in /dev and a symbolic link as follows:
>>
>> crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
>> crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
>> lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->
>> tty.usbserial
>>
>> In my SendMessage.java, I have this line:
>> CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
>>
>> Appreciate any help ?
>>
>> - Jon
>>
>>
>> Errors as follows:
>>
>>>> INFO: SMSLib API for Java / v1.2.2
>>>> INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>>> INFO: JRE Version: 1.5.0_06
>>>> INFO: JRE Impl Version: 1.5.0_06-64
>>>> INFO: O/S: Mac OS X / ppc / 10.4.6
>>>> INFO: Using Wavecom (Generic) AT handler.
>>
>> SendMessage(): Send a message.
>>   Using SMSLib API for Java v1.2.2
>>
>> Connecting ..... :
>>>> INFO: CSerialDriver(): Connecting...
>> Experimental:  JNI_OnLoad called.
>> Stable Library
>> =========================================
>> Native lib Version = RXTX-2.1-7
>> Java lib Version   = RXTX-2.1-7
>>>> INFO: CSerialDriver(): Disconnecting...
>> gnu.io.NoSuchPortException
>>         at
>> gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:
>> 218)
>>         at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
>>         at org.smslib.CService.connect(CService.java:197)
>>         at SendMessage.main(SendMessage.java:38)
>>
>> _________________________________________________________________
>> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Sun Jun 18 17:33:08 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 19:33:08 -0400
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
Message-ID: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>

Hi,

I am have a program that I wrote in Java to communicate with a  
Bluetooth GPS device. I am
trying to get this working on my Mac, but I keep getting told that:

gnu.io.PortInUseException: Unknown Application

but

portIdentifier.isCurrentlyOwned()

returns false and when I do lsof on the device I am trying to connect  
to, I see no application
using it. As the same time if I go to the command line and use  
minicom I have no issues. The
exception happens with this call:

CommPort commPort = portIdentifier.open(null,0);

Any suggestions?

Andre


From ajmas at sympatico.ca  Sun Jun 18 17:45:11 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 19:45:11 -0400
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
Message-ID: <30245B30-682D-4EAE-8084-8227B719F10D@sympatico.ca>

BTW My code snippet is:

     private InputStream connectToSerial () throws IOException,  
Exception
     {
         InputStream in = null;

         Enumeration portEnum = CommPortIdentifier.getPortIdentifiers();
         while ( portEnum.hasMoreElements() )
         {
             CommPortIdentifier portIdentifier = (CommPortIdentifier)  
portEnum.nextElement();
             System.out.println(portIdentifier.getName() + " - " +  
portIdentifier.getPortType() );
         }

         CommPortIdentifier portIdentifier =  
CommPortIdentifier.getPortIdentifier("/dev/cu.BTGPS-SPPslave-1");
         System.out.println("current owner: " +  
portIdentifier.getCurrentOwner());
         if ( portIdentifier.isCurrentlyOwned() )
         {
             System.out.println("Error: Port is currently in use");
             return null;
         }
         else
         {
             CommPort commPort = portIdentifier.open(this.getClass 
().getName(),2000);

             if ( commPort instanceof SerialPort )
             {
                 SerialPort serialPort = (SerialPort) commPort;
                 serialPort.setSerialPortParams 
(4800,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE 
);
                 in = serialPort.getInputStream();

                 return in;
             }
             else
             {
                 System.out.println("Error: Only serial ports are  
handled.");
             }
         }


         return in;
     }


On 18-Jun-06, at 19:33 , Andr?-John Mas wrote:

> Hi,
>
> I am have a program that I wrote in Java to communicate with a
> Bluetooth GPS device. I am
> trying to get this working on my Mac, but I keep getting told that:
>
> gnu.io.PortInUseException: Unknown Application
>
> but
>
> portIdentifier.isCurrentlyOwned()
>
> returns false and when I do lsof on the device I am trying to connect
> to, I see no application
> using it. As the same time if I go to the command line and use
> minicom I have no issues. The
> exception happens with this call:
>
> CommPort commPort = portIdentifier.open(null,0);
>
> Any suggestions?
>
> Andre
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From joachim at buechse.de  Mon Jun 19 05:54:49 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 13:54:49 +0200
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de>

This is most likely due to a problem with lock files. If you have  
downloaded the binaries of 2.17 rxtx will try to create non-standard  
lock files on OSX. We have since changed the code to use OSX device  
locking - however the binaries have not been updated yet. The 2.18  
release fixing this issue is due shortly.

Regards,
Joachim

On 19.06.2006, at 01:33, Andr?-John Mas wrote:

> Hi,
>
> I am have a program that I wrote in Java to communicate with a
> Bluetooth GPS device. I am
> trying to get this working on my Mac, but I keep getting told that:
>
> gnu.io.PortInUseException: Unknown Application
>
> but
>
> portIdentifier.isCurrentlyOwned()
>
> returns false and when I do lsof on the device I am trying to connect
> to, I see no application
> using it. As the same time if I go to the command line and use
> minicom I have no issues. The
> exception happens with this call:
>
> CommPort commPort = portIdentifier.open(null,0);
>
> Any suggestions?
>
> Andre
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From joachim at buechse.de  Mon Jun 19 06:44:27 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 14:44:27 +0200
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <4490A60A.9090305@sun.com>
References: <4490A60A.9090305@sun.com>
Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>

Hello Paul,

I just downloaded the "generic" javax.comm version now available. A  
first check indicates, that it was compiled with a JDK 1.4 javac  
without setting the target classfile version. In other words in can  
not be loaded by 1.1-1.3 VMs (or PersonalJava).

Do you see any chance to provide a version compiled with classfile  
format 45.3 (ie JVM1.1).

---
52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose  
javax.comm.SerialPort | head -5
Compiled from "SerialPort.java"
public abstract class javax.comm.SerialPort extends javax.comm.CommPort
   SourceFile: "SerialPort.java"
   minor version: 0
   major version: 48
---

Best regards,
Joachim


On 15.06.2006, at 02:12, Paul Klissner wrote:

> Hello RxTx community,
>
> I finally think I have a compromise in place that will stand in the  
> gap.
>
> If you go to http://www.sun.com and search for javax.comm, you'll
> get taken to a download page, where now users can get a copy of the
> comm.jar file out of 2.0.3, along with just a license and a README.
>
> I trust this will suffice until such time as RxTx decided to implement
> their own java classes or we can get a JSR going to mitigate some
> of the problems (the readme in the comm.jar 2.0.3 zip file
> contains my thoughts on that).
>
> Thanks,
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Mon Jun 19 09:11:45 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Mon, 19 Jun 2006 11:11:45 -0400
Subject: [Rxtx] Examples added to Wiki
Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

I have added a couple of examples to the Wiki:

http://rxtx.qbang.org/wiki/index.php/Examples

If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :)

Andre



From paul.klissner at sun.com  Mon Jun 19 10:42:47 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Mon, 19 Jun 2006 09:42:47 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>
References: <4490A60A.9090305@sun.com>
	<03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>
Message-ID: <4496D407.1090609@sun.com>

Joachim Buechse wrote:
> Hello Paul,
> 
> I just downloaded the "generic" javax.comm version now available. A  
> first check indicates, that it was compiled with a JDK 1.4 javac  
> without setting the target classfile version. In other words in can  
> not be loaded by 1.1-1.3 VMs (or PersonalJava).
> 
> Do you see any chance to provide a version compiled with classfile  
> format 45.3 (ie JVM1.1).
> 
> ---
> 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose  
> javax.comm.SerialPort | head -5
> Compiled from "SerialPort.java"
> public abstract class javax.comm.SerialPort extends javax.comm.CommPort
>    SourceFile: "SerialPort.java"
>    minor version: 0
>    major version: 48
> ---

I cannot promise when I can do that. Since we thought we were done
with javax.comm, the build environment got moved around, and right
now it doesn't even compile in it's new home.  I tried and it was
not cooperative at all. I was never impressed with that workspace
(in fact far far from it, it is a mess, which is why I migrated 3.0
to ant and never looked back).  It will take some real determination
for me to rebuild it, and frankly, right now I'm swamped.  If I can
find a bit of time over the next few weeks to do it, and it isn't
too bad an ordeal, I will.

Posting that will give me an excuse to post javax.comm 3.0, Update 2 as
well, while I'm working with the people who put content up on our
download center.  The only reason for a new update to 3.0 is that
I've changed the distribution to provide ispt (Interactive Serial
Port Tool), such that it can be launched as soon as the zip file
is unpacked, via a provided script.  ISPT is a command line
interactive tool for  manipulating one or two serial port,
sending data, managing events, etc... I've found it to be so useful
for doing certain kinds of validation  that I assume others will
find it useful to.  ISPT is already in 3.0u1, but one has to set
up their own classpath and launch it and since few people ever read
the documentation most won't know about it.  I've added the ability
to set stop bits and parity since 3.0u1 too.  But I digress.

Paul


From joachim at buechse.de  Mon Jun 19 11:01:28 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 19:01:28 +0200
Subject: [Rxtx] load mechanism of 2.0x
Message-ID: <CFD1440C-21AA-4D3B-9EA6-270D0FF9D6FC@buechse.de>

Good day,

I am trying to figure out, how the 2.0x distribution interacts with  
Suns implementation of javax.comm.CommPortIdentifier.

1) Apparently one can put javax.comm.properties in {java.home}/lib
2) The javax.comm package also reacts to -Djavax.comm.properties="...."

Looking at the javap output it also seems like CommPortIdentifier  
tries to find it's jar file and load the properties from there??


What I'm really looking for is a solution that allows using  
javax.comm with RXTX without modifying the VM installation. So I  
would prefer not to use 1) but I can't figure out how to use 2).

Any hints are welcome,
Joachim



From bob_tai2001 at yahoo.com  Mon Jun 19 15:00:35 2006
From: bob_tai2001 at yahoo.com (Bob Tai)
Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT)
Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place
	to start?
Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>

Hi, 

I got  rxtx Windows 2000 installed.  I did not use the
"best" way ... I just follow the insturuction and dump
the necessary files into the jre... I know it's "best"
idea, I got lazy didn't want to change my setting to
my Eclipse and classpath.

I was able to modify SimpleWrite.java to print on my
AddMaster serial printer.  I think I am ready to code!
But I need to make sure I can handle exceptions and so
on.  I notice the \samples\NullDriver\  has two files
seems to have some of the require method done, should
I start coding from those file?  I like the idea it
has the "time out" and basic exceptions done.   I am
slowly digging into the samples, but if you think any
of the code from Sun is good to checkout please let me
know.

btw, http://rxtx.qbang.org/wiki/index.php/Examples/
was very helpful, wish there are more examples.

thank you,

    Bob


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Mon Jun 19 15:55:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT)
Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good
 place to start?
In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>
References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606191542260.14139@www>

> I am
> slowly digging into the samples, but if you think any
> of the code from Sun is good to checkout please let me
> know.
>

I think NullDriver.java was an example stub driver for implementing 
something like rxtx.  It has been a while.  Unless they have been updated, 
you will find the examples are very dated.  You can look at how they use 
the port but avoid the GUI and hard coded variables (number of ports for 
instance).

There was no Swing and nobody knew what requirements today's compilers 
would make on code.  The examples worked fine with jdk 1.1 but times have 
changed.

--
Trent Jarvi
tjarvi at qbang.org


From tropicsu at hotmail.com  Mon Jun 19 19:49:08 2006
From: tropicsu at hotmail.com (Yoke K)
Date: Tue, 20 Jun 2006 01:49:08 +0000
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
Message-ID: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>

An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/fa588f00/attachment-0007.html

From ajmas at sympatico.ca  Mon Jun 19 21:14:37 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Mon, 19 Jun 2006 23:14:37 -0400
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>
References: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>
Message-ID: <CA22AB2A-5712-458B-9984-68477C6042AF@sympatico.ca>

Regarding the PortInUseException, I had a similar issue and got
this response from the mailing list:

   http://mailman.qbang.org/pipermail/rxtx/Week-of- 
Mon-20060619/062838.html

Andre
On 19-Jun-06, at 21:49 , Yoke K wrote:

> Hi Andre, Joachim
>
> I have tried using /dev/tty.usbserial and also /dev/cu.usbserial  
> and it also reported error as  "gnu.io.PortInUseException".
>
> The iTegno modem works in windows environment. As I moving around  
> using my ibook and I need to get it work on MAC OS as well.
>
> >> INFO: SMSLib API for Java / v1.2.2
> >> INFO: Using port: /dev/tty.usbserial @ 115200 baud.
> >> INFO: JRE Version: 1.5.0_06
> >> INFO: JRE Impl Version: 1.5.0_06-64
> >> INFO: O/S: Mac OS X / ppc / 10.4.6
> >> INFO: Using Wavecom (Generic) AT handler.
>
> SendMessage(): Send a message.
> Using SMSLib API for Java v1.2.2
>
> Connecting ..... :
> >> INFO: CSerialDriver(): Connecting...
> Experimental: JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version = RXTX-2.1-7
> >> INFO: CSerialDriver(): Disconnecting...
> gnu.io.PortInUseException: Unknown Application
> at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354)
> at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1)
> at org.smslib.CService.connect(CService.java:197)
> at SendMessage.main(SendMessage.java:38)
>
> Thanks.
>
> - Jon
>
>
>
>
> ====================
>
> Hello Jon,
>
> From OSX's standpoint a symbolic link is not a device (as far as I
> know). What stops you from using tty.usbserial? Did you try hard-
> linking?
>
> Regards,
> Joachim
>
>
>
> From:  "Yoke K" <tropicsu at hotmail.com>
> To:  rxtx at qbang.org
> Subject:  RXTX-2.1-7 / MAC OS X / NoSuchPortException
> Date:  Sat, 17 Jun 2006 15:32:48 +0000
> >Hi,
> >
> >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to
> >work with MAC OS X.
> >I am using iTegno 3000 - USB GPRS Modem.
> >
> >Files in /dev and a symbolic link as follows:
> >
> >crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
> >crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
> >lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->
> >tty.usbserial
> >
> >In my SendMessage.java, I have this line:
> >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
> >
> >Appreciate any help ?
> >
> >- Jon
> >
> >
> >Errors as follows:
> >
> >>>INFO: SMSLib API for Java / v1.2.2
> >>>INFO: Using port: /dev/ttyS1 @ 56000 baud.
> >>>INFO: JRE Version: 1.5.0_06
> >>>INFO: JRE Impl Version: 1.5.0_06-64
> >>>INFO: O/S: Mac OS X / ppc / 10.4.6
> >>>INFO: Using Wavecom (Generic) AT handler.
> >
> >SendMessage(): Send a message.
> >  Using SMSLib API for Java v1.2.2
> >
> >Connecting ..... :
> >>>INFO: CSerialDriver(): Connecting...
> >Experimental:  JNI_OnLoad called.
> >Stable Library
> >=========================================
> >Native lib Version = RXTX-2.1-7
> >Java lib Version   = RXTX-2.1-7
> >>>INFO: CSerialDriver(): Disconnecting...
> >gnu.io.NoSuchPortException
> >        at
> >gnu.io.CommPortIdentifier.getPortIdentifier 
> (CommPortIdentifier.java:218)
> >        at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
> >        at org.smslib.CService.connect(CService.java:197)
> >        at SendMessage.main(SendMessage.java:38)
> >
> >_________________________________________________________________
> >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
> >
>
> Find love online with MSN Personals
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Tue Jun 20 02:35:24 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 10:35:24 +0200
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>

Hello everybody,

I have been fighting a bit with the javax.comm version of RXTX the  
last days. I am working on the README .OSX now and try to figure out  
which should be the "suggested" installation.

The facts:
------

- the "generic" comm.jar version of javax.comm which has been made re- 
available tries to load com.sun.comm.SolarisDriver
- this classname can be overridden ONLY by putting a file  
javax.comm.properties in {java.home}/lib
- if it is not overridden and SolarisDriver.class is not found  
CommPortIdentifier will be disfunctional (in particual it is not  
possible to add CommPort's via CommPortIdentifier.add).
- the license distributed with comm.jar does not allow the  
modification/addition of classes in javax.comm (however no mention of  
com.sun...)


What really bothers me is to suggest putting this config file in the  
"global" vm installation. This is particularly ugly on the Mac as  
there are several VM installations and the file may be forgotten.  
Additionally it may create versioning problems. I prefer an  
installation where all files are local to the application (even  
comm.jar).

In my opinion the ideal situation would be:
------

1) The author of a program compiles against javax.comm.
2a) For platforms supported by Sun the user is free to use the 3.0  
comm.jar download from Sun
2b) For platforms not supported by Sun the user adds RXTXComm.jar to  
the classpath of the application (and librxtxSerial.jnilib to the  
application directory). Also he will need the 2.0.3 generic comm.jar  
from Sun.
3) Nobody messes with the global VM installation.

Of course 2a) and 2b) could be handled by the author of the program  
via an appropriate installer. The author could also decide to always  
use RXTX and include the generic javax.comm classes as well as the  
RXTX classes in his application jar. [If he further uses an explicit  
call to System.load() he may even include the jnilib(s) in the jar,  
extract it (based on the platform name) at runtime to a temp file and  
load it from there.]


Suggested solution:
------

We only need to put the following class in the classpath BEFORE Suns  
comm.jar

   package com.sun.comm;
   public class SolarisDriver extends gnu.io.RXTXCommDriver {
   }

This is not "the pure art" (TM). It depends on an implementation  
detail of the generic driver. However, so does the  
javax.comm.properties file - as we have seen when Sun released 3.0.  
It has the following advantages:

- The "generic" javax.comm implementation will happily load this  
class as its primary driver.
- No javax.comm.properties file is required.
- This does not violate the javax.comm license agreement as there is  
no mention of the "com.sun.comm" package in this license agreement at  
all.
- Authors packaging comm.jar with their application can strip out all  
com.sun.comm classes from comm.jar


Please comment!

Joachim



From joachim at buechse.de  Tue Jun 20 02:50:36 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 10:50:36 +0200
Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar
Message-ID: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>

There has been some discussions about the best way to install RXTX  
and where to place files.

I suggest that,

- we include the native libraries for the most common operating  
systems (in a special version of) RXTXcomm.jar
- we add loader code which tries to extract and load the platform  
specific binary at runtime
- on failure the current mechanism remains as a fallback

Wether the current mechanism should have priority (ie loadLibrary  
before load) remains to be discussed.


The advantages of this solution are
  - users of RXTX do not need to worry about java/platform specific  
file placement.
  - authors of applications may fully merge RXTX into their  
application jar (which provides a double-clickable application for  
Windows and OSX, Linux?).

Please comment,
Joachim

PS: Of course the suggested solution is already possible today,  
however relatively few programmers know how to correctly extract a  
binary resource file via the class loader and load it as a native  
library.


From tjarvi at qbang.org  Tue Jun 20 03:58:12 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT)
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
Message-ID: <Pine.LNX.4.61.0606200335190.14139@www>

> 2a) For platforms supported by Sun the user is free to use the 3.0
> comm.jar download from Sun
> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to
> the classpath of the application (and librxtxSerial.jnilib to the
> application directory). Also he will need the 2.0.3 generic comm.jar
> from Sun.

As there are no plans to support CommAPI 3.0 due to the limitations in its 
implementation mentioned before, I would not recommend projects use Sun's 
3.0 comm.jar.  They will lose the freedom to chose their low level 
implementation by being locked into vendor specific modifications.

Projects should chose between platform neutrality in CommAPI 2.0 and 
reduced platform neutrality in commapi 3.0.  Projects should also strongly 
consider the fact that the 2.0 comm.jar targets only a reduced number of 
JVMs.

Projects can go with rxtx 2.1 or other packages but should probably only 
consider using Sun CommAPI with rxtx if they did so in the past.  They 
should take steps to no longer depend upon this option being available.

> Suggested solution:
> ------
>
> We only need to put the following class in the classpath BEFORE Suns
> comm.jar
>
>   package com.sun.comm;
>   public class SolarisDriver extends gnu.io.RXTXCommDriver {
>   }
>
> This is not "the pure art" (TM). It depends on an implementation
> detail of the generic driver. However, so does the
> javax.comm.properties file - as we have seen when Sun released 3.0.
> It has the following advantages:
>
> - The "generic" javax.comm implementation will happily load this
> class as its primary driver.
> - No javax.comm.properties file is required.
> - This does not violate the javax.comm license agreement as there is
> no mention of the "com.sun.comm" package in this license agreement at
> all.
> - Authors packaging comm.jar with their application can strip out all
> com.sun.comm classes from comm.jar
>

I would not encourage people to place packages in the com.sun.comm 
namespace.  Authors using Sun's commapi 2.0 should just realize it is 
greatly limited in practical utility and consider moving to something that 
isn't being rescued from EOL.

The primary focus of this release is projects previously depending upon 
Sun CommAPI + RXTX.  There are no plans at this time to provide future 
support in this arrangement due to technical incompatabilities we have no 
control over in commapi 3.0 and limited utility of Sun's generic comm.jar 
in commapi 2.0 offered.  Projects should be aware of this so they can make 
appropriate plans.

--
Trent Jarvi
tjarvi at qbang.org


From paul.klissner at sun.com  Tue Jun 20 05:24:00 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Tue, 20 Jun 2006 04:24:00 -0700
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
In-Reply-To: <Pine.LNX.4.61.0606200335190.14139@www>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
	<Pine.LNX.4.61.0606200335190.14139@www>
Message-ID: <4497DAD0.10803@sun.com>

Trent Jarvi wrote:
>> 2a) For platforms supported by Sun the user is free to use the 3.0
>> comm.jar download from Sun
>> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to
>> the classpath of the application (and librxtxSerial.jnilib to the
>> application directory). Also he will need the 2.0.3 generic comm.jar
>> from Sun.
> 
> As there are no plans to support CommAPI 3.0 due to the limitations in its 
> implementation mentioned before, I would not recommend projects use Sun's 
> 3.0 comm.jar.  They will lose the freedom to chose their low level 
> implementation by being locked into vendor specific modifications.
> 
> Projects should chose between platform neutrality in CommAPI 2.0 and 
> reduced platform neutrality in commapi 3.0.  Projects should also strongly 
> consider the fact that the 2.0 comm.jar targets only a reduced number of 
> JVMs.

Well, that's a little ambiguous because the API is the same
either way.  We're talking about Sun's implementation vs.
other implementations.
> 
> Projects can go with rxtx 2.1 or other packages but should probably only 
> consider using Sun CommAPI with rxtx if they did so in the past.  They 
> should take steps to no longer depend upon this option being available.

3.0 is platform centric because there is a need to add some
platform awareness to Sun's implementation, and the choices
for how to do that are limited by the constraints of the API,
as mentioned in the javax.comm 2.0.3 comm.jar download's README.

I am really advocating getting a JSR open (http://www.jcp.org)
to push a new comm API that is more pluggable, platform neutral
and addresses some of the deficiencies of the current API. Then
we can achieve the optimal of platform neutrality while
simulataneously allowing the API to flexibly adapt to
heterogeneous environments.

This is not a question of attitude, this is an issue of resources,
time and commitment.  The current owners of javax.comm within
Sun would like nothing better than to see the ideal reached for
the API and a model that will extend well beyond the foreseeable
future and work for the industry overall.



> 
>> Suggested solution:
>> ------
>>
>> We only need to put the following class in the classpath BEFORE Suns
>> comm.jar
>>
>>   package com.sun.comm;
>>   public class SolarisDriver extends gnu.io.RXTXCommDriver {
>>   }
>>
>> This is not "the pure art" (TM). It depends on an implementation
>> detail of the generic driver. However, so does the
>> javax.comm.properties file - as we have seen when Sun released 3.0.
>> It has the following advantages:
>>
>> - The "generic" javax.comm implementation will happily load this
>> class as its primary driver.
>> - No javax.comm.properties file is required.
>> - This does not violate the javax.comm license agreement as there is
>> no mention of the "com.sun.comm" package in this license agreement at
>> all.
>> - Authors packaging comm.jar with their application can strip out all
>> com.sun.comm classes from comm.jar
>>
> 
> I would not encourage people to place packages in the com.sun.comm 
> namespace.  Authors using Sun's commapi 2.0 should just realize it is 
> greatly limited in practical utility and consider moving to something that 
> isn't being rescued from EOL.
> 
> The primary focus of this release is projects previously depending upon 
> Sun CommAPI + RXTX.  There are no plans at this time to provide future 
> support in this arrangement due to technical incompatabilities we have no 
> control over in commapi 3.0 and limited utility of Sun's generic comm.jar 
> in commapi 2.0 offered.  Projects should be aware of this so they can make 
> appropriate plans.

Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86,
or need the powerful portmapping features in javax.com 3.0, or would like to
acquire the Interactive Serial Port Test utility.

-Paul


From paul.klissner at sun.com  Tue Jun 20 05:33:44 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Tue, 20 Jun 2006 04:33:44 -0700
Subject: [Rxtx] Suggested installation RXTX 2.0x...
In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
Message-ID: <4497DD18.70207@sun.com>

Joachim Buechse wrote:
> Hello everybody,
> 
> I have been fighting a bit with the javax.comm version of RXTX the  
> last days. I am working on the README .OSX now and try to figure out  
> which should be the "suggested" installation.
> 
> The facts:
> ------
> 
> - the "generic" comm.jar version of javax.comm which has been made re- 
> available tries to load com.sun.comm.SolarisDriver
> - this classname can be overridden ONLY by putting a file  
> javax.comm.properties in {java.home}/lib
> - if it is not overridden and SolarisDriver.class is not found  
> CommPortIdentifier will be disfunctional (in particual it is not  
> possible to add CommPort's via CommPortIdentifier.add).
> - the license distributed with comm.jar does not allow the  
> modification/addition of classes in javax.comm (however no mention of  
> com.sun...)
> 
> 
> What really bothers me is to suggest putting this config file in the  
> "global" vm installation. This is particularly ugly on the Mac as  
> there are several VM installations and the file may be forgotten.  
> Additionally it may create versioning problems. I prefer an  
> installation where all files are local to the application (even  
> comm.jar).
> 
> In my opinion the ideal situation would be:
> ------
> 
> 1) The author of a program compiles against javax.comm.
> 2a) For platforms supported by Sun the user is free to use the 3.0  
> comm.jar download from Sun
> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to  
> the classpath of the application (and librxtxSerial.jnilib to the  
> application directory). Also he will need the 2.0.3 generic comm.jar  
> from Sun.
> 3) Nobody messes with the global VM installation.
> 
> Of course 2a) and 2b) could be handled by the author of the program  
> via an appropriate installer. The author could also decide to always  
> use RXTX and include the generic javax.comm classes as well as the  
> RXTX classes in his application jar. [If he further uses an explicit  
> call to System.load() he may even include the jnilib(s) in the jar,  
> extract it (based on the platform name) at runtime to a temp file and  
> load it from there.]
> 

This was how the Sun implementation originated (I did not write
that code).  I completely agree, and I fixed the whole conf file
locating mechanism in 3.0 to avoid the problems youmentioned.
However, I was unaware of how RxTx was using Sun's implementation,
so I didn't architect it in such a way as to avoid namespace pollution
in the native space in for the backend provider.  In retrospect,
I should have done that differently just as a design principle,
but at this point I don't have the spare cycles to get that all
re-factored.  Further, I'm loathe to do it, because the whole
thing will still be an under-the-hood hack due to the constraints
of the API itself.

Paul





From brian at mbari.org  Tue Jun 20 10:23:54 2006
From: brian at mbari.org (Brian Schlining)
Date: Tue, 20 Jun 2006 09:23:54 -0700
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>


Hi Joachim,

> There has been some discussions about the best way to install RXTX
> and where to place files.
>
> I suggest that,
>
> - we include the native libraries for the most common operating
> systems (in a special version of) RXTXcomm.jar
> - we add loader code which tries to extract and load the platform
> specific binary at runtime
> - on failure the current mechanism remains as a fallback

I like your suggestion. However, my understanding is that in general  
the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH  
(Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to  
be loaded by the JVM. The alternative is to point to your native lib  
directory using -Djava.library.path=/my/dir/with/native/libs when you  
launch the JVM. So, I'm very interested to know how you're planning  
to work around this.

> PS: Of course the suggested solution is already possible today,
> however relatively few programmers know how to correctly extract a
> binary resource file via the class loader and load it as a native
> library.

So how do you use it to dynamically load a native lib? I've read that  
you can't really modify the java.library.path after the JVM has been  
launched. (http://forum.java.sun.com/thread.jspa? 
threadID=627890&tstart=90)

Thanks

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0016.html

From joachim at buechse.de  Tue Jun 20 09:20:29 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 17:20:29 +0200
Subject: [Rxtx] 2.0x in sync with 2.1x
Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>

I have added most of the changes from the 2.1 branch to the 2.0 branch.

This includes
  - correction of illegal javadoc comments
  - implementation errors in handling of Thread.interrupt in  
RXTXPort.java
  - MacOS X locking without lock files/special user groups
  - XCode project which builds a universal binary library
  - updated documentation for OSX

I have done some minimal testing (only G4).
[Trent: there are still some changes you made for specific baud  
rates. I will not sync this, as I can not test them. From my  
perspective we are ready for 2.08/2.18]

The updated documentation can be found in the file README.OSX. Here  
it is:

------------------------ Required files -----------------------

To use or compile RXTX 2.0.x you need to downlad the "generic"  
version (2.0.3)
of the javax.comm implementation from Sun. The zip you download  
contains an
archive comm.jar which is required:

- To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar

- To run the app you will need comm.jar in the classpath or in  
{java.lib.path}


------------------------ Installation on MacOSX -----------------------

WARNING: Please read this section until the end.

---
Preparation
---

You may want to spare your users the burden of modifying the global VM
installation. OSX has several different VM versions installed by  
default and
regular users will be unable to figure out which version will load your
application.

If you provide the class

package com.sun.comm;
public class SolarisDriver extends gnu.io.RXTXCommDriver {
}

and make sure, that it is present in the classpath before Suns  
"generic" comm.jar
your users can skip the following step:

Create a file named
    javax.comm.properties
in the directory
    /System/Library/Frameworks/JavaVM.framework/Home/lib/
which contains (only) the following line (no leading space):
    Driver=gnu.io.RXTXCommDriver



----
The unsafe way of using RXTX on OS X:
----

RXTX can be installed by putting the files
   libSerial.jnilib
   RXTXcomm.jar
   comm.jar
into the folder
   /Library/Java/Extensions

This is NOT RECOMMENDED as it creates versioning conflicts among  
applications.
However you may be forced to install it this way if an application  
was written
for Windows or Linux, requires RXTX and you are not able to change  
its starter.


----
The safe way of using RXTX on OS X:
----

Make sure that you have no (older) version of RXTX installed in
   /Library/Java/Extensions
   /System/Library/Java/Extensions
   /usr/lib/java

Put
   libSerial.jnilib
in the directory of the application (the JavaVM will find it there). Add
   RXTXComm.jar
   comm.jar
to the application classpath or include the classes in the  
application jar.
(Some applications already include the RXTX classes in their  
application jar,
in which case only the file libSerial.jnilib is required).


----
History
----

Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation  
of lockfiles
required special permissions for the user executing an application  
based on RXTX.
To simplify the setup RXTX came with an installer modifying group  
permissions
and installing RXTX in the global location /Library/Java/Extensions.  
However
this was prune to versioning conflicts and is no longer recommended.

--------------------- Build instructions for OSX XCode  
-------------------

contributed by Joachim Buechse <joachim at buechse.de>
original version by Dmitry Markman <dmarkman at mac.com>

System requirements for building:
MacOSX 10.4
XCode 2.3

   open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj
   choose libSerial.jnilib target
   build

After the build you will find RXTXcomm.jar and libSerial.jnilib files  
in the
directory build/Development.

In case you can't find RXTXcomm.jar build the RXTXcomm target manually.
In case of (serious) problems feel free to contact joachim at buechse.de .



From tjarvi at qbang.org  Tue Jun 20 22:01:45 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT)
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
Message-ID: <Pine.LNX.4.61.0606202127270.14139@www>

> ---
> Preparation
> ---
>
> You may want to spare your users the burden of modifying the global VM
> installation. OSX has several different VM versions installed by
> default and
> regular users will be unable to figure out which version will load your
> application.
>
> If you provide the class
>
> package com.sun.comm;
> public class SolarisDriver extends gnu.io.RXTXCommDriver {
> }
>
> and make sure, that it is present in the classpath before Suns
> "generic" comm.jar
> your users can skip the following step:

Hi Joachim

With regards to the above, I have not seen that we have Sun's OK to 
promote that.  I'm not very comfortable with the distribution 
documentation advocating this without Sun agreeing.

I see your point but I'd rather not actively promote putting classes in 
Sun's namespace without permission if you don't mind.  This isn't about 
what is in a license.

I'll go through the code tomorrow night.  It was a late night at work 
today.  There is also a w32 fix comming for people opening and closing 
multiple ports.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Wed Jun 21 01:56:45 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 21 Jun 2006 09:56:45 +0200
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <Pine.LNX.4.61.0606202127270.14139@www>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
	<Pine.LNX.4.61.0606202127270.14139@www>
Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>

Hello Trent,

I guess we will not get an explicit OK from Sun for such a hack. I  
think Paul has made it pretty clear, that he does not have the  
resources to modify the 2.x or 3.x code for the needs of RXTX. I'm  
not thrilled but OK with the current API. Hence I dont agree with  
Paul's idea to start a new JSR to fix the implementation - but that's  
mainly because I dont have the time to push it. According to their  
Readme Sun sees no business case in having cross platform support for  
javax.comm - that is sad but it's none of my business. However I  
prefer to program versus javax.comm in my projects as this gives an  
advanced user the chance to exchange the provider without access to  
the code.

I interpret Pauls reponse to my original "Request for comment" as a  
quiet acceptance of the hack I propose (he did respond, but not at  
all to the sun.comm namespace suggestion). This is certainly not  
something we should put into RXTXcomm.jar but hinting a work around  
for implementation errors should be allowed. That's why I've choosen  
the wording "You may want to spare" and "If you provide". The company  
I worked for has choosen similar hacks for years to fix bugs in swing  
for JDK1.1 applications. Those hacks were usually included in their  
own swingpatch.jar.

Having said all that - I do not take it as an insult if you remove  
the paragraph from the Readme. I appreciate that you notified me  
before. It would be interesting to hear some more opinions from the  
list members...

Best regards,
Joachim


On 21.06.2006, at 06:01, Trent Jarvi wrote:

>> ---
>> Preparation
>> ---
>>
>> You may want to spare your users the burden of modifying the  
>> global VM
>> installation. OSX has several different VM versions installed by
>> default and
>> regular users will be unable to figure out which version will load  
>> your
>> application.
>>
>> If you provide the class
>>
>> package com.sun.comm;
>> public class SolarisDriver extends gnu.io.RXTXCommDriver {
>> }
>>
>> and make sure, that it is present in the classpath before Suns
>> "generic" comm.jar
>> your users can skip the following step:
>
> Hi Joachim
>
> With regards to the above, I have not seen that we have Sun's OK to
> promote that.  I'm not very comfortable with the distribution
> documentation advocating this without Sun agreeing.
>
> I see your point but I'd rather not actively promote putting  
> classes in
> Sun's namespace without permission if you don't mind.  This isn't  
> about
> what is in a license.
>
> I'll go through the code tomorrow night.  It was a late night at work
> today.  There is also a w32 fix comming for people opening and closing
> multiple ports.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Wed Jun 21 02:03:33 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 21 Jun 2006 10:03:33 +0200
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
	<6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
Message-ID: <BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>

See System.load(String) [it's also mentioned under the URL you posted].

Regards,
Joachim


On 20.06.2006, at 18:23, Brian Schlining wrote:

> So how do you use it to dynamically load a native lib? I've read  
> that you can't really modify the java.library.path after the JVM  
> has been launched. (http://forum.java.sun.com/thread.jspa? 
> threadID=627890&tstart=90)
>
> Thanks
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From baris.ozkan at elikasu.com.tr  Wed Jun 21 07:58:06 2006
From: baris.ozkan at elikasu.com.tr (Baris)
Date: Wed, 21 Jun 2006 16:58:06 +0300
Subject: [Rxtx] RS 232 ..additional parameters
Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>

Hi,
 
Currently i am developing an application that requires to connect to a
remote rs232 device through  a dialup connection.
 
My problem is that the communication needs several more connection
parameters (i extracted that information from the vendor's dll , listed at
the end of the message)
 
I explored rxtx API and src files and could not find methods to set a
majority  of the parameters.
Am i missing any point or does rxtx is limited to soem standard set of
functionality(e.g. commAPI)? How  is it possible ,if i want to put some
extensions(???) to current rxtx implementation?
 
I am not very good at rs232 programming so excuse me if this message  is
boring one.
 
Thanx
 
Baris Ozkan
 
 
A Listing of Parameters:
 
 
typedef struct _DCB {

DWORD DCBlength; /* sizeof(DCB) */

DWORD BaudRate; /* Baudrate at which running */

DWORD fBinary: 1; /* Binary Mode (skip EOF check) */

DWORD fParity: 1; /* Enable parity checking */

DWORD fOutxCtsFlow:1; /* CTS handshaking on output */

DWORD fOutxDsrFlow:1; /* DSR handshaking on output */

DWORD fDtrControl:2; /* DTR Flow control */

DWORD fDsrSensitivity:1; /* DSR Sensitivity */

DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */

DWORD fOutX: 1; /* Enable output X-ON/X-OFF */

DWORD fInX: 1; /* Enable input X-ON/X-OFF */

DWORD fErrorChar: 1; /* Enable Err Replacement */

DWORD fNull: 1; /* Enable Null stripping */

DWORD fRtsControl:2; /* Rts Flow control */

DWORD fAbortOnError:1; /* Abort all reads and writes on Error */

DWORD fDummy2:17; /* Reserved */

WORD wReserved; /* Not currently used */

WORD XonLim; /* Transmit X-ON threshold */

WORD XoffLim; /* Transmit X-OFF threshold */

BYTE ByteSize; /* Number of bits/byte, 4-8 */

BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */

BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */

char XonChar; /* Tx and Rx X-ON character */

char XoffChar; /* Tx and Rx X-OFF character */

char ErrorChar; /* Error replacement char */

char EofChar; /* End of Input character */

char EvtChar; /* Received Event character */

WORD wReserved1; /* Fill for now. */

} DCB, *LPDCB;

typedef struct _COMMTIMEOUTS {

DWORD ReadIntervalTimeout; /* Maximum time between read chars. */

DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */

DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */

DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */

DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */

} COMMTIMEOUTS,*LPCOMMTIMEOUTS;

dcb.fOutX = FALSE;

dcb.fInX = FALSE;

dcb.fOutxCtsFlow = FALSE;

dcb.fBinary = TRUE;

dcb.fRtsControl = RTS_CONTROL_ENABLE;

SetCommState(hComm , &dcb ); 

COMMTIMEOUTS commTimeOut;

GetCommTimeouts(hComm, &commTimeOut );

commTimeOut.WriteTotalTimeoutMultiplier = 1; 

commTimeOut.WriteTotalTimeoutConstant = 18; 

// commTimeOut.ReadIntervalTimeout = 28; 

commTimeOut.ReadIntervalTimeout = 0; 

// commTimeOut.ReadTotalTimeoutMultiplier = 184; 

commTimeOut.ReadTotalTimeoutMultiplier = 300; 

// commTimeOut.ReadTotalTimeoutConstant = 1200;

commTimeOut.ReadTotalTimeoutConstant = 1200;

SetCommTimeouts(hComm, &commTimeOut);

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0016.html

From ajmas at sympatico.ca  Wed Jun 21 08:14:26 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Wed, 21 Jun 2006 10:14:26 -0400
Subject: [Rxtx] When is 2.18 planned for?
Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

Just curious as to know if there is a target date for 2.18?

Andre



From brian at mbari.org  Wed Jun 21 09:36:00 2006
From: brian at mbari.org (Brian Schlining)
Date: Wed, 21 Jun 2006 08:36:00 -0700
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
	<6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
	<BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>
Message-ID: <A21C9BC0-7894-4B08-AC82-44E11AB3D461@mbari.org>

Ha!!

I suppose I should read my own postings. ;-)

Thanks
B

On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote:

> See System.load(String) [it's also mentioned under the URL you  
> posted].
>
> Regards,
> Joachim
>
>
> On 20.06.2006, at 18:23, Brian Schlining wrote:
>
>> So how do you use it to dynamically load a native lib? I've read
>> that you can't really modify the java.library.path after the JVM
>> has been launched. (http://forum.java.sun.com/thread.jspa?
>> threadID=627890&tstart=90)

Brian Schlining
Software Engineer
http://www.mbari.org




From ajmas at sympatico.ca  Wed Jun 21 16:41:28 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Wed, 21 Jun 2006 18:41:28 -0400
Subject: [Rxtx] CVS build question
Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X:

 The JCL extension to RxTx requires comm.jar
 If you intend to use RxTx for commapi support comm.jar
 needs to be located in  /System/Library/Frameworks/JavaVM.framework/
  Versions/1.5/Home/lib/ext/comm.jar

I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me.

On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native).

Andre






From tjarvi at qbang.org  Wed Jun 21 18:00:04 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT)
Subject: [Rxtx] CVS build question
In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606211756310.14139@www>

On Wed, 21 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> Is the CVS repository meant to build for gnu.io or javax.comm? I ask 
> this, because I see the following when calling ./configure from MacOS X:
>
> The JCL extension to RxTx requires comm.jar
> If you intend to use RxTx for commapi support comm.jar
> needs to be located in  /System/Library/Frameworks/JavaVM.framework/
>  Versions/1.5/Home/lib/ext/comm.jar
>
> I am wanting to build for the gnu.io package, since I want to jump ahead 
> and see if the changes, intended for 2.18 for MacOS X, work for me.
>
> On a side note /Library/Java/Extensions should be included as a valid 
> search path for the JAR, since this is where Apple recommends placing 
> third party extensions (both Java and native).
>

rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel"
rxtx 2.0 src is obtained with "cvs checkout rxtx-devel"

rxtx 2.1 is a complete package in namespace gnu.io
rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 18:02:23 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT)
Subject: [Rxtx] When is 2.18 planned for?
In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606211800180.14139@www>

On Wed, 21 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> Just curious as to know if there is a target date for 2.18?
>

Hi Andre

"When it is ready" :)

Probably this weekend.  Maybe sooner.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 18:10:18 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT)
Subject: [Rxtx] RS 232 ..additional parameters
In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>
References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>
Message-ID: <Pine.LNX.4.61.0606211805010.14139@www>

On Wed, 21 Jun 2006, Baris wrote:

> Hi,
>
> Currently i am developing an application that requires to connect to a
> remote rs232 device through  a dialup connection.
>
> My problem is that the communication needs several more connection
> parameters (i extracted that information from the vendor's dll , listed at
> the end of the message)
>
> I explored rxtx API and src files and could not find methods to set a
> majority  of the parameters.
> Am i missing any point or does rxtx is limited to soem standard set of
> functionality(e.g. commAPI)? How  is it possible ,if i want to put some
> extensions(???) to current rxtx implementation?
>
> I am not very good at rs232 programming so excuse me if this message  is
> boring one.
>
> Thanx
>

Hi Baris

> typedef struct _DCB {
> typedef struct _COMMTIMEOUTS {

These are all handled in termios.c.  It is possible to add extensions to 
rxtx 2.1.  It may well be that the defaults are the same for the variables 
not covered by the existing API.  You can dump the DCB and COMMTIMEOUTS 
from inside termios.c to compare.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 20:23:30 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT)
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
	<Pine.LNX.4.61.0606202127270.14139@www>
	<789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>
Message-ID: <Pine.LNX.4.61.0606212012210.14139@www>

> I'm
> not thrilled but OK with the current API. Hence I dont agree with
> Paul's idea to start a new JSR to fix the implementation - but that's
> mainly because I dont have the time to push it. According to their
> Readme Sun sees no business case in having cross platform support for
> javax.comm - that is sad but it's none of my business. However I
> prefer to program versus javax.comm in my projects as this gives an
> advanced user the chance to exchange the provider without access to
> the code.

Hi Joachim

With regards to the JSR, I think that would be Doug's call.  The effort I 
put in would have to be on my own time which would not be a great deal.  I 
could help things go smoothly but thats not the same as pushing something 
through.

--
Trent Jarvi
tjarvi at qbang.org



From vt at freehold.crocodile.org  Wed Jun 21 21:05:22 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Wed, 21 Jun 2006 20:05:22 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
Message-ID: <449A08F2.3020106@freehold.crocodile.org>

Hello all,

I know this question may belong to JSR lists, but since all interested 
parties are here, I thought I just ask this question here, again...

A while ago I run into a problem and wrote a rant, here: 
http://servomaster.sourceforge.net/dev/serial-usb.html
At the time of writing I didn't think of adding another possible 
solution - changing the CommAPI specs to support removable devices. 
Apparently, Serial/USB bridges are here to stay, and this issue has to 
be addressed.

Wonder if anything changed since, and any abstractions for supporting 
removable devices made it into current or future Java CommAPI drafts - 
Paul, any comments?

--vt



From joachim at buechse.de  Thu Jun 22 01:59:54 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 22 Jun 2006 09:59:54 +0200
Subject: [Rxtx] CVS build question
In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de>

Hello Andre,

I am not sure how well the configure/make mechanism will work on OSX.  
I know that a while ago some contributors tried to get configure/make  
working on OSX but from comments I found in the readmes this work was  
only partially successfull. For compilation on OSX we have used the  
ProjectBuilder/XCode projects you can find in MACOSX_IDE.

Regarding the  ./configure comment:
RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config  
file javax.comm.properties. The later MUST reside in {java.home}/lib.  
As the two only work together putting comm.jar into  /Library/Java/ 
Extensions  and hence making it available to all current and future  
VM installations will only add to confusion.

Regards,
Joachim

On 22.06.2006, at 00:41, Andre-John Mas wrote:

> Hi,
>
> Is the CVS repository meant to build for gnu.io or javax.comm? I  
> ask this, because I see the following when calling ./configure from  
> MacOS X:
>
>  The JCL extension to RxTx requires comm.jar
>  If you intend to use RxTx for commapi support comm.jar
>  needs to be located in  /System/Library/Frameworks/JavaVM.framework/
>   Versions/1.5/Home/lib/ext/comm.jar
>
> I am wanting to build for the gnu.io package, since I want to jump  
> ahead and see if the changes, intended for 2.18 for MacOS X, work  
> for me.
>
> On a side note /Library/Java/Extensions should be included as a  
> valid search path for the JAR, since this is where Apple recommends  
> placing third party extensions (both Java and native).
>
> Andre
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Thu Jun 22 02:51:05 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 22 Jun 2006 10:51:05 +0200
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449A08F2.3020106@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>

Hello Vadim,

I think that your rant is to the point. However it is a bit like  
saying that Windows is at the source of email degradation and the  
only solution is to have users switch to safer operating systems.

I don't see how javax.comm or RXTX can address the problems you  
mention. Of course it would be super cool if javax.comm could magicly  
find the "matching" usb-device and query it's configuration via the  
usb protocol - however this magic (mapping /dev/xyz to its underlying  
USB device) is not supported by any kernel APIs I am aware of. It  
could be supported via POSSIX ioctl calls but then you should address  
your rant to the POSSIX group...

So for the time beeing it's either up to the virtual comm port driver  
to provide a usefull name under /dev/ or to the user choosing the  
right port to use. One example of a smart(er) com port driver is the  
KDDI driver for OSX, which will create device names like "/dev/ 
cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- 
encoded into the bridge chip. The same driver for windows also has  
some options allowing it in theory to recreate the same COMx every  
time a device is plugged/unplugged.

For most industrial applications however it will be up to the user to  
choose the right port (without getting a lot of help doing so).

Probing serial ports can go wrong, that's right. However any serial  
device developper would be well adviced to implement a basic set of  
Hayes AT modem commands (be it a modem or not). Especially AT I0.  
Anyone failing to do so risks that the users favourite TCP/PPP/FAX  
application or stack will kill the device in short time.

Best regards,
Joachim


On 22.06.2006, at 05:05, Vadim Tkachenko wrote:

> Hello all,
>
> I know this question may belong to JSR lists, but since all interested
> parties are here, I thought I just ask this question here, again...
>
> A while ago I run into a problem and wrote a rant, here:
> http://servomaster.sourceforge.net/dev/serial-usb.html
> At the time of writing I didn't think of adding another possible
> solution - changing the CommAPI specs to support removable devices.
> Apparently, Serial/USB bridges are here to stay, and this issue has to
> be addressed.
>
> Wonder if anything changed since, and any abstractions for supporting
> removable devices made it into current or future Java CommAPI drafts -
> Paul, any comments?
>
> --vt
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From vt at freehold.crocodile.org  Thu Jun 22 13:16:03 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 12:16:03 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
Message-ID: <20060622191603.GA17487@freehold.crocodile.org>

Hello Joachim,

> I think that your rant is to the point. However it is a bit like  
> saying that Windows is at the source of email degradation and the  
> only solution is to have users switch to safer operating systems.

I guess the problem is that the rant itself is obsolete and has to be
updated according to latest developments. At the time of writing there
weren't that many bridges around, and the trend didn't manifest itself as it
does now.

> I don't see how javax.comm or RXTX can address the problems you  
> mention.

I would agree that javax.comm won't be able to address the problem, at least
in the short run. As for RxTx - well, nobody prevents it from being a
superset of CommAPI specification, right? RxTx being the de-facto standard
for quite a few platforms, I'd daresay the standard may follow.

> Of course it would be super cool if javax.comm could magicly find the
> "matching" usb-device and query it's configuration via the usb protocol -
> however this magic (mapping /dev/xyz to its underlying USB device) is not
> supported by any kernel APIs I am aware of. It could be supported via
> POSSIX ioctl calls but then you should address your rant to the POSSIX
> group...

As a matter of fact, my bigger concern is addressing the fact that a serial
device can now be removable. This hasn't been the case before, and it
clearly is now. Regarding the above, well, I guess if we accept this fact,
we also need to accept the fact that we need at least rudimentary means of
identification of a serial device. For the USB case, it would usually be the
vendor/product ID, plus possible serial number - but it is irrelevant what
exactly the identifying information is, as long as it allows to identify the
device.

A paradigm shift is required, this is what I wanted to say. Serial devices
can be removed and replaced, it's now our turn to learn to deal with it.

> Joachim

--vt


From jredman at ergotech.com  Thu Jun 22 13:41:44 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 13:41:44 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
Message-ID: <449AF278.6000903@ergotech.com>


Vadim Tkachenko wrote:
> A paradigm shift is required, this is what I wanted to say. Serial devices
> can be removed and replaced, it's now our turn to learn to deal with it.

The removal if the serial port hardly significantly different from the 
removal of the device attached to the serial port.   Different, 
slightly, but not a "paradigm shift".

And yes, someone could unplug a USB serial device and plug it into a 
different USB port so that it has a different name/number, but they 
could do that with the device itself, move it from com1 to com2.

Am I missing something?

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 13:57:27 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 12:57:27 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449AF278.6000903@ergotech.com>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
Message-ID: <20060622195727.GA20247@freehold.crocodile.org>

On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote:
> 
> Vadim Tkachenko wrote:
> > A paradigm shift is required, this is what I wanted to say. Serial devices
> > can be removed and replaced, it's now our turn to learn to deal with it.
> 
> The removal if the serial port hardly significantly different from the 
> removal of the device attached to the serial port.   Different, 
> slightly, but not a "paradigm shift".
> 
> And yes, someone could unplug a USB serial device and plug it into a 
> different USB port so that it has a different name/number, but they 
> could do that with the device itself, move it from com1 to com2.
> 
> Am I missing something?

Yes, the fact that they could unplug a device A and plug a device B. With
the introduction of the concept of removability, the notion of the serial
port itself is not as important anymore, but the notion of the unique device
identifier is.

Consider a situation: long running system (enterprise HVAC, tens of nodes,
tens of thousands square feet area, hundreds of thousand dollars worth of
equipment being conditioned, can't shut down), serial/usb device fails, is
replaced by an identical device with a different serial #.

A little bit farfetched, but hopefully highlighting the point I'm trying to
make.

> Jim

--vt


From jredman at ergotech.com  Thu Jun 22 14:37:38 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 14:37:38 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>	<20060622191603.GA17487@freehold.crocodile.org>	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
Message-ID: <449AFF92.8080003@ergotech.com>


Vadim Tkachenko wrote:
>>
>> Am I missing something?
> 
> Yes, the fact that they could unplug a device A and plug a device B. With
> the introduction of the concept of removability, the notion of the serial
> port itself is not as important anymore, but the notion of the unique device
> identifier is.

Serial devices are always removable.  I could unplug _serial_ device A 
and plug in _serial_ device B.  We have systems running with two RS485 
ports, one talks to a Modbus PLC network one to a number of drives on a 
proprietary protocol.  If you plug the wrong DB9 into the wrong port the 
application doesn't work.

If you dangle a USB 485 converter on the end of the DB9 you've just 
moved the problem from RS485 to USB, but the problem/effect is the same.

> 
> Consider a situation: long running system (enterprise HVAC, tens of nodes,
> tens of thousands square feet area, hundreds of thousand dollars worth of
> equipment being conditioned, can't shut down), serial/usb device fails, is
> replaced by an identical device with a different serial #.
> 
> A little bit farfetched, but hopefully highlighting the point I'm trying to
> make.

Nothing's changed.  If I had a 4 port ISA board and plugged it into my 
new shiny '386 machine.  I could have com ports 9-12.  If I took a board 
off the shelf and didn't set the jumpers, I would have com ports 3-6.

The problem's the same.  If you replace with identical product then the 
com ports  will be the same - no software changes required.  If you 
replace one piece of hardware with hardware from a different 
manufacturer, then the naming/numbering may change.  You're physically 
changing the system, so may reasonably expect to have to make a software 
change.  RXTX actually handles this situation quite well with the -D 
command line option.  (My experience has generally been that the port 
number depends more on the USB port used than the hardware - so the 
chances are even with a hardware change the port number/name will be the 
same.)

Slightly Off Topic - there is a reason why industrial users will pay a 
premium for continued availability of hardware.  Yes you can mail-order 
a $10 USB converter and it will work, but there's no guarantee that the 
next time you buy the same part number from the same vendor it will be 
the same.  The industrial vendors will charge you $100+ for the same 
item, but it will be the same every time you buy it for the next 5 to 10 
years.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 14:37:19 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 13:37:19 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
Message-ID: <20060622203719.GA22521@freehold.crocodile.org>

Hello again,

And while I'm at it, why don't just say this: give me one good reason to
write 3+ different ways of handling removable devices, one for USB, one for
FireWire, one for serial...

I understand very well that this goes way beyond the scope of RxTx and
CommAPI and will require cooperation between them and javax.usb and whatever
JSR is responsible for FireWire implementation - but the end result is well
worth it. Abstract out and generalize arrival/departure/monitoring/discovery
API, provide protocol specific extensions for each, live happily ever after.

--vt


On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote:
> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote:
> > 
> > Vadim Tkachenko wrote:
> > > A paradigm shift is required, this is what I wanted to say. Serial devices
> > > can be removed and replaced, it's now our turn to learn to deal with it.
> > 
> > The removal if the serial port hardly significantly different from the 
> > removal of the device attached to the serial port.   Different, 
> > slightly, but not a "paradigm shift".
> > 
> > And yes, someone could unplug a USB serial device and plug it into a 
> > different USB port so that it has a different name/number, but they 
> > could do that with the device itself, move it from com1 to com2.
> > 
> > Am I missing something?
> 
> Yes, the fact that they could unplug a device A and plug a device B. With
> the introduction of the concept of removability, the notion of the serial
> port itself is not as important anymore, but the notion of the unique device
> identifier is.
> 
> Consider a situation: long running system (enterprise HVAC, tens of nodes,
> tens of thousands square feet area, hundreds of thousand dollars worth of
> equipment being conditioned, can't shut down), serial/usb device fails, is
> replaced by an identical device with a different serial #.
> 
> A little bit farfetched, but hopefully highlighting the point I'm trying to
> make.
> 
> > Jim
> 
> --vt
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx


From jredman at ergotech.com  Thu Jun 22 15:13:49 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 15:13:49 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>	<20060622191603.GA17487@freehold.crocodile.org>	<449AF278.6000903@ergotech.com>	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
Message-ID: <449B080D.9080208@ergotech.com>


Vadim Tkachenko wrote:
> Hello again,
> 
> And while I'm at it, why don't just say this: give me one good reason to
> write 3+ different ways of handling removable devices, one for USB, one for
> FireWire, one for serial...

You don't, they're all the same "I have lost communication with my 
serial device".

The only thing you could really do is improve error reporting by knowing 
the exact sub-system.  ("Device X which is/was attached to USB port Y is 
no longer functioning, please check the USB ports, the device, the 
cables and anything else you can think of that may be a cause of 
failure.")  That just requires an intelligent description of the port.

> I understand very well that this goes way beyond the scope of RxTx and
> CommAPI and will require cooperation between them and javax.usb and whatever
> JSR is responsible for FireWire implementation - but the end result is well
> worth it. Abstract out and generalize arrival/departure/monitoring/discovery
> API, provide protocol specific extensions for each, live happily ever after.

There's a huge list of pseudo-serial devices each with a different set 
of requirements, Bluetooth, RFC 2217, a host of proprietary systems, 
etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I 
have no clue how you'd implement them in a general/cross platform sense.

You haven't convinced me (and only me, others may see something that I 
don't, I'm not speaking for them) that this mechanism can be implemented 
in any practical sense.  That is, that the implementation could be wide 
enough to be consider generally available in RXTX regardless of the 
serial port implementation, platform, etc..  However, if you can come up 
with a general design and a reference implementation for one subsystem, 
I'd like to see it and might get on board.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 15:40:55 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 14:40:55 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449B080D.9080208@ergotech.com>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
Message-ID: <20060622214055.GA25497@freehold.crocodile.org>

On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote:
> 
> Vadim Tkachenko wrote:
> > Hello again,
> > 
> > And while I'm at it, why don't just say this: give me one good reason to
> > write 3+ different ways of handling removable devices, one for USB, one for
> > FireWire, one for serial...
> 
> You don't, they're all the same "I have lost communication with my 
> serial device".

"I have lost communication with my ${protocol} device".

> The only thing you could really do is improve error reporting by knowing 
> the exact sub-system.  ("Device X which is/was attached to USB port Y is 
> no longer functioning, please check the USB ports, the device, the 
> cables and anything else you can think of that may be a cause of 
> failure.")

"Device ${id} which is/was attached to ${protocol} port ${port} is no longer
functioning, please check the ${protocol} ports, the device, the
${protocol_media} and anything else you can think of that may be a cause of
failure".

>  That just requires an intelligent description of the port.

Agree absolutely.

> > I understand very well that this goes way beyond the scope of RxTx and
> > CommAPI and will require cooperation between them and javax.usb and whatever
> > JSR is responsible for FireWire implementation - but the end result is well
> > worth it. Abstract out and generalize arrival/departure/monitoring/discovery
> > API, provide protocol specific extensions for each, live happily ever after.
> 
> There's a huge list of pseudo-serial devices each with a different set 
> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, 
> etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I 
> have no clue how you'd implement them in a general/cross platform sense.

That's because some of the protocols were created decades ago when
autoconfiguration wasn't even conceived, much less practical. RS232/RS485
don't have a clue about identity discovery, and even capabilities discovery
beyond obvious 8N1 etc.

I agree that today all these protocols have generally incompatible
strategies for handling the situations I'm trying to address, but there's
nothing that says it's not an oversight. Besides, we're dealing with the
devices at a level of abstraction that allows some simplifications and
generalizations, at least part of the time - unless it's the protocol
specific features we're dealing with.

> You haven't convinced me (and only me, others may see something that I 
> don't, I'm not speaking for them) that this mechanism can be implemented 
> in any practical sense.  That is, that the implementation could be wide 
> enough to be consider generally available in RXTX regardless of the 
> serial port implementation, platform, etc..  However, if you can come up 
> with a general design and a reference implementation for one subsystem, 
> I'd like to see it and might get on board.

Actually, I wasn't even thinking about all this stuff when I wrote the first
message on the subject :) Now that you mention it - well, I'm not sure I can
chew the piece I just tried to bite in reasonable amount of time.

How do you eat an elephant? One bite at a time. If we could agree that a
small step in the specification is acceptable at this time, and express
further intentions, things may start happening.

To put it succinctly:

- Concept of a "port" should be augmented with a concept of a "device". A
device may be attached to a port in an implicit or explicit way.
- Implicitly connected device is exactly what the current scope of the
specification covers. No new functionality is offered.
- Explicitly connected device supports detachable device semantics, just as
other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a
few).
- The input and output streams are not properties of a port now, but
properties of the device attached to the port.
- A mechanism to allow listening for device arrivals and departures must be
made available.

That's it, off the top of my head.

I understand that this goes completely against current javax.comm specs, but
an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be
difficult to implement without disrupting javax.comm compatibility.

One concern is how to deal with the device identity - but there's no general
way of dealing with this at this time, devices may or may not offer identity
discovery.

> Jim

--vt


From joachim at buechse.de  Fri Jun 23 02:12:43 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 23 Jun 2006 10:12:43 +0200
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
Message-ID: <CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>

Hello++ Vadim,

I would like to repeat that your request is best addressed to the  
POSSIX standardization group - or maybe the BSD/Linux maintainers. If  
you convince the BSD or Linux guys to add this kind of functionality  
(they can as most of there VCP drivers are open source), there is a  
certain chance that other vendors will pick it up. I assure you that  
RXTX will happily provide this functionality once it's possible - I'm  
sure there is more than one maintainer that would love to add it.  
Having this concept penetrate the market may take some years though.

SHORT: The solution you would like to see could be added to the API  
but it can not be implemented (at least not on the platforms I know).  
There are currently no hooks in the kernel that allow you to discover  
"the device" or even the "means of connection" based on an existing  
"device file descriptor" ie COM-port or /dev/... entry. The name  
mapping of the device is handled by the virtual com port driver of  
the device. Unless you are suggesting RXTX should reimplement virtual  
com port drivers for all usb/serial bridges out there your request is  
understandable from a users viewpoint but simply not realizable. It's  
like asking that the Socket api should identify the computer behind  
an IP address (ie by its Ethernet address). While this COULD be  
implemented in TCP/IP, it IS not, and hence there is no point adding  
such a function to the Socket API.

The current trend for USB/Bluetooth/Irda/etc connected devices is  
going away from serial port abstraction towards RPC (ie the drivers  
provide a device specific or device class specific driver that  
provides an application level api to the device functions). The line  
level protocol is often not even published.

Best regards,
Joachim

On 22.06.2006, at 23:40, Vadim Tkachenko wrote:

> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote:
>>
>> Vadim Tkachenko wrote:
>>> Hello again,
>>>
>>> And while I'm at it, why don't just say this: give me one good  
>>> reason to
>>> write 3+ different ways of handling removable devices, one for  
>>> USB, one for
>>> FireWire, one for serial...
>>
>> You don't, they're all the same "I have lost communication with my
>> serial device".
>
> "I have lost communication with my ${protocol} device".
>
>> The only thing you could really do is improve error reporting by  
>> knowing
>> the exact sub-system.  ("Device X which is/was attached to USB  
>> port Y is
>> no longer functioning, please check the USB ports, the device, the
>> cables and anything else you can think of that may be a cause of
>> failure.")
>
> "Device ${id} which is/was attached to ${protocol} port ${port} is  
> no longer
> functioning, please check the ${protocol} ports, the device, the
> ${protocol_media} and anything else you can think of that may be a  
> cause of
> failure".
>
>>  That just requires an intelligent description of the port.
>
> Agree absolutely.
>
>>> I understand very well that this goes way beyond the scope of  
>>> RxTx and
>>> CommAPI and will require cooperation between them and javax.usb  
>>> and whatever
>>> JSR is responsible for FireWire implementation - but the end  
>>> result is well
>>> worth it. Abstract out and generalize arrival/departure/ 
>>> monitoring/discovery
>>> API, provide protocol specific extensions for each, live happily  
>>> ever after.
>>
>> There's a huge list of pseudo-serial devices each with a different  
>> set
>> of requirements, Bluetooth, RFC 2217, a host of proprietary systems,
>> etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I
>> have no clue how you'd implement them in a general/cross platform  
>> sense.
>
> That's because some of the protocols were created decades ago when
> autoconfiguration wasn't even conceived, much less practical. RS232/ 
> RS485
> don't have a clue about identity discovery, and even capabilities  
> discovery
> beyond obvious 8N1 etc.
>
> I agree that today all these protocols have generally incompatible
> strategies for handling the situations I'm trying to address, but  
> there's
> nothing that says it's not an oversight. Besides, we're dealing  
> with the
> devices at a level of abstraction that allows some simplifications and
> generalizations, at least part of the time - unless it's the protocol
> specific features we're dealing with.
>
>> You haven't convinced me (and only me, others may see something  
>> that I
>> don't, I'm not speaking for them) that this mechanism can be  
>> implemented
>> in any practical sense.  That is, that the implementation could be  
>> wide
>> enough to be consider generally available in RXTX regardless of the
>> serial port implementation, platform, etc..  However, if you can  
>> come up
>> with a general design and a reference implementation for one  
>> subsystem,
>> I'd like to see it and might get on board.
>
> Actually, I wasn't even thinking about all this stuff when I wrote  
> the first
> message on the subject :) Now that you mention it - well, I'm not  
> sure I can
> chew the piece I just tried to bite in reasonable amount of time.
>
> How do you eat an elephant? One bite at a time. If we could agree  
> that a
> small step in the specification is acceptable at this time, and  
> express
> further intentions, things may start happening.
>
> To put it succinctly:
>
> - Concept of a "port" should be augmented with a concept of a  
> "device". A
> device may be attached to a port in an implicit or explicit way.
> - Implicitly connected device is exactly what the current scope of the
> specification covers. No new functionality is offered.
> - Explicitly connected device supports detachable device semantics,  
> just as
> other protocols do (USB, FireWire, Wireless USB, Bluetooth, to  
> mention a
> few).
> - The input and output streams are not properties of a port now, but
> properties of the device attached to the port.
> - A mechanism to allow listening for device arrivals and departures  
> must be
> made available.
>
> That's it, off the top of my head.
>
> I understand that this goes completely against current javax.comm  
> specs, but
> an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern )  
> won't be
> difficult to implement without disrupting javax.comm compatibility.
>
> One concern is how to deal with the device identity - but there's  
> no general
> way of dealing with this at this time, devices may or may not offer  
> identity
> discovery.
>
>> Jim
>
> --vt
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From vt at freehold.crocodile.org  Fri Jun 23 11:28:29 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Fri, 23 Jun 2006 10:28:29 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
	<CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
Message-ID: <20060623172829.GA5335@freehold.crocodile.org>

Hello Joachim,

> I would like to repeat that your request is best addressed to the POSSIX
> standardization group - or maybe the BSD/Linux maintainers. If you
> convince the BSD or Linux guys to add this kind of functionality (they can
> as most of there VCP drivers are open source), there is a certain chance
> that other vendors will pick it up. I assure you that RXTX will happily
> provide this functionality once it's possible - I'm sure there is more
> than one maintainer that would love to add it.

I realize this thing is bigger than RxTx itself, and I'm afraid it's too
global not to cause people to laugh before they think about it :)

> Having this concept penetrate the market may take some years though.

Well, I'm sure it'll get there, the only question is - when.

> SHORT: The solution you would like to see could be added to the API but it
> can not be implemented (at least not on the platforms I know).

I guess I'm concerned about the abstraction more than I'm concerned about
the implementation at this point.
  
> There are currently no hooks in the kernel that allow you to discover  
> "the device" or even the "means of connection" based on an existing  
> "device file descriptor" ie COM-port or /dev/... entry.

Well, I'm not so sure you need to keep the literal mapping from /dev
namespace to your device namespace. As long as you can consistently offer a
virtual serial device on top of a virtual serial port, it may be irrelevant
whether you can map it into /dev. The mapping is going be schitzofrenic
anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the
representation...

> The name mapping of the device is handled by the virtual com port driver
> of the device. Unless you are suggesting RXTX should reimplement virtual
> com port drivers for all usb/serial bridges out there your request is
> understandable from a users viewpoint but simply not realizable.

It's not so much a request but rather an offer of participation. I run a few
projects actively using serial communications, as well as USB device
drivers, in different degrees of readiness (Servomaster, Haywire, DIY
Zoning) - and it would be a perfect playground.

You mentioned above that this task is about two things: a) abstraction b)
implementation. I could start the abstraction part of it without changing
the current CommAPI, on top of it, as an adapter. Even if the removable
device semantics are not implemented, but offered, this is already a step
forward.

> It's like asking that the Socket api should identify the computer behind
> an IP address (ie by its Ethernet address). While this COULD be
> implemented in TCP/IP, it IS not, and hence there is no point adding such
> a function to the Socket API.

Thank you for bringing up this example - I guess this is just about the same
thing that I'd like to see. Socket transparently provides you with the
input/output streams, at the same time offering protocol level specifics to
you.

> The current trend for USB/Bluetooth/Irda/etc connected devices is going
> away from serial port abstraction towards RPC (ie the drivers provide a
> device specific or device class specific driver that provides an
> application level api to the device functions). The line level protocol is
> often not even published.

I can't say I'm that happy with it. The best (or, rather, worst) example is
suchlike support for the Phidget servo controller - zealous Linux developers
implemented kernel module support for it, completely hijacking a possibility
of using it on a different level (it's somewhat fixed by now, thankfully).

I believe that whenever an abstraction is offered, it must be made optional
and/or pluggable so it can be replaced by something more suited to the task.

The nature of Java applications is such that they'd probably care much more
about Java API offered, than about no matter how rich application level api
that is offered outside of Java. I've dealt with JNI adapters in the past,
and whereas they can be made reasonably stable, the very fact that you are
forced to deal with things that are not on the critical timing/memory path
and could've been done much easier in Java causes endless grief.

> Joachim

--vt


From lyon at docjava.com  Sat Jun 24 04:54:12 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Sat, 24 Jun 2006 06:54:12 -0400
Subject: [Rxtx] jsr
In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
	<CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
	<20060623172829.GA5335@freehold.crocodile.org>
Message-ID: <p060204a3c0c2c9dde4f8@[192.168.1.152]>

Hi All,
I have had some off-list discussion with Trent.
Opening up a JSR with Sun, as per Peters' suggestion
seems like a reasonable idea, to us.

Does anyone having any concerns about the JSR process
that they would like to raise?

Thanks!
  - Doug



From the.grey.lantern at gmail.com  Sat Jun 24 18:15:26 2006
From: the.grey.lantern at gmail.com (Craig Nicoll)
Date: Sun, 25 Jun 2006 01:15:26 +0100
Subject: [Rxtx] Cannot create virtual serial port
Message-ID: <a1221cc50606241715g2d1e2af6r747347dd4c20e997@mail.gmail.com>

Hello,

This is my first post on this mailing list and I hope someone can help me.

I am having great difficult establishing a virtual serial port for the
Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia
7600.

Every time I try to run the SendMessage program that comes with SMSLib, I
get the following exception: gnu.io.NoSuchPortException

The port names I have tried are:
rfcomm0
rfcomm
/dev/rfcomm0
/dev/rfcomm

This is what I have done so far:
Modified /etc/bluetooth/rfcomm.conf to include the address of my phone:

rfcomm0 {
# Automatically bind the device at startup
bind no;

# Bluetooth address of the device
device 00:0e:6d:7a:98:43;

# RFCOMM channel for the connection
channel 1;

# Description of the connection
comment "Example Bluetooth device";
}

I also tried running the following command: rfcomm bind /dev/rfcomm0

I have searched the mailing list archives and found this post where someone
had a very similar problem to me:
http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried
changing the system properties as suggested and it made no difference.

I have also been scouring Google all day to no avail.

I would be incredibly grateful if anyone could give me some tips.

Thank you,

Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060625/cfa6df35/attachment-0007.html

From tjarvi at qbang.org  Sun Jun 25 19:56:08 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT)
Subject: [Rxtx] Pending release
Message-ID: <Pine.LNX.4.61.0606251942460.15744@www>


With frustration, I was unable to get to the pending release this weekend.
The release should be comming this next week once things calm down.
The source is in CVS except for a fix for multiple ports in windows.

I had planned on doing the release this weekend but that was disrupted by 
my transportation failing in a spectacular fashion.

--
Trent Jarvi
tjarvi at qbang.org


From Pawan.Kharbanda at dot.state.co.us  Tue Jun 27 22:28:51 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 27 Jun 2006 22:28:51 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>

 Trent, 
   I have an application running in a cluster in linux environment and I
am using RXTX2.1.7 (final) with JDK1.5. The application opens and closes
serial comm ports every 30 seconds and exchanges datas. I have
experienced some of my Comm Ports are left hanging (I can see the
LCK..cufXX lock files under /var/lock folder). On putting the debugs I
found out that, it is stuck at a native call line 809 in RXTXPort.java
class (Please see the code snippet below). Can you help me explain what
this method does in the native code? Am I getting into some thread
deadlocks? Thanks in advance.

Pawan Kharbanda 


public void removeEventListener()
	{
		if (debug)
			z.reportln( "RXTXPort:removeEventListener()
called");
		waitForTheNativeCodeSilly();
		//if( monThread != null && monThread.isAlive() )
		if( monThreadisInterrupted == true )
		{
			z.reportln( "	RXTXPort:removeEventListener()
already interrupted");
			monThread = null;
			SPEventListener = null;
			return;
		}
		else if( monThread != null && monThread.isAlive() )
		{
			if (debug)
				z.reportln( "
RXTXPort:Interrupt=true");
			monThreadisInterrupted=true;
			/*
			   Notify all threads in this PID that something
is up
			   They will call back to see if its their
thread
			   using isInterrupted().
			*/
			if (debug)
				z.reportln( "	RXTXPort:calling
interruptEventLoop");
// LINE 809			interruptEventLoop( ); It never returns
out of this 
			
			if (debug)
				z.reportln( "	RXTXPort:calling
monThread.join()");
			try {
				monThread.join(1000);
			} catch (Exception ex) {
				/* yikes */
				ex.printStackTrace();
			}
			if (debug)
				z.reportln( "	RXTXPort:waiting on
isAlive()");
			while( monThread.isAlive() )
			{
				if ( debug )
					z.reportln( "	MonThread is
still alive!");
				try {
					monThread.join(1000);
					Thread.sleep( 1000 );
				} catch( Exception e ){} 
				//monThread.stop();
			}
			
		}
		if (debug)
			z.reportln( "	RXTXPort:calling gc()");
		monThread = null;
		SPEventListener = null;
		MonitorThreadLock = false;
		MonitorThreadAlive=false;
		monThreadisInterrupted=true;
		z.reportln( "RXTXPort:removeEventListener() returning");
	} 

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Sunday, June 25, 2006 7:56 PM
To: rxtx at qbang.org
Subject: [Rxtx] Pending release


With frustration, I was unable to get to the pending release this
weekend.
The release should be comming this next week once things calm down.
The source is in CVS except for a fix for multiple ports in windows.

I had planned on doing the release this weekend but that was disrupted
by my transportation failing in a spectacular fashion.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Wed Jun 28 04:17:29 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 28 Jun 2006 04:17:29 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606280406330.9561@www>



Hi Pawan

You may have found a deadlock but I've not seen on recently on linux.

If you can, please update from CVS.  This will have some close fixes. 
I'm running with the same code as is in CVS.  It is not perfect but I've 
not seen anything like you mention.  Be sure to set timeouts and 
thresholds on the port.  It may be that the port is waiting on pending io 
that never happens.  I think the CVS patches deal with this also but it 
looks like your in a better test environment to know for sure.

The exploded vehicle mentioned below is expected to be fixed today.  It 
was just a ninja small radiator hose.  The pressure test afterwards 
created its own set of problems.  Until this is resolved, I'm spending 
most of my free time commuting by bicycle.

On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>   I have an application running in a cluster in linux environment and I
> am using RXTX2.1.7 (final) with JDK1.5. The application opens and closes
> serial comm ports every 30 seconds and exchanges datas. I have
> experienced some of my Comm Ports are left hanging (I can see the
> LCK..cufXX lock files under /var/lock folder). On putting the debugs I
> found out that, it is stuck at a native call line 809 in RXTXPort.java
> class (Please see the code snippet below). Can you help me explain what
> this method does in the native code? Am I getting into some thread
> deadlocks? Thanks in advance.
>
> Pawan Kharbanda
>
>
> public void removeEventListener()
> 	{
> 		if (debug)
> 			z.reportln( "RXTXPort:removeEventListener()
> called");
> 		waitForTheNativeCodeSilly();
> 		//if( monThread != null && monThread.isAlive() )
> 		if( monThreadisInterrupted == true )
> 		{
> 			z.reportln( "	RXTXPort:removeEventListener()
> already interrupted");
> 			monThread = null;
> 			SPEventListener = null;
> 			return;
> 		}
> 		else if( monThread != null && monThread.isAlive() )
> 		{
> 			if (debug)
> 				z.reportln( "
> RXTXPort:Interrupt=true");
> 			monThreadisInterrupted=true;
> 			/*
> 			   Notify all threads in this PID that something
> is up
> 			   They will call back to see if its their
> thread
> 			   using isInterrupted().
> 			*/
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> interruptEventLoop");
> // LINE 809			interruptEventLoop( ); It never returns
> out of this
>
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> monThread.join()");
> 			try {
> 				monThread.join(1000);
> 			} catch (Exception ex) {
> 				/* yikes */
> 				ex.printStackTrace();
> 			}
> 			if (debug)
> 				z.reportln( "	RXTXPort:waiting on
> isAlive()");
> 			while( monThread.isAlive() )
> 			{
> 				if ( debug )
> 					z.reportln( "	MonThread is
> still alive!");
> 				try {
> 					monThread.join(1000);
> 					Thread.sleep( 1000 );
> 				} catch( Exception e ){}
> 				//monThread.stop();
> 			}
>
> 		}
> 		if (debug)
> 			z.reportln( "	RXTXPort:calling gc()");
> 		monThread = null;
> 		SPEventListener = null;
> 		MonitorThreadLock = false;
> 		MonitorThreadAlive=false;
> 		monThreadisInterrupted=true;
> 		z.reportln( "RXTXPort:removeEventListener() returning");
> 	}
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Sunday, June 25, 2006 7:56 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] Pending release
>
>
> With frustration, I was unable to get to the pending release this
> weekend.
> The release should be comming this next week once things calm down.
> The source is in CVS except for a fix for multiple ports in windows.
>
> I had planned on doing the release this weekend but that was disrupted
> by my transportation failing in a spectacular fashion.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From Pawan.Kharbanda at dot.state.co.us  Wed Jun 28 12:11:06 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Wed, 28 Jun 2006 12:11:06 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>

Trent,
    Again thanks for the reply. First of all I have Receive timeouts set
on all communications including Max no of bytes to expect during the
call. I have noticed the problem is during "closing the connection". I
am not sure if the RXTX is 100% thread-safe yet. There seems to be a
glitch in the native calls. I am sure I have the latest code I did the
update on the Version 2.1.7 from CVS, is this where the latest updates
are located, I have noticed another version in CVS "rxtx-devel".

Regards
Pawan Kharbanda

    

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Wednesday, June 28, 2006 4:17 AM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports



Hi Pawan

You may have found a deadlock but I've not seen on recently on linux.

If you can, please update from CVS.  This will have some close fixes. 
I'm running with the same code as is in CVS.  It is not perfect but I've
not seen anything like you mention.  Be sure to set timeouts and
thresholds on the port.  It may be that the port is waiting on pending
io that never happens.  I think the CVS patches deal with this also but
it looks like your in a better test environment to know for sure.

The exploded vehicle mentioned below is expected to be fixed today.  It
was just a ninja small radiator hose.  The pressure test afterwards
created its own set of problems.  Until this is resolved, I'm spending
most of my free time commuting by bicycle.

On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>   I have an application running in a cluster in linux environment and 
> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and 
> closes serial comm ports every 30 seconds and exchanges datas. I have 
> experienced some of my Comm Ports are left hanging (I can see the 
> LCK..cufXX lock files under /var/lock folder). On putting the debugs I

> found out that, it is stuck at a native call line 809 in RXTXPort.java

> class (Please see the code snippet below). Can you help me explain 
> what this method does in the native code? Am I getting into some 
> thread deadlocks? Thanks in advance.
>
> Pawan Kharbanda
>
>
> public void removeEventListener()
> 	{
> 		if (debug)
> 			z.reportln( "RXTXPort:removeEventListener()
called");
> 		waitForTheNativeCodeSilly();
> 		//if( monThread != null && monThread.isAlive() )
> 		if( monThreadisInterrupted == true )
> 		{
> 			z.reportln( "	RXTXPort:removeEventListener()
> already interrupted");
> 			monThread = null;
> 			SPEventListener = null;
> 			return;
> 		}
> 		else if( monThread != null && monThread.isAlive() )
> 		{
> 			if (debug)
> 				z.reportln( "
> RXTXPort:Interrupt=true");
> 			monThreadisInterrupted=true;
> 			/*
> 			   Notify all threads in this PID that something
is up
> 			   They will call back to see if its their
thread
> 			   using isInterrupted().
> 			*/
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> interruptEventLoop");
> // LINE 809			interruptEventLoop( ); It never returns
> out of this
>
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> monThread.join()");
> 			try {
> 				monThread.join(1000);
> 			} catch (Exception ex) {
> 				/* yikes */
> 				ex.printStackTrace();
> 			}
> 			if (debug)
> 				z.reportln( "	RXTXPort:waiting on
> isAlive()");
> 			while( monThread.isAlive() )
> 			{
> 				if ( debug )
> 					z.reportln( "	MonThread is
> still alive!");
> 				try {
> 					monThread.join(1000);
> 					Thread.sleep( 1000 );
> 				} catch( Exception e ){}
> 				//monThread.stop();
> 			}
>
> 		}
> 		if (debug)
> 			z.reportln( "	RXTXPort:calling gc()");
> 		monThread = null;
> 		SPEventListener = null;
> 		MonitorThreadLock = false;
> 		MonitorThreadAlive=false;
> 		monThreadisInterrupted=true;
> 		z.reportln( "RXTXPort:removeEventListener() returning");
> 	}
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf

> Of Trent Jarvi
> Sent: Sunday, June 25, 2006 7:56 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] Pending release
>
>
> With frustration, I was unable to get to the pending release this 
> weekend.
> The release should be comming this next week once things calm down.
> The source is in CVS except for a fix for multiple ports in windows.
>
> I had planned on doing the release this weekend but that was disrupted

> by my transportation failing in a spectacular fashion.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Wed Jun 28 12:26:21 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 28 Jun 2006 12:26:21 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606281222420.9561@www>


Hi Pawan

If you did a cvs update from the 2.1-7 tar ball, you have the current 
version.  All rxtx in CVS is under rxtx-devel.  The 2.1-7 just has -r
commapi-0-0-1.

You may well have found something.  I have seen win32 fail on closing 
ports but not linux that I can think of.  Your use is much different than 
I normally see too.

Could you give us more information on how we would reproduce this and the 
frequency?


On Wed, 28 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>    Again thanks for the reply. First of all I have Receive timeouts set
> on all communications including Max no of bytes to expect during the
> call. I have noticed the problem is during "closing the connection". I
> am not sure if the RXTX is 100% thread-safe yet. There seems to be a
> glitch in the native calls. I am sure I have the latest code I did the
> update on the Version 2.1.7 from CVS, is this where the latest updates
> are located, I have noticed another version in CVS "rxtx-devel".
>
> Regards
> Pawan Kharbanda
>
>
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Wednesday, June 28, 2006 4:17 AM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] Locked Ports
>
>
>
> Hi Pawan
>
> You may have found a deadlock but I've not seen on recently on linux.
>
> If you can, please update from CVS.  This will have some close fixes.
> I'm running with the same code as is in CVS.  It is not perfect but I've
> not seen anything like you mention.  Be sure to set timeouts and
> thresholds on the port.  It may be that the port is waiting on pending
> io that never happens.  I think the CVS patches deal with this also but
> it looks like your in a better test environment to know for sure.
>
> The exploded vehicle mentioned below is expected to be fixed today.  It
> was just a ninja small radiator hose.  The pressure test afterwards
> created its own set of problems.  Until this is resolved, I'm spending
> most of my free time commuting by bicycle.
>
> On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:
>
>> Trent,
>>   I have an application running in a cluster in linux environment and
>> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and
>> closes serial comm ports every 30 seconds and exchanges datas. I have
>> experienced some of my Comm Ports are left hanging (I can see the
>> LCK..cufXX lock files under /var/lock folder). On putting the debugs I
>
>> found out that, it is stuck at a native call line 809 in RXTXPort.java
>
>> class (Please see the code snippet below). Can you help me explain
>> what this method does in the native code? Am I getting into some
>> thread deadlocks? Thanks in advance.
>>
>> Pawan Kharbanda
>>
>>
>> public void removeEventListener()
>> 	{
>> 		if (debug)
>> 			z.reportln( "RXTXPort:removeEventListener()
> called");
>> 		waitForTheNativeCodeSilly();
>> 		//if( monThread != null && monThread.isAlive() )
>> 		if( monThreadisInterrupted == true )
>> 		{
>> 			z.reportln( "	RXTXPort:removeEventListener()
>> already interrupted");
>> 			monThread = null;
>> 			SPEventListener = null;
>> 			return;
>> 		}
>> 		else if( monThread != null && monThread.isAlive() )
>> 		{
>> 			if (debug)
>> 				z.reportln( "
>> RXTXPort:Interrupt=true");
>> 			monThreadisInterrupted=true;
>> 			/*
>> 			   Notify all threads in this PID that something
> is up
>> 			   They will call back to see if its their
> thread
>> 			   using isInterrupted().
>> 			*/
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> interruptEventLoop");
>> // LINE 809			interruptEventLoop( ); It never returns
>> out of this
>>
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> monThread.join()");
>> 			try {
>> 				monThread.join(1000);
>> 			} catch (Exception ex) {
>> 				/* yikes */
>> 				ex.printStackTrace();
>> 			}
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:waiting on
>> isAlive()");
>> 			while( monThread.isAlive() )
>> 			{
>> 				if ( debug )
>> 					z.reportln( "	MonThread is
>> still alive!");
>> 				try {
>> 					monThread.join(1000);
>> 					Thread.sleep( 1000 );
>> 				} catch( Exception e ){}
>> 				//monThread.stop();
>> 			}
>>
>> 		}
>> 		if (debug)
>> 			z.reportln( "	RXTXPort:calling gc()");
>> 		monThread = null;
>> 		SPEventListener = null;
>> 		MonitorThreadLock = false;
>> 		MonitorThreadAlive=false;
>> 		monThreadisInterrupted=true;
>> 		z.reportln( "RXTXPort:removeEventListener() returning");
>> 	}
>>
>> -----Original Message-----
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
>
>> Of Trent Jarvi
>> Sent: Sunday, June 25, 2006 7:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] Pending release
>>
>>
>> With frustration, I was unable to get to the pending release this
>> weekend.
>> The release should be comming this next week once things calm down.
>> The source is in CVS except for a fix for multiple ports in windows.
>>
>> I had planned on doing the release this weekend but that was disrupted
>
>> by my transportation failing in a spectacular fashion.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From Pawan.Kharbanda at dot.state.co.us  Wed Jun 28 15:42:49 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Wed, 28 Jun 2006 15:42:49 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>

Trent,
    I will try to explain how I am setup and will try to write you a
Sample code little later to reproduce this. On our system we have
DigiBoxes installed on the 2 Linux servers. Both of them have RXTX2.1-7
version installed with the JRE(1.5) and both the machines have the same
port mappings in gnu.io.rxtx.properties (Currently in the production
system I have 64 ports). This is how the system works:

1) A thick Map based client initiates a Action on the Device on the
field. One of the Thread Workers(Asynchronous Call) in the Cluster picks
up the request. 
2) Once the worker gets the request it locks the Device and
Communication port in the DB's(These are our persistent locks, because
most of the devices do one to one communication with the serial ports).
After that the worker (or Comm Server) opens up the connection and after
exchanging the information calls the "Close" and returns.
3) Once the connection is closed , the DB lock is removed on the comm
port and is made available to accept future calls. Here is where the
glitch is the Serial Comm Close method never returns due to the
deadlock. 

I have noticed that the deadlocks are very inconsistent, sometime it
happens right away as soon as Application server starts and sometimes I
don't see any deadlocks for days, but it happens for sure. 

Here is how you can test if you have resources/ test environment. Write
a program and try to open/close  different ports(I will say have a
minimum of four) randomly and very frequently(may be 30 seconds), I am
pretty sure you will see the deadlocks and it happens in the native call
to interrptEventLoop in RXTXPort.java in removeEventListener() method
call.

Also I have noticed that the JVM carshes (without any memrory errors or
JVM errors. Its just not there) when native call is made to eventLoop()
in run() method in MonitorThread inner class. I am still investigating
why this is happening, but at this point I can just tell you the
location. You might have a question How I am so sure about the location?
My application is configured with Log4J and I have enabled the debugs on
the RXTXPort.java, so every time my JVM dies I see these logs at the end
of the file.

"2006-06-28 15:27:15,183 INFO  [STDOUT] RXTXPort:RXTXPort(/dev/cub01)
called
2006-06-28 15:27:15,218 INFO  [STDOUT]
RXTXPort:MontitorThread:MonitorThread()
2006-06-28 15:27:15,219 INFO  [STDOUT] RXTXPort:MontitorThread:run()"

I surely do have a luxury of a testing environment(ports, devices etc.)
and can help you fix these problems? Please advise me how we can resolve
these issues.

Thanks 
Pawan Kharbanda
303-478-2991





-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Wednesday, June 28, 2006 12:26 PM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports


Hi Pawan

If you did a cvs update from the 2.1-7 tar ball, you have the current
version.  All rxtx in CVS is under rxtx-devel.  The 2.1-7 just has -r
commapi-0-0-1.

You may well have found something.  I have seen win32 fail on closing
ports but not linux that I can think of.  Your use is much different
than I normally see too.

Could you give us more information on how we would reproduce this and
the frequency?


On Wed, 28 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>    Again thanks for the reply. First of all I have Receive timeouts
set
> on all communications including Max no of bytes to expect during the
> call. I have noticed the problem is during "closing the connection". I
> am not sure if the RXTX is 100% thread-safe yet. There seems to be a
> glitch in the native calls. I am sure I have the latest code I did the
> update on the Version 2.1.7 from CVS, is this where the latest updates
> are located, I have noticed another version in CVS "rxtx-devel".
>
> Regards
> Pawan Kharbanda
>
>
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Wednesday, June 28, 2006 4:17 AM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] Locked Ports
>
>
>
> Hi Pawan
>
> You may have found a deadlock but I've not seen on recently on linux.
>
> If you can, please update from CVS.  This will have some close fixes.
> I'm running with the same code as is in CVS.  It is not perfect but
I've
> not seen anything like you mention.  Be sure to set timeouts and
> thresholds on the port.  It may be that the port is waiting on pending
> io that never happens.  I think the CVS patches deal with this also
but
> it looks like your in a better test environment to know for sure.
>
> The exploded vehicle mentioned below is expected to be fixed today.
It
> was just a ninja small radiator hose.  The pressure test afterwards
> created its own set of problems.  Until this is resolved, I'm spending
> most of my free time commuting by bicycle.
>
> On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:
>
>> Trent,
>>   I have an application running in a cluster in linux environment and
>> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and
>> closes serial comm ports every 30 seconds and exchanges datas. I have
>> experienced some of my Comm Ports are left hanging (I can see the
>> LCK..cufXX lock files under /var/lock folder). On putting the debugs
I
>
>> found out that, it is stuck at a native call line 809 in
RXTXPort.java
>
>> class (Please see the code snippet below). Can you help me explain
>> what this method does in the native code? Am I getting into some
>> thread deadlocks? Thanks in advance.
>>
>> Pawan Kharbanda
>>
>>
>> public void removeEventListener()
>> 	{
>> 		if (debug)
>> 			z.reportln( "RXTXPort:removeEventListener()
> called");
>> 		waitForTheNativeCodeSilly();
>> 		//if( monThread != null && monThread.isAlive() )
>> 		if( monThreadisInterrupted == true )
>> 		{
>> 			z.reportln( "	RXTXPort:removeEventListener()
>> already interrupted");
>> 			monThread = null;
>> 			SPEventListener = null;
>> 			return;
>> 		}
>> 		else if( monThread != null && monThread.isAlive() )
>> 		{
>> 			if (debug)
>> 				z.reportln( "
>> RXTXPort:Interrupt=true");
>> 			monThreadisInterrupted=true;
>> 			/*
>> 			   Notify all threads in this PID that something
> is up
>> 			   They will call back to see if its their
> thread
>> 			   using isInterrupted().
>> 			*/
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> interruptEventLoop");
>> // LINE 809			interruptEventLoop( ); It never returns
>> out of this
>>
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> monThread.join()");
>> 			try {
>> 				monThread.join(1000);
>> 			} catch (Exception ex) {
>> 				/* yikes */
>> 				ex.printStackTrace();
>> 			}
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:waiting on
>> isAlive()");
>> 			while( monThread.isAlive() )
>> 			{
>> 				if ( debug )
>> 					z.reportln( "	MonThread is
>> still alive!");
>> 				try {
>> 					monThread.join(1000);
>> 					Thread.sleep( 1000 );
>> 				} catch( Exception e ){}
>> 				//monThread.stop();
>> 			}
>>
>> 		}
>> 		if (debug)
>> 			z.reportln( "	RXTXPort:calling gc()");
>> 		monThread = null;
>> 		SPEventListener = null;
>> 		MonitorThreadLock = false;
>> 		MonitorThreadAlive=false;
>> 		monThreadisInterrupted=true;
>> 		z.reportln( "RXTXPort:removeEventListener() returning");
>> 	}
>>
>> -----Original Message-----
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On
Behalf
>
>> Of Trent Jarvi
>> Sent: Sunday, June 25, 2006 7:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] Pending release
>>
>>
>> With frustration, I was unable to get to the pending release this
>> weekend.
>> The release should be comming this next week once things calm down.
>> The source is in CVS except for a fix for multiple ports in windows.
>>
>> I had planned on doing the release this weekend but that was
disrupted
>
>> by my transportation failing in a spectacular fashion.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx 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 khattar31 at yahoo.com  Wed Jun 28 22:04:59 2006
From: khattar31 at yahoo.com (rahul khattar)
Date: Wed, 28 Jun 2006 21:04:59 -0700 (PDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
Message-ID: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>

Hi All,

I was looking at the src file on the last release.
I did notice a missing header file while trying to
compile the parallelport.dll. Would somebody be kind
enoughf to share the missing header file:
gnu_io_LPRPort.h

I am using MinGw to compile the same from Parinya
(which is an execellent tool)


Regards,
Rahul Khattar

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Thu Jun 29 03:43:53 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 03:43:53 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>
References: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606290341210.9561@www>

On Wed, 28 Jun 2006, rahul khattar wrote:

> Hi All,
>
> I was looking at the src file on the last release.
> I did notice a missing header file while trying to
> compile the parallelport.dll. Would somebody be kind
> enoughf to share the missing header file:
> gnu_io_LPRPort.h
>
> I am using MinGw to compile the same from Parinya
> (which is an execellent tool)
>

Hi Rahul

The gnu.io_LPRPort.h file is generated with javah.  You can see the 
command in the Makefile I presume.  You do not need rxtxParallel.dll to 
use w32 serial btw.

--
Trent Jarvi
tjarvi at qbang.org


From khattar31 at yahoo.com  Thu Jun 29 04:47:01 2006
From: khattar31 at yahoo.com (rahul khattar)
Date: Thu, 29 Jun 2006 03:47:01 -0700 (PDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606290341210.9561@www>
Message-ID: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>

Hi Trent 
I did notice this file is required in the source file
ParallelImp.c
on line 38

Attached the O/P 

Regards,
Rahul Khattar




--- Trent Jarvi <tjarvi at qbang.org> wrote:

> On Wed, 28 Jun 2006, rahul khattar wrote:
> 
> > Hi All,
> >
> > I was looking at the src file on the last release.
> > I did notice a missing header file while trying to
> > compile the parallelport.dll. Would somebody be
> kind
> > enoughf to share the missing header file:
> > gnu_io_LPRPort.h
> >
> > I am using MinGw to compile the same from Parinya
> > (which is an execellent tool)
> >
> 
> Hi Rahul
> 
> The gnu.io_LPRPort.h file is generated with javah. 
> You can see the 
> command in the Makefile I presume.  You do not need
> rxtxParallel.dll to 
> use w32 serial btw.
> 
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Error.zip
Type: application/x-zip-compressed
Size: 1746 bytes
Desc: 2948039066-Error.zip
Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060629/a5b6f783/Error-0016.bin

From tjarvi at qbang.org  Thu Jun 29 06:16:24 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 06:16:24 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606290614530.9561@www>

On Thu, 29 Jun 2006, rahul khattar wrote:

> Hi Trent
> I did notice this file is required in the source file
> ParallelImp.c
> on line 38
>
> Attached the O/P
>

The command to generate the .h file will be something like:

javah -classpath . -jni gnu.io.LPRPort

The makefile should have this.  There are several approaches to creating 
or using makefiles so I have no idea which one you used if any.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Thu Jun 29 06:20:51 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 06:20:51 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606290616420.9561@www>

> Here is how you can test if you have resources/ test environment. Write
> a program and try to open/close  different ports(I will say have a
> minimum of four) randomly and very frequently(may be 30 seconds), I am
> pretty sure you will see the deadlocks and it happens in the native call
> to interrptEventLoop in RXTXPort.java in removeEventListener() method
> call.

Hi Pawan

I'll try to find a way to reproduce this.  One thing to note is that you 
are using different kernel drivers (digi) to perform this task.  So I 
probably will not be able to reproduce the exact same environment.

In general, multiport kernel drivers have been tested far less than 
typical serial drivers.  This may or may not be an issue.

--
Trent Jarvi
tjarvi at qbang.org



From jhaysonn at gmail.com  Thu Jun 29 12:29:13 2006
From: jhaysonn at gmail.com (jhaysonn pathak)
Date: Thu, 29 Jun 2006 14:29:13 -0400
Subject: [Rxtx] RXTX install
Message-ID: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>

Hi Guys,

I'm doing trying to write a generative piece of Sonic Art using an EEG
plugged into a mac runnning Max/MSP.  I just recently discovered RXTX
drivers in my search for a piece of software that might give me more
output options for my EEG (I'm using the CEO from MindPeak).  I found
Bioera which uses RXTX drivers.  Thing is - I can't figure out how to
install RXTX correctly.

After I build the 'libSerial.jnilib' target inside of
'LibSerial.pbproj' I can't find the libSerial.jnilib file that
accompanies the RXTXcomm.jar nor do I know where to put them.

I also don't understand this part at the bottom of the OS X instructions at all:

"AFTER INSTALLATION VERY IMPORTANT
	check existence of the folder /var/spool/uucp
	if you don't have it create it with command
	sudo mkdir /var/spool/uucp
	permissions should be: drwxrwxr-x
	if they are not do command
	sudo chmod 775 /var/spool/uucp

	YOU should be a member of the uucp group
	you can check it with command
		niutil -readprop / /groups/uucp users
	you should see your name in output of the niutil command
	if you don't do following:
		sudo niutil -appendprop / /groups/uucp users <yourname>
			substitute  <yourname> with your user's name
			for example if your user name is peter:
				sudo niutil -appendprop / /groups/uucp users peter

	NOTES: RXTX.pkg should create uucp folder and insert your name  in
uucp group automatically"



I really appreciate any help that you guys can offer.  I've been
struggling with this for a while now as part of a research grant that
I was awarded.  Thanks again for the help.

Jhaysonn Pathak


From naranjo.manuel at gmail.com  Thu Jun 29 07:19:15 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 10:19:15 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606290614530.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www>
Message-ID: <44A3D353.6010605@gmail.com>

Speaking about Windows Support, I had seen that inside the 
rxtx-2.1-7-bins-r2 package inside Windows directory it says:
"i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will 
not make harm to anyone, and i'm almost sure that someone has noticed it 
before.
Cheers,
Manuel


From joachim at buechse.de  Thu Jun 29 13:25:16 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 29 Jun 2006 21:25:16 +0200
Subject: [Rxtx] RXTX install
In-Reply-To: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>
References: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>
Message-ID: <2A003E42-97E1-4237-8438-646BDE2E3961@buechse.de>

Hello Jhaysonn,

I assume you are trying to use the javax.comm version of RXTX.

Please use "cvs up" to update your download to the latest version of  
the repository. The latest version does not use lock files, so the  
mentioned process is no longer needed. Updating with CVS will also  
provide you with a new README.OSX file that should be simpler to  
understand.

You will find LibSerialUniversal.xcodeproj in MACOSX_IDE/Xcode. Put  
comm.jar (downloaded from Sun) into MACOSX_IDE/Xcode. Compile the  
library. You will find RXTXcomm.jar and librxtxSerial.jnilib in  
MACOSX_IDE/Xcode/build/Default

Best regards,
Joachim
---
Joachim B?chse
Softwarel?sungen und Beratung
Hadlaubsteig 2
CH-8006 Z?rich


On 29.06.2006, at 20:29, jhaysonn pathak wrote:

> Hi Guys,
>
> I'm doing trying to write a generative piece of Sonic Art using an EEG
> plugged into a mac runnning Max/MSP.  I just recently discovered RXTX
> drivers in my search for a piece of software that might give me more
> output options for my EEG (I'm using the CEO from MindPeak).  I found
> Bioera which uses RXTX drivers.  Thing is - I can't figure out how to
> install RXTX correctly.
>
> After I build the 'libSerial.jnilib' target inside of
> 'LibSerial.pbproj' I can't find the libSerial.jnilib file that
> accompanies the RXTXcomm.jar nor do I know where to put them.
>
> I also don't understand this part at the bottom of the OS X  
> instructions at all:
>
> "AFTER INSTALLATION VERY IMPORTANT
> 	check existence of the folder /var/spool/uucp
> 	if you don't have it create it with command
> 	sudo mkdir /var/spool/uucp
> 	permissions should be: drwxrwxr-x
> 	if they are not do command
> 	sudo chmod 775 /var/spool/uucp
>
> 	YOU should be a member of the uucp group
> 	you can check it with command
> 		niutil -readprop / /groups/uucp users
> 	you should see your name in output of the niutil command
> 	if you don't do following:
> 		sudo niutil -appendprop / /groups/uucp users <yourname>
> 			substitute  <yourname> with your user's name
> 			for example if your user name is peter:
> 				sudo niutil -appendprop / /groups/uucp users peter
>
> 	NOTES: RXTX.pkg should create uucp folder and insert your name  in
> uucp group automatically"
>
>
>
> I really appreciate any help that you guys can offer.  I've been
> struggling with this for a while now as part of a research grant that
> I was awarded.  Thanks again for the help.
>
> Jhaysonn Pathak
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From tjarvi at qbang.org  Thu Jun 29 19:30:00 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 19:30:00 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A3D353.6010605@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
Message-ID: <Pine.LNX.4.61.0606291923000.9561@www>

On Thu, 29 Jun 2006, Manuel Naranjo wrote:

> Speaking about Windows Support, I had seen that inside the
> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
> not make harm to anyone, and i'm almost sure that someone has noticed it
> before.

Hi Manuel

         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
     47421  01-30-06 00:23 
rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
     77759  03-01-06 12:01 
rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README


It looks normal to me.  There are no fancy tools used there :)

--
Trent Jarvi
tjarvi at qbang.org

From naranjo.manuel at gmail.com  Thu Jun 29 19:38:16 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 22:38:16 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606291923000.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com> <Pine.LNX.4.61.0606291923000.9561@www>
Message-ID: <44A48088.2040407@gmail.com>

> On Thu, 29 Jun 2006, Manuel Naranjo wrote:
> 
>> Speaking about Windows Support, I had seen that inside the
>> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
>> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
>> not make harm to anyone, and i'm almost sure that someone has noticed it
>> before.
> 
> Hi Manuel
> 
>         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
>         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
>     47421  01-30-06 00:23 
> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
>     77759  03-01-06 12:01 
> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
>       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README
> 
> 
> It looks normal to me.  There are no fancy tools used there :)
> 
Hi Trent:
Is not the i368 representing the name of the Architecture?? If so the 
name should start with i386 it will not break any system, is simply miss
written, I saw that and wanted to report it. It a silly thing.
Ohh I forgoten I must congratulate you for your GREAT libray, I was able 
to make an .exe with JSmooth that launches an application that uses RXTX 
with out the need to install RXTX on users system :). The .exe tells JVM 
where to find the RXTX Library and Binaries. I tried with Sun's Java 
Comm but it was imposible.
Regards,
Manuel


From tjarvi at qbang.org  Thu Jun 29 19:52:45 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 19:52:45 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A48088.2040407@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
	<Pine.LNX.4.61.0606291923000.9561@www> <44A48088.2040407@gmail.com>
Message-ID: <Pine.LNX.4.61.0606291945060.9561@www>

On Thu, 29 Jun 2006, Manuel Naranjo wrote:

>> On Thu, 29 Jun 2006, Manuel Naranjo wrote:
>>
>>> Speaking about Windows Support, I had seen that inside the
>>> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
>>> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
>>> not make harm to anyone, and i'm almost sure that someone has noticed it
>>> before.
>>
>> Hi Manuel
>>
>>         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
>>         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
>>     47421  01-30-06 00:23
>> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
>>     77759  03-01-06 12:01
>> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
>>       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README
>>
>>
>> It looks normal to me.  There are no fancy tools used there :)
>>
> Hi Trent:
> Is not the i368 representing the name of the Architecture?? If so the
> name should start with i386 it will not break any system, is simply miss
> written, I saw that and wanted to report it. It a silly thing.
> Ohh I forgoten I must congratulate you for your GREAT libray, I was able
> to make an .exe with JSmooth that launches an application that uses RXTX
> with out the need to install RXTX on users system :). The .exe tells JVM
> where to find the RXTX Library and Binaries. I tried with Sun's Java
> Comm but it was imposible.

Hi Manuel

The compiler uses only the i386 instruction set for windows.  I doubt 
there will be any measurable advantages with going to later instruction 
sets.  In theory rxtx would run on a 386 but I doubt anyone does that.

So it looks odd but is not a typo.

We could compile to i686 but don't.  The compiler used does not appear to 
be a problem yet so I don't see any point in changing it.  Right now, we 
could not compile 64 bit windows binaries.  gcc/mingw/... do not support 
them that I know of.  People will have to compile those with closed source 
tools on their own until an option is available.

--
Trent Jarvi
tjarvi at qbang.org

From naranjo.manuel at gmail.com  Thu Jun 29 20:00:48 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 23:00:48 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606291945060.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com>	<Pine.LNX.4.61.0606291923000.9561@www>
	<44A48088.2040407@gmail.com> <Pine.LNX.4.61.0606291945060.9561@www>
Message-ID: <44A485D0.7050202@gmail.com>

Trent you did not get my point
The folder says 368 three hundred sixty eight, when
it should say 386 three hundred eighty six. Is simply a miss writting.
Regards,
Manuel


From tjarvi at qbang.org  Thu Jun 29 20:12:15 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 20:12:15 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A485D0.7050202@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
	<Pine.LNX.4.61.0606291923000.9561@www> <44A48088.2040407@gmail.com>
	<Pine.LNX.4.61.0606291945060.9561@www> <44A485D0.7050202@gmail.com>
Message-ID: <Pine.LNX.4.61.0606292008061.9561@www>


On Thu, 29 Jun 2006, Manuel Naranjo wrote:

> Trent you did not get my point
> The folder says 368 three hundred sixty eight, when
> it should say 386 three hundred eighty six. Is simply a miss writting.

hehe..  OK.  My bad.  It's been a long day.

Nevermind :)

--
Trent Jarvi
tjarvi at qbang.org




From naranjo.manuel at gmail.com  Thu Jun 29 20:18:44 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 23:18:44 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606292008061.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com>	<Pine.LNX.4.61.0606291923000.9561@www>
	<44A48088.2040407@gmail.com>	<Pine.LNX.4.61.0606291945060.9561@www>
	<44A485D0.7050202@gmail.com> <Pine.LNX.4.61.0606292008061.9561@www>
Message-ID: <44A48A04.9040401@gmail.com>

Don't worry Trent.
About 64 bits compilation, I would like to colaborate, I have a Pc with 
64 bits, the only problem is that i do not have windows 64 bits 
installed :(.




From Pawan.Kharbanda at dot.state.co.us  Fri Jun 30 08:49:52 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 30 Jun 2006 08:49:52 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E996@hqexchange3.dot.state.co.us>

Trent,  
    Can you explain what the interruptedEventLoop() native method is
doing is there a possibility that method is somehow getting into the
infinite loop(there are 2 while loops without any break statements).
This might be a very basic question how can I debug the native code(or
print the debug statements).  Again thanks for the help. 

Pawan Kharbanda

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Thursday, June 29, 2006 6:21 AM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports

> Here is how you can test if you have resources/ test environment. 
> Write a program and try to open/close  different ports(I will say have

> a minimum of four) randomly and very frequently(may be 30 seconds), I 
> am pretty sure you will see the deadlocks and it happens in the native

> call to interrptEventLoop in RXTXPort.java in removeEventListener() 
> method call.

Hi Pawan

I'll try to find a way to reproduce this.  One thing to note is that you
are using different kernel drivers (digi) to perform this task.  So I
probably will not be able to reproduce the exact same environment.

In general, multiport kernel drivers have been tested far less than
typical serial drivers.  This may or may not be an issue.

--
Trent Jarvi
tjarvi at qbang.org

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From cpine at wrsystems.com  Thu Jun 29 15:17:12 2006
From: cpine at wrsystems.com (Chris Pine)
Date: Thu, 29 Jun 2006 17:17:12 -0400
Subject: [Rxtx]  Controlling Individual Signals DTR and RTS
Message-ID: <MAIL4FJo0S8ACLEBajJ000005cf@mail4.wrsystems.com>

Dear Moussa Ba,
	I hope I am not being too forward, but we are having the exact same
issue with needing to control DTR from RXTX in Linux.  Did you ever have any
luck figuring it out?

Thank you very much for your time,

Chris Pine




From tjarvi at qbang.org  Thu Jun  1 11:13:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 11:13:40 -0600 (MDT)
Subject: [Rxtx] custom baud rate win32
In-Reply-To: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606011107210.30220@www>


Hi Daren

I can't imagine that 1953 is possibly the actual value on the UART.  Maybe 
if your baud base is very high with a custom serial board.  More likely, 
the driver just remembers that what you asked for and did something else.

I'll have more to say on the dcb->BaudRate after I try some things here. 
I have managed to do something like that in the past as a quick hack but 
it was for 14400.  I may have used the CBR_14400.

If we can't access this through the win32 API with protected mode, there 
is another layer of complication.  With real mode, it would be easy.
With protected mode, I assume there would have to be some kernel driver or 
a hook I'm not aware of to access the MCR directly (bang a memory 
addresss).



On Thu, 1 Jun 2006, Daren wrote:

> Trent,
> I have managed to successfully open the port at this speed using Realterm
> (available on sourceforge). From memory this uses DLPortIO.
>
> Using portmon.exe with realterm, even there it says that the port has opened
> at 1953.
>
> I changed termios.c:560 to
> dcb->BaudRate        = 1953 ;
>
> and it still opens the port at 9600.
>
> Daren
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Trent Jarvi
> Sent: Thursday, 1 June 2006 1:44 PM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] custom baud rate win32
>
> On Thu, 1 Jun 2006, Daren wrote:
>
>> Hi all,
>>
>> I downloaded 2.1.7-pre16 and managed to build it and get it going. I made
>> the changes as suggested by Peter Smith in an old post, by adding his code
>> to SerialImpl.c, uncommenting the TIOCGSERIAL and TIOCSSERIAL, and
> defining
>> ASYNC_SPD_CUST which is equal to 0x0030 (according to linus header
> files)..
>>
>>
>> Still not working, it opens the port at 9600 according to portmon.exe .
> Has
>> anyone managed to get this going at a custom rate?
>>
>> Here is the post I'm referring to:
>> http://marc.theaimsgroup.com/?l=rxtx&m=106270038110713&w=2
>>
>>
>> Thanks,
>> Daren
>>
>> ________________________________________
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
>> Daren
>> Sent: Wednesday, 31 May 2006 10:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] (no subject)
>>
>> Hi All,
>> I have been using rxtx for a little while and needed to get it working at
>> 1953, like a past user in the mailing list, who seemed to have got it
>> working by changing some C code.
>>
>> I wanted to build rxtx myself with these changes but don't know where to
>> start. I have windows here and FC4 at home. I downloaded cygwin and
> mingw32,
>> each build works by building a rxtxSerial.dll file that is ~11k smaller
> than
>> the original, and I always get the following error when testing the dll:
>>
>> Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at
>> PC=0x8077655
>> Function=[Unknown.]
>> Library=C:\opt\java\j2sdk1.4.2\jre\bin\client\jvm.dll
>>
>> NOTE: We are unable to locate the function name symbol for the error
>>      just occurred. Please refer to release documentation for possible
>>      reason and solutions.
>>
>>
>> Current Java thread:
>> 	at gnu.io.RXTXPort.open(Native Method)
>> 	- locked <0x1002c800> (a gnu.io.RXTXPort)
>> 	at gnu.io.RXTXPort.<init>(RXTXPort.java:84)
>>
>> Anyone know what im doing wrong?
>>
>>
>>
>>
>
> Hi Daren
>
> You are running into the same rats nest I'm looking at now.
>
> With win32 and specific custom baud rates, I'm not sure how this will go.
> I've got the Linux custom baud rates working very nicely.  I did much like
> the post you linked.  In fact I had forgot about that post.  You probably
> noticed that it becomes a bunch of dirt roads going noplace fast in
> termios.c for w32.
>
> I'm probably only going to get 14400, 28800, 128000 and 256000 working
> with the next release on w32.  I'll look a little further.  If you have an
> example w32 that works at 1953 I'd really like to hear.  Thats an unusual
> baud rate.
>
> Assuming a baud_base of 128000, your divisor will be 65 or 66.
>
> 128000/66=1939 -14
> 128000/65=1969 +13
>
> One thing I've been wondering about with linux is which would be the right
> answer in cases like this.  Right now it would just go with a baud base of
> 65 and ignore the modulus details.
>
> It appears to be a general trend for kernel developers to hide these
> details thinking that they can come up with a general solution.  Then they
> run out of time.  Perahps the solution is to help out but there are
> ultiple OS's rxtx supports making that nontrivial.
>
> If you look at current linux kernels, the 'tricks' above have been marked
> deprecated with no replacement.  Windows has some hard defines and then
> ancient near magic.  I've not looked at Solaris via Open Solaris yet but
> doubt there is a solution at all.
>
> What I'd try since you have the equipment and the monitor software is to
> hardcode the dcb->Baud in termios.c to 1953 (no define) and see what the
> w32 kernel does with it.  I think if you toss a baud rate at the driver it
> will try to come close.  You may try comming closer to a real baudrate
> based upon the 128000 baud base as shown above.
>
> If it works, it is worth looking at the rest of the ping/pong logic then.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
>
>
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From doug at dupreeinc.com  Thu Jun  1 13:22:13 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 12:22:13 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011107210.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
Message-ID: <447F3E65.1020809@dupreeinc.com>

Hello,

I am still trying to get this startup a little faster so I turned on the 
debug of a few of the classes.  The COM ports are scanned really fast 
and the delay occurs during the LPT scan.  The console output looks like 
this:

    ...
      LPT1
      LPT2
      LPT3
     valid port prefixes:
      LPT
    LPT1 LPT
    1 1
    LPT2 LPT
    2 2                                                                 
      * <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
    CommPortIdentifier:addPortName(LPT2)
    CommPortIdentifier:AddIdentifierToList()
    LPT3 LPT
    3 3
    CommPortIdentifier:addPortName(LPT3)
    CommPortIdentifier:AddIdentifierToList()
    CommPortIdentifier:AddIdentifierToList() index.next
    Leaving registerValidPorts()
    Have not implemented native_psmisc_report_owner(PortName)); in
    CommPortIdentifier
    CommPortIdentifier:getPortIdentifier(COM3)
    CommPortIdentifier:open(densConnect, 30000)
    RXTXCommDriver:getCommPort(COM3,1)
    ...

It would seem to me that if I removed the code for port scanning of LPT 
ports I could solve this problem. I would much prefer to use unmodified 
code if at all possible.  Do any of you have alternate suggestions?

Thank you for your time.

Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/cf433ee7/attachment-0017.html

From tjarvi at qbang.org  Thu Jun  1 13:52:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 13:52:06 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F3E65.1020809@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011348380.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I am still trying to get this startup a little faster so I turned on the 
> debug of a few of the classes.  The COM ports are scanned really fast and the 
> delay occurs during the LPT scan.  The console output looks like this:
>
>   ...
>     LPT1
>     LPT2
>     LPT3
>    valid port prefixes:
>     LPT
>   LPT1 LPT
>   1 1
>   LPT2 LPT
>   2 2                                                                      * 
> <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>   CommPortIdentifier:addPortName(LPT2)
>   CommPortIdentifier:AddIdentifierToList()
>   LPT3 LPT
>   3 3
>   CommPortIdentifier:addPortName(LPT3)
>   CommPortIdentifier:AddIdentifierToList()
>   CommPortIdentifier:AddIdentifierToList() index.next
>   Leaving registerValidPorts()
>   Have not implemented native_psmisc_report_owner(PortName)); in
>   CommPortIdentifier
>   CommPortIdentifier:getPortIdentifier(COM3)
>   CommPortIdentifier:open(densConnect, 30000)
>   RXTXCommDriver:getCommPort(COM3,1)
>   ...
>
> It would seem to me that if I removed the code for port scanning of LPT ports 
> I could solve this problem. I would much prefer to use unmodified code if at 
> all possible.  Do any of you have alternate suggestions?
>
> Thank you for your time.
>
> Doug
>


Does commenting out the LPT enumeration actually help?  There can often be 
differences between debug information printed and whats really going on. 
When you combine various environments the debug info can even come out in 
the wrong order.

I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
I do not think this problem is universal.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Thu Jun  1 14:29:44 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:29:44 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4E38.2060004@dupreeinc.com>

I will give it a try.  One thing to note on this PC is it has no LPT 
Parallel ports.

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
>>Hello,
>>
>>I am still trying to get this startup a little faster so I turned on the 
>>debug of a few of the classes.  The COM ports are scanned really fast and the 
>>delay occurs during the LPT scan.  The console output looks like this:
>>
>>  ...
>>    LPT1
>>    LPT2
>>    LPT3
>>   valid port prefixes:
>>    LPT
>>  LPT1 LPT
>>  1 1
>>  LPT2 LPT
>>  2 2                                                                      * 
>><<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>>  CommPortIdentifier:addPortName(LPT2)
>>  CommPortIdentifier:AddIdentifierToList()
>>  LPT3 LPT
>>  3 3
>>  CommPortIdentifier:addPortName(LPT3)
>>  CommPortIdentifier:AddIdentifierToList()
>>  CommPortIdentifier:AddIdentifierToList() index.next
>>  Leaving registerValidPorts()
>>  Have not implemented native_psmisc_report_owner(PortName)); in
>>  CommPortIdentifier
>>  CommPortIdentifier:getPortIdentifier(COM3)
>>  CommPortIdentifier:open(densConnect, 30000)
>>  RXTXCommDriver:getCommPort(COM3,1)
>>  ...
>>
>>It would seem to me that if I removed the code for port scanning of LPT ports 
>>I could solve this problem. I would much prefer to use unmodified code if at 
>>all possible.  Do any of you have alternate suggestions?
>>
>>Thank you for your time.
>>
>>Doug
>>
>>    
>>
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/dd31fed5/attachment-0017.html

From doug at dupreeinc.com  Thu Jun  1 14:36:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:36:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4FC8.9080106@dupreeinc.com>

Trent,

I commented out the section in RegisterScannedPorts() that adds the 
three LPT ports to the CandidateDeviceNames string array.  The 
application started immediately.  This is probably not the way to do 
this, but it was quick ,dirty, and worked.

It would be nice if there was a way to pole the OS to see if there is 
even a port there, though I guess this is what this code is suppose to do...

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
> ...
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From lynn at swcp.com  Thu Jun  1 14:49:34 2006
From: lynn at swcp.com (lynn@swcp.com)
Date: Thu, 1 Jun 2006 20:49:34 -0000
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>,
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <twig.1149194974.97617@swcp.com>

Perhaps we could add an argument to port enumeration where if not specified,
you get the default behavior that looks for everything.  With a new
constructor that has an argument(or more) you could optionally declare it to
not inspect printer ports.

Existing code would work as it always has.  New code could be smarter.

Lynn



Doug Thistlethwaite <doug at dupreeinc.com> said:

> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
> >On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
> >
> >  
> >
> > ...
> >
> >
> >Does commenting out the LPT enumeration actually help?  There can often be 
> >differences between debug information printed and whats really going on. 
> >When you combine various environments the debug info can even come out in 
> >the wrong order.
> >
> >I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
> >I do not think this problem is universal.
> >
> >--
> >Trent Jarvi
> >tjarvi at qbang.org
> >_______________________________________________
> >Rxtx mailing list
> >Rxtx at qbang.org
> >http://mailman.qbang.org/mailman/listinfo/rxtx
> >
> >
> >  
> >
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



-- 





From jredman at ergotech.com  Thu Jun  1 15:20:20 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 01 Jun 2006 15:20:20 -0600
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
Message-ID: <447F5A14.6010803@ergotech.com>

Doug,

If you specifically request ports, eg:

-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

or
 
-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

Depending upon the version  (Windows is COM1:COM2, etc. I assume).

Does it still enumerate the parallel ports?

Jim

Doug Thistlethwaite wrote:
> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
>> On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>
>>  
>>
>> ...
>>
>>
>> Does commenting out the LPT enumeration actually help?  There can often be 
>> differences between debug information printed and whats really going on. 
>> When you combine various environments the debug info can even come out in 
>> the wrong order.
>>
>> I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>> I do not think this problem is universal.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>>
>>  
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  1 16:49:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:49:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6EF4.7080709@dupreeinc.com>

I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
folder.  I created this file and added the following to the file:

gnu.io.rxtx.SerialPorts=COM3

and I get the following error on the console:
CommPortIdentifier:static initialization()
RXTXCommDriver {}
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
RXTXCommDriver:
    Jar version = RXTX-2.1-7
    native lib Version = RXTX-2.1-7
RXTXCommDriver:initialize()
checking for system-known ports of type 1
checking registry for ports of type 1

RXTXCommDriver:addSpecifiedPorts()
Exception in thread "main" java.lang.ExceptionInInitializerError
    at 
densconnect.SerialConnection.openConnection(SerialConnection.java:136)
    at densconnect.DensTalk.<init>(DensTalk.java:165)
    at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
    at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
    at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
    at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
Caused by: java.lang.NullPointerException
    at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
CommPortIdentifier:addPortName(COM3)
CommPortIdentifier:AddIdentifierToList()
CommPortIdentifier:AddIdentifierToList() null
...


It looks like it  read COM3 from the file, but it had the above 
exception that killed it.  The strange this is this error is from 
RXTXCommDriver initialize function (if statement line):

        OS = System.getProperty("os.name");
                System.out.println("OS NAME: " + OS);
        if(OS.toLowerCase().indexOf("linux") == -1)

OS is returning null, thus the error.

If the file is not present, it scans the ports and reads the OS.

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>Doug Thistlethwaite wrote:
>  
>
>>Trent,
>>
>>I commented out the section in RegisterScannedPorts() that adds the 
>>three LPT ports to the CandidateDeviceNames string array.  The 
>>application started immediately.  This is probably not the way to do 
>>this, but it was quick ,dirty, and worked.
>>
>>It would be nice if there was a way to pole the OS to see if there is 
>>even a port there, though I guess this is what this code is suppose to do...
>>
>>Doug
>>
>>Trent Jarvi wrote:
>>
>>    
>>
>>>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>>
>>> 
>>>
>>>...
>>>
>>>
>>>Does commenting out the LPT enumeration actually help?  There can often be 
>>>differences between debug information printed and whats really going on. 
>>>When you combine various environments the debug info can even come out in 
>>>the wrong order.
>>>
>>>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>>>I do not think this problem is universal.
>>>
>>>--
>>>Trent Jarvi
>>>tjarvi at qbang.org
>>>_______________________________________________
>>>Rxtx mailing list
>>>Rxtx at qbang.org
>>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>>
>>>
>>> 
>>>
>>>      
>>>
>>_______________________________________________
>>Rxtx mailing list
>>Rxtx at qbang.org
>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>    
>>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/bf4cca0e/attachment-0017.html

From doug at dupreeinc.com  Thu Jun  1 16:51:26 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:51:26 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6F6E.5060603@dupreeinc.com>

Jim,

I did not try your suggestion as I do not understand where I would put 
these command line parameters (it that is what they are).  It appears 
that using the properties file should do that same thing...

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>
>  
>


From doug at dupreeinc.com  Thu Jun  1 17:56:19 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 16:56:19 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
Message-ID: <447F7EA3.6050400@dupreeinc.com>

I think there is an error in the registerSpecifiedPorts() method.  When 
I have a gnu.io.rxtx.properties file in the ext directory, this function 
kills the System class  IF I call System.getProperty("os.name") before 
the call  to registerSpecifiedPorts(), it returns the os name, after the 
call, it returns null.  I have not played much with properties, except 
for reading them, so I don't really understand the code.

Doug



From doug at dupreeinc.com  Thu Jun  1 18:11:14 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 17:11:14 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F7EA3.6050400@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com>
Message-ID: <447F8222.3060402@dupreeinc.com>

Ok, I just hacked this thing up and got it to read the 
gnu.io.rxtx.properties file.

I commented out the line:
System.setProperties(p); in the method registerSpecifiedPorts() in 
RXTXCommDriver class.  I really don't understand that much about 
properties, but this call kills the System class.

I used the following in the gnu.io.rxtx.properties file:

gnu.io.rxtx.SerialPorts=COM3
gnu.io.rxtx.ParallelPorts=null

This allows the application to open very quickly without any errors.  
Whomever coded this class or somebody who understands properties should 
look at this method and make sure it is doing what they expect.

Doug




Doug Thistlethwaite wrote:

>I think there is an error in the registerSpecifiedPorts() method.  When 
>I have a gnu.io.rxtx.properties file in the ext directory, this function 
>kills the System class  IF I call System.getProperty("os.name") before 
>the call  to registerSpecifiedPorts(), it returns the os name, after the 
>call, it returns null.  I have not played much with properties, except 
>for reading them, so I don't really understand the code.
>
>Doug
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From tjarvi at qbang.org  Thu Jun  1 18:32:50 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 18:32:50 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F6EF4.7080709@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com> <447F6EF4.7080709@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011831510.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
> folder.  I created this file and added the following to the file:
>
> gnu.io.rxtx.SerialPorts=COM3
>
> and I get the following error on the console:
> CommPortIdentifier:static initialization()
> RXTXCommDriver {}
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
> RXTXCommDriver:
>   Jar version = RXTX-2.1-7
>   native lib Version = RXTX-2.1-7
> RXTXCommDriver:initialize()
> checking for system-known ports of type 1
> checking registry for ports of type 1
>
> RXTXCommDriver:addSpecifiedPorts()
> Exception in thread "main" java.lang.ExceptionInInitializerError
>   at densconnect.SerialConnection.openConnection(SerialConnection.java:136)
>   at densconnect.DensTalk.<init>(DensTalk.java:165)
>   at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
>   at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
>   at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
>   at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
> Caused by: java.lang.NullPointerException
>   at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
> CommPortIdentifier:addPortName(COM3)
> CommPortIdentifier:AddIdentifierToList()
> CommPortIdentifier:AddIdentifierToList() null
> ...
>
>

There is a solution for this bug.

http://bugzilla.qbang.org/show_bug.cgi?id=54

We have been horribly slow at getting the next round of patches in but 
they are comming.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  2 00:58:02 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 08:58:02 +0200
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F8222.3060402@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
Message-ID: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>

Hi Doug,

you wrote in an earlier message, that you would prefer an unchanged  
version. What about simply removing the RXTX parallel lib from the  
ext directory. This does not fix the bug, but it should fix your  
problem.

In general I think it is not a good idea to put the RXTX files in a  
system wide location. Putting the libs in the application folder and  
including the .jar in the application classpath (or application jar)  
is all that is required.

Regards,
Joachim

On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:

> Ok, I just hacked this thing up and got it to read the
> gnu.io.rxtx.properties file.
>
> I commented out the line:
> System.setProperties(p); in the method registerSpecifiedPorts() in
> RXTXCommDriver class.  I really don't understand that much about
> properties, but this call kills the System class.
>
> I used the following in the gnu.io.rxtx.properties file:
>
> gnu.io.rxtx.SerialPorts=COM3
> gnu.io.rxtx.ParallelPorts=null
>
> This allows the application to open very quickly without any errors.
> Whomever coded this class or somebody who understands properties  
> should
> look at this method and make sure it is doing what they expect.
>
> Doug
>
>
>
>
> Doug Thistlethwaite wrote:
>
>> I think there is an error in the registerSpecifiedPorts() method.   
>> When
>> I have a gnu.io.rxtx.properties file in the ext directory, this  
>> function
>> kills the System class  IF I call System.getProperty("os.name")  
>> before
>> the call  to registerSpecifiedPorts(), it returns the os name,  
>> after the
>> call, it returns null.  I have not played much with properties,  
>> except
>> for reading them, so I don't really understand the code.
>>
>> 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 antonio.luis at iscte.pt  Fri Jun  2 02:42:28 2006
From: antonio.luis at iscte.pt (=?ISO-8859-1?Q?Ant=F3nio_Lopes?=)
Date: Fri, 02 Jun 2006 09:42:28 +0100
Subject: [Rxtx] Exception when closing serial port
Message-ID: <447FF9F4.7060209@iscte.pt>

Hello everyone,
I've been using RXTX in a Java application in my Pocket PC.
The communication through the (bluetooth) serial port is working perfectly.

However, when I disconnect the app and close the serial port, sometimes I get 
the following error:

"1149237595000: RXTXPort:close detected bad File Descriptor"

The problem is that after this error occurs, the app is no longer able to 
connect to the serial port and I have to soft-reset the device in order to be 
able to connect to it again.

Any ideas on how to solve this issue?

Any help is appreciated.
Thanks,
regards,
-- 
Ant?nio Lopes

@contact: antonio.luis at iscte.pt
@work: ADETTI - ISCTE
@web: http://antonio.lopes.googlepages.com


From paul.klissner at sun.com  Fri Jun  2 02:44:34 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 01:44:34 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to RXTX
	again
Message-ID: <447FFA72.6040807@sun.com>

After looking into javax.comm 3.1 and what it would take to re-engineer it
to be compatible with RXTX platform libraries, I've decided, due my group's
priorities, complexity of the effort vs. benefit, and limited resources, 
to re-post
javax.comm 2.0 binaries on Sun's software download server, unsupported,
with disclaimers, as it was previously.

I don't think there will be any snags doing this from the standpoint of Sun
management or legality.  I will try to have it  posted there in the next 
week
or two, depending on how fast we can get it pushed through the process.

I'd like to think of this as a stop gap measure... ie. a compromise, 
where, at some
point in the not too distant future RXTX implements their own version of the
Java side of the API, as is normally done by javax.extension porters. 
That way
we avoid uncomfortable dependencies in the future.  And that really is 
the Java
development model.

Since RXTX already has the back-end code, porting the java code shouldn't
be a gargantuan effort at all, and RXTX will be in full control of the 
code top
to bottom. I think RXTX can do at least as good a job as the original 
coder.
Prepping 2.0 to be open sourced is more trouble than it is worth. ie. I 
don't
think the current implementation warrants it.

Ultimately, it would be nice to see someone open up a JSR and re-architect
the comm. API to overcome some of it's current design flaws (ie. be more
adaptable to modern platforms, more pluggable, better defined SPI, better
port ownership handling, etc...). A superior architecture would allow for
better collaboration in the future and better interchangeability of 
components
among projects.

Sun's 3.1 version of javax.comm, which is Sun's currently supported version,
has changes pertaining mostly to Sun platform-specific portmapping and has
some minor additional interactions with our back end code, but generally
has little bearing on RXTX. 

Paul



From joachim at buechse.de  Fri Jun  2 04:00:19 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 12:00:19 +0200
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
	RXTX again
In-Reply-To: <447FFA72.6040807@sun.com>
References: <447FFA72.6040807@sun.com>
Message-ID: <1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>

Good day Paul!

A clean architecture with loadable drivers and reusable code would be  
very beneficial for the future, I think everybody agrees. However  
this could be several years into the future. In the meantime, there  
is a real existing problem with IO support on Java. I have the strong  
feeling that most programmers want to code against one specification  
(javax.comm) and be able to replace the underlying implementation via  
a "plugin" on platforms where the SUN implementation is not  
sufficient. RXTX could be just this plugin (reusing very close to 0%  
of the javax.comm implementation but 100% of its API).

I want to propose an API addition and implementation change that will  
take less then 2 hours of manpower to implement and create a solution  
that can bridge the years until javax.comm has been based on a new  
architecture.

Looking at the javax.comm api at http://java.sun.com/products/ 
javacomm/reference/api/index.html I would like to propose the following:

The only entry point to javax.comm is CommPortIdentifier. It has 3  
static methods plus the constructor.

1) define one additional Interface

public interface CommProvider {
    CommPortIdentifier getPortIdentifier(CommPort port);
    CommPortIdentifier getPortIdentifier(String portName);
    Enumeration getPortIdentifiers ();
}

2) add one method to CommPortIdentifier

   public static setCustomCommProvider (CommProvider);

3) change the three static methods of CommPortIdentifier to dispatch  
to the CommProvider if it is set

4) change the constructor of CommPortIdentifier to

   public CommPortIdentifier(...) {
      if (isProviderSet && this.getClass() ==  
javax.comm.CommPortIdentifier) {
          throw new RuntimeException("illegal creation of  
CommPortIndentifier, custom CommProvider is in use");
      }

5) (this is optional, but would be very nice) automatically set a  
custom CommProvider if it is found on the classpath or defined via a  
system property.


The above 1) - 4) can be implemented in less than 1hour. 5) may take  
another hour. I agree that this is not the most elegant design, but  
it would solve a lot of problems with very little effort. It would  
certainly allow RXTX to move forward. If the javax.comm API needs to  
be redesigned completely this addition will not hurt, as people will  
move to the new API anyway and javax.comm 3.0 was so far never  
included in the main distribution.

Best regards,
Joachim

On 02.06.2006, at 10:44, Paul Klissner wrote:

> After looking into javax.comm 3.1 and what it would take to re- 
> engineer it
> to be compatible with RXTX platform libraries, I've decided, due my  
> group's
> priorities, complexity of the effort vs. benefit, and limited  
> resources,
> to re-post
> javax.comm 2.0 binaries on Sun's software download server,  
> unsupported,
> with disclaimers, as it was previously.
>
> I don't think there will be any snags doing this from the  
> standpoint of Sun
> management or legality.  I will try to have it  posted there in the  
> next
> week
> or two, depending on how fast we can get it pushed through the  
> process.
>
> I'd like to think of this as a stop gap measure... ie. a compromise,
> where, at some
> point in the not too distant future RXTX implements their own  
> version of the
> Java side of the API, as is normally done by javax.extension porters.
> That way
> we avoid uncomfortable dependencies in the future.  And that really is
> the Java
> development model.
>
> Since RXTX already has the back-end code, porting the java code  
> shouldn't
> be a gargantuan effort at all, and RXTX will be in full control of the
> code top
> to bottom. I think RXTX can do at least as good a job as the original
> coder.
> Prepping 2.0 to be open sourced is more trouble than it is worth.  
> ie. I
> don't
> think the current implementation warrants it.
>
> Ultimately, it would be nice to see someone open up a JSR and re- 
> architect
> the comm. API to overcome some of it's current design flaws (ie. be  
> more
> adaptable to modern platforms, more pluggable, better defined SPI,  
> better
> port ownership handling, etc...). A superior architecture would  
> allow for
> better collaboration in the future and better interchangeability of
> components
> among projects.
>
> Sun's 3.1 version of javax.comm, which is Sun's currently supported  
> version,
> has changes pertaining mostly to Sun platform-specific portmapping  
> and has
> some minor additional interactions with our back end code, but  
> generally
> has little bearing on RXTX.
>
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Fri Jun  2 09:10:13 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Fri, 2 Jun 2006 09:10:13 -0600 (MDT)
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <447FFA72.6040807@sun.com>
References: <447FFA72.6040807@sun.com>
Message-ID: <Pine.LNX.4.61.0606020906400.15971@www>

On Fri, 2 Jun 2006, Paul Klissner wrote:

> After looking into javax.comm 3.1 and what it would take to re-engineer it
> to be compatible with RXTX platform libraries, I've decided, due my group's
> priorities, complexity of the effort vs. benefit, and limited resources,
> to re-post
> javax.comm 2.0 binaries on Sun's software download server, unsupported,
> with disclaimers, as it was previously.
>

Hi Paul

To address users' immediate needs, we can release rxtx 2.0-7 (final) to 
match the 2.0 binaries from Sun when they are offered for download.

We can discuss potential long term solutions after that.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Fri Jun  2 10:20:09 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 02 Jun 2006 09:20:09 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
	<9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
Message-ID: <44806539.8080902@dupreeinc.com>

Thanks for the suggestion, I will give it a try.

Doug

Joachim Buechse wrote:

>Hi Doug,
>
>you wrote in an earlier message, that you would prefer an unchanged  
>version. What about simply removing the RXTX parallel lib from the  
>ext directory. This does not fix the bug, but it should fix your  
>problem.
>
>In general I think it is not a good idea to put the RXTX files in a  
>system wide location. Putting the libs in the application folder and  
>including the .jar in the application classpath (or application jar)  
>is all that is required.
>
>Regards,
>Joachim
>
>On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:
>
>  
>
>>Ok, I just hacked this thing up and got it to read the
>>gnu.io.rxtx.properties file.
>>
>>I commented out the line:
>>System.setProperties(p); in the method registerSpecifiedPorts() in
>>RXTXCommDriver class.  I really don't understand that much about
>>properties, but this call kills the System class.
>>
>>I used the following in the gnu.io.rxtx.properties file:
>>
>>gnu.io.rxtx.SerialPorts=COM3
>>gnu.io.rxtx.ParallelPorts=null
>>
>>This allows the application to open very quickly without any errors.
>>Whomever coded this class or somebody who understands properties  
>>should
>>look at this method and make sure it is doing what they expect.
>>
>>Doug
>>
>>
>>
>>
>>Doug Thistlethwaite wrote:
>>
>>    
>>
>>>I think there is an error in the registerSpecifiedPorts() method.   
>>>When
>>>I have a gnu.io.rxtx.properties file in the ext directory, this  
>>>function
>>>kills the System class  IF I call System.getProperty("os.name")  
>>>before
>>>the call  to registerSpecifiedPorts(), it returns the os name,  
>>>after the
>>>call, it returns null.  I have not played much with properties,  
>>>except
>>>for reading them, so I don't really understand the code.
>>>
>>>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
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060602/c8892a46/attachment-0017.html

From paul.klissner at sun.com  Fri Jun  2 12:09:26 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 11:09:26 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
Message-ID: <44807ED6.8000903@sun.com>

Joachim Buechse wrote:
> Good day Paul!
>
> A clean architecture with loadable drivers and reusable code would be  
> very beneficial for the future, I think everybody agrees. However  
> this could be several years into the future. In the meantime, there  
> is a real existing problem with IO support on Java. I have the strong  
> feeling that most programmers want to code against one specification  
> (javax.comm) and be able to replace the underlying implementation via  
> a "plugin" on platforms where the SUN implementation is not  
> sufficient. RXTX could be just this plugin (reusing very close to 0%  
> of the javax.comm implementation but 100% of its API).
>
> I want to propose an API addition and implementation change that will  
> take less then 2 hours of manpower to implement and create a solution  
> that can bridge the years until javax.comm has been based on a new  
> architecture.
>
> Looking at the javax.comm api at http://java.sun.com/products/ 
> javacomm/reference/api/index.html I would like to propose the following:
>
> The only entry point to javax.comm is CommPortIdentifier. It has 3  
> static methods plus the constructor.
>
> 1) define one additional Interface
>
> public interface CommProvider {
>     CommPortIdentifier getPortIdentifier(CommPort port);
>     CommPortIdentifier getPortIdentifier(String portName);
>     Enumeration getPortIdentifiers ();
> }
>
> 2) add one method to CommPortIdentifier
>
>    public static setCustomCommProvider (CommProvider);
>
> 3) change the three static methods of CommPortIdentifier to dispatch  
> to the CommProvider if it is set
>
> 4) change the constructor of CommPortIdentifier to
>
>    public CommPortIdentifier(...) {
>       if (isProviderSet && this.getClass() ==  
> javax.comm.CommPortIdentifier) {
>           throw new RuntimeException("illegal creation of  
> CommPortIndentifier, custom CommProvider is in use");
>       }
>
> 5) (this is optional, but would be very nice) automatically set a  
> custom CommProvider if it is found on the classpath or defined via a  
> system property.
>
>
> The above 1) - 4) can be implemented in less than 1hour. 5) may take  
> another hour. I agree that this is not the most elegant design, but  
> it would solve a lot of problems with very little effort. It would  
> certainly allow RXTX to move forward. If the javax.comm API needs to  
> be redesigned completely this addition will not hurt, as people will  
> move to the new API anyway and javax.comm 3.0 was so far never  
> included in the main distribution.
>
> Best regards,
> Joachi
I'm afraid modifying the interface classes isn't my call.  There was 
actually
a TCK written and one of the tests was to ensure that the interface classes
match the spec.  Thus my hands have already been tied since this project
was essentially grandfathered into the JCP.

That's why we need to open a new JSR and find someone who wants
to be the spec lead, and go in with a new reference implementation.
I'm not sure why it would have to take years, since this isn't bleeding edge
technology and there are only so many things that can be done with it,
and we already have practical experience about many functional aspects
that we could cite precedence on.

As it becomes clear that the specification is being accepted completely
or by-and-large by the community, nothing would stop people from
starting adapting to the new API (using the reference implementation or
porting it) and using it in their projects prior to it's final community and
JCP approval, since approval is required only to make it official and
get the "100% pure java" certification for platform ports.

You have one idea already.  Why don't you implement it, solicit some
design feedback from Sun and the RXTX, and create a functional
implementation that addresses the needs of the community, then
we can document it and open a JSR.  That's it.  It should march through
the approval stages reasonably quickly I would imagine, and meantime
RXTX could start using it.

Paul




From doug at dupreeinc.com  Fri Jun  2 12:45:01 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 02 Jun 2006 11:45:01 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
	<9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
Message-ID: <4480872D.6000605@dupreeinc.com>

Joachim,

Thank you for the suggestion.  I restored the jar file to the one I 
downloaded, moved the dll files into the project directory, and added 
the jar to the classpath.  The SerialDemo program that was included with 
the Sun commapi started in 12 seconds instead of the 58 seconds when the 
parallel dll is present.  I did get the startup time to about a second 
by modifying the java code and adding the properties file but this is 
probably not a good idea.

Doug

Joachim Buechse wrote:

>Hi Doug,
>
>you wrote in an earlier message, that you would prefer an unchanged  
>version. What about simply removing the RXTX parallel lib from the  
>ext directory. This does not fix the bug, but it should fix your  
>problem.
>
>In general I think it is not a good idea to put the RXTX files in a  
>system wide location. Putting the libs in the application folder and  
>including the .jar in the application classpath (or application jar)  
>is all that is required.
>
>Regards,
>Joachim
>
>On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:
>
>  
>
>>Ok, I just hacked this thing up and got it to read the
>>gnu.io.rxtx.properties file.
>>
>>I commented out the line:
>>System.setProperties(p); in the method registerSpecifiedPorts() in
>>RXTXCommDriver class.  I really don't understand that much about
>>properties, but this call kills the System class.
>>
>>I used the following in the gnu.io.rxtx.properties file:
>>
>>gnu.io.rxtx.SerialPorts=COM3
>>gnu.io.rxtx.ParallelPorts=null
>>
>>This allows the application to open very quickly without any errors.
>>Whomever coded this class or somebody who understands properties  
>>should
>>look at this method and make sure it is doing what they expect.
>>
>>Doug
>>
>>
>>
>>
>>Doug Thistlethwaite wrote:
>>
>>    
>>
>>>I think there is an error in the registerSpecifiedPorts() method.   
>>>When
>>>I have a gnu.io.rxtx.properties file in the ext directory, this  
>>>function
>>>kills the System class  IF I call System.getProperty("os.name")  
>>>before
>>>the call  to registerSpecifiedPorts(), it returns the os name,  
>>>after the
>>>call, it returns null.  I have not played much with properties,  
>>>except
>>>for reading them, so I don't really understand the code.
>>>
>>>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
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060602/3c0e420f/attachment-0017.html

From joachim at buechse.de  Fri Jun  2 13:46:36 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 21:46:36 +0200
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
	RXTX again
In-Reply-To: <44807ED6.8000903@sun.com>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
	<44807ED6.8000903@sun.com>
Message-ID: <6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>

Hello Paul,

of course, the basic change I suggested could be done "hidden".  The  
CommProvider interface could live somewhere in sun.xyz.*
The setCustomCommProvider method would not be in CommPortIdentifier  
but also somewhere in sun.xyz.* This would be an unofficial feature,  
the official interface stays exactly the same. However RXTX (and  
others) could access the hidden interface.

Don't get me wrong, I don't want to harass you into making changes  
you don't like (which probably wouldn't work anyway;-). But I'm a  
long time Java programmer and seeing the state of cross platform  
serial support for Java makes me feel really sad. In fact, when I  
started to look into Java serial port programming some months ago I  
was very surprised that javax.comm never made it into the JDK.

I'm sorry that I did not contribute my feedback to the JSR for  
javax.comm 3.0. However at the time I didn't do serial port  
programming in Java. I agree that a new JSR should be opened - I'm  
not an expert on JSRs or the JCP process, but from looking quickly  
over the progress of some JSRs I would be very surprised if we can  
have a new version in less then a year. In the meanwhile some people  
will start using javax.comm 3.0 (which can not be supported by RXTX),  
some will use javax.comm 2.0 (which means the 2.0.7 release of RXTX  
still needs to be maintained). This may get even worse if eg Apple  
decides to port and include javax.comm 3.0 at which point it may get  
very tricky to write a cross platform Java application.

All of this simply means, that we are loosing a lot of man-power that  
could otherwise be invested in building a clean solution and/or to  
add features that are becoming more and more important (USB events...).

In the automation / machine control universe Java makes a lot of  
sense. Right now many people are migrating to Linux or from  
propietary systems (even DOS) to Windows. Writing the control/ 
configuration applications in Java is the kings way to unify the code  
base.

Best regards,
Joachim


On 02.06.2006, at 20:09, Paul Klissner wrote:

> Joachim Buechse wrote:
>> Good day Paul!
>>
>> A clean architecture with loadable drivers and reusable code would be
>> very beneficial for the future, I think everybody agrees. However
>> this could be several years into the future. In the meantime, there
>> is a real existing problem with IO support on Java. I have the strong
>> feeling that most programmers want to code against one specification
>> (javax.comm) and be able to replace the underlying implementation via
>> a "plugin" on platforms where the SUN implementation is not
>> sufficient. RXTX could be just this plugin (reusing very close to 0%
>> of the javax.comm implementation but 100% of its API).
>>
>> I want to propose an API addition and implementation change that will
>> take less then 2 hours of manpower to implement and create a solution
>> that can bridge the years until javax.comm has been based on a new
>> architecture.
>>
>> Looking at the javax.comm api at http://java.sun.com/products/
>> javacomm/reference/api/index.html I would like to propose the  
>> following:
>>
>> The only entry point to javax.comm is CommPortIdentifier. It has 3
>> static methods plus the constructor.
>>
>> 1) define one additional Interface
>>
>> public interface CommProvider {
>>     CommPortIdentifier getPortIdentifier(CommPort port);
>>     CommPortIdentifier getPortIdentifier(String portName);
>>     Enumeration getPortIdentifiers ();
>> }
>>
>> 2) add one method to CommPortIdentifier
>>
>>    public static setCustomCommProvider (CommProvider);
>>
>> 3) change the three static methods of CommPortIdentifier to dispatch
>> to the CommProvider if it is set
>>
>> 4) change the constructor of CommPortIdentifier to
>>
>>    public CommPortIdentifier(...) {
>>       if (isProviderSet && this.getClass() ==
>> javax.comm.CommPortIdentifier) {
>>           throw new RuntimeException("illegal creation of
>> CommPortIndentifier, custom CommProvider is in use");
>>       }
>>
>> 5) (this is optional, but would be very nice) automatically set a
>> custom CommProvider if it is found on the classpath or defined via a
>> system property.
>>
>>
>> The above 1) - 4) can be implemented in less than 1hour. 5) may take
>> another hour. I agree that this is not the most elegant design, but
>> it would solve a lot of problems with very little effort. It would
>> certainly allow RXTX to move forward. If the javax.comm API needs to
>> be redesigned completely this addition will not hurt, as people will
>> move to the new API anyway and javax.comm 3.0 was so far never
>> included in the main distribution.
>>
>> Best regards,
>> Joachi
> I'm afraid modifying the interface classes isn't my call.  There was
> actually
> a TCK written and one of the tests was to ensure that the interface  
> classes
> match the spec.  Thus my hands have already been tied since this  
> project
> was essentially grandfathered into the JCP.
>
> That's why we need to open a new JSR and find someone who wants
> to be the spec lead, and go in with a new reference implementation.
> I'm not sure why it would have to take years, since this isn't  
> bleeding edge
> technology and there are only so many things that can be done with it,
> and we already have practical experience about many functional aspects
> that we could cite precedence on.
>
> As it becomes clear that the specification is being accepted  
> completely
> or by-and-large by the community, nothing would stop people from
> starting adapting to the new API (using the reference  
> implementation or
> porting it) and using it in their projects prior to it's final  
> community and
> JCP approval, since approval is required only to make it official and
> get the "100% pure java" certification for platform ports.
>
> You have one idea already.  Why don't you implement it, solicit some
> design feedback from Sun and the RXTX, and create a functional
> implementation that addresses the needs of the community, then
> we can document it and open a JSR.  That's it.  It should march  
> through
> the approval stages reasonably quickly I would imagine, and meantime
> RXTX could start using it.
>
> Paul
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From paul.klissner at sun.com  Fri Jun  2 14:38:49 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 13:38:49 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
	<44807ED6.8000903@sun.com>
	<6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>
Message-ID: <4480A1D9.5060106@sun.com>

Joachim Buechse wrote:
> Hello Paul,
>
> of course, the basic change I suggested could be done "hidden".  The  
> CommProvider interface could live somewhere in sun.xyz.*
> The setCustomCommProvider method would not be in CommPortIdentifier  
> but also somewhere in sun.xyz.* This would be an unofficial feature,  
> the official interface stays exactly the same. However RXTX (and  
> others) could access the hidden interface.
>
> Don't get me wrong, I don't want to harass you into making changes  
> you don't like (which probably wouldn't work anyway;-). But I'm a  
> long time Java programmer and seeing the state of cross platform  
> serial support for Java makes me feel really sad. In fact, when I  
> started to look into Java serial port programming some months ago I  
> was very surprised that javax.comm never made it into the JDK.
>
> I'm sorry that I did not contribute my feedback to the JSR for  
> javax.comm 3.0. 
There was no JSR for 3.0, because we didn't have the resources to make 
the commitment.
Yet Sun needed to add support for platform-dependent port name mapping, 
which had to
be done 'under the hood', since the API isn't designed to handle that in 
a pluggable way.
But these quick fixes aren't the right approach, they just kick the dog 
down the road,
setting bad precedent, inviting confusion and more intractable problems 
(such as the
one plaguing us now).

My changes could have been layered better, it was a trade off between 
achieving an
ideal architecture, trying to find internal reviewers, and meet the 
needs of big customers
in a timely way.  Thus my namespace changes collided with RXTX's 
dependencies.
I was unaware of Jagane's rogue agreement made with the RXTX community 7 
years ago,
before Jagane left Sun.  I think this was a wag-the-dog situation.

Now it is time to do it right, and I don't think it is going to be as 
much trouble as people
some people fear. If RXTX wants to sponsor the JSR and seed a new spec, 
Sun can join
the Expert Group.  And we'd be largely in agreement, since we're not 
talking about
humongous changes, and looking for mutually beneficial changes. The core 
API is already
largely proved and tested.
> However at the time I didn't do serial port  
> programming in Java. I agree that a new JSR should be opened - I'm  
> not an expert on JSRs or the JCP process, but from looking quickly  
> over the progress of some JSRs I would be very surprised if we can  
> have a new version in less then a year. 
*Approved*  But that doesn't mean the spec couldn't be 99.9% stable 
before that.  Once
the delta rate declines and changes approach nil, people could start 
adapting to the API in
advance of formal approval.   It isn't going to be drawn out like 
javax.usb, which was new
technology, a very complex API, and involved precedent setting corporate 
disputes and
policy issues to resolve.

> In the meanwhile some people  
> will start using javax.comm 3.0 (which can not be supported by RXTX),  
> some will use javax.comm 2.0 (which means the 2.0.7 release of RXTX  
> still needs to be maintained). This may get even worse if eg Apple  
> decides to port and include javax.comm 3.0 at which point it may get  
> very tricky to write a cross platform Java application.
>   
The interfaces haven't changed since 1.0.  If we open a JSR ,we can 
contact Apple and
allow them to be on the E.G., if they want.  That might make the JSR a 
bit more drawn out,
but then we'd arrive ultimately arrive at a best-of-all-worlds API that 
most people would
accept, perhaps forever, and arrive at a respectable set of compromises.

-Paul

> All of this simply means, that we are loosing a lot of man-power that  
> could otherwise be invested in building a clean solution and/or to  
> add features that are becoming more and more important (USB events...).
>
> In the automation / machine control universe Java makes a lot of  
> sense. Right now many people are migrating to Linux or from  
> propietary systems (even DOS) to Windows. Writing the control/ 
> configuration applications in Java is the kings way to unify the code  
> base.
>
> Best regards,
> Joachim
>
>
> On 02.06.2006, at 20:09, Paul Klissner wrote:
>
>   
>> Joachim Buechse wrote:
>>     
>>> Good day Paul!
>>>
>>> A clean architecture with loadable drivers and reusable code would be
>>> very beneficial for the future, I think everybody agrees. However
>>> this could be several years into the future. In the meantime, there
>>> is a real existing problem with IO support on Java. I have the strong
>>> feeling that most programmers want to code against one specification
>>> (javax.comm) and be able to replace the underlying implementation via
>>> a "plugin" on platforms where the SUN implementation is not
>>> sufficient. RXTX could be just this plugin (reusing very close to 0%
>>> of the javax.comm implementation but 100% of its API).
>>>
>>> I want to propose an API addition and implementation change that will
>>> take less then 2 hours of manpower to implement and create a solution
>>> that can bridge the years until javax.comm has been based on a new
>>> architecture.
>>>
>>> Looking at the javax.comm api at http://java.sun.com/products/
>>> javacomm/reference/api/index.html I would like to propose the  
>>> following:
>>>
>>> The only entry point to javax.comm is CommPortIdentifier. It has 3
>>> static methods plus the constructor.
>>>
>>> 1) define one additional Interface
>>>
>>> public interface CommProvider {
>>>     CommPortIdentifier getPortIdentifier(CommPort port);
>>>     CommPortIdentifier getPortIdentifier(String portName);
>>>     Enumeration getPortIdentifiers ();
>>> }
>>>
>>> 2) add one method to CommPortIdentifier
>>>
>>>    public static setCustomCommProvider (CommProvider);
>>>
>>> 3) change the three static methods of CommPortIdentifier to dispatch
>>> to the CommProvider if it is set
>>>
>>> 4) change the constructor of CommPortIdentifier to
>>>
>>>    public CommPortIdentifier(...) {
>>>       if (isProviderSet && this.getClass() ==
>>> javax.comm.CommPortIdentifier) {
>>>           throw new RuntimeException("illegal creation of
>>> CommPortIndentifier, custom CommProvider is in use");
>>>       }
>>>
>>> 5) (this is optional, but would be very nice) automatically set a
>>> custom CommProvider if it is found on the classpath or defined via a
>>> system property.
>>>
>>>
>>> The above 1) - 4) can be implemented in less than 1hour. 5) may take
>>> another hour. I agree that this is not the most elegant design, but
>>> it would solve a lot of problems with very little effort. It would
>>> certainly allow RXTX to move forward. If the javax.comm API needs to
>>> be redesigned completely this addition will not hurt, as people will
>>> move to the new API anyway and javax.comm 3.0 was so far never
>>> included in the main distribution.
>>>
>>> Best regards,
>>> Joachi
>>>       
>> I'm afraid modifying the interface classes isn't my call.  There was
>> actually
>> a TCK written and one of the tests was to ensure that the interface  
>> classes
>> match the spec.  Thus my hands have already been tied since this  
>> project
>> was essentially grandfathered into the JCP.
>>
>> That's why we need to open a new JSR and find someone who wants
>> to be the spec lead, and go in with a new reference implementation.
>> I'm not sure why it would have to take years, since this isn't  
>> bleeding edge
>> technology and there are only so many things that can be done with it,
>> and we already have practical experience about many functional aspects
>> that we could cite precedence on.
>>
>> As it becomes clear that the specification is being accepted  
>> completely
>> or by-and-large by the community, nothing would stop people from
>> starting adapting to the new API (using the reference  
>> implementation or
>> porting it) and using it in their projects prior to it's final  
>> community and
>> JCP approval, since approval is required only to make it official and
>> get the "100% pure java" certification for platform ports.
>>
>> You have one idea already.  Why don't you implement it, solicit some
>> design feedback from Sun and the RXTX, and create a functional
>> implementation that addresses the needs of the community, then
>> we can document it and open a JSR.  That's it.  It should march  
>> through
>> the approval stages reasonably quickly I would imagine, and meantime
>> RXTX could start using it.
>>
>> Paul
>>
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at 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  Sat Jun  3 18:15:24 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 18:15:24 -0600 (MDT)
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
Message-ID: <Pine.LNX.4.61.0606031715100.10890@www>


The attached patch allows baud rates of 14400, 28800, 128000 and 256000.

That was my goal.

[import standard disclaimer]

But I took some time to look a little further.  I got custom baud rates 
working enough that someone (perhaps me) can properly fix them in the 
future.  Proof of concept.

As an undocumented bonus, you can toss random baudrates (say 1953), at the 
API and it will set it to something close to that on windows and linux. 
Solaris should say the baud rate is not supported but I have not tested it 
yet.  Mac OS X behavior is unknown at this point.  Just dont expect 
correct behavior at ~8192-9009 baudrates or baudrates less than 20 on 
windows; these baud rates overlap with defines in win32termios.h.  I 
conveniently closed my eyes there.  Try another value close.  On Linux, a 
baud base and divisor are guestimated and set.  On windows, we wave pixie 
dust over the kernel driver and hope.  Do not expect pixie dust and 
guestimates to be the same on windows and linux.  They may well round to 
different values in yet to be tested ways.  There are only so many 
divisors.  If it isn't working, try a little higher or lower.

In the example of 1953 for instance, there is no divisor for commodity 
hardware that comes to that baudrate.  We just come close on one side or 
the other.  If tools tell you they got 1953 exactly, the tools may be 
questionable and just reading values not directly related to the actual 
hardware settings.

These fixes have been tested on Linux and Windows while using an 
oscilloscope to confirm they change relative to known baudrates at 9600, 
14400*, 19200, 28800* (and 1800, 1953** and 2400).

* = previously unsupported.
** = still not supported but probably works from what I saw.

There could be future discussion in this area.  For now this is working 
for almost all unusual baud rate demands.  Cleaning up the custom baud 
rate should be easier with a working starting point.  Baud bases other 
than 128000 have not been characterized.  Yes.. this overlapps with two of 
the baud rates enabled.

Feedback and ideas are welcome.

--
Trent Jarvi
tjarvi at qbang.org
-------------- next part --------------
Index: SerialImp.c
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v
retrieving revision 1.46.2.187
diff -u -r1.46.2.187 SerialImp.c
--- SerialImp.c	29 Jan 2006 22:19:04 -0000	1.46.2.187
+++ SerialImp.c	3 Jun 2006 23:12:40 -0000
@@ -793,6 +793,19 @@
 		result &= ~TIOCM_DTR;
 		ioctl( fd, TIOCMSET, &result );
 	}
+	/*
+	   B38400 is a special case in Linux for custom baud rates.
+
+	   We just treat this as a custom speed for now.  If you take this ifdef
+	   out and select baud rates 38400 then 28800 then 38400, you will get
+	   a final baud rate of 28800 because you did not update the divisor.
+
+	   See the next ifdef below for the divisor.
+	*/
+#if defined(TIOCGSERIAL)
+	if ( cspeed == B38400 )
+		cspeed = 38400;
+#endif /* TIOCGSERIAL */
 	if(     cfsetispeed( &ttyset, cspeed ) < 0 ||
 		cfsetospeed( &ttyset, cspeed ) < 0 )
 	{
@@ -814,6 +827,7 @@
 		*/
 
 #if defined(TIOCGSERIAL)
+		ioctl( fd, TIOCGSERIAL, &sstruct );
 		sstruct.custom_divisor = ( sstruct.baud_base/cspeed );
 		cspeed = B38400;
 #endif /* TIOCGSERIAL */
@@ -827,7 +841,7 @@
 #if defined(TIOCSSERIAL)
 		/*  It is assumed Win32 does this for us */
 		if (	sstruct.baud_base < 1 ||
-			ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
+		ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
 		{
 			return( 1 );
 		}
Index: termios.c
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v
retrieving revision 1.9.2.56
diff -u -r1.9.2.56 termios.c
--- termios.c	16 Jan 2006 02:50:32 -0000	1.9.2.56
+++ termios.c	3 Jun 2006 23:12:40 -0000
@@ -323,8 +323,8 @@
 		case CBR_3500000:	return( B3500000 );
 		case CBR_4000000:	return( B4000000 );
 		default:
-			set_errno(EINVAL );
-			return -1;
+			/* assume custom baudrate */
+			return( Baud );
 	}
 }
 
@@ -361,12 +361,13 @@
 		case B9600:	ret = CBR_9600;		break;
 		case B14400:	ret = CBR_14400;	break;
 		case B19200:	ret = CBR_19200;	break;
+		case B28800:	ret = CBR_28800;	break;
 		case B38400:	ret = CBR_38400;	break;
 		case B57600:	ret = CBR_57600;	break;
 		case B115200:	ret = CBR_115200;	break;
 		case B128000:	ret = CBR_128000;	break;
-		case B256000: 	ret = CBR_256000;	break;
 		case B230400:	ret = CBR_230400;	break;
+		case B256000: 	ret = CBR_256000;	break;
 		case B460800:	ret = CBR_460800;	break;
 		case B500000:	ret = CBR_500000;	break;
 		case B576000:	ret = CBR_576000;	break;
@@ -381,10 +382,8 @@
 		case B4000000:	ret = CBR_4000000;	break;
 	
 		default:
-			fprintf( stderr, "B_to_CBR: invalid baudrate: %#o\n",
-				Baud );
-			set_errno( EINVAL );
-			return -1;
+			/* assume custom baudrate */
+			return Baud;
 	}
 	LEAVE( "B_to_CBR" );
 	return ret;
@@ -708,12 +707,9 @@
 	ENTER( "init_serial_struct" );
 
 	/*
-	FIXME
-
-	This needs to use inb() to read the actual baud_base
-	and divisor from the UART registers.  Question is how
-	far do we take this?
-
+	use of custom_divisor and baud_base requires access to
+	kernel space.  The kernel does try its best if you just
+	toss a baud rate at it though.
 	*/
 
 	sstruct->custom_divisor = 0;
@@ -1678,16 +1674,17 @@
 {
 	char message[80];
 	ENTER( "cfsetospeed" );
+	/* clear baudrate */
+	s_termios->c_cflag &= ~CBAUD;
 	if ( speed & ~CBAUD )
 	{
 		sprintf( message, "cfsetospeed: not speed: %#o\n", speed );
 		report( message );
-		return 0;
+		/* continue assuming its a custom baudrate */
+		s_termios->c_cflag |= B38400;  /* use 38400 during custom */
+		s_termios->c_cflag |= CBAUDEX; /* use CBAUDEX for custom */
 	}
-	s_termios->c_ispeed = s_termios->c_ospeed = speed;
-	/* clear baudrate */
-	s_termios->c_cflag &= ~CBAUD;
-	if( speed )
+	else if( speed )
 	{
 		s_termios->c_cflag |= speed;
 	}
@@ -1696,6 +1693,7 @@
 		/* PC blows up with speed 0 handled in Java */
 		s_termios->c_cflag |= B9600;
 	}
+	s_termios->c_ispeed = s_termios->c_ospeed = speed;
 	LEAVE( "cfsetospeed" );
 	return 1;
 }
@@ -1767,25 +1765,6 @@
 }
 
 /*----------------------------------------------------------
-serial_struct_to_DCB()
-
-   accept:      
-   perform:     
-   return:      
-   exceptions:  
-   win32api:     None
-   comments:    
-----------------------------------------------------------*/
-int serial_struct_to_DCB( struct serial_struct *sstruct, DCB *dcb )
-{
-	/* 5 Baud rate fix
-	sstruct.baud_base
-	sstruct.custom_divisor = ( sstruct.baud_base/cspeed );
-	*/
-	return(0);
-}
-
-/*----------------------------------------------------------
 termios_to_DCB()
 
    accept:      
@@ -1798,7 +1777,8 @@
 int termios_to_DCB( struct termios *s_termios, DCB *dcb )
 {
 	ENTER( "termios_to_DCB" );
-	s_termios->c_ispeed = s_termios->c_ospeed = s_termios->c_cflag & CBAUD;
+	if ( !(s_termios->c_cflag & CBAUDEX) )
+		s_termios->c_ispeed = s_termios->c_ospeed = s_termios->c_cflag & CBAUD;
 	dcb->BaudRate        = B_to_CBR( s_termios->c_ispeed );
 	dcb->ByteSize = termios_to_bytesize( s_termios->c_cflag );
 
@@ -2863,11 +2843,6 @@
 			GetCommState( index->hComm, dcb );
 
 			index->sstruct = va_arg( ap, struct serial_struct * );
-			if ( serial_struct_to_DCB( index->sstruct, dcb ) < 0 )
-			{
-				va_end( ap );
-				return -1;
-			}
 
 			report( "TIOCSSERIAL\n" );
 			free(dcb);
Index: win32termios.h
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v
retrieving revision 1.5.2.28
diff -u -r1.5.2.28 win32termios.h
--- win32termios.h	30 Jun 2005 20:23:26 -0000	1.5.2.28
+++ win32termios.h	3 Jun 2006 23:12:40 -0000
@@ -279,7 +279,7 @@
 #define XTABS	01000000 /* Hmm.. Linux/i386 considers this part of TABDLY.. */
 
 /* c_cflag bit meaning */
-# define CBAUD	0010017
+#define  CBAUD  0030017
 #define  B0	0000000		/* hang up */
 #define  B50	0000001
 #define  B75	0000002
@@ -312,13 +312,16 @@
 #define  B3500000 0010016
 #define  B4000000 0010017
 
-/* glue for unsupported linux speeds see also SerialImp.h */
-/* hosed */
-
-#define B14400		1010001
-#define B28800		1010002
-#define B128000		1010003
-#define B256000		1010004
+/*
+	glue for unsupported linux speeds see also SerialImp.h 
+	custom baud rates around 8192-9000 will not work because
+	of these.
+*/
+
+#define B14400		0020001
+#define B28800		0020002
+#define B128000		0020003
+#define B256000		0020004
 
 #define EXTA B19200
 #define EXTB B38400
@@ -356,8 +359,10 @@
 
 /* glue for unsupported windows speeds */
 
-#define CBR_230400	230400
 #define CBR_28800	28800
+#define CBR_128000	128000
+#define CBR_230400	230400
+#define CBR_256000	256000
 #define CBR_460800	460800
 #define CBR_500000	500000
 #define CBR_576000	576000

From impakt01 at optusnet.com.au  Sat Jun  3 18:30:37 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 10:30:37 +1000
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
In-Reply-To: <Pine.LNX.4.61.0606031715100.10890@www>
Message-ID: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>

Hi Trent,
I'd love to try the patch but I can't get the latest build compiling, only
pre16. 

Can you attach the rxtxSerial.dll file with this patch?

Also, I hardcoded 1953 in a couple more places last night on pre16 and it
managed to open the port at the right speed, but stopped receiving anything
after 100-150 bytes, even though more data was getting sent to the port.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 10:15 AM
To: rxtx at qbang.org
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.


The attached patch allows baud rates of 14400, 28800, 128000 and 256000.

That was my goal.

[import standard disclaimer]

But I took some time to look a little further.  I got custom baud rates 
working enough that someone (perhaps me) can properly fix them in the 
future.  Proof of concept.

As an undocumented bonus, you can toss random baudrates (say 1953), at the 
API and it will set it to something close to that on windows and linux. 
Solaris should say the baud rate is not supported but I have not tested it 
yet.  Mac OS X behavior is unknown at this point.  Just dont expect 
correct behavior at ~8192-9009 baudrates or baudrates less than 20 on 
windows; these baud rates overlap with defines in win32termios.h.  I 
conveniently closed my eyes there.  Try another value close.  On Linux, a 
baud base and divisor are guestimated and set.  On windows, we wave pixie 
dust over the kernel driver and hope.  Do not expect pixie dust and 
guestimates to be the same on windows and linux.  They may well round to 
different values in yet to be tested ways.  There are only so many 
divisors.  If it isn't working, try a little higher or lower.

In the example of 1953 for instance, there is no divisor for commodity 
hardware that comes to that baudrate.  We just come close on one side or 
the other.  If tools tell you they got 1953 exactly, the tools may be 
questionable and just reading values not directly related to the actual 
hardware settings.

These fixes have been tested on Linux and Windows while using an 
oscilloscope to confirm they change relative to known baudrates at 9600, 
14400*, 19200, 28800* (and 1800, 1953** and 2400).

* = previously unsupported.
** = still not supported but probably works from what I saw.

There could be future discussion in this area.  For now this is working 
for almost all unusual baud rate demands.  Cleaning up the custom baud 
rate should be easier with a working starting point.  Baud bases other 
than 128000 have not been characterized.  Yes.. this overlapps with two of 
the baud rates enabled.

Feedback and ideas are welcome.

--
Trent Jarvi
tjarvi at qbang.org



From tjarvi at qbang.org  Sat Jun  3 19:05:11 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 19:05:11 -0600 (MDT)
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
In-Reply-To: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>
References: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606031840400.10890@www>

On Sun, 4 Jun 2006, Daren wrote:

> Hi Trent,
> I'd love to try the patch but I can't get the latest build compiling, only
> pre16.
>
> Can you attach the rxtxSerial.dll file with this patch?
>
> Also, I hardcoded 1953 in a couple more places last night on pre16 and it
> managed to open the port at the right speed, but stopped receiving anything
> after 100-150 bytes, even though more data was getting sent to the port.
>


ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing

I dont think they will hang.  But I was just testing via loopback/break 
out box/scope.

I'll be putting about 10 patches and another set of binaries in that 
directory shortly.  For now the binaries should just have the baud_rate 
fix.

I'll announce all the patches at once.  but wont be releasing 2.1-8 right 
away.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Sat Jun  3 21:00:01 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 21:00:01 -0600 (MDT)
Subject: [Rxtx] CVS for 2.1 should have everything
Message-ID: <Pine.LNX.4.61.0606032056190.10890@www>


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org


From impakt01 at optusnet.com.au  Sat Jun  3 21:08:14 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 13:08:14 +1000
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <Pine.LNX.4.61.0606032056190.10890@www>
Message-ID: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>

Hi Trent,
I tried the latest dll and it opens the port, receives 100-200 bytes and
then stops receiving anything else..

I'll keep playing with it.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 1:00 PM
To: rxtx at qbang.org
Subject: [Rxtx] CVS for 2.1 should have everything


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From impakt01 at optusnet.com.au  Sat Jun  3 21:22:41 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 13:22:41 +1000
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
Message-ID: <200606040322.k543MqW1008455@mail12.syd.optusnet.com.au>

Played with it, problem, with a while loop in my code, working great now

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Daren
Sent: Sunday, 4 June 2006 1:08 PM
To: 'RXTX Developers and Users'
Subject: Re: [Rxtx] CVS for 2.1 should have everything

Hi Trent,
I tried the latest dll and it opens the port, receives 100-200 bytes and
then stops receiving anything else..

I'll keep playing with it.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 1:00 PM
To: rxtx at qbang.org
Subject: [Rxtx] CVS for 2.1 should have everything


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Sat Jun  3 21:35:41 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 21:35:41 -0600 (MDT)
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
References: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606032131140.10890@www>

On Sun, 4 Jun 2006, Daren wrote:

> Hi Trent,
> I tried the latest dll and it opens the port, receives 100-200 bytes and
> then stops receiving anything else..
>
> I'll keep playing with it.
>
> Daren

The difference may be that I'm talking to something at the exact same baud 
rate (loopback).

You may also try setting the baudrate to ~1933 and ~1973 to force the 
guesses one way or the other.  If you are on windows, we are not doing 
anything fancy in the end.  Thats the kernel guessing.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sun Jun  4 04:12:09 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sun, 4 Jun 2006 12:12:09 +0200
Subject: [Rxtx] Update of OSX installer, Readme, etc
Message-ID: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>

Good day,

after the latest changes a lot of OS X specific files should be  
updated. Especially the installer!

- The "MaxOSX" readme file on the root level is outdated (ie  
CodeWarrior information). Maybe we could even rename it to README.OSX  
to be in line with README.IPAQ, README.SCO (Trent do you mind copying/ 
renaming ,v files in the repository?).

- The lock files are no longer used and hence the user group magic  
and lock folder creation should be removed from the installer.

- MACOSX_IDE/ForPackageMaker/Resources/ReadMe.rtf and Welcome.rtf  
need to be updated.

- I suggest to replace the current installation instruction for OS X:  
Installation should occur into the application directory, not in the  
Java-VM directory. This simplifies things a lot, as the Mac Installer  
can be removed completely.

- The xcodeproject's build settings need to be updated to generate  
JAVA 1.1 format class files.


Dimitry: do you have time to tackle this? I could do it, but as this  
is "your baby" I thought you may prefer to do it yourself.

Regards,
Joachim



From dmarkman at mac.com  Sun Jun  4 11:27:53 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Sun, 4 Jun 2006 13:27:53 -0400
Subject: [Rxtx] Update of OSX installer, Readme, etc
In-Reply-To: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
References: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
Message-ID: <26E7A202-962B-4C19-93B6-29426C467249@mac.com>

Joachim,
unfortunately I don't have time right now to do that
so if you can do that, please do

it's not only my baby
it's yours too :-)

thanks


On Jun 4, 2006, at 6:12 AM, Joachim Buechse wrote:

> Good day,
>
> after the latest changes a lot of OS X specific files should be
> updated. Especially the installer!
>
> - The "MaxOSX" readme file on the root level is outdated (ie
> CodeWarrior information). Maybe we could even rename it to README.OSX
> to be in line with README.IPAQ, README.SCO (Trent do you mind copying/
> renaming ,v files in the repository?).
>
> - The lock files are no longer used and hence the user group magic
> and lock folder creation should be removed from the installer.
>
> - MACOSX_IDE/ForPackageMaker/Resources/ReadMe.rtf and Welcome.rtf
> need to be updated.
>
> - I suggest to replace the current installation instruction for OS X:
> Installation should occur into the application directory, not in the
> Java-VM directory. This simplifies things a lot, as the Mac Installer
> can be removed completely.
>
> - The xcodeproject's build settings need to be updated to generate
> JAVA 1.1 format class files.
>
>
> Dimitry: do you have time to tackle this? I could do it, but as this
> is "your baby" I thought you may prefer to do it yourself.
>
> Regards,
> Joachim
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman



From tjarvi at qbang.org  Sun Jun  4 13:54:02 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 4 Jun 2006 13:54:02 -0600 (MDT)
Subject: [Rxtx] Update of OSX installer, Readme, etc
In-Reply-To: <26E7A202-962B-4C19-93B6-29426C467249@mac.com>
References: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
	<26E7A202-962B-4C19-93B6-29426C467249@mac.com>
Message-ID: <Pine.LNX.4.61.0606041353040.22522@www>

On Sun, 4 Jun 2006, Dmitry Markman wrote:

> Joachim,
> unfortunately I don't have time right now to do that
> so if you can do that, please do
>
> it's not only my baby
> it's yours too :-)
>

I've given Joachim cvs access.  He has shown good work in bugzilla.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Mon Jun  5 10:08:32 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 5 Jun 2006 18:08:32 +0200
Subject: [Rxtx] Build process changes for Mac OS X
Message-ID: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>

Good day,

I have cleaned up some outdated Mac OSX specific build files in the  
repository.

There was not a lot left of the readme file "MacOSX" after cleaning  
it up, so I decided to rename it README.OSX to be in harmony with the  
other files in the directory (ie README.IPAQ, README.SCO, ...)

I added an (uncompressed) XCode 2.3 project file/structure  
with .cvsignore files that will ignore the user specific settings.  
This should work "out of the box" for OSX10.4. Users of 10.2/10.3 may  
have to switch the build settings.

[It's kind of tricky to choose "the right" setting. Afaik there is no  
way to compile a universal binary that will work on 10.3 or before.  
So it's either UniversalBinary OR Legacy. Maybe we should have  
different build targets for these different targets?? I would like to  
get some feedback from the Mac developers on this list regarding the  
subject].

Besides other things the OSX installer is no longer required. Since  
the next version (2.1.8) will no longer use lockfiles on OSX, the  
group/permission magic is no longer required and hence there remains  
basicly no work for the installer - other than copying 2 files to the  
VM extension directory. Then again, this is not the best way to  
install RXTX. So I removed the installer completely without modifying  
it, this should simplify a "resurrection" should it ever get necessary.

I had problems with the (compressed, ie sit.hqx) legacy project files  
on the latest installation of OSX (javac 1.5 creating non JDK1.1  
class files and some minor problems). To reduce potential confusion  
for newcomers I decided to remove them. This means that there is no  
longer a simple way to build RXTX for OSX 10.0 and 10.1 (I deeply  
apologize if anyone still relied on this ... well the files are in  
the Attiq).

Best regards,
Joachim


From joachim at buechse.de  Mon Jun  5 10:16:37 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 5 Jun 2006 18:16:37 +0200
Subject: [Rxtx] RXTX and lockfiles on OSX [it is fixed now]
Message-ID: <7D2C4418-9397-4B59-8091-9FDE4ED67836@buechse.de>

Quite a number of people contacted me in the last couple of weeks  
because of problems installing RXTX on OSX. I told you to wait for  
the "official" fix. Well, it has been fixed.

So if you were among the people waiting for the solution, you can now  
download the source rxtx-2.1-7r2.zip from the website. Once unpacked  
dont forget to use "cvs up" to update the files to the latest  
version. You can then open MACOSX_IDE/XCode/ 
LibSerialUniversal.xcodeproj with XCode 2.3 and build the libraries  
that no longer try to create lock files.

Regards,
Joachim


From brian at mbari.org  Mon Jun  5 10:52:43 2006
From: brian at mbari.org (Brian Schlining)
Date: Mon, 5 Jun 2006 09:52:43 -0700
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
Message-ID: <78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>

Hi Joachim,

> [It's kind of tricky to choose "the right" setting. Afaik there is no
> way to compile a universal binary that will work on 10.3 or before.
> So it's either UniversalBinary OR Legacy. Maybe we should have
> different build targets for these different targets?? I would like to
> get some feedback from the Mac developers on this list regarding the
> subject].

I imagine most developers will be compiling on 10.4 (It's the nature  
of the coder...gotta have the latest and greatest) and deploying to  
both 10.3 and 10.4; both of which will run Universal Binaries (see  
http://forums.macrumors.com/showthread.php?t=205348). So it sounds  
like you've covered the majority of users. Still, you know someone's  
going to pipe up about needing RXTX on 10.2 so it would be nice to  
have a target to make a PPC only build.

Just my 2 cents

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/1cac8c39/attachment-0017.html

From dmarkman at mac.com  Mon Jun  5 13:47:50 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Mon, 5 Jun 2006 15:47:50 -0400
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
Message-ID: <686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>

I don't think it will be a problem to run universal binary
on 10.2
however if binary has some calls that aren't implemented in 10.2
then you'll have a problem


On Jun 5, 2006, at 12:52 PM, Brian Schlining wrote:

> Hi Joachim,
>
>> [It's kind of tricky to choose "the right" setting. Afaik there is no
>> way to compile a universal binary that will work on 10.3 or before.
>> So it's either UniversalBinary OR Legacy. Maybe we should have
>> different build targets for these different targets?? I would like to
>> get some feedback from the Mac developers on this list regarding the
>> subject].
>
> I imagine most developers will be compiling on 10.4 (It's the  
> nature of the coder...gotta have the latest and greatest) and  
> deploying to both 10.3 and 10.4; both of which will run Universal  
> Binaries (see http://forums.macrumors.com/showthread.php?t=205348).  
> So it sounds like you've covered the majority of users. Still, you  
> know someone's going to pipe up about needing RXTX on 10.2 so it  
> would be nice to have a target to make a PPC only build.
>
> Just my 2 cents
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/9fafc878/attachment-0017.html

From brian at mbari.org  Mon Jun  5 14:52:41 2006
From: brian at mbari.org (Brian Schlining)
Date: Mon, 5 Jun 2006 13:52:41 -0700
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
Message-ID: <E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>

Hi Dmitry,

> I don't think it will be a problem to run universal binary
> on 10.2
> however if binary has some calls that aren't implemented in 10.2
> then you'll have a problem

You're right...I stand corrected.

Note however, to deploy a universal binary to 10.2 RXTX will need to  
use the 10.2 SDK to build the PPC side. (see http:// 
developer.apple.com/documentation/DeveloperTools/Conceptual/ 
cross_development/UniversalBinaries/chapter_4_section_1.html). I  
haven't been paying close attention to the new locking mechanism used  
by RXTX on the Mac...does 10.2 support it?

Joachim, which SDK will you be using by default for building the Mac  
PPC binaries?

>> Hi Joachim,
>>
>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>> is no
>>> way to compile a universal binary that will work on 10.3 or before.
>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>> different build targets for these different targets?? I would  
>>> like to
>>> get some feedback from the Mac developers on this list regarding the
>>> subject].
>>
>> I imagine most developers will be compiling on 10.4 (It's the  
>> nature of the coder...gotta have the latest and greatest) and  
>> deploying to both 10.3 and 10.4; both of which will run Universal  
>> Binaries (see http://forums.macrumors.com/showthread.php? 
>> t=205348). So it sounds like you've covered the majority of users.  
>> Still, you know someone's going to pipe up about needing RXTX on  
>> 10.2 so it would be nice to have a target to make a PPC only build.

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/153bf50e/attachment-0017.html

From dmarkman at mac.com  Mon Jun  5 19:02:04 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Mon, 5 Jun 2006 21:02:04 -0400
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
Message-ID: <7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>

if Joachim didn't change xcode project setting

/Developer/SDKs/MacOSX10.4u.sdk is used to build universal binary

so it's quite possible that it won't run properly on 10.2

so we have to change the building process, so ppc part will be built
with
/Developer/SDKs/MacOSX10.2.8.sdk

and finally to use lipo utility to build universal binaries

Joachim, did you use some specific locking API that wasn't implemented

in MacOSX10.2.8.sdk?

thanks


On Jun 5, 2006, at 4:52 PM, Brian Schlining wrote:

> Hi Dmitry,
>
>> I don't think it will be a problem to run universal binary
>> on 10.2
>> however if binary has some calls that aren't implemented in 10.2
>> then you'll have a problem
>
> You're right...I stand corrected.
>
> Note however, to deploy a universal binary to 10.2 RXTX will need  
> to use the 10.2 SDK to build the PPC side. (see http:// 
> developer.apple.com/documentation/DeveloperTools/Conceptual/ 
> cross_development/UniversalBinaries/chapter_4_section_1.html). I  
> haven't been paying close attention to the new locking mechanism  
> used by RXTX on the Mac...does 10.2 support it?
>
> Joachim, which SDK will you be using by default for building the  
> Mac PPC binaries?
>
>>> Hi Joachim,
>>>
>>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>>> is no
>>>> way to compile a universal binary that will work on 10.3 or before.
>>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>>> different build targets for these different targets?? I would  
>>>> like to
>>>> get some feedback from the Mac developers on this list regarding  
>>>> the
>>>> subject].
>>>
>>> I imagine most developers will be compiling on 10.4 (It's the  
>>> nature of the coder...gotta have the latest and greatest) and  
>>> deploying to both 10.3 and 10.4; both of which will run Universal  
>>> Binaries (see http://forums.macrumors.com/showthread.php? 
>>> t=205348). So it sounds like you've covered the majority of  
>>> users. Still, you know someone's going to pipe up about needing  
>>> RXTX on 10.2 so it would be nice to have a target to make a PPC  
>>> only build.
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/84790f80/attachment-0017.html

From joachim at buechse.de  Tue Jun  6 02:40:47 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 6 Jun 2006 10:40:47 +0200
Subject: [Rxtx] Building on OS X, Impl Changes
In-Reply-To: <7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
Message-ID: <CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>

Good day!

What's in the XCode project setting?
----------

The xcode project remained pretty much the same as before. I excluded  
the user specific files from CVS and changed some settings. I kept  
all the built targets (you shouldn't change what you don't understand;-)

Currently we the following build targets:
    RXTXComm (java files)
    librxtxParallel.jnilib (usefull on the Mac???)
    libI2C.jnilib (not yet working in RXTX)
    libRS485.jnilib (not yet working in RXTX)
    librxtxSerial.jnilib (1)
    librxtxSerial.jnilib Dynamic (2)
    rxtxSerial (3)
We also have the following build configurations for each target:
    Development
    Default
    Deployment

What was changed in the xcode project from previous versions:
- java.souce=1.3 and java.target=1.1 in RXTXComm settings
- removed copying of build products into installer directory
- removed "(Upgraded)" from build target names

What remains to be changed:
- choosing a "non-debug" Build-configuration as default
- potentially removing "Default"/"Development" Build-configurations
- reducing the number of build targets
- creating 10.2 compatible universal binaries

I suggest, that the build configurations should be reduced to 2  
(Debug/Deployment), possibly even 1 (Debug).
I have not yet found the deeper meaning of the build targets(1)(2) 
(3), it seems to me like they should be reduced into one "doing the  
right thing" or maybe into two "rxtxSerial.jnilib Legacy" (back to  
10.2, universal if possible) and "rxtxSerial.jnilib 10.4 
+" (universal, 10.4+).

Should the code work on 10.2?
----------

Absolutely. The code should work on NextStep, in fact on any BSD  
unix. I would go as far as saying, this code should work on any  
POSSIX based unix. All that was added is the call "ioctl(fd,  
TIOCEXCL)" to request excusivity of the port:

http://gemma.apple.com/documentation/DeviceDrivers/Conceptual/ 
WorkingWSerial/WWSerial_SerialDevs/chapter_2_section_8.html

It is not yet "the perfect solution". Normally an open /dev/tty  
(listen for incomming connection) should be "preemptable" by opening  
a /dev/cu (outgoing connection) for the same port. This is not yet  
implemented as it needs calls outside of POSSIX on OSX.

On "classic" systems (like NextStep) this worked based on the  
"carried detect line". open() on /dev/tty.xxx would block until the  
carrier detect signal was raised. As the device was not "opened"  
opening /dev/cu.xxx worked without a hitch. When they ported to the  
Mac this broke. On Macs the "carier detect" is usually not wired.  
Furthermore FAX modems did no longer raise the line. So the OSX  
implementor defined a new call, which is documented here:

http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00045.html

Best regards,
Joachim




On 06.06.2006, at 03:02, Dmitry Markman wrote:

> if Joachim didn't change xcode project setting
>
> /Developer/SDKs/MacOSX10.4u.sdk is used to build universal binary
>
> so it's quite possible that it won't run properly on 10.2
>
> so we have to change the building process, so ppc part will be built
> with
> /Developer/SDKs/MacOSX10.2.8.sdk
>
> and finally to use lipo utility to build universal binaries
>
> Joachim, did you use some specific locking API that wasn't implemented
>
> in MacOSX10.2.8.sdk?
>
> thanks
>
>
> On Jun 5, 2006, at 4:52 PM, Brian Schlining wrote:
>
>> Hi Dmitry,
>>
>>> I don't think it will be a problem to run universal binary
>>> on 10.2
>>> however if binary has some calls that aren't implemented in 10.2
>>> then you'll have a problem
>>
>> You're right...I stand corrected.
>>
>> Note however, to deploy a universal binary to 10.2 RXTX will need  
>> to use the 10.2 SDK to build the PPC side. (see http:// 
>> developer.apple.com/documentation/DeveloperTools/Conceptual/ 
>> cross_development/UniversalBinaries/chapter_4_section_1.html). I  
>> haven't been paying close attention to the new locking mechanism  
>> used by RXTX on the Mac...does 10.2 support it?
>>
>> Joachim, which SDK will you be using by default for building the  
>> Mac PPC binaries?
>>
>>>> Hi Joachim,
>>>>
>>>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>>>> is no
>>>>> way to compile a universal binary that will work on 10.3 or  
>>>>> before.
>>>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>>>> different build targets for these different targets?? I would  
>>>>> like to
>>>>> get some feedback from the Mac developers on this list  
>>>>> regarding the
>>>>> subject].
>>>>
>>>> I imagine most developers will be compiling on 10.4 (It's the  
>>>> nature of the coder...gotta have the latest and greatest) and  
>>>> deploying to both 10.3 and 10.4; both of which will run  
>>>> Universal Binaries (see http://forums.macrumors.com/ 
>>>> showthread.php?t=205348). So it sounds like you've covered the  
>>>> majority of users. Still, you know someone's going to pipe up  
>>>> about needing RXTX on 10.2 so it would be nice to have a target  
>>>> to make a PPC only build.
>>
>> Brian Schlining
>> Software Engineer
>> http://www.mbari.org
>>
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> Dmitry Markman
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Tue Jun  6 07:01:06 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 6 Jun 2006 15:01:06 +0200
Subject: [Rxtx] Serial port code for OS X, future steps
In-Reply-To: <CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
	<CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
Message-ID: <8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>

I posted the "wrong link". There is a correction here:

    http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00059.html

In fact, the 2.1.7 implementation of RXTX has quite some deficiencies  
on OSX. I have tried to supply some patches that don't interfere to  
much with the existing RXTX code base, but there are limits to what  
can be done with local patches.

There are some very intrusive changes that should be done. Ie proper  
mapping of /dev/tty <-> /dev/cu handling to correct behaviour of  
CommPortOwnershipListener (http://java.sun.com/products/javacomm/ 
reference/api/index.html). I dont think this can be done with  
patches. Hence I think, RXTX should be rewritten from scratch de- 
unifying the native code base (and implementing thread safe code on  
the Java side).


How "should" /dev/tty vs /dev/cu be implemented?

=====
The Unix contract is this: An open /dev/tty.xxx port (incomming)  
should be interrupted/auto-closed when opening /dev/cu.xxx (outgoing)  
[if /dev/tty.xxx is not currently handling a communication].  /dev/ 
cu.xxx and /dev/tty.xxx refer to the same device, so owning  
"exclusively" should block both. This should be respected across all  
applications native or Java.

This contract is realizable on OSX with the existing javax.comm  
interface while also respecting (to the biggest part) the contract  
defined by javax.comm.PortOwnershipListener.

The one point where the suggested implementation "breaks" the  
javax.comm contract, is by the fact that one can loose a /dev/tty  
port without calling close. However, the only option I see is to  
always open serial ports "non-exclusively" which would outrule Java  
as a platform for (dormant) applications waiting for incoming  
connections/faxes/etc. There could be a system property to choose the  
intended behavior.
=====

Here is how it could be done on OSX:

Calling port=ComportIdentifier.open("/dev/cu.xxx") opens and owns the  
port exclusively until port.close() is called.
- Java applications listening with a PortOwnershipListener should get  
a PORT_OWNED event reasonably soon.
- Any further attempt by a Java or native application to open "/dev/ 
cu.xxx" or "/dev/tty.xxx" fails.
- /dev/cu.xxx is for "outgoing" connections, so receiving  
PORT_OWNERSHIP_REQUESTED makes little to no sense. With native  
applications it can not be implemented. For Java applications it  
could be implemented (by a hidden communication channel). I think  
it's not worth bothering. If anyone is willing to give up a port to  
others he should use /dev/tty.xxx instead of /dev/cu.xxx.

Registering a PortOwnershipListener on "/dev/cu.xxx" without opening  
it, uses /dev/tty.xxx (native open()) non-exclusively and polls its  
state. PORT_OWNED and PORT_UNOWNED can be produced.

Calling port=ComportIdentifier.open("/dev/tty.xxx") should open the  
port non-exclusively.
- Adding a SerialPortEventListener and reading from the port could be  
allowed while keeping it non-exclusive.
- When port.getOutputStream() is called, the state should be changed  
to an "exclusive" ownership. This may be configurable via a system  
property.
- To return to the non-exclusive state the port must be closed and  
reopened.
- While non-exclusively opened, opening the corresponding /dev/cu.xxx  
produces a PORT_OWNERSHIP_REQUESTED event. Which should be responded  
by closing the port from within the callback (as described in  
java.comm.PortOwnershipListener). If there is a pending read, it will  
return after the listener finishes (with -1 or "0 bytes read").
- Calling write() on the /dev/tty.xxx after somebody opened /dev/ 
cu.xxx will fail with a descriptive IOException.
- Calling read() on the /dev/tty.xxx after somebody opened /dev/ 
cu.xxx will fail with a descriptive IOException (or potentially  
block, see side notes below).

CommPortIdentifier.getCurrentOwner() can be implemented by an  
external call to lsof.

CommPortIdentifier.isCurrentlyOwned() can be implemented by trying an  
open on the /dev/tty.
- It returns true if the port is currently held "exclusively".
- Whether it should also return true on /dev/tty if /dev/tty is  
already opened non-exclusively might be a system property option. In  
general, having several applications waiting for incoming connections  
on the same port will require an application level "arbitration"  
protocol...

[[side note1: One interesting question is, what happens if the  
process holding /dev/tty non-exclusively ignores  
PORT_OWNERSHIP_REQUESTED. Ie after "loosing" a non-exclusively opened  
"dev/tty.xxx" port to another process. One possible implementation  
is, that the port is "regained" when the other process gives up the  
port. This would mean that in the meanwhile read() returns no data,  
and any changes to the configuration of the port are stored but not  
forwarded. I guess, the safe (and simple) way to do this is to make  
the close() mandatory (ie setting the port into an "awaiting_close"  
state which produces IOExceptions to any other call than close). ]]

[[side note2:  Another interesting question is, what should happen if  
several applications open the same /dev/tty.xxx port "non- 
exclusively" and start to change the settings of the device.]]

Regards,
Joachim



On 06.06.2006, at 10:40, Joachim Buechse wrote:

> Should the code work on 10.2?
> ----------
>
> Absolutely. The code should work on NextStep, in fact on any BSD
> unix. I would go as far as saying, this code should work on any
> POSSIX based unix. All that was added is the call "ioctl(fd,
> TIOCEXCL)" to request excusivity of the port:
>
> http://gemma.apple.com/documentation/DeviceDrivers/Conceptual/
> WorkingWSerial/WWSerial_SerialDevs/chapter_2_section_8.html
>
> It is not yet "the perfect solution". Normally an open /dev/tty
> (listen for incomming connection) should be "preemptable" by opening
> a /dev/cu (outgoing connection) for the same port. This is not yet
> implemented as it needs calls outside of POSSIX on OSX.
>
> On "classic" systems (like NextStep) this worked based on the
> "carried detect line". open() on /dev/tty.xxx would block until the
> carrier detect signal was raised. As the device was not "opened"
> opening /dev/cu.xxx worked without a hitch. When they ported to the
> Mac this broke. On Macs the "carier detect" is usually not wired.
> Furthermore FAX modems did no longer raise the line. So the OSX
> implementor defined a new call, which is documented here:
>
> http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00045.html
>
> Best regards,
> Joachim



From sds at dcs.gla.ac.uk  Tue Jun  6 11:22:45 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Tue, 06 Jun 2006 18:22:45 +0100
Subject: [Rxtx] Correct compile flag for HP iPAQ hx4700 running Familiar
	Linux?
Message-ID: <1149614565.19496.10.camel@addu>

Hi,

I'd like to use RXTX 2.1 on my HP iPAQ hx4700. The iPAQ is running
Familiar Linux 0.8.2 (as I recall), with Blackdown Java 1.3.1.

I can compile and run a test program which uses RXTX on my i686 machine,
and it works fine. But I can't seem to get things working quite right on
my PDA.

I compile the code on the laptop with the following commands:
	./configure --host=arm-gnu-linux && make
... as suggested in a post to this list, albeit some time ago. This
compiles, I transfer the files, set up LD_LIBRARY_PATH and CLASSPATH
variables, and get the following error on the PDA:

sds at ipaq-pxa-2:~# java Test
java.lang.UnsatisfiedLinkError: /usr/local/lib/ext/librxtxSerial.so: /usr/local/lib/ext/librxtxSerial.so: cannot open shared object file: No such file or directory thrown while loading gnu.io.RXTXCommDriver
Exception in thread "main"
java.lang.UnsatisfiedLinkError: /usr/local/lib/ext/librxtxSerial.so: /usr/local/lib/ext/librxtxSerial.so: cannot open shared object file: No such file or directory
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1382)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1290)
        at java.lang.Runtime.loadLibrary0(Runtime.java:749)
        at java.lang.System.loadLibrary(System.java:820)
        at
gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:83)
        at Test.<init>(Test.java:9)
        at Test.main(Test.java:32)
sds at ipaq-pxa-2:~# 

Note that I'm copying the files to /usr/local/lib/ext/ along with the
RXTXcomm.jar file, purely to keep things separate from the rest of the
system while testing. The location of the .so files doesn't seem to have
any bearing on whether "java Test" will succeed or not. The contents of
this directory are:

sds at ipaq-pxa-2:~$ ls /usr/local/lib/ext/
RXTXcomm.jar              librxtxParallel-2.1-7.so  librxtxRS485.so
librxtxSerial-2.1-7.so
librxtxI2C-2.1-7.so       librxtxParallel.so        librxtxRaw-2.1-7.so
librxtxSerial.so
librxtxI2C.so             librxtxRS485-2.1-7.so     librxtxRaw.so
sds at ipaq-pxa-2:~$

Test.java fails on the first real line of code I'm using to test that
things are working, prior to real development, and was carefully pinched
from the web:
Enumeration portIdentifiers = CommPortIdentifier.getPortIdentifiers();


I assume that I've gotten my --host flag wrong way back up there at
the ./configure step. But if that's the case, what should I set it to?
Or am I missing something more obvious?


Cheers,
Stephen Strowes,
University of Glasgow.




From tjarvi at qbang.org  Tue Jun  6 13:39:41 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 6 Jun 2006 13:39:41 -0600 (MDT)
Subject: [Rxtx] Serial port code for OS X, future steps
In-Reply-To: <8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
	<CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
	<8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>
Message-ID: <Pine.LNX.4.61.0606061315070.9856@www>


>>
There are some very intrusive changes that should be done. Ie proper
mapping of /dev/tty <-> /dev/cu handling to correct behaviour of
CommPortOwnershipListener (http://java.sun.com/products/javacomm/
reference/api/index.html). I dont think this can be done with
patches. Hence I think, RXTX should be rewritten from scratch de-
unifying the native code base (and implementing thread safe code on
the Java side).
<<

This appears to be a very small amount of functionality for a total 
rewrite.  The port ownership only needs maybe 3 native calls if it is done 
with native calls at all.

Those features which are not part of the Unix standard(s) can be special 
cased.  I'm not sure /dev/cu is standard.  We can look.  I know linux 
deprecated /dev/cua years ago.

Thread safe Java code is not a platform specific issue.

--
Trent Jarvi
tjarvi at qbang.org


From sds at dcs.gla.ac.uk  Wed Jun  7 12:36:43 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Wed, 07 Jun 2006 19:36:43 +0100
Subject: [Rxtx] Expected RXTX behaviour?
In-Reply-To: <1149703900.30891.19.camel@addu>
References: <1149703900.30891.19.camel@addu>
Message-ID: <1149705403.30891.25.camel@addu>

Apologies, caught the problem. Had to append '\r' to the end of the AT
string. A non obvious but stupid mistake... :-)

Final quick question though: How might I stop the echoing of
outputStream data back into the inputStream? I still see the ATI
commands on the inputStream, along with the output from the device.


Cheers,
S.



On Wed, 2006-06-07 at 19:11 +0100, Stephen Strowes wrote:
> Hi,
> 
> I managed to get RXTX to compile for my iPAQ following my previous post
> to this list. Quick query though:
> 
> I want to be able to issue AT commands to a device, and interpret the
> responses. For this, I assume I do the following, in psuedo-form:
> 
> 	CommPortIdentifier.getPortIdentifiers();
> 	// find the correct device id
> 	serialPort= (SerialPort)portID.open("Test");
> 	// Set parameters and flow control
> 	outputStream= serialPort.getOutputStream();
> 	inputStream=  serialPort.getInputStream();
> 
> ... following this, I spawn a thread to respond to DATA_AVAILABLE events
> on serialPort with inputStream, and occasionally write and flush an
> "ATI" onto the outputStream. Nothing complex, I just want to see it
> work.
> 
> I would have expected inputStream to give the same information back from
> an "ATI" command as minicom provides, but instead inputStream only sees
> the "ATI" I put onto the outputStream.
> 
> Have I missed something?
> 
> 
> Cheers,
> S.
> 



From sds at dcs.gla.ac.uk  Wed Jun  7 12:11:40 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Wed, 07 Jun 2006 19:11:40 +0100
Subject: [Rxtx] Expected RXTX behaviour?
Message-ID: <1149703900.30891.19.camel@addu>

Hi,

I managed to get RXTX to compile for my iPAQ following my previous post
to this list. Quick query though:

I want to be able to issue AT commands to a device, and interpret the
responses. For this, I assume I do the following, in psuedo-form:

	CommPortIdentifier.getPortIdentifiers();
	// find the correct device id
	serialPort= (SerialPort)portID.open("Test");
	// Set parameters and flow control
	outputStream= serialPort.getOutputStream();
	inputStream=  serialPort.getInputStream();

... following this, I spawn a thread to respond to DATA_AVAILABLE events
on serialPort with inputStream, and occasionally write and flush an
"ATI" onto the outputStream. Nothing complex, I just want to see it
work.

I would have expected inputStream to give the same information back from
an "ATI" command as minicom provides, but instead inputStream only sees
the "ATI" I put onto the outputStream.

Have I missed something?


Cheers,
S.




From joachim at buechse.de  Wed Jun  7 09:02:13 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 7 Jun 2006 17:02:13 +0200
Subject: [Rxtx] Update of build process for OSX (XCode project)
Message-ID: <62EC47B1-46BD-4ECA-B9EC-C4061D147CDA@buechse.de>

With the help of Dmitry Markman and Brian Schilling I have updated  
(and largely simplifed) the XCode project file for Mac OS X.

Changes:
- compiles a universal binary library with intel=OSX10.4+, ppc=OSX10.2 
+ support
- compiles the Java sources into a JRE1.1 compatible, compressed jar.

Please test on your configuration, especially if you have computers  
running 10.2/10.3 or intel.

Best regards,
Joachim


From joachim at buechse.de  Wed Jun  7 14:36:37 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 7 Jun 2006 22:36:37 +0200
Subject: [Rxtx] Expected RXTX behaviour?
In-Reply-To: <1149705403.30891.25.camel@addu>
References: <1149703900.30891.19.camel@addu> <1149705403.30891.25.camel@addu>
Message-ID: <D3AD6EAF-27BB-455E-9697-86C1121920C3@buechse.de>

Echoing is a feature of the modem. Try ATE0 which works with most  
"rockwell" compatible modems.

Regards,
Joachim


On 07.06.2006, at 20:36, Stephen Strowes wrote:

> Apologies, caught the problem. Had to append '\r' to the end of the AT
> string. A non obvious but stupid mistake... :-)
>
> Final quick question though: How might I stop the echoing of
> outputStream data back into the inputStream? I still see the ATI
> commands on the inputStream, along with the output from the device.
>
>
> Cheers,
> S.
>
>
>
> On Wed, 2006-06-07 at 19:11 +0100, Stephen Strowes wrote:
>> Hi,
>>
>> I managed to get RXTX to compile for my iPAQ following my previous  
>> post
>> to this list. Quick query though:
>>
>> I want to be able to issue AT commands to a device, and interpret the
>> responses. For this, I assume I do the following, in psuedo-form:
>>
>> 	CommPortIdentifier.getPortIdentifiers();
>> 	// find the correct device id
>> 	serialPort= (SerialPort)portID.open("Test");
>> 	// Set parameters and flow control
>> 	outputStream= serialPort.getOutputStream();
>> 	inputStream=  serialPort.getInputStream();
>>
>> ... following this, I spawn a thread to respond to DATA_AVAILABLE  
>> events
>> on serialPort with inputStream, and occasionally write and flush an
>> "ATI" onto the outputStream. Nothing complex, I just want to see it
>> work.
>>
>> I would have expected inputStream to give the same information  
>> back from
>> an "ATI" command as minicom provides, but instead inputStream only  
>> sees
>> the "ATI" I put onto the outputStream.
>>
>> Have I missed something?
>>
>>
>> Cheers,
>> S.
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From g_petrini at yahoo.it  Thu Jun  8 01:41:58 2006
From: g_petrini at yahoo.it (Giacomo Petrini)
Date: Thu, 8 Jun 2006 09:41:58 +0200 (CEST)
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from FieldTalk
Message-ID: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>

Hi,
I'm evaluating the library for the modbus protocol
from FieldTalk
(http://www.modbusdriver.com/fieldtalk/.
I'm using J2SE 5.0 and RXTX 2.1 on win XP.
The problem is that the modbus lib has a method (the
openProtocol method, but maybe there are others) tha
throws the
javax.comm.UnsupportedCommOperationException.
Now, in RXTX 2.1 the namespace has changed in gnu.io,
so the modbus library doesn't work anymore (it look
for things in javax.comm). I've already sent an email
to fieldtalk to see if they are aware of the problem.
The solution should be to use JavaComm + RXTX 2.0. But
I've read somewhere that JavaComm 2.0 does not work
with Java 5.0 and JavaComm 3.0 does not work with RXTX
2.0 so I don't know what to do.

Any ideas?

Thanks Jack

PS: can you make a CC to my personal email
(g_petrini at yahoo.it) too please?

Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 


From rxtx at tapastda.co.uk  Thu Jun  8 02:27:57 2006
From: rxtx at tapastda.co.uk (rxtx@tapastda.co.uk)
Date: Thu, 08 Jun 2006 09:27:57 +0100
Subject: [Rxtx] Win XP and Infrared based serial port
Message-ID: <4487DF8D.5050807@tapastda.co.uk>

I'm attempting to use RXTX 2.1.7 on Win XP with J2SE 5.0 to communicate with a
GSM mobile using a COM port. A peculiarity that I've seen is that whilst I can
communicate successfully with a mobile which uses an infrared based COM port
using the SUN provided javax.comm (v2.0) I cannot use RXTX because it fails to
read anything from the port (i.e. read timeout always occurs returning zero bytes).

I assumed that this could be the result of flow control problems and thus I've
tried setting either software or hardware based flow control on the port however
this has no affect.

Can you suggest any other port configuration changes which might be required to
make such a port work with RXTX.

Thanks
Stu
-- 
Stuart
Tapastda Limited


From tjarvi at qbang.org  Thu Jun  8 05:17:12 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 8 Jun 2006 05:17:12 -0600 (MDT)
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from
	FieldTalk
In-Reply-To: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
References: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606080504480.9856@www>

On Thu, 8 Jun 2006, Giacomo Petrini wrote:

> Hi,
> I'm evaluating the library for the modbus protocol
> from FieldTalk
> (http://www.modbusdriver.com/fieldtalk/.
> I'm using J2SE 5.0 and RXTX 2.1 on win XP.
> The problem is that the modbus lib has a method (the
> openProtocol method, but maybe there are others) tha
> throws the
> javax.comm.UnsupportedCommOperationException.
> Now, in RXTX 2.1 the namespace has changed in gnu.io,
> so the modbus library doesn't work anymore (it look
> for things in javax.comm). I've already sent an email
> to fieldtalk to see if they are aware of the problem.
> The solution should be to use JavaComm + RXTX 2.0. But
> I've read somewhere that JavaComm 2.0 does not work
> with Java 5.0 and JavaComm 3.0 does not work with RXTX
> 2.0 so I don't know what to do.
>
> Any ideas?
>
> Thanks Jack
>


Hi Jack

There are plans for Sun to rerelease JavaComm 2.0 mentioned in the rxtx 
mail-list archives.  When this happens rxtx will release a current rxtx 
2.0 library that works with it.

There are no dates promised by either side but rxtx will do it as soon as 
possible after Sun's rerelease.  Just to give you a feel for the time 
frame, this started last year and no significant progress has been made. 
There have been friendly talks pointing towards solutions (rerelease 2.0) 
but that does not get your application working today.  rxtx is preparing 
for its second release in gnu.io since then.

--
Trent Jarvi
tjarvi at qbang.org




From jredman at ergotech.com  Thu Jun  8 08:47:23 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 08 Jun 2006 08:47:23 -0600
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from
	FieldTalk
In-Reply-To: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
References: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
Message-ID: <4488387B.6040903@ergotech.com>

You could always try a different library, eg.

http://sourceforge.net/projects/jamod

I've only used the slave side since we have our own implementation of 
Modbus Client (and a host of other PLC protocols).  However the client 
side seems to be pretty well supported and fairly widely used.  Since 
the source is there you could change to gnu.io.

I think I should take more of an interest in this issue.  We generally 
run 1.4.2 on Linux, but also have some J9 and old platforms that we 
support that are basically Personal Java.  5.0 on Linux has some 
horrible MDI bugs, to the point of being unusable.   Sounds as though we 
are going to have code compatibility problems across these platforms.

Jim


Giacomo Petrini wrote:
> Hi,
> I'm evaluating the library for the modbus protocol
> from FieldTalk
> (http://www.modbusdriver.com/fieldtalk/.
> I'm using J2SE 5.0 and RXTX 2.1 on win XP.
> The problem is that the modbus lib has a method (the
> openProtocol method, but maybe there are others) tha
> throws the
> javax.comm.UnsupportedCommOperationException.
> Now, in RXTX 2.1 the namespace has changed in gnu.io,
> so the modbus library doesn't work anymore (it look
> for things in javax.comm). I've already sent an email
> to fieldtalk to see if they are aware of the problem.
> The solution should be to use JavaComm + RXTX 2.0. But
> I've read somewhere that JavaComm 2.0 does not work
> with Java 5.0 and JavaComm 3.0 does not work with RXTX
> 2.0 so I don't know what to do.
> 
> Any ideas?
> 
> Thanks Jack
> 
> PS: can you make a CC to my personal email
> (g_petrini at yahoo.it) too please?
> 
> Chiacchiera con i tuoi amici in tempo reale! 
>  http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  8 18:17:23 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 08 Jun 2006 17:17:23 -0700
Subject: [Rxtx] rxtx access is denied error
Message-ID: <4488BE13.2050706@dupreeinc.com>

Hello,

I have been trying to replace the commapi from sun with rxtx for a 
project that communicates with a serial port that is a USB-Serial 
interface.  To be exact, I am using the FTDI VCP driver with one of 
their modules connected to a windows XP system.

I have the RXTX package working pretty well as long as nothing goes wrong.

If a user disconnects the USB port while my java application is running, 
my application goes into an endless loop with lots of messages in the  
errors stream  like the ones below:

    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(481):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.


I believe when this happens the COM port completely disappears and the 
rxtx driver has a heart attack.  Obviously, the user should not do this, 
but my application needs to ideally, correct the situation or as a worse 
case, terminate with a little dignity.  Currently, I have not figured 
out how to catch this error.

The closest I have come is to trap an exception to my input stream read  
that says "No error in readByte"  This error appears to be outside of 
the endless loop of the errors listed above.

Does anybody have an idea of how to identify and trap this error?  Any 
suggestions on how to gracefully recover from it would be greatly 
appreciated!

Thank you for your time,

Doug Thistlethwaite




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060608/9cfca302/attachment-0017.html

From tjarvi at qbang.org  Thu Jun  8 20:54:17 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 8 Jun 2006 20:54:17 -0600 (MDT)
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <4488BE13.2050706@dupreeinc.com>
References: <4488BE13.2050706@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606082022580.1323@www>

On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I have been trying to replace the commapi from sun with rxtx for a project 
> that communicates with a serial port that is a USB-Serial interface.  To be 
> exact, I am using the FTDI VCP driver with one of their modules connected to 
> a windows XP system.
>
> I have the RXTX package working pretty well as long as nothing goes wrong.
>
> If a user disconnects the USB port while my java application is running, my 
> application goes into an endless loop with lots of messages in the  errors 
> stream  like the ones below:
>
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(481):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>
>
> I believe when this happens the COM port completely disappears and the rxtx 
> driver has a heart attack.  Obviously, the user should not do this, but my 
> application needs to ideally, correct the situation or as a worse case, 
> terminate with a little dignity.  Currently, I have not figured out how to 
> catch this error.
>
> The closest I have come is to trap an exception to my input stream read  that 
> says "No error in readByte"  This error appears to be outside of the endless 
> loop of the errors listed above.
>
> Does anybody have an idea of how to identify and trap this error?  Any 
> suggestions on how to gracefully recover from it would be greatly 
> appreciated!
>

Hi Doug

Sadly I don't have a quick solution for you.

Termios has no knowlage about the JVM so it wont be throwing exceptions 
you can catch.

We can return error and set the error number to something reasonable that 
results in an exception.  The No Error message simply means we did not set 
an error number in termios.c.  Those are the line numbers in the code you 
see.  SerialImp.c realizes it errored but does not know much more yet. 
Everything touching the file descriptor is going to error after the port 
is gone presumably.

We don't currently have a plan in place for vanishing (or appearing) com 
ports.

Another example of what we need to think about is what happens if you 
start your application and then plug in the dongle?  Or what if you unplug 
and then plug it in again?

So in each of these three cases, what would the behavior of the (yet to 
be) correct implementation do?

How will the enumerated ports be handled during these changes?

There can also be hints from the OS that could be taken into 
consideration.

We can probably get some exceptions thrown that make sense and null the 
file descriptor when it happens to prevent io attempts.  That would be a 
crude way to let applications know something strange has happened.

Is anyone else tinkering with this problem?

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  9 01:31:29 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 9 Jun 2006 09:31:29 +0200
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <Pine.LNX.4.61.0606082022580.1323@www>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
Message-ID: <AC6EDDDD-0A64-401F-B16B-E484788CDF4A@buechse.de>

Hello Trent,

I am not tinkering with this on the Source Level - but I think it  
should work pretty much the same way as it currently does in OSX.  
When the port goes away you get an IOException thrown for any read/ 
write. It will no longer be in the list of ports from  
CommPortIdentifier.getPortIdentifiers(). When a port (re-)appears it  
is added to the list. It's up to the application to re-check the list  
from time to time.

On Windows you can't do much better then that, because the ports  
don't have useful names. Which USB "virtual com port" is on which  
COMx depends on the order the devices were added. So reconnecting to  
the same device may mean connecting to another port.

Regarding the exception thrown: it would be nice to use an  
IOException subclass but the Exception message should definetly be  
informative also as most applications may want to keep compatibility  
with javax.comm.

Regards,
Joachim


On 09.06.2006, at 04:54, Trent Jarvi wrote:

> On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:
>
>> Hello,
>>
>> I have been trying to replace the commapi from sun with rxtx for a  
>> project
>> that communicates with a serial port that is a USB-Serial  
>> interface.  To be
>> exact, I am using the FTDI VCP driver with one of their modules  
>> connected to
>> a windows XP system.
>>
>> I have the RXTX package working pretty well as long as nothing  
>> goes wrong.
>>
>> If a user disconnects the USB port while my java application is  
>> running, my
>> application goes into an endless loop with lots of messages in  
>> the  errors
>> stream  like the ones below:
>>
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (481):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>
>>
>> I believe when this happens the COM port completely disappears and  
>> the rxtx
>> driver has a heart attack.  Obviously, the user should not do  
>> this, but my
>> application needs to ideally, correct the situation or as a worse  
>> case,
>> terminate with a little dignity.  Currently, I have not figured  
>> out how to
>> catch this error.
>>
>> The closest I have come is to trap an exception to my input stream  
>> read  that
>> says "No error in readByte"  This error appears to be outside of  
>> the endless
>> loop of the errors listed above.
>>
>> Does anybody have an idea of how to identify and trap this error?   
>> Any
>> suggestions on how to gracefully recover from it would be greatly
>> appreciated!
>>
>
> Hi Doug
>
> Sadly I don't have a quick solution for you.
>
> Termios has no knowlage about the JVM so it wont be throwing  
> exceptions
> you can catch.
>
> We can return error and set the error number to something  
> reasonable that
> results in an exception.  The No Error message simply means we did  
> not set
> an error number in termios.c.  Those are the line numbers in the  
> code you
> see.  SerialImp.c realizes it errored but does not know much more yet.
> Everything touching the file descriptor is going to error after the  
> port
> is gone presumably.
>
> We don't currently have a plan in place for vanishing (or  
> appearing) com
> ports.
>
> Another example of what we need to think about is what happens if you
> start your application and then plug in the dongle?  Or what if you  
> unplug
> and then plug it in again?
>
> So in each of these three cases, what would the behavior of the  
> (yet to
> be) correct implementation do?
>
> How will the enumerated ports be handled during these changes?
>
> There can also be hints from the OS that could be taken into
> consideration.
>
> We can probably get some exceptions thrown that make sense and null  
> the
> file descriptor when it happens to prevent io attempts.  That would  
> be a
> crude way to let applications know something strange has happened.
>
> Is anyone else tinkering with this problem?
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From doug at dupreeinc.com  Fri Jun  9 13:09:58 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 09 Jun 2006 12:09:58 -0700
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <Pine.LNX.4.61.0606082022580.1323@www>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
Message-ID: <4489C786.9050504@dupreeinc.com>


Ideally, it would be nice if it would throw an exception and terminate 
the loop.  I am still trying to figure out how to detect the condition 
and recover form it in some form...  I am getting the "No error in 
readByte" exception in my serialEvent() method after an input stream 
read.  It appears to me that the only graceful recovery is to close the 
port and then reopen it when it becomes available.  I can pass the event 
up to the update method in my main frame, but I still can't close the 
port from within that thread.  Any suggestions on how to pass this event 
to a location where the port can be safely closed?

Re: Slow startup in windows XP
I have been looking into this a little closer and have found out the 
following:
System Windows XP Pro 3GHz dual core with 1GB RAM and NO parallel port.
Starting the SerialDemo included with the commapi using the rxtx instead 
of javax.comm takes 60 seconds.
Starting the SerialDemo using rxrx with the rxtxParallel.dll file 
removed takes about 20 seconds.
Modify initialize in RXRXCommDriver.java to not test the parallel ports 
takes less than 1 second.

It would be nice if the initialize routine could detect the presence of 
rxtxParallel.dll file and just skip the whole process if not present.  
Is there an easy way to check for the presence of this file without 
running the parallel port test?

Doug


 

Trent Jarvi wrote:

>On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:
>...
>  
>
>
>Hi Doug
>
>Sadly I don't have a quick solution for you.
>
>Termios has no knowlage about the JVM so it wont be throwing exceptions 
>you can catch.
>
>We can return error and set the error number to something reasonable that 
>results in an exception.  The No Error message simply means we did not set 
>an error number in termios.c.  Those are the line numbers in the code you 
>see.  SerialImp.c realizes it errored but does not know much more yet. 
>Everything touching the file descriptor is going to error after the port 
>is gone presumably.
>
>We don't currently have a plan in place for vanishing (or appearing) com 
>ports.
>
>Another example of what we need to think about is what happens if you 
>start your application and then plug in the dongle?  Or what if you unplug 
>and then plug it in again?
>
>So in each of these three cases, what would the behavior of the (yet to 
>be) correct implementation do?
>
>How will the enumerated ports be handled during these changes?
>
>There can also be hints from the OS that could be taken into 
>consideration.
>
>We can probably get some exceptions thrown that make sense and null the 
>file descriptor when it happens to prevent io attempts.  That would be a 
>crude way to let applications know something strange has happened.
>
>Is anyone else tinkering with this problem?
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060609/911ed787/attachment-0017.html

From Ugo.Landini at Sun.COM  Fri Jun  2 14:23:47 2006
From: Ugo.Landini at Sun.COM (Ugo Landini)
Date: Fri, 02 Jun 2006 22:23:47 +0200
Subject: [Rxtx] OSX 10.4.7 and usb
Message-ID: <44809E53.2070905@sun.com>

Hi, I have installed the library and the native libraries on OSX 10.4.7. 
Then I have run this simple code:

...
while (portList.hasMoreElements()) {
             portId = (CommPortIdentifier) portList.nextElement();
             System.out.println("-> " + portId.getName() + " Port Type:" 
+ portId.getPortType());
...

and the output is:

Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7

Ports found:
-> /dev/tty.Bluetooth-PDA-Sync Port Type:1
-> /dev/cu.Bluetooth-PDA-Sync Port Type:1
-> /dev/tty.Bluetooth-Modem Port Type:1
-> /dev/cu.Bluetooth-Modem Port Type:1

I can't see any USB ports... with javax.comm on linux I could see the 
/dev/ttyUSB stuff, but that's not the case with OSX. Any idea?

tia

uL


From tod at todbot.com  Sun Jun 11 12:04:37 2006
From: tod at todbot.com (Tod E. Kurt)
Date: Sun, 11 Jun 2006 11:04:37 -0700
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <44809E53.2070905@sun.com>
References: <44809E53.2070905@sun.com>
Message-ID: <E2EB14A1-20A7-4611-8F1A-E3D2ABE41F48@todbot.com>

A dumb question, but: do you have the USB serial adapters plugged  
in?  They only show up in /dev when plugged in.  Also, you can verify  
they exist independent of RXTX by doing something like "ls -l /dev/ 
cu.*".

On Jun 2, 2006, at 1:23 PM, Ugo Landini wrote:

> Hi, I have installed the library and the native libraries on OSX  
> 10.4.7.
> Then I have run this simple code:
>
> ...
> while (portList.hasMoreElements()) {
>              portId = (CommPortIdentifier) portList.nextElement();
>              System.out.println("-> " + portId.getName() + " Port  
> Type:"
> + portId.getPortType());
> ...
>
> and the output is:
>
> Experimental:  JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
>
> Ports found:
> -> /dev/tty.Bluetooth-PDA-Sync Port Type:1
> -> /dev/cu.Bluetooth-PDA-Sync Port Type:1
> -> /dev/tty.Bluetooth-Modem Port Type:1
> -> /dev/cu.Bluetooth-Modem Port Type:1
>
> I can't see any USB ports... with javax.comm on linux I could see the
> /dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>
> tia
>
> uL
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>



From lyon at docjava.com  Sun Jun 11 12:14:50 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Sun, 11 Jun 2006 14:14:50 -0400
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <44809E53.2070905@sun.com>
References: <44809E53.2070905@sun.com>
Message-ID: <p06020444c0b20de7d248@[192.168.1.152]>

>Hi Ugo,

Do you have any USB serial ports (like the keyspan 19-HS) plugged
into the mac?
Thanks!
  - DL


>Hi, I have installed the library and the native libraries on OSX 10.4.7.
>Then I have run this simple code:
>
>...
>while (portList.hasMoreElements()) {
>              portId = (CommPortIdentifier) portList.nextElement();
>              System.out.println("-> " + portId.getName() + " Port Type:"
>+ portId.getPortType());
>...
>
>and the output is:
>
>Experimental:  JNI_OnLoad called.
>Stable Library
>=========================================
>Native lib Version = RXTX-2.1-7
>Java lib Version   = RXTX-2.1-7
>
>Ports found:
>-> /dev/tty.Bluetooth-PDA-Sync Port Type:1
>-> /dev/cu.Bluetooth-PDA-Sync Port Type:1
>-> /dev/tty.Bluetooth-Modem Port Type:1
>-> /dev/cu.Bluetooth-Modem Port Type:1
>
>I can't see any USB ports... with javax.comm on linux I could see the
>/dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>
>tia
>
>uL
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx



From dmarkman at mac.com  Sun Jun 11 14:30:27 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Sun, 11 Jun 2006 16:30:27 -0400
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <p06020444c0b20de7d248@[192.168.1.152]>
References: <44809E53.2070905@sun.com> <p06020444c0b20de7d248@[192.168.1.152]>
Message-ID: <B9C1606B-4339-4564-A175-FE83DFFA7D76@mac.com>

afaik
10.4.7 wasn't released yet
it will soon, no doubts


On Jun 11, 2006, at 2:14 PM, Dr. Douglas Lyon wrote:

>> Hi Ugo,
>
> Do you have any USB serial ports (like the keyspan 19-HS) plugged
> into the mac?
> Thanks!
>   - DL
>
>
>> Hi, I have installed the library and the native libraries on OSX  
>> 10.4.7.
>> Then I have run this simple code:
>>
>> ...
>> while (portList.hasMoreElements()) {
>>              portId = (CommPortIdentifier) portList.nextElement();
>>              System.out.println("-> " + portId.getName() + " Port  
>> Type:"
>> + portId.getPortType());
>> ...
>>
>> and the output is:
>>
>> Experimental:  JNI_OnLoad called.
>> Stable Library
>> =========================================
>> Native lib Version = RXTX-2.1-7
>> Java lib Version   = RXTX-2.1-7
>>
>> Ports found:
>> -> /dev/tty.Bluetooth-PDA-Sync Port Type:1
>> -> /dev/cu.Bluetooth-PDA-Sync Port Type:1
>> -> /dev/tty.Bluetooth-Modem Port Type:1
>> -> /dev/cu.Bluetooth-Modem Port Type:1
>>
>> I can't see any USB ports... with javax.comm on linux I could see the
>> /dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>>
>> tia
>>
>> uL
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman



From tjarvi at qbang.org  Sun Jun 11 18:52:59 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 11 Jun 2006 18:52:59 -0600 (MDT)
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <4489C786.9050504@dupreeinc.com>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
	<4489C786.9050504@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606111845430.7274@www>

On Fri, 9 Jun 2006, Doug Thistlethwaite wrote:

>
> Ideally, it would be nice if it would throw an exception and terminate the 
> loop.  I am still trying to figure out how to detect the condition and 
> recover form it in some form...  I am getting the "No error in readByte" 
> exception in my serialEvent() method after an input stream read.  It appears 
> to me that the only graceful recovery is to close the port and then reopen it 
> when it becomes available.  I can pass the event up to the update method in 
> my main frame, but I still can't close the port from within that thread.  Any 
> suggestions on how to pass this event to a location where the port can be 
> safely closed?
>

I've gone through and cleaned up the termios.c layer.  I need to get to a 
windows machine with a USB dongle and see where the ioctl() is being 
called.  Probably the eventLoop.  But all of the ioctls should probably 
result in an IOException during this condition.

I'll probably finish this up Monday night when I can borrow a USB 
dongle.

There is no point in putting the code into CVS yet.  If you are tinkering 
I can mail the patch.  I think we will want to make a couple fixes in 
SerialImp.c to handle errors before it's ready.

--
Trent Jarvi
tjarvi at qbang.org



From bob_tai2001 at yahoo.com  Mon Jun 12 09:42:14 2006
From: bob_tai2001 at yahoo.com (Bob Tai)
Date: Mon, 12 Jun 2006 08:42:14 -0700 (PDT)
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to RXTX
	again
Message-ID: <20060612154214.58219.qmail@web32804.mail.mud.yahoo.com>


thank you Paul, Joachim, Trent and everyone try to
workout the java comm and Rxtx situation.  At least
now I have something that is solid enough to make my
decision.  

thank you,
     Bob

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From Ralph.Buchfelder at gmx.net  Mon Jun 12 15:30:20 2006
From: Ralph.Buchfelder at gmx.net (Ralph Buchfelder)
Date: Mon, 12 Jun 2006 23:30:20 +0200
Subject: [Rxtx] rxtx binaries or porting to XSCALE Windows Mobile 2003 / 2005
Message-ID: <448DDCEC.7090506@gmx.net>

dear group,

i have been carefully reading your homepage, wiki and archives
but there seems to be no detailled information on porting to Windows 
Mobile/CE.

as far as i understood from the 'porting' section you can do porting to 
winCE. but how? do i only need to obtain the sourcecode (which one?) and 
compile this in Microsoft eMbedded Visual C++ for ARM/Xscale?
Any other ways?


unfortunately i must admit that i do have little linux skills but i have 
made my way through gcc and makefiles. right now i need to implement com 
  communication in a J2ME application and found your website as >the< 
solution.

best regards
Ralph Buchfelder

University of Regensburg
Department of Geography

PS: i dont care about Javacomm compliancy (ie. 2.0 or 2.1) - i just need 
a working serial port API in IBM J9 VM.


From paul.klissner at sun.com  Wed Jun 14 18:12:58 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Wed, 14 Jun 2006 17:12:58 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
Message-ID: <4490A60A.9090305@sun.com>

Hello RxTx community,

I finally think I have a compromise in place that will stand in the gap.

If you go to http://www.sun.com and search for javax.comm, you'll
get taken to a download page, where now users can get a copy of the
comm.jar file out of 2.0.3, along with just a license and a README.

I trust this will suffice until such time as RxTx decided to implement
their own java classes or we can get a JSR going to mitigate some
of the problems (the readme in the comm.jar 2.0.3 zip file
contains my thoughts on that).

Thanks,
Paul



From tjarvi at qbang.org  Wed Jun 14 21:15:35 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 14 Jun 2006 21:15:35 -0600 (MDT)
Subject: [Rxtx] rxtx-2.0-7 (final) src is in CVS
Message-ID: <Pine.LNX.4.61.0606142100500.2742@www>


I wasn't expecting to be working on rxtx 2.0 tonight :)

Thanks go out to Paul Klissner for his work in making the coming release 
of rxtx-2.0-7 possible for users that require package javax.comm on many 
platforms.

Most people know that rxtx 2.0 is for use with Sun's CommAPI 2.0 for 
Solaris or the Generic CommAPI 2.0-3 available for download at Sun.  If 
you need javax.comm packages on many platforms, you are probably 
interested.  If you use rxtx 2.1 in package gnu.io, then you are not going 
to care much.

I've tried to update the rxtx 2.0 src directory in preparation for 
rxtx-2.0-7 (final).  Linux should compile.  Windows will compile if you 
generate your own .def files (I'll generate these tomorrow).  If you have 
some time to do basic testing of the source, I'd appreciate it.  The 
source should be good but you may find classes not found.  This source is 
a backport from rxtx 2.1.

I wanted to get things started so anyone interested on Mac OS X could get 
a head start.

All of this is in CVS.  http://www.rxtx.org/cvs.html

I suspect we will have binaries for testing in a couple days if you are 
unable to compile.   Consider this a smoke test.

--
Trent Jarvi
tjarvi at qbang.org


From legolas.w at gmail.com  Wed Jun 14 22:04:28 2006
From: legolas.w at gmail.com (Legolas Woodland)
Date: Wed, 14 Jun 2006 21:04:28 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <4490A60A.9090305@sun.com>
References: <4490A60A.9090305@sun.com>
Message-ID: <87ee9b170606142104p745fcef0vea622fbc8f528bfc@mail.gmail.com>

is there anything new in this version of javax.comm ?
thanks


On 6/14/06, Paul Klissner <paul.klissner at sun.com> wrote:
>
> Hello RxTx community,
>
> I finally think I have a compromise in place that will stand in the gap.
>
> If you go to http://www.sun.com and search for javax.comm, you'll
> get taken to a download page, where now users can get a copy of the
> comm.jar file out of 2.0.3, along with just a license and a README.
>
> I trust this will suffice until such time as RxTx decided to implement
> their own java classes or we can get a JSR going to mitigate some
> of the problems (the readme in the comm.jar 2.0.3 zip file
> contains my thoughts on that).
>
> Thanks,
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060614/5ff4dfbc/attachment-0017.html

From joachim at buechse.de  Thu Jun 15 07:22:48 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 15 Jun 2006 15:22:48 +0200
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
Message-ID: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>

Good day!

Some of my users report problems using RXTX 2.1.7 on Windows98 to  
communicate with an FTDI FT245BM chip (using their latest VCP  
driver). Either no ports are being shown (ie returned form  
CommPortIdentifier.getPortIdentifiers()) or the transfers fail.

Did anyone run into similar Problems with Win98??

Best regards,
Joachim



From ajmas at sympatico.ca  Thu Jun 15 08:12:28 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Thu, 15 Jun 2006 10:12:28 -0400
Subject: [Rxtx] API change question
Message-ID: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

How closely do you follow the Java Communication API spec? The reason I ask is because I would be interested in augmenting the CommPortIdentifier class to include a getDisplayName() method. By default it would return the same value as getName(), but would provide the possibility of displaying a 'user friendly' name, for platforms where the display name is not the same as the device name. An example of this is on MacOS X, where currently the names seem to be of the form /dev/cu.* and /dev/tty.*, yet what the expects to see is simply the part after the full-stop. Although I could move this logic into the Java code, it would be nice to see it transparent to the Java code.

Andre




From ajmas at sympatico.ca  Thu Jun 15 08:16:22 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Thu, 15 Jun 2006 10:16:22 -0400
Subject: [Rxtx] Package to use
Message-ID: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

While the Java API spec refers to javax.comm, I see that only gnu.io is provide by the rxtx project. Should our projects refer to the gnu.io package or the javax.comm API?

Andre



From joachim at buechse.de  Thu Jun 15 08:45:05 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 15 Jun 2006 16:45:05 +0200
Subject: [Rxtx] API change question
In-Reply-To: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>

Hello Andre,

the /dev/cu and /dev/tty have different semantics on OS X. It is much  
more than a simply naming issue to unify them, see my recent mail to  
the list...

Best regards,
Joachim


On 15.06.2006, at 16:12, Andre-John Mas wrote:

> Hi,
>
> How closely do you follow the Java Communication API spec? The  
> reason I ask is because I would be interested in augmenting the  
> CommPortIdentifier class to include a getDisplayName() method. By  
> default it would return the same value as getName(), but would  
> provide the possibility of displaying a 'user friendly' name, for  
> platforms where the display name is not the same as the device  
> name. An example of this is on MacOS X, where currently the names  
> seem to be of the form /dev/cu.* and /dev/tty.*, yet what the  
> expects to see is simply the part after the full-stop. Although I  
> could move this logic into the Java code, it would be nice to see  
> it transparent to the Java code.
>
> Andre
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From lyon at docjava.com  Thu Jun 15 10:16:29 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Thu, 15 Jun 2006 12:16:29 -0400
Subject: [Rxtx] cu.modem != /dev/ttya on mac.
In-Reply-To: <763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
	<763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>
Message-ID: <p0602046cc0b7378a95b0@[192.168.1.152]>

>Hi All,

I think that Joachim is correct. For the longest time,
I have been trying to figure out how to direct dial using
the cu.modem on the mac under os x.

As a less-than-optimal approach to auto-dialing, I have used
a keyspan USB 19HS adapter, along with an external modem, to
obtain the dialing feature.

Ideally, it would be better to dial with the built-in modem...but that did not
always seem to work, for some reason. Have others had some experience with
using the built in modem for dialing on the mac?

Thanks!
  - Doug


>Hello Andre,
>
>the /dev/cu and /dev/tty have different semantics on OS X. It is much?
>more than a simply naming issue to unify them, see my recent mail to?
>the list...
>
>Best regards,
>Joachim
>



From doug at dupreeinc.com  Thu Jun 15 14:52:50 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 15 Jun 2006 13:52:50 -0700
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
In-Reply-To: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
References: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
Message-ID: <4491C8A2.8090108@dupreeinc.com>

Hi Joachim,

I have been doing a lot with the new FTDI driver with win XP and have 
not had that particular problem.  I did notice that the new driver 
(dated May19th, 2006) is only for XP, Server 2003, and 2000.  Are they 
trying to use the 2.00.00 drivers or the old 1.09.06 version.  I am 
using a FT232R based module, but it uses the same drivers and I assume 
it would have the same problems.  Let me know which driver they are 
using and I can load up a 98 system here and see if  I can duplicate the 
problem.

Doug

Joachim Buechse wrote:

>Good day!
>
>Some of my users report problems using RXTX 2.1.7 on Windows98 to  
>communicate with an FTDI FT245BM chip (using their latest VCP  
>driver). Either no ports are being shown (ie returned form  
>CommPortIdentifier.getPortIdentifiers()) or the transfers fail.
>
>Did anyone run into similar Problems with Win98??
>
>Best regards,
>Joachim
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From matthewhepp at yahoo.com  Thu Jun 15 17:34:47 2006
From: matthewhepp at yahoo.com (Matthew Hepp)
Date: Thu, 15 Jun 2006 16:34:47 -0700 (PDT)
Subject: [Rxtx] Wither the XCode project?
Message-ID: <20060615233447.48064.qmail@web50311.mail.yahoo.com>

Either I don't know how to properly use CVS (entirely possibl), or the XCode
project is not making through the update properly. Doing a "cvs update" against
2.1-7 creates an XCode folder in MACOSX_IDE, and therein a
LibSerialUniversal.xcodeproj, but trying to open it yields a "Unable to Open
Project - Project rxtx-devel/MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj
cannot be opened because it is missing its project.pbxproj file" error. Showing
package contents reveals just the cvs-related files. Perhaps this is why
previous xcode projects have been saved as an sit.hqx - to retain the resource
fork?

Can someone point me in the right direction?

Thanks,

Matt

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Thu Jun 15 19:53:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 19:53:06 -0600 (MDT)
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
In-Reply-To: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
References: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
Message-ID: <Pine.LNX.4.61.0606151944070.23137@www>

On Thu, 15 Jun 2006, Joachim Buechse wrote:

> Good day!
>
> Some of my users report problems using RXTX 2.1.7 on Windows98 to
> communicate with an FTDI FT245BM chip (using their latest VCP
> driver). Either no ports are being shown (ie returned form
> CommPortIdentifier.getPortIdentifiers()) or the transfers fail.
>
> Did anyone run into similar Problems with Win98??
>

Hi Joachim

It has been a long time since I've tested win98.  I know rxtx-2.1-7pre16 
did get testing on win98 with ~jdk 1.3 though.  I wonder if jdks are still 
tested on that platform.

With win98 you usually have older boxes.  They can be short on CPU and 
memory.  Enumeration should work but I could picture runtime performance 
issues on win98.

The enumeration problems could result from other copies of your 
application if various states of decay still holding onto the port.  When 
things go wrong, people also like to open other terminal software to see 
whats going on which can interfere.  You can't open a windows port with 
two apps.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Thu Jun 15 20:08:53 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 20:08:53 -0600 (MDT)
Subject: [Rxtx] API change question
In-Reply-To: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606151954270.23137@www>

On Thu, 15 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> How closely do you follow the Java Communication API spec?

I can explain how this worked in the past.  How we do it in the future is 
open for discussion.

In the past we have tried to follow it as close as possible in gnu.io 
(rxtx 2.1).  We have added extensions but try to discourage their use. 
The extensions are clearly marked as such in the source code and javadocs.

rxtx 2.0 was intended to be a strict implementation of part of the spec. 
We let Sun's interfaces decide what methods can be called. There are 
differences not covered by the spec such as default values.  Thats not 
intentional but rather hard to avoid.

--
Trent Jarvi
tjarvi at qbang.org





From tjarvi at qbang.org  Thu Jun 15 21:09:11 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 21:09:11 -0600 (MDT)
Subject: [Rxtx] Package to use
In-Reply-To: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606152026120.23137@www>

On Thu, 15 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> While the Java API spec refers to javax.comm, I see that only gnu.io is 
> provide by the rxtx project. Should our projects refer to the gnu.io 
> package or the javax.comm API?
>

Hi Andre

Lets see if I can give a fair and balanced answer to that.

If you are starting a new project and want to use RXTX, I would recommend 
using gnu.io.  The community support for gnu.io will not be going away 
anytime soon.  You can switch between gnu.io (2.1) and javax.comm (2.0) 
fairly easily.  They are not intended to be incompatible.  You just change 
package names and libs.

You can also consider the combination of rxtx 2.0 with Sun's commapi 
2.0-3.  This is considered a stop-gap measure by Sun for previous users of 
that combination.  Together rxtx 2.0 and Sun CommAPI 2.0 work in namespace 
javax.comm for programmers.

Finally, you can opt to just use Sun's oferrings in CommAPI 3.0 without 
rxtx.  That would be in namespace javax.comm also.  CommAPI 3.0 may be 
of more interest to you if you are looking at POS with Sun computers. 
Rxtx does not currently support the changes in CommAPI 3.0 or have firm 
plans to do so.  That does not mean we wouldn't implement them.  It just 
means nobody has contributed code yet.

You can't combine rxtx with CommAPI 3.0 for technical reasons that wont 
likely be fixed soon.

It's up to you as far as what you use.  We like to provide the freedom so 
you can choose.  Realistically, we will be supporting gnu.io mainly 
because we have some control over that name space and can support it.

Things may happen in the future that enable rxtx to provide more support 
in the javax namespace but that has not happened yet.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun 16 00:33:06 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 08:33:06 +0200
Subject: [Rxtx] Wither the XCode project?
In-Reply-To: <20060615233447.48064.qmail@web50311.mail.yahoo.com>
References: <20060615233447.48064.qmail@web50311.mail.yahoo.com>
Message-ID: <D30D660F-A49B-464E-AE4C-6B4563893682@buechse.de>

Hello Matthew,

could you please send me the contents of your

   rxtx-devel/CVS
   rxtx-devel/MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj/CVS

directories as a zip to my personal email address. This should  
indicate why the file is not checked out. I can see that it exists on  
the correct branch in the repository, so something must have gone  
wrong during the "cvs update"...

Best regards,
Joachim

On 16.06.2006, at 01:34, Matthew Hepp wrote:

> Either I don't know how to properly use CVS (entirely possibl), or  
> the XCode
> project is not making through the update properly. Doing a "cvs  
> update" against
> 2.1-7 creates an XCode folder in MACOSX_IDE, and therein a
> LibSerialUniversal.xcodeproj, but trying to open it yields a  
> "Unable to Open
> Project - Project rxtx-devel/MACOSX_IDE/XCode/ 
> LibSerialUniversal.xcodeproj
> cannot be opened because it is missing its project.pbxproj file"  
> error. Showing
> package contents reveals just the cvs-related files. Perhaps this  
> is why
> previous xcode projects have been saved as an sit.hqx - to retain  
> the resource
> fork?
>
> Can someone point me in the right direction?



From joachim at buechse.de  Fri Jun 16 10:41:20 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 18:41:20 +0200
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <p06230903c0b88613dca6@[10.0.1.7]>
References: <p06230903c0b88613dca6@[10.0.1.7]>
Message-ID: <03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>

Hello Bob,

until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was  
behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if  
Trent has migrated all recent changes from 2.1 to 2.0.

I have added the XCode project and updated documentation only to the  
gnu.io branch. Once the 2.0 implementation is up to date I will copy  
over the documentation/build files make them work.

Best regards,
Joachim

On 16.06.2006, at 18:07, Bob Jacobsen wrote:

> I'm one of the developers for the JMRI project, which provides  
> model railroad software in Java.  We've been using RXTX to provide  
> serial port access on MacOS X and Linux; we use the old javax.comm  
> 2.0 on Windows, OS/2 and Solaris.  Because of that, we need to stay  
> with RXTX 2.0, not 2.1
>
> We've been using the 2.0-pre17 installer for a long time, but it's  
> not compatible with Intel macs.
>
> Can you point me to where I can find the right files for RXTX 2.0  
> to package with the program?
>
> The current situation is confusing to me.  I've been pointed to  
> recent 2.1 versions (but we need the javax.comm names), to an even  
> older installer, etc.  I've been reading that some versions require  
> an installer, and others don't, but I haven't been able to figure  
> out which (if any) of those are where in CVS.
>
> I'd really appreciate a clear statement of what files to use and  
> what to do with them that I can pass on to our users.
>
> I'm more than happy to put files in the local classpath, have users  
> run an installer, or anything else.  Whatever is easiest for you.
>
> Thanks!  I really appreciate all that you do to keep RXTX working.
>
> Bob
> -- 
> Bob Jacobsen +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG



From joachim at buechse.de  Fri Jun 16 09:59:28 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 17:59:28 +0200
Subject: [Rxtx] Wither the XCode project?
In-Reply-To: <20060616150240.49464.qmail@web50309.mail.yahoo.com>
References: <20060616150240.49464.qmail@web50309.mail.yahoo.com>
Message-ID: <D9935E05-2B83-488D-86DD-42599E229052@buechse.de>

Hello Matthew,

you have checked out the trunk (which is the 2.0.7 javax.comm.xxx  
release). For rxtx-2.1.7 (gnu.io.xxx release) you need to check out  
the branch

      commapi-0-0-1

The easiest way to do this is to download the rxtx src archive,  
unpack it and then do a cvs up inside the decompressed tree.  
Optionally you could do a

      cvs co -r commapi-0-0-1

but this will take much longer!

Best regards,
Joachim

When you do a cvs status it will show the sticky tag.

41:~/jdevelop/rxtx-2.1-7r2 joachim$ cvs status README.OSX
===================================================================
File: README.OSX        Status: Up-to-date

    Working revision:    1.1.2.1
    Repository revision: 1.1.2.1 /usr/local/cvsroot/rxtx-devel/Attic/ 
README.OSX,v
    Sticky Tag:          commapi-0-0-1 (branch: 1.1.2)
    Sticky Date:         (none)
    Sticky Options:      (none)




On 16.06.2006, at 17:02, Matthew Hepp wrote:

> %cvs status README.MACOSX
> ===================================================================
> File: README.MACOSX     Status: Up-to-date
>
>    Working revision:    1.1
>    Repository revision: 1.1     /usr/local/cvsroot/rxtx-devel/ 
> README.MACOSX,v
>    Sticky Tag:          (none)
>    Sticky Date:         (none)
>    Sticky Options:      (none)



From tjarvi at qbang.org  Fri Jun 16 16:31:18 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Fri, 16 Jun 2006 16:31:18 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
Message-ID: <Pine.LNX.4.61.0606161630030.14139@www>

On Fri, 16 Jun 2006, Joachim Buechse wrote:

> Hello Bob,
>
> until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was
> behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if
> Trent has migrated all recent changes from 2.1 to 2.0.
>

The src/ directory and configure.in/configure files should be fine.  I 
have not touched the Mac OS X directories.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sat Jun 17 02:39:55 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sat, 17 Jun 2006 10:39:55 +0200
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <Pine.LNX.4.61.0606161630030.14139@www>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
Message-ID: <350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>

Hello Trent,

apparently the IOEXCL changes have not made it into 2.0. I will add  
them to achieve a minimal diff between 2.0 and 2.1.

One other thing that bugs me for a while...

Shouldn't we replace "if !defined(TIOCSERGETLSR) && !defined(WIN32)"  
by a definition of its own "if defined(DRAINTHREAD)"? I think this  
would make the code clearer for people starting to read it.

Regards,
Joachim


On 17.06.2006, at 00:31, Trent Jarvi wrote:

> On Fri, 16 Jun 2006, Joachim Buechse wrote:
>
>> Hello Bob,
>>
>> until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was
>> behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if
>> Trent has migrated all recent changes from 2.1 to 2.0.
>>
>
> The src/ directory and configure.in/configure files should be fine.  I
> have not touched the Mac OS X directories.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From tropicsu at hotmail.com  Sat Jun 17 09:32:48 2006
From: tropicsu at hotmail.com (Yoke K)
Date: Sat, 17 Jun 2006 15:32:48 +0000
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
Message-ID: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>

Hi,

I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to work with 
MAC OS X.
I am using iTegno 3000 - USB GPRS Modem.

Files in /dev and a symbolic link as follows:

crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 -> tty.usbserial

In my SendMessage.java, I have this line:
CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");

Appreciate any help ?

- Jon


Errors as follows:

>>INFO: SMSLib API for Java / v1.2.2
>>INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>INFO: JRE Version: 1.5.0_06
>>INFO: JRE Impl Version: 1.5.0_06-64
>>INFO: O/S: Mac OS X / ppc / 10.4.6
>>INFO: Using Wavecom (Generic) AT handler.

SendMessage(): Send a message.
  Using SMSLib API for Java v1.2.2

Connecting ..... :
>>INFO: CSerialDriver(): Connecting...
Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
>>INFO: CSerialDriver(): Disconnecting...
gnu.io.NoSuchPortException
        at 
gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:218)
        at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
        at org.smslib.CService.connect(CService.java:197)
        at SendMessage.main(SendMessage.java:38)

_________________________________________________________________
Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/



From tjarvi at qbang.org  Sat Jun 17 10:12:30 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 10:12:30 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
	<350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
Message-ID: <Pine.LNX.4.61.0606171010060.14139@www>

On Sat, 17 Jun 2006, Joachim Buechse wrote:

> Hello Trent,
>
> apparently the IOEXCL changes have not made it into 2.0. I will add
> them to achieve a minimal diff between 2.0 and 2.1.
>

Hi Joachim

As I recall the IOEXCL change was after 2.1-7.  I was just syncing with 
2.1-7.  We can release 2.1-8 and 2.0-8 with the same changes.

> One other thing that bugs me for a while...
>
> Shouldn't we replace "if !defined(TIOCSERGETLSR) && !defined(WIN32)"
> by a definition of its own "if defined(DRAINTHREAD)"? I think this
> would make the code clearer for people starting to read it.
>


Sure.  We can do that for -8.  The TIOCSERGETLSR code should be a special 
case not the expected.  I think only Linux uses it.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Sat Jun 17 10:48:21 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 10:48:21 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <Pine.LNX.4.61.0606171010060.14139@www>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
	<350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
	<Pine.LNX.4.61.0606171010060.14139@www>
Message-ID: <Pine.LNX.4.61.0606171047310.14139@www>

On Sat, 17 Jun 2006, Trent Jarvi wrote:

> On Sat, 17 Jun 2006, Joachim Buechse wrote:
>
>> Hello Trent,
>>
>> apparently the IOEXCL changes have not made it into 2.0. I will add
>> them to achieve a minimal diff between 2.0 and 2.1.
>>
>
> Hi Joachim
>
> As I recall the IOEXCL change was after 2.1-7.  I was just syncing with
> 2.1-7.  We can release 2.1-8 and 2.0-8 with the same changes.
>

We could just move to 2.1-8 and 2.0-8.

--
Trent Jarvi
tjarvi at qbang.org


From brian.t.lamb at gmail.com  Tue Jun 13 13:54:13 2006
From: brian.t.lamb at gmail.com (Brian Lamb)
Date: Tue, 13 Jun 2006 15:54:13 -0400
Subject: [Rxtx] Windows XP Installation
Message-ID: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>

I've not installed Java packages on Windows before and am unsure how to
proceed. All the documentation I've seen provides detailed instructions on
how to install on Linux or Solaris. I was wondering how to install rxtx on
Windows XP.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060613/6f68cd5c/attachment-0017.html

From tjarvi at qbang.org  Sat Jun 17 13:57:03 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 13:57:03 -0600 (MDT)
Subject: [Rxtx] Windows XP Installation
In-Reply-To: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>
References: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0606171356120.14139@www>

On Tue, 13 Jun 2006, Brian Lamb wrote:

> I've not installed Java packages on Windows before and am unsure how to
> proceed. All the documentation I've seen provides detailed instructions on
> how to install on Linux or Solaris. I was wondering how to install rxtx on
> Windows XP.
>

Hi Brian

Which rxtx version are you trying to install?

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sun Jun 18 10:41:44 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sun, 18 Jun 2006 18:41:44 +0200
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
References: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
Message-ID: <8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>

Hello Jon,

 From OSX's standpoint a symbolic link is not a device (as far as I  
know). What stops you from using tty.usbserial? Did you try hard- 
linking?

Regards,
Joachim

On 17.06.2006, at 17:32, Yoke K wrote:
> Hi,
>
> I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to  
> work with
> MAC OS X.
> I am using iTegno 3000 - USB GPRS Modem.
>
> Files in /dev and a symbolic link as follows:
>
> crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
> crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
> lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->  
> tty.usbserial
>
> In my SendMessage.java, I have this line:
> CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
>
> Appreciate any help ?
>
> - Jon
>
>
> Errors as follows:
>
>>> INFO: SMSLib API for Java / v1.2.2
>>> INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>> INFO: JRE Version: 1.5.0_06
>>> INFO: JRE Impl Version: 1.5.0_06-64
>>> INFO: O/S: Mac OS X / ppc / 10.4.6
>>> INFO: Using Wavecom (Generic) AT handler.
>
> SendMessage(): Send a message.
>   Using SMSLib API for Java v1.2.2
>
> Connecting ..... :
>>> INFO: CSerialDriver(): Connecting...
> Experimental:  JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
>>> INFO: CSerialDriver(): Disconnecting...
> gnu.io.NoSuchPortException
>         at
> gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java: 
> 218)
>         at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
>         at org.smslib.CService.connect(CService.java:197)
>         at SendMessage.main(SendMessage.java:38)
>
> _________________________________________________________________
> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Sun Jun 18 10:56:55 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 12:56:55 -0400
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>
References: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
	<8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>
Message-ID: <7B6834E3-F41D-46B6-B979-55466BC73859@sympatico.ca>

Have you been able to get any other software to talk with your
modem? What port is it using? Have tried using the cu.usbserial
instead?

Andre

On 18-Jun-06, at 12:41 , Joachim Buechse wrote:

> Hello Jon,
>
>  From OSX's standpoint a symbolic link is not a device (as far as I
> know). What stops you from using tty.usbserial? Did you try hard-
> linking?
>
> Regards,
> Joachim
>
> On 17.06.2006, at 17:32, Yoke K wrote:
>> Hi,
>>
>> I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to
>> work with
>> MAC OS X.
>> I am using iTegno 3000 - USB GPRS Modem.
>>
>> Files in /dev and a symbolic link as follows:
>>
>> crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
>> crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
>> lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->
>> tty.usbserial
>>
>> In my SendMessage.java, I have this line:
>> CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
>>
>> Appreciate any help ?
>>
>> - Jon
>>
>>
>> Errors as follows:
>>
>>>> INFO: SMSLib API for Java / v1.2.2
>>>> INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>>> INFO: JRE Version: 1.5.0_06
>>>> INFO: JRE Impl Version: 1.5.0_06-64
>>>> INFO: O/S: Mac OS X / ppc / 10.4.6
>>>> INFO: Using Wavecom (Generic) AT handler.
>>
>> SendMessage(): Send a message.
>>   Using SMSLib API for Java v1.2.2
>>
>> Connecting ..... :
>>>> INFO: CSerialDriver(): Connecting...
>> Experimental:  JNI_OnLoad called.
>> Stable Library
>> =========================================
>> Native lib Version = RXTX-2.1-7
>> Java lib Version   = RXTX-2.1-7
>>>> INFO: CSerialDriver(): Disconnecting...
>> gnu.io.NoSuchPortException
>>         at
>> gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:
>> 218)
>>         at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
>>         at org.smslib.CService.connect(CService.java:197)
>>         at SendMessage.main(SendMessage.java:38)
>>
>> _________________________________________________________________
>> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Sun Jun 18 17:33:08 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 19:33:08 -0400
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
Message-ID: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>

Hi,

I am have a program that I wrote in Java to communicate with a  
Bluetooth GPS device. I am
trying to get this working on my Mac, but I keep getting told that:

gnu.io.PortInUseException: Unknown Application

but

portIdentifier.isCurrentlyOwned()

returns false and when I do lsof on the device I am trying to connect  
to, I see no application
using it. As the same time if I go to the command line and use  
minicom I have no issues. The
exception happens with this call:

CommPort commPort = portIdentifier.open(null,0);

Any suggestions?

Andre


From ajmas at sympatico.ca  Sun Jun 18 17:45:11 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 19:45:11 -0400
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
Message-ID: <30245B30-682D-4EAE-8084-8227B719F10D@sympatico.ca>

BTW My code snippet is:

     private InputStream connectToSerial () throws IOException,  
Exception
     {
         InputStream in = null;

         Enumeration portEnum = CommPortIdentifier.getPortIdentifiers();
         while ( portEnum.hasMoreElements() )
         {
             CommPortIdentifier portIdentifier = (CommPortIdentifier)  
portEnum.nextElement();
             System.out.println(portIdentifier.getName() + " - " +  
portIdentifier.getPortType() );
         }

         CommPortIdentifier portIdentifier =  
CommPortIdentifier.getPortIdentifier("/dev/cu.BTGPS-SPPslave-1");
         System.out.println("current owner: " +  
portIdentifier.getCurrentOwner());
         if ( portIdentifier.isCurrentlyOwned() )
         {
             System.out.println("Error: Port is currently in use");
             return null;
         }
         else
         {
             CommPort commPort = portIdentifier.open(this.getClass 
().getName(),2000);

             if ( commPort instanceof SerialPort )
             {
                 SerialPort serialPort = (SerialPort) commPort;
                 serialPort.setSerialPortParams 
(4800,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE 
);
                 in = serialPort.getInputStream();

                 return in;
             }
             else
             {
                 System.out.println("Error: Only serial ports are  
handled.");
             }
         }


         return in;
     }


On 18-Jun-06, at 19:33 , Andr?-John Mas wrote:

> Hi,
>
> I am have a program that I wrote in Java to communicate with a
> Bluetooth GPS device. I am
> trying to get this working on my Mac, but I keep getting told that:
>
> gnu.io.PortInUseException: Unknown Application
>
> but
>
> portIdentifier.isCurrentlyOwned()
>
> returns false and when I do lsof on the device I am trying to connect
> to, I see no application
> using it. As the same time if I go to the command line and use
> minicom I have no issues. The
> exception happens with this call:
>
> CommPort commPort = portIdentifier.open(null,0);
>
> Any suggestions?
>
> Andre
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From joachim at buechse.de  Mon Jun 19 05:54:49 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 13:54:49 +0200
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de>

This is most likely due to a problem with lock files. If you have  
downloaded the binaries of 2.17 rxtx will try to create non-standard  
lock files on OSX. We have since changed the code to use OSX device  
locking - however the binaries have not been updated yet. The 2.18  
release fixing this issue is due shortly.

Regards,
Joachim

On 19.06.2006, at 01:33, Andr?-John Mas wrote:

> Hi,
>
> I am have a program that I wrote in Java to communicate with a
> Bluetooth GPS device. I am
> trying to get this working on my Mac, but I keep getting told that:
>
> gnu.io.PortInUseException: Unknown Application
>
> but
>
> portIdentifier.isCurrentlyOwned()
>
> returns false and when I do lsof on the device I am trying to connect
> to, I see no application
> using it. As the same time if I go to the command line and use
> minicom I have no issues. The
> exception happens with this call:
>
> CommPort commPort = portIdentifier.open(null,0);
>
> Any suggestions?
>
> Andre
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From joachim at buechse.de  Mon Jun 19 06:44:27 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 14:44:27 +0200
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <4490A60A.9090305@sun.com>
References: <4490A60A.9090305@sun.com>
Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>

Hello Paul,

I just downloaded the "generic" javax.comm version now available. A  
first check indicates, that it was compiled with a JDK 1.4 javac  
without setting the target classfile version. In other words in can  
not be loaded by 1.1-1.3 VMs (or PersonalJava).

Do you see any chance to provide a version compiled with classfile  
format 45.3 (ie JVM1.1).

---
52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose  
javax.comm.SerialPort | head -5
Compiled from "SerialPort.java"
public abstract class javax.comm.SerialPort extends javax.comm.CommPort
   SourceFile: "SerialPort.java"
   minor version: 0
   major version: 48
---

Best regards,
Joachim


On 15.06.2006, at 02:12, Paul Klissner wrote:

> Hello RxTx community,
>
> I finally think I have a compromise in place that will stand in the  
> gap.
>
> If you go to http://www.sun.com and search for javax.comm, you'll
> get taken to a download page, where now users can get a copy of the
> comm.jar file out of 2.0.3, along with just a license and a README.
>
> I trust this will suffice until such time as RxTx decided to implement
> their own java classes or we can get a JSR going to mitigate some
> of the problems (the readme in the comm.jar 2.0.3 zip file
> contains my thoughts on that).
>
> Thanks,
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Mon Jun 19 09:11:45 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Mon, 19 Jun 2006 11:11:45 -0400
Subject: [Rxtx] Examples added to Wiki
Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

I have added a couple of examples to the Wiki:

http://rxtx.qbang.org/wiki/index.php/Examples

If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :)

Andre



From paul.klissner at sun.com  Mon Jun 19 10:42:47 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Mon, 19 Jun 2006 09:42:47 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>
References: <4490A60A.9090305@sun.com>
	<03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>
Message-ID: <4496D407.1090609@sun.com>

Joachim Buechse wrote:
> Hello Paul,
> 
> I just downloaded the "generic" javax.comm version now available. A  
> first check indicates, that it was compiled with a JDK 1.4 javac  
> without setting the target classfile version. In other words in can  
> not be loaded by 1.1-1.3 VMs (or PersonalJava).
> 
> Do you see any chance to provide a version compiled with classfile  
> format 45.3 (ie JVM1.1).
> 
> ---
> 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose  
> javax.comm.SerialPort | head -5
> Compiled from "SerialPort.java"
> public abstract class javax.comm.SerialPort extends javax.comm.CommPort
>    SourceFile: "SerialPort.java"
>    minor version: 0
>    major version: 48
> ---

I cannot promise when I can do that. Since we thought we were done
with javax.comm, the build environment got moved around, and right
now it doesn't even compile in it's new home.  I tried and it was
not cooperative at all. I was never impressed with that workspace
(in fact far far from it, it is a mess, which is why I migrated 3.0
to ant and never looked back).  It will take some real determination
for me to rebuild it, and frankly, right now I'm swamped.  If I can
find a bit of time over the next few weeks to do it, and it isn't
too bad an ordeal, I will.

Posting that will give me an excuse to post javax.comm 3.0, Update 2 as
well, while I'm working with the people who put content up on our
download center.  The only reason for a new update to 3.0 is that
I've changed the distribution to provide ispt (Interactive Serial
Port Tool), such that it can be launched as soon as the zip file
is unpacked, via a provided script.  ISPT is a command line
interactive tool for  manipulating one or two serial port,
sending data, managing events, etc... I've found it to be so useful
for doing certain kinds of validation  that I assume others will
find it useful to.  ISPT is already in 3.0u1, but one has to set
up their own classpath and launch it and since few people ever read
the documentation most won't know about it.  I've added the ability
to set stop bits and parity since 3.0u1 too.  But I digress.

Paul


From joachim at buechse.de  Mon Jun 19 11:01:28 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 19:01:28 +0200
Subject: [Rxtx] load mechanism of 2.0x
Message-ID: <CFD1440C-21AA-4D3B-9EA6-270D0FF9D6FC@buechse.de>

Good day,

I am trying to figure out, how the 2.0x distribution interacts with  
Suns implementation of javax.comm.CommPortIdentifier.

1) Apparently one can put javax.comm.properties in {java.home}/lib
2) The javax.comm package also reacts to -Djavax.comm.properties="...."

Looking at the javap output it also seems like CommPortIdentifier  
tries to find it's jar file and load the properties from there??


What I'm really looking for is a solution that allows using  
javax.comm with RXTX without modifying the VM installation. So I  
would prefer not to use 1) but I can't figure out how to use 2).

Any hints are welcome,
Joachim



From bob_tai2001 at yahoo.com  Mon Jun 19 15:00:35 2006
From: bob_tai2001 at yahoo.com (Bob Tai)
Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT)
Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place
	to start?
Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>

Hi, 

I got  rxtx Windows 2000 installed.  I did not use the
"best" way ... I just follow the insturuction and dump
the necessary files into the jre... I know it's "best"
idea, I got lazy didn't want to change my setting to
my Eclipse and classpath.

I was able to modify SimpleWrite.java to print on my
AddMaster serial printer.  I think I am ready to code!
But I need to make sure I can handle exceptions and so
on.  I notice the \samples\NullDriver\  has two files
seems to have some of the require method done, should
I start coding from those file?  I like the idea it
has the "time out" and basic exceptions done.   I am
slowly digging into the samples, but if you think any
of the code from Sun is good to checkout please let me
know.

btw, http://rxtx.qbang.org/wiki/index.php/Examples/
was very helpful, wish there are more examples.

thank you,

    Bob


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Mon Jun 19 15:55:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT)
Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good
 place to start?
In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>
References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606191542260.14139@www>

> I am
> slowly digging into the samples, but if you think any
> of the code from Sun is good to checkout please let me
> know.
>

I think NullDriver.java was an example stub driver for implementing 
something like rxtx.  It has been a while.  Unless they have been updated, 
you will find the examples are very dated.  You can look at how they use 
the port but avoid the GUI and hard coded variables (number of ports for 
instance).

There was no Swing and nobody knew what requirements today's compilers 
would make on code.  The examples worked fine with jdk 1.1 but times have 
changed.

--
Trent Jarvi
tjarvi at qbang.org


From tropicsu at hotmail.com  Mon Jun 19 19:49:08 2006
From: tropicsu at hotmail.com (Yoke K)
Date: Tue, 20 Jun 2006 01:49:08 +0000
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
Message-ID: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>

An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/fa588f00/attachment-0008.html

From ajmas at sympatico.ca  Mon Jun 19 21:14:37 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Mon, 19 Jun 2006 23:14:37 -0400
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>
References: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>
Message-ID: <CA22AB2A-5712-458B-9984-68477C6042AF@sympatico.ca>

Regarding the PortInUseException, I had a similar issue and got
this response from the mailing list:

   http://mailman.qbang.org/pipermail/rxtx/Week-of- 
Mon-20060619/062838.html

Andre
On 19-Jun-06, at 21:49 , Yoke K wrote:

> Hi Andre, Joachim
>
> I have tried using /dev/tty.usbserial and also /dev/cu.usbserial  
> and it also reported error as  "gnu.io.PortInUseException".
>
> The iTegno modem works in windows environment. As I moving around  
> using my ibook and I need to get it work on MAC OS as well.
>
> >> INFO: SMSLib API for Java / v1.2.2
> >> INFO: Using port: /dev/tty.usbserial @ 115200 baud.
> >> INFO: JRE Version: 1.5.0_06
> >> INFO: JRE Impl Version: 1.5.0_06-64
> >> INFO: O/S: Mac OS X / ppc / 10.4.6
> >> INFO: Using Wavecom (Generic) AT handler.
>
> SendMessage(): Send a message.
> Using SMSLib API for Java v1.2.2
>
> Connecting ..... :
> >> INFO: CSerialDriver(): Connecting...
> Experimental: JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version = RXTX-2.1-7
> >> INFO: CSerialDriver(): Disconnecting...
> gnu.io.PortInUseException: Unknown Application
> at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354)
> at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1)
> at org.smslib.CService.connect(CService.java:197)
> at SendMessage.main(SendMessage.java:38)
>
> Thanks.
>
> - Jon
>
>
>
>
> ====================
>
> Hello Jon,
>
> From OSX's standpoint a symbolic link is not a device (as far as I
> know). What stops you from using tty.usbserial? Did you try hard-
> linking?
>
> Regards,
> Joachim
>
>
>
> From:  "Yoke K" <tropicsu at hotmail.com>
> To:  rxtx at qbang.org
> Subject:  RXTX-2.1-7 / MAC OS X / NoSuchPortException
> Date:  Sat, 17 Jun 2006 15:32:48 +0000
> >Hi,
> >
> >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to
> >work with MAC OS X.
> >I am using iTegno 3000 - USB GPRS Modem.
> >
> >Files in /dev and a symbolic link as follows:
> >
> >crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
> >crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
> >lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->
> >tty.usbserial
> >
> >In my SendMessage.java, I have this line:
> >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
> >
> >Appreciate any help ?
> >
> >- Jon
> >
> >
> >Errors as follows:
> >
> >>>INFO: SMSLib API for Java / v1.2.2
> >>>INFO: Using port: /dev/ttyS1 @ 56000 baud.
> >>>INFO: JRE Version: 1.5.0_06
> >>>INFO: JRE Impl Version: 1.5.0_06-64
> >>>INFO: O/S: Mac OS X / ppc / 10.4.6
> >>>INFO: Using Wavecom (Generic) AT handler.
> >
> >SendMessage(): Send a message.
> >  Using SMSLib API for Java v1.2.2
> >
> >Connecting ..... :
> >>>INFO: CSerialDriver(): Connecting...
> >Experimental:  JNI_OnLoad called.
> >Stable Library
> >=========================================
> >Native lib Version = RXTX-2.1-7
> >Java lib Version   = RXTX-2.1-7
> >>>INFO: CSerialDriver(): Disconnecting...
> >gnu.io.NoSuchPortException
> >        at
> >gnu.io.CommPortIdentifier.getPortIdentifier 
> (CommPortIdentifier.java:218)
> >        at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
> >        at org.smslib.CService.connect(CService.java:197)
> >        at SendMessage.main(SendMessage.java:38)
> >
> >_________________________________________________________________
> >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
> >
>
> Find love online with MSN Personals
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Tue Jun 20 02:35:24 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 10:35:24 +0200
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>

Hello everybody,

I have been fighting a bit with the javax.comm version of RXTX the  
last days. I am working on the README .OSX now and try to figure out  
which should be the "suggested" installation.

The facts:
------

- the "generic" comm.jar version of javax.comm which has been made re- 
available tries to load com.sun.comm.SolarisDriver
- this classname can be overridden ONLY by putting a file  
javax.comm.properties in {java.home}/lib
- if it is not overridden and SolarisDriver.class is not found  
CommPortIdentifier will be disfunctional (in particual it is not  
possible to add CommPort's via CommPortIdentifier.add).
- the license distributed with comm.jar does not allow the  
modification/addition of classes in javax.comm (however no mention of  
com.sun...)


What really bothers me is to suggest putting this config file in the  
"global" vm installation. This is particularly ugly on the Mac as  
there are several VM installations and the file may be forgotten.  
Additionally it may create versioning problems. I prefer an  
installation where all files are local to the application (even  
comm.jar).

In my opinion the ideal situation would be:
------

1) The author of a program compiles against javax.comm.
2a) For platforms supported by Sun the user is free to use the 3.0  
comm.jar download from Sun
2b) For platforms not supported by Sun the user adds RXTXComm.jar to  
the classpath of the application (and librxtxSerial.jnilib to the  
application directory). Also he will need the 2.0.3 generic comm.jar  
from Sun.
3) Nobody messes with the global VM installation.

Of course 2a) and 2b) could be handled by the author of the program  
via an appropriate installer. The author could also decide to always  
use RXTX and include the generic javax.comm classes as well as the  
RXTX classes in his application jar. [If he further uses an explicit  
call to System.load() he may even include the jnilib(s) in the jar,  
extract it (based on the platform name) at runtime to a temp file and  
load it from there.]


Suggested solution:
------

We only need to put the following class in the classpath BEFORE Suns  
comm.jar

   package com.sun.comm;
   public class SolarisDriver extends gnu.io.RXTXCommDriver {
   }

This is not "the pure art" (TM). It depends on an implementation  
detail of the generic driver. However, so does the  
javax.comm.properties file - as we have seen when Sun released 3.0.  
It has the following advantages:

- The "generic" javax.comm implementation will happily load this  
class as its primary driver.
- No javax.comm.properties file is required.
- This does not violate the javax.comm license agreement as there is  
no mention of the "com.sun.comm" package in this license agreement at  
all.
- Authors packaging comm.jar with their application can strip out all  
com.sun.comm classes from comm.jar


Please comment!

Joachim



From joachim at buechse.de  Tue Jun 20 02:50:36 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 10:50:36 +0200
Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar
Message-ID: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>

There has been some discussions about the best way to install RXTX  
and where to place files.

I suggest that,

- we include the native libraries for the most common operating  
systems (in a special version of) RXTXcomm.jar
- we add loader code which tries to extract and load the platform  
specific binary at runtime
- on failure the current mechanism remains as a fallback

Wether the current mechanism should have priority (ie loadLibrary  
before load) remains to be discussed.


The advantages of this solution are
  - users of RXTX do not need to worry about java/platform specific  
file placement.
  - authors of applications may fully merge RXTX into their  
application jar (which provides a double-clickable application for  
Windows and OSX, Linux?).

Please comment,
Joachim

PS: Of course the suggested solution is already possible today,  
however relatively few programmers know how to correctly extract a  
binary resource file via the class loader and load it as a native  
library.


From tjarvi at qbang.org  Tue Jun 20 03:58:12 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT)
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
Message-ID: <Pine.LNX.4.61.0606200335190.14139@www>

> 2a) For platforms supported by Sun the user is free to use the 3.0
> comm.jar download from Sun
> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to
> the classpath of the application (and librxtxSerial.jnilib to the
> application directory). Also he will need the 2.0.3 generic comm.jar
> from Sun.

As there are no plans to support CommAPI 3.0 due to the limitations in its 
implementation mentioned before, I would not recommend projects use Sun's 
3.0 comm.jar.  They will lose the freedom to chose their low level 
implementation by being locked into vendor specific modifications.

Projects should chose between platform neutrality in CommAPI 2.0 and 
reduced platform neutrality in commapi 3.0.  Projects should also strongly 
consider the fact that the 2.0 comm.jar targets only a reduced number of 
JVMs.

Projects can go with rxtx 2.1 or other packages but should probably only 
consider using Sun CommAPI with rxtx if they did so in the past.  They 
should take steps to no longer depend upon this option being available.

> Suggested solution:
> ------
>
> We only need to put the following class in the classpath BEFORE Suns
> comm.jar
>
>   package com.sun.comm;
>   public class SolarisDriver extends gnu.io.RXTXCommDriver {
>   }
>
> This is not "the pure art" (TM). It depends on an implementation
> detail of the generic driver. However, so does the
> javax.comm.properties file - as we have seen when Sun released 3.0.
> It has the following advantages:
>
> - The "generic" javax.comm implementation will happily load this
> class as its primary driver.
> - No javax.comm.properties file is required.
> - This does not violate the javax.comm license agreement as there is
> no mention of the "com.sun.comm" package in this license agreement at
> all.
> - Authors packaging comm.jar with their application can strip out all
> com.sun.comm classes from comm.jar
>

I would not encourage people to place packages in the com.sun.comm 
namespace.  Authors using Sun's commapi 2.0 should just realize it is 
greatly limited in practical utility and consider moving to something that 
isn't being rescued from EOL.

The primary focus of this release is projects previously depending upon 
Sun CommAPI + RXTX.  There are no plans at this time to provide future 
support in this arrangement due to technical incompatabilities we have no 
control over in commapi 3.0 and limited utility of Sun's generic comm.jar 
in commapi 2.0 offered.  Projects should be aware of this so they can make 
appropriate plans.

--
Trent Jarvi
tjarvi at qbang.org


From paul.klissner at sun.com  Tue Jun 20 05:24:00 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Tue, 20 Jun 2006 04:24:00 -0700
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
In-Reply-To: <Pine.LNX.4.61.0606200335190.14139@www>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
	<Pine.LNX.4.61.0606200335190.14139@www>
Message-ID: <4497DAD0.10803@sun.com>

Trent Jarvi wrote:
>> 2a) For platforms supported by Sun the user is free to use the 3.0
>> comm.jar download from Sun
>> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to
>> the classpath of the application (and librxtxSerial.jnilib to the
>> application directory). Also he will need the 2.0.3 generic comm.jar
>> from Sun.
> 
> As there are no plans to support CommAPI 3.0 due to the limitations in its 
> implementation mentioned before, I would not recommend projects use Sun's 
> 3.0 comm.jar.  They will lose the freedom to chose their low level 
> implementation by being locked into vendor specific modifications.
> 
> Projects should chose between platform neutrality in CommAPI 2.0 and 
> reduced platform neutrality in commapi 3.0.  Projects should also strongly 
> consider the fact that the 2.0 comm.jar targets only a reduced number of 
> JVMs.

Well, that's a little ambiguous because the API is the same
either way.  We're talking about Sun's implementation vs.
other implementations.
> 
> Projects can go with rxtx 2.1 or other packages but should probably only 
> consider using Sun CommAPI with rxtx if they did so in the past.  They 
> should take steps to no longer depend upon this option being available.

3.0 is platform centric because there is a need to add some
platform awareness to Sun's implementation, and the choices
for how to do that are limited by the constraints of the API,
as mentioned in the javax.comm 2.0.3 comm.jar download's README.

I am really advocating getting a JSR open (http://www.jcp.org)
to push a new comm API that is more pluggable, platform neutral
and addresses some of the deficiencies of the current API. Then
we can achieve the optimal of platform neutrality while
simulataneously allowing the API to flexibly adapt to
heterogeneous environments.

This is not a question of attitude, this is an issue of resources,
time and commitment.  The current owners of javax.comm within
Sun would like nothing better than to see the ideal reached for
the API and a model that will extend well beyond the foreseeable
future and work for the industry overall.



> 
>> Suggested solution:
>> ------
>>
>> We only need to put the following class in the classpath BEFORE Suns
>> comm.jar
>>
>>   package com.sun.comm;
>>   public class SolarisDriver extends gnu.io.RXTXCommDriver {
>>   }
>>
>> This is not "the pure art" (TM). It depends on an implementation
>> detail of the generic driver. However, so does the
>> javax.comm.properties file - as we have seen when Sun released 3.0.
>> It has the following advantages:
>>
>> - The "generic" javax.comm implementation will happily load this
>> class as its primary driver.
>> - No javax.comm.properties file is required.
>> - This does not violate the javax.comm license agreement as there is
>> no mention of the "com.sun.comm" package in this license agreement at
>> all.
>> - Authors packaging comm.jar with their application can strip out all
>> com.sun.comm classes from comm.jar
>>
> 
> I would not encourage people to place packages in the com.sun.comm 
> namespace.  Authors using Sun's commapi 2.0 should just realize it is 
> greatly limited in practical utility and consider moving to something that 
> isn't being rescued from EOL.
> 
> The primary focus of this release is projects previously depending upon 
> Sun CommAPI + RXTX.  There are no plans at this time to provide future 
> support in this arrangement due to technical incompatabilities we have no 
> control over in commapi 3.0 and limited utility of Sun's generic comm.jar 
> in commapi 2.0 offered.  Projects should be aware of this so they can make 
> appropriate plans.

Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86,
or need the powerful portmapping features in javax.com 3.0, or would like to
acquire the Interactive Serial Port Test utility.

-Paul


From paul.klissner at sun.com  Tue Jun 20 05:33:44 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Tue, 20 Jun 2006 04:33:44 -0700
Subject: [Rxtx] Suggested installation RXTX 2.0x...
In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
Message-ID: <4497DD18.70207@sun.com>

Joachim Buechse wrote:
> Hello everybody,
> 
> I have been fighting a bit with the javax.comm version of RXTX the  
> last days. I am working on the README .OSX now and try to figure out  
> which should be the "suggested" installation.
> 
> The facts:
> ------
> 
> - the "generic" comm.jar version of javax.comm which has been made re- 
> available tries to load com.sun.comm.SolarisDriver
> - this classname can be overridden ONLY by putting a file  
> javax.comm.properties in {java.home}/lib
> - if it is not overridden and SolarisDriver.class is not found  
> CommPortIdentifier will be disfunctional (in particual it is not  
> possible to add CommPort's via CommPortIdentifier.add).
> - the license distributed with comm.jar does not allow the  
> modification/addition of classes in javax.comm (however no mention of  
> com.sun...)
> 
> 
> What really bothers me is to suggest putting this config file in the  
> "global" vm installation. This is particularly ugly on the Mac as  
> there are several VM installations and the file may be forgotten.  
> Additionally it may create versioning problems. I prefer an  
> installation where all files are local to the application (even  
> comm.jar).
> 
> In my opinion the ideal situation would be:
> ------
> 
> 1) The author of a program compiles against javax.comm.
> 2a) For platforms supported by Sun the user is free to use the 3.0  
> comm.jar download from Sun
> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to  
> the classpath of the application (and librxtxSerial.jnilib to the  
> application directory). Also he will need the 2.0.3 generic comm.jar  
> from Sun.
> 3) Nobody messes with the global VM installation.
> 
> Of course 2a) and 2b) could be handled by the author of the program  
> via an appropriate installer. The author could also decide to always  
> use RXTX and include the generic javax.comm classes as well as the  
> RXTX classes in his application jar. [If he further uses an explicit  
> call to System.load() he may even include the jnilib(s) in the jar,  
> extract it (based on the platform name) at runtime to a temp file and  
> load it from there.]
> 

This was how the Sun implementation originated (I did not write
that code).  I completely agree, and I fixed the whole conf file
locating mechanism in 3.0 to avoid the problems youmentioned.
However, I was unaware of how RxTx was using Sun's implementation,
so I didn't architect it in such a way as to avoid namespace pollution
in the native space in for the backend provider.  In retrospect,
I should have done that differently just as a design principle,
but at this point I don't have the spare cycles to get that all
re-factored.  Further, I'm loathe to do it, because the whole
thing will still be an under-the-hood hack due to the constraints
of the API itself.

Paul





From brian at mbari.org  Tue Jun 20 10:23:54 2006
From: brian at mbari.org (Brian Schlining)
Date: Tue, 20 Jun 2006 09:23:54 -0700
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>


Hi Joachim,

> There has been some discussions about the best way to install RXTX
> and where to place files.
>
> I suggest that,
>
> - we include the native libraries for the most common operating
> systems (in a special version of) RXTXcomm.jar
> - we add loader code which tries to extract and load the platform
> specific binary at runtime
> - on failure the current mechanism remains as a fallback

I like your suggestion. However, my understanding is that in general  
the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH  
(Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to  
be loaded by the JVM. The alternative is to point to your native lib  
directory using -Djava.library.path=/my/dir/with/native/libs when you  
launch the JVM. So, I'm very interested to know how you're planning  
to work around this.

> PS: Of course the suggested solution is already possible today,
> however relatively few programmers know how to correctly extract a
> binary resource file via the class loader and load it as a native
> library.

So how do you use it to dynamically load a native lib? I've read that  
you can't really modify the java.library.path after the JVM has been  
launched. (http://forum.java.sun.com/thread.jspa? 
threadID=627890&tstart=90)

Thanks

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0017.html

From joachim at buechse.de  Tue Jun 20 09:20:29 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 17:20:29 +0200
Subject: [Rxtx] 2.0x in sync with 2.1x
Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>

I have added most of the changes from the 2.1 branch to the 2.0 branch.

This includes
  - correction of illegal javadoc comments
  - implementation errors in handling of Thread.interrupt in  
RXTXPort.java
  - MacOS X locking without lock files/special user groups
  - XCode project which builds a universal binary library
  - updated documentation for OSX

I have done some minimal testing (only G4).
[Trent: there are still some changes you made for specific baud  
rates. I will not sync this, as I can not test them. From my  
perspective we are ready for 2.08/2.18]

The updated documentation can be found in the file README.OSX. Here  
it is:

------------------------ Required files -----------------------

To use or compile RXTX 2.0.x you need to downlad the "generic"  
version (2.0.3)
of the javax.comm implementation from Sun. The zip you download  
contains an
archive comm.jar which is required:

- To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar

- To run the app you will need comm.jar in the classpath or in  
{java.lib.path}


------------------------ Installation on MacOSX -----------------------

WARNING: Please read this section until the end.

---
Preparation
---

You may want to spare your users the burden of modifying the global VM
installation. OSX has several different VM versions installed by  
default and
regular users will be unable to figure out which version will load your
application.

If you provide the class

package com.sun.comm;
public class SolarisDriver extends gnu.io.RXTXCommDriver {
}

and make sure, that it is present in the classpath before Suns  
"generic" comm.jar
your users can skip the following step:

Create a file named
    javax.comm.properties
in the directory
    /System/Library/Frameworks/JavaVM.framework/Home/lib/
which contains (only) the following line (no leading space):
    Driver=gnu.io.RXTXCommDriver



----
The unsafe way of using RXTX on OS X:
----

RXTX can be installed by putting the files
   libSerial.jnilib
   RXTXcomm.jar
   comm.jar
into the folder
   /Library/Java/Extensions

This is NOT RECOMMENDED as it creates versioning conflicts among  
applications.
However you may be forced to install it this way if an application  
was written
for Windows or Linux, requires RXTX and you are not able to change  
its starter.


----
The safe way of using RXTX on OS X:
----

Make sure that you have no (older) version of RXTX installed in
   /Library/Java/Extensions
   /System/Library/Java/Extensions
   /usr/lib/java

Put
   libSerial.jnilib
in the directory of the application (the JavaVM will find it there). Add
   RXTXComm.jar
   comm.jar
to the application classpath or include the classes in the  
application jar.
(Some applications already include the RXTX classes in their  
application jar,
in which case only the file libSerial.jnilib is required).


----
History
----

Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation  
of lockfiles
required special permissions for the user executing an application  
based on RXTX.
To simplify the setup RXTX came with an installer modifying group  
permissions
and installing RXTX in the global location /Library/Java/Extensions.  
However
this was prune to versioning conflicts and is no longer recommended.

--------------------- Build instructions for OSX XCode  
-------------------

contributed by Joachim Buechse <joachim at buechse.de>
original version by Dmitry Markman <dmarkman at mac.com>

System requirements for building:
MacOSX 10.4
XCode 2.3

   open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj
   choose libSerial.jnilib target
   build

After the build you will find RXTXcomm.jar and libSerial.jnilib files  
in the
directory build/Development.

In case you can't find RXTXcomm.jar build the RXTXcomm target manually.
In case of (serious) problems feel free to contact joachim at buechse.de .



From tjarvi at qbang.org  Tue Jun 20 22:01:45 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT)
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
Message-ID: <Pine.LNX.4.61.0606202127270.14139@www>

> ---
> Preparation
> ---
>
> You may want to spare your users the burden of modifying the global VM
> installation. OSX has several different VM versions installed by
> default and
> regular users will be unable to figure out which version will load your
> application.
>
> If you provide the class
>
> package com.sun.comm;
> public class SolarisDriver extends gnu.io.RXTXCommDriver {
> }
>
> and make sure, that it is present in the classpath before Suns
> "generic" comm.jar
> your users can skip the following step:

Hi Joachim

With regards to the above, I have not seen that we have Sun's OK to 
promote that.  I'm not very comfortable with the distribution 
documentation advocating this without Sun agreeing.

I see your point but I'd rather not actively promote putting classes in 
Sun's namespace without permission if you don't mind.  This isn't about 
what is in a license.

I'll go through the code tomorrow night.  It was a late night at work 
today.  There is also a w32 fix comming for people opening and closing 
multiple ports.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Wed Jun 21 01:56:45 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 21 Jun 2006 09:56:45 +0200
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <Pine.LNX.4.61.0606202127270.14139@www>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
	<Pine.LNX.4.61.0606202127270.14139@www>
Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>

Hello Trent,

I guess we will not get an explicit OK from Sun for such a hack. I  
think Paul has made it pretty clear, that he does not have the  
resources to modify the 2.x or 3.x code for the needs of RXTX. I'm  
not thrilled but OK with the current API. Hence I dont agree with  
Paul's idea to start a new JSR to fix the implementation - but that's  
mainly because I dont have the time to push it. According to their  
Readme Sun sees no business case in having cross platform support for  
javax.comm - that is sad but it's none of my business. However I  
prefer to program versus javax.comm in my projects as this gives an  
advanced user the chance to exchange the provider without access to  
the code.

I interpret Pauls reponse to my original "Request for comment" as a  
quiet acceptance of the hack I propose (he did respond, but not at  
all to the sun.comm namespace suggestion). This is certainly not  
something we should put into RXTXcomm.jar but hinting a work around  
for implementation errors should be allowed. That's why I've choosen  
the wording "You may want to spare" and "If you provide". The company  
I worked for has choosen similar hacks for years to fix bugs in swing  
for JDK1.1 applications. Those hacks were usually included in their  
own swingpatch.jar.

Having said all that - I do not take it as an insult if you remove  
the paragraph from the Readme. I appreciate that you notified me  
before. It would be interesting to hear some more opinions from the  
list members...

Best regards,
Joachim


On 21.06.2006, at 06:01, Trent Jarvi wrote:

>> ---
>> Preparation
>> ---
>>
>> You may want to spare your users the burden of modifying the  
>> global VM
>> installation. OSX has several different VM versions installed by
>> default and
>> regular users will be unable to figure out which version will load  
>> your
>> application.
>>
>> If you provide the class
>>
>> package com.sun.comm;
>> public class SolarisDriver extends gnu.io.RXTXCommDriver {
>> }
>>
>> and make sure, that it is present in the classpath before Suns
>> "generic" comm.jar
>> your users can skip the following step:
>
> Hi Joachim
>
> With regards to the above, I have not seen that we have Sun's OK to
> promote that.  I'm not very comfortable with the distribution
> documentation advocating this without Sun agreeing.
>
> I see your point but I'd rather not actively promote putting  
> classes in
> Sun's namespace without permission if you don't mind.  This isn't  
> about
> what is in a license.
>
> I'll go through the code tomorrow night.  It was a late night at work
> today.  There is also a w32 fix comming for people opening and closing
> multiple ports.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Wed Jun 21 02:03:33 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 21 Jun 2006 10:03:33 +0200
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
	<6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
Message-ID: <BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>

See System.load(String) [it's also mentioned under the URL you posted].

Regards,
Joachim


On 20.06.2006, at 18:23, Brian Schlining wrote:

> So how do you use it to dynamically load a native lib? I've read  
> that you can't really modify the java.library.path after the JVM  
> has been launched. (http://forum.java.sun.com/thread.jspa? 
> threadID=627890&tstart=90)
>
> Thanks
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From baris.ozkan at elikasu.com.tr  Wed Jun 21 07:58:06 2006
From: baris.ozkan at elikasu.com.tr (Baris)
Date: Wed, 21 Jun 2006 16:58:06 +0300
Subject: [Rxtx] RS 232 ..additional parameters
Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>

Hi,
 
Currently i am developing an application that requires to connect to a
remote rs232 device through  a dialup connection.
 
My problem is that the communication needs several more connection
parameters (i extracted that information from the vendor's dll , listed at
the end of the message)
 
I explored rxtx API and src files and could not find methods to set a
majority  of the parameters.
Am i missing any point or does rxtx is limited to soem standard set of
functionality(e.g. commAPI)? How  is it possible ,if i want to put some
extensions(???) to current rxtx implementation?
 
I am not very good at rs232 programming so excuse me if this message  is
boring one.
 
Thanx
 
Baris Ozkan
 
 
A Listing of Parameters:
 
 
typedef struct _DCB {

DWORD DCBlength; /* sizeof(DCB) */

DWORD BaudRate; /* Baudrate at which running */

DWORD fBinary: 1; /* Binary Mode (skip EOF check) */

DWORD fParity: 1; /* Enable parity checking */

DWORD fOutxCtsFlow:1; /* CTS handshaking on output */

DWORD fOutxDsrFlow:1; /* DSR handshaking on output */

DWORD fDtrControl:2; /* DTR Flow control */

DWORD fDsrSensitivity:1; /* DSR Sensitivity */

DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */

DWORD fOutX: 1; /* Enable output X-ON/X-OFF */

DWORD fInX: 1; /* Enable input X-ON/X-OFF */

DWORD fErrorChar: 1; /* Enable Err Replacement */

DWORD fNull: 1; /* Enable Null stripping */

DWORD fRtsControl:2; /* Rts Flow control */

DWORD fAbortOnError:1; /* Abort all reads and writes on Error */

DWORD fDummy2:17; /* Reserved */

WORD wReserved; /* Not currently used */

WORD XonLim; /* Transmit X-ON threshold */

WORD XoffLim; /* Transmit X-OFF threshold */

BYTE ByteSize; /* Number of bits/byte, 4-8 */

BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */

BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */

char XonChar; /* Tx and Rx X-ON character */

char XoffChar; /* Tx and Rx X-OFF character */

char ErrorChar; /* Error replacement char */

char EofChar; /* End of Input character */

char EvtChar; /* Received Event character */

WORD wReserved1; /* Fill for now. */

} DCB, *LPDCB;

typedef struct _COMMTIMEOUTS {

DWORD ReadIntervalTimeout; /* Maximum time between read chars. */

DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */

DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */

DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */

DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */

} COMMTIMEOUTS,*LPCOMMTIMEOUTS;

dcb.fOutX = FALSE;

dcb.fInX = FALSE;

dcb.fOutxCtsFlow = FALSE;

dcb.fBinary = TRUE;

dcb.fRtsControl = RTS_CONTROL_ENABLE;

SetCommState(hComm , &dcb ); 

COMMTIMEOUTS commTimeOut;

GetCommTimeouts(hComm, &commTimeOut );

commTimeOut.WriteTotalTimeoutMultiplier = 1; 

commTimeOut.WriteTotalTimeoutConstant = 18; 

// commTimeOut.ReadIntervalTimeout = 28; 

commTimeOut.ReadIntervalTimeout = 0; 

// commTimeOut.ReadTotalTimeoutMultiplier = 184; 

commTimeOut.ReadTotalTimeoutMultiplier = 300; 

// commTimeOut.ReadTotalTimeoutConstant = 1200;

commTimeOut.ReadTotalTimeoutConstant = 1200;

SetCommTimeouts(hComm, &commTimeOut);

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0017.html

From ajmas at sympatico.ca  Wed Jun 21 08:14:26 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Wed, 21 Jun 2006 10:14:26 -0400
Subject: [Rxtx] When is 2.18 planned for?
Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

Just curious as to know if there is a target date for 2.18?

Andre



From brian at mbari.org  Wed Jun 21 09:36:00 2006
From: brian at mbari.org (Brian Schlining)
Date: Wed, 21 Jun 2006 08:36:00 -0700
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
	<6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
	<BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>
Message-ID: <A21C9BC0-7894-4B08-AC82-44E11AB3D461@mbari.org>

Ha!!

I suppose I should read my own postings. ;-)

Thanks
B

On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote:

> See System.load(String) [it's also mentioned under the URL you  
> posted].
>
> Regards,
> Joachim
>
>
> On 20.06.2006, at 18:23, Brian Schlining wrote:
>
>> So how do you use it to dynamically load a native lib? I've read
>> that you can't really modify the java.library.path after the JVM
>> has been launched. (http://forum.java.sun.com/thread.jspa?
>> threadID=627890&tstart=90)

Brian Schlining
Software Engineer
http://www.mbari.org




From ajmas at sympatico.ca  Wed Jun 21 16:41:28 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Wed, 21 Jun 2006 18:41:28 -0400
Subject: [Rxtx] CVS build question
Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X:

 The JCL extension to RxTx requires comm.jar
 If you intend to use RxTx for commapi support comm.jar
 needs to be located in  /System/Library/Frameworks/JavaVM.framework/
  Versions/1.5/Home/lib/ext/comm.jar

I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me.

On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native).

Andre






From tjarvi at qbang.org  Wed Jun 21 18:00:04 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT)
Subject: [Rxtx] CVS build question
In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606211756310.14139@www>

On Wed, 21 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> Is the CVS repository meant to build for gnu.io or javax.comm? I ask 
> this, because I see the following when calling ./configure from MacOS X:
>
> The JCL extension to RxTx requires comm.jar
> If you intend to use RxTx for commapi support comm.jar
> needs to be located in  /System/Library/Frameworks/JavaVM.framework/
>  Versions/1.5/Home/lib/ext/comm.jar
>
> I am wanting to build for the gnu.io package, since I want to jump ahead 
> and see if the changes, intended for 2.18 for MacOS X, work for me.
>
> On a side note /Library/Java/Extensions should be included as a valid 
> search path for the JAR, since this is where Apple recommends placing 
> third party extensions (both Java and native).
>

rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel"
rxtx 2.0 src is obtained with "cvs checkout rxtx-devel"

rxtx 2.1 is a complete package in namespace gnu.io
rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 18:02:23 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT)
Subject: [Rxtx] When is 2.18 planned for?
In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606211800180.14139@www>

On Wed, 21 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> Just curious as to know if there is a target date for 2.18?
>

Hi Andre

"When it is ready" :)

Probably this weekend.  Maybe sooner.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 18:10:18 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT)
Subject: [Rxtx] RS 232 ..additional parameters
In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>
References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>
Message-ID: <Pine.LNX.4.61.0606211805010.14139@www>

On Wed, 21 Jun 2006, Baris wrote:

> Hi,
>
> Currently i am developing an application that requires to connect to a
> remote rs232 device through  a dialup connection.
>
> My problem is that the communication needs several more connection
> parameters (i extracted that information from the vendor's dll , listed at
> the end of the message)
>
> I explored rxtx API and src files and could not find methods to set a
> majority  of the parameters.
> Am i missing any point or does rxtx is limited to soem standard set of
> functionality(e.g. commAPI)? How  is it possible ,if i want to put some
> extensions(???) to current rxtx implementation?
>
> I am not very good at rs232 programming so excuse me if this message  is
> boring one.
>
> Thanx
>

Hi Baris

> typedef struct _DCB {
> typedef struct _COMMTIMEOUTS {

These are all handled in termios.c.  It is possible to add extensions to 
rxtx 2.1.  It may well be that the defaults are the same for the variables 
not covered by the existing API.  You can dump the DCB and COMMTIMEOUTS 
from inside termios.c to compare.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 20:23:30 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT)
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
	<Pine.LNX.4.61.0606202127270.14139@www>
	<789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>
Message-ID: <Pine.LNX.4.61.0606212012210.14139@www>

> I'm
> not thrilled but OK with the current API. Hence I dont agree with
> Paul's idea to start a new JSR to fix the implementation - but that's
> mainly because I dont have the time to push it. According to their
> Readme Sun sees no business case in having cross platform support for
> javax.comm - that is sad but it's none of my business. However I
> prefer to program versus javax.comm in my projects as this gives an
> advanced user the chance to exchange the provider without access to
> the code.

Hi Joachim

With regards to the JSR, I think that would be Doug's call.  The effort I 
put in would have to be on my own time which would not be a great deal.  I 
could help things go smoothly but thats not the same as pushing something 
through.

--
Trent Jarvi
tjarvi at qbang.org



From vt at freehold.crocodile.org  Wed Jun 21 21:05:22 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Wed, 21 Jun 2006 20:05:22 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
Message-ID: <449A08F2.3020106@freehold.crocodile.org>

Hello all,

I know this question may belong to JSR lists, but since all interested 
parties are here, I thought I just ask this question here, again...

A while ago I run into a problem and wrote a rant, here: 
http://servomaster.sourceforge.net/dev/serial-usb.html
At the time of writing I didn't think of adding another possible 
solution - changing the CommAPI specs to support removable devices. 
Apparently, Serial/USB bridges are here to stay, and this issue has to 
be addressed.

Wonder if anything changed since, and any abstractions for supporting 
removable devices made it into current or future Java CommAPI drafts - 
Paul, any comments?

--vt



From joachim at buechse.de  Thu Jun 22 01:59:54 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 22 Jun 2006 09:59:54 +0200
Subject: [Rxtx] CVS build question
In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de>

Hello Andre,

I am not sure how well the configure/make mechanism will work on OSX.  
I know that a while ago some contributors tried to get configure/make  
working on OSX but from comments I found in the readmes this work was  
only partially successfull. For compilation on OSX we have used the  
ProjectBuilder/XCode projects you can find in MACOSX_IDE.

Regarding the  ./configure comment:
RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config  
file javax.comm.properties. The later MUST reside in {java.home}/lib.  
As the two only work together putting comm.jar into  /Library/Java/ 
Extensions  and hence making it available to all current and future  
VM installations will only add to confusion.

Regards,
Joachim

On 22.06.2006, at 00:41, Andre-John Mas wrote:

> Hi,
>
> Is the CVS repository meant to build for gnu.io or javax.comm? I  
> ask this, because I see the following when calling ./configure from  
> MacOS X:
>
>  The JCL extension to RxTx requires comm.jar
>  If you intend to use RxTx for commapi support comm.jar
>  needs to be located in  /System/Library/Frameworks/JavaVM.framework/
>   Versions/1.5/Home/lib/ext/comm.jar
>
> I am wanting to build for the gnu.io package, since I want to jump  
> ahead and see if the changes, intended for 2.18 for MacOS X, work  
> for me.
>
> On a side note /Library/Java/Extensions should be included as a  
> valid search path for the JAR, since this is where Apple recommends  
> placing third party extensions (both Java and native).
>
> Andre
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Thu Jun 22 02:51:05 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 22 Jun 2006 10:51:05 +0200
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449A08F2.3020106@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>

Hello Vadim,

I think that your rant is to the point. However it is a bit like  
saying that Windows is at the source of email degradation and the  
only solution is to have users switch to safer operating systems.

I don't see how javax.comm or RXTX can address the problems you  
mention. Of course it would be super cool if javax.comm could magicly  
find the "matching" usb-device and query it's configuration via the  
usb protocol - however this magic (mapping /dev/xyz to its underlying  
USB device) is not supported by any kernel APIs I am aware of. It  
could be supported via POSSIX ioctl calls but then you should address  
your rant to the POSSIX group...

So for the time beeing it's either up to the virtual comm port driver  
to provide a usefull name under /dev/ or to the user choosing the  
right port to use. One example of a smart(er) com port driver is the  
KDDI driver for OSX, which will create device names like "/dev/ 
cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- 
encoded into the bridge chip. The same driver for windows also has  
some options allowing it in theory to recreate the same COMx every  
time a device is plugged/unplugged.

For most industrial applications however it will be up to the user to  
choose the right port (without getting a lot of help doing so).

Probing serial ports can go wrong, that's right. However any serial  
device developper would be well adviced to implement a basic set of  
Hayes AT modem commands (be it a modem or not). Especially AT I0.  
Anyone failing to do so risks that the users favourite TCP/PPP/FAX  
application or stack will kill the device in short time.

Best regards,
Joachim


On 22.06.2006, at 05:05, Vadim Tkachenko wrote:

> Hello all,
>
> I know this question may belong to JSR lists, but since all interested
> parties are here, I thought I just ask this question here, again...
>
> A while ago I run into a problem and wrote a rant, here:
> http://servomaster.sourceforge.net/dev/serial-usb.html
> At the time of writing I didn't think of adding another possible
> solution - changing the CommAPI specs to support removable devices.
> Apparently, Serial/USB bridges are here to stay, and this issue has to
> be addressed.
>
> Wonder if anything changed since, and any abstractions for supporting
> removable devices made it into current or future Java CommAPI drafts -
> Paul, any comments?
>
> --vt
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From vt at freehold.crocodile.org  Thu Jun 22 13:16:03 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 12:16:03 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
Message-ID: <20060622191603.GA17487@freehold.crocodile.org>

Hello Joachim,

> I think that your rant is to the point. However it is a bit like  
> saying that Windows is at the source of email degradation and the  
> only solution is to have users switch to safer operating systems.

I guess the problem is that the rant itself is obsolete and has to be
updated according to latest developments. At the time of writing there
weren't that many bridges around, and the trend didn't manifest itself as it
does now.

> I don't see how javax.comm or RXTX can address the problems you  
> mention.

I would agree that javax.comm won't be able to address the problem, at least
in the short run. As for RxTx - well, nobody prevents it from being a
superset of CommAPI specification, right? RxTx being the de-facto standard
for quite a few platforms, I'd daresay the standard may follow.

> Of course it would be super cool if javax.comm could magicly find the
> "matching" usb-device and query it's configuration via the usb protocol -
> however this magic (mapping /dev/xyz to its underlying USB device) is not
> supported by any kernel APIs I am aware of. It could be supported via
> POSSIX ioctl calls but then you should address your rant to the POSSIX
> group...

As a matter of fact, my bigger concern is addressing the fact that a serial
device can now be removable. This hasn't been the case before, and it
clearly is now. Regarding the above, well, I guess if we accept this fact,
we also need to accept the fact that we need at least rudimentary means of
identification of a serial device. For the USB case, it would usually be the
vendor/product ID, plus possible serial number - but it is irrelevant what
exactly the identifying information is, as long as it allows to identify the
device.

A paradigm shift is required, this is what I wanted to say. Serial devices
can be removed and replaced, it's now our turn to learn to deal with it.

> Joachim

--vt


From jredman at ergotech.com  Thu Jun 22 13:41:44 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 13:41:44 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
Message-ID: <449AF278.6000903@ergotech.com>


Vadim Tkachenko wrote:
> A paradigm shift is required, this is what I wanted to say. Serial devices
> can be removed and replaced, it's now our turn to learn to deal with it.

The removal if the serial port hardly significantly different from the 
removal of the device attached to the serial port.   Different, 
slightly, but not a "paradigm shift".

And yes, someone could unplug a USB serial device and plug it into a 
different USB port so that it has a different name/number, but they 
could do that with the device itself, move it from com1 to com2.

Am I missing something?

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 13:57:27 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 12:57:27 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449AF278.6000903@ergotech.com>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
Message-ID: <20060622195727.GA20247@freehold.crocodile.org>

On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote:
> 
> Vadim Tkachenko wrote:
> > A paradigm shift is required, this is what I wanted to say. Serial devices
> > can be removed and replaced, it's now our turn to learn to deal with it.
> 
> The removal if the serial port hardly significantly different from the 
> removal of the device attached to the serial port.   Different, 
> slightly, but not a "paradigm shift".
> 
> And yes, someone could unplug a USB serial device and plug it into a 
> different USB port so that it has a different name/number, but they 
> could do that with the device itself, move it from com1 to com2.
> 
> Am I missing something?

Yes, the fact that they could unplug a device A and plug a device B. With
the introduction of the concept of removability, the notion of the serial
port itself is not as important anymore, but the notion of the unique device
identifier is.

Consider a situation: long running system (enterprise HVAC, tens of nodes,
tens of thousands square feet area, hundreds of thousand dollars worth of
equipment being conditioned, can't shut down), serial/usb device fails, is
replaced by an identical device with a different serial #.

A little bit farfetched, but hopefully highlighting the point I'm trying to
make.

> Jim

--vt


From jredman at ergotech.com  Thu Jun 22 14:37:38 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 14:37:38 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>	<20060622191603.GA17487@freehold.crocodile.org>	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
Message-ID: <449AFF92.8080003@ergotech.com>


Vadim Tkachenko wrote:
>>
>> Am I missing something?
> 
> Yes, the fact that they could unplug a device A and plug a device B. With
> the introduction of the concept of removability, the notion of the serial
> port itself is not as important anymore, but the notion of the unique device
> identifier is.

Serial devices are always removable.  I could unplug _serial_ device A 
and plug in _serial_ device B.  We have systems running with two RS485 
ports, one talks to a Modbus PLC network one to a number of drives on a 
proprietary protocol.  If you plug the wrong DB9 into the wrong port the 
application doesn't work.

If you dangle a USB 485 converter on the end of the DB9 you've just 
moved the problem from RS485 to USB, but the problem/effect is the same.

> 
> Consider a situation: long running system (enterprise HVAC, tens of nodes,
> tens of thousands square feet area, hundreds of thousand dollars worth of
> equipment being conditioned, can't shut down), serial/usb device fails, is
> replaced by an identical device with a different serial #.
> 
> A little bit farfetched, but hopefully highlighting the point I'm trying to
> make.

Nothing's changed.  If I had a 4 port ISA board and plugged it into my 
new shiny '386 machine.  I could have com ports 9-12.  If I took a board 
off the shelf and didn't set the jumpers, I would have com ports 3-6.

The problem's the same.  If you replace with identical product then the 
com ports  will be the same - no software changes required.  If you 
replace one piece of hardware with hardware from a different 
manufacturer, then the naming/numbering may change.  You're physically 
changing the system, so may reasonably expect to have to make a software 
change.  RXTX actually handles this situation quite well with the -D 
command line option.  (My experience has generally been that the port 
number depends more on the USB port used than the hardware - so the 
chances are even with a hardware change the port number/name will be the 
same.)

Slightly Off Topic - there is a reason why industrial users will pay a 
premium for continued availability of hardware.  Yes you can mail-order 
a $10 USB converter and it will work, but there's no guarantee that the 
next time you buy the same part number from the same vendor it will be 
the same.  The industrial vendors will charge you $100+ for the same 
item, but it will be the same every time you buy it for the next 5 to 10 
years.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 14:37:19 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 13:37:19 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
Message-ID: <20060622203719.GA22521@freehold.crocodile.org>

Hello again,

And while I'm at it, why don't just say this: give me one good reason to
write 3+ different ways of handling removable devices, one for USB, one for
FireWire, one for serial...

I understand very well that this goes way beyond the scope of RxTx and
CommAPI and will require cooperation between them and javax.usb and whatever
JSR is responsible for FireWire implementation - but the end result is well
worth it. Abstract out and generalize arrival/departure/monitoring/discovery
API, provide protocol specific extensions for each, live happily ever after.

--vt


On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote:
> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote:
> > 
> > Vadim Tkachenko wrote:
> > > A paradigm shift is required, this is what I wanted to say. Serial devices
> > > can be removed and replaced, it's now our turn to learn to deal with it.
> > 
> > The removal if the serial port hardly significantly different from the 
> > removal of the device attached to the serial port.   Different, 
> > slightly, but not a "paradigm shift".
> > 
> > And yes, someone could unplug a USB serial device and plug it into a 
> > different USB port so that it has a different name/number, but they 
> > could do that with the device itself, move it from com1 to com2.
> > 
> > Am I missing something?
> 
> Yes, the fact that they could unplug a device A and plug a device B. With
> the introduction of the concept of removability, the notion of the serial
> port itself is not as important anymore, but the notion of the unique device
> identifier is.
> 
> Consider a situation: long running system (enterprise HVAC, tens of nodes,
> tens of thousands square feet area, hundreds of thousand dollars worth of
> equipment being conditioned, can't shut down), serial/usb device fails, is
> replaced by an identical device with a different serial #.
> 
> A little bit farfetched, but hopefully highlighting the point I'm trying to
> make.
> 
> > Jim
> 
> --vt
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx


From jredman at ergotech.com  Thu Jun 22 15:13:49 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 15:13:49 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>	<20060622191603.GA17487@freehold.crocodile.org>	<449AF278.6000903@ergotech.com>	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
Message-ID: <449B080D.9080208@ergotech.com>


Vadim Tkachenko wrote:
> Hello again,
> 
> And while I'm at it, why don't just say this: give me one good reason to
> write 3+ different ways of handling removable devices, one for USB, one for
> FireWire, one for serial...

You don't, they're all the same "I have lost communication with my 
serial device".

The only thing you could really do is improve error reporting by knowing 
the exact sub-system.  ("Device X which is/was attached to USB port Y is 
no longer functioning, please check the USB ports, the device, the 
cables and anything else you can think of that may be a cause of 
failure.")  That just requires an intelligent description of the port.

> I understand very well that this goes way beyond the scope of RxTx and
> CommAPI and will require cooperation between them and javax.usb and whatever
> JSR is responsible for FireWire implementation - but the end result is well
> worth it. Abstract out and generalize arrival/departure/monitoring/discovery
> API, provide protocol specific extensions for each, live happily ever after.

There's a huge list of pseudo-serial devices each with a different set 
of requirements, Bluetooth, RFC 2217, a host of proprietary systems, 
etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I 
have no clue how you'd implement them in a general/cross platform sense.

You haven't convinced me (and only me, others may see something that I 
don't, I'm not speaking for them) that this mechanism can be implemented 
in any practical sense.  That is, that the implementation could be wide 
enough to be consider generally available in RXTX regardless of the 
serial port implementation, platform, etc..  However, if you can come up 
with a general design and a reference implementation for one subsystem, 
I'd like to see it and might get on board.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 15:40:55 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 14:40:55 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449B080D.9080208@ergotech.com>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
Message-ID: <20060622214055.GA25497@freehold.crocodile.org>

On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote:
> 
> Vadim Tkachenko wrote:
> > Hello again,
> > 
> > And while I'm at it, why don't just say this: give me one good reason to
> > write 3+ different ways of handling removable devices, one for USB, one for
> > FireWire, one for serial...
> 
> You don't, they're all the same "I have lost communication with my 
> serial device".

"I have lost communication with my ${protocol} device".

> The only thing you could really do is improve error reporting by knowing 
> the exact sub-system.  ("Device X which is/was attached to USB port Y is 
> no longer functioning, please check the USB ports, the device, the 
> cables and anything else you can think of that may be a cause of 
> failure.")

"Device ${id} which is/was attached to ${protocol} port ${port} is no longer
functioning, please check the ${protocol} ports, the device, the
${protocol_media} and anything else you can think of that may be a cause of
failure".

>  That just requires an intelligent description of the port.

Agree absolutely.

> > I understand very well that this goes way beyond the scope of RxTx and
> > CommAPI and will require cooperation between them and javax.usb and whatever
> > JSR is responsible for FireWire implementation - but the end result is well
> > worth it. Abstract out and generalize arrival/departure/monitoring/discovery
> > API, provide protocol specific extensions for each, live happily ever after.
> 
> There's a huge list of pseudo-serial devices each with a different set 
> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, 
> etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I 
> have no clue how you'd implement them in a general/cross platform sense.

That's because some of the protocols were created decades ago when
autoconfiguration wasn't even conceived, much less practical. RS232/RS485
don't have a clue about identity discovery, and even capabilities discovery
beyond obvious 8N1 etc.

I agree that today all these protocols have generally incompatible
strategies for handling the situations I'm trying to address, but there's
nothing that says it's not an oversight. Besides, we're dealing with the
devices at a level of abstraction that allows some simplifications and
generalizations, at least part of the time - unless it's the protocol
specific features we're dealing with.

> You haven't convinced me (and only me, others may see something that I 
> don't, I'm not speaking for them) that this mechanism can be implemented 
> in any practical sense.  That is, that the implementation could be wide 
> enough to be consider generally available in RXTX regardless of the 
> serial port implementation, platform, etc..  However, if you can come up 
> with a general design and a reference implementation for one subsystem, 
> I'd like to see it and might get on board.

Actually, I wasn't even thinking about all this stuff when I wrote the first
message on the subject :) Now that you mention it - well, I'm not sure I can
chew the piece I just tried to bite in reasonable amount of time.

How do you eat an elephant? One bite at a time. If we could agree that a
small step in the specification is acceptable at this time, and express
further intentions, things may start happening.

To put it succinctly:

- Concept of a "port" should be augmented with a concept of a "device". A
device may be attached to a port in an implicit or explicit way.
- Implicitly connected device is exactly what the current scope of the
specification covers. No new functionality is offered.
- Explicitly connected device supports detachable device semantics, just as
other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a
few).
- The input and output streams are not properties of a port now, but
properties of the device attached to the port.
- A mechanism to allow listening for device arrivals and departures must be
made available.

That's it, off the top of my head.

I understand that this goes completely against current javax.comm specs, but
an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be
difficult to implement without disrupting javax.comm compatibility.

One concern is how to deal with the device identity - but there's no general
way of dealing with this at this time, devices may or may not offer identity
discovery.

> Jim

--vt


From joachim at buechse.de  Fri Jun 23 02:12:43 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 23 Jun 2006 10:12:43 +0200
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
Message-ID: <CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>

Hello++ Vadim,

I would like to repeat that your request is best addressed to the  
POSSIX standardization group - or maybe the BSD/Linux maintainers. If  
you convince the BSD or Linux guys to add this kind of functionality  
(they can as most of there VCP drivers are open source), there is a  
certain chance that other vendors will pick it up. I assure you that  
RXTX will happily provide this functionality once it's possible - I'm  
sure there is more than one maintainer that would love to add it.  
Having this concept penetrate the market may take some years though.

SHORT: The solution you would like to see could be added to the API  
but it can not be implemented (at least not on the platforms I know).  
There are currently no hooks in the kernel that allow you to discover  
"the device" or even the "means of connection" based on an existing  
"device file descriptor" ie COM-port or /dev/... entry. The name  
mapping of the device is handled by the virtual com port driver of  
the device. Unless you are suggesting RXTX should reimplement virtual  
com port drivers for all usb/serial bridges out there your request is  
understandable from a users viewpoint but simply not realizable. It's  
like asking that the Socket api should identify the computer behind  
an IP address (ie by its Ethernet address). While this COULD be  
implemented in TCP/IP, it IS not, and hence there is no point adding  
such a function to the Socket API.

The current trend for USB/Bluetooth/Irda/etc connected devices is  
going away from serial port abstraction towards RPC (ie the drivers  
provide a device specific or device class specific driver that  
provides an application level api to the device functions). The line  
level protocol is often not even published.

Best regards,
Joachim

On 22.06.2006, at 23:40, Vadim Tkachenko wrote:

> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote:
>>
>> Vadim Tkachenko wrote:
>>> Hello again,
>>>
>>> And while I'm at it, why don't just say this: give me one good  
>>> reason to
>>> write 3+ different ways of handling removable devices, one for  
>>> USB, one for
>>> FireWire, one for serial...
>>
>> You don't, they're all the same "I have lost communication with my
>> serial device".
>
> "I have lost communication with my ${protocol} device".
>
>> The only thing you could really do is improve error reporting by  
>> knowing
>> the exact sub-system.  ("Device X which is/was attached to USB  
>> port Y is
>> no longer functioning, please check the USB ports, the device, the
>> cables and anything else you can think of that may be a cause of
>> failure.")
>
> "Device ${id} which is/was attached to ${protocol} port ${port} is  
> no longer
> functioning, please check the ${protocol} ports, the device, the
> ${protocol_media} and anything else you can think of that may be a  
> cause of
> failure".
>
>>  That just requires an intelligent description of the port.
>
> Agree absolutely.
>
>>> I understand very well that this goes way beyond the scope of  
>>> RxTx and
>>> CommAPI and will require cooperation between them and javax.usb  
>>> and whatever
>>> JSR is responsible for FireWire implementation - but the end  
>>> result is well
>>> worth it. Abstract out and generalize arrival/departure/ 
>>> monitoring/discovery
>>> API, provide protocol specific extensions for each, live happily  
>>> ever after.
>>
>> There's a huge list of pseudo-serial devices each with a different  
>> set
>> of requirements, Bluetooth, RFC 2217, a host of proprietary systems,
>> etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I
>> have no clue how you'd implement them in a general/cross platform  
>> sense.
>
> That's because some of the protocols were created decades ago when
> autoconfiguration wasn't even conceived, much less practical. RS232/ 
> RS485
> don't have a clue about identity discovery, and even capabilities  
> discovery
> beyond obvious 8N1 etc.
>
> I agree that today all these protocols have generally incompatible
> strategies for handling the situations I'm trying to address, but  
> there's
> nothing that says it's not an oversight. Besides, we're dealing  
> with the
> devices at a level of abstraction that allows some simplifications and
> generalizations, at least part of the time - unless it's the protocol
> specific features we're dealing with.
>
>> You haven't convinced me (and only me, others may see something  
>> that I
>> don't, I'm not speaking for them) that this mechanism can be  
>> implemented
>> in any practical sense.  That is, that the implementation could be  
>> wide
>> enough to be consider generally available in RXTX regardless of the
>> serial port implementation, platform, etc..  However, if you can  
>> come up
>> with a general design and a reference implementation for one  
>> subsystem,
>> I'd like to see it and might get on board.
>
> Actually, I wasn't even thinking about all this stuff when I wrote  
> the first
> message on the subject :) Now that you mention it - well, I'm not  
> sure I can
> chew the piece I just tried to bite in reasonable amount of time.
>
> How do you eat an elephant? One bite at a time. If we could agree  
> that a
> small step in the specification is acceptable at this time, and  
> express
> further intentions, things may start happening.
>
> To put it succinctly:
>
> - Concept of a "port" should be augmented with a concept of a  
> "device". A
> device may be attached to a port in an implicit or explicit way.
> - Implicitly connected device is exactly what the current scope of the
> specification covers. No new functionality is offered.
> - Explicitly connected device supports detachable device semantics,  
> just as
> other protocols do (USB, FireWire, Wireless USB, Bluetooth, to  
> mention a
> few).
> - The input and output streams are not properties of a port now, but
> properties of the device attached to the port.
> - A mechanism to allow listening for device arrivals and departures  
> must be
> made available.
>
> That's it, off the top of my head.
>
> I understand that this goes completely against current javax.comm  
> specs, but
> an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern )  
> won't be
> difficult to implement without disrupting javax.comm compatibility.
>
> One concern is how to deal with the device identity - but there's  
> no general
> way of dealing with this at this time, devices may or may not offer  
> identity
> discovery.
>
>> Jim
>
> --vt
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From vt at freehold.crocodile.org  Fri Jun 23 11:28:29 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Fri, 23 Jun 2006 10:28:29 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
	<CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
Message-ID: <20060623172829.GA5335@freehold.crocodile.org>

Hello Joachim,

> I would like to repeat that your request is best addressed to the POSSIX
> standardization group - or maybe the BSD/Linux maintainers. If you
> convince the BSD or Linux guys to add this kind of functionality (they can
> as most of there VCP drivers are open source), there is a certain chance
> that other vendors will pick it up. I assure you that RXTX will happily
> provide this functionality once it's possible - I'm sure there is more
> than one maintainer that would love to add it.

I realize this thing is bigger than RxTx itself, and I'm afraid it's too
global not to cause people to laugh before they think about it :)

> Having this concept penetrate the market may take some years though.

Well, I'm sure it'll get there, the only question is - when.

> SHORT: The solution you would like to see could be added to the API but it
> can not be implemented (at least not on the platforms I know).

I guess I'm concerned about the abstraction more than I'm concerned about
the implementation at this point.
  
> There are currently no hooks in the kernel that allow you to discover  
> "the device" or even the "means of connection" based on an existing  
> "device file descriptor" ie COM-port or /dev/... entry.

Well, I'm not so sure you need to keep the literal mapping from /dev
namespace to your device namespace. As long as you can consistently offer a
virtual serial device on top of a virtual serial port, it may be irrelevant
whether you can map it into /dev. The mapping is going be schitzofrenic
anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the
representation...

> The name mapping of the device is handled by the virtual com port driver
> of the device. Unless you are suggesting RXTX should reimplement virtual
> com port drivers for all usb/serial bridges out there your request is
> understandable from a users viewpoint but simply not realizable.

It's not so much a request but rather an offer of participation. I run a few
projects actively using serial communications, as well as USB device
drivers, in different degrees of readiness (Servomaster, Haywire, DIY
Zoning) - and it would be a perfect playground.

You mentioned above that this task is about two things: a) abstraction b)
implementation. I could start the abstraction part of it without changing
the current CommAPI, on top of it, as an adapter. Even if the removable
device semantics are not implemented, but offered, this is already a step
forward.

> It's like asking that the Socket api should identify the computer behind
> an IP address (ie by its Ethernet address). While this COULD be
> implemented in TCP/IP, it IS not, and hence there is no point adding such
> a function to the Socket API.

Thank you for bringing up this example - I guess this is just about the same
thing that I'd like to see. Socket transparently provides you with the
input/output streams, at the same time offering protocol level specifics to
you.

> The current trend for USB/Bluetooth/Irda/etc connected devices is going
> away from serial port abstraction towards RPC (ie the drivers provide a
> device specific or device class specific driver that provides an
> application level api to the device functions). The line level protocol is
> often not even published.

I can't say I'm that happy with it. The best (or, rather, worst) example is
suchlike support for the Phidget servo controller - zealous Linux developers
implemented kernel module support for it, completely hijacking a possibility
of using it on a different level (it's somewhat fixed by now, thankfully).

I believe that whenever an abstraction is offered, it must be made optional
and/or pluggable so it can be replaced by something more suited to the task.

The nature of Java applications is such that they'd probably care much more
about Java API offered, than about no matter how rich application level api
that is offered outside of Java. I've dealt with JNI adapters in the past,
and whereas they can be made reasonably stable, the very fact that you are
forced to deal with things that are not on the critical timing/memory path
and could've been done much easier in Java causes endless grief.

> Joachim

--vt


From lyon at docjava.com  Sat Jun 24 04:54:12 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Sat, 24 Jun 2006 06:54:12 -0400
Subject: [Rxtx] jsr
In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
	<CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
	<20060623172829.GA5335@freehold.crocodile.org>
Message-ID: <p060204a3c0c2c9dde4f8@[192.168.1.152]>

Hi All,
I have had some off-list discussion with Trent.
Opening up a JSR with Sun, as per Peters' suggestion
seems like a reasonable idea, to us.

Does anyone having any concerns about the JSR process
that they would like to raise?

Thanks!
  - Doug



From the.grey.lantern at gmail.com  Sat Jun 24 18:15:26 2006
From: the.grey.lantern at gmail.com (Craig Nicoll)
Date: Sun, 25 Jun 2006 01:15:26 +0100
Subject: [Rxtx] Cannot create virtual serial port
Message-ID: <a1221cc50606241715g2d1e2af6r747347dd4c20e997@mail.gmail.com>

Hello,

This is my first post on this mailing list and I hope someone can help me.

I am having great difficult establishing a virtual serial port for the
Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia
7600.

Every time I try to run the SendMessage program that comes with SMSLib, I
get the following exception: gnu.io.NoSuchPortException

The port names I have tried are:
rfcomm0
rfcomm
/dev/rfcomm0
/dev/rfcomm

This is what I have done so far:
Modified /etc/bluetooth/rfcomm.conf to include the address of my phone:

rfcomm0 {
# Automatically bind the device at startup
bind no;

# Bluetooth address of the device
device 00:0e:6d:7a:98:43;

# RFCOMM channel for the connection
channel 1;

# Description of the connection
comment "Example Bluetooth device";
}

I also tried running the following command: rfcomm bind /dev/rfcomm0

I have searched the mailing list archives and found this post where someone
had a very similar problem to me:
http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried
changing the system properties as suggested and it made no difference.

I have also been scouring Google all day to no avail.

I would be incredibly grateful if anyone could give me some tips.

Thank you,

Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060625/cfa6df35/attachment-0008.html

From tjarvi at qbang.org  Sun Jun 25 19:56:08 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT)
Subject: [Rxtx] Pending release
Message-ID: <Pine.LNX.4.61.0606251942460.15744@www>


With frustration, I was unable to get to the pending release this weekend.
The release should be comming this next week once things calm down.
The source is in CVS except for a fix for multiple ports in windows.

I had planned on doing the release this weekend but that was disrupted by 
my transportation failing in a spectacular fashion.

--
Trent Jarvi
tjarvi at qbang.org


From Pawan.Kharbanda at dot.state.co.us  Tue Jun 27 22:28:51 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 27 Jun 2006 22:28:51 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>

 Trent, 
   I have an application running in a cluster in linux environment and I
am using RXTX2.1.7 (final) with JDK1.5. The application opens and closes
serial comm ports every 30 seconds and exchanges datas. I have
experienced some of my Comm Ports are left hanging (I can see the
LCK..cufXX lock files under /var/lock folder). On putting the debugs I
found out that, it is stuck at a native call line 809 in RXTXPort.java
class (Please see the code snippet below). Can you help me explain what
this method does in the native code? Am I getting into some thread
deadlocks? Thanks in advance.

Pawan Kharbanda 


public void removeEventListener()
	{
		if (debug)
			z.reportln( "RXTXPort:removeEventListener()
called");
		waitForTheNativeCodeSilly();
		//if( monThread != null && monThread.isAlive() )
		if( monThreadisInterrupted == true )
		{
			z.reportln( "	RXTXPort:removeEventListener()
already interrupted");
			monThread = null;
			SPEventListener = null;
			return;
		}
		else if( monThread != null && monThread.isAlive() )
		{
			if (debug)
				z.reportln( "
RXTXPort:Interrupt=true");
			monThreadisInterrupted=true;
			/*
			   Notify all threads in this PID that something
is up
			   They will call back to see if its their
thread
			   using isInterrupted().
			*/
			if (debug)
				z.reportln( "	RXTXPort:calling
interruptEventLoop");
// LINE 809			interruptEventLoop( ); It never returns
out of this 
			
			if (debug)
				z.reportln( "	RXTXPort:calling
monThread.join()");
			try {
				monThread.join(1000);
			} catch (Exception ex) {
				/* yikes */
				ex.printStackTrace();
			}
			if (debug)
				z.reportln( "	RXTXPort:waiting on
isAlive()");
			while( monThread.isAlive() )
			{
				if ( debug )
					z.reportln( "	MonThread is
still alive!");
				try {
					monThread.join(1000);
					Thread.sleep( 1000 );
				} catch( Exception e ){} 
				//monThread.stop();
			}
			
		}
		if (debug)
			z.reportln( "	RXTXPort:calling gc()");
		monThread = null;
		SPEventListener = null;
		MonitorThreadLock = false;
		MonitorThreadAlive=false;
		monThreadisInterrupted=true;
		z.reportln( "RXTXPort:removeEventListener() returning");
	} 

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Sunday, June 25, 2006 7:56 PM
To: rxtx at qbang.org
Subject: [Rxtx] Pending release


With frustration, I was unable to get to the pending release this
weekend.
The release should be comming this next week once things calm down.
The source is in CVS except for a fix for multiple ports in windows.

I had planned on doing the release this weekend but that was disrupted
by my transportation failing in a spectacular fashion.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Wed Jun 28 04:17:29 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 28 Jun 2006 04:17:29 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606280406330.9561@www>



Hi Pawan

You may have found a deadlock but I've not seen on recently on linux.

If you can, please update from CVS.  This will have some close fixes. 
I'm running with the same code as is in CVS.  It is not perfect but I've 
not seen anything like you mention.  Be sure to set timeouts and 
thresholds on the port.  It may be that the port is waiting on pending io 
that never happens.  I think the CVS patches deal with this also but it 
looks like your in a better test environment to know for sure.

The exploded vehicle mentioned below is expected to be fixed today.  It 
was just a ninja small radiator hose.  The pressure test afterwards 
created its own set of problems.  Until this is resolved, I'm spending 
most of my free time commuting by bicycle.

On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>   I have an application running in a cluster in linux environment and I
> am using RXTX2.1.7 (final) with JDK1.5. The application opens and closes
> serial comm ports every 30 seconds and exchanges datas. I have
> experienced some of my Comm Ports are left hanging (I can see the
> LCK..cufXX lock files under /var/lock folder). On putting the debugs I
> found out that, it is stuck at a native call line 809 in RXTXPort.java
> class (Please see the code snippet below). Can you help me explain what
> this method does in the native code? Am I getting into some thread
> deadlocks? Thanks in advance.
>
> Pawan Kharbanda
>
>
> public void removeEventListener()
> 	{
> 		if (debug)
> 			z.reportln( "RXTXPort:removeEventListener()
> called");
> 		waitForTheNativeCodeSilly();
> 		//if( monThread != null && monThread.isAlive() )
> 		if( monThreadisInterrupted == true )
> 		{
> 			z.reportln( "	RXTXPort:removeEventListener()
> already interrupted");
> 			monThread = null;
> 			SPEventListener = null;
> 			return;
> 		}
> 		else if( monThread != null && monThread.isAlive() )
> 		{
> 			if (debug)
> 				z.reportln( "
> RXTXPort:Interrupt=true");
> 			monThreadisInterrupted=true;
> 			/*
> 			   Notify all threads in this PID that something
> is up
> 			   They will call back to see if its their
> thread
> 			   using isInterrupted().
> 			*/
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> interruptEventLoop");
> // LINE 809			interruptEventLoop( ); It never returns
> out of this
>
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> monThread.join()");
> 			try {
> 				monThread.join(1000);
> 			} catch (Exception ex) {
> 				/* yikes */
> 				ex.printStackTrace();
> 			}
> 			if (debug)
> 				z.reportln( "	RXTXPort:waiting on
> isAlive()");
> 			while( monThread.isAlive() )
> 			{
> 				if ( debug )
> 					z.reportln( "	MonThread is
> still alive!");
> 				try {
> 					monThread.join(1000);
> 					Thread.sleep( 1000 );
> 				} catch( Exception e ){}
> 				//monThread.stop();
> 			}
>
> 		}
> 		if (debug)
> 			z.reportln( "	RXTXPort:calling gc()");
> 		monThread = null;
> 		SPEventListener = null;
> 		MonitorThreadLock = false;
> 		MonitorThreadAlive=false;
> 		monThreadisInterrupted=true;
> 		z.reportln( "RXTXPort:removeEventListener() returning");
> 	}
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Sunday, June 25, 2006 7:56 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] Pending release
>
>
> With frustration, I was unable to get to the pending release this
> weekend.
> The release should be comming this next week once things calm down.
> The source is in CVS except for a fix for multiple ports in windows.
>
> I had planned on doing the release this weekend but that was disrupted
> by my transportation failing in a spectacular fashion.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From Pawan.Kharbanda at dot.state.co.us  Wed Jun 28 12:11:06 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Wed, 28 Jun 2006 12:11:06 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>

Trent,
    Again thanks for the reply. First of all I have Receive timeouts set
on all communications including Max no of bytes to expect during the
call. I have noticed the problem is during "closing the connection". I
am not sure if the RXTX is 100% thread-safe yet. There seems to be a
glitch in the native calls. I am sure I have the latest code I did the
update on the Version 2.1.7 from CVS, is this where the latest updates
are located, I have noticed another version in CVS "rxtx-devel".

Regards
Pawan Kharbanda

    

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Wednesday, June 28, 2006 4:17 AM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports



Hi Pawan

You may have found a deadlock but I've not seen on recently on linux.

If you can, please update from CVS.  This will have some close fixes. 
I'm running with the same code as is in CVS.  It is not perfect but I've
not seen anything like you mention.  Be sure to set timeouts and
thresholds on the port.  It may be that the port is waiting on pending
io that never happens.  I think the CVS patches deal with this also but
it looks like your in a better test environment to know for sure.

The exploded vehicle mentioned below is expected to be fixed today.  It
was just a ninja small radiator hose.  The pressure test afterwards
created its own set of problems.  Until this is resolved, I'm spending
most of my free time commuting by bicycle.

On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>   I have an application running in a cluster in linux environment and 
> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and 
> closes serial comm ports every 30 seconds and exchanges datas. I have 
> experienced some of my Comm Ports are left hanging (I can see the 
> LCK..cufXX lock files under /var/lock folder). On putting the debugs I

> found out that, it is stuck at a native call line 809 in RXTXPort.java

> class (Please see the code snippet below). Can you help me explain 
> what this method does in the native code? Am I getting into some 
> thread deadlocks? Thanks in advance.
>
> Pawan Kharbanda
>
>
> public void removeEventListener()
> 	{
> 		if (debug)
> 			z.reportln( "RXTXPort:removeEventListener()
called");
> 		waitForTheNativeCodeSilly();
> 		//if( monThread != null && monThread.isAlive() )
> 		if( monThreadisInterrupted == true )
> 		{
> 			z.reportln( "	RXTXPort:removeEventListener()
> already interrupted");
> 			monThread = null;
> 			SPEventListener = null;
> 			return;
> 		}
> 		else if( monThread != null && monThread.isAlive() )
> 		{
> 			if (debug)
> 				z.reportln( "
> RXTXPort:Interrupt=true");
> 			monThreadisInterrupted=true;
> 			/*
> 			   Notify all threads in this PID that something
is up
> 			   They will call back to see if its their
thread
> 			   using isInterrupted().
> 			*/
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> interruptEventLoop");
> // LINE 809			interruptEventLoop( ); It never returns
> out of this
>
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> monThread.join()");
> 			try {
> 				monThread.join(1000);
> 			} catch (Exception ex) {
> 				/* yikes */
> 				ex.printStackTrace();
> 			}
> 			if (debug)
> 				z.reportln( "	RXTXPort:waiting on
> isAlive()");
> 			while( monThread.isAlive() )
> 			{
> 				if ( debug )
> 					z.reportln( "	MonThread is
> still alive!");
> 				try {
> 					monThread.join(1000);
> 					Thread.sleep( 1000 );
> 				} catch( Exception e ){}
> 				//monThread.stop();
> 			}
>
> 		}
> 		if (debug)
> 			z.reportln( "	RXTXPort:calling gc()");
> 		monThread = null;
> 		SPEventListener = null;
> 		MonitorThreadLock = false;
> 		MonitorThreadAlive=false;
> 		monThreadisInterrupted=true;
> 		z.reportln( "RXTXPort:removeEventListener() returning");
> 	}
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf

> Of Trent Jarvi
> Sent: Sunday, June 25, 2006 7:56 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] Pending release
>
>
> With frustration, I was unable to get to the pending release this 
> weekend.
> The release should be comming this next week once things calm down.
> The source is in CVS except for a fix for multiple ports in windows.
>
> I had planned on doing the release this weekend but that was disrupted

> by my transportation failing in a spectacular fashion.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Wed Jun 28 12:26:21 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 28 Jun 2006 12:26:21 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606281222420.9561@www>


Hi Pawan

If you did a cvs update from the 2.1-7 tar ball, you have the current 
version.  All rxtx in CVS is under rxtx-devel.  The 2.1-7 just has -r
commapi-0-0-1.

You may well have found something.  I have seen win32 fail on closing 
ports but not linux that I can think of.  Your use is much different than 
I normally see too.

Could you give us more information on how we would reproduce this and the 
frequency?


On Wed, 28 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>    Again thanks for the reply. First of all I have Receive timeouts set
> on all communications including Max no of bytes to expect during the
> call. I have noticed the problem is during "closing the connection". I
> am not sure if the RXTX is 100% thread-safe yet. There seems to be a
> glitch in the native calls. I am sure I have the latest code I did the
> update on the Version 2.1.7 from CVS, is this where the latest updates
> are located, I have noticed another version in CVS "rxtx-devel".
>
> Regards
> Pawan Kharbanda
>
>
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Wednesday, June 28, 2006 4:17 AM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] Locked Ports
>
>
>
> Hi Pawan
>
> You may have found a deadlock but I've not seen on recently on linux.
>
> If you can, please update from CVS.  This will have some close fixes.
> I'm running with the same code as is in CVS.  It is not perfect but I've
> not seen anything like you mention.  Be sure to set timeouts and
> thresholds on the port.  It may be that the port is waiting on pending
> io that never happens.  I think the CVS patches deal with this also but
> it looks like your in a better test environment to know for sure.
>
> The exploded vehicle mentioned below is expected to be fixed today.  It
> was just a ninja small radiator hose.  The pressure test afterwards
> created its own set of problems.  Until this is resolved, I'm spending
> most of my free time commuting by bicycle.
>
> On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:
>
>> Trent,
>>   I have an application running in a cluster in linux environment and
>> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and
>> closes serial comm ports every 30 seconds and exchanges datas. I have
>> experienced some of my Comm Ports are left hanging (I can see the
>> LCK..cufXX lock files under /var/lock folder). On putting the debugs I
>
>> found out that, it is stuck at a native call line 809 in RXTXPort.java
>
>> class (Please see the code snippet below). Can you help me explain
>> what this method does in the native code? Am I getting into some
>> thread deadlocks? Thanks in advance.
>>
>> Pawan Kharbanda
>>
>>
>> public void removeEventListener()
>> 	{
>> 		if (debug)
>> 			z.reportln( "RXTXPort:removeEventListener()
> called");
>> 		waitForTheNativeCodeSilly();
>> 		//if( monThread != null && monThread.isAlive() )
>> 		if( monThreadisInterrupted == true )
>> 		{
>> 			z.reportln( "	RXTXPort:removeEventListener()
>> already interrupted");
>> 			monThread = null;
>> 			SPEventListener = null;
>> 			return;
>> 		}
>> 		else if( monThread != null && monThread.isAlive() )
>> 		{
>> 			if (debug)
>> 				z.reportln( "
>> RXTXPort:Interrupt=true");
>> 			monThreadisInterrupted=true;
>> 			/*
>> 			   Notify all threads in this PID that something
> is up
>> 			   They will call back to see if its their
> thread
>> 			   using isInterrupted().
>> 			*/
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> interruptEventLoop");
>> // LINE 809			interruptEventLoop( ); It never returns
>> out of this
>>
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> monThread.join()");
>> 			try {
>> 				monThread.join(1000);
>> 			} catch (Exception ex) {
>> 				/* yikes */
>> 				ex.printStackTrace();
>> 			}
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:waiting on
>> isAlive()");
>> 			while( monThread.isAlive() )
>> 			{
>> 				if ( debug )
>> 					z.reportln( "	MonThread is
>> still alive!");
>> 				try {
>> 					monThread.join(1000);
>> 					Thread.sleep( 1000 );
>> 				} catch( Exception e ){}
>> 				//monThread.stop();
>> 			}
>>
>> 		}
>> 		if (debug)
>> 			z.reportln( "	RXTXPort:calling gc()");
>> 		monThread = null;
>> 		SPEventListener = null;
>> 		MonitorThreadLock = false;
>> 		MonitorThreadAlive=false;
>> 		monThreadisInterrupted=true;
>> 		z.reportln( "RXTXPort:removeEventListener() returning");
>> 	}
>>
>> -----Original Message-----
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
>
>> Of Trent Jarvi
>> Sent: Sunday, June 25, 2006 7:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] Pending release
>>
>>
>> With frustration, I was unable to get to the pending release this
>> weekend.
>> The release should be comming this next week once things calm down.
>> The source is in CVS except for a fix for multiple ports in windows.
>>
>> I had planned on doing the release this weekend but that was disrupted
>
>> by my transportation failing in a spectacular fashion.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From Pawan.Kharbanda at dot.state.co.us  Wed Jun 28 15:42:49 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Wed, 28 Jun 2006 15:42:49 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>

Trent,
    I will try to explain how I am setup and will try to write you a
Sample code little later to reproduce this. On our system we have
DigiBoxes installed on the 2 Linux servers. Both of them have RXTX2.1-7
version installed with the JRE(1.5) and both the machines have the same
port mappings in gnu.io.rxtx.properties (Currently in the production
system I have 64 ports). This is how the system works:

1) A thick Map based client initiates a Action on the Device on the
field. One of the Thread Workers(Asynchronous Call) in the Cluster picks
up the request. 
2) Once the worker gets the request it locks the Device and
Communication port in the DB's(These are our persistent locks, because
most of the devices do one to one communication with the serial ports).
After that the worker (or Comm Server) opens up the connection and after
exchanging the information calls the "Close" and returns.
3) Once the connection is closed , the DB lock is removed on the comm
port and is made available to accept future calls. Here is where the
glitch is the Serial Comm Close method never returns due to the
deadlock. 

I have noticed that the deadlocks are very inconsistent, sometime it
happens right away as soon as Application server starts and sometimes I
don't see any deadlocks for days, but it happens for sure. 

Here is how you can test if you have resources/ test environment. Write
a program and try to open/close  different ports(I will say have a
minimum of four) randomly and very frequently(may be 30 seconds), I am
pretty sure you will see the deadlocks and it happens in the native call
to interrptEventLoop in RXTXPort.java in removeEventListener() method
call.

Also I have noticed that the JVM carshes (without any memrory errors or
JVM errors. Its just not there) when native call is made to eventLoop()
in run() method in MonitorThread inner class. I am still investigating
why this is happening, but at this point I can just tell you the
location. You might have a question How I am so sure about the location?
My application is configured with Log4J and I have enabled the debugs on
the RXTXPort.java, so every time my JVM dies I see these logs at the end
of the file.

"2006-06-28 15:27:15,183 INFO  [STDOUT] RXTXPort:RXTXPort(/dev/cub01)
called
2006-06-28 15:27:15,218 INFO  [STDOUT]
RXTXPort:MontitorThread:MonitorThread()
2006-06-28 15:27:15,219 INFO  [STDOUT] RXTXPort:MontitorThread:run()"

I surely do have a luxury of a testing environment(ports, devices etc.)
and can help you fix these problems? Please advise me how we can resolve
these issues.

Thanks 
Pawan Kharbanda
303-478-2991





-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Wednesday, June 28, 2006 12:26 PM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports


Hi Pawan

If you did a cvs update from the 2.1-7 tar ball, you have the current
version.  All rxtx in CVS is under rxtx-devel.  The 2.1-7 just has -r
commapi-0-0-1.

You may well have found something.  I have seen win32 fail on closing
ports but not linux that I can think of.  Your use is much different
than I normally see too.

Could you give us more information on how we would reproduce this and
the frequency?


On Wed, 28 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>    Again thanks for the reply. First of all I have Receive timeouts
set
> on all communications including Max no of bytes to expect during the
> call. I have noticed the problem is during "closing the connection". I
> am not sure if the RXTX is 100% thread-safe yet. There seems to be a
> glitch in the native calls. I am sure I have the latest code I did the
> update on the Version 2.1.7 from CVS, is this where the latest updates
> are located, I have noticed another version in CVS "rxtx-devel".
>
> Regards
> Pawan Kharbanda
>
>
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Wednesday, June 28, 2006 4:17 AM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] Locked Ports
>
>
>
> Hi Pawan
>
> You may have found a deadlock but I've not seen on recently on linux.
>
> If you can, please update from CVS.  This will have some close fixes.
> I'm running with the same code as is in CVS.  It is not perfect but
I've
> not seen anything like you mention.  Be sure to set timeouts and
> thresholds on the port.  It may be that the port is waiting on pending
> io that never happens.  I think the CVS patches deal with this also
but
> it looks like your in a better test environment to know for sure.
>
> The exploded vehicle mentioned below is expected to be fixed today.
It
> was just a ninja small radiator hose.  The pressure test afterwards
> created its own set of problems.  Until this is resolved, I'm spending
> most of my free time commuting by bicycle.
>
> On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:
>
>> Trent,
>>   I have an application running in a cluster in linux environment and
>> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and
>> closes serial comm ports every 30 seconds and exchanges datas. I have
>> experienced some of my Comm Ports are left hanging (I can see the
>> LCK..cufXX lock files under /var/lock folder). On putting the debugs
I
>
>> found out that, it is stuck at a native call line 809 in
RXTXPort.java
>
>> class (Please see the code snippet below). Can you help me explain
>> what this method does in the native code? Am I getting into some
>> thread deadlocks? Thanks in advance.
>>
>> Pawan Kharbanda
>>
>>
>> public void removeEventListener()
>> 	{
>> 		if (debug)
>> 			z.reportln( "RXTXPort:removeEventListener()
> called");
>> 		waitForTheNativeCodeSilly();
>> 		//if( monThread != null && monThread.isAlive() )
>> 		if( monThreadisInterrupted == true )
>> 		{
>> 			z.reportln( "	RXTXPort:removeEventListener()
>> already interrupted");
>> 			monThread = null;
>> 			SPEventListener = null;
>> 			return;
>> 		}
>> 		else if( monThread != null && monThread.isAlive() )
>> 		{
>> 			if (debug)
>> 				z.reportln( "
>> RXTXPort:Interrupt=true");
>> 			monThreadisInterrupted=true;
>> 			/*
>> 			   Notify all threads in this PID that something
> is up
>> 			   They will call back to see if its their
> thread
>> 			   using isInterrupted().
>> 			*/
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> interruptEventLoop");
>> // LINE 809			interruptEventLoop( ); It never returns
>> out of this
>>
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> monThread.join()");
>> 			try {
>> 				monThread.join(1000);
>> 			} catch (Exception ex) {
>> 				/* yikes */
>> 				ex.printStackTrace();
>> 			}
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:waiting on
>> isAlive()");
>> 			while( monThread.isAlive() )
>> 			{
>> 				if ( debug )
>> 					z.reportln( "	MonThread is
>> still alive!");
>> 				try {
>> 					monThread.join(1000);
>> 					Thread.sleep( 1000 );
>> 				} catch( Exception e ){}
>> 				//monThread.stop();
>> 			}
>>
>> 		}
>> 		if (debug)
>> 			z.reportln( "	RXTXPort:calling gc()");
>> 		monThread = null;
>> 		SPEventListener = null;
>> 		MonitorThreadLock = false;
>> 		MonitorThreadAlive=false;
>> 		monThreadisInterrupted=true;
>> 		z.reportln( "RXTXPort:removeEventListener() returning");
>> 	}
>>
>> -----Original Message-----
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On
Behalf
>
>> Of Trent Jarvi
>> Sent: Sunday, June 25, 2006 7:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] Pending release
>>
>>
>> With frustration, I was unable to get to the pending release this
>> weekend.
>> The release should be comming this next week once things calm down.
>> The source is in CVS except for a fix for multiple ports in windows.
>>
>> I had planned on doing the release this weekend but that was
disrupted
>
>> by my transportation failing in a spectacular fashion.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx 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 khattar31 at yahoo.com  Wed Jun 28 22:04:59 2006
From: khattar31 at yahoo.com (rahul khattar)
Date: Wed, 28 Jun 2006 21:04:59 -0700 (PDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
Message-ID: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>

Hi All,

I was looking at the src file on the last release.
I did notice a missing header file while trying to
compile the parallelport.dll. Would somebody be kind
enoughf to share the missing header file:
gnu_io_LPRPort.h

I am using MinGw to compile the same from Parinya
(which is an execellent tool)


Regards,
Rahul Khattar

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Thu Jun 29 03:43:53 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 03:43:53 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>
References: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606290341210.9561@www>

On Wed, 28 Jun 2006, rahul khattar wrote:

> Hi All,
>
> I was looking at the src file on the last release.
> I did notice a missing header file while trying to
> compile the parallelport.dll. Would somebody be kind
> enoughf to share the missing header file:
> gnu_io_LPRPort.h
>
> I am using MinGw to compile the same from Parinya
> (which is an execellent tool)
>

Hi Rahul

The gnu.io_LPRPort.h file is generated with javah.  You can see the 
command in the Makefile I presume.  You do not need rxtxParallel.dll to 
use w32 serial btw.

--
Trent Jarvi
tjarvi at qbang.org


From khattar31 at yahoo.com  Thu Jun 29 04:47:01 2006
From: khattar31 at yahoo.com (rahul khattar)
Date: Thu, 29 Jun 2006 03:47:01 -0700 (PDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606290341210.9561@www>
Message-ID: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>

Hi Trent 
I did notice this file is required in the source file
ParallelImp.c
on line 38

Attached the O/P 

Regards,
Rahul Khattar




--- Trent Jarvi <tjarvi at qbang.org> wrote:

> On Wed, 28 Jun 2006, rahul khattar wrote:
> 
> > Hi All,
> >
> > I was looking at the src file on the last release.
> > I did notice a missing header file while trying to
> > compile the parallelport.dll. Would somebody be
> kind
> > enoughf to share the missing header file:
> > gnu_io_LPRPort.h
> >
> > I am using MinGw to compile the same from Parinya
> > (which is an execellent tool)
> >
> 
> Hi Rahul
> 
> The gnu.io_LPRPort.h file is generated with javah. 
> You can see the 
> command in the Makefile I presume.  You do not need
> rxtxParallel.dll to 
> use w32 serial btw.
> 
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Error.zip
Type: application/x-zip-compressed
Size: 1746 bytes
Desc: 2948039066-Error.zip
Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060629/a5b6f783/Error-0017.bin

From tjarvi at qbang.org  Thu Jun 29 06:16:24 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 06:16:24 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606290614530.9561@www>

On Thu, 29 Jun 2006, rahul khattar wrote:

> Hi Trent
> I did notice this file is required in the source file
> ParallelImp.c
> on line 38
>
> Attached the O/P
>

The command to generate the .h file will be something like:

javah -classpath . -jni gnu.io.LPRPort

The makefile should have this.  There are several approaches to creating 
or using makefiles so I have no idea which one you used if any.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Thu Jun 29 06:20:51 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 06:20:51 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606290616420.9561@www>

> Here is how you can test if you have resources/ test environment. Write
> a program and try to open/close  different ports(I will say have a
> minimum of four) randomly and very frequently(may be 30 seconds), I am
> pretty sure you will see the deadlocks and it happens in the native call
> to interrptEventLoop in RXTXPort.java in removeEventListener() method
> call.

Hi Pawan

I'll try to find a way to reproduce this.  One thing to note is that you 
are using different kernel drivers (digi) to perform this task.  So I 
probably will not be able to reproduce the exact same environment.

In general, multiport kernel drivers have been tested far less than 
typical serial drivers.  This may or may not be an issue.

--
Trent Jarvi
tjarvi at qbang.org



From jhaysonn at gmail.com  Thu Jun 29 12:29:13 2006
From: jhaysonn at gmail.com (jhaysonn pathak)
Date: Thu, 29 Jun 2006 14:29:13 -0400
Subject: [Rxtx] RXTX install
Message-ID: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>

Hi Guys,

I'm doing trying to write a generative piece of Sonic Art using an EEG
plugged into a mac runnning Max/MSP.  I just recently discovered RXTX
drivers in my search for a piece of software that might give me more
output options for my EEG (I'm using the CEO from MindPeak).  I found
Bioera which uses RXTX drivers.  Thing is - I can't figure out how to
install RXTX correctly.

After I build the 'libSerial.jnilib' target inside of
'LibSerial.pbproj' I can't find the libSerial.jnilib file that
accompanies the RXTXcomm.jar nor do I know where to put them.

I also don't understand this part at the bottom of the OS X instructions at all:

"AFTER INSTALLATION VERY IMPORTANT
	check existence of the folder /var/spool/uucp
	if you don't have it create it with command
	sudo mkdir /var/spool/uucp
	permissions should be: drwxrwxr-x
	if they are not do command
	sudo chmod 775 /var/spool/uucp

	YOU should be a member of the uucp group
	you can check it with command
		niutil -readprop / /groups/uucp users
	you should see your name in output of the niutil command
	if you don't do following:
		sudo niutil -appendprop / /groups/uucp users <yourname>
			substitute  <yourname> with your user's name
			for example if your user name is peter:
				sudo niutil -appendprop / /groups/uucp users peter

	NOTES: RXTX.pkg should create uucp folder and insert your name  in
uucp group automatically"



I really appreciate any help that you guys can offer.  I've been
struggling with this for a while now as part of a research grant that
I was awarded.  Thanks again for the help.

Jhaysonn Pathak


From naranjo.manuel at gmail.com  Thu Jun 29 07:19:15 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 10:19:15 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606290614530.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www>
Message-ID: <44A3D353.6010605@gmail.com>

Speaking about Windows Support, I had seen that inside the 
rxtx-2.1-7-bins-r2 package inside Windows directory it says:
"i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will 
not make harm to anyone, and i'm almost sure that someone has noticed it 
before.
Cheers,
Manuel


From joachim at buechse.de  Thu Jun 29 13:25:16 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 29 Jun 2006 21:25:16 +0200
Subject: [Rxtx] RXTX install
In-Reply-To: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>
References: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>
Message-ID: <2A003E42-97E1-4237-8438-646BDE2E3961@buechse.de>

Hello Jhaysonn,

I assume you are trying to use the javax.comm version of RXTX.

Please use "cvs up" to update your download to the latest version of  
the repository. The latest version does not use lock files, so the  
mentioned process is no longer needed. Updating with CVS will also  
provide you with a new README.OSX file that should be simpler to  
understand.

You will find LibSerialUniversal.xcodeproj in MACOSX_IDE/Xcode. Put  
comm.jar (downloaded from Sun) into MACOSX_IDE/Xcode. Compile the  
library. You will find RXTXcomm.jar and librxtxSerial.jnilib in  
MACOSX_IDE/Xcode/build/Default

Best regards,
Joachim
---
Joachim B?chse
Softwarel?sungen und Beratung
Hadlaubsteig 2
CH-8006 Z?rich


On 29.06.2006, at 20:29, jhaysonn pathak wrote:

> Hi Guys,
>
> I'm doing trying to write a generative piece of Sonic Art using an EEG
> plugged into a mac runnning Max/MSP.  I just recently discovered RXTX
> drivers in my search for a piece of software that might give me more
> output options for my EEG (I'm using the CEO from MindPeak).  I found
> Bioera which uses RXTX drivers.  Thing is - I can't figure out how to
> install RXTX correctly.
>
> After I build the 'libSerial.jnilib' target inside of
> 'LibSerial.pbproj' I can't find the libSerial.jnilib file that
> accompanies the RXTXcomm.jar nor do I know where to put them.
>
> I also don't understand this part at the bottom of the OS X  
> instructions at all:
>
> "AFTER INSTALLATION VERY IMPORTANT
> 	check existence of the folder /var/spool/uucp
> 	if you don't have it create it with command
> 	sudo mkdir /var/spool/uucp
> 	permissions should be: drwxrwxr-x
> 	if they are not do command
> 	sudo chmod 775 /var/spool/uucp
>
> 	YOU should be a member of the uucp group
> 	you can check it with command
> 		niutil -readprop / /groups/uucp users
> 	you should see your name in output of the niutil command
> 	if you don't do following:
> 		sudo niutil -appendprop / /groups/uucp users <yourname>
> 			substitute  <yourname> with your user's name
> 			for example if your user name is peter:
> 				sudo niutil -appendprop / /groups/uucp users peter
>
> 	NOTES: RXTX.pkg should create uucp folder and insert your name  in
> uucp group automatically"
>
>
>
> I really appreciate any help that you guys can offer.  I've been
> struggling with this for a while now as part of a research grant that
> I was awarded.  Thanks again for the help.
>
> Jhaysonn Pathak
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From tjarvi at qbang.org  Thu Jun 29 19:30:00 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 19:30:00 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A3D353.6010605@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
Message-ID: <Pine.LNX.4.61.0606291923000.9561@www>

On Thu, 29 Jun 2006, Manuel Naranjo wrote:

> Speaking about Windows Support, I had seen that inside the
> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
> not make harm to anyone, and i'm almost sure that someone has noticed it
> before.

Hi Manuel

         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
     47421  01-30-06 00:23 
rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
     77759  03-01-06 12:01 
rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README


It looks normal to me.  There are no fancy tools used there :)

--
Trent Jarvi
tjarvi at qbang.org

From naranjo.manuel at gmail.com  Thu Jun 29 19:38:16 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 22:38:16 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606291923000.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com> <Pine.LNX.4.61.0606291923000.9561@www>
Message-ID: <44A48088.2040407@gmail.com>

> On Thu, 29 Jun 2006, Manuel Naranjo wrote:
> 
>> Speaking about Windows Support, I had seen that inside the
>> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
>> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
>> not make harm to anyone, and i'm almost sure that someone has noticed it
>> before.
> 
> Hi Manuel
> 
>         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
>         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
>     47421  01-30-06 00:23 
> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
>     77759  03-01-06 12:01 
> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
>       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README
> 
> 
> It looks normal to me.  There are no fancy tools used there :)
> 
Hi Trent:
Is not the i368 representing the name of the Architecture?? If so the 
name should start with i386 it will not break any system, is simply miss
written, I saw that and wanted to report it. It a silly thing.
Ohh I forgoten I must congratulate you for your GREAT libray, I was able 
to make an .exe with JSmooth that launches an application that uses RXTX 
with out the need to install RXTX on users system :). The .exe tells JVM 
where to find the RXTX Library and Binaries. I tried with Sun's Java 
Comm but it was imposible.
Regards,
Manuel


From tjarvi at qbang.org  Thu Jun 29 19:52:45 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 19:52:45 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A48088.2040407@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
	<Pine.LNX.4.61.0606291923000.9561@www> <44A48088.2040407@gmail.com>
Message-ID: <Pine.LNX.4.61.0606291945060.9561@www>

On Thu, 29 Jun 2006, Manuel Naranjo wrote:

>> On Thu, 29 Jun 2006, Manuel Naranjo wrote:
>>
>>> Speaking about Windows Support, I had seen that inside the
>>> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
>>> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
>>> not make harm to anyone, and i'm almost sure that someone has noticed it
>>> before.
>>
>> Hi Manuel
>>
>>         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
>>         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
>>     47421  01-30-06 00:23
>> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
>>     77759  03-01-06 12:01
>> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
>>       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README
>>
>>
>> It looks normal to me.  There are no fancy tools used there :)
>>
> Hi Trent:
> Is not the i368 representing the name of the Architecture?? If so the
> name should start with i386 it will not break any system, is simply miss
> written, I saw that and wanted to report it. It a silly thing.
> Ohh I forgoten I must congratulate you for your GREAT libray, I was able
> to make an .exe with JSmooth that launches an application that uses RXTX
> with out the need to install RXTX on users system :). The .exe tells JVM
> where to find the RXTX Library and Binaries. I tried with Sun's Java
> Comm but it was imposible.

Hi Manuel

The compiler uses only the i386 instruction set for windows.  I doubt 
there will be any measurable advantages with going to later instruction 
sets.  In theory rxtx would run on a 386 but I doubt anyone does that.

So it looks odd but is not a typo.

We could compile to i686 but don't.  The compiler used does not appear to 
be a problem yet so I don't see any point in changing it.  Right now, we 
could not compile 64 bit windows binaries.  gcc/mingw/... do not support 
them that I know of.  People will have to compile those with closed source 
tools on their own until an option is available.

--
Trent Jarvi
tjarvi at qbang.org

From naranjo.manuel at gmail.com  Thu Jun 29 20:00:48 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 23:00:48 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606291945060.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com>	<Pine.LNX.4.61.0606291923000.9561@www>
	<44A48088.2040407@gmail.com> <Pine.LNX.4.61.0606291945060.9561@www>
Message-ID: <44A485D0.7050202@gmail.com>

Trent you did not get my point
The folder says 368 three hundred sixty eight, when
it should say 386 three hundred eighty six. Is simply a miss writting.
Regards,
Manuel


From tjarvi at qbang.org  Thu Jun 29 20:12:15 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 20:12:15 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A485D0.7050202@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
	<Pine.LNX.4.61.0606291923000.9561@www> <44A48088.2040407@gmail.com>
	<Pine.LNX.4.61.0606291945060.9561@www> <44A485D0.7050202@gmail.com>
Message-ID: <Pine.LNX.4.61.0606292008061.9561@www>


On Thu, 29 Jun 2006, Manuel Naranjo wrote:

> Trent you did not get my point
> The folder says 368 three hundred sixty eight, when
> it should say 386 three hundred eighty six. Is simply a miss writting.

hehe..  OK.  My bad.  It's been a long day.

Nevermind :)

--
Trent Jarvi
tjarvi at qbang.org




From naranjo.manuel at gmail.com  Thu Jun 29 20:18:44 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 23:18:44 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606292008061.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com>	<Pine.LNX.4.61.0606291923000.9561@www>
	<44A48088.2040407@gmail.com>	<Pine.LNX.4.61.0606291945060.9561@www>
	<44A485D0.7050202@gmail.com> <Pine.LNX.4.61.0606292008061.9561@www>
Message-ID: <44A48A04.9040401@gmail.com>

Don't worry Trent.
About 64 bits compilation, I would like to colaborate, I have a Pc with 
64 bits, the only problem is that i do not have windows 64 bits 
installed :(.




From Pawan.Kharbanda at dot.state.co.us  Fri Jun 30 08:49:52 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 30 Jun 2006 08:49:52 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E996@hqexchange3.dot.state.co.us>

Trent,  
    Can you explain what the interruptedEventLoop() native method is
doing is there a possibility that method is somehow getting into the
infinite loop(there are 2 while loops without any break statements).
This might be a very basic question how can I debug the native code(or
print the debug statements).  Again thanks for the help. 

Pawan Kharbanda

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Thursday, June 29, 2006 6:21 AM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports

> Here is how you can test if you have resources/ test environment. 
> Write a program and try to open/close  different ports(I will say have

> a minimum of four) randomly and very frequently(may be 30 seconds), I 
> am pretty sure you will see the deadlocks and it happens in the native

> call to interrptEventLoop in RXTXPort.java in removeEventListener() 
> method call.

Hi Pawan

I'll try to find a way to reproduce this.  One thing to note is that you
are using different kernel drivers (digi) to perform this task.  So I
probably will not be able to reproduce the exact same environment.

In general, multiport kernel drivers have been tested far less than
typical serial drivers.  This may or may not be an issue.

--
Trent Jarvi
tjarvi at qbang.org

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From cpine at wrsystems.com  Thu Jun 29 15:17:12 2006
From: cpine at wrsystems.com (Chris Pine)
Date: Thu, 29 Jun 2006 17:17:12 -0400
Subject: [Rxtx]  Controlling Individual Signals DTR and RTS
Message-ID: <MAIL4FJo0S8ACLEBajJ000005cf@mail4.wrsystems.com>

Dear Moussa Ba,
	I hope I am not being too forward, but we are having the exact same
issue with needing to control DTR from RXTX in Linux.  Did you ever have any
luck figuring it out?

Thank you very much for your time,

Chris Pine




From tjarvi at qbang.org  Thu Jun  1 11:13:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 11:13:40 -0600 (MDT)
Subject: [Rxtx] custom baud rate win32
In-Reply-To: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606011107210.30220@www>


Hi Daren

I can't imagine that 1953 is possibly the actual value on the UART.  Maybe 
if your baud base is very high with a custom serial board.  More likely, 
the driver just remembers that what you asked for and did something else.

I'll have more to say on the dcb->BaudRate after I try some things here. 
I have managed to do something like that in the past as a quick hack but 
it was for 14400.  I may have used the CBR_14400.

If we can't access this through the win32 API with protected mode, there 
is another layer of complication.  With real mode, it would be easy.
With protected mode, I assume there would have to be some kernel driver or 
a hook I'm not aware of to access the MCR directly (bang a memory 
addresss).



On Thu, 1 Jun 2006, Daren wrote:

> Trent,
> I have managed to successfully open the port at this speed using Realterm
> (available on sourceforge). From memory this uses DLPortIO.
>
> Using portmon.exe with realterm, even there it says that the port has opened
> at 1953.
>
> I changed termios.c:560 to
> dcb->BaudRate        = 1953 ;
>
> and it still opens the port at 9600.
>
> Daren
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Trent Jarvi
> Sent: Thursday, 1 June 2006 1:44 PM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] custom baud rate win32
>
> On Thu, 1 Jun 2006, Daren wrote:
>
>> Hi all,
>>
>> I downloaded 2.1.7-pre16 and managed to build it and get it going. I made
>> the changes as suggested by Peter Smith in an old post, by adding his code
>> to SerialImpl.c, uncommenting the TIOCGSERIAL and TIOCSSERIAL, and
> defining
>> ASYNC_SPD_CUST which is equal to 0x0030 (according to linus header
> files)..
>>
>>
>> Still not working, it opens the port at 9600 according to portmon.exe .
> Has
>> anyone managed to get this going at a custom rate?
>>
>> Here is the post I'm referring to:
>> http://marc.theaimsgroup.com/?l=rxtx&m=106270038110713&w=2
>>
>>
>> Thanks,
>> Daren
>>
>> ________________________________________
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
>> Daren
>> Sent: Wednesday, 31 May 2006 10:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] (no subject)
>>
>> Hi All,
>> I have been using rxtx for a little while and needed to get it working at
>> 1953, like a past user in the mailing list, who seemed to have got it
>> working by changing some C code.
>>
>> I wanted to build rxtx myself with these changes but don't know where to
>> start. I have windows here and FC4 at home. I downloaded cygwin and
> mingw32,
>> each build works by building a rxtxSerial.dll file that is ~11k smaller
> than
>> the original, and I always get the following error when testing the dll:
>>
>> Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at
>> PC=0x8077655
>> Function=[Unknown.]
>> Library=C:\opt\java\j2sdk1.4.2\jre\bin\client\jvm.dll
>>
>> NOTE: We are unable to locate the function name symbol for the error
>>      just occurred. Please refer to release documentation for possible
>>      reason and solutions.
>>
>>
>> Current Java thread:
>> 	at gnu.io.RXTXPort.open(Native Method)
>> 	- locked <0x1002c800> (a gnu.io.RXTXPort)
>> 	at gnu.io.RXTXPort.<init>(RXTXPort.java:84)
>>
>> Anyone know what im doing wrong?
>>
>>
>>
>>
>
> Hi Daren
>
> You are running into the same rats nest I'm looking at now.
>
> With win32 and specific custom baud rates, I'm not sure how this will go.
> I've got the Linux custom baud rates working very nicely.  I did much like
> the post you linked.  In fact I had forgot about that post.  You probably
> noticed that it becomes a bunch of dirt roads going noplace fast in
> termios.c for w32.
>
> I'm probably only going to get 14400, 28800, 128000 and 256000 working
> with the next release on w32.  I'll look a little further.  If you have an
> example w32 that works at 1953 I'd really like to hear.  Thats an unusual
> baud rate.
>
> Assuming a baud_base of 128000, your divisor will be 65 or 66.
>
> 128000/66=1939 -14
> 128000/65=1969 +13
>
> One thing I've been wondering about with linux is which would be the right
> answer in cases like this.  Right now it would just go with a baud base of
> 65 and ignore the modulus details.
>
> It appears to be a general trend for kernel developers to hide these
> details thinking that they can come up with a general solution.  Then they
> run out of time.  Perahps the solution is to help out but there are
> ultiple OS's rxtx supports making that nontrivial.
>
> If you look at current linux kernels, the 'tricks' above have been marked
> deprecated with no replacement.  Windows has some hard defines and then
> ancient near magic.  I've not looked at Solaris via Open Solaris yet but
> doubt there is a solution at all.
>
> What I'd try since you have the equipment and the monitor software is to
> hardcode the dcb->Baud in termios.c to 1953 (no define) and see what the
> w32 kernel does with it.  I think if you toss a baud rate at the driver it
> will try to come close.  You may try comming closer to a real baudrate
> based upon the 128000 baud base as shown above.
>
> If it works, it is worth looking at the rest of the ping/pong logic then.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
>
>
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From doug at dupreeinc.com  Thu Jun  1 13:22:13 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 12:22:13 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011107210.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
Message-ID: <447F3E65.1020809@dupreeinc.com>

Hello,

I am still trying to get this startup a little faster so I turned on the 
debug of a few of the classes.  The COM ports are scanned really fast 
and the delay occurs during the LPT scan.  The console output looks like 
this:

    ...
      LPT1
      LPT2
      LPT3
     valid port prefixes:
      LPT
    LPT1 LPT
    1 1
    LPT2 LPT
    2 2                                                                 
      * <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
    CommPortIdentifier:addPortName(LPT2)
    CommPortIdentifier:AddIdentifierToList()
    LPT3 LPT
    3 3
    CommPortIdentifier:addPortName(LPT3)
    CommPortIdentifier:AddIdentifierToList()
    CommPortIdentifier:AddIdentifierToList() index.next
    Leaving registerValidPorts()
    Have not implemented native_psmisc_report_owner(PortName)); in
    CommPortIdentifier
    CommPortIdentifier:getPortIdentifier(COM3)
    CommPortIdentifier:open(densConnect, 30000)
    RXTXCommDriver:getCommPort(COM3,1)
    ...

It would seem to me that if I removed the code for port scanning of LPT 
ports I could solve this problem. I would much prefer to use unmodified 
code if at all possible.  Do any of you have alternate suggestions?

Thank you for your time.

Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/cf433ee7/attachment-0018.html

From tjarvi at qbang.org  Thu Jun  1 13:52:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 13:52:06 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F3E65.1020809@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011348380.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I am still trying to get this startup a little faster so I turned on the 
> debug of a few of the classes.  The COM ports are scanned really fast and the 
> delay occurs during the LPT scan.  The console output looks like this:
>
>   ...
>     LPT1
>     LPT2
>     LPT3
>    valid port prefixes:
>     LPT
>   LPT1 LPT
>   1 1
>   LPT2 LPT
>   2 2                                                                      * 
> <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>   CommPortIdentifier:addPortName(LPT2)
>   CommPortIdentifier:AddIdentifierToList()
>   LPT3 LPT
>   3 3
>   CommPortIdentifier:addPortName(LPT3)
>   CommPortIdentifier:AddIdentifierToList()
>   CommPortIdentifier:AddIdentifierToList() index.next
>   Leaving registerValidPorts()
>   Have not implemented native_psmisc_report_owner(PortName)); in
>   CommPortIdentifier
>   CommPortIdentifier:getPortIdentifier(COM3)
>   CommPortIdentifier:open(densConnect, 30000)
>   RXTXCommDriver:getCommPort(COM3,1)
>   ...
>
> It would seem to me that if I removed the code for port scanning of LPT ports 
> I could solve this problem. I would much prefer to use unmodified code if at 
> all possible.  Do any of you have alternate suggestions?
>
> Thank you for your time.
>
> Doug
>


Does commenting out the LPT enumeration actually help?  There can often be 
differences between debug information printed and whats really going on. 
When you combine various environments the debug info can even come out in 
the wrong order.

I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
I do not think this problem is universal.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Thu Jun  1 14:29:44 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:29:44 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4E38.2060004@dupreeinc.com>

I will give it a try.  One thing to note on this PC is it has no LPT 
Parallel ports.

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
>>Hello,
>>
>>I am still trying to get this startup a little faster so I turned on the 
>>debug of a few of the classes.  The COM ports are scanned really fast and the 
>>delay occurs during the LPT scan.  The console output looks like this:
>>
>>  ...
>>    LPT1
>>    LPT2
>>    LPT3
>>   valid port prefixes:
>>    LPT
>>  LPT1 LPT
>>  1 1
>>  LPT2 LPT
>>  2 2                                                                      * 
>><<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>>  CommPortIdentifier:addPortName(LPT2)
>>  CommPortIdentifier:AddIdentifierToList()
>>  LPT3 LPT
>>  3 3
>>  CommPortIdentifier:addPortName(LPT3)
>>  CommPortIdentifier:AddIdentifierToList()
>>  CommPortIdentifier:AddIdentifierToList() index.next
>>  Leaving registerValidPorts()
>>  Have not implemented native_psmisc_report_owner(PortName)); in
>>  CommPortIdentifier
>>  CommPortIdentifier:getPortIdentifier(COM3)
>>  CommPortIdentifier:open(densConnect, 30000)
>>  RXTXCommDriver:getCommPort(COM3,1)
>>  ...
>>
>>It would seem to me that if I removed the code for port scanning of LPT ports 
>>I could solve this problem. I would much prefer to use unmodified code if at 
>>all possible.  Do any of you have alternate suggestions?
>>
>>Thank you for your time.
>>
>>Doug
>>
>>    
>>
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/dd31fed5/attachment-0018.html

From doug at dupreeinc.com  Thu Jun  1 14:36:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:36:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4FC8.9080106@dupreeinc.com>

Trent,

I commented out the section in RegisterScannedPorts() that adds the 
three LPT ports to the CandidateDeviceNames string array.  The 
application started immediately.  This is probably not the way to do 
this, but it was quick ,dirty, and worked.

It would be nice if there was a way to pole the OS to see if there is 
even a port there, though I guess this is what this code is suppose to do...

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
> ...
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From lynn at swcp.com  Thu Jun  1 14:49:34 2006
From: lynn at swcp.com (lynn@swcp.com)
Date: Thu, 1 Jun 2006 20:49:34 -0000
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>,
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <twig.1149194974.97617@swcp.com>

Perhaps we could add an argument to port enumeration where if not specified,
you get the default behavior that looks for everything.  With a new
constructor that has an argument(or more) you could optionally declare it to
not inspect printer ports.

Existing code would work as it always has.  New code could be smarter.

Lynn



Doug Thistlethwaite <doug at dupreeinc.com> said:

> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
> >On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
> >
> >  
> >
> > ...
> >
> >
> >Does commenting out the LPT enumeration actually help?  There can often be 
> >differences between debug information printed and whats really going on. 
> >When you combine various environments the debug info can even come out in 
> >the wrong order.
> >
> >I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
> >I do not think this problem is universal.
> >
> >--
> >Trent Jarvi
> >tjarvi at qbang.org
> >_______________________________________________
> >Rxtx mailing list
> >Rxtx at qbang.org
> >http://mailman.qbang.org/mailman/listinfo/rxtx
> >
> >
> >  
> >
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



-- 





From jredman at ergotech.com  Thu Jun  1 15:20:20 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 01 Jun 2006 15:20:20 -0600
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
Message-ID: <447F5A14.6010803@ergotech.com>

Doug,

If you specifically request ports, eg:

-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

or
 
-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

Depending upon the version  (Windows is COM1:COM2, etc. I assume).

Does it still enumerate the parallel ports?

Jim

Doug Thistlethwaite wrote:
> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
>> On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>
>>  
>>
>> ...
>>
>>
>> Does commenting out the LPT enumeration actually help?  There can often be 
>> differences between debug information printed and whats really going on. 
>> When you combine various environments the debug info can even come out in 
>> the wrong order.
>>
>> I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>> I do not think this problem is universal.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>>
>>  
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  1 16:49:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:49:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6EF4.7080709@dupreeinc.com>

I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
folder.  I created this file and added the following to the file:

gnu.io.rxtx.SerialPorts=COM3

and I get the following error on the console:
CommPortIdentifier:static initialization()
RXTXCommDriver {}
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
RXTXCommDriver:
    Jar version = RXTX-2.1-7
    native lib Version = RXTX-2.1-7
RXTXCommDriver:initialize()
checking for system-known ports of type 1
checking registry for ports of type 1

RXTXCommDriver:addSpecifiedPorts()
Exception in thread "main" java.lang.ExceptionInInitializerError
    at 
densconnect.SerialConnection.openConnection(SerialConnection.java:136)
    at densconnect.DensTalk.<init>(DensTalk.java:165)
    at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
    at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
    at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
    at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
Caused by: java.lang.NullPointerException
    at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
CommPortIdentifier:addPortName(COM3)
CommPortIdentifier:AddIdentifierToList()
CommPortIdentifier:AddIdentifierToList() null
...


It looks like it  read COM3 from the file, but it had the above 
exception that killed it.  The strange this is this error is from 
RXTXCommDriver initialize function (if statement line):

        OS = System.getProperty("os.name");
                System.out.println("OS NAME: " + OS);
        if(OS.toLowerCase().indexOf("linux") == -1)

OS is returning null, thus the error.

If the file is not present, it scans the ports and reads the OS.

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>Doug Thistlethwaite wrote:
>  
>
>>Trent,
>>
>>I commented out the section in RegisterScannedPorts() that adds the 
>>three LPT ports to the CandidateDeviceNames string array.  The 
>>application started immediately.  This is probably not the way to do 
>>this, but it was quick ,dirty, and worked.
>>
>>It would be nice if there was a way to pole the OS to see if there is 
>>even a port there, though I guess this is what this code is suppose to do...
>>
>>Doug
>>
>>Trent Jarvi wrote:
>>
>>    
>>
>>>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>>
>>> 
>>>
>>>...
>>>
>>>
>>>Does commenting out the LPT enumeration actually help?  There can often be 
>>>differences between debug information printed and whats really going on. 
>>>When you combine various environments the debug info can even come out in 
>>>the wrong order.
>>>
>>>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>>>I do not think this problem is universal.
>>>
>>>--
>>>Trent Jarvi
>>>tjarvi at qbang.org
>>>_______________________________________________
>>>Rxtx mailing list
>>>Rxtx at qbang.org
>>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>>
>>>
>>> 
>>>
>>>      
>>>
>>_______________________________________________
>>Rxtx mailing list
>>Rxtx at qbang.org
>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>    
>>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/bf4cca0e/attachment-0018.html

From doug at dupreeinc.com  Thu Jun  1 16:51:26 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:51:26 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6F6E.5060603@dupreeinc.com>

Jim,

I did not try your suggestion as I do not understand where I would put 
these command line parameters (it that is what they are).  It appears 
that using the properties file should do that same thing...

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>
>  
>


From doug at dupreeinc.com  Thu Jun  1 17:56:19 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 16:56:19 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
Message-ID: <447F7EA3.6050400@dupreeinc.com>

I think there is an error in the registerSpecifiedPorts() method.  When 
I have a gnu.io.rxtx.properties file in the ext directory, this function 
kills the System class  IF I call System.getProperty("os.name") before 
the call  to registerSpecifiedPorts(), it returns the os name, after the 
call, it returns null.  I have not played much with properties, except 
for reading them, so I don't really understand the code.

Doug



From doug at dupreeinc.com  Thu Jun  1 18:11:14 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 17:11:14 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F7EA3.6050400@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com>
Message-ID: <447F8222.3060402@dupreeinc.com>

Ok, I just hacked this thing up and got it to read the 
gnu.io.rxtx.properties file.

I commented out the line:
System.setProperties(p); in the method registerSpecifiedPorts() in 
RXTXCommDriver class.  I really don't understand that much about 
properties, but this call kills the System class.

I used the following in the gnu.io.rxtx.properties file:

gnu.io.rxtx.SerialPorts=COM3
gnu.io.rxtx.ParallelPorts=null

This allows the application to open very quickly without any errors.  
Whomever coded this class or somebody who understands properties should 
look at this method and make sure it is doing what they expect.

Doug




Doug Thistlethwaite wrote:

>I think there is an error in the registerSpecifiedPorts() method.  When 
>I have a gnu.io.rxtx.properties file in the ext directory, this function 
>kills the System class  IF I call System.getProperty("os.name") before 
>the call  to registerSpecifiedPorts(), it returns the os name, after the 
>call, it returns null.  I have not played much with properties, except 
>for reading them, so I don't really understand the code.
>
>Doug
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From tjarvi at qbang.org  Thu Jun  1 18:32:50 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 18:32:50 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F6EF4.7080709@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com> <447F6EF4.7080709@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011831510.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
> folder.  I created this file and added the following to the file:
>
> gnu.io.rxtx.SerialPorts=COM3
>
> and I get the following error on the console:
> CommPortIdentifier:static initialization()
> RXTXCommDriver {}
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
> RXTXCommDriver:
>   Jar version = RXTX-2.1-7
>   native lib Version = RXTX-2.1-7
> RXTXCommDriver:initialize()
> checking for system-known ports of type 1
> checking registry for ports of type 1
>
> RXTXCommDriver:addSpecifiedPorts()
> Exception in thread "main" java.lang.ExceptionInInitializerError
>   at densconnect.SerialConnection.openConnection(SerialConnection.java:136)
>   at densconnect.DensTalk.<init>(DensTalk.java:165)
>   at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
>   at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
>   at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
>   at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
> Caused by: java.lang.NullPointerException
>   at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
> CommPortIdentifier:addPortName(COM3)
> CommPortIdentifier:AddIdentifierToList()
> CommPortIdentifier:AddIdentifierToList() null
> ...
>
>

There is a solution for this bug.

http://bugzilla.qbang.org/show_bug.cgi?id=54

We have been horribly slow at getting the next round of patches in but 
they are comming.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  2 00:58:02 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 08:58:02 +0200
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F8222.3060402@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
Message-ID: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>

Hi Doug,

you wrote in an earlier message, that you would prefer an unchanged  
version. What about simply removing the RXTX parallel lib from the  
ext directory. This does not fix the bug, but it should fix your  
problem.

In general I think it is not a good idea to put the RXTX files in a  
system wide location. Putting the libs in the application folder and  
including the .jar in the application classpath (or application jar)  
is all that is required.

Regards,
Joachim

On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:

> Ok, I just hacked this thing up and got it to read the
> gnu.io.rxtx.properties file.
>
> I commented out the line:
> System.setProperties(p); in the method registerSpecifiedPorts() in
> RXTXCommDriver class.  I really don't understand that much about
> properties, but this call kills the System class.
>
> I used the following in the gnu.io.rxtx.properties file:
>
> gnu.io.rxtx.SerialPorts=COM3
> gnu.io.rxtx.ParallelPorts=null
>
> This allows the application to open very quickly without any errors.
> Whomever coded this class or somebody who understands properties  
> should
> look at this method and make sure it is doing what they expect.
>
> Doug
>
>
>
>
> Doug Thistlethwaite wrote:
>
>> I think there is an error in the registerSpecifiedPorts() method.   
>> When
>> I have a gnu.io.rxtx.properties file in the ext directory, this  
>> function
>> kills the System class  IF I call System.getProperty("os.name")  
>> before
>> the call  to registerSpecifiedPorts(), it returns the os name,  
>> after the
>> call, it returns null.  I have not played much with properties,  
>> except
>> for reading them, so I don't really understand the code.
>>
>> 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 antonio.luis at iscte.pt  Fri Jun  2 02:42:28 2006
From: antonio.luis at iscte.pt (=?ISO-8859-1?Q?Ant=F3nio_Lopes?=)
Date: Fri, 02 Jun 2006 09:42:28 +0100
Subject: [Rxtx] Exception when closing serial port
Message-ID: <447FF9F4.7060209@iscte.pt>

Hello everyone,
I've been using RXTX in a Java application in my Pocket PC.
The communication through the (bluetooth) serial port is working perfectly.

However, when I disconnect the app and close the serial port, sometimes I get 
the following error:

"1149237595000: RXTXPort:close detected bad File Descriptor"

The problem is that after this error occurs, the app is no longer able to 
connect to the serial port and I have to soft-reset the device in order to be 
able to connect to it again.

Any ideas on how to solve this issue?

Any help is appreciated.
Thanks,
regards,
-- 
Ant?nio Lopes

@contact: antonio.luis at iscte.pt
@work: ADETTI - ISCTE
@web: http://antonio.lopes.googlepages.com


From paul.klissner at sun.com  Fri Jun  2 02:44:34 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 01:44:34 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to RXTX
	again
Message-ID: <447FFA72.6040807@sun.com>

After looking into javax.comm 3.1 and what it would take to re-engineer it
to be compatible with RXTX platform libraries, I've decided, due my group's
priorities, complexity of the effort vs. benefit, and limited resources, 
to re-post
javax.comm 2.0 binaries on Sun's software download server, unsupported,
with disclaimers, as it was previously.

I don't think there will be any snags doing this from the standpoint of Sun
management or legality.  I will try to have it  posted there in the next 
week
or two, depending on how fast we can get it pushed through the process.

I'd like to think of this as a stop gap measure... ie. a compromise, 
where, at some
point in the not too distant future RXTX implements their own version of the
Java side of the API, as is normally done by javax.extension porters. 
That way
we avoid uncomfortable dependencies in the future.  And that really is 
the Java
development model.

Since RXTX already has the back-end code, porting the java code shouldn't
be a gargantuan effort at all, and RXTX will be in full control of the 
code top
to bottom. I think RXTX can do at least as good a job as the original 
coder.
Prepping 2.0 to be open sourced is more trouble than it is worth. ie. I 
don't
think the current implementation warrants it.

Ultimately, it would be nice to see someone open up a JSR and re-architect
the comm. API to overcome some of it's current design flaws (ie. be more
adaptable to modern platforms, more pluggable, better defined SPI, better
port ownership handling, etc...). A superior architecture would allow for
better collaboration in the future and better interchangeability of 
components
among projects.

Sun's 3.1 version of javax.comm, which is Sun's currently supported version,
has changes pertaining mostly to Sun platform-specific portmapping and has
some minor additional interactions with our back end code, but generally
has little bearing on RXTX. 

Paul



From joachim at buechse.de  Fri Jun  2 04:00:19 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 12:00:19 +0200
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
	RXTX again
In-Reply-To: <447FFA72.6040807@sun.com>
References: <447FFA72.6040807@sun.com>
Message-ID: <1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>

Good day Paul!

A clean architecture with loadable drivers and reusable code would be  
very beneficial for the future, I think everybody agrees. However  
this could be several years into the future. In the meantime, there  
is a real existing problem with IO support on Java. I have the strong  
feeling that most programmers want to code against one specification  
(javax.comm) and be able to replace the underlying implementation via  
a "plugin" on platforms where the SUN implementation is not  
sufficient. RXTX could be just this plugin (reusing very close to 0%  
of the javax.comm implementation but 100% of its API).

I want to propose an API addition and implementation change that will  
take less then 2 hours of manpower to implement and create a solution  
that can bridge the years until javax.comm has been based on a new  
architecture.

Looking at the javax.comm api at http://java.sun.com/products/ 
javacomm/reference/api/index.html I would like to propose the following:

The only entry point to javax.comm is CommPortIdentifier. It has 3  
static methods plus the constructor.

1) define one additional Interface

public interface CommProvider {
    CommPortIdentifier getPortIdentifier(CommPort port);
    CommPortIdentifier getPortIdentifier(String portName);
    Enumeration getPortIdentifiers ();
}

2) add one method to CommPortIdentifier

   public static setCustomCommProvider (CommProvider);

3) change the three static methods of CommPortIdentifier to dispatch  
to the CommProvider if it is set

4) change the constructor of CommPortIdentifier to

   public CommPortIdentifier(...) {
      if (isProviderSet && this.getClass() ==  
javax.comm.CommPortIdentifier) {
          throw new RuntimeException("illegal creation of  
CommPortIndentifier, custom CommProvider is in use");
      }

5) (this is optional, but would be very nice) automatically set a  
custom CommProvider if it is found on the classpath or defined via a  
system property.


The above 1) - 4) can be implemented in less than 1hour. 5) may take  
another hour. I agree that this is not the most elegant design, but  
it would solve a lot of problems with very little effort. It would  
certainly allow RXTX to move forward. If the javax.comm API needs to  
be redesigned completely this addition will not hurt, as people will  
move to the new API anyway and javax.comm 3.0 was so far never  
included in the main distribution.

Best regards,
Joachim

On 02.06.2006, at 10:44, Paul Klissner wrote:

> After looking into javax.comm 3.1 and what it would take to re- 
> engineer it
> to be compatible with RXTX platform libraries, I've decided, due my  
> group's
> priorities, complexity of the effort vs. benefit, and limited  
> resources,
> to re-post
> javax.comm 2.0 binaries on Sun's software download server,  
> unsupported,
> with disclaimers, as it was previously.
>
> I don't think there will be any snags doing this from the  
> standpoint of Sun
> management or legality.  I will try to have it  posted there in the  
> next
> week
> or two, depending on how fast we can get it pushed through the  
> process.
>
> I'd like to think of this as a stop gap measure... ie. a compromise,
> where, at some
> point in the not too distant future RXTX implements their own  
> version of the
> Java side of the API, as is normally done by javax.extension porters.
> That way
> we avoid uncomfortable dependencies in the future.  And that really is
> the Java
> development model.
>
> Since RXTX already has the back-end code, porting the java code  
> shouldn't
> be a gargantuan effort at all, and RXTX will be in full control of the
> code top
> to bottom. I think RXTX can do at least as good a job as the original
> coder.
> Prepping 2.0 to be open sourced is more trouble than it is worth.  
> ie. I
> don't
> think the current implementation warrants it.
>
> Ultimately, it would be nice to see someone open up a JSR and re- 
> architect
> the comm. API to overcome some of it's current design flaws (ie. be  
> more
> adaptable to modern platforms, more pluggable, better defined SPI,  
> better
> port ownership handling, etc...). A superior architecture would  
> allow for
> better collaboration in the future and better interchangeability of
> components
> among projects.
>
> Sun's 3.1 version of javax.comm, which is Sun's currently supported  
> version,
> has changes pertaining mostly to Sun platform-specific portmapping  
> and has
> some minor additional interactions with our back end code, but  
> generally
> has little bearing on RXTX.
>
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Fri Jun  2 09:10:13 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Fri, 2 Jun 2006 09:10:13 -0600 (MDT)
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <447FFA72.6040807@sun.com>
References: <447FFA72.6040807@sun.com>
Message-ID: <Pine.LNX.4.61.0606020906400.15971@www>

On Fri, 2 Jun 2006, Paul Klissner wrote:

> After looking into javax.comm 3.1 and what it would take to re-engineer it
> to be compatible with RXTX platform libraries, I've decided, due my group's
> priorities, complexity of the effort vs. benefit, and limited resources,
> to re-post
> javax.comm 2.0 binaries on Sun's software download server, unsupported,
> with disclaimers, as it was previously.
>

Hi Paul

To address users' immediate needs, we can release rxtx 2.0-7 (final) to 
match the 2.0 binaries from Sun when they are offered for download.

We can discuss potential long term solutions after that.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Fri Jun  2 10:20:09 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 02 Jun 2006 09:20:09 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
	<9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
Message-ID: <44806539.8080902@dupreeinc.com>

Thanks for the suggestion, I will give it a try.

Doug

Joachim Buechse wrote:

>Hi Doug,
>
>you wrote in an earlier message, that you would prefer an unchanged  
>version. What about simply removing the RXTX parallel lib from the  
>ext directory. This does not fix the bug, but it should fix your  
>problem.
>
>In general I think it is not a good idea to put the RXTX files in a  
>system wide location. Putting the libs in the application folder and  
>including the .jar in the application classpath (or application jar)  
>is all that is required.
>
>Regards,
>Joachim
>
>On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:
>
>  
>
>>Ok, I just hacked this thing up and got it to read the
>>gnu.io.rxtx.properties file.
>>
>>I commented out the line:
>>System.setProperties(p); in the method registerSpecifiedPorts() in
>>RXTXCommDriver class.  I really don't understand that much about
>>properties, but this call kills the System class.
>>
>>I used the following in the gnu.io.rxtx.properties file:
>>
>>gnu.io.rxtx.SerialPorts=COM3
>>gnu.io.rxtx.ParallelPorts=null
>>
>>This allows the application to open very quickly without any errors.
>>Whomever coded this class or somebody who understands properties  
>>should
>>look at this method and make sure it is doing what they expect.
>>
>>Doug
>>
>>
>>
>>
>>Doug Thistlethwaite wrote:
>>
>>    
>>
>>>I think there is an error in the registerSpecifiedPorts() method.   
>>>When
>>>I have a gnu.io.rxtx.properties file in the ext directory, this  
>>>function
>>>kills the System class  IF I call System.getProperty("os.name")  
>>>before
>>>the call  to registerSpecifiedPorts(), it returns the os name,  
>>>after the
>>>call, it returns null.  I have not played much with properties,  
>>>except
>>>for reading them, so I don't really understand the code.
>>>
>>>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
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060602/c8892a46/attachment-0018.html

From paul.klissner at sun.com  Fri Jun  2 12:09:26 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 11:09:26 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
Message-ID: <44807ED6.8000903@sun.com>

Joachim Buechse wrote:
> Good day Paul!
>
> A clean architecture with loadable drivers and reusable code would be  
> very beneficial for the future, I think everybody agrees. However  
> this could be several years into the future. In the meantime, there  
> is a real existing problem with IO support on Java. I have the strong  
> feeling that most programmers want to code against one specification  
> (javax.comm) and be able to replace the underlying implementation via  
> a "plugin" on platforms where the SUN implementation is not  
> sufficient. RXTX could be just this plugin (reusing very close to 0%  
> of the javax.comm implementation but 100% of its API).
>
> I want to propose an API addition and implementation change that will  
> take less then 2 hours of manpower to implement and create a solution  
> that can bridge the years until javax.comm has been based on a new  
> architecture.
>
> Looking at the javax.comm api at http://java.sun.com/products/ 
> javacomm/reference/api/index.html I would like to propose the following:
>
> The only entry point to javax.comm is CommPortIdentifier. It has 3  
> static methods plus the constructor.
>
> 1) define one additional Interface
>
> public interface CommProvider {
>     CommPortIdentifier getPortIdentifier(CommPort port);
>     CommPortIdentifier getPortIdentifier(String portName);
>     Enumeration getPortIdentifiers ();
> }
>
> 2) add one method to CommPortIdentifier
>
>    public static setCustomCommProvider (CommProvider);
>
> 3) change the three static methods of CommPortIdentifier to dispatch  
> to the CommProvider if it is set
>
> 4) change the constructor of CommPortIdentifier to
>
>    public CommPortIdentifier(...) {
>       if (isProviderSet && this.getClass() ==  
> javax.comm.CommPortIdentifier) {
>           throw new RuntimeException("illegal creation of  
> CommPortIndentifier, custom CommProvider is in use");
>       }
>
> 5) (this is optional, but would be very nice) automatically set a  
> custom CommProvider if it is found on the classpath or defined via a  
> system property.
>
>
> The above 1) - 4) can be implemented in less than 1hour. 5) may take  
> another hour. I agree that this is not the most elegant design, but  
> it would solve a lot of problems with very little effort. It would  
> certainly allow RXTX to move forward. If the javax.comm API needs to  
> be redesigned completely this addition will not hurt, as people will  
> move to the new API anyway and javax.comm 3.0 was so far never  
> included in the main distribution.
>
> Best regards,
> Joachi
I'm afraid modifying the interface classes isn't my call.  There was 
actually
a TCK written and one of the tests was to ensure that the interface classes
match the spec.  Thus my hands have already been tied since this project
was essentially grandfathered into the JCP.

That's why we need to open a new JSR and find someone who wants
to be the spec lead, and go in with a new reference implementation.
I'm not sure why it would have to take years, since this isn't bleeding edge
technology and there are only so many things that can be done with it,
and we already have practical experience about many functional aspects
that we could cite precedence on.

As it becomes clear that the specification is being accepted completely
or by-and-large by the community, nothing would stop people from
starting adapting to the new API (using the reference implementation or
porting it) and using it in their projects prior to it's final community and
JCP approval, since approval is required only to make it official and
get the "100% pure java" certification for platform ports.

You have one idea already.  Why don't you implement it, solicit some
design feedback from Sun and the RXTX, and create a functional
implementation that addresses the needs of the community, then
we can document it and open a JSR.  That's it.  It should march through
the approval stages reasonably quickly I would imagine, and meantime
RXTX could start using it.

Paul




From doug at dupreeinc.com  Fri Jun  2 12:45:01 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 02 Jun 2006 11:45:01 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
	<9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
Message-ID: <4480872D.6000605@dupreeinc.com>

Joachim,

Thank you for the suggestion.  I restored the jar file to the one I 
downloaded, moved the dll files into the project directory, and added 
the jar to the classpath.  The SerialDemo program that was included with 
the Sun commapi started in 12 seconds instead of the 58 seconds when the 
parallel dll is present.  I did get the startup time to about a second 
by modifying the java code and adding the properties file but this is 
probably not a good idea.

Doug

Joachim Buechse wrote:

>Hi Doug,
>
>you wrote in an earlier message, that you would prefer an unchanged  
>version. What about simply removing the RXTX parallel lib from the  
>ext directory. This does not fix the bug, but it should fix your  
>problem.
>
>In general I think it is not a good idea to put the RXTX files in a  
>system wide location. Putting the libs in the application folder and  
>including the .jar in the application classpath (or application jar)  
>is all that is required.
>
>Regards,
>Joachim
>
>On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:
>
>  
>
>>Ok, I just hacked this thing up and got it to read the
>>gnu.io.rxtx.properties file.
>>
>>I commented out the line:
>>System.setProperties(p); in the method registerSpecifiedPorts() in
>>RXTXCommDriver class.  I really don't understand that much about
>>properties, but this call kills the System class.
>>
>>I used the following in the gnu.io.rxtx.properties file:
>>
>>gnu.io.rxtx.SerialPorts=COM3
>>gnu.io.rxtx.ParallelPorts=null
>>
>>This allows the application to open very quickly without any errors.
>>Whomever coded this class or somebody who understands properties  
>>should
>>look at this method and make sure it is doing what they expect.
>>
>>Doug
>>
>>
>>
>>
>>Doug Thistlethwaite wrote:
>>
>>    
>>
>>>I think there is an error in the registerSpecifiedPorts() method.   
>>>When
>>>I have a gnu.io.rxtx.properties file in the ext directory, this  
>>>function
>>>kills the System class  IF I call System.getProperty("os.name")  
>>>before
>>>the call  to registerSpecifiedPorts(), it returns the os name,  
>>>after the
>>>call, it returns null.  I have not played much with properties,  
>>>except
>>>for reading them, so I don't really understand the code.
>>>
>>>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
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060602/3c0e420f/attachment-0018.html

From joachim at buechse.de  Fri Jun  2 13:46:36 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 21:46:36 +0200
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
	RXTX again
In-Reply-To: <44807ED6.8000903@sun.com>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
	<44807ED6.8000903@sun.com>
Message-ID: <6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>

Hello Paul,

of course, the basic change I suggested could be done "hidden".  The  
CommProvider interface could live somewhere in sun.xyz.*
The setCustomCommProvider method would not be in CommPortIdentifier  
but also somewhere in sun.xyz.* This would be an unofficial feature,  
the official interface stays exactly the same. However RXTX (and  
others) could access the hidden interface.

Don't get me wrong, I don't want to harass you into making changes  
you don't like (which probably wouldn't work anyway;-). But I'm a  
long time Java programmer and seeing the state of cross platform  
serial support for Java makes me feel really sad. In fact, when I  
started to look into Java serial port programming some months ago I  
was very surprised that javax.comm never made it into the JDK.

I'm sorry that I did not contribute my feedback to the JSR for  
javax.comm 3.0. However at the time I didn't do serial port  
programming in Java. I agree that a new JSR should be opened - I'm  
not an expert on JSRs or the JCP process, but from looking quickly  
over the progress of some JSRs I would be very surprised if we can  
have a new version in less then a year. In the meanwhile some people  
will start using javax.comm 3.0 (which can not be supported by RXTX),  
some will use javax.comm 2.0 (which means the 2.0.7 release of RXTX  
still needs to be maintained). This may get even worse if eg Apple  
decides to port and include javax.comm 3.0 at which point it may get  
very tricky to write a cross platform Java application.

All of this simply means, that we are loosing a lot of man-power that  
could otherwise be invested in building a clean solution and/or to  
add features that are becoming more and more important (USB events...).

In the automation / machine control universe Java makes a lot of  
sense. Right now many people are migrating to Linux or from  
propietary systems (even DOS) to Windows. Writing the control/ 
configuration applications in Java is the kings way to unify the code  
base.

Best regards,
Joachim


On 02.06.2006, at 20:09, Paul Klissner wrote:

> Joachim Buechse wrote:
>> Good day Paul!
>>
>> A clean architecture with loadable drivers and reusable code would be
>> very beneficial for the future, I think everybody agrees. However
>> this could be several years into the future. In the meantime, there
>> is a real existing problem with IO support on Java. I have the strong
>> feeling that most programmers want to code against one specification
>> (javax.comm) and be able to replace the underlying implementation via
>> a "plugin" on platforms where the SUN implementation is not
>> sufficient. RXTX could be just this plugin (reusing very close to 0%
>> of the javax.comm implementation but 100% of its API).
>>
>> I want to propose an API addition and implementation change that will
>> take less then 2 hours of manpower to implement and create a solution
>> that can bridge the years until javax.comm has been based on a new
>> architecture.
>>
>> Looking at the javax.comm api at http://java.sun.com/products/
>> javacomm/reference/api/index.html I would like to propose the  
>> following:
>>
>> The only entry point to javax.comm is CommPortIdentifier. It has 3
>> static methods plus the constructor.
>>
>> 1) define one additional Interface
>>
>> public interface CommProvider {
>>     CommPortIdentifier getPortIdentifier(CommPort port);
>>     CommPortIdentifier getPortIdentifier(String portName);
>>     Enumeration getPortIdentifiers ();
>> }
>>
>> 2) add one method to CommPortIdentifier
>>
>>    public static setCustomCommProvider (CommProvider);
>>
>> 3) change the three static methods of CommPortIdentifier to dispatch
>> to the CommProvider if it is set
>>
>> 4) change the constructor of CommPortIdentifier to
>>
>>    public CommPortIdentifier(...) {
>>       if (isProviderSet && this.getClass() ==
>> javax.comm.CommPortIdentifier) {
>>           throw new RuntimeException("illegal creation of
>> CommPortIndentifier, custom CommProvider is in use");
>>       }
>>
>> 5) (this is optional, but would be very nice) automatically set a
>> custom CommProvider if it is found on the classpath or defined via a
>> system property.
>>
>>
>> The above 1) - 4) can be implemented in less than 1hour. 5) may take
>> another hour. I agree that this is not the most elegant design, but
>> it would solve a lot of problems with very little effort. It would
>> certainly allow RXTX to move forward. If the javax.comm API needs to
>> be redesigned completely this addition will not hurt, as people will
>> move to the new API anyway and javax.comm 3.0 was so far never
>> included in the main distribution.
>>
>> Best regards,
>> Joachi
> I'm afraid modifying the interface classes isn't my call.  There was
> actually
> a TCK written and one of the tests was to ensure that the interface  
> classes
> match the spec.  Thus my hands have already been tied since this  
> project
> was essentially grandfathered into the JCP.
>
> That's why we need to open a new JSR and find someone who wants
> to be the spec lead, and go in with a new reference implementation.
> I'm not sure why it would have to take years, since this isn't  
> bleeding edge
> technology and there are only so many things that can be done with it,
> and we already have practical experience about many functional aspects
> that we could cite precedence on.
>
> As it becomes clear that the specification is being accepted  
> completely
> or by-and-large by the community, nothing would stop people from
> starting adapting to the new API (using the reference  
> implementation or
> porting it) and using it in their projects prior to it's final  
> community and
> JCP approval, since approval is required only to make it official and
> get the "100% pure java" certification for platform ports.
>
> You have one idea already.  Why don't you implement it, solicit some
> design feedback from Sun and the RXTX, and create a functional
> implementation that addresses the needs of the community, then
> we can document it and open a JSR.  That's it.  It should march  
> through
> the approval stages reasonably quickly I would imagine, and meantime
> RXTX could start using it.
>
> Paul
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From paul.klissner at sun.com  Fri Jun  2 14:38:49 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 13:38:49 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
	<44807ED6.8000903@sun.com>
	<6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>
Message-ID: <4480A1D9.5060106@sun.com>

Joachim Buechse wrote:
> Hello Paul,
>
> of course, the basic change I suggested could be done "hidden".  The  
> CommProvider interface could live somewhere in sun.xyz.*
> The setCustomCommProvider method would not be in CommPortIdentifier  
> but also somewhere in sun.xyz.* This would be an unofficial feature,  
> the official interface stays exactly the same. However RXTX (and  
> others) could access the hidden interface.
>
> Don't get me wrong, I don't want to harass you into making changes  
> you don't like (which probably wouldn't work anyway;-). But I'm a  
> long time Java programmer and seeing the state of cross platform  
> serial support for Java makes me feel really sad. In fact, when I  
> started to look into Java serial port programming some months ago I  
> was very surprised that javax.comm never made it into the JDK.
>
> I'm sorry that I did not contribute my feedback to the JSR for  
> javax.comm 3.0. 
There was no JSR for 3.0, because we didn't have the resources to make 
the commitment.
Yet Sun needed to add support for platform-dependent port name mapping, 
which had to
be done 'under the hood', since the API isn't designed to handle that in 
a pluggable way.
But these quick fixes aren't the right approach, they just kick the dog 
down the road,
setting bad precedent, inviting confusion and more intractable problems 
(such as the
one plaguing us now).

My changes could have been layered better, it was a trade off between 
achieving an
ideal architecture, trying to find internal reviewers, and meet the 
needs of big customers
in a timely way.  Thus my namespace changes collided with RXTX's 
dependencies.
I was unaware of Jagane's rogue agreement made with the RXTX community 7 
years ago,
before Jagane left Sun.  I think this was a wag-the-dog situation.

Now it is time to do it right, and I don't think it is going to be as 
much trouble as people
some people fear. If RXTX wants to sponsor the JSR and seed a new spec, 
Sun can join
the Expert Group.  And we'd be largely in agreement, since we're not 
talking about
humongous changes, and looking for mutually beneficial changes. The core 
API is already
largely proved and tested.
> However at the time I didn't do serial port  
> programming in Java. I agree that a new JSR should be opened - I'm  
> not an expert on JSRs or the JCP process, but from looking quickly  
> over the progress of some JSRs I would be very surprised if we can  
> have a new version in less then a year. 
*Approved*  But that doesn't mean the spec couldn't be 99.9% stable 
before that.  Once
the delta rate declines and changes approach nil, people could start 
adapting to the API in
advance of formal approval.   It isn't going to be drawn out like 
javax.usb, which was new
technology, a very complex API, and involved precedent setting corporate 
disputes and
policy issues to resolve.

> In the meanwhile some people  
> will start using javax.comm 3.0 (which can not be supported by RXTX),  
> some will use javax.comm 2.0 (which means the 2.0.7 release of RXTX  
> still needs to be maintained). This may get even worse if eg Apple  
> decides to port and include javax.comm 3.0 at which point it may get  
> very tricky to write a cross platform Java application.
>   
The interfaces haven't changed since 1.0.  If we open a JSR ,we can 
contact Apple and
allow them to be on the E.G., if they want.  That might make the JSR a 
bit more drawn out,
but then we'd arrive ultimately arrive at a best-of-all-worlds API that 
most people would
accept, perhaps forever, and arrive at a respectable set of compromises.

-Paul

> All of this simply means, that we are loosing a lot of man-power that  
> could otherwise be invested in building a clean solution and/or to  
> add features that are becoming more and more important (USB events...).
>
> In the automation / machine control universe Java makes a lot of  
> sense. Right now many people are migrating to Linux or from  
> propietary systems (even DOS) to Windows. Writing the control/ 
> configuration applications in Java is the kings way to unify the code  
> base.
>
> Best regards,
> Joachim
>
>
> On 02.06.2006, at 20:09, Paul Klissner wrote:
>
>   
>> Joachim Buechse wrote:
>>     
>>> Good day Paul!
>>>
>>> A clean architecture with loadable drivers and reusable code would be
>>> very beneficial for the future, I think everybody agrees. However
>>> this could be several years into the future. In the meantime, there
>>> is a real existing problem with IO support on Java. I have the strong
>>> feeling that most programmers want to code against one specification
>>> (javax.comm) and be able to replace the underlying implementation via
>>> a "plugin" on platforms where the SUN implementation is not
>>> sufficient. RXTX could be just this plugin (reusing very close to 0%
>>> of the javax.comm implementation but 100% of its API).
>>>
>>> I want to propose an API addition and implementation change that will
>>> take less then 2 hours of manpower to implement and create a solution
>>> that can bridge the years until javax.comm has been based on a new
>>> architecture.
>>>
>>> Looking at the javax.comm api at http://java.sun.com/products/
>>> javacomm/reference/api/index.html I would like to propose the  
>>> following:
>>>
>>> The only entry point to javax.comm is CommPortIdentifier. It has 3
>>> static methods plus the constructor.
>>>
>>> 1) define one additional Interface
>>>
>>> public interface CommProvider {
>>>     CommPortIdentifier getPortIdentifier(CommPort port);
>>>     CommPortIdentifier getPortIdentifier(String portName);
>>>     Enumeration getPortIdentifiers ();
>>> }
>>>
>>> 2) add one method to CommPortIdentifier
>>>
>>>    public static setCustomCommProvider (CommProvider);
>>>
>>> 3) change the three static methods of CommPortIdentifier to dispatch
>>> to the CommProvider if it is set
>>>
>>> 4) change the constructor of CommPortIdentifier to
>>>
>>>    public CommPortIdentifier(...) {
>>>       if (isProviderSet && this.getClass() ==
>>> javax.comm.CommPortIdentifier) {
>>>           throw new RuntimeException("illegal creation of
>>> CommPortIndentifier, custom CommProvider is in use");
>>>       }
>>>
>>> 5) (this is optional, but would be very nice) automatically set a
>>> custom CommProvider if it is found on the classpath or defined via a
>>> system property.
>>>
>>>
>>> The above 1) - 4) can be implemented in less than 1hour. 5) may take
>>> another hour. I agree that this is not the most elegant design, but
>>> it would solve a lot of problems with very little effort. It would
>>> certainly allow RXTX to move forward. If the javax.comm API needs to
>>> be redesigned completely this addition will not hurt, as people will
>>> move to the new API anyway and javax.comm 3.0 was so far never
>>> included in the main distribution.
>>>
>>> Best regards,
>>> Joachi
>>>       
>> I'm afraid modifying the interface classes isn't my call.  There was
>> actually
>> a TCK written and one of the tests was to ensure that the interface  
>> classes
>> match the spec.  Thus my hands have already been tied since this  
>> project
>> was essentially grandfathered into the JCP.
>>
>> That's why we need to open a new JSR and find someone who wants
>> to be the spec lead, and go in with a new reference implementation.
>> I'm not sure why it would have to take years, since this isn't  
>> bleeding edge
>> technology and there are only so many things that can be done with it,
>> and we already have practical experience about many functional aspects
>> that we could cite precedence on.
>>
>> As it becomes clear that the specification is being accepted  
>> completely
>> or by-and-large by the community, nothing would stop people from
>> starting adapting to the new API (using the reference  
>> implementation or
>> porting it) and using it in their projects prior to it's final  
>> community and
>> JCP approval, since approval is required only to make it official and
>> get the "100% pure java" certification for platform ports.
>>
>> You have one idea already.  Why don't you implement it, solicit some
>> design feedback from Sun and the RXTX, and create a functional
>> implementation that addresses the needs of the community, then
>> we can document it and open a JSR.  That's it.  It should march  
>> through
>> the approval stages reasonably quickly I would imagine, and meantime
>> RXTX could start using it.
>>
>> Paul
>>
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at 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  Sat Jun  3 18:15:24 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 18:15:24 -0600 (MDT)
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
Message-ID: <Pine.LNX.4.61.0606031715100.10890@www>


The attached patch allows baud rates of 14400, 28800, 128000 and 256000.

That was my goal.

[import standard disclaimer]

But I took some time to look a little further.  I got custom baud rates 
working enough that someone (perhaps me) can properly fix them in the 
future.  Proof of concept.

As an undocumented bonus, you can toss random baudrates (say 1953), at the 
API and it will set it to something close to that on windows and linux. 
Solaris should say the baud rate is not supported but I have not tested it 
yet.  Mac OS X behavior is unknown at this point.  Just dont expect 
correct behavior at ~8192-9009 baudrates or baudrates less than 20 on 
windows; these baud rates overlap with defines in win32termios.h.  I 
conveniently closed my eyes there.  Try another value close.  On Linux, a 
baud base and divisor are guestimated and set.  On windows, we wave pixie 
dust over the kernel driver and hope.  Do not expect pixie dust and 
guestimates to be the same on windows and linux.  They may well round to 
different values in yet to be tested ways.  There are only so many 
divisors.  If it isn't working, try a little higher or lower.

In the example of 1953 for instance, there is no divisor for commodity 
hardware that comes to that baudrate.  We just come close on one side or 
the other.  If tools tell you they got 1953 exactly, the tools may be 
questionable and just reading values not directly related to the actual 
hardware settings.

These fixes have been tested on Linux and Windows while using an 
oscilloscope to confirm they change relative to known baudrates at 9600, 
14400*, 19200, 28800* (and 1800, 1953** and 2400).

* = previously unsupported.
** = still not supported but probably works from what I saw.

There could be future discussion in this area.  For now this is working 
for almost all unusual baud rate demands.  Cleaning up the custom baud 
rate should be easier with a working starting point.  Baud bases other 
than 128000 have not been characterized.  Yes.. this overlapps with two of 
the baud rates enabled.

Feedback and ideas are welcome.

--
Trent Jarvi
tjarvi at qbang.org
-------------- next part --------------
Index: SerialImp.c
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v
retrieving revision 1.46.2.187
diff -u -r1.46.2.187 SerialImp.c
--- SerialImp.c	29 Jan 2006 22:19:04 -0000	1.46.2.187
+++ SerialImp.c	3 Jun 2006 23:12:40 -0000
@@ -793,6 +793,19 @@
 		result &= ~TIOCM_DTR;
 		ioctl( fd, TIOCMSET, &result );
 	}
+	/*
+	   B38400 is a special case in Linux for custom baud rates.
+
+	   We just treat this as a custom speed for now.  If you take this ifdef
+	   out and select baud rates 38400 then 28800 then 38400, you will get
+	   a final baud rate of 28800 because you did not update the divisor.
+
+	   See the next ifdef below for the divisor.
+	*/
+#if defined(TIOCGSERIAL)
+	if ( cspeed == B38400 )
+		cspeed = 38400;
+#endif /* TIOCGSERIAL */
 	if(     cfsetispeed( &ttyset, cspeed ) < 0 ||
 		cfsetospeed( &ttyset, cspeed ) < 0 )
 	{
@@ -814,6 +827,7 @@
 		*/
 
 #if defined(TIOCGSERIAL)
+		ioctl( fd, TIOCGSERIAL, &sstruct );
 		sstruct.custom_divisor = ( sstruct.baud_base/cspeed );
 		cspeed = B38400;
 #endif /* TIOCGSERIAL */
@@ -827,7 +841,7 @@
 #if defined(TIOCSSERIAL)
 		/*  It is assumed Win32 does this for us */
 		if (	sstruct.baud_base < 1 ||
-			ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
+		ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
 		{
 			return( 1 );
 		}
Index: termios.c
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v
retrieving revision 1.9.2.56
diff -u -r1.9.2.56 termios.c
--- termios.c	16 Jan 2006 02:50:32 -0000	1.9.2.56
+++ termios.c	3 Jun 2006 23:12:40 -0000
@@ -323,8 +323,8 @@
 		case CBR_3500000:	return( B3500000 );
 		case CBR_4000000:	return( B4000000 );
 		default:
-			set_errno(EINVAL );
-			return -1;
+			/* assume custom baudrate */
+			return( Baud );
 	}
 }
 
@@ -361,12 +361,13 @@
 		case B9600:	ret = CBR_9600;		break;
 		case B14400:	ret = CBR_14400;	break;
 		case B19200:	ret = CBR_19200;	break;
+		case B28800:	ret = CBR_28800;	break;
 		case B38400:	ret = CBR_38400;	break;
 		case B57600:	ret = CBR_57600;	break;
 		case B115200:	ret = CBR_115200;	break;
 		case B128000:	ret = CBR_128000;	break;
-		case B256000: 	ret = CBR_256000;	break;
 		case B230400:	ret = CBR_230400;	break;
+		case B256000: 	ret = CBR_256000;	break;
 		case B460800:	ret = CBR_460800;	break;
 		case B500000:	ret = CBR_500000;	break;
 		case B576000:	ret = CBR_576000;	break;
@@ -381,10 +382,8 @@
 		case B4000000:	ret = CBR_4000000;	break;
 	
 		default:
-			fprintf( stderr, "B_to_CBR: invalid baudrate: %#o\n",
-				Baud );
-			set_errno( EINVAL );
-			return -1;
+			/* assume custom baudrate */
+			return Baud;
 	}
 	LEAVE( "B_to_CBR" );
 	return ret;
@@ -708,12 +707,9 @@
 	ENTER( "init_serial_struct" );
 
 	/*
-	FIXME
-
-	This needs to use inb() to read the actual baud_base
-	and divisor from the UART registers.  Question is how
-	far do we take this?
-
+	use of custom_divisor and baud_base requires access to
+	kernel space.  The kernel does try its best if you just
+	toss a baud rate at it though.
 	*/
 
 	sstruct->custom_divisor = 0;
@@ -1678,16 +1674,17 @@
 {
 	char message[80];
 	ENTER( "cfsetospeed" );
+	/* clear baudrate */
+	s_termios->c_cflag &= ~CBAUD;
 	if ( speed & ~CBAUD )
 	{
 		sprintf( message, "cfsetospeed: not speed: %#o\n", speed );
 		report( message );
-		return 0;
+		/* continue assuming its a custom baudrate */
+		s_termios->c_cflag |= B38400;  /* use 38400 during custom */
+		s_termios->c_cflag |= CBAUDEX; /* use CBAUDEX for custom */
 	}
-	s_termios->c_ispeed = s_termios->c_ospeed = speed;
-	/* clear baudrate */
-	s_termios->c_cflag &= ~CBAUD;
-	if( speed )
+	else if( speed )
 	{
 		s_termios->c_cflag |= speed;
 	}
@@ -1696,6 +1693,7 @@
 		/* PC blows up with speed 0 handled in Java */
 		s_termios->c_cflag |= B9600;
 	}
+	s_termios->c_ispeed = s_termios->c_ospeed = speed;
 	LEAVE( "cfsetospeed" );
 	return 1;
 }
@@ -1767,25 +1765,6 @@
 }
 
 /*----------------------------------------------------------
-serial_struct_to_DCB()
-
-   accept:      
-   perform:     
-   return:      
-   exceptions:  
-   win32api:     None
-   comments:    
-----------------------------------------------------------*/
-int serial_struct_to_DCB( struct serial_struct *sstruct, DCB *dcb )
-{
-	/* 5 Baud rate fix
-	sstruct.baud_base
-	sstruct.custom_divisor = ( sstruct.baud_base/cspeed );
-	*/
-	return(0);
-}
-
-/*----------------------------------------------------------
 termios_to_DCB()
 
    accept:      
@@ -1798,7 +1777,8 @@
 int termios_to_DCB( struct termios *s_termios, DCB *dcb )
 {
 	ENTER( "termios_to_DCB" );
-	s_termios->c_ispeed = s_termios->c_ospeed = s_termios->c_cflag & CBAUD;
+	if ( !(s_termios->c_cflag & CBAUDEX) )
+		s_termios->c_ispeed = s_termios->c_ospeed = s_termios->c_cflag & CBAUD;
 	dcb->BaudRate        = B_to_CBR( s_termios->c_ispeed );
 	dcb->ByteSize = termios_to_bytesize( s_termios->c_cflag );
 
@@ -2863,11 +2843,6 @@
 			GetCommState( index->hComm, dcb );
 
 			index->sstruct = va_arg( ap, struct serial_struct * );
-			if ( serial_struct_to_DCB( index->sstruct, dcb ) < 0 )
-			{
-				va_end( ap );
-				return -1;
-			}
 
 			report( "TIOCSSERIAL\n" );
 			free(dcb);
Index: win32termios.h
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v
retrieving revision 1.5.2.28
diff -u -r1.5.2.28 win32termios.h
--- win32termios.h	30 Jun 2005 20:23:26 -0000	1.5.2.28
+++ win32termios.h	3 Jun 2006 23:12:40 -0000
@@ -279,7 +279,7 @@
 #define XTABS	01000000 /* Hmm.. Linux/i386 considers this part of TABDLY.. */
 
 /* c_cflag bit meaning */
-# define CBAUD	0010017
+#define  CBAUD  0030017
 #define  B0	0000000		/* hang up */
 #define  B50	0000001
 #define  B75	0000002
@@ -312,13 +312,16 @@
 #define  B3500000 0010016
 #define  B4000000 0010017
 
-/* glue for unsupported linux speeds see also SerialImp.h */
-/* hosed */
-
-#define B14400		1010001
-#define B28800		1010002
-#define B128000		1010003
-#define B256000		1010004
+/*
+	glue for unsupported linux speeds see also SerialImp.h 
+	custom baud rates around 8192-9000 will not work because
+	of these.
+*/
+
+#define B14400		0020001
+#define B28800		0020002
+#define B128000		0020003
+#define B256000		0020004
 
 #define EXTA B19200
 #define EXTB B38400
@@ -356,8 +359,10 @@
 
 /* glue for unsupported windows speeds */
 
-#define CBR_230400	230400
 #define CBR_28800	28800
+#define CBR_128000	128000
+#define CBR_230400	230400
+#define CBR_256000	256000
 #define CBR_460800	460800
 #define CBR_500000	500000
 #define CBR_576000	576000

From impakt01 at optusnet.com.au  Sat Jun  3 18:30:37 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 10:30:37 +1000
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
In-Reply-To: <Pine.LNX.4.61.0606031715100.10890@www>
Message-ID: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>

Hi Trent,
I'd love to try the patch but I can't get the latest build compiling, only
pre16. 

Can you attach the rxtxSerial.dll file with this patch?

Also, I hardcoded 1953 in a couple more places last night on pre16 and it
managed to open the port at the right speed, but stopped receiving anything
after 100-150 bytes, even though more data was getting sent to the port.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 10:15 AM
To: rxtx at qbang.org
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.


The attached patch allows baud rates of 14400, 28800, 128000 and 256000.

That was my goal.

[import standard disclaimer]

But I took some time to look a little further.  I got custom baud rates 
working enough that someone (perhaps me) can properly fix them in the 
future.  Proof of concept.

As an undocumented bonus, you can toss random baudrates (say 1953), at the 
API and it will set it to something close to that on windows and linux. 
Solaris should say the baud rate is not supported but I have not tested it 
yet.  Mac OS X behavior is unknown at this point.  Just dont expect 
correct behavior at ~8192-9009 baudrates or baudrates less than 20 on 
windows; these baud rates overlap with defines in win32termios.h.  I 
conveniently closed my eyes there.  Try another value close.  On Linux, a 
baud base and divisor are guestimated and set.  On windows, we wave pixie 
dust over the kernel driver and hope.  Do not expect pixie dust and 
guestimates to be the same on windows and linux.  They may well round to 
different values in yet to be tested ways.  There are only so many 
divisors.  If it isn't working, try a little higher or lower.

In the example of 1953 for instance, there is no divisor for commodity 
hardware that comes to that baudrate.  We just come close on one side or 
the other.  If tools tell you they got 1953 exactly, the tools may be 
questionable and just reading values not directly related to the actual 
hardware settings.

These fixes have been tested on Linux and Windows while using an 
oscilloscope to confirm they change relative to known baudrates at 9600, 
14400*, 19200, 28800* (and 1800, 1953** and 2400).

* = previously unsupported.
** = still not supported but probably works from what I saw.

There could be future discussion in this area.  For now this is working 
for almost all unusual baud rate demands.  Cleaning up the custom baud 
rate should be easier with a working starting point.  Baud bases other 
than 128000 have not been characterized.  Yes.. this overlapps with two of 
the baud rates enabled.

Feedback and ideas are welcome.

--
Trent Jarvi
tjarvi at qbang.org



From tjarvi at qbang.org  Sat Jun  3 19:05:11 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 19:05:11 -0600 (MDT)
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
In-Reply-To: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>
References: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606031840400.10890@www>

On Sun, 4 Jun 2006, Daren wrote:

> Hi Trent,
> I'd love to try the patch but I can't get the latest build compiling, only
> pre16.
>
> Can you attach the rxtxSerial.dll file with this patch?
>
> Also, I hardcoded 1953 in a couple more places last night on pre16 and it
> managed to open the port at the right speed, but stopped receiving anything
> after 100-150 bytes, even though more data was getting sent to the port.
>


ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing

I dont think they will hang.  But I was just testing via loopback/break 
out box/scope.

I'll be putting about 10 patches and another set of binaries in that 
directory shortly.  For now the binaries should just have the baud_rate 
fix.

I'll announce all the patches at once.  but wont be releasing 2.1-8 right 
away.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Sat Jun  3 21:00:01 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 21:00:01 -0600 (MDT)
Subject: [Rxtx] CVS for 2.1 should have everything
Message-ID: <Pine.LNX.4.61.0606032056190.10890@www>


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org


From impakt01 at optusnet.com.au  Sat Jun  3 21:08:14 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 13:08:14 +1000
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <Pine.LNX.4.61.0606032056190.10890@www>
Message-ID: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>

Hi Trent,
I tried the latest dll and it opens the port, receives 100-200 bytes and
then stops receiving anything else..

I'll keep playing with it.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 1:00 PM
To: rxtx at qbang.org
Subject: [Rxtx] CVS for 2.1 should have everything


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From impakt01 at optusnet.com.au  Sat Jun  3 21:22:41 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 13:22:41 +1000
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
Message-ID: <200606040322.k543MqW1008455@mail12.syd.optusnet.com.au>

Played with it, problem, with a while loop in my code, working great now

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Daren
Sent: Sunday, 4 June 2006 1:08 PM
To: 'RXTX Developers and Users'
Subject: Re: [Rxtx] CVS for 2.1 should have everything

Hi Trent,
I tried the latest dll and it opens the port, receives 100-200 bytes and
then stops receiving anything else..

I'll keep playing with it.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 1:00 PM
To: rxtx at qbang.org
Subject: [Rxtx] CVS for 2.1 should have everything


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Sat Jun  3 21:35:41 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 21:35:41 -0600 (MDT)
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
References: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606032131140.10890@www>

On Sun, 4 Jun 2006, Daren wrote:

> Hi Trent,
> I tried the latest dll and it opens the port, receives 100-200 bytes and
> then stops receiving anything else..
>
> I'll keep playing with it.
>
> Daren

The difference may be that I'm talking to something at the exact same baud 
rate (loopback).

You may also try setting the baudrate to ~1933 and ~1973 to force the 
guesses one way or the other.  If you are on windows, we are not doing 
anything fancy in the end.  Thats the kernel guessing.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sun Jun  4 04:12:09 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sun, 4 Jun 2006 12:12:09 +0200
Subject: [Rxtx] Update of OSX installer, Readme, etc
Message-ID: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>

Good day,

after the latest changes a lot of OS X specific files should be  
updated. Especially the installer!

- The "MaxOSX" readme file on the root level is outdated (ie  
CodeWarrior information). Maybe we could even rename it to README.OSX  
to be in line with README.IPAQ, README.SCO (Trent do you mind copying/ 
renaming ,v files in the repository?).

- The lock files are no longer used and hence the user group magic  
and lock folder creation should be removed from the installer.

- MACOSX_IDE/ForPackageMaker/Resources/ReadMe.rtf and Welcome.rtf  
need to be updated.

- I suggest to replace the current installation instruction for OS X:  
Installation should occur into the application directory, not in the  
Java-VM directory. This simplifies things a lot, as the Mac Installer  
can be removed completely.

- The xcodeproject's build settings need to be updated to generate  
JAVA 1.1 format class files.


Dimitry: do you have time to tackle this? I could do it, but as this  
is "your baby" I thought you may prefer to do it yourself.

Regards,
Joachim



From dmarkman at mac.com  Sun Jun  4 11:27:53 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Sun, 4 Jun 2006 13:27:53 -0400
Subject: [Rxtx] Update of OSX installer, Readme, etc
In-Reply-To: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
References: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
Message-ID: <26E7A202-962B-4C19-93B6-29426C467249@mac.com>

Joachim,
unfortunately I don't have time right now to do that
so if you can do that, please do

it's not only my baby
it's yours too :-)

thanks


On Jun 4, 2006, at 6:12 AM, Joachim Buechse wrote:

> Good day,
>
> after the latest changes a lot of OS X specific files should be
> updated. Especially the installer!
>
> - The "MaxOSX" readme file on the root level is outdated (ie
> CodeWarrior information). Maybe we could even rename it to README.OSX
> to be in line with README.IPAQ, README.SCO (Trent do you mind copying/
> renaming ,v files in the repository?).
>
> - The lock files are no longer used and hence the user group magic
> and lock folder creation should be removed from the installer.
>
> - MACOSX_IDE/ForPackageMaker/Resources/ReadMe.rtf and Welcome.rtf
> need to be updated.
>
> - I suggest to replace the current installation instruction for OS X:
> Installation should occur into the application directory, not in the
> Java-VM directory. This simplifies things a lot, as the Mac Installer
> can be removed completely.
>
> - The xcodeproject's build settings need to be updated to generate
> JAVA 1.1 format class files.
>
>
> Dimitry: do you have time to tackle this? I could do it, but as this
> is "your baby" I thought you may prefer to do it yourself.
>
> Regards,
> Joachim
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman



From tjarvi at qbang.org  Sun Jun  4 13:54:02 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 4 Jun 2006 13:54:02 -0600 (MDT)
Subject: [Rxtx] Update of OSX installer, Readme, etc
In-Reply-To: <26E7A202-962B-4C19-93B6-29426C467249@mac.com>
References: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
	<26E7A202-962B-4C19-93B6-29426C467249@mac.com>
Message-ID: <Pine.LNX.4.61.0606041353040.22522@www>

On Sun, 4 Jun 2006, Dmitry Markman wrote:

> Joachim,
> unfortunately I don't have time right now to do that
> so if you can do that, please do
>
> it's not only my baby
> it's yours too :-)
>

I've given Joachim cvs access.  He has shown good work in bugzilla.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Mon Jun  5 10:08:32 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 5 Jun 2006 18:08:32 +0200
Subject: [Rxtx] Build process changes for Mac OS X
Message-ID: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>

Good day,

I have cleaned up some outdated Mac OSX specific build files in the  
repository.

There was not a lot left of the readme file "MacOSX" after cleaning  
it up, so I decided to rename it README.OSX to be in harmony with the  
other files in the directory (ie README.IPAQ, README.SCO, ...)

I added an (uncompressed) XCode 2.3 project file/structure  
with .cvsignore files that will ignore the user specific settings.  
This should work "out of the box" for OSX10.4. Users of 10.2/10.3 may  
have to switch the build settings.

[It's kind of tricky to choose "the right" setting. Afaik there is no  
way to compile a universal binary that will work on 10.3 or before.  
So it's either UniversalBinary OR Legacy. Maybe we should have  
different build targets for these different targets?? I would like to  
get some feedback from the Mac developers on this list regarding the  
subject].

Besides other things the OSX installer is no longer required. Since  
the next version (2.1.8) will no longer use lockfiles on OSX, the  
group/permission magic is no longer required and hence there remains  
basicly no work for the installer - other than copying 2 files to the  
VM extension directory. Then again, this is not the best way to  
install RXTX. So I removed the installer completely without modifying  
it, this should simplify a "resurrection" should it ever get necessary.

I had problems with the (compressed, ie sit.hqx) legacy project files  
on the latest installation of OSX (javac 1.5 creating non JDK1.1  
class files and some minor problems). To reduce potential confusion  
for newcomers I decided to remove them. This means that there is no  
longer a simple way to build RXTX for OSX 10.0 and 10.1 (I deeply  
apologize if anyone still relied on this ... well the files are in  
the Attiq).

Best regards,
Joachim


From joachim at buechse.de  Mon Jun  5 10:16:37 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 5 Jun 2006 18:16:37 +0200
Subject: [Rxtx] RXTX and lockfiles on OSX [it is fixed now]
Message-ID: <7D2C4418-9397-4B59-8091-9FDE4ED67836@buechse.de>

Quite a number of people contacted me in the last couple of weeks  
because of problems installing RXTX on OSX. I told you to wait for  
the "official" fix. Well, it has been fixed.

So if you were among the people waiting for the solution, you can now  
download the source rxtx-2.1-7r2.zip from the website. Once unpacked  
dont forget to use "cvs up" to update the files to the latest  
version. You can then open MACOSX_IDE/XCode/ 
LibSerialUniversal.xcodeproj with XCode 2.3 and build the libraries  
that no longer try to create lock files.

Regards,
Joachim


From brian at mbari.org  Mon Jun  5 10:52:43 2006
From: brian at mbari.org (Brian Schlining)
Date: Mon, 5 Jun 2006 09:52:43 -0700
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
Message-ID: <78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>

Hi Joachim,

> [It's kind of tricky to choose "the right" setting. Afaik there is no
> way to compile a universal binary that will work on 10.3 or before.
> So it's either UniversalBinary OR Legacy. Maybe we should have
> different build targets for these different targets?? I would like to
> get some feedback from the Mac developers on this list regarding the
> subject].

I imagine most developers will be compiling on 10.4 (It's the nature  
of the coder...gotta have the latest and greatest) and deploying to  
both 10.3 and 10.4; both of which will run Universal Binaries (see  
http://forums.macrumors.com/showthread.php?t=205348). So it sounds  
like you've covered the majority of users. Still, you know someone's  
going to pipe up about needing RXTX on 10.2 so it would be nice to  
have a target to make a PPC only build.

Just my 2 cents

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/1cac8c39/attachment-0018.html

From dmarkman at mac.com  Mon Jun  5 13:47:50 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Mon, 5 Jun 2006 15:47:50 -0400
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
Message-ID: <686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>

I don't think it will be a problem to run universal binary
on 10.2
however if binary has some calls that aren't implemented in 10.2
then you'll have a problem


On Jun 5, 2006, at 12:52 PM, Brian Schlining wrote:

> Hi Joachim,
>
>> [It's kind of tricky to choose "the right" setting. Afaik there is no
>> way to compile a universal binary that will work on 10.3 or before.
>> So it's either UniversalBinary OR Legacy. Maybe we should have
>> different build targets for these different targets?? I would like to
>> get some feedback from the Mac developers on this list regarding the
>> subject].
>
> I imagine most developers will be compiling on 10.4 (It's the  
> nature of the coder...gotta have the latest and greatest) and  
> deploying to both 10.3 and 10.4; both of which will run Universal  
> Binaries (see http://forums.macrumors.com/showthread.php?t=205348).  
> So it sounds like you've covered the majority of users. Still, you  
> know someone's going to pipe up about needing RXTX on 10.2 so it  
> would be nice to have a target to make a PPC only build.
>
> Just my 2 cents
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/9fafc878/attachment-0018.html

From brian at mbari.org  Mon Jun  5 14:52:41 2006
From: brian at mbari.org (Brian Schlining)
Date: Mon, 5 Jun 2006 13:52:41 -0700
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
Message-ID: <E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>

Hi Dmitry,

> I don't think it will be a problem to run universal binary
> on 10.2
> however if binary has some calls that aren't implemented in 10.2
> then you'll have a problem

You're right...I stand corrected.

Note however, to deploy a universal binary to 10.2 RXTX will need to  
use the 10.2 SDK to build the PPC side. (see http:// 
developer.apple.com/documentation/DeveloperTools/Conceptual/ 
cross_development/UniversalBinaries/chapter_4_section_1.html). I  
haven't been paying close attention to the new locking mechanism used  
by RXTX on the Mac...does 10.2 support it?

Joachim, which SDK will you be using by default for building the Mac  
PPC binaries?

>> Hi Joachim,
>>
>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>> is no
>>> way to compile a universal binary that will work on 10.3 or before.
>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>> different build targets for these different targets?? I would  
>>> like to
>>> get some feedback from the Mac developers on this list regarding the
>>> subject].
>>
>> I imagine most developers will be compiling on 10.4 (It's the  
>> nature of the coder...gotta have the latest and greatest) and  
>> deploying to both 10.3 and 10.4; both of which will run Universal  
>> Binaries (see http://forums.macrumors.com/showthread.php? 
>> t=205348). So it sounds like you've covered the majority of users.  
>> Still, you know someone's going to pipe up about needing RXTX on  
>> 10.2 so it would be nice to have a target to make a PPC only build.

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/153bf50e/attachment-0018.html

From dmarkman at mac.com  Mon Jun  5 19:02:04 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Mon, 5 Jun 2006 21:02:04 -0400
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
Message-ID: <7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>

if Joachim didn't change xcode project setting

/Developer/SDKs/MacOSX10.4u.sdk is used to build universal binary

so it's quite possible that it won't run properly on 10.2

so we have to change the building process, so ppc part will be built
with
/Developer/SDKs/MacOSX10.2.8.sdk

and finally to use lipo utility to build universal binaries

Joachim, did you use some specific locking API that wasn't implemented

in MacOSX10.2.8.sdk?

thanks


On Jun 5, 2006, at 4:52 PM, Brian Schlining wrote:

> Hi Dmitry,
>
>> I don't think it will be a problem to run universal binary
>> on 10.2
>> however if binary has some calls that aren't implemented in 10.2
>> then you'll have a problem
>
> You're right...I stand corrected.
>
> Note however, to deploy a universal binary to 10.2 RXTX will need  
> to use the 10.2 SDK to build the PPC side. (see http:// 
> developer.apple.com/documentation/DeveloperTools/Conceptual/ 
> cross_development/UniversalBinaries/chapter_4_section_1.html). I  
> haven't been paying close attention to the new locking mechanism  
> used by RXTX on the Mac...does 10.2 support it?
>
> Joachim, which SDK will you be using by default for building the  
> Mac PPC binaries?
>
>>> Hi Joachim,
>>>
>>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>>> is no
>>>> way to compile a universal binary that will work on 10.3 or before.
>>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>>> different build targets for these different targets?? I would  
>>>> like to
>>>> get some feedback from the Mac developers on this list regarding  
>>>> the
>>>> subject].
>>>
>>> I imagine most developers will be compiling on 10.4 (It's the  
>>> nature of the coder...gotta have the latest and greatest) and  
>>> deploying to both 10.3 and 10.4; both of which will run Universal  
>>> Binaries (see http://forums.macrumors.com/showthread.php? 
>>> t=205348). So it sounds like you've covered the majority of  
>>> users. Still, you know someone's going to pipe up about needing  
>>> RXTX on 10.2 so it would be nice to have a target to make a PPC  
>>> only build.
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/84790f80/attachment-0018.html

From joachim at buechse.de  Tue Jun  6 02:40:47 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 6 Jun 2006 10:40:47 +0200
Subject: [Rxtx] Building on OS X, Impl Changes
In-Reply-To: <7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
Message-ID: <CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>

Good day!

What's in the XCode project setting?
----------

The xcode project remained pretty much the same as before. I excluded  
the user specific files from CVS and changed some settings. I kept  
all the built targets (you shouldn't change what you don't understand;-)

Currently we the following build targets:
    RXTXComm (java files)
    librxtxParallel.jnilib (usefull on the Mac???)
    libI2C.jnilib (not yet working in RXTX)
    libRS485.jnilib (not yet working in RXTX)
    librxtxSerial.jnilib (1)
    librxtxSerial.jnilib Dynamic (2)
    rxtxSerial (3)
We also have the following build configurations for each target:
    Development
    Default
    Deployment

What was changed in the xcode project from previous versions:
- java.souce=1.3 and java.target=1.1 in RXTXComm settings
- removed copying of build products into installer directory
- removed "(Upgraded)" from build target names

What remains to be changed:
- choosing a "non-debug" Build-configuration as default
- potentially removing "Default"/"Development" Build-configurations
- reducing the number of build targets
- creating 10.2 compatible universal binaries

I suggest, that the build configurations should be reduced to 2  
(Debug/Deployment), possibly even 1 (Debug).
I have not yet found the deeper meaning of the build targets(1)(2) 
(3), it seems to me like they should be reduced into one "doing the  
right thing" or maybe into two "rxtxSerial.jnilib Legacy" (back to  
10.2, universal if possible) and "rxtxSerial.jnilib 10.4 
+" (universal, 10.4+).

Should the code work on 10.2?
----------

Absolutely. The code should work on NextStep, in fact on any BSD  
unix. I would go as far as saying, this code should work on any  
POSSIX based unix. All that was added is the call "ioctl(fd,  
TIOCEXCL)" to request excusivity of the port:

http://gemma.apple.com/documentation/DeviceDrivers/Conceptual/ 
WorkingWSerial/WWSerial_SerialDevs/chapter_2_section_8.html

It is not yet "the perfect solution". Normally an open /dev/tty  
(listen for incomming connection) should be "preemptable" by opening  
a /dev/cu (outgoing connection) for the same port. This is not yet  
implemented as it needs calls outside of POSSIX on OSX.

On "classic" systems (like NextStep) this worked based on the  
"carried detect line". open() on /dev/tty.xxx would block until the  
carrier detect signal was raised. As the device was not "opened"  
opening /dev/cu.xxx worked without a hitch. When they ported to the  
Mac this broke. On Macs the "carier detect" is usually not wired.  
Furthermore FAX modems did no longer raise the line. So the OSX  
implementor defined a new call, which is documented here:

http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00045.html

Best regards,
Joachim




On 06.06.2006, at 03:02, Dmitry Markman wrote:

> if Joachim didn't change xcode project setting
>
> /Developer/SDKs/MacOSX10.4u.sdk is used to build universal binary
>
> so it's quite possible that it won't run properly on 10.2
>
> so we have to change the building process, so ppc part will be built
> with
> /Developer/SDKs/MacOSX10.2.8.sdk
>
> and finally to use lipo utility to build universal binaries
>
> Joachim, did you use some specific locking API that wasn't implemented
>
> in MacOSX10.2.8.sdk?
>
> thanks
>
>
> On Jun 5, 2006, at 4:52 PM, Brian Schlining wrote:
>
>> Hi Dmitry,
>>
>>> I don't think it will be a problem to run universal binary
>>> on 10.2
>>> however if binary has some calls that aren't implemented in 10.2
>>> then you'll have a problem
>>
>> You're right...I stand corrected.
>>
>> Note however, to deploy a universal binary to 10.2 RXTX will need  
>> to use the 10.2 SDK to build the PPC side. (see http:// 
>> developer.apple.com/documentation/DeveloperTools/Conceptual/ 
>> cross_development/UniversalBinaries/chapter_4_section_1.html). I  
>> haven't been paying close attention to the new locking mechanism  
>> used by RXTX on the Mac...does 10.2 support it?
>>
>> Joachim, which SDK will you be using by default for building the  
>> Mac PPC binaries?
>>
>>>> Hi Joachim,
>>>>
>>>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>>>> is no
>>>>> way to compile a universal binary that will work on 10.3 or  
>>>>> before.
>>>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>>>> different build targets for these different targets?? I would  
>>>>> like to
>>>>> get some feedback from the Mac developers on this list  
>>>>> regarding the
>>>>> subject].
>>>>
>>>> I imagine most developers will be compiling on 10.4 (It's the  
>>>> nature of the coder...gotta have the latest and greatest) and  
>>>> deploying to both 10.3 and 10.4; both of which will run  
>>>> Universal Binaries (see http://forums.macrumors.com/ 
>>>> showthread.php?t=205348). So it sounds like you've covered the  
>>>> majority of users. Still, you know someone's going to pipe up  
>>>> about needing RXTX on 10.2 so it would be nice to have a target  
>>>> to make a PPC only build.
>>
>> Brian Schlining
>> Software Engineer
>> http://www.mbari.org
>>
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> Dmitry Markman
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Tue Jun  6 07:01:06 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 6 Jun 2006 15:01:06 +0200
Subject: [Rxtx] Serial port code for OS X, future steps
In-Reply-To: <CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
	<CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
Message-ID: <8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>

I posted the "wrong link". There is a correction here:

    http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00059.html

In fact, the 2.1.7 implementation of RXTX has quite some deficiencies  
on OSX. I have tried to supply some patches that don't interfere to  
much with the existing RXTX code base, but there are limits to what  
can be done with local patches.

There are some very intrusive changes that should be done. Ie proper  
mapping of /dev/tty <-> /dev/cu handling to correct behaviour of  
CommPortOwnershipListener (http://java.sun.com/products/javacomm/ 
reference/api/index.html). I dont think this can be done with  
patches. Hence I think, RXTX should be rewritten from scratch de- 
unifying the native code base (and implementing thread safe code on  
the Java side).


How "should" /dev/tty vs /dev/cu be implemented?

=====
The Unix contract is this: An open /dev/tty.xxx port (incomming)  
should be interrupted/auto-closed when opening /dev/cu.xxx (outgoing)  
[if /dev/tty.xxx is not currently handling a communication].  /dev/ 
cu.xxx and /dev/tty.xxx refer to the same device, so owning  
"exclusively" should block both. This should be respected across all  
applications native or Java.

This contract is realizable on OSX with the existing javax.comm  
interface while also respecting (to the biggest part) the contract  
defined by javax.comm.PortOwnershipListener.

The one point where the suggested implementation "breaks" the  
javax.comm contract, is by the fact that one can loose a /dev/tty  
port without calling close. However, the only option I see is to  
always open serial ports "non-exclusively" which would outrule Java  
as a platform for (dormant) applications waiting for incoming  
connections/faxes/etc. There could be a system property to choose the  
intended behavior.
=====

Here is how it could be done on OSX:

Calling port=ComportIdentifier.open("/dev/cu.xxx") opens and owns the  
port exclusively until port.close() is called.
- Java applications listening with a PortOwnershipListener should get  
a PORT_OWNED event reasonably soon.
- Any further attempt by a Java or native application to open "/dev/ 
cu.xxx" or "/dev/tty.xxx" fails.
- /dev/cu.xxx is for "outgoing" connections, so receiving  
PORT_OWNERSHIP_REQUESTED makes little to no sense. With native  
applications it can not be implemented. For Java applications it  
could be implemented (by a hidden communication channel). I think  
it's not worth bothering. If anyone is willing to give up a port to  
others he should use /dev/tty.xxx instead of /dev/cu.xxx.

Registering a PortOwnershipListener on "/dev/cu.xxx" without opening  
it, uses /dev/tty.xxx (native open()) non-exclusively and polls its  
state. PORT_OWNED and PORT_UNOWNED can be produced.

Calling port=ComportIdentifier.open("/dev/tty.xxx") should open the  
port non-exclusively.
- Adding a SerialPortEventListener and reading from the port could be  
allowed while keeping it non-exclusive.
- When port.getOutputStream() is called, the state should be changed  
to an "exclusive" ownership. This may be configurable via a system  
property.
- To return to the non-exclusive state the port must be closed and  
reopened.
- While non-exclusively opened, opening the corresponding /dev/cu.xxx  
produces a PORT_OWNERSHIP_REQUESTED event. Which should be responded  
by closing the port from within the callback (as described in  
java.comm.PortOwnershipListener). If there is a pending read, it will  
return after the listener finishes (with -1 or "0 bytes read").
- Calling write() on the /dev/tty.xxx after somebody opened /dev/ 
cu.xxx will fail with a descriptive IOException.
- Calling read() on the /dev/tty.xxx after somebody opened /dev/ 
cu.xxx will fail with a descriptive IOException (or potentially  
block, see side notes below).

CommPortIdentifier.getCurrentOwner() can be implemented by an  
external call to lsof.

CommPortIdentifier.isCurrentlyOwned() can be implemented by trying an  
open on the /dev/tty.
- It returns true if the port is currently held "exclusively".
- Whether it should also return true on /dev/tty if /dev/tty is  
already opened non-exclusively might be a system property option. In  
general, having several applications waiting for incoming connections  
on the same port will require an application level "arbitration"  
protocol...

[[side note1: One interesting question is, what happens if the  
process holding /dev/tty non-exclusively ignores  
PORT_OWNERSHIP_REQUESTED. Ie after "loosing" a non-exclusively opened  
"dev/tty.xxx" port to another process. One possible implementation  
is, that the port is "regained" when the other process gives up the  
port. This would mean that in the meanwhile read() returns no data,  
and any changes to the configuration of the port are stored but not  
forwarded. I guess, the safe (and simple) way to do this is to make  
the close() mandatory (ie setting the port into an "awaiting_close"  
state which produces IOExceptions to any other call than close). ]]

[[side note2:  Another interesting question is, what should happen if  
several applications open the same /dev/tty.xxx port "non- 
exclusively" and start to change the settings of the device.]]

Regards,
Joachim



On 06.06.2006, at 10:40, Joachim Buechse wrote:

> Should the code work on 10.2?
> ----------
>
> Absolutely. The code should work on NextStep, in fact on any BSD
> unix. I would go as far as saying, this code should work on any
> POSSIX based unix. All that was added is the call "ioctl(fd,
> TIOCEXCL)" to request excusivity of the port:
>
> http://gemma.apple.com/documentation/DeviceDrivers/Conceptual/
> WorkingWSerial/WWSerial_SerialDevs/chapter_2_section_8.html
>
> It is not yet "the perfect solution". Normally an open /dev/tty
> (listen for incomming connection) should be "preemptable" by opening
> a /dev/cu (outgoing connection) for the same port. This is not yet
> implemented as it needs calls outside of POSSIX on OSX.
>
> On "classic" systems (like NextStep) this worked based on the
> "carried detect line". open() on /dev/tty.xxx would block until the
> carrier detect signal was raised. As the device was not "opened"
> opening /dev/cu.xxx worked without a hitch. When they ported to the
> Mac this broke. On Macs the "carier detect" is usually not wired.
> Furthermore FAX modems did no longer raise the line. So the OSX
> implementor defined a new call, which is documented here:
>
> http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00045.html
>
> Best regards,
> Joachim



From sds at dcs.gla.ac.uk  Tue Jun  6 11:22:45 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Tue, 06 Jun 2006 18:22:45 +0100
Subject: [Rxtx] Correct compile flag for HP iPAQ hx4700 running Familiar
	Linux?
Message-ID: <1149614565.19496.10.camel@addu>

Hi,

I'd like to use RXTX 2.1 on my HP iPAQ hx4700. The iPAQ is running
Familiar Linux 0.8.2 (as I recall), with Blackdown Java 1.3.1.

I can compile and run a test program which uses RXTX on my i686 machine,
and it works fine. But I can't seem to get things working quite right on
my PDA.

I compile the code on the laptop with the following commands:
	./configure --host=arm-gnu-linux && make
... as suggested in a post to this list, albeit some time ago. This
compiles, I transfer the files, set up LD_LIBRARY_PATH and CLASSPATH
variables, and get the following error on the PDA:

sds at ipaq-pxa-2:~# java Test
java.lang.UnsatisfiedLinkError: /usr/local/lib/ext/librxtxSerial.so: /usr/local/lib/ext/librxtxSerial.so: cannot open shared object file: No such file or directory thrown while loading gnu.io.RXTXCommDriver
Exception in thread "main"
java.lang.UnsatisfiedLinkError: /usr/local/lib/ext/librxtxSerial.so: /usr/local/lib/ext/librxtxSerial.so: cannot open shared object file: No such file or directory
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1382)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1290)
        at java.lang.Runtime.loadLibrary0(Runtime.java:749)
        at java.lang.System.loadLibrary(System.java:820)
        at
gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:83)
        at Test.<init>(Test.java:9)
        at Test.main(Test.java:32)
sds at ipaq-pxa-2:~# 

Note that I'm copying the files to /usr/local/lib/ext/ along with the
RXTXcomm.jar file, purely to keep things separate from the rest of the
system while testing. The location of the .so files doesn't seem to have
any bearing on whether "java Test" will succeed or not. The contents of
this directory are:

sds at ipaq-pxa-2:~$ ls /usr/local/lib/ext/
RXTXcomm.jar              librxtxParallel-2.1-7.so  librxtxRS485.so
librxtxSerial-2.1-7.so
librxtxI2C-2.1-7.so       librxtxParallel.so        librxtxRaw-2.1-7.so
librxtxSerial.so
librxtxI2C.so             librxtxRS485-2.1-7.so     librxtxRaw.so
sds at ipaq-pxa-2:~$

Test.java fails on the first real line of code I'm using to test that
things are working, prior to real development, and was carefully pinched
from the web:
Enumeration portIdentifiers = CommPortIdentifier.getPortIdentifiers();


I assume that I've gotten my --host flag wrong way back up there at
the ./configure step. But if that's the case, what should I set it to?
Or am I missing something more obvious?


Cheers,
Stephen Strowes,
University of Glasgow.




From tjarvi at qbang.org  Tue Jun  6 13:39:41 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 6 Jun 2006 13:39:41 -0600 (MDT)
Subject: [Rxtx] Serial port code for OS X, future steps
In-Reply-To: <8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
	<CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
	<8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>
Message-ID: <Pine.LNX.4.61.0606061315070.9856@www>


>>
There are some very intrusive changes that should be done. Ie proper
mapping of /dev/tty <-> /dev/cu handling to correct behaviour of
CommPortOwnershipListener (http://java.sun.com/products/javacomm/
reference/api/index.html). I dont think this can be done with
patches. Hence I think, RXTX should be rewritten from scratch de-
unifying the native code base (and implementing thread safe code on
the Java side).
<<

This appears to be a very small amount of functionality for a total 
rewrite.  The port ownership only needs maybe 3 native calls if it is done 
with native calls at all.

Those features which are not part of the Unix standard(s) can be special 
cased.  I'm not sure /dev/cu is standard.  We can look.  I know linux 
deprecated /dev/cua years ago.

Thread safe Java code is not a platform specific issue.

--
Trent Jarvi
tjarvi at qbang.org


From sds at dcs.gla.ac.uk  Wed Jun  7 12:36:43 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Wed, 07 Jun 2006 19:36:43 +0100
Subject: [Rxtx] Expected RXTX behaviour?
In-Reply-To: <1149703900.30891.19.camel@addu>
References: <1149703900.30891.19.camel@addu>
Message-ID: <1149705403.30891.25.camel@addu>

Apologies, caught the problem. Had to append '\r' to the end of the AT
string. A non obvious but stupid mistake... :-)

Final quick question though: How might I stop the echoing of
outputStream data back into the inputStream? I still see the ATI
commands on the inputStream, along with the output from the device.


Cheers,
S.



On Wed, 2006-06-07 at 19:11 +0100, Stephen Strowes wrote:
> Hi,
> 
> I managed to get RXTX to compile for my iPAQ following my previous post
> to this list. Quick query though:
> 
> I want to be able to issue AT commands to a device, and interpret the
> responses. For this, I assume I do the following, in psuedo-form:
> 
> 	CommPortIdentifier.getPortIdentifiers();
> 	// find the correct device id
> 	serialPort= (SerialPort)portID.open("Test");
> 	// Set parameters and flow control
> 	outputStream= serialPort.getOutputStream();
> 	inputStream=  serialPort.getInputStream();
> 
> ... following this, I spawn a thread to respond to DATA_AVAILABLE events
> on serialPort with inputStream, and occasionally write and flush an
> "ATI" onto the outputStream. Nothing complex, I just want to see it
> work.
> 
> I would have expected inputStream to give the same information back from
> an "ATI" command as minicom provides, but instead inputStream only sees
> the "ATI" I put onto the outputStream.
> 
> Have I missed something?
> 
> 
> Cheers,
> S.
> 



From sds at dcs.gla.ac.uk  Wed Jun  7 12:11:40 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Wed, 07 Jun 2006 19:11:40 +0100
Subject: [Rxtx] Expected RXTX behaviour?
Message-ID: <1149703900.30891.19.camel@addu>

Hi,

I managed to get RXTX to compile for my iPAQ following my previous post
to this list. Quick query though:

I want to be able to issue AT commands to a device, and interpret the
responses. For this, I assume I do the following, in psuedo-form:

	CommPortIdentifier.getPortIdentifiers();
	// find the correct device id
	serialPort= (SerialPort)portID.open("Test");
	// Set parameters and flow control
	outputStream= serialPort.getOutputStream();
	inputStream=  serialPort.getInputStream();

... following this, I spawn a thread to respond to DATA_AVAILABLE events
on serialPort with inputStream, and occasionally write and flush an
"ATI" onto the outputStream. Nothing complex, I just want to see it
work.

I would have expected inputStream to give the same information back from
an "ATI" command as minicom provides, but instead inputStream only sees
the "ATI" I put onto the outputStream.

Have I missed something?


Cheers,
S.




From joachim at buechse.de  Wed Jun  7 09:02:13 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 7 Jun 2006 17:02:13 +0200
Subject: [Rxtx] Update of build process for OSX (XCode project)
Message-ID: <62EC47B1-46BD-4ECA-B9EC-C4061D147CDA@buechse.de>

With the help of Dmitry Markman and Brian Schilling I have updated  
(and largely simplifed) the XCode project file for Mac OS X.

Changes:
- compiles a universal binary library with intel=OSX10.4+, ppc=OSX10.2 
+ support
- compiles the Java sources into a JRE1.1 compatible, compressed jar.

Please test on your configuration, especially if you have computers  
running 10.2/10.3 or intel.

Best regards,
Joachim


From joachim at buechse.de  Wed Jun  7 14:36:37 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 7 Jun 2006 22:36:37 +0200
Subject: [Rxtx] Expected RXTX behaviour?
In-Reply-To: <1149705403.30891.25.camel@addu>
References: <1149703900.30891.19.camel@addu> <1149705403.30891.25.camel@addu>
Message-ID: <D3AD6EAF-27BB-455E-9697-86C1121920C3@buechse.de>

Echoing is a feature of the modem. Try ATE0 which works with most  
"rockwell" compatible modems.

Regards,
Joachim


On 07.06.2006, at 20:36, Stephen Strowes wrote:

> Apologies, caught the problem. Had to append '\r' to the end of the AT
> string. A non obvious but stupid mistake... :-)
>
> Final quick question though: How might I stop the echoing of
> outputStream data back into the inputStream? I still see the ATI
> commands on the inputStream, along with the output from the device.
>
>
> Cheers,
> S.
>
>
>
> On Wed, 2006-06-07 at 19:11 +0100, Stephen Strowes wrote:
>> Hi,
>>
>> I managed to get RXTX to compile for my iPAQ following my previous  
>> post
>> to this list. Quick query though:
>>
>> I want to be able to issue AT commands to a device, and interpret the
>> responses. For this, I assume I do the following, in psuedo-form:
>>
>> 	CommPortIdentifier.getPortIdentifiers();
>> 	// find the correct device id
>> 	serialPort= (SerialPort)portID.open("Test");
>> 	// Set parameters and flow control
>> 	outputStream= serialPort.getOutputStream();
>> 	inputStream=  serialPort.getInputStream();
>>
>> ... following this, I spawn a thread to respond to DATA_AVAILABLE  
>> events
>> on serialPort with inputStream, and occasionally write and flush an
>> "ATI" onto the outputStream. Nothing complex, I just want to see it
>> work.
>>
>> I would have expected inputStream to give the same information  
>> back from
>> an "ATI" command as minicom provides, but instead inputStream only  
>> sees
>> the "ATI" I put onto the outputStream.
>>
>> Have I missed something?
>>
>>
>> Cheers,
>> S.
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From g_petrini at yahoo.it  Thu Jun  8 01:41:58 2006
From: g_petrini at yahoo.it (Giacomo Petrini)
Date: Thu, 8 Jun 2006 09:41:58 +0200 (CEST)
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from FieldTalk
Message-ID: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>

Hi,
I'm evaluating the library for the modbus protocol
from FieldTalk
(http://www.modbusdriver.com/fieldtalk/.
I'm using J2SE 5.0 and RXTX 2.1 on win XP.
The problem is that the modbus lib has a method (the
openProtocol method, but maybe there are others) tha
throws the
javax.comm.UnsupportedCommOperationException.
Now, in RXTX 2.1 the namespace has changed in gnu.io,
so the modbus library doesn't work anymore (it look
for things in javax.comm). I've already sent an email
to fieldtalk to see if they are aware of the problem.
The solution should be to use JavaComm + RXTX 2.0. But
I've read somewhere that JavaComm 2.0 does not work
with Java 5.0 and JavaComm 3.0 does not work with RXTX
2.0 so I don't know what to do.

Any ideas?

Thanks Jack

PS: can you make a CC to my personal email
(g_petrini at yahoo.it) too please?

Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 


From rxtx at tapastda.co.uk  Thu Jun  8 02:27:57 2006
From: rxtx at tapastda.co.uk (rxtx@tapastda.co.uk)
Date: Thu, 08 Jun 2006 09:27:57 +0100
Subject: [Rxtx] Win XP and Infrared based serial port
Message-ID: <4487DF8D.5050807@tapastda.co.uk>

I'm attempting to use RXTX 2.1.7 on Win XP with J2SE 5.0 to communicate with a
GSM mobile using a COM port. A peculiarity that I've seen is that whilst I can
communicate successfully with a mobile which uses an infrared based COM port
using the SUN provided javax.comm (v2.0) I cannot use RXTX because it fails to
read anything from the port (i.e. read timeout always occurs returning zero bytes).

I assumed that this could be the result of flow control problems and thus I've
tried setting either software or hardware based flow control on the port however
this has no affect.

Can you suggest any other port configuration changes which might be required to
make such a port work with RXTX.

Thanks
Stu
-- 
Stuart
Tapastda Limited


From tjarvi at qbang.org  Thu Jun  8 05:17:12 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 8 Jun 2006 05:17:12 -0600 (MDT)
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from
	FieldTalk
In-Reply-To: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
References: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606080504480.9856@www>

On Thu, 8 Jun 2006, Giacomo Petrini wrote:

> Hi,
> I'm evaluating the library for the modbus protocol
> from FieldTalk
> (http://www.modbusdriver.com/fieldtalk/.
> I'm using J2SE 5.0 and RXTX 2.1 on win XP.
> The problem is that the modbus lib has a method (the
> openProtocol method, but maybe there are others) tha
> throws the
> javax.comm.UnsupportedCommOperationException.
> Now, in RXTX 2.1 the namespace has changed in gnu.io,
> so the modbus library doesn't work anymore (it look
> for things in javax.comm). I've already sent an email
> to fieldtalk to see if they are aware of the problem.
> The solution should be to use JavaComm + RXTX 2.0. But
> I've read somewhere that JavaComm 2.0 does not work
> with Java 5.0 and JavaComm 3.0 does not work with RXTX
> 2.0 so I don't know what to do.
>
> Any ideas?
>
> Thanks Jack
>


Hi Jack

There are plans for Sun to rerelease JavaComm 2.0 mentioned in the rxtx 
mail-list archives.  When this happens rxtx will release a current rxtx 
2.0 library that works with it.

There are no dates promised by either side but rxtx will do it as soon as 
possible after Sun's rerelease.  Just to give you a feel for the time 
frame, this started last year and no significant progress has been made. 
There have been friendly talks pointing towards solutions (rerelease 2.0) 
but that does not get your application working today.  rxtx is preparing 
for its second release in gnu.io since then.

--
Trent Jarvi
tjarvi at qbang.org




From jredman at ergotech.com  Thu Jun  8 08:47:23 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 08 Jun 2006 08:47:23 -0600
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from
	FieldTalk
In-Reply-To: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
References: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
Message-ID: <4488387B.6040903@ergotech.com>

You could always try a different library, eg.

http://sourceforge.net/projects/jamod

I've only used the slave side since we have our own implementation of 
Modbus Client (and a host of other PLC protocols).  However the client 
side seems to be pretty well supported and fairly widely used.  Since 
the source is there you could change to gnu.io.

I think I should take more of an interest in this issue.  We generally 
run 1.4.2 on Linux, but also have some J9 and old platforms that we 
support that are basically Personal Java.  5.0 on Linux has some 
horrible MDI bugs, to the point of being unusable.   Sounds as though we 
are going to have code compatibility problems across these platforms.

Jim


Giacomo Petrini wrote:
> Hi,
> I'm evaluating the library for the modbus protocol
> from FieldTalk
> (http://www.modbusdriver.com/fieldtalk/.
> I'm using J2SE 5.0 and RXTX 2.1 on win XP.
> The problem is that the modbus lib has a method (the
> openProtocol method, but maybe there are others) tha
> throws the
> javax.comm.UnsupportedCommOperationException.
> Now, in RXTX 2.1 the namespace has changed in gnu.io,
> so the modbus library doesn't work anymore (it look
> for things in javax.comm). I've already sent an email
> to fieldtalk to see if they are aware of the problem.
> The solution should be to use JavaComm + RXTX 2.0. But
> I've read somewhere that JavaComm 2.0 does not work
> with Java 5.0 and JavaComm 3.0 does not work with RXTX
> 2.0 so I don't know what to do.
> 
> Any ideas?
> 
> Thanks Jack
> 
> PS: can you make a CC to my personal email
> (g_petrini at yahoo.it) too please?
> 
> Chiacchiera con i tuoi amici in tempo reale! 
>  http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  8 18:17:23 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 08 Jun 2006 17:17:23 -0700
Subject: [Rxtx] rxtx access is denied error
Message-ID: <4488BE13.2050706@dupreeinc.com>

Hello,

I have been trying to replace the commapi from sun with rxtx for a 
project that communicates with a serial port that is a USB-Serial 
interface.  To be exact, I am using the FTDI VCP driver with one of 
their modules connected to a windows XP system.

I have the RXTX package working pretty well as long as nothing goes wrong.

If a user disconnects the USB port while my java application is running, 
my application goes into an endless loop with lots of messages in the  
errors stream  like the ones below:

    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(481):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.


I believe when this happens the COM port completely disappears and the 
rxtx driver has a heart attack.  Obviously, the user should not do this, 
but my application needs to ideally, correct the situation or as a worse 
case, terminate with a little dignity.  Currently, I have not figured 
out how to catch this error.

The closest I have come is to trap an exception to my input stream read  
that says "No error in readByte"  This error appears to be outside of 
the endless loop of the errors listed above.

Does anybody have an idea of how to identify and trap this error?  Any 
suggestions on how to gracefully recover from it would be greatly 
appreciated!

Thank you for your time,

Doug Thistlethwaite




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060608/9cfca302/attachment-0018.html

From tjarvi at qbang.org  Thu Jun  8 20:54:17 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 8 Jun 2006 20:54:17 -0600 (MDT)
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <4488BE13.2050706@dupreeinc.com>
References: <4488BE13.2050706@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606082022580.1323@www>

On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I have been trying to replace the commapi from sun with rxtx for a project 
> that communicates with a serial port that is a USB-Serial interface.  To be 
> exact, I am using the FTDI VCP driver with one of their modules connected to 
> a windows XP system.
>
> I have the RXTX package working pretty well as long as nothing goes wrong.
>
> If a user disconnects the USB port while my java application is running, my 
> application goes into an endless loop with lots of messages in the  errors 
> stream  like the ones below:
>
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(481):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>
>
> I believe when this happens the COM port completely disappears and the rxtx 
> driver has a heart attack.  Obviously, the user should not do this, but my 
> application needs to ideally, correct the situation or as a worse case, 
> terminate with a little dignity.  Currently, I have not figured out how to 
> catch this error.
>
> The closest I have come is to trap an exception to my input stream read  that 
> says "No error in readByte"  This error appears to be outside of the endless 
> loop of the errors listed above.
>
> Does anybody have an idea of how to identify and trap this error?  Any 
> suggestions on how to gracefully recover from it would be greatly 
> appreciated!
>

Hi Doug

Sadly I don't have a quick solution for you.

Termios has no knowlage about the JVM so it wont be throwing exceptions 
you can catch.

We can return error and set the error number to something reasonable that 
results in an exception.  The No Error message simply means we did not set 
an error number in termios.c.  Those are the line numbers in the code you 
see.  SerialImp.c realizes it errored but does not know much more yet. 
Everything touching the file descriptor is going to error after the port 
is gone presumably.

We don't currently have a plan in place for vanishing (or appearing) com 
ports.

Another example of what we need to think about is what happens if you 
start your application and then plug in the dongle?  Or what if you unplug 
and then plug it in again?

So in each of these three cases, what would the behavior of the (yet to 
be) correct implementation do?

How will the enumerated ports be handled during these changes?

There can also be hints from the OS that could be taken into 
consideration.

We can probably get some exceptions thrown that make sense and null the 
file descriptor when it happens to prevent io attempts.  That would be a 
crude way to let applications know something strange has happened.

Is anyone else tinkering with this problem?

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  9 01:31:29 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 9 Jun 2006 09:31:29 +0200
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <Pine.LNX.4.61.0606082022580.1323@www>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
Message-ID: <AC6EDDDD-0A64-401F-B16B-E484788CDF4A@buechse.de>

Hello Trent,

I am not tinkering with this on the Source Level - but I think it  
should work pretty much the same way as it currently does in OSX.  
When the port goes away you get an IOException thrown for any read/ 
write. It will no longer be in the list of ports from  
CommPortIdentifier.getPortIdentifiers(). When a port (re-)appears it  
is added to the list. It's up to the application to re-check the list  
from time to time.

On Windows you can't do much better then that, because the ports  
don't have useful names. Which USB "virtual com port" is on which  
COMx depends on the order the devices were added. So reconnecting to  
the same device may mean connecting to another port.

Regarding the exception thrown: it would be nice to use an  
IOException subclass but the Exception message should definetly be  
informative also as most applications may want to keep compatibility  
with javax.comm.

Regards,
Joachim


On 09.06.2006, at 04:54, Trent Jarvi wrote:

> On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:
>
>> Hello,
>>
>> I have been trying to replace the commapi from sun with rxtx for a  
>> project
>> that communicates with a serial port that is a USB-Serial  
>> interface.  To be
>> exact, I am using the FTDI VCP driver with one of their modules  
>> connected to
>> a windows XP system.
>>
>> I have the RXTX package working pretty well as long as nothing  
>> goes wrong.
>>
>> If a user disconnects the USB port while my java application is  
>> running, my
>> application goes into an endless loop with lots of messages in  
>> the  errors
>> stream  like the ones below:
>>
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (481):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>
>>
>> I believe when this happens the COM port completely disappears and  
>> the rxtx
>> driver has a heart attack.  Obviously, the user should not do  
>> this, but my
>> application needs to ideally, correct the situation or as a worse  
>> case,
>> terminate with a little dignity.  Currently, I have not figured  
>> out how to
>> catch this error.
>>
>> The closest I have come is to trap an exception to my input stream  
>> read  that
>> says "No error in readByte"  This error appears to be outside of  
>> the endless
>> loop of the errors listed above.
>>
>> Does anybody have an idea of how to identify and trap this error?   
>> Any
>> suggestions on how to gracefully recover from it would be greatly
>> appreciated!
>>
>
> Hi Doug
>
> Sadly I don't have a quick solution for you.
>
> Termios has no knowlage about the JVM so it wont be throwing  
> exceptions
> you can catch.
>
> We can return error and set the error number to something  
> reasonable that
> results in an exception.  The No Error message simply means we did  
> not set
> an error number in termios.c.  Those are the line numbers in the  
> code you
> see.  SerialImp.c realizes it errored but does not know much more yet.
> Everything touching the file descriptor is going to error after the  
> port
> is gone presumably.
>
> We don't currently have a plan in place for vanishing (or  
> appearing) com
> ports.
>
> Another example of what we need to think about is what happens if you
> start your application and then plug in the dongle?  Or what if you  
> unplug
> and then plug it in again?
>
> So in each of these three cases, what would the behavior of the  
> (yet to
> be) correct implementation do?
>
> How will the enumerated ports be handled during these changes?
>
> There can also be hints from the OS that could be taken into
> consideration.
>
> We can probably get some exceptions thrown that make sense and null  
> the
> file descriptor when it happens to prevent io attempts.  That would  
> be a
> crude way to let applications know something strange has happened.
>
> Is anyone else tinkering with this problem?
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From doug at dupreeinc.com  Fri Jun  9 13:09:58 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 09 Jun 2006 12:09:58 -0700
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <Pine.LNX.4.61.0606082022580.1323@www>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
Message-ID: <4489C786.9050504@dupreeinc.com>


Ideally, it would be nice if it would throw an exception and terminate 
the loop.  I am still trying to figure out how to detect the condition 
and recover form it in some form...  I am getting the "No error in 
readByte" exception in my serialEvent() method after an input stream 
read.  It appears to me that the only graceful recovery is to close the 
port and then reopen it when it becomes available.  I can pass the event 
up to the update method in my main frame, but I still can't close the 
port from within that thread.  Any suggestions on how to pass this event 
to a location where the port can be safely closed?

Re: Slow startup in windows XP
I have been looking into this a little closer and have found out the 
following:
System Windows XP Pro 3GHz dual core with 1GB RAM and NO parallel port.
Starting the SerialDemo included with the commapi using the rxtx instead 
of javax.comm takes 60 seconds.
Starting the SerialDemo using rxrx with the rxtxParallel.dll file 
removed takes about 20 seconds.
Modify initialize in RXRXCommDriver.java to not test the parallel ports 
takes less than 1 second.

It would be nice if the initialize routine could detect the presence of 
rxtxParallel.dll file and just skip the whole process if not present.  
Is there an easy way to check for the presence of this file without 
running the parallel port test?

Doug


 

Trent Jarvi wrote:

>On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:
>...
>  
>
>
>Hi Doug
>
>Sadly I don't have a quick solution for you.
>
>Termios has no knowlage about the JVM so it wont be throwing exceptions 
>you can catch.
>
>We can return error and set the error number to something reasonable that 
>results in an exception.  The No Error message simply means we did not set 
>an error number in termios.c.  Those are the line numbers in the code you 
>see.  SerialImp.c realizes it errored but does not know much more yet. 
>Everything touching the file descriptor is going to error after the port 
>is gone presumably.
>
>We don't currently have a plan in place for vanishing (or appearing) com 
>ports.
>
>Another example of what we need to think about is what happens if you 
>start your application and then plug in the dongle?  Or what if you unplug 
>and then plug it in again?
>
>So in each of these three cases, what would the behavior of the (yet to 
>be) correct implementation do?
>
>How will the enumerated ports be handled during these changes?
>
>There can also be hints from the OS that could be taken into 
>consideration.
>
>We can probably get some exceptions thrown that make sense and null the 
>file descriptor when it happens to prevent io attempts.  That would be a 
>crude way to let applications know something strange has happened.
>
>Is anyone else tinkering with this problem?
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060609/911ed787/attachment-0018.html

From Ugo.Landini at Sun.COM  Fri Jun  2 14:23:47 2006
From: Ugo.Landini at Sun.COM (Ugo Landini)
Date: Fri, 02 Jun 2006 22:23:47 +0200
Subject: [Rxtx] OSX 10.4.7 and usb
Message-ID: <44809E53.2070905@sun.com>

Hi, I have installed the library and the native libraries on OSX 10.4.7. 
Then I have run this simple code:

...
while (portList.hasMoreElements()) {
             portId = (CommPortIdentifier) portList.nextElement();
             System.out.println("-> " + portId.getName() + " Port Type:" 
+ portId.getPortType());
...

and the output is:

Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7

Ports found:
-> /dev/tty.Bluetooth-PDA-Sync Port Type:1
-> /dev/cu.Bluetooth-PDA-Sync Port Type:1
-> /dev/tty.Bluetooth-Modem Port Type:1
-> /dev/cu.Bluetooth-Modem Port Type:1

I can't see any USB ports... with javax.comm on linux I could see the 
/dev/ttyUSB stuff, but that's not the case with OSX. Any idea?

tia

uL


From tod at todbot.com  Sun Jun 11 12:04:37 2006
From: tod at todbot.com (Tod E. Kurt)
Date: Sun, 11 Jun 2006 11:04:37 -0700
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <44809E53.2070905@sun.com>
References: <44809E53.2070905@sun.com>
Message-ID: <E2EB14A1-20A7-4611-8F1A-E3D2ABE41F48@todbot.com>

A dumb question, but: do you have the USB serial adapters plugged  
in?  They only show up in /dev when plugged in.  Also, you can verify  
they exist independent of RXTX by doing something like "ls -l /dev/ 
cu.*".

On Jun 2, 2006, at 1:23 PM, Ugo Landini wrote:

> Hi, I have installed the library and the native libraries on OSX  
> 10.4.7.
> Then I have run this simple code:
>
> ...
> while (portList.hasMoreElements()) {
>              portId = (CommPortIdentifier) portList.nextElement();
>              System.out.println("-> " + portId.getName() + " Port  
> Type:"
> + portId.getPortType());
> ...
>
> and the output is:
>
> Experimental:  JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
>
> Ports found:
> -> /dev/tty.Bluetooth-PDA-Sync Port Type:1
> -> /dev/cu.Bluetooth-PDA-Sync Port Type:1
> -> /dev/tty.Bluetooth-Modem Port Type:1
> -> /dev/cu.Bluetooth-Modem Port Type:1
>
> I can't see any USB ports... with javax.comm on linux I could see the
> /dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>
> tia
>
> uL
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>



From lyon at docjava.com  Sun Jun 11 12:14:50 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Sun, 11 Jun 2006 14:14:50 -0400
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <44809E53.2070905@sun.com>
References: <44809E53.2070905@sun.com>
Message-ID: <p06020444c0b20de7d248@[192.168.1.152]>

>Hi Ugo,

Do you have any USB serial ports (like the keyspan 19-HS) plugged
into the mac?
Thanks!
  - DL


>Hi, I have installed the library and the native libraries on OSX 10.4.7.
>Then I have run this simple code:
>
>...
>while (portList.hasMoreElements()) {
>              portId = (CommPortIdentifier) portList.nextElement();
>              System.out.println("-> " + portId.getName() + " Port Type:"
>+ portId.getPortType());
>...
>
>and the output is:
>
>Experimental:  JNI_OnLoad called.
>Stable Library
>=========================================
>Native lib Version = RXTX-2.1-7
>Java lib Version   = RXTX-2.1-7
>
>Ports found:
>-> /dev/tty.Bluetooth-PDA-Sync Port Type:1
>-> /dev/cu.Bluetooth-PDA-Sync Port Type:1
>-> /dev/tty.Bluetooth-Modem Port Type:1
>-> /dev/cu.Bluetooth-Modem Port Type:1
>
>I can't see any USB ports... with javax.comm on linux I could see the
>/dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>
>tia
>
>uL
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx



From dmarkman at mac.com  Sun Jun 11 14:30:27 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Sun, 11 Jun 2006 16:30:27 -0400
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <p06020444c0b20de7d248@[192.168.1.152]>
References: <44809E53.2070905@sun.com> <p06020444c0b20de7d248@[192.168.1.152]>
Message-ID: <B9C1606B-4339-4564-A175-FE83DFFA7D76@mac.com>

afaik
10.4.7 wasn't released yet
it will soon, no doubts


On Jun 11, 2006, at 2:14 PM, Dr. Douglas Lyon wrote:

>> Hi Ugo,
>
> Do you have any USB serial ports (like the keyspan 19-HS) plugged
> into the mac?
> Thanks!
>   - DL
>
>
>> Hi, I have installed the library and the native libraries on OSX  
>> 10.4.7.
>> Then I have run this simple code:
>>
>> ...
>> while (portList.hasMoreElements()) {
>>              portId = (CommPortIdentifier) portList.nextElement();
>>              System.out.println("-> " + portId.getName() + " Port  
>> Type:"
>> + portId.getPortType());
>> ...
>>
>> and the output is:
>>
>> Experimental:  JNI_OnLoad called.
>> Stable Library
>> =========================================
>> Native lib Version = RXTX-2.1-7
>> Java lib Version   = RXTX-2.1-7
>>
>> Ports found:
>> -> /dev/tty.Bluetooth-PDA-Sync Port Type:1
>> -> /dev/cu.Bluetooth-PDA-Sync Port Type:1
>> -> /dev/tty.Bluetooth-Modem Port Type:1
>> -> /dev/cu.Bluetooth-Modem Port Type:1
>>
>> I can't see any USB ports... with javax.comm on linux I could see the
>> /dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>>
>> tia
>>
>> uL
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman



From tjarvi at qbang.org  Sun Jun 11 18:52:59 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 11 Jun 2006 18:52:59 -0600 (MDT)
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <4489C786.9050504@dupreeinc.com>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
	<4489C786.9050504@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606111845430.7274@www>

On Fri, 9 Jun 2006, Doug Thistlethwaite wrote:

>
> Ideally, it would be nice if it would throw an exception and terminate the 
> loop.  I am still trying to figure out how to detect the condition and 
> recover form it in some form...  I am getting the "No error in readByte" 
> exception in my serialEvent() method after an input stream read.  It appears 
> to me that the only graceful recovery is to close the port and then reopen it 
> when it becomes available.  I can pass the event up to the update method in 
> my main frame, but I still can't close the port from within that thread.  Any 
> suggestions on how to pass this event to a location where the port can be 
> safely closed?
>

I've gone through and cleaned up the termios.c layer.  I need to get to a 
windows machine with a USB dongle and see where the ioctl() is being 
called.  Probably the eventLoop.  But all of the ioctls should probably 
result in an IOException during this condition.

I'll probably finish this up Monday night when I can borrow a USB 
dongle.

There is no point in putting the code into CVS yet.  If you are tinkering 
I can mail the patch.  I think we will want to make a couple fixes in 
SerialImp.c to handle errors before it's ready.

--
Trent Jarvi
tjarvi at qbang.org



From bob_tai2001 at yahoo.com  Mon Jun 12 09:42:14 2006
From: bob_tai2001 at yahoo.com (Bob Tai)
Date: Mon, 12 Jun 2006 08:42:14 -0700 (PDT)
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to RXTX
	again
Message-ID: <20060612154214.58219.qmail@web32804.mail.mud.yahoo.com>


thank you Paul, Joachim, Trent and everyone try to
workout the java comm and Rxtx situation.  At least
now I have something that is solid enough to make my
decision.  

thank you,
     Bob

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From Ralph.Buchfelder at gmx.net  Mon Jun 12 15:30:20 2006
From: Ralph.Buchfelder at gmx.net (Ralph Buchfelder)
Date: Mon, 12 Jun 2006 23:30:20 +0200
Subject: [Rxtx] rxtx binaries or porting to XSCALE Windows Mobile 2003 / 2005
Message-ID: <448DDCEC.7090506@gmx.net>

dear group,

i have been carefully reading your homepage, wiki and archives
but there seems to be no detailled information on porting to Windows 
Mobile/CE.

as far as i understood from the 'porting' section you can do porting to 
winCE. but how? do i only need to obtain the sourcecode (which one?) and 
compile this in Microsoft eMbedded Visual C++ for ARM/Xscale?
Any other ways?


unfortunately i must admit that i do have little linux skills but i have 
made my way through gcc and makefiles. right now i need to implement com 
  communication in a J2ME application and found your website as >the< 
solution.

best regards
Ralph Buchfelder

University of Regensburg
Department of Geography

PS: i dont care about Javacomm compliancy (ie. 2.0 or 2.1) - i just need 
a working serial port API in IBM J9 VM.


From paul.klissner at sun.com  Wed Jun 14 18:12:58 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Wed, 14 Jun 2006 17:12:58 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
Message-ID: <4490A60A.9090305@sun.com>

Hello RxTx community,

I finally think I have a compromise in place that will stand in the gap.

If you go to http://www.sun.com and search for javax.comm, you'll
get taken to a download page, where now users can get a copy of the
comm.jar file out of 2.0.3, along with just a license and a README.

I trust this will suffice until such time as RxTx decided to implement
their own java classes or we can get a JSR going to mitigate some
of the problems (the readme in the comm.jar 2.0.3 zip file
contains my thoughts on that).

Thanks,
Paul



From tjarvi at qbang.org  Wed Jun 14 21:15:35 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 14 Jun 2006 21:15:35 -0600 (MDT)
Subject: [Rxtx] rxtx-2.0-7 (final) src is in CVS
Message-ID: <Pine.LNX.4.61.0606142100500.2742@www>


I wasn't expecting to be working on rxtx 2.0 tonight :)

Thanks go out to Paul Klissner for his work in making the coming release 
of rxtx-2.0-7 possible for users that require package javax.comm on many 
platforms.

Most people know that rxtx 2.0 is for use with Sun's CommAPI 2.0 for 
Solaris or the Generic CommAPI 2.0-3 available for download at Sun.  If 
you need javax.comm packages on many platforms, you are probably 
interested.  If you use rxtx 2.1 in package gnu.io, then you are not going 
to care much.

I've tried to update the rxtx 2.0 src directory in preparation for 
rxtx-2.0-7 (final).  Linux should compile.  Windows will compile if you 
generate your own .def files (I'll generate these tomorrow).  If you have 
some time to do basic testing of the source, I'd appreciate it.  The 
source should be good but you may find classes not found.  This source is 
a backport from rxtx 2.1.

I wanted to get things started so anyone interested on Mac OS X could get 
a head start.

All of this is in CVS.  http://www.rxtx.org/cvs.html

I suspect we will have binaries for testing in a couple days if you are 
unable to compile.   Consider this a smoke test.

--
Trent Jarvi
tjarvi at qbang.org


From legolas.w at gmail.com  Wed Jun 14 22:04:28 2006
From: legolas.w at gmail.com (Legolas Woodland)
Date: Wed, 14 Jun 2006 21:04:28 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <4490A60A.9090305@sun.com>
References: <4490A60A.9090305@sun.com>
Message-ID: <87ee9b170606142104p745fcef0vea622fbc8f528bfc@mail.gmail.com>

is there anything new in this version of javax.comm ?
thanks


On 6/14/06, Paul Klissner <paul.klissner at sun.com> wrote:
>
> Hello RxTx community,
>
> I finally think I have a compromise in place that will stand in the gap.
>
> If you go to http://www.sun.com and search for javax.comm, you'll
> get taken to a download page, where now users can get a copy of the
> comm.jar file out of 2.0.3, along with just a license and a README.
>
> I trust this will suffice until such time as RxTx decided to implement
> their own java classes or we can get a JSR going to mitigate some
> of the problems (the readme in the comm.jar 2.0.3 zip file
> contains my thoughts on that).
>
> Thanks,
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060614/5ff4dfbc/attachment-0018.html

From joachim at buechse.de  Thu Jun 15 07:22:48 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 15 Jun 2006 15:22:48 +0200
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
Message-ID: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>

Good day!

Some of my users report problems using RXTX 2.1.7 on Windows98 to  
communicate with an FTDI FT245BM chip (using their latest VCP  
driver). Either no ports are being shown (ie returned form  
CommPortIdentifier.getPortIdentifiers()) or the transfers fail.

Did anyone run into similar Problems with Win98??

Best regards,
Joachim



From ajmas at sympatico.ca  Thu Jun 15 08:12:28 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Thu, 15 Jun 2006 10:12:28 -0400
Subject: [Rxtx] API change question
Message-ID: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

How closely do you follow the Java Communication API spec? The reason I ask is because I would be interested in augmenting the CommPortIdentifier class to include a getDisplayName() method. By default it would return the same value as getName(), but would provide the possibility of displaying a 'user friendly' name, for platforms where the display name is not the same as the device name. An example of this is on MacOS X, where currently the names seem to be of the form /dev/cu.* and /dev/tty.*, yet what the expects to see is simply the part after the full-stop. Although I could move this logic into the Java code, it would be nice to see it transparent to the Java code.

Andre




From ajmas at sympatico.ca  Thu Jun 15 08:16:22 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Thu, 15 Jun 2006 10:16:22 -0400
Subject: [Rxtx] Package to use
Message-ID: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

While the Java API spec refers to javax.comm, I see that only gnu.io is provide by the rxtx project. Should our projects refer to the gnu.io package or the javax.comm API?

Andre



From joachim at buechse.de  Thu Jun 15 08:45:05 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 15 Jun 2006 16:45:05 +0200
Subject: [Rxtx] API change question
In-Reply-To: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>

Hello Andre,

the /dev/cu and /dev/tty have different semantics on OS X. It is much  
more than a simply naming issue to unify them, see my recent mail to  
the list...

Best regards,
Joachim


On 15.06.2006, at 16:12, Andre-John Mas wrote:

> Hi,
>
> How closely do you follow the Java Communication API spec? The  
> reason I ask is because I would be interested in augmenting the  
> CommPortIdentifier class to include a getDisplayName() method. By  
> default it would return the same value as getName(), but would  
> provide the possibility of displaying a 'user friendly' name, for  
> platforms where the display name is not the same as the device  
> name. An example of this is on MacOS X, where currently the names  
> seem to be of the form /dev/cu.* and /dev/tty.*, yet what the  
> expects to see is simply the part after the full-stop. Although I  
> could move this logic into the Java code, it would be nice to see  
> it transparent to the Java code.
>
> Andre
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From lyon at docjava.com  Thu Jun 15 10:16:29 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Thu, 15 Jun 2006 12:16:29 -0400
Subject: [Rxtx] cu.modem != /dev/ttya on mac.
In-Reply-To: <763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
	<763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>
Message-ID: <p0602046cc0b7378a95b0@[192.168.1.152]>

>Hi All,

I think that Joachim is correct. For the longest time,
I have been trying to figure out how to direct dial using
the cu.modem on the mac under os x.

As a less-than-optimal approach to auto-dialing, I have used
a keyspan USB 19HS adapter, along with an external modem, to
obtain the dialing feature.

Ideally, it would be better to dial with the built-in modem...but that did not
always seem to work, for some reason. Have others had some experience with
using the built in modem for dialing on the mac?

Thanks!
  - Doug


>Hello Andre,
>
>the /dev/cu and /dev/tty have different semantics on OS X. It is much?
>more than a simply naming issue to unify them, see my recent mail to?
>the list...
>
>Best regards,
>Joachim
>



From doug at dupreeinc.com  Thu Jun 15 14:52:50 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 15 Jun 2006 13:52:50 -0700
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
In-Reply-To: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
References: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
Message-ID: <4491C8A2.8090108@dupreeinc.com>

Hi Joachim,

I have been doing a lot with the new FTDI driver with win XP and have 
not had that particular problem.  I did notice that the new driver 
(dated May19th, 2006) is only for XP, Server 2003, and 2000.  Are they 
trying to use the 2.00.00 drivers or the old 1.09.06 version.  I am 
using a FT232R based module, but it uses the same drivers and I assume 
it would have the same problems.  Let me know which driver they are 
using and I can load up a 98 system here and see if  I can duplicate the 
problem.

Doug

Joachim Buechse wrote:

>Good day!
>
>Some of my users report problems using RXTX 2.1.7 on Windows98 to  
>communicate with an FTDI FT245BM chip (using their latest VCP  
>driver). Either no ports are being shown (ie returned form  
>CommPortIdentifier.getPortIdentifiers()) or the transfers fail.
>
>Did anyone run into similar Problems with Win98??
>
>Best regards,
>Joachim
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From matthewhepp at yahoo.com  Thu Jun 15 17:34:47 2006
From: matthewhepp at yahoo.com (Matthew Hepp)
Date: Thu, 15 Jun 2006 16:34:47 -0700 (PDT)
Subject: [Rxtx] Wither the XCode project?
Message-ID: <20060615233447.48064.qmail@web50311.mail.yahoo.com>

Either I don't know how to properly use CVS (entirely possibl), or the XCode
project is not making through the update properly. Doing a "cvs update" against
2.1-7 creates an XCode folder in MACOSX_IDE, and therein a
LibSerialUniversal.xcodeproj, but trying to open it yields a "Unable to Open
Project - Project rxtx-devel/MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj
cannot be opened because it is missing its project.pbxproj file" error. Showing
package contents reveals just the cvs-related files. Perhaps this is why
previous xcode projects have been saved as an sit.hqx - to retain the resource
fork?

Can someone point me in the right direction?

Thanks,

Matt

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Thu Jun 15 19:53:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 19:53:06 -0600 (MDT)
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
In-Reply-To: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
References: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
Message-ID: <Pine.LNX.4.61.0606151944070.23137@www>

On Thu, 15 Jun 2006, Joachim Buechse wrote:

> Good day!
>
> Some of my users report problems using RXTX 2.1.7 on Windows98 to
> communicate with an FTDI FT245BM chip (using their latest VCP
> driver). Either no ports are being shown (ie returned form
> CommPortIdentifier.getPortIdentifiers()) or the transfers fail.
>
> Did anyone run into similar Problems with Win98??
>

Hi Joachim

It has been a long time since I've tested win98.  I know rxtx-2.1-7pre16 
did get testing on win98 with ~jdk 1.3 though.  I wonder if jdks are still 
tested on that platform.

With win98 you usually have older boxes.  They can be short on CPU and 
memory.  Enumeration should work but I could picture runtime performance 
issues on win98.

The enumeration problems could result from other copies of your 
application if various states of decay still holding onto the port.  When 
things go wrong, people also like to open other terminal software to see 
whats going on which can interfere.  You can't open a windows port with 
two apps.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Thu Jun 15 20:08:53 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 20:08:53 -0600 (MDT)
Subject: [Rxtx] API change question
In-Reply-To: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606151954270.23137@www>

On Thu, 15 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> How closely do you follow the Java Communication API spec?

I can explain how this worked in the past.  How we do it in the future is 
open for discussion.

In the past we have tried to follow it as close as possible in gnu.io 
(rxtx 2.1).  We have added extensions but try to discourage their use. 
The extensions are clearly marked as such in the source code and javadocs.

rxtx 2.0 was intended to be a strict implementation of part of the spec. 
We let Sun's interfaces decide what methods can be called. There are 
differences not covered by the spec such as default values.  Thats not 
intentional but rather hard to avoid.

--
Trent Jarvi
tjarvi at qbang.org





From tjarvi at qbang.org  Thu Jun 15 21:09:11 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 21:09:11 -0600 (MDT)
Subject: [Rxtx] Package to use
In-Reply-To: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606152026120.23137@www>

On Thu, 15 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> While the Java API spec refers to javax.comm, I see that only gnu.io is 
> provide by the rxtx project. Should our projects refer to the gnu.io 
> package or the javax.comm API?
>

Hi Andre

Lets see if I can give a fair and balanced answer to that.

If you are starting a new project and want to use RXTX, I would recommend 
using gnu.io.  The community support for gnu.io will not be going away 
anytime soon.  You can switch between gnu.io (2.1) and javax.comm (2.0) 
fairly easily.  They are not intended to be incompatible.  You just change 
package names and libs.

You can also consider the combination of rxtx 2.0 with Sun's commapi 
2.0-3.  This is considered a stop-gap measure by Sun for previous users of 
that combination.  Together rxtx 2.0 and Sun CommAPI 2.0 work in namespace 
javax.comm for programmers.

Finally, you can opt to just use Sun's oferrings in CommAPI 3.0 without 
rxtx.  That would be in namespace javax.comm also.  CommAPI 3.0 may be 
of more interest to you if you are looking at POS with Sun computers. 
Rxtx does not currently support the changes in CommAPI 3.0 or have firm 
plans to do so.  That does not mean we wouldn't implement them.  It just 
means nobody has contributed code yet.

You can't combine rxtx with CommAPI 3.0 for technical reasons that wont 
likely be fixed soon.

It's up to you as far as what you use.  We like to provide the freedom so 
you can choose.  Realistically, we will be supporting gnu.io mainly 
because we have some control over that name space and can support it.

Things may happen in the future that enable rxtx to provide more support 
in the javax namespace but that has not happened yet.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun 16 00:33:06 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 08:33:06 +0200
Subject: [Rxtx] Wither the XCode project?
In-Reply-To: <20060615233447.48064.qmail@web50311.mail.yahoo.com>
References: <20060615233447.48064.qmail@web50311.mail.yahoo.com>
Message-ID: <D30D660F-A49B-464E-AE4C-6B4563893682@buechse.de>

Hello Matthew,

could you please send me the contents of your

   rxtx-devel/CVS
   rxtx-devel/MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj/CVS

directories as a zip to my personal email address. This should  
indicate why the file is not checked out. I can see that it exists on  
the correct branch in the repository, so something must have gone  
wrong during the "cvs update"...

Best regards,
Joachim

On 16.06.2006, at 01:34, Matthew Hepp wrote:

> Either I don't know how to properly use CVS (entirely possibl), or  
> the XCode
> project is not making through the update properly. Doing a "cvs  
> update" against
> 2.1-7 creates an XCode folder in MACOSX_IDE, and therein a
> LibSerialUniversal.xcodeproj, but trying to open it yields a  
> "Unable to Open
> Project - Project rxtx-devel/MACOSX_IDE/XCode/ 
> LibSerialUniversal.xcodeproj
> cannot be opened because it is missing its project.pbxproj file"  
> error. Showing
> package contents reveals just the cvs-related files. Perhaps this  
> is why
> previous xcode projects have been saved as an sit.hqx - to retain  
> the resource
> fork?
>
> Can someone point me in the right direction?



From joachim at buechse.de  Fri Jun 16 10:41:20 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 18:41:20 +0200
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <p06230903c0b88613dca6@[10.0.1.7]>
References: <p06230903c0b88613dca6@[10.0.1.7]>
Message-ID: <03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>

Hello Bob,

until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was  
behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if  
Trent has migrated all recent changes from 2.1 to 2.0.

I have added the XCode project and updated documentation only to the  
gnu.io branch. Once the 2.0 implementation is up to date I will copy  
over the documentation/build files make them work.

Best regards,
Joachim

On 16.06.2006, at 18:07, Bob Jacobsen wrote:

> I'm one of the developers for the JMRI project, which provides  
> model railroad software in Java.  We've been using RXTX to provide  
> serial port access on MacOS X and Linux; we use the old javax.comm  
> 2.0 on Windows, OS/2 and Solaris.  Because of that, we need to stay  
> with RXTX 2.0, not 2.1
>
> We've been using the 2.0-pre17 installer for a long time, but it's  
> not compatible with Intel macs.
>
> Can you point me to where I can find the right files for RXTX 2.0  
> to package with the program?
>
> The current situation is confusing to me.  I've been pointed to  
> recent 2.1 versions (but we need the javax.comm names), to an even  
> older installer, etc.  I've been reading that some versions require  
> an installer, and others don't, but I haven't been able to figure  
> out which (if any) of those are where in CVS.
>
> I'd really appreciate a clear statement of what files to use and  
> what to do with them that I can pass on to our users.
>
> I'm more than happy to put files in the local classpath, have users  
> run an installer, or anything else.  Whatever is easiest for you.
>
> Thanks!  I really appreciate all that you do to keep RXTX working.
>
> Bob
> -- 
> Bob Jacobsen +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG



From joachim at buechse.de  Fri Jun 16 09:59:28 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 17:59:28 +0200
Subject: [Rxtx] Wither the XCode project?
In-Reply-To: <20060616150240.49464.qmail@web50309.mail.yahoo.com>
References: <20060616150240.49464.qmail@web50309.mail.yahoo.com>
Message-ID: <D9935E05-2B83-488D-86DD-42599E229052@buechse.de>

Hello Matthew,

you have checked out the trunk (which is the 2.0.7 javax.comm.xxx  
release). For rxtx-2.1.7 (gnu.io.xxx release) you need to check out  
the branch

      commapi-0-0-1

The easiest way to do this is to download the rxtx src archive,  
unpack it and then do a cvs up inside the decompressed tree.  
Optionally you could do a

      cvs co -r commapi-0-0-1

but this will take much longer!

Best regards,
Joachim

When you do a cvs status it will show the sticky tag.

41:~/jdevelop/rxtx-2.1-7r2 joachim$ cvs status README.OSX
===================================================================
File: README.OSX        Status: Up-to-date

    Working revision:    1.1.2.1
    Repository revision: 1.1.2.1 /usr/local/cvsroot/rxtx-devel/Attic/ 
README.OSX,v
    Sticky Tag:          commapi-0-0-1 (branch: 1.1.2)
    Sticky Date:         (none)
    Sticky Options:      (none)




On 16.06.2006, at 17:02, Matthew Hepp wrote:

> %cvs status README.MACOSX
> ===================================================================
> File: README.MACOSX     Status: Up-to-date
>
>    Working revision:    1.1
>    Repository revision: 1.1     /usr/local/cvsroot/rxtx-devel/ 
> README.MACOSX,v
>    Sticky Tag:          (none)
>    Sticky Date:         (none)
>    Sticky Options:      (none)



From tjarvi at qbang.org  Fri Jun 16 16:31:18 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Fri, 16 Jun 2006 16:31:18 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
Message-ID: <Pine.LNX.4.61.0606161630030.14139@www>

On Fri, 16 Jun 2006, Joachim Buechse wrote:

> Hello Bob,
>
> until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was
> behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if
> Trent has migrated all recent changes from 2.1 to 2.0.
>

The src/ directory and configure.in/configure files should be fine.  I 
have not touched the Mac OS X directories.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sat Jun 17 02:39:55 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sat, 17 Jun 2006 10:39:55 +0200
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <Pine.LNX.4.61.0606161630030.14139@www>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
Message-ID: <350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>

Hello Trent,

apparently the IOEXCL changes have not made it into 2.0. I will add  
them to achieve a minimal diff between 2.0 and 2.1.

One other thing that bugs me for a while...

Shouldn't we replace "if !defined(TIOCSERGETLSR) && !defined(WIN32)"  
by a definition of its own "if defined(DRAINTHREAD)"? I think this  
would make the code clearer for people starting to read it.

Regards,
Joachim


On 17.06.2006, at 00:31, Trent Jarvi wrote:

> On Fri, 16 Jun 2006, Joachim Buechse wrote:
>
>> Hello Bob,
>>
>> until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was
>> behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if
>> Trent has migrated all recent changes from 2.1 to 2.0.
>>
>
> The src/ directory and configure.in/configure files should be fine.  I
> have not touched the Mac OS X directories.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From tropicsu at hotmail.com  Sat Jun 17 09:32:48 2006
From: tropicsu at hotmail.com (Yoke K)
Date: Sat, 17 Jun 2006 15:32:48 +0000
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
Message-ID: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>

Hi,

I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to work with 
MAC OS X.
I am using iTegno 3000 - USB GPRS Modem.

Files in /dev and a symbolic link as follows:

crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 -> tty.usbserial

In my SendMessage.java, I have this line:
CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");

Appreciate any help ?

- Jon


Errors as follows:

>>INFO: SMSLib API for Java / v1.2.2
>>INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>INFO: JRE Version: 1.5.0_06
>>INFO: JRE Impl Version: 1.5.0_06-64
>>INFO: O/S: Mac OS X / ppc / 10.4.6
>>INFO: Using Wavecom (Generic) AT handler.

SendMessage(): Send a message.
  Using SMSLib API for Java v1.2.2

Connecting ..... :
>>INFO: CSerialDriver(): Connecting...
Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
>>INFO: CSerialDriver(): Disconnecting...
gnu.io.NoSuchPortException
        at 
gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:218)
        at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
        at org.smslib.CService.connect(CService.java:197)
        at SendMessage.main(SendMessage.java:38)

_________________________________________________________________
Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/



From tjarvi at qbang.org  Sat Jun 17 10:12:30 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 10:12:30 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
	<350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
Message-ID: <Pine.LNX.4.61.0606171010060.14139@www>

On Sat, 17 Jun 2006, Joachim Buechse wrote:

> Hello Trent,
>
> apparently the IOEXCL changes have not made it into 2.0. I will add
> them to achieve a minimal diff between 2.0 and 2.1.
>

Hi Joachim

As I recall the IOEXCL change was after 2.1-7.  I was just syncing with 
2.1-7.  We can release 2.1-8 and 2.0-8 with the same changes.

> One other thing that bugs me for a while...
>
> Shouldn't we replace "if !defined(TIOCSERGETLSR) && !defined(WIN32)"
> by a definition of its own "if defined(DRAINTHREAD)"? I think this
> would make the code clearer for people starting to read it.
>


Sure.  We can do that for -8.  The TIOCSERGETLSR code should be a special 
case not the expected.  I think only Linux uses it.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Sat Jun 17 10:48:21 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 10:48:21 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <Pine.LNX.4.61.0606171010060.14139@www>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
	<350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
	<Pine.LNX.4.61.0606171010060.14139@www>
Message-ID: <Pine.LNX.4.61.0606171047310.14139@www>

On Sat, 17 Jun 2006, Trent Jarvi wrote:

> On Sat, 17 Jun 2006, Joachim Buechse wrote:
>
>> Hello Trent,
>>
>> apparently the IOEXCL changes have not made it into 2.0. I will add
>> them to achieve a minimal diff between 2.0 and 2.1.
>>
>
> Hi Joachim
>
> As I recall the IOEXCL change was after 2.1-7.  I was just syncing with
> 2.1-7.  We can release 2.1-8 and 2.0-8 with the same changes.
>

We could just move to 2.1-8 and 2.0-8.

--
Trent Jarvi
tjarvi at qbang.org


From brian.t.lamb at gmail.com  Tue Jun 13 13:54:13 2006
From: brian.t.lamb at gmail.com (Brian Lamb)
Date: Tue, 13 Jun 2006 15:54:13 -0400
Subject: [Rxtx] Windows XP Installation
Message-ID: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>

I've not installed Java packages on Windows before and am unsure how to
proceed. All the documentation I've seen provides detailed instructions on
how to install on Linux or Solaris. I was wondering how to install rxtx on
Windows XP.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060613/6f68cd5c/attachment-0018.html

From tjarvi at qbang.org  Sat Jun 17 13:57:03 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 13:57:03 -0600 (MDT)
Subject: [Rxtx] Windows XP Installation
In-Reply-To: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>
References: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0606171356120.14139@www>

On Tue, 13 Jun 2006, Brian Lamb wrote:

> I've not installed Java packages on Windows before and am unsure how to
> proceed. All the documentation I've seen provides detailed instructions on
> how to install on Linux or Solaris. I was wondering how to install rxtx on
> Windows XP.
>

Hi Brian

Which rxtx version are you trying to install?

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sun Jun 18 10:41:44 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sun, 18 Jun 2006 18:41:44 +0200
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
References: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
Message-ID: <8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>

Hello Jon,

 From OSX's standpoint a symbolic link is not a device (as far as I  
know). What stops you from using tty.usbserial? Did you try hard- 
linking?

Regards,
Joachim

On 17.06.2006, at 17:32, Yoke K wrote:
> Hi,
>
> I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to  
> work with
> MAC OS X.
> I am using iTegno 3000 - USB GPRS Modem.
>
> Files in /dev and a symbolic link as follows:
>
> crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
> crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
> lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->  
> tty.usbserial
>
> In my SendMessage.java, I have this line:
> CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
>
> Appreciate any help ?
>
> - Jon
>
>
> Errors as follows:
>
>>> INFO: SMSLib API for Java / v1.2.2
>>> INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>> INFO: JRE Version: 1.5.0_06
>>> INFO: JRE Impl Version: 1.5.0_06-64
>>> INFO: O/S: Mac OS X / ppc / 10.4.6
>>> INFO: Using Wavecom (Generic) AT handler.
>
> SendMessage(): Send a message.
>   Using SMSLib API for Java v1.2.2
>
> Connecting ..... :
>>> INFO: CSerialDriver(): Connecting...
> Experimental:  JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
>>> INFO: CSerialDriver(): Disconnecting...
> gnu.io.NoSuchPortException
>         at
> gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java: 
> 218)
>         at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
>         at org.smslib.CService.connect(CService.java:197)
>         at SendMessage.main(SendMessage.java:38)
>
> _________________________________________________________________
> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Sun Jun 18 10:56:55 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 12:56:55 -0400
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>
References: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
	<8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>
Message-ID: <7B6834E3-F41D-46B6-B979-55466BC73859@sympatico.ca>

Have you been able to get any other software to talk with your
modem? What port is it using? Have tried using the cu.usbserial
instead?

Andre

On 18-Jun-06, at 12:41 , Joachim Buechse wrote:

> Hello Jon,
>
>  From OSX's standpoint a symbolic link is not a device (as far as I
> know). What stops you from using tty.usbserial? Did you try hard-
> linking?
>
> Regards,
> Joachim
>
> On 17.06.2006, at 17:32, Yoke K wrote:
>> Hi,
>>
>> I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to
>> work with
>> MAC OS X.
>> I am using iTegno 3000 - USB GPRS Modem.
>>
>> Files in /dev and a symbolic link as follows:
>>
>> crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
>> crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
>> lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->
>> tty.usbserial
>>
>> In my SendMessage.java, I have this line:
>> CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
>>
>> Appreciate any help ?
>>
>> - Jon
>>
>>
>> Errors as follows:
>>
>>>> INFO: SMSLib API for Java / v1.2.2
>>>> INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>>> INFO: JRE Version: 1.5.0_06
>>>> INFO: JRE Impl Version: 1.5.0_06-64
>>>> INFO: O/S: Mac OS X / ppc / 10.4.6
>>>> INFO: Using Wavecom (Generic) AT handler.
>>
>> SendMessage(): Send a message.
>>   Using SMSLib API for Java v1.2.2
>>
>> Connecting ..... :
>>>> INFO: CSerialDriver(): Connecting...
>> Experimental:  JNI_OnLoad called.
>> Stable Library
>> =========================================
>> Native lib Version = RXTX-2.1-7
>> Java lib Version   = RXTX-2.1-7
>>>> INFO: CSerialDriver(): Disconnecting...
>> gnu.io.NoSuchPortException
>>         at
>> gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:
>> 218)
>>         at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
>>         at org.smslib.CService.connect(CService.java:197)
>>         at SendMessage.main(SendMessage.java:38)
>>
>> _________________________________________________________________
>> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Sun Jun 18 17:33:08 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 19:33:08 -0400
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
Message-ID: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>

Hi,

I am have a program that I wrote in Java to communicate with a  
Bluetooth GPS device. I am
trying to get this working on my Mac, but I keep getting told that:

gnu.io.PortInUseException: Unknown Application

but

portIdentifier.isCurrentlyOwned()

returns false and when I do lsof on the device I am trying to connect  
to, I see no application
using it. As the same time if I go to the command line and use  
minicom I have no issues. The
exception happens with this call:

CommPort commPort = portIdentifier.open(null,0);

Any suggestions?

Andre


From ajmas at sympatico.ca  Sun Jun 18 17:45:11 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 19:45:11 -0400
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
Message-ID: <30245B30-682D-4EAE-8084-8227B719F10D@sympatico.ca>

BTW My code snippet is:

     private InputStream connectToSerial () throws IOException,  
Exception
     {
         InputStream in = null;

         Enumeration portEnum = CommPortIdentifier.getPortIdentifiers();
         while ( portEnum.hasMoreElements() )
         {
             CommPortIdentifier portIdentifier = (CommPortIdentifier)  
portEnum.nextElement();
             System.out.println(portIdentifier.getName() + " - " +  
portIdentifier.getPortType() );
         }

         CommPortIdentifier portIdentifier =  
CommPortIdentifier.getPortIdentifier("/dev/cu.BTGPS-SPPslave-1");
         System.out.println("current owner: " +  
portIdentifier.getCurrentOwner());
         if ( portIdentifier.isCurrentlyOwned() )
         {
             System.out.println("Error: Port is currently in use");
             return null;
         }
         else
         {
             CommPort commPort = portIdentifier.open(this.getClass 
().getName(),2000);

             if ( commPort instanceof SerialPort )
             {
                 SerialPort serialPort = (SerialPort) commPort;
                 serialPort.setSerialPortParams 
(4800,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE 
);
                 in = serialPort.getInputStream();

                 return in;
             }
             else
             {
                 System.out.println("Error: Only serial ports are  
handled.");
             }
         }


         return in;
     }


On 18-Jun-06, at 19:33 , Andr?-John Mas wrote:

> Hi,
>
> I am have a program that I wrote in Java to communicate with a
> Bluetooth GPS device. I am
> trying to get this working on my Mac, but I keep getting told that:
>
> gnu.io.PortInUseException: Unknown Application
>
> but
>
> portIdentifier.isCurrentlyOwned()
>
> returns false and when I do lsof on the device I am trying to connect
> to, I see no application
> using it. As the same time if I go to the command line and use
> minicom I have no issues. The
> exception happens with this call:
>
> CommPort commPort = portIdentifier.open(null,0);
>
> Any suggestions?
>
> Andre
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From joachim at buechse.de  Mon Jun 19 05:54:49 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 13:54:49 +0200
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de>

This is most likely due to a problem with lock files. If you have  
downloaded the binaries of 2.17 rxtx will try to create non-standard  
lock files on OSX. We have since changed the code to use OSX device  
locking - however the binaries have not been updated yet. The 2.18  
release fixing this issue is due shortly.

Regards,
Joachim

On 19.06.2006, at 01:33, Andr?-John Mas wrote:

> Hi,
>
> I am have a program that I wrote in Java to communicate with a
> Bluetooth GPS device. I am
> trying to get this working on my Mac, but I keep getting told that:
>
> gnu.io.PortInUseException: Unknown Application
>
> but
>
> portIdentifier.isCurrentlyOwned()
>
> returns false and when I do lsof on the device I am trying to connect
> to, I see no application
> using it. As the same time if I go to the command line and use
> minicom I have no issues. The
> exception happens with this call:
>
> CommPort commPort = portIdentifier.open(null,0);
>
> Any suggestions?
>
> Andre
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From joachim at buechse.de  Mon Jun 19 06:44:27 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 14:44:27 +0200
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <4490A60A.9090305@sun.com>
References: <4490A60A.9090305@sun.com>
Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>

Hello Paul,

I just downloaded the "generic" javax.comm version now available. A  
first check indicates, that it was compiled with a JDK 1.4 javac  
without setting the target classfile version. In other words in can  
not be loaded by 1.1-1.3 VMs (or PersonalJava).

Do you see any chance to provide a version compiled with classfile  
format 45.3 (ie JVM1.1).

---
52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose  
javax.comm.SerialPort | head -5
Compiled from "SerialPort.java"
public abstract class javax.comm.SerialPort extends javax.comm.CommPort
   SourceFile: "SerialPort.java"
   minor version: 0
   major version: 48
---

Best regards,
Joachim


On 15.06.2006, at 02:12, Paul Klissner wrote:

> Hello RxTx community,
>
> I finally think I have a compromise in place that will stand in the  
> gap.
>
> If you go to http://www.sun.com and search for javax.comm, you'll
> get taken to a download page, where now users can get a copy of the
> comm.jar file out of 2.0.3, along with just a license and a README.
>
> I trust this will suffice until such time as RxTx decided to implement
> their own java classes or we can get a JSR going to mitigate some
> of the problems (the readme in the comm.jar 2.0.3 zip file
> contains my thoughts on that).
>
> Thanks,
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Mon Jun 19 09:11:45 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Mon, 19 Jun 2006 11:11:45 -0400
Subject: [Rxtx] Examples added to Wiki
Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

I have added a couple of examples to the Wiki:

http://rxtx.qbang.org/wiki/index.php/Examples

If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :)

Andre



From paul.klissner at sun.com  Mon Jun 19 10:42:47 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Mon, 19 Jun 2006 09:42:47 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>
References: <4490A60A.9090305@sun.com>
	<03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>
Message-ID: <4496D407.1090609@sun.com>

Joachim Buechse wrote:
> Hello Paul,
> 
> I just downloaded the "generic" javax.comm version now available. A  
> first check indicates, that it was compiled with a JDK 1.4 javac  
> without setting the target classfile version. In other words in can  
> not be loaded by 1.1-1.3 VMs (or PersonalJava).
> 
> Do you see any chance to provide a version compiled with classfile  
> format 45.3 (ie JVM1.1).
> 
> ---
> 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose  
> javax.comm.SerialPort | head -5
> Compiled from "SerialPort.java"
> public abstract class javax.comm.SerialPort extends javax.comm.CommPort
>    SourceFile: "SerialPort.java"
>    minor version: 0
>    major version: 48
> ---

I cannot promise when I can do that. Since we thought we were done
with javax.comm, the build environment got moved around, and right
now it doesn't even compile in it's new home.  I tried and it was
not cooperative at all. I was never impressed with that workspace
(in fact far far from it, it is a mess, which is why I migrated 3.0
to ant and never looked back).  It will take some real determination
for me to rebuild it, and frankly, right now I'm swamped.  If I can
find a bit of time over the next few weeks to do it, and it isn't
too bad an ordeal, I will.

Posting that will give me an excuse to post javax.comm 3.0, Update 2 as
well, while I'm working with the people who put content up on our
download center.  The only reason for a new update to 3.0 is that
I've changed the distribution to provide ispt (Interactive Serial
Port Tool), such that it can be launched as soon as the zip file
is unpacked, via a provided script.  ISPT is a command line
interactive tool for  manipulating one or two serial port,
sending data, managing events, etc... I've found it to be so useful
for doing certain kinds of validation  that I assume others will
find it useful to.  ISPT is already in 3.0u1, but one has to set
up their own classpath and launch it and since few people ever read
the documentation most won't know about it.  I've added the ability
to set stop bits and parity since 3.0u1 too.  But I digress.

Paul


From joachim at buechse.de  Mon Jun 19 11:01:28 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 19:01:28 +0200
Subject: [Rxtx] load mechanism of 2.0x
Message-ID: <CFD1440C-21AA-4D3B-9EA6-270D0FF9D6FC@buechse.de>

Good day,

I am trying to figure out, how the 2.0x distribution interacts with  
Suns implementation of javax.comm.CommPortIdentifier.

1) Apparently one can put javax.comm.properties in {java.home}/lib
2) The javax.comm package also reacts to -Djavax.comm.properties="...."

Looking at the javap output it also seems like CommPortIdentifier  
tries to find it's jar file and load the properties from there??


What I'm really looking for is a solution that allows using  
javax.comm with RXTX without modifying the VM installation. So I  
would prefer not to use 1) but I can't figure out how to use 2).

Any hints are welcome,
Joachim



From bob_tai2001 at yahoo.com  Mon Jun 19 15:00:35 2006
From: bob_tai2001 at yahoo.com (Bob Tai)
Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT)
Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place
	to start?
Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>

Hi, 

I got  rxtx Windows 2000 installed.  I did not use the
"best" way ... I just follow the insturuction and dump
the necessary files into the jre... I know it's "best"
idea, I got lazy didn't want to change my setting to
my Eclipse and classpath.

I was able to modify SimpleWrite.java to print on my
AddMaster serial printer.  I think I am ready to code!
But I need to make sure I can handle exceptions and so
on.  I notice the \samples\NullDriver\  has two files
seems to have some of the require method done, should
I start coding from those file?  I like the idea it
has the "time out" and basic exceptions done.   I am
slowly digging into the samples, but if you think any
of the code from Sun is good to checkout please let me
know.

btw, http://rxtx.qbang.org/wiki/index.php/Examples/
was very helpful, wish there are more examples.

thank you,

    Bob


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Mon Jun 19 15:55:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT)
Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good
 place to start?
In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>
References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606191542260.14139@www>

> I am
> slowly digging into the samples, but if you think any
> of the code from Sun is good to checkout please let me
> know.
>

I think NullDriver.java was an example stub driver for implementing 
something like rxtx.  It has been a while.  Unless they have been updated, 
you will find the examples are very dated.  You can look at how they use 
the port but avoid the GUI and hard coded variables (number of ports for 
instance).

There was no Swing and nobody knew what requirements today's compilers 
would make on code.  The examples worked fine with jdk 1.1 but times have 
changed.

--
Trent Jarvi
tjarvi at qbang.org


From tropicsu at hotmail.com  Mon Jun 19 19:49:08 2006
From: tropicsu at hotmail.com (Yoke K)
Date: Tue, 20 Jun 2006 01:49:08 +0000
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
Message-ID: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>

An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/fa588f00/attachment-0009.html

From ajmas at sympatico.ca  Mon Jun 19 21:14:37 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Mon, 19 Jun 2006 23:14:37 -0400
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>
References: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>
Message-ID: <CA22AB2A-5712-458B-9984-68477C6042AF@sympatico.ca>

Regarding the PortInUseException, I had a similar issue and got
this response from the mailing list:

   http://mailman.qbang.org/pipermail/rxtx/Week-of- 
Mon-20060619/062838.html

Andre
On 19-Jun-06, at 21:49 , Yoke K wrote:

> Hi Andre, Joachim
>
> I have tried using /dev/tty.usbserial and also /dev/cu.usbserial  
> and it also reported error as  "gnu.io.PortInUseException".
>
> The iTegno modem works in windows environment. As I moving around  
> using my ibook and I need to get it work on MAC OS as well.
>
> >> INFO: SMSLib API for Java / v1.2.2
> >> INFO: Using port: /dev/tty.usbserial @ 115200 baud.
> >> INFO: JRE Version: 1.5.0_06
> >> INFO: JRE Impl Version: 1.5.0_06-64
> >> INFO: O/S: Mac OS X / ppc / 10.4.6
> >> INFO: Using Wavecom (Generic) AT handler.
>
> SendMessage(): Send a message.
> Using SMSLib API for Java v1.2.2
>
> Connecting ..... :
> >> INFO: CSerialDriver(): Connecting...
> Experimental: JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version = RXTX-2.1-7
> >> INFO: CSerialDriver(): Disconnecting...
> gnu.io.PortInUseException: Unknown Application
> at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354)
> at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1)
> at org.smslib.CService.connect(CService.java:197)
> at SendMessage.main(SendMessage.java:38)
>
> Thanks.
>
> - Jon
>
>
>
>
> ====================
>
> Hello Jon,
>
> From OSX's standpoint a symbolic link is not a device (as far as I
> know). What stops you from using tty.usbserial? Did you try hard-
> linking?
>
> Regards,
> Joachim
>
>
>
> From:  "Yoke K" <tropicsu at hotmail.com>
> To:  rxtx at qbang.org
> Subject:  RXTX-2.1-7 / MAC OS X / NoSuchPortException
> Date:  Sat, 17 Jun 2006 15:32:48 +0000
> >Hi,
> >
> >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to
> >work with MAC OS X.
> >I am using iTegno 3000 - USB GPRS Modem.
> >
> >Files in /dev and a symbolic link as follows:
> >
> >crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
> >crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
> >lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->
> >tty.usbserial
> >
> >In my SendMessage.java, I have this line:
> >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
> >
> >Appreciate any help ?
> >
> >- Jon
> >
> >
> >Errors as follows:
> >
> >>>INFO: SMSLib API for Java / v1.2.2
> >>>INFO: Using port: /dev/ttyS1 @ 56000 baud.
> >>>INFO: JRE Version: 1.5.0_06
> >>>INFO: JRE Impl Version: 1.5.0_06-64
> >>>INFO: O/S: Mac OS X / ppc / 10.4.6
> >>>INFO: Using Wavecom (Generic) AT handler.
> >
> >SendMessage(): Send a message.
> >  Using SMSLib API for Java v1.2.2
> >
> >Connecting ..... :
> >>>INFO: CSerialDriver(): Connecting...
> >Experimental:  JNI_OnLoad called.
> >Stable Library
> >=========================================
> >Native lib Version = RXTX-2.1-7
> >Java lib Version   = RXTX-2.1-7
> >>>INFO: CSerialDriver(): Disconnecting...
> >gnu.io.NoSuchPortException
> >        at
> >gnu.io.CommPortIdentifier.getPortIdentifier 
> (CommPortIdentifier.java:218)
> >        at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
> >        at org.smslib.CService.connect(CService.java:197)
> >        at SendMessage.main(SendMessage.java:38)
> >
> >_________________________________________________________________
> >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
> >
>
> Find love online with MSN Personals
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Tue Jun 20 02:35:24 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 10:35:24 +0200
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>

Hello everybody,

I have been fighting a bit with the javax.comm version of RXTX the  
last days. I am working on the README .OSX now and try to figure out  
which should be the "suggested" installation.

The facts:
------

- the "generic" comm.jar version of javax.comm which has been made re- 
available tries to load com.sun.comm.SolarisDriver
- this classname can be overridden ONLY by putting a file  
javax.comm.properties in {java.home}/lib
- if it is not overridden and SolarisDriver.class is not found  
CommPortIdentifier will be disfunctional (in particual it is not  
possible to add CommPort's via CommPortIdentifier.add).
- the license distributed with comm.jar does not allow the  
modification/addition of classes in javax.comm (however no mention of  
com.sun...)


What really bothers me is to suggest putting this config file in the  
"global" vm installation. This is particularly ugly on the Mac as  
there are several VM installations and the file may be forgotten.  
Additionally it may create versioning problems. I prefer an  
installation where all files are local to the application (even  
comm.jar).

In my opinion the ideal situation would be:
------

1) The author of a program compiles against javax.comm.
2a) For platforms supported by Sun the user is free to use the 3.0  
comm.jar download from Sun
2b) For platforms not supported by Sun the user adds RXTXComm.jar to  
the classpath of the application (and librxtxSerial.jnilib to the  
application directory). Also he will need the 2.0.3 generic comm.jar  
from Sun.
3) Nobody messes with the global VM installation.

Of course 2a) and 2b) could be handled by the author of the program  
via an appropriate installer. The author could also decide to always  
use RXTX and include the generic javax.comm classes as well as the  
RXTX classes in his application jar. [If he further uses an explicit  
call to System.load() he may even include the jnilib(s) in the jar,  
extract it (based on the platform name) at runtime to a temp file and  
load it from there.]


Suggested solution:
------

We only need to put the following class in the classpath BEFORE Suns  
comm.jar

   package com.sun.comm;
   public class SolarisDriver extends gnu.io.RXTXCommDriver {
   }

This is not "the pure art" (TM). It depends on an implementation  
detail of the generic driver. However, so does the  
javax.comm.properties file - as we have seen when Sun released 3.0.  
It has the following advantages:

- The "generic" javax.comm implementation will happily load this  
class as its primary driver.
- No javax.comm.properties file is required.
- This does not violate the javax.comm license agreement as there is  
no mention of the "com.sun.comm" package in this license agreement at  
all.
- Authors packaging comm.jar with their application can strip out all  
com.sun.comm classes from comm.jar


Please comment!

Joachim



From joachim at buechse.de  Tue Jun 20 02:50:36 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 10:50:36 +0200
Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar
Message-ID: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>

There has been some discussions about the best way to install RXTX  
and where to place files.

I suggest that,

- we include the native libraries for the most common operating  
systems (in a special version of) RXTXcomm.jar
- we add loader code which tries to extract and load the platform  
specific binary at runtime
- on failure the current mechanism remains as a fallback

Wether the current mechanism should have priority (ie loadLibrary  
before load) remains to be discussed.


The advantages of this solution are
  - users of RXTX do not need to worry about java/platform specific  
file placement.
  - authors of applications may fully merge RXTX into their  
application jar (which provides a double-clickable application for  
Windows and OSX, Linux?).

Please comment,
Joachim

PS: Of course the suggested solution is already possible today,  
however relatively few programmers know how to correctly extract a  
binary resource file via the class loader and load it as a native  
library.


From tjarvi at qbang.org  Tue Jun 20 03:58:12 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT)
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
Message-ID: <Pine.LNX.4.61.0606200335190.14139@www>

> 2a) For platforms supported by Sun the user is free to use the 3.0
> comm.jar download from Sun
> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to
> the classpath of the application (and librxtxSerial.jnilib to the
> application directory). Also he will need the 2.0.3 generic comm.jar
> from Sun.

As there are no plans to support CommAPI 3.0 due to the limitations in its 
implementation mentioned before, I would not recommend projects use Sun's 
3.0 comm.jar.  They will lose the freedom to chose their low level 
implementation by being locked into vendor specific modifications.

Projects should chose between platform neutrality in CommAPI 2.0 and 
reduced platform neutrality in commapi 3.0.  Projects should also strongly 
consider the fact that the 2.0 comm.jar targets only a reduced number of 
JVMs.

Projects can go with rxtx 2.1 or other packages but should probably only 
consider using Sun CommAPI with rxtx if they did so in the past.  They 
should take steps to no longer depend upon this option being available.

> Suggested solution:
> ------
>
> We only need to put the following class in the classpath BEFORE Suns
> comm.jar
>
>   package com.sun.comm;
>   public class SolarisDriver extends gnu.io.RXTXCommDriver {
>   }
>
> This is not "the pure art" (TM). It depends on an implementation
> detail of the generic driver. However, so does the
> javax.comm.properties file - as we have seen when Sun released 3.0.
> It has the following advantages:
>
> - The "generic" javax.comm implementation will happily load this
> class as its primary driver.
> - No javax.comm.properties file is required.
> - This does not violate the javax.comm license agreement as there is
> no mention of the "com.sun.comm" package in this license agreement at
> all.
> - Authors packaging comm.jar with their application can strip out all
> com.sun.comm classes from comm.jar
>

I would not encourage people to place packages in the com.sun.comm 
namespace.  Authors using Sun's commapi 2.0 should just realize it is 
greatly limited in practical utility and consider moving to something that 
isn't being rescued from EOL.

The primary focus of this release is projects previously depending upon 
Sun CommAPI + RXTX.  There are no plans at this time to provide future 
support in this arrangement due to technical incompatabilities we have no 
control over in commapi 3.0 and limited utility of Sun's generic comm.jar 
in commapi 2.0 offered.  Projects should be aware of this so they can make 
appropriate plans.

--
Trent Jarvi
tjarvi at qbang.org


From paul.klissner at sun.com  Tue Jun 20 05:24:00 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Tue, 20 Jun 2006 04:24:00 -0700
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
In-Reply-To: <Pine.LNX.4.61.0606200335190.14139@www>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
	<Pine.LNX.4.61.0606200335190.14139@www>
Message-ID: <4497DAD0.10803@sun.com>

Trent Jarvi wrote:
>> 2a) For platforms supported by Sun the user is free to use the 3.0
>> comm.jar download from Sun
>> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to
>> the classpath of the application (and librxtxSerial.jnilib to the
>> application directory). Also he will need the 2.0.3 generic comm.jar
>> from Sun.
> 
> As there are no plans to support CommAPI 3.0 due to the limitations in its 
> implementation mentioned before, I would not recommend projects use Sun's 
> 3.0 comm.jar.  They will lose the freedom to chose their low level 
> implementation by being locked into vendor specific modifications.
> 
> Projects should chose between platform neutrality in CommAPI 2.0 and 
> reduced platform neutrality in commapi 3.0.  Projects should also strongly 
> consider the fact that the 2.0 comm.jar targets only a reduced number of 
> JVMs.

Well, that's a little ambiguous because the API is the same
either way.  We're talking about Sun's implementation vs.
other implementations.
> 
> Projects can go with rxtx 2.1 or other packages but should probably only 
> consider using Sun CommAPI with rxtx if they did so in the past.  They 
> should take steps to no longer depend upon this option being available.

3.0 is platform centric because there is a need to add some
platform awareness to Sun's implementation, and the choices
for how to do that are limited by the constraints of the API,
as mentioned in the javax.comm 2.0.3 comm.jar download's README.

I am really advocating getting a JSR open (http://www.jcp.org)
to push a new comm API that is more pluggable, platform neutral
and addresses some of the deficiencies of the current API. Then
we can achieve the optimal of platform neutrality while
simulataneously allowing the API to flexibly adapt to
heterogeneous environments.

This is not a question of attitude, this is an issue of resources,
time and commitment.  The current owners of javax.comm within
Sun would like nothing better than to see the ideal reached for
the API and a model that will extend well beyond the foreseeable
future and work for the industry overall.



> 
>> Suggested solution:
>> ------
>>
>> We only need to put the following class in the classpath BEFORE Suns
>> comm.jar
>>
>>   package com.sun.comm;
>>   public class SolarisDriver extends gnu.io.RXTXCommDriver {
>>   }
>>
>> This is not "the pure art" (TM). It depends on an implementation
>> detail of the generic driver. However, so does the
>> javax.comm.properties file - as we have seen when Sun released 3.0.
>> It has the following advantages:
>>
>> - The "generic" javax.comm implementation will happily load this
>> class as its primary driver.
>> - No javax.comm.properties file is required.
>> - This does not violate the javax.comm license agreement as there is
>> no mention of the "com.sun.comm" package in this license agreement at
>> all.
>> - Authors packaging comm.jar with their application can strip out all
>> com.sun.comm classes from comm.jar
>>
> 
> I would not encourage people to place packages in the com.sun.comm 
> namespace.  Authors using Sun's commapi 2.0 should just realize it is 
> greatly limited in practical utility and consider moving to something that 
> isn't being rescued from EOL.
> 
> The primary focus of this release is projects previously depending upon 
> Sun CommAPI + RXTX.  There are no plans at this time to provide future 
> support in this arrangement due to technical incompatabilities we have no 
> control over in commapi 3.0 and limited utility of Sun's generic comm.jar 
> in commapi 2.0 offered.  Projects should be aware of this so they can make 
> appropriate plans.

Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86,
or need the powerful portmapping features in javax.com 3.0, or would like to
acquire the Interactive Serial Port Test utility.

-Paul


From paul.klissner at sun.com  Tue Jun 20 05:33:44 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Tue, 20 Jun 2006 04:33:44 -0700
Subject: [Rxtx] Suggested installation RXTX 2.0x...
In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
Message-ID: <4497DD18.70207@sun.com>

Joachim Buechse wrote:
> Hello everybody,
> 
> I have been fighting a bit with the javax.comm version of RXTX the  
> last days. I am working on the README .OSX now and try to figure out  
> which should be the "suggested" installation.
> 
> The facts:
> ------
> 
> - the "generic" comm.jar version of javax.comm which has been made re- 
> available tries to load com.sun.comm.SolarisDriver
> - this classname can be overridden ONLY by putting a file  
> javax.comm.properties in {java.home}/lib
> - if it is not overridden and SolarisDriver.class is not found  
> CommPortIdentifier will be disfunctional (in particual it is not  
> possible to add CommPort's via CommPortIdentifier.add).
> - the license distributed with comm.jar does not allow the  
> modification/addition of classes in javax.comm (however no mention of  
> com.sun...)
> 
> 
> What really bothers me is to suggest putting this config file in the  
> "global" vm installation. This is particularly ugly on the Mac as  
> there are several VM installations and the file may be forgotten.  
> Additionally it may create versioning problems. I prefer an  
> installation where all files are local to the application (even  
> comm.jar).
> 
> In my opinion the ideal situation would be:
> ------
> 
> 1) The author of a program compiles against javax.comm.
> 2a) For platforms supported by Sun the user is free to use the 3.0  
> comm.jar download from Sun
> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to  
> the classpath of the application (and librxtxSerial.jnilib to the  
> application directory). Also he will need the 2.0.3 generic comm.jar  
> from Sun.
> 3) Nobody messes with the global VM installation.
> 
> Of course 2a) and 2b) could be handled by the author of the program  
> via an appropriate installer. The author could also decide to always  
> use RXTX and include the generic javax.comm classes as well as the  
> RXTX classes in his application jar. [If he further uses an explicit  
> call to System.load() he may even include the jnilib(s) in the jar,  
> extract it (based on the platform name) at runtime to a temp file and  
> load it from there.]
> 

This was how the Sun implementation originated (I did not write
that code).  I completely agree, and I fixed the whole conf file
locating mechanism in 3.0 to avoid the problems youmentioned.
However, I was unaware of how RxTx was using Sun's implementation,
so I didn't architect it in such a way as to avoid namespace pollution
in the native space in for the backend provider.  In retrospect,
I should have done that differently just as a design principle,
but at this point I don't have the spare cycles to get that all
re-factored.  Further, I'm loathe to do it, because the whole
thing will still be an under-the-hood hack due to the constraints
of the API itself.

Paul





From brian at mbari.org  Tue Jun 20 10:23:54 2006
From: brian at mbari.org (Brian Schlining)
Date: Tue, 20 Jun 2006 09:23:54 -0700
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>


Hi Joachim,

> There has been some discussions about the best way to install RXTX
> and where to place files.
>
> I suggest that,
>
> - we include the native libraries for the most common operating
> systems (in a special version of) RXTXcomm.jar
> - we add loader code which tries to extract and load the platform
> specific binary at runtime
> - on failure the current mechanism remains as a fallback

I like your suggestion. However, my understanding is that in general  
the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH  
(Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to  
be loaded by the JVM. The alternative is to point to your native lib  
directory using -Djava.library.path=/my/dir/with/native/libs when you  
launch the JVM. So, I'm very interested to know how you're planning  
to work around this.

> PS: Of course the suggested solution is already possible today,
> however relatively few programmers know how to correctly extract a
> binary resource file via the class loader and load it as a native
> library.

So how do you use it to dynamically load a native lib? I've read that  
you can't really modify the java.library.path after the JVM has been  
launched. (http://forum.java.sun.com/thread.jspa? 
threadID=627890&tstart=90)

Thanks

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0018.html

From joachim at buechse.de  Tue Jun 20 09:20:29 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 17:20:29 +0200
Subject: [Rxtx] 2.0x in sync with 2.1x
Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>

I have added most of the changes from the 2.1 branch to the 2.0 branch.

This includes
  - correction of illegal javadoc comments
  - implementation errors in handling of Thread.interrupt in  
RXTXPort.java
  - MacOS X locking without lock files/special user groups
  - XCode project which builds a universal binary library
  - updated documentation for OSX

I have done some minimal testing (only G4).
[Trent: there are still some changes you made for specific baud  
rates. I will not sync this, as I can not test them. From my  
perspective we are ready for 2.08/2.18]

The updated documentation can be found in the file README.OSX. Here  
it is:

------------------------ Required files -----------------------

To use or compile RXTX 2.0.x you need to downlad the "generic"  
version (2.0.3)
of the javax.comm implementation from Sun. The zip you download  
contains an
archive comm.jar which is required:

- To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar

- To run the app you will need comm.jar in the classpath or in  
{java.lib.path}


------------------------ Installation on MacOSX -----------------------

WARNING: Please read this section until the end.

---
Preparation
---

You may want to spare your users the burden of modifying the global VM
installation. OSX has several different VM versions installed by  
default and
regular users will be unable to figure out which version will load your
application.

If you provide the class

package com.sun.comm;
public class SolarisDriver extends gnu.io.RXTXCommDriver {
}

and make sure, that it is present in the classpath before Suns  
"generic" comm.jar
your users can skip the following step:

Create a file named
    javax.comm.properties
in the directory
    /System/Library/Frameworks/JavaVM.framework/Home/lib/
which contains (only) the following line (no leading space):
    Driver=gnu.io.RXTXCommDriver



----
The unsafe way of using RXTX on OS X:
----

RXTX can be installed by putting the files
   libSerial.jnilib
   RXTXcomm.jar
   comm.jar
into the folder
   /Library/Java/Extensions

This is NOT RECOMMENDED as it creates versioning conflicts among  
applications.
However you may be forced to install it this way if an application  
was written
for Windows or Linux, requires RXTX and you are not able to change  
its starter.


----
The safe way of using RXTX on OS X:
----

Make sure that you have no (older) version of RXTX installed in
   /Library/Java/Extensions
   /System/Library/Java/Extensions
   /usr/lib/java

Put
   libSerial.jnilib
in the directory of the application (the JavaVM will find it there). Add
   RXTXComm.jar
   comm.jar
to the application classpath or include the classes in the  
application jar.
(Some applications already include the RXTX classes in their  
application jar,
in which case only the file libSerial.jnilib is required).


----
History
----

Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation  
of lockfiles
required special permissions for the user executing an application  
based on RXTX.
To simplify the setup RXTX came with an installer modifying group  
permissions
and installing RXTX in the global location /Library/Java/Extensions.  
However
this was prune to versioning conflicts and is no longer recommended.

--------------------- Build instructions for OSX XCode  
-------------------

contributed by Joachim Buechse <joachim at buechse.de>
original version by Dmitry Markman <dmarkman at mac.com>

System requirements for building:
MacOSX 10.4
XCode 2.3

   open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj
   choose libSerial.jnilib target
   build

After the build you will find RXTXcomm.jar and libSerial.jnilib files  
in the
directory build/Development.

In case you can't find RXTXcomm.jar build the RXTXcomm target manually.
In case of (serious) problems feel free to contact joachim at buechse.de .



From tjarvi at qbang.org  Tue Jun 20 22:01:45 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT)
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
Message-ID: <Pine.LNX.4.61.0606202127270.14139@www>

> ---
> Preparation
> ---
>
> You may want to spare your users the burden of modifying the global VM
> installation. OSX has several different VM versions installed by
> default and
> regular users will be unable to figure out which version will load your
> application.
>
> If you provide the class
>
> package com.sun.comm;
> public class SolarisDriver extends gnu.io.RXTXCommDriver {
> }
>
> and make sure, that it is present in the classpath before Suns
> "generic" comm.jar
> your users can skip the following step:

Hi Joachim

With regards to the above, I have not seen that we have Sun's OK to 
promote that.  I'm not very comfortable with the distribution 
documentation advocating this without Sun agreeing.

I see your point but I'd rather not actively promote putting classes in 
Sun's namespace without permission if you don't mind.  This isn't about 
what is in a license.

I'll go through the code tomorrow night.  It was a late night at work 
today.  There is also a w32 fix comming for people opening and closing 
multiple ports.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Wed Jun 21 01:56:45 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 21 Jun 2006 09:56:45 +0200
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <Pine.LNX.4.61.0606202127270.14139@www>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
	<Pine.LNX.4.61.0606202127270.14139@www>
Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>

Hello Trent,

I guess we will not get an explicit OK from Sun for such a hack. I  
think Paul has made it pretty clear, that he does not have the  
resources to modify the 2.x or 3.x code for the needs of RXTX. I'm  
not thrilled but OK with the current API. Hence I dont agree with  
Paul's idea to start a new JSR to fix the implementation - but that's  
mainly because I dont have the time to push it. According to their  
Readme Sun sees no business case in having cross platform support for  
javax.comm - that is sad but it's none of my business. However I  
prefer to program versus javax.comm in my projects as this gives an  
advanced user the chance to exchange the provider without access to  
the code.

I interpret Pauls reponse to my original "Request for comment" as a  
quiet acceptance of the hack I propose (he did respond, but not at  
all to the sun.comm namespace suggestion). This is certainly not  
something we should put into RXTXcomm.jar but hinting a work around  
for implementation errors should be allowed. That's why I've choosen  
the wording "You may want to spare" and "If you provide". The company  
I worked for has choosen similar hacks for years to fix bugs in swing  
for JDK1.1 applications. Those hacks were usually included in their  
own swingpatch.jar.

Having said all that - I do not take it as an insult if you remove  
the paragraph from the Readme. I appreciate that you notified me  
before. It would be interesting to hear some more opinions from the  
list members...

Best regards,
Joachim


On 21.06.2006, at 06:01, Trent Jarvi wrote:

>> ---
>> Preparation
>> ---
>>
>> You may want to spare your users the burden of modifying the  
>> global VM
>> installation. OSX has several different VM versions installed by
>> default and
>> regular users will be unable to figure out which version will load  
>> your
>> application.
>>
>> If you provide the class
>>
>> package com.sun.comm;
>> public class SolarisDriver extends gnu.io.RXTXCommDriver {
>> }
>>
>> and make sure, that it is present in the classpath before Suns
>> "generic" comm.jar
>> your users can skip the following step:
>
> Hi Joachim
>
> With regards to the above, I have not seen that we have Sun's OK to
> promote that.  I'm not very comfortable with the distribution
> documentation advocating this without Sun agreeing.
>
> I see your point but I'd rather not actively promote putting  
> classes in
> Sun's namespace without permission if you don't mind.  This isn't  
> about
> what is in a license.
>
> I'll go through the code tomorrow night.  It was a late night at work
> today.  There is also a w32 fix comming for people opening and closing
> multiple ports.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Wed Jun 21 02:03:33 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 21 Jun 2006 10:03:33 +0200
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
	<6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
Message-ID: <BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>

See System.load(String) [it's also mentioned under the URL you posted].

Regards,
Joachim


On 20.06.2006, at 18:23, Brian Schlining wrote:

> So how do you use it to dynamically load a native lib? I've read  
> that you can't really modify the java.library.path after the JVM  
> has been launched. (http://forum.java.sun.com/thread.jspa? 
> threadID=627890&tstart=90)
>
> Thanks
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From baris.ozkan at elikasu.com.tr  Wed Jun 21 07:58:06 2006
From: baris.ozkan at elikasu.com.tr (Baris)
Date: Wed, 21 Jun 2006 16:58:06 +0300
Subject: [Rxtx] RS 232 ..additional parameters
Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>

Hi,
 
Currently i am developing an application that requires to connect to a
remote rs232 device through  a dialup connection.
 
My problem is that the communication needs several more connection
parameters (i extracted that information from the vendor's dll , listed at
the end of the message)
 
I explored rxtx API and src files and could not find methods to set a
majority  of the parameters.
Am i missing any point or does rxtx is limited to soem standard set of
functionality(e.g. commAPI)? How  is it possible ,if i want to put some
extensions(???) to current rxtx implementation?
 
I am not very good at rs232 programming so excuse me if this message  is
boring one.
 
Thanx
 
Baris Ozkan
 
 
A Listing of Parameters:
 
 
typedef struct _DCB {

DWORD DCBlength; /* sizeof(DCB) */

DWORD BaudRate; /* Baudrate at which running */

DWORD fBinary: 1; /* Binary Mode (skip EOF check) */

DWORD fParity: 1; /* Enable parity checking */

DWORD fOutxCtsFlow:1; /* CTS handshaking on output */

DWORD fOutxDsrFlow:1; /* DSR handshaking on output */

DWORD fDtrControl:2; /* DTR Flow control */

DWORD fDsrSensitivity:1; /* DSR Sensitivity */

DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */

DWORD fOutX: 1; /* Enable output X-ON/X-OFF */

DWORD fInX: 1; /* Enable input X-ON/X-OFF */

DWORD fErrorChar: 1; /* Enable Err Replacement */

DWORD fNull: 1; /* Enable Null stripping */

DWORD fRtsControl:2; /* Rts Flow control */

DWORD fAbortOnError:1; /* Abort all reads and writes on Error */

DWORD fDummy2:17; /* Reserved */

WORD wReserved; /* Not currently used */

WORD XonLim; /* Transmit X-ON threshold */

WORD XoffLim; /* Transmit X-OFF threshold */

BYTE ByteSize; /* Number of bits/byte, 4-8 */

BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */

BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */

char XonChar; /* Tx and Rx X-ON character */

char XoffChar; /* Tx and Rx X-OFF character */

char ErrorChar; /* Error replacement char */

char EofChar; /* End of Input character */

char EvtChar; /* Received Event character */

WORD wReserved1; /* Fill for now. */

} DCB, *LPDCB;

typedef struct _COMMTIMEOUTS {

DWORD ReadIntervalTimeout; /* Maximum time between read chars. */

DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */

DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */

DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */

DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */

} COMMTIMEOUTS,*LPCOMMTIMEOUTS;

dcb.fOutX = FALSE;

dcb.fInX = FALSE;

dcb.fOutxCtsFlow = FALSE;

dcb.fBinary = TRUE;

dcb.fRtsControl = RTS_CONTROL_ENABLE;

SetCommState(hComm , &dcb ); 

COMMTIMEOUTS commTimeOut;

GetCommTimeouts(hComm, &commTimeOut );

commTimeOut.WriteTotalTimeoutMultiplier = 1; 

commTimeOut.WriteTotalTimeoutConstant = 18; 

// commTimeOut.ReadIntervalTimeout = 28; 

commTimeOut.ReadIntervalTimeout = 0; 

// commTimeOut.ReadTotalTimeoutMultiplier = 184; 

commTimeOut.ReadTotalTimeoutMultiplier = 300; 

// commTimeOut.ReadTotalTimeoutConstant = 1200;

commTimeOut.ReadTotalTimeoutConstant = 1200;

SetCommTimeouts(hComm, &commTimeOut);

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0018.html

From ajmas at sympatico.ca  Wed Jun 21 08:14:26 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Wed, 21 Jun 2006 10:14:26 -0400
Subject: [Rxtx] When is 2.18 planned for?
Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

Just curious as to know if there is a target date for 2.18?

Andre



From brian at mbari.org  Wed Jun 21 09:36:00 2006
From: brian at mbari.org (Brian Schlining)
Date: Wed, 21 Jun 2006 08:36:00 -0700
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
	<6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
	<BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>
Message-ID: <A21C9BC0-7894-4B08-AC82-44E11AB3D461@mbari.org>

Ha!!

I suppose I should read my own postings. ;-)

Thanks
B

On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote:

> See System.load(String) [it's also mentioned under the URL you  
> posted].
>
> Regards,
> Joachim
>
>
> On 20.06.2006, at 18:23, Brian Schlining wrote:
>
>> So how do you use it to dynamically load a native lib? I've read
>> that you can't really modify the java.library.path after the JVM
>> has been launched. (http://forum.java.sun.com/thread.jspa?
>> threadID=627890&tstart=90)

Brian Schlining
Software Engineer
http://www.mbari.org




From ajmas at sympatico.ca  Wed Jun 21 16:41:28 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Wed, 21 Jun 2006 18:41:28 -0400
Subject: [Rxtx] CVS build question
Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X:

 The JCL extension to RxTx requires comm.jar
 If you intend to use RxTx for commapi support comm.jar
 needs to be located in  /System/Library/Frameworks/JavaVM.framework/
  Versions/1.5/Home/lib/ext/comm.jar

I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me.

On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native).

Andre






From tjarvi at qbang.org  Wed Jun 21 18:00:04 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT)
Subject: [Rxtx] CVS build question
In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606211756310.14139@www>

On Wed, 21 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> Is the CVS repository meant to build for gnu.io or javax.comm? I ask 
> this, because I see the following when calling ./configure from MacOS X:
>
> The JCL extension to RxTx requires comm.jar
> If you intend to use RxTx for commapi support comm.jar
> needs to be located in  /System/Library/Frameworks/JavaVM.framework/
>  Versions/1.5/Home/lib/ext/comm.jar
>
> I am wanting to build for the gnu.io package, since I want to jump ahead 
> and see if the changes, intended for 2.18 for MacOS X, work for me.
>
> On a side note /Library/Java/Extensions should be included as a valid 
> search path for the JAR, since this is where Apple recommends placing 
> third party extensions (both Java and native).
>

rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel"
rxtx 2.0 src is obtained with "cvs checkout rxtx-devel"

rxtx 2.1 is a complete package in namespace gnu.io
rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 18:02:23 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT)
Subject: [Rxtx] When is 2.18 planned for?
In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606211800180.14139@www>

On Wed, 21 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> Just curious as to know if there is a target date for 2.18?
>

Hi Andre

"When it is ready" :)

Probably this weekend.  Maybe sooner.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 18:10:18 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT)
Subject: [Rxtx] RS 232 ..additional parameters
In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>
References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>
Message-ID: <Pine.LNX.4.61.0606211805010.14139@www>

On Wed, 21 Jun 2006, Baris wrote:

> Hi,
>
> Currently i am developing an application that requires to connect to a
> remote rs232 device through  a dialup connection.
>
> My problem is that the communication needs several more connection
> parameters (i extracted that information from the vendor's dll , listed at
> the end of the message)
>
> I explored rxtx API and src files and could not find methods to set a
> majority  of the parameters.
> Am i missing any point or does rxtx is limited to soem standard set of
> functionality(e.g. commAPI)? How  is it possible ,if i want to put some
> extensions(???) to current rxtx implementation?
>
> I am not very good at rs232 programming so excuse me if this message  is
> boring one.
>
> Thanx
>

Hi Baris

> typedef struct _DCB {
> typedef struct _COMMTIMEOUTS {

These are all handled in termios.c.  It is possible to add extensions to 
rxtx 2.1.  It may well be that the defaults are the same for the variables 
not covered by the existing API.  You can dump the DCB and COMMTIMEOUTS 
from inside termios.c to compare.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 20:23:30 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT)
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
	<Pine.LNX.4.61.0606202127270.14139@www>
	<789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>
Message-ID: <Pine.LNX.4.61.0606212012210.14139@www>

> I'm
> not thrilled but OK with the current API. Hence I dont agree with
> Paul's idea to start a new JSR to fix the implementation - but that's
> mainly because I dont have the time to push it. According to their
> Readme Sun sees no business case in having cross platform support for
> javax.comm - that is sad but it's none of my business. However I
> prefer to program versus javax.comm in my projects as this gives an
> advanced user the chance to exchange the provider without access to
> the code.

Hi Joachim

With regards to the JSR, I think that would be Doug's call.  The effort I 
put in would have to be on my own time which would not be a great deal.  I 
could help things go smoothly but thats not the same as pushing something 
through.

--
Trent Jarvi
tjarvi at qbang.org



From vt at freehold.crocodile.org  Wed Jun 21 21:05:22 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Wed, 21 Jun 2006 20:05:22 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
Message-ID: <449A08F2.3020106@freehold.crocodile.org>

Hello all,

I know this question may belong to JSR lists, but since all interested 
parties are here, I thought I just ask this question here, again...

A while ago I run into a problem and wrote a rant, here: 
http://servomaster.sourceforge.net/dev/serial-usb.html
At the time of writing I didn't think of adding another possible 
solution - changing the CommAPI specs to support removable devices. 
Apparently, Serial/USB bridges are here to stay, and this issue has to 
be addressed.

Wonder if anything changed since, and any abstractions for supporting 
removable devices made it into current or future Java CommAPI drafts - 
Paul, any comments?

--vt



From joachim at buechse.de  Thu Jun 22 01:59:54 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 22 Jun 2006 09:59:54 +0200
Subject: [Rxtx] CVS build question
In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de>

Hello Andre,

I am not sure how well the configure/make mechanism will work on OSX.  
I know that a while ago some contributors tried to get configure/make  
working on OSX but from comments I found in the readmes this work was  
only partially successfull. For compilation on OSX we have used the  
ProjectBuilder/XCode projects you can find in MACOSX_IDE.

Regarding the  ./configure comment:
RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config  
file javax.comm.properties. The later MUST reside in {java.home}/lib.  
As the two only work together putting comm.jar into  /Library/Java/ 
Extensions  and hence making it available to all current and future  
VM installations will only add to confusion.

Regards,
Joachim

On 22.06.2006, at 00:41, Andre-John Mas wrote:

> Hi,
>
> Is the CVS repository meant to build for gnu.io or javax.comm? I  
> ask this, because I see the following when calling ./configure from  
> MacOS X:
>
>  The JCL extension to RxTx requires comm.jar
>  If you intend to use RxTx for commapi support comm.jar
>  needs to be located in  /System/Library/Frameworks/JavaVM.framework/
>   Versions/1.5/Home/lib/ext/comm.jar
>
> I am wanting to build for the gnu.io package, since I want to jump  
> ahead and see if the changes, intended for 2.18 for MacOS X, work  
> for me.
>
> On a side note /Library/Java/Extensions should be included as a  
> valid search path for the JAR, since this is where Apple recommends  
> placing third party extensions (both Java and native).
>
> Andre
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Thu Jun 22 02:51:05 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 22 Jun 2006 10:51:05 +0200
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449A08F2.3020106@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>

Hello Vadim,

I think that your rant is to the point. However it is a bit like  
saying that Windows is at the source of email degradation and the  
only solution is to have users switch to safer operating systems.

I don't see how javax.comm or RXTX can address the problems you  
mention. Of course it would be super cool if javax.comm could magicly  
find the "matching" usb-device and query it's configuration via the  
usb protocol - however this magic (mapping /dev/xyz to its underlying  
USB device) is not supported by any kernel APIs I am aware of. It  
could be supported via POSSIX ioctl calls but then you should address  
your rant to the POSSIX group...

So for the time beeing it's either up to the virtual comm port driver  
to provide a usefull name under /dev/ or to the user choosing the  
right port to use. One example of a smart(er) com port driver is the  
KDDI driver for OSX, which will create device names like "/dev/ 
cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- 
encoded into the bridge chip. The same driver for windows also has  
some options allowing it in theory to recreate the same COMx every  
time a device is plugged/unplugged.

For most industrial applications however it will be up to the user to  
choose the right port (without getting a lot of help doing so).

Probing serial ports can go wrong, that's right. However any serial  
device developper would be well adviced to implement a basic set of  
Hayes AT modem commands (be it a modem or not). Especially AT I0.  
Anyone failing to do so risks that the users favourite TCP/PPP/FAX  
application or stack will kill the device in short time.

Best regards,
Joachim


On 22.06.2006, at 05:05, Vadim Tkachenko wrote:

> Hello all,
>
> I know this question may belong to JSR lists, but since all interested
> parties are here, I thought I just ask this question here, again...
>
> A while ago I run into a problem and wrote a rant, here:
> http://servomaster.sourceforge.net/dev/serial-usb.html
> At the time of writing I didn't think of adding another possible
> solution - changing the CommAPI specs to support removable devices.
> Apparently, Serial/USB bridges are here to stay, and this issue has to
> be addressed.
>
> Wonder if anything changed since, and any abstractions for supporting
> removable devices made it into current or future Java CommAPI drafts -
> Paul, any comments?
>
> --vt
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From vt at freehold.crocodile.org  Thu Jun 22 13:16:03 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 12:16:03 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
Message-ID: <20060622191603.GA17487@freehold.crocodile.org>

Hello Joachim,

> I think that your rant is to the point. However it is a bit like  
> saying that Windows is at the source of email degradation and the  
> only solution is to have users switch to safer operating systems.

I guess the problem is that the rant itself is obsolete and has to be
updated according to latest developments. At the time of writing there
weren't that many bridges around, and the trend didn't manifest itself as it
does now.

> I don't see how javax.comm or RXTX can address the problems you  
> mention.

I would agree that javax.comm won't be able to address the problem, at least
in the short run. As for RxTx - well, nobody prevents it from being a
superset of CommAPI specification, right? RxTx being the de-facto standard
for quite a few platforms, I'd daresay the standard may follow.

> Of course it would be super cool if javax.comm could magicly find the
> "matching" usb-device and query it's configuration via the usb protocol -
> however this magic (mapping /dev/xyz to its underlying USB device) is not
> supported by any kernel APIs I am aware of. It could be supported via
> POSSIX ioctl calls but then you should address your rant to the POSSIX
> group...

As a matter of fact, my bigger concern is addressing the fact that a serial
device can now be removable. This hasn't been the case before, and it
clearly is now. Regarding the above, well, I guess if we accept this fact,
we also need to accept the fact that we need at least rudimentary means of
identification of a serial device. For the USB case, it would usually be the
vendor/product ID, plus possible serial number - but it is irrelevant what
exactly the identifying information is, as long as it allows to identify the
device.

A paradigm shift is required, this is what I wanted to say. Serial devices
can be removed and replaced, it's now our turn to learn to deal with it.

> Joachim

--vt


From jredman at ergotech.com  Thu Jun 22 13:41:44 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 13:41:44 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
Message-ID: <449AF278.6000903@ergotech.com>


Vadim Tkachenko wrote:
> A paradigm shift is required, this is what I wanted to say. Serial devices
> can be removed and replaced, it's now our turn to learn to deal with it.

The removal if the serial port hardly significantly different from the 
removal of the device attached to the serial port.   Different, 
slightly, but not a "paradigm shift".

And yes, someone could unplug a USB serial device and plug it into a 
different USB port so that it has a different name/number, but they 
could do that with the device itself, move it from com1 to com2.

Am I missing something?

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 13:57:27 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 12:57:27 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449AF278.6000903@ergotech.com>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
Message-ID: <20060622195727.GA20247@freehold.crocodile.org>

On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote:
> 
> Vadim Tkachenko wrote:
> > A paradigm shift is required, this is what I wanted to say. Serial devices
> > can be removed and replaced, it's now our turn to learn to deal with it.
> 
> The removal if the serial port hardly significantly different from the 
> removal of the device attached to the serial port.   Different, 
> slightly, but not a "paradigm shift".
> 
> And yes, someone could unplug a USB serial device and plug it into a 
> different USB port so that it has a different name/number, but they 
> could do that with the device itself, move it from com1 to com2.
> 
> Am I missing something?

Yes, the fact that they could unplug a device A and plug a device B. With
the introduction of the concept of removability, the notion of the serial
port itself is not as important anymore, but the notion of the unique device
identifier is.

Consider a situation: long running system (enterprise HVAC, tens of nodes,
tens of thousands square feet area, hundreds of thousand dollars worth of
equipment being conditioned, can't shut down), serial/usb device fails, is
replaced by an identical device with a different serial #.

A little bit farfetched, but hopefully highlighting the point I'm trying to
make.

> Jim

--vt


From jredman at ergotech.com  Thu Jun 22 14:37:38 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 14:37:38 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>	<20060622191603.GA17487@freehold.crocodile.org>	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
Message-ID: <449AFF92.8080003@ergotech.com>


Vadim Tkachenko wrote:
>>
>> Am I missing something?
> 
> Yes, the fact that they could unplug a device A and plug a device B. With
> the introduction of the concept of removability, the notion of the serial
> port itself is not as important anymore, but the notion of the unique device
> identifier is.

Serial devices are always removable.  I could unplug _serial_ device A 
and plug in _serial_ device B.  We have systems running with two RS485 
ports, one talks to a Modbus PLC network one to a number of drives on a 
proprietary protocol.  If you plug the wrong DB9 into the wrong port the 
application doesn't work.

If you dangle a USB 485 converter on the end of the DB9 you've just 
moved the problem from RS485 to USB, but the problem/effect is the same.

> 
> Consider a situation: long running system (enterprise HVAC, tens of nodes,
> tens of thousands square feet area, hundreds of thousand dollars worth of
> equipment being conditioned, can't shut down), serial/usb device fails, is
> replaced by an identical device with a different serial #.
> 
> A little bit farfetched, but hopefully highlighting the point I'm trying to
> make.

Nothing's changed.  If I had a 4 port ISA board and plugged it into my 
new shiny '386 machine.  I could have com ports 9-12.  If I took a board 
off the shelf and didn't set the jumpers, I would have com ports 3-6.

The problem's the same.  If you replace with identical product then the 
com ports  will be the same - no software changes required.  If you 
replace one piece of hardware with hardware from a different 
manufacturer, then the naming/numbering may change.  You're physically 
changing the system, so may reasonably expect to have to make a software 
change.  RXTX actually handles this situation quite well with the -D 
command line option.  (My experience has generally been that the port 
number depends more on the USB port used than the hardware - so the 
chances are even with a hardware change the port number/name will be the 
same.)

Slightly Off Topic - there is a reason why industrial users will pay a 
premium for continued availability of hardware.  Yes you can mail-order 
a $10 USB converter and it will work, but there's no guarantee that the 
next time you buy the same part number from the same vendor it will be 
the same.  The industrial vendors will charge you $100+ for the same 
item, but it will be the same every time you buy it for the next 5 to 10 
years.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 14:37:19 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 13:37:19 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
Message-ID: <20060622203719.GA22521@freehold.crocodile.org>

Hello again,

And while I'm at it, why don't just say this: give me one good reason to
write 3+ different ways of handling removable devices, one for USB, one for
FireWire, one for serial...

I understand very well that this goes way beyond the scope of RxTx and
CommAPI and will require cooperation between them and javax.usb and whatever
JSR is responsible for FireWire implementation - but the end result is well
worth it. Abstract out and generalize arrival/departure/monitoring/discovery
API, provide protocol specific extensions for each, live happily ever after.

--vt


On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote:
> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote:
> > 
> > Vadim Tkachenko wrote:
> > > A paradigm shift is required, this is what I wanted to say. Serial devices
> > > can be removed and replaced, it's now our turn to learn to deal with it.
> > 
> > The removal if the serial port hardly significantly different from the 
> > removal of the device attached to the serial port.   Different, 
> > slightly, but not a "paradigm shift".
> > 
> > And yes, someone could unplug a USB serial device and plug it into a 
> > different USB port so that it has a different name/number, but they 
> > could do that with the device itself, move it from com1 to com2.
> > 
> > Am I missing something?
> 
> Yes, the fact that they could unplug a device A and plug a device B. With
> the introduction of the concept of removability, the notion of the serial
> port itself is not as important anymore, but the notion of the unique device
> identifier is.
> 
> Consider a situation: long running system (enterprise HVAC, tens of nodes,
> tens of thousands square feet area, hundreds of thousand dollars worth of
> equipment being conditioned, can't shut down), serial/usb device fails, is
> replaced by an identical device with a different serial #.
> 
> A little bit farfetched, but hopefully highlighting the point I'm trying to
> make.
> 
> > Jim
> 
> --vt
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx


From jredman at ergotech.com  Thu Jun 22 15:13:49 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 15:13:49 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>	<20060622191603.GA17487@freehold.crocodile.org>	<449AF278.6000903@ergotech.com>	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
Message-ID: <449B080D.9080208@ergotech.com>


Vadim Tkachenko wrote:
> Hello again,
> 
> And while I'm at it, why don't just say this: give me one good reason to
> write 3+ different ways of handling removable devices, one for USB, one for
> FireWire, one for serial...

You don't, they're all the same "I have lost communication with my 
serial device".

The only thing you could really do is improve error reporting by knowing 
the exact sub-system.  ("Device X which is/was attached to USB port Y is 
no longer functioning, please check the USB ports, the device, the 
cables and anything else you can think of that may be a cause of 
failure.")  That just requires an intelligent description of the port.

> I understand very well that this goes way beyond the scope of RxTx and
> CommAPI and will require cooperation between them and javax.usb and whatever
> JSR is responsible for FireWire implementation - but the end result is well
> worth it. Abstract out and generalize arrival/departure/monitoring/discovery
> API, provide protocol specific extensions for each, live happily ever after.

There's a huge list of pseudo-serial devices each with a different set 
of requirements, Bluetooth, RFC 2217, a host of proprietary systems, 
etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I 
have no clue how you'd implement them in a general/cross platform sense.

You haven't convinced me (and only me, others may see something that I 
don't, I'm not speaking for them) that this mechanism can be implemented 
in any practical sense.  That is, that the implementation could be wide 
enough to be consider generally available in RXTX regardless of the 
serial port implementation, platform, etc..  However, if you can come up 
with a general design and a reference implementation for one subsystem, 
I'd like to see it and might get on board.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 15:40:55 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 14:40:55 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449B080D.9080208@ergotech.com>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
Message-ID: <20060622214055.GA25497@freehold.crocodile.org>

On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote:
> 
> Vadim Tkachenko wrote:
> > Hello again,
> > 
> > And while I'm at it, why don't just say this: give me one good reason to
> > write 3+ different ways of handling removable devices, one for USB, one for
> > FireWire, one for serial...
> 
> You don't, they're all the same "I have lost communication with my 
> serial device".

"I have lost communication with my ${protocol} device".

> The only thing you could really do is improve error reporting by knowing 
> the exact sub-system.  ("Device X which is/was attached to USB port Y is 
> no longer functioning, please check the USB ports, the device, the 
> cables and anything else you can think of that may be a cause of 
> failure.")

"Device ${id} which is/was attached to ${protocol} port ${port} is no longer
functioning, please check the ${protocol} ports, the device, the
${protocol_media} and anything else you can think of that may be a cause of
failure".

>  That just requires an intelligent description of the port.

Agree absolutely.

> > I understand very well that this goes way beyond the scope of RxTx and
> > CommAPI and will require cooperation between them and javax.usb and whatever
> > JSR is responsible for FireWire implementation - but the end result is well
> > worth it. Abstract out and generalize arrival/departure/monitoring/discovery
> > API, provide protocol specific extensions for each, live happily ever after.
> 
> There's a huge list of pseudo-serial devices each with a different set 
> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, 
> etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I 
> have no clue how you'd implement them in a general/cross platform sense.

That's because some of the protocols were created decades ago when
autoconfiguration wasn't even conceived, much less practical. RS232/RS485
don't have a clue about identity discovery, and even capabilities discovery
beyond obvious 8N1 etc.

I agree that today all these protocols have generally incompatible
strategies for handling the situations I'm trying to address, but there's
nothing that says it's not an oversight. Besides, we're dealing with the
devices at a level of abstraction that allows some simplifications and
generalizations, at least part of the time - unless it's the protocol
specific features we're dealing with.

> You haven't convinced me (and only me, others may see something that I 
> don't, I'm not speaking for them) that this mechanism can be implemented 
> in any practical sense.  That is, that the implementation could be wide 
> enough to be consider generally available in RXTX regardless of the 
> serial port implementation, platform, etc..  However, if you can come up 
> with a general design and a reference implementation for one subsystem, 
> I'd like to see it and might get on board.

Actually, I wasn't even thinking about all this stuff when I wrote the first
message on the subject :) Now that you mention it - well, I'm not sure I can
chew the piece I just tried to bite in reasonable amount of time.

How do you eat an elephant? One bite at a time. If we could agree that a
small step in the specification is acceptable at this time, and express
further intentions, things may start happening.

To put it succinctly:

- Concept of a "port" should be augmented with a concept of a "device". A
device may be attached to a port in an implicit or explicit way.
- Implicitly connected device is exactly what the current scope of the
specification covers. No new functionality is offered.
- Explicitly connected device supports detachable device semantics, just as
other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a
few).
- The input and output streams are not properties of a port now, but
properties of the device attached to the port.
- A mechanism to allow listening for device arrivals and departures must be
made available.

That's it, off the top of my head.

I understand that this goes completely against current javax.comm specs, but
an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be
difficult to implement without disrupting javax.comm compatibility.

One concern is how to deal with the device identity - but there's no general
way of dealing with this at this time, devices may or may not offer identity
discovery.

> Jim

--vt


From joachim at buechse.de  Fri Jun 23 02:12:43 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 23 Jun 2006 10:12:43 +0200
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
Message-ID: <CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>

Hello++ Vadim,

I would like to repeat that your request is best addressed to the  
POSSIX standardization group - or maybe the BSD/Linux maintainers. If  
you convince the BSD or Linux guys to add this kind of functionality  
(they can as most of there VCP drivers are open source), there is a  
certain chance that other vendors will pick it up. I assure you that  
RXTX will happily provide this functionality once it's possible - I'm  
sure there is more than one maintainer that would love to add it.  
Having this concept penetrate the market may take some years though.

SHORT: The solution you would like to see could be added to the API  
but it can not be implemented (at least not on the platforms I know).  
There are currently no hooks in the kernel that allow you to discover  
"the device" or even the "means of connection" based on an existing  
"device file descriptor" ie COM-port or /dev/... entry. The name  
mapping of the device is handled by the virtual com port driver of  
the device. Unless you are suggesting RXTX should reimplement virtual  
com port drivers for all usb/serial bridges out there your request is  
understandable from a users viewpoint but simply not realizable. It's  
like asking that the Socket api should identify the computer behind  
an IP address (ie by its Ethernet address). While this COULD be  
implemented in TCP/IP, it IS not, and hence there is no point adding  
such a function to the Socket API.

The current trend for USB/Bluetooth/Irda/etc connected devices is  
going away from serial port abstraction towards RPC (ie the drivers  
provide a device specific or device class specific driver that  
provides an application level api to the device functions). The line  
level protocol is often not even published.

Best regards,
Joachim

On 22.06.2006, at 23:40, Vadim Tkachenko wrote:

> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote:
>>
>> Vadim Tkachenko wrote:
>>> Hello again,
>>>
>>> And while I'm at it, why don't just say this: give me one good  
>>> reason to
>>> write 3+ different ways of handling removable devices, one for  
>>> USB, one for
>>> FireWire, one for serial...
>>
>> You don't, they're all the same "I have lost communication with my
>> serial device".
>
> "I have lost communication with my ${protocol} device".
>
>> The only thing you could really do is improve error reporting by  
>> knowing
>> the exact sub-system.  ("Device X which is/was attached to USB  
>> port Y is
>> no longer functioning, please check the USB ports, the device, the
>> cables and anything else you can think of that may be a cause of
>> failure.")
>
> "Device ${id} which is/was attached to ${protocol} port ${port} is  
> no longer
> functioning, please check the ${protocol} ports, the device, the
> ${protocol_media} and anything else you can think of that may be a  
> cause of
> failure".
>
>>  That just requires an intelligent description of the port.
>
> Agree absolutely.
>
>>> I understand very well that this goes way beyond the scope of  
>>> RxTx and
>>> CommAPI and will require cooperation between them and javax.usb  
>>> and whatever
>>> JSR is responsible for FireWire implementation - but the end  
>>> result is well
>>> worth it. Abstract out and generalize arrival/departure/ 
>>> monitoring/discovery
>>> API, provide protocol specific extensions for each, live happily  
>>> ever after.
>>
>> There's a huge list of pseudo-serial devices each with a different  
>> set
>> of requirements, Bluetooth, RFC 2217, a host of proprietary systems,
>> etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I
>> have no clue how you'd implement them in a general/cross platform  
>> sense.
>
> That's because some of the protocols were created decades ago when
> autoconfiguration wasn't even conceived, much less practical. RS232/ 
> RS485
> don't have a clue about identity discovery, and even capabilities  
> discovery
> beyond obvious 8N1 etc.
>
> I agree that today all these protocols have generally incompatible
> strategies for handling the situations I'm trying to address, but  
> there's
> nothing that says it's not an oversight. Besides, we're dealing  
> with the
> devices at a level of abstraction that allows some simplifications and
> generalizations, at least part of the time - unless it's the protocol
> specific features we're dealing with.
>
>> You haven't convinced me (and only me, others may see something  
>> that I
>> don't, I'm not speaking for them) that this mechanism can be  
>> implemented
>> in any practical sense.  That is, that the implementation could be  
>> wide
>> enough to be consider generally available in RXTX regardless of the
>> serial port implementation, platform, etc..  However, if you can  
>> come up
>> with a general design and a reference implementation for one  
>> subsystem,
>> I'd like to see it and might get on board.
>
> Actually, I wasn't even thinking about all this stuff when I wrote  
> the first
> message on the subject :) Now that you mention it - well, I'm not  
> sure I can
> chew the piece I just tried to bite in reasonable amount of time.
>
> How do you eat an elephant? One bite at a time. If we could agree  
> that a
> small step in the specification is acceptable at this time, and  
> express
> further intentions, things may start happening.
>
> To put it succinctly:
>
> - Concept of a "port" should be augmented with a concept of a  
> "device". A
> device may be attached to a port in an implicit or explicit way.
> - Implicitly connected device is exactly what the current scope of the
> specification covers. No new functionality is offered.
> - Explicitly connected device supports detachable device semantics,  
> just as
> other protocols do (USB, FireWire, Wireless USB, Bluetooth, to  
> mention a
> few).
> - The input and output streams are not properties of a port now, but
> properties of the device attached to the port.
> - A mechanism to allow listening for device arrivals and departures  
> must be
> made available.
>
> That's it, off the top of my head.
>
> I understand that this goes completely against current javax.comm  
> specs, but
> an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern )  
> won't be
> difficult to implement without disrupting javax.comm compatibility.
>
> One concern is how to deal with the device identity - but there's  
> no general
> way of dealing with this at this time, devices may or may not offer  
> identity
> discovery.
>
>> Jim
>
> --vt
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From vt at freehold.crocodile.org  Fri Jun 23 11:28:29 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Fri, 23 Jun 2006 10:28:29 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
	<CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
Message-ID: <20060623172829.GA5335@freehold.crocodile.org>

Hello Joachim,

> I would like to repeat that your request is best addressed to the POSSIX
> standardization group - or maybe the BSD/Linux maintainers. If you
> convince the BSD or Linux guys to add this kind of functionality (they can
> as most of there VCP drivers are open source), there is a certain chance
> that other vendors will pick it up. I assure you that RXTX will happily
> provide this functionality once it's possible - I'm sure there is more
> than one maintainer that would love to add it.

I realize this thing is bigger than RxTx itself, and I'm afraid it's too
global not to cause people to laugh before they think about it :)

> Having this concept penetrate the market may take some years though.

Well, I'm sure it'll get there, the only question is - when.

> SHORT: The solution you would like to see could be added to the API but it
> can not be implemented (at least not on the platforms I know).

I guess I'm concerned about the abstraction more than I'm concerned about
the implementation at this point.
  
> There are currently no hooks in the kernel that allow you to discover  
> "the device" or even the "means of connection" based on an existing  
> "device file descriptor" ie COM-port or /dev/... entry.

Well, I'm not so sure you need to keep the literal mapping from /dev
namespace to your device namespace. As long as you can consistently offer a
virtual serial device on top of a virtual serial port, it may be irrelevant
whether you can map it into /dev. The mapping is going be schitzofrenic
anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the
representation...

> The name mapping of the device is handled by the virtual com port driver
> of the device. Unless you are suggesting RXTX should reimplement virtual
> com port drivers for all usb/serial bridges out there your request is
> understandable from a users viewpoint but simply not realizable.

It's not so much a request but rather an offer of participation. I run a few
projects actively using serial communications, as well as USB device
drivers, in different degrees of readiness (Servomaster, Haywire, DIY
Zoning) - and it would be a perfect playground.

You mentioned above that this task is about two things: a) abstraction b)
implementation. I could start the abstraction part of it without changing
the current CommAPI, on top of it, as an adapter. Even if the removable
device semantics are not implemented, but offered, this is already a step
forward.

> It's like asking that the Socket api should identify the computer behind
> an IP address (ie by its Ethernet address). While this COULD be
> implemented in TCP/IP, it IS not, and hence there is no point adding such
> a function to the Socket API.

Thank you for bringing up this example - I guess this is just about the same
thing that I'd like to see. Socket transparently provides you with the
input/output streams, at the same time offering protocol level specifics to
you.

> The current trend for USB/Bluetooth/Irda/etc connected devices is going
> away from serial port abstraction towards RPC (ie the drivers provide a
> device specific or device class specific driver that provides an
> application level api to the device functions). The line level protocol is
> often not even published.

I can't say I'm that happy with it. The best (or, rather, worst) example is
suchlike support for the Phidget servo controller - zealous Linux developers
implemented kernel module support for it, completely hijacking a possibility
of using it on a different level (it's somewhat fixed by now, thankfully).

I believe that whenever an abstraction is offered, it must be made optional
and/or pluggable so it can be replaced by something more suited to the task.

The nature of Java applications is such that they'd probably care much more
about Java API offered, than about no matter how rich application level api
that is offered outside of Java. I've dealt with JNI adapters in the past,
and whereas they can be made reasonably stable, the very fact that you are
forced to deal with things that are not on the critical timing/memory path
and could've been done much easier in Java causes endless grief.

> Joachim

--vt


From lyon at docjava.com  Sat Jun 24 04:54:12 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Sat, 24 Jun 2006 06:54:12 -0400
Subject: [Rxtx] jsr
In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
	<CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
	<20060623172829.GA5335@freehold.crocodile.org>
Message-ID: <p060204a3c0c2c9dde4f8@[192.168.1.152]>

Hi All,
I have had some off-list discussion with Trent.
Opening up a JSR with Sun, as per Peters' suggestion
seems like a reasonable idea, to us.

Does anyone having any concerns about the JSR process
that they would like to raise?

Thanks!
  - Doug



From the.grey.lantern at gmail.com  Sat Jun 24 18:15:26 2006
From: the.grey.lantern at gmail.com (Craig Nicoll)
Date: Sun, 25 Jun 2006 01:15:26 +0100
Subject: [Rxtx] Cannot create virtual serial port
Message-ID: <a1221cc50606241715g2d1e2af6r747347dd4c20e997@mail.gmail.com>

Hello,

This is my first post on this mailing list and I hope someone can help me.

I am having great difficult establishing a virtual serial port for the
Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia
7600.

Every time I try to run the SendMessage program that comes with SMSLib, I
get the following exception: gnu.io.NoSuchPortException

The port names I have tried are:
rfcomm0
rfcomm
/dev/rfcomm0
/dev/rfcomm

This is what I have done so far:
Modified /etc/bluetooth/rfcomm.conf to include the address of my phone:

rfcomm0 {
# Automatically bind the device at startup
bind no;

# Bluetooth address of the device
device 00:0e:6d:7a:98:43;

# RFCOMM channel for the connection
channel 1;

# Description of the connection
comment "Example Bluetooth device";
}

I also tried running the following command: rfcomm bind /dev/rfcomm0

I have searched the mailing list archives and found this post where someone
had a very similar problem to me:
http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried
changing the system properties as suggested and it made no difference.

I have also been scouring Google all day to no avail.

I would be incredibly grateful if anyone could give me some tips.

Thank you,

Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060625/cfa6df35/attachment-0009.html

From tjarvi at qbang.org  Sun Jun 25 19:56:08 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT)
Subject: [Rxtx] Pending release
Message-ID: <Pine.LNX.4.61.0606251942460.15744@www>


With frustration, I was unable to get to the pending release this weekend.
The release should be comming this next week once things calm down.
The source is in CVS except for a fix for multiple ports in windows.

I had planned on doing the release this weekend but that was disrupted by 
my transportation failing in a spectacular fashion.

--
Trent Jarvi
tjarvi at qbang.org


From Pawan.Kharbanda at dot.state.co.us  Tue Jun 27 22:28:51 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 27 Jun 2006 22:28:51 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>

 Trent, 
   I have an application running in a cluster in linux environment and I
am using RXTX2.1.7 (final) with JDK1.5. The application opens and closes
serial comm ports every 30 seconds and exchanges datas. I have
experienced some of my Comm Ports are left hanging (I can see the
LCK..cufXX lock files under /var/lock folder). On putting the debugs I
found out that, it is stuck at a native call line 809 in RXTXPort.java
class (Please see the code snippet below). Can you help me explain what
this method does in the native code? Am I getting into some thread
deadlocks? Thanks in advance.

Pawan Kharbanda 


public void removeEventListener()
	{
		if (debug)
			z.reportln( "RXTXPort:removeEventListener()
called");
		waitForTheNativeCodeSilly();
		//if( monThread != null && monThread.isAlive() )
		if( monThreadisInterrupted == true )
		{
			z.reportln( "	RXTXPort:removeEventListener()
already interrupted");
			monThread = null;
			SPEventListener = null;
			return;
		}
		else if( monThread != null && monThread.isAlive() )
		{
			if (debug)
				z.reportln( "
RXTXPort:Interrupt=true");
			monThreadisInterrupted=true;
			/*
			   Notify all threads in this PID that something
is up
			   They will call back to see if its their
thread
			   using isInterrupted().
			*/
			if (debug)
				z.reportln( "	RXTXPort:calling
interruptEventLoop");
// LINE 809			interruptEventLoop( ); It never returns
out of this 
			
			if (debug)
				z.reportln( "	RXTXPort:calling
monThread.join()");
			try {
				monThread.join(1000);
			} catch (Exception ex) {
				/* yikes */
				ex.printStackTrace();
			}
			if (debug)
				z.reportln( "	RXTXPort:waiting on
isAlive()");
			while( monThread.isAlive() )
			{
				if ( debug )
					z.reportln( "	MonThread is
still alive!");
				try {
					monThread.join(1000);
					Thread.sleep( 1000 );
				} catch( Exception e ){} 
				//monThread.stop();
			}
			
		}
		if (debug)
			z.reportln( "	RXTXPort:calling gc()");
		monThread = null;
		SPEventListener = null;
		MonitorThreadLock = false;
		MonitorThreadAlive=false;
		monThreadisInterrupted=true;
		z.reportln( "RXTXPort:removeEventListener() returning");
	} 

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Sunday, June 25, 2006 7:56 PM
To: rxtx at qbang.org
Subject: [Rxtx] Pending release


With frustration, I was unable to get to the pending release this
weekend.
The release should be comming this next week once things calm down.
The source is in CVS except for a fix for multiple ports in windows.

I had planned on doing the release this weekend but that was disrupted
by my transportation failing in a spectacular fashion.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Wed Jun 28 04:17:29 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 28 Jun 2006 04:17:29 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606280406330.9561@www>



Hi Pawan

You may have found a deadlock but I've not seen on recently on linux.

If you can, please update from CVS.  This will have some close fixes. 
I'm running with the same code as is in CVS.  It is not perfect but I've 
not seen anything like you mention.  Be sure to set timeouts and 
thresholds on the port.  It may be that the port is waiting on pending io 
that never happens.  I think the CVS patches deal with this also but it 
looks like your in a better test environment to know for sure.

The exploded vehicle mentioned below is expected to be fixed today.  It 
was just a ninja small radiator hose.  The pressure test afterwards 
created its own set of problems.  Until this is resolved, I'm spending 
most of my free time commuting by bicycle.

On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>   I have an application running in a cluster in linux environment and I
> am using RXTX2.1.7 (final) with JDK1.5. The application opens and closes
> serial comm ports every 30 seconds and exchanges datas. I have
> experienced some of my Comm Ports are left hanging (I can see the
> LCK..cufXX lock files under /var/lock folder). On putting the debugs I
> found out that, it is stuck at a native call line 809 in RXTXPort.java
> class (Please see the code snippet below). Can you help me explain what
> this method does in the native code? Am I getting into some thread
> deadlocks? Thanks in advance.
>
> Pawan Kharbanda
>
>
> public void removeEventListener()
> 	{
> 		if (debug)
> 			z.reportln( "RXTXPort:removeEventListener()
> called");
> 		waitForTheNativeCodeSilly();
> 		//if( monThread != null && monThread.isAlive() )
> 		if( monThreadisInterrupted == true )
> 		{
> 			z.reportln( "	RXTXPort:removeEventListener()
> already interrupted");
> 			monThread = null;
> 			SPEventListener = null;
> 			return;
> 		}
> 		else if( monThread != null && monThread.isAlive() )
> 		{
> 			if (debug)
> 				z.reportln( "
> RXTXPort:Interrupt=true");
> 			monThreadisInterrupted=true;
> 			/*
> 			   Notify all threads in this PID that something
> is up
> 			   They will call back to see if its their
> thread
> 			   using isInterrupted().
> 			*/
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> interruptEventLoop");
> // LINE 809			interruptEventLoop( ); It never returns
> out of this
>
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> monThread.join()");
> 			try {
> 				monThread.join(1000);
> 			} catch (Exception ex) {
> 				/* yikes */
> 				ex.printStackTrace();
> 			}
> 			if (debug)
> 				z.reportln( "	RXTXPort:waiting on
> isAlive()");
> 			while( monThread.isAlive() )
> 			{
> 				if ( debug )
> 					z.reportln( "	MonThread is
> still alive!");
> 				try {
> 					monThread.join(1000);
> 					Thread.sleep( 1000 );
> 				} catch( Exception e ){}
> 				//monThread.stop();
> 			}
>
> 		}
> 		if (debug)
> 			z.reportln( "	RXTXPort:calling gc()");
> 		monThread = null;
> 		SPEventListener = null;
> 		MonitorThreadLock = false;
> 		MonitorThreadAlive=false;
> 		monThreadisInterrupted=true;
> 		z.reportln( "RXTXPort:removeEventListener() returning");
> 	}
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Sunday, June 25, 2006 7:56 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] Pending release
>
>
> With frustration, I was unable to get to the pending release this
> weekend.
> The release should be comming this next week once things calm down.
> The source is in CVS except for a fix for multiple ports in windows.
>
> I had planned on doing the release this weekend but that was disrupted
> by my transportation failing in a spectacular fashion.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From Pawan.Kharbanda at dot.state.co.us  Wed Jun 28 12:11:06 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Wed, 28 Jun 2006 12:11:06 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>

Trent,
    Again thanks for the reply. First of all I have Receive timeouts set
on all communications including Max no of bytes to expect during the
call. I have noticed the problem is during "closing the connection". I
am not sure if the RXTX is 100% thread-safe yet. There seems to be a
glitch in the native calls. I am sure I have the latest code I did the
update on the Version 2.1.7 from CVS, is this where the latest updates
are located, I have noticed another version in CVS "rxtx-devel".

Regards
Pawan Kharbanda

    

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Wednesday, June 28, 2006 4:17 AM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports



Hi Pawan

You may have found a deadlock but I've not seen on recently on linux.

If you can, please update from CVS.  This will have some close fixes. 
I'm running with the same code as is in CVS.  It is not perfect but I've
not seen anything like you mention.  Be sure to set timeouts and
thresholds on the port.  It may be that the port is waiting on pending
io that never happens.  I think the CVS patches deal with this also but
it looks like your in a better test environment to know for sure.

The exploded vehicle mentioned below is expected to be fixed today.  It
was just a ninja small radiator hose.  The pressure test afterwards
created its own set of problems.  Until this is resolved, I'm spending
most of my free time commuting by bicycle.

On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>   I have an application running in a cluster in linux environment and 
> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and 
> closes serial comm ports every 30 seconds and exchanges datas. I have 
> experienced some of my Comm Ports are left hanging (I can see the 
> LCK..cufXX lock files under /var/lock folder). On putting the debugs I

> found out that, it is stuck at a native call line 809 in RXTXPort.java

> class (Please see the code snippet below). Can you help me explain 
> what this method does in the native code? Am I getting into some 
> thread deadlocks? Thanks in advance.
>
> Pawan Kharbanda
>
>
> public void removeEventListener()
> 	{
> 		if (debug)
> 			z.reportln( "RXTXPort:removeEventListener()
called");
> 		waitForTheNativeCodeSilly();
> 		//if( monThread != null && monThread.isAlive() )
> 		if( monThreadisInterrupted == true )
> 		{
> 			z.reportln( "	RXTXPort:removeEventListener()
> already interrupted");
> 			monThread = null;
> 			SPEventListener = null;
> 			return;
> 		}
> 		else if( monThread != null && monThread.isAlive() )
> 		{
> 			if (debug)
> 				z.reportln( "
> RXTXPort:Interrupt=true");
> 			monThreadisInterrupted=true;
> 			/*
> 			   Notify all threads in this PID that something
is up
> 			   They will call back to see if its their
thread
> 			   using isInterrupted().
> 			*/
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> interruptEventLoop");
> // LINE 809			interruptEventLoop( ); It never returns
> out of this
>
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> monThread.join()");
> 			try {
> 				monThread.join(1000);
> 			} catch (Exception ex) {
> 				/* yikes */
> 				ex.printStackTrace();
> 			}
> 			if (debug)
> 				z.reportln( "	RXTXPort:waiting on
> isAlive()");
> 			while( monThread.isAlive() )
> 			{
> 				if ( debug )
> 					z.reportln( "	MonThread is
> still alive!");
> 				try {
> 					monThread.join(1000);
> 					Thread.sleep( 1000 );
> 				} catch( Exception e ){}
> 				//monThread.stop();
> 			}
>
> 		}
> 		if (debug)
> 			z.reportln( "	RXTXPort:calling gc()");
> 		monThread = null;
> 		SPEventListener = null;
> 		MonitorThreadLock = false;
> 		MonitorThreadAlive=false;
> 		monThreadisInterrupted=true;
> 		z.reportln( "RXTXPort:removeEventListener() returning");
> 	}
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf

> Of Trent Jarvi
> Sent: Sunday, June 25, 2006 7:56 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] Pending release
>
>
> With frustration, I was unable to get to the pending release this 
> weekend.
> The release should be comming this next week once things calm down.
> The source is in CVS except for a fix for multiple ports in windows.
>
> I had planned on doing the release this weekend but that was disrupted

> by my transportation failing in a spectacular fashion.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Wed Jun 28 12:26:21 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 28 Jun 2006 12:26:21 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606281222420.9561@www>


Hi Pawan

If you did a cvs update from the 2.1-7 tar ball, you have the current 
version.  All rxtx in CVS is under rxtx-devel.  The 2.1-7 just has -r
commapi-0-0-1.

You may well have found something.  I have seen win32 fail on closing 
ports but not linux that I can think of.  Your use is much different than 
I normally see too.

Could you give us more information on how we would reproduce this and the 
frequency?


On Wed, 28 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>    Again thanks for the reply. First of all I have Receive timeouts set
> on all communications including Max no of bytes to expect during the
> call. I have noticed the problem is during "closing the connection". I
> am not sure if the RXTX is 100% thread-safe yet. There seems to be a
> glitch in the native calls. I am sure I have the latest code I did the
> update on the Version 2.1.7 from CVS, is this where the latest updates
> are located, I have noticed another version in CVS "rxtx-devel".
>
> Regards
> Pawan Kharbanda
>
>
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Wednesday, June 28, 2006 4:17 AM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] Locked Ports
>
>
>
> Hi Pawan
>
> You may have found a deadlock but I've not seen on recently on linux.
>
> If you can, please update from CVS.  This will have some close fixes.
> I'm running with the same code as is in CVS.  It is not perfect but I've
> not seen anything like you mention.  Be sure to set timeouts and
> thresholds on the port.  It may be that the port is waiting on pending
> io that never happens.  I think the CVS patches deal with this also but
> it looks like your in a better test environment to know for sure.
>
> The exploded vehicle mentioned below is expected to be fixed today.  It
> was just a ninja small radiator hose.  The pressure test afterwards
> created its own set of problems.  Until this is resolved, I'm spending
> most of my free time commuting by bicycle.
>
> On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:
>
>> Trent,
>>   I have an application running in a cluster in linux environment and
>> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and
>> closes serial comm ports every 30 seconds and exchanges datas. I have
>> experienced some of my Comm Ports are left hanging (I can see the
>> LCK..cufXX lock files under /var/lock folder). On putting the debugs I
>
>> found out that, it is stuck at a native call line 809 in RXTXPort.java
>
>> class (Please see the code snippet below). Can you help me explain
>> what this method does in the native code? Am I getting into some
>> thread deadlocks? Thanks in advance.
>>
>> Pawan Kharbanda
>>
>>
>> public void removeEventListener()
>> 	{
>> 		if (debug)
>> 			z.reportln( "RXTXPort:removeEventListener()
> called");
>> 		waitForTheNativeCodeSilly();
>> 		//if( monThread != null && monThread.isAlive() )
>> 		if( monThreadisInterrupted == true )
>> 		{
>> 			z.reportln( "	RXTXPort:removeEventListener()
>> already interrupted");
>> 			monThread = null;
>> 			SPEventListener = null;
>> 			return;
>> 		}
>> 		else if( monThread != null && monThread.isAlive() )
>> 		{
>> 			if (debug)
>> 				z.reportln( "
>> RXTXPort:Interrupt=true");
>> 			monThreadisInterrupted=true;
>> 			/*
>> 			   Notify all threads in this PID that something
> is up
>> 			   They will call back to see if its their
> thread
>> 			   using isInterrupted().
>> 			*/
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> interruptEventLoop");
>> // LINE 809			interruptEventLoop( ); It never returns
>> out of this
>>
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> monThread.join()");
>> 			try {
>> 				monThread.join(1000);
>> 			} catch (Exception ex) {
>> 				/* yikes */
>> 				ex.printStackTrace();
>> 			}
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:waiting on
>> isAlive()");
>> 			while( monThread.isAlive() )
>> 			{
>> 				if ( debug )
>> 					z.reportln( "	MonThread is
>> still alive!");
>> 				try {
>> 					monThread.join(1000);
>> 					Thread.sleep( 1000 );
>> 				} catch( Exception e ){}
>> 				//monThread.stop();
>> 			}
>>
>> 		}
>> 		if (debug)
>> 			z.reportln( "	RXTXPort:calling gc()");
>> 		monThread = null;
>> 		SPEventListener = null;
>> 		MonitorThreadLock = false;
>> 		MonitorThreadAlive=false;
>> 		monThreadisInterrupted=true;
>> 		z.reportln( "RXTXPort:removeEventListener() returning");
>> 	}
>>
>> -----Original Message-----
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
>
>> Of Trent Jarvi
>> Sent: Sunday, June 25, 2006 7:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] Pending release
>>
>>
>> With frustration, I was unable to get to the pending release this
>> weekend.
>> The release should be comming this next week once things calm down.
>> The source is in CVS except for a fix for multiple ports in windows.
>>
>> I had planned on doing the release this weekend but that was disrupted
>
>> by my transportation failing in a spectacular fashion.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From Pawan.Kharbanda at dot.state.co.us  Wed Jun 28 15:42:49 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Wed, 28 Jun 2006 15:42:49 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>

Trent,
    I will try to explain how I am setup and will try to write you a
Sample code little later to reproduce this. On our system we have
DigiBoxes installed on the 2 Linux servers. Both of them have RXTX2.1-7
version installed with the JRE(1.5) and both the machines have the same
port mappings in gnu.io.rxtx.properties (Currently in the production
system I have 64 ports). This is how the system works:

1) A thick Map based client initiates a Action on the Device on the
field. One of the Thread Workers(Asynchronous Call) in the Cluster picks
up the request. 
2) Once the worker gets the request it locks the Device and
Communication port in the DB's(These are our persistent locks, because
most of the devices do one to one communication with the serial ports).
After that the worker (or Comm Server) opens up the connection and after
exchanging the information calls the "Close" and returns.
3) Once the connection is closed , the DB lock is removed on the comm
port and is made available to accept future calls. Here is where the
glitch is the Serial Comm Close method never returns due to the
deadlock. 

I have noticed that the deadlocks are very inconsistent, sometime it
happens right away as soon as Application server starts and sometimes I
don't see any deadlocks for days, but it happens for sure. 

Here is how you can test if you have resources/ test environment. Write
a program and try to open/close  different ports(I will say have a
minimum of four) randomly and very frequently(may be 30 seconds), I am
pretty sure you will see the deadlocks and it happens in the native call
to interrptEventLoop in RXTXPort.java in removeEventListener() method
call.

Also I have noticed that the JVM carshes (without any memrory errors or
JVM errors. Its just not there) when native call is made to eventLoop()
in run() method in MonitorThread inner class. I am still investigating
why this is happening, but at this point I can just tell you the
location. You might have a question How I am so sure about the location?
My application is configured with Log4J and I have enabled the debugs on
the RXTXPort.java, so every time my JVM dies I see these logs at the end
of the file.

"2006-06-28 15:27:15,183 INFO  [STDOUT] RXTXPort:RXTXPort(/dev/cub01)
called
2006-06-28 15:27:15,218 INFO  [STDOUT]
RXTXPort:MontitorThread:MonitorThread()
2006-06-28 15:27:15,219 INFO  [STDOUT] RXTXPort:MontitorThread:run()"

I surely do have a luxury of a testing environment(ports, devices etc.)
and can help you fix these problems? Please advise me how we can resolve
these issues.

Thanks 
Pawan Kharbanda
303-478-2991





-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Wednesday, June 28, 2006 12:26 PM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports


Hi Pawan

If you did a cvs update from the 2.1-7 tar ball, you have the current
version.  All rxtx in CVS is under rxtx-devel.  The 2.1-7 just has -r
commapi-0-0-1.

You may well have found something.  I have seen win32 fail on closing
ports but not linux that I can think of.  Your use is much different
than I normally see too.

Could you give us more information on how we would reproduce this and
the frequency?


On Wed, 28 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>    Again thanks for the reply. First of all I have Receive timeouts
set
> on all communications including Max no of bytes to expect during the
> call. I have noticed the problem is during "closing the connection". I
> am not sure if the RXTX is 100% thread-safe yet. There seems to be a
> glitch in the native calls. I am sure I have the latest code I did the
> update on the Version 2.1.7 from CVS, is this where the latest updates
> are located, I have noticed another version in CVS "rxtx-devel".
>
> Regards
> Pawan Kharbanda
>
>
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Wednesday, June 28, 2006 4:17 AM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] Locked Ports
>
>
>
> Hi Pawan
>
> You may have found a deadlock but I've not seen on recently on linux.
>
> If you can, please update from CVS.  This will have some close fixes.
> I'm running with the same code as is in CVS.  It is not perfect but
I've
> not seen anything like you mention.  Be sure to set timeouts and
> thresholds on the port.  It may be that the port is waiting on pending
> io that never happens.  I think the CVS patches deal with this also
but
> it looks like your in a better test environment to know for sure.
>
> The exploded vehicle mentioned below is expected to be fixed today.
It
> was just a ninja small radiator hose.  The pressure test afterwards
> created its own set of problems.  Until this is resolved, I'm spending
> most of my free time commuting by bicycle.
>
> On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:
>
>> Trent,
>>   I have an application running in a cluster in linux environment and
>> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and
>> closes serial comm ports every 30 seconds and exchanges datas. I have
>> experienced some of my Comm Ports are left hanging (I can see the
>> LCK..cufXX lock files under /var/lock folder). On putting the debugs
I
>
>> found out that, it is stuck at a native call line 809 in
RXTXPort.java
>
>> class (Please see the code snippet below). Can you help me explain
>> what this method does in the native code? Am I getting into some
>> thread deadlocks? Thanks in advance.
>>
>> Pawan Kharbanda
>>
>>
>> public void removeEventListener()
>> 	{
>> 		if (debug)
>> 			z.reportln( "RXTXPort:removeEventListener()
> called");
>> 		waitForTheNativeCodeSilly();
>> 		//if( monThread != null && monThread.isAlive() )
>> 		if( monThreadisInterrupted == true )
>> 		{
>> 			z.reportln( "	RXTXPort:removeEventListener()
>> already interrupted");
>> 			monThread = null;
>> 			SPEventListener = null;
>> 			return;
>> 		}
>> 		else if( monThread != null && monThread.isAlive() )
>> 		{
>> 			if (debug)
>> 				z.reportln( "
>> RXTXPort:Interrupt=true");
>> 			monThreadisInterrupted=true;
>> 			/*
>> 			   Notify all threads in this PID that something
> is up
>> 			   They will call back to see if its their
> thread
>> 			   using isInterrupted().
>> 			*/
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> interruptEventLoop");
>> // LINE 809			interruptEventLoop( ); It never returns
>> out of this
>>
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> monThread.join()");
>> 			try {
>> 				monThread.join(1000);
>> 			} catch (Exception ex) {
>> 				/* yikes */
>> 				ex.printStackTrace();
>> 			}
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:waiting on
>> isAlive()");
>> 			while( monThread.isAlive() )
>> 			{
>> 				if ( debug )
>> 					z.reportln( "	MonThread is
>> still alive!");
>> 				try {
>> 					monThread.join(1000);
>> 					Thread.sleep( 1000 );
>> 				} catch( Exception e ){}
>> 				//monThread.stop();
>> 			}
>>
>> 		}
>> 		if (debug)
>> 			z.reportln( "	RXTXPort:calling gc()");
>> 		monThread = null;
>> 		SPEventListener = null;
>> 		MonitorThreadLock = false;
>> 		MonitorThreadAlive=false;
>> 		monThreadisInterrupted=true;
>> 		z.reportln( "RXTXPort:removeEventListener() returning");
>> 	}
>>
>> -----Original Message-----
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On
Behalf
>
>> Of Trent Jarvi
>> Sent: Sunday, June 25, 2006 7:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] Pending release
>>
>>
>> With frustration, I was unable to get to the pending release this
>> weekend.
>> The release should be comming this next week once things calm down.
>> The source is in CVS except for a fix for multiple ports in windows.
>>
>> I had planned on doing the release this weekend but that was
disrupted
>
>> by my transportation failing in a spectacular fashion.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx 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 khattar31 at yahoo.com  Wed Jun 28 22:04:59 2006
From: khattar31 at yahoo.com (rahul khattar)
Date: Wed, 28 Jun 2006 21:04:59 -0700 (PDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
Message-ID: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>

Hi All,

I was looking at the src file on the last release.
I did notice a missing header file while trying to
compile the parallelport.dll. Would somebody be kind
enoughf to share the missing header file:
gnu_io_LPRPort.h

I am using MinGw to compile the same from Parinya
(which is an execellent tool)


Regards,
Rahul Khattar

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Thu Jun 29 03:43:53 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 03:43:53 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>
References: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606290341210.9561@www>

On Wed, 28 Jun 2006, rahul khattar wrote:

> Hi All,
>
> I was looking at the src file on the last release.
> I did notice a missing header file while trying to
> compile the parallelport.dll. Would somebody be kind
> enoughf to share the missing header file:
> gnu_io_LPRPort.h
>
> I am using MinGw to compile the same from Parinya
> (which is an execellent tool)
>

Hi Rahul

The gnu.io_LPRPort.h file is generated with javah.  You can see the 
command in the Makefile I presume.  You do not need rxtxParallel.dll to 
use w32 serial btw.

--
Trent Jarvi
tjarvi at qbang.org


From khattar31 at yahoo.com  Thu Jun 29 04:47:01 2006
From: khattar31 at yahoo.com (rahul khattar)
Date: Thu, 29 Jun 2006 03:47:01 -0700 (PDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606290341210.9561@www>
Message-ID: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>

Hi Trent 
I did notice this file is required in the source file
ParallelImp.c
on line 38

Attached the O/P 

Regards,
Rahul Khattar




--- Trent Jarvi <tjarvi at qbang.org> wrote:

> On Wed, 28 Jun 2006, rahul khattar wrote:
> 
> > Hi All,
> >
> > I was looking at the src file on the last release.
> > I did notice a missing header file while trying to
> > compile the parallelport.dll. Would somebody be
> kind
> > enoughf to share the missing header file:
> > gnu_io_LPRPort.h
> >
> > I am using MinGw to compile the same from Parinya
> > (which is an execellent tool)
> >
> 
> Hi Rahul
> 
> The gnu.io_LPRPort.h file is generated with javah. 
> You can see the 
> command in the Makefile I presume.  You do not need
> rxtxParallel.dll to 
> use w32 serial btw.
> 
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Error.zip
Type: application/x-zip-compressed
Size: 1746 bytes
Desc: 2948039066-Error.zip
Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060629/a5b6f783/Error-0018.bin

From tjarvi at qbang.org  Thu Jun 29 06:16:24 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 06:16:24 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606290614530.9561@www>

On Thu, 29 Jun 2006, rahul khattar wrote:

> Hi Trent
> I did notice this file is required in the source file
> ParallelImp.c
> on line 38
>
> Attached the O/P
>

The command to generate the .h file will be something like:

javah -classpath . -jni gnu.io.LPRPort

The makefile should have this.  There are several approaches to creating 
or using makefiles so I have no idea which one you used if any.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Thu Jun 29 06:20:51 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 06:20:51 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606290616420.9561@www>

> Here is how you can test if you have resources/ test environment. Write
> a program and try to open/close  different ports(I will say have a
> minimum of four) randomly and very frequently(may be 30 seconds), I am
> pretty sure you will see the deadlocks and it happens in the native call
> to interrptEventLoop in RXTXPort.java in removeEventListener() method
> call.

Hi Pawan

I'll try to find a way to reproduce this.  One thing to note is that you 
are using different kernel drivers (digi) to perform this task.  So I 
probably will not be able to reproduce the exact same environment.

In general, multiport kernel drivers have been tested far less than 
typical serial drivers.  This may or may not be an issue.

--
Trent Jarvi
tjarvi at qbang.org



From jhaysonn at gmail.com  Thu Jun 29 12:29:13 2006
From: jhaysonn at gmail.com (jhaysonn pathak)
Date: Thu, 29 Jun 2006 14:29:13 -0400
Subject: [Rxtx] RXTX install
Message-ID: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>

Hi Guys,

I'm doing trying to write a generative piece of Sonic Art using an EEG
plugged into a mac runnning Max/MSP.  I just recently discovered RXTX
drivers in my search for a piece of software that might give me more
output options for my EEG (I'm using the CEO from MindPeak).  I found
Bioera which uses RXTX drivers.  Thing is - I can't figure out how to
install RXTX correctly.

After I build the 'libSerial.jnilib' target inside of
'LibSerial.pbproj' I can't find the libSerial.jnilib file that
accompanies the RXTXcomm.jar nor do I know where to put them.

I also don't understand this part at the bottom of the OS X instructions at all:

"AFTER INSTALLATION VERY IMPORTANT
	check existence of the folder /var/spool/uucp
	if you don't have it create it with command
	sudo mkdir /var/spool/uucp
	permissions should be: drwxrwxr-x
	if they are not do command
	sudo chmod 775 /var/spool/uucp

	YOU should be a member of the uucp group
	you can check it with command
		niutil -readprop / /groups/uucp users
	you should see your name in output of the niutil command
	if you don't do following:
		sudo niutil -appendprop / /groups/uucp users <yourname>
			substitute  <yourname> with your user's name
			for example if your user name is peter:
				sudo niutil -appendprop / /groups/uucp users peter

	NOTES: RXTX.pkg should create uucp folder and insert your name  in
uucp group automatically"



I really appreciate any help that you guys can offer.  I've been
struggling with this for a while now as part of a research grant that
I was awarded.  Thanks again for the help.

Jhaysonn Pathak


From naranjo.manuel at gmail.com  Thu Jun 29 07:19:15 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 10:19:15 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606290614530.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www>
Message-ID: <44A3D353.6010605@gmail.com>

Speaking about Windows Support, I had seen that inside the 
rxtx-2.1-7-bins-r2 package inside Windows directory it says:
"i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will 
not make harm to anyone, and i'm almost sure that someone has noticed it 
before.
Cheers,
Manuel


From joachim at buechse.de  Thu Jun 29 13:25:16 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 29 Jun 2006 21:25:16 +0200
Subject: [Rxtx] RXTX install
In-Reply-To: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>
References: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>
Message-ID: <2A003E42-97E1-4237-8438-646BDE2E3961@buechse.de>

Hello Jhaysonn,

I assume you are trying to use the javax.comm version of RXTX.

Please use "cvs up" to update your download to the latest version of  
the repository. The latest version does not use lock files, so the  
mentioned process is no longer needed. Updating with CVS will also  
provide you with a new README.OSX file that should be simpler to  
understand.

You will find LibSerialUniversal.xcodeproj in MACOSX_IDE/Xcode. Put  
comm.jar (downloaded from Sun) into MACOSX_IDE/Xcode. Compile the  
library. You will find RXTXcomm.jar and librxtxSerial.jnilib in  
MACOSX_IDE/Xcode/build/Default

Best regards,
Joachim
---
Joachim B?chse
Softwarel?sungen und Beratung
Hadlaubsteig 2
CH-8006 Z?rich


On 29.06.2006, at 20:29, jhaysonn pathak wrote:

> Hi Guys,
>
> I'm doing trying to write a generative piece of Sonic Art using an EEG
> plugged into a mac runnning Max/MSP.  I just recently discovered RXTX
> drivers in my search for a piece of software that might give me more
> output options for my EEG (I'm using the CEO from MindPeak).  I found
> Bioera which uses RXTX drivers.  Thing is - I can't figure out how to
> install RXTX correctly.
>
> After I build the 'libSerial.jnilib' target inside of
> 'LibSerial.pbproj' I can't find the libSerial.jnilib file that
> accompanies the RXTXcomm.jar nor do I know where to put them.
>
> I also don't understand this part at the bottom of the OS X  
> instructions at all:
>
> "AFTER INSTALLATION VERY IMPORTANT
> 	check existence of the folder /var/spool/uucp
> 	if you don't have it create it with command
> 	sudo mkdir /var/spool/uucp
> 	permissions should be: drwxrwxr-x
> 	if they are not do command
> 	sudo chmod 775 /var/spool/uucp
>
> 	YOU should be a member of the uucp group
> 	you can check it with command
> 		niutil -readprop / /groups/uucp users
> 	you should see your name in output of the niutil command
> 	if you don't do following:
> 		sudo niutil -appendprop / /groups/uucp users <yourname>
> 			substitute  <yourname> with your user's name
> 			for example if your user name is peter:
> 				sudo niutil -appendprop / /groups/uucp users peter
>
> 	NOTES: RXTX.pkg should create uucp folder and insert your name  in
> uucp group automatically"
>
>
>
> I really appreciate any help that you guys can offer.  I've been
> struggling with this for a while now as part of a research grant that
> I was awarded.  Thanks again for the help.
>
> Jhaysonn Pathak
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From tjarvi at qbang.org  Thu Jun 29 19:30:00 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 19:30:00 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A3D353.6010605@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
Message-ID: <Pine.LNX.4.61.0606291923000.9561@www>

On Thu, 29 Jun 2006, Manuel Naranjo wrote:

> Speaking about Windows Support, I had seen that inside the
> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
> not make harm to anyone, and i'm almost sure that someone has noticed it
> before.

Hi Manuel

         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
     47421  01-30-06 00:23 
rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
     77759  03-01-06 12:01 
rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README


It looks normal to me.  There are no fancy tools used there :)

--
Trent Jarvi
tjarvi at qbang.org

From naranjo.manuel at gmail.com  Thu Jun 29 19:38:16 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 22:38:16 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606291923000.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com> <Pine.LNX.4.61.0606291923000.9561@www>
Message-ID: <44A48088.2040407@gmail.com>

> On Thu, 29 Jun 2006, Manuel Naranjo wrote:
> 
>> Speaking about Windows Support, I had seen that inside the
>> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
>> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
>> not make harm to anyone, and i'm almost sure that someone has noticed it
>> before.
> 
> Hi Manuel
> 
>         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
>         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
>     47421  01-30-06 00:23 
> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
>     77759  03-01-06 12:01 
> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
>       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README
> 
> 
> It looks normal to me.  There are no fancy tools used there :)
> 
Hi Trent:
Is not the i368 representing the name of the Architecture?? If so the 
name should start with i386 it will not break any system, is simply miss
written, I saw that and wanted to report it. It a silly thing.
Ohh I forgoten I must congratulate you for your GREAT libray, I was able 
to make an .exe with JSmooth that launches an application that uses RXTX 
with out the need to install RXTX on users system :). The .exe tells JVM 
where to find the RXTX Library and Binaries. I tried with Sun's Java 
Comm but it was imposible.
Regards,
Manuel


From tjarvi at qbang.org  Thu Jun 29 19:52:45 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 19:52:45 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A48088.2040407@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
	<Pine.LNX.4.61.0606291923000.9561@www> <44A48088.2040407@gmail.com>
Message-ID: <Pine.LNX.4.61.0606291945060.9561@www>

On Thu, 29 Jun 2006, Manuel Naranjo wrote:

>> On Thu, 29 Jun 2006, Manuel Naranjo wrote:
>>
>>> Speaking about Windows Support, I had seen that inside the
>>> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
>>> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
>>> not make harm to anyone, and i'm almost sure that someone has noticed it
>>> before.
>>
>> Hi Manuel
>>
>>         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
>>         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
>>     47421  01-30-06 00:23
>> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
>>     77759  03-01-06 12:01
>> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
>>       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README
>>
>>
>> It looks normal to me.  There are no fancy tools used there :)
>>
> Hi Trent:
> Is not the i368 representing the name of the Architecture?? If so the
> name should start with i386 it will not break any system, is simply miss
> written, I saw that and wanted to report it. It a silly thing.
> Ohh I forgoten I must congratulate you for your GREAT libray, I was able
> to make an .exe with JSmooth that launches an application that uses RXTX
> with out the need to install RXTX on users system :). The .exe tells JVM
> where to find the RXTX Library and Binaries. I tried with Sun's Java
> Comm but it was imposible.

Hi Manuel

The compiler uses only the i386 instruction set for windows.  I doubt 
there will be any measurable advantages with going to later instruction 
sets.  In theory rxtx would run on a 386 but I doubt anyone does that.

So it looks odd but is not a typo.

We could compile to i686 but don't.  The compiler used does not appear to 
be a problem yet so I don't see any point in changing it.  Right now, we 
could not compile 64 bit windows binaries.  gcc/mingw/... do not support 
them that I know of.  People will have to compile those with closed source 
tools on their own until an option is available.

--
Trent Jarvi
tjarvi at qbang.org

From naranjo.manuel at gmail.com  Thu Jun 29 20:00:48 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 23:00:48 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606291945060.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com>	<Pine.LNX.4.61.0606291923000.9561@www>
	<44A48088.2040407@gmail.com> <Pine.LNX.4.61.0606291945060.9561@www>
Message-ID: <44A485D0.7050202@gmail.com>

Trent you did not get my point
The folder says 368 three hundred sixty eight, when
it should say 386 three hundred eighty six. Is simply a miss writting.
Regards,
Manuel


From tjarvi at qbang.org  Thu Jun 29 20:12:15 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 20:12:15 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A485D0.7050202@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
	<Pine.LNX.4.61.0606291923000.9561@www> <44A48088.2040407@gmail.com>
	<Pine.LNX.4.61.0606291945060.9561@www> <44A485D0.7050202@gmail.com>
Message-ID: <Pine.LNX.4.61.0606292008061.9561@www>


On Thu, 29 Jun 2006, Manuel Naranjo wrote:

> Trent you did not get my point
> The folder says 368 three hundred sixty eight, when
> it should say 386 three hundred eighty six. Is simply a miss writting.

hehe..  OK.  My bad.  It's been a long day.

Nevermind :)

--
Trent Jarvi
tjarvi at qbang.org




From naranjo.manuel at gmail.com  Thu Jun 29 20:18:44 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 23:18:44 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606292008061.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com>	<Pine.LNX.4.61.0606291923000.9561@www>
	<44A48088.2040407@gmail.com>	<Pine.LNX.4.61.0606291945060.9561@www>
	<44A485D0.7050202@gmail.com> <Pine.LNX.4.61.0606292008061.9561@www>
Message-ID: <44A48A04.9040401@gmail.com>

Don't worry Trent.
About 64 bits compilation, I would like to colaborate, I have a Pc with 
64 bits, the only problem is that i do not have windows 64 bits 
installed :(.




From Pawan.Kharbanda at dot.state.co.us  Fri Jun 30 08:49:52 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 30 Jun 2006 08:49:52 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E996@hqexchange3.dot.state.co.us>

Trent,  
    Can you explain what the interruptedEventLoop() native method is
doing is there a possibility that method is somehow getting into the
infinite loop(there are 2 while loops without any break statements).
This might be a very basic question how can I debug the native code(or
print the debug statements).  Again thanks for the help. 

Pawan Kharbanda

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Thursday, June 29, 2006 6:21 AM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports

> Here is how you can test if you have resources/ test environment. 
> Write a program and try to open/close  different ports(I will say have

> a minimum of four) randomly and very frequently(may be 30 seconds), I 
> am pretty sure you will see the deadlocks and it happens in the native

> call to interrptEventLoop in RXTXPort.java in removeEventListener() 
> method call.

Hi Pawan

I'll try to find a way to reproduce this.  One thing to note is that you
are using different kernel drivers (digi) to perform this task.  So I
probably will not be able to reproduce the exact same environment.

In general, multiport kernel drivers have been tested far less than
typical serial drivers.  This may or may not be an issue.

--
Trent Jarvi
tjarvi at qbang.org

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From cpine at wrsystems.com  Thu Jun 29 15:17:12 2006
From: cpine at wrsystems.com (Chris Pine)
Date: Thu, 29 Jun 2006 17:17:12 -0400
Subject: [Rxtx]  Controlling Individual Signals DTR and RTS
Message-ID: <MAIL4FJo0S8ACLEBajJ000005cf@mail4.wrsystems.com>

Dear Moussa Ba,
	I hope I am not being too forward, but we are having the exact same
issue with needing to control DTR from RXTX in Linux.  Did you ever have any
luck figuring it out?

Thank you very much for your time,

Chris Pine




From tjarvi at qbang.org  Thu Jun  1 11:13:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 11:13:40 -0600 (MDT)
Subject: [Rxtx] custom baud rate win32
In-Reply-To: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606011107210.30220@www>


Hi Daren

I can't imagine that 1953 is possibly the actual value on the UART.  Maybe 
if your baud base is very high with a custom serial board.  More likely, 
the driver just remembers that what you asked for and did something else.

I'll have more to say on the dcb->BaudRate after I try some things here. 
I have managed to do something like that in the past as a quick hack but 
it was for 14400.  I may have used the CBR_14400.

If we can't access this through the win32 API with protected mode, there 
is another layer of complication.  With real mode, it would be easy.
With protected mode, I assume there would have to be some kernel driver or 
a hook I'm not aware of to access the MCR directly (bang a memory 
addresss).



On Thu, 1 Jun 2006, Daren wrote:

> Trent,
> I have managed to successfully open the port at this speed using Realterm
> (available on sourceforge). From memory this uses DLPortIO.
>
> Using portmon.exe with realterm, even there it says that the port has opened
> at 1953.
>
> I changed termios.c:560 to
> dcb->BaudRate        = 1953 ;
>
> and it still opens the port at 9600.
>
> Daren
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Trent Jarvi
> Sent: Thursday, 1 June 2006 1:44 PM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] custom baud rate win32
>
> On Thu, 1 Jun 2006, Daren wrote:
>
>> Hi all,
>>
>> I downloaded 2.1.7-pre16 and managed to build it and get it going. I made
>> the changes as suggested by Peter Smith in an old post, by adding his code
>> to SerialImpl.c, uncommenting the TIOCGSERIAL and TIOCSSERIAL, and
> defining
>> ASYNC_SPD_CUST which is equal to 0x0030 (according to linus header
> files)..
>>
>>
>> Still not working, it opens the port at 9600 according to portmon.exe .
> Has
>> anyone managed to get this going at a custom rate?
>>
>> Here is the post I'm referring to:
>> http://marc.theaimsgroup.com/?l=rxtx&m=106270038110713&w=2
>>
>>
>> Thanks,
>> Daren
>>
>> ________________________________________
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
>> Daren
>> Sent: Wednesday, 31 May 2006 10:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] (no subject)
>>
>> Hi All,
>> I have been using rxtx for a little while and needed to get it working at
>> 1953, like a past user in the mailing list, who seemed to have got it
>> working by changing some C code.
>>
>> I wanted to build rxtx myself with these changes but don't know where to
>> start. I have windows here and FC4 at home. I downloaded cygwin and
> mingw32,
>> each build works by building a rxtxSerial.dll file that is ~11k smaller
> than
>> the original, and I always get the following error when testing the dll:
>>
>> Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at
>> PC=0x8077655
>> Function=[Unknown.]
>> Library=C:\opt\java\j2sdk1.4.2\jre\bin\client\jvm.dll
>>
>> NOTE: We are unable to locate the function name symbol for the error
>>      just occurred. Please refer to release documentation for possible
>>      reason and solutions.
>>
>>
>> Current Java thread:
>> 	at gnu.io.RXTXPort.open(Native Method)
>> 	- locked <0x1002c800> (a gnu.io.RXTXPort)
>> 	at gnu.io.RXTXPort.<init>(RXTXPort.java:84)
>>
>> Anyone know what im doing wrong?
>>
>>
>>
>>
>
> Hi Daren
>
> You are running into the same rats nest I'm looking at now.
>
> With win32 and specific custom baud rates, I'm not sure how this will go.
> I've got the Linux custom baud rates working very nicely.  I did much like
> the post you linked.  In fact I had forgot about that post.  You probably
> noticed that it becomes a bunch of dirt roads going noplace fast in
> termios.c for w32.
>
> I'm probably only going to get 14400, 28800, 128000 and 256000 working
> with the next release on w32.  I'll look a little further.  If you have an
> example w32 that works at 1953 I'd really like to hear.  Thats an unusual
> baud rate.
>
> Assuming a baud_base of 128000, your divisor will be 65 or 66.
>
> 128000/66=1939 -14
> 128000/65=1969 +13
>
> One thing I've been wondering about with linux is which would be the right
> answer in cases like this.  Right now it would just go with a baud base of
> 65 and ignore the modulus details.
>
> It appears to be a general trend for kernel developers to hide these
> details thinking that they can come up with a general solution.  Then they
> run out of time.  Perahps the solution is to help out but there are
> ultiple OS's rxtx supports making that nontrivial.
>
> If you look at current linux kernels, the 'tricks' above have been marked
> deprecated with no replacement.  Windows has some hard defines and then
> ancient near magic.  I've not looked at Solaris via Open Solaris yet but
> doubt there is a solution at all.
>
> What I'd try since you have the equipment and the monitor software is to
> hardcode the dcb->Baud in termios.c to 1953 (no define) and see what the
> w32 kernel does with it.  I think if you toss a baud rate at the driver it
> will try to come close.  You may try comming closer to a real baudrate
> based upon the 128000 baud base as shown above.
>
> If it works, it is worth looking at the rest of the ping/pong logic then.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
>
>
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From doug at dupreeinc.com  Thu Jun  1 13:22:13 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 12:22:13 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011107210.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
Message-ID: <447F3E65.1020809@dupreeinc.com>

Hello,

I am still trying to get this startup a little faster so I turned on the 
debug of a few of the classes.  The COM ports are scanned really fast 
and the delay occurs during the LPT scan.  The console output looks like 
this:

    ...
      LPT1
      LPT2
      LPT3
     valid port prefixes:
      LPT
    LPT1 LPT
    1 1
    LPT2 LPT
    2 2                                                                 
      * <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
    CommPortIdentifier:addPortName(LPT2)
    CommPortIdentifier:AddIdentifierToList()
    LPT3 LPT
    3 3
    CommPortIdentifier:addPortName(LPT3)
    CommPortIdentifier:AddIdentifierToList()
    CommPortIdentifier:AddIdentifierToList() index.next
    Leaving registerValidPorts()
    Have not implemented native_psmisc_report_owner(PortName)); in
    CommPortIdentifier
    CommPortIdentifier:getPortIdentifier(COM3)
    CommPortIdentifier:open(densConnect, 30000)
    RXTXCommDriver:getCommPort(COM3,1)
    ...

It would seem to me that if I removed the code for port scanning of LPT 
ports I could solve this problem. I would much prefer to use unmodified 
code if at all possible.  Do any of you have alternate suggestions?

Thank you for your time.

Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/cf433ee7/attachment-0019.html

From tjarvi at qbang.org  Thu Jun  1 13:52:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 13:52:06 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F3E65.1020809@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011348380.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I am still trying to get this startup a little faster so I turned on the 
> debug of a few of the classes.  The COM ports are scanned really fast and the 
> delay occurs during the LPT scan.  The console output looks like this:
>
>   ...
>     LPT1
>     LPT2
>     LPT3
>    valid port prefixes:
>     LPT
>   LPT1 LPT
>   1 1
>   LPT2 LPT
>   2 2                                                                      * 
> <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>   CommPortIdentifier:addPortName(LPT2)
>   CommPortIdentifier:AddIdentifierToList()
>   LPT3 LPT
>   3 3
>   CommPortIdentifier:addPortName(LPT3)
>   CommPortIdentifier:AddIdentifierToList()
>   CommPortIdentifier:AddIdentifierToList() index.next
>   Leaving registerValidPorts()
>   Have not implemented native_psmisc_report_owner(PortName)); in
>   CommPortIdentifier
>   CommPortIdentifier:getPortIdentifier(COM3)
>   CommPortIdentifier:open(densConnect, 30000)
>   RXTXCommDriver:getCommPort(COM3,1)
>   ...
>
> It would seem to me that if I removed the code for port scanning of LPT ports 
> I could solve this problem. I would much prefer to use unmodified code if at 
> all possible.  Do any of you have alternate suggestions?
>
> Thank you for your time.
>
> Doug
>


Does commenting out the LPT enumeration actually help?  There can often be 
differences between debug information printed and whats really going on. 
When you combine various environments the debug info can even come out in 
the wrong order.

I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
I do not think this problem is universal.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Thu Jun  1 14:29:44 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:29:44 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4E38.2060004@dupreeinc.com>

I will give it a try.  One thing to note on this PC is it has no LPT 
Parallel ports.

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
>>Hello,
>>
>>I am still trying to get this startup a little faster so I turned on the 
>>debug of a few of the classes.  The COM ports are scanned really fast and the 
>>delay occurs during the LPT scan.  The console output looks like this:
>>
>>  ...
>>    LPT1
>>    LPT2
>>    LPT3
>>   valid port prefixes:
>>    LPT
>>  LPT1 LPT
>>  1 1
>>  LPT2 LPT
>>  2 2                                                                      * 
>><<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>>  CommPortIdentifier:addPortName(LPT2)
>>  CommPortIdentifier:AddIdentifierToList()
>>  LPT3 LPT
>>  3 3
>>  CommPortIdentifier:addPortName(LPT3)
>>  CommPortIdentifier:AddIdentifierToList()
>>  CommPortIdentifier:AddIdentifierToList() index.next
>>  Leaving registerValidPorts()
>>  Have not implemented native_psmisc_report_owner(PortName)); in
>>  CommPortIdentifier
>>  CommPortIdentifier:getPortIdentifier(COM3)
>>  CommPortIdentifier:open(densConnect, 30000)
>>  RXTXCommDriver:getCommPort(COM3,1)
>>  ...
>>
>>It would seem to me that if I removed the code for port scanning of LPT ports 
>>I could solve this problem. I would much prefer to use unmodified code if at 
>>all possible.  Do any of you have alternate suggestions?
>>
>>Thank you for your time.
>>
>>Doug
>>
>>    
>>
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/dd31fed5/attachment-0019.html

From doug at dupreeinc.com  Thu Jun  1 14:36:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:36:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4FC8.9080106@dupreeinc.com>

Trent,

I commented out the section in RegisterScannedPorts() that adds the 
three LPT ports to the CandidateDeviceNames string array.  The 
application started immediately.  This is probably not the way to do 
this, but it was quick ,dirty, and worked.

It would be nice if there was a way to pole the OS to see if there is 
even a port there, though I guess this is what this code is suppose to do...

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
> ...
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From lynn at swcp.com  Thu Jun  1 14:49:34 2006
From: lynn at swcp.com (lynn@swcp.com)
Date: Thu, 1 Jun 2006 20:49:34 -0000
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>,
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <twig.1149194974.97617@swcp.com>

Perhaps we could add an argument to port enumeration where if not specified,
you get the default behavior that looks for everything.  With a new
constructor that has an argument(or more) you could optionally declare it to
not inspect printer ports.

Existing code would work as it always has.  New code could be smarter.

Lynn



Doug Thistlethwaite <doug at dupreeinc.com> said:

> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
> >On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
> >
> >  
> >
> > ...
> >
> >
> >Does commenting out the LPT enumeration actually help?  There can often be 
> >differences between debug information printed and whats really going on. 
> >When you combine various environments the debug info can even come out in 
> >the wrong order.
> >
> >I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
> >I do not think this problem is universal.
> >
> >--
> >Trent Jarvi
> >tjarvi at qbang.org
> >_______________________________________________
> >Rxtx mailing list
> >Rxtx at qbang.org
> >http://mailman.qbang.org/mailman/listinfo/rxtx
> >
> >
> >  
> >
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



-- 





From jredman at ergotech.com  Thu Jun  1 15:20:20 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 01 Jun 2006 15:20:20 -0600
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
Message-ID: <447F5A14.6010803@ergotech.com>

Doug,

If you specifically request ports, eg:

-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

or
 
-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

Depending upon the version  (Windows is COM1:COM2, etc. I assume).

Does it still enumerate the parallel ports?

Jim

Doug Thistlethwaite wrote:
> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
>> On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>
>>  
>>
>> ...
>>
>>
>> Does commenting out the LPT enumeration actually help?  There can often be 
>> differences between debug information printed and whats really going on. 
>> When you combine various environments the debug info can even come out in 
>> the wrong order.
>>
>> I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>> I do not think this problem is universal.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>>
>>  
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  1 16:49:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:49:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6EF4.7080709@dupreeinc.com>

I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
folder.  I created this file and added the following to the file:

gnu.io.rxtx.SerialPorts=COM3

and I get the following error on the console:
CommPortIdentifier:static initialization()
RXTXCommDriver {}
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
RXTXCommDriver:
    Jar version = RXTX-2.1-7
    native lib Version = RXTX-2.1-7
RXTXCommDriver:initialize()
checking for system-known ports of type 1
checking registry for ports of type 1

RXTXCommDriver:addSpecifiedPorts()
Exception in thread "main" java.lang.ExceptionInInitializerError
    at 
densconnect.SerialConnection.openConnection(SerialConnection.java:136)
    at densconnect.DensTalk.<init>(DensTalk.java:165)
    at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
    at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
    at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
    at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
Caused by: java.lang.NullPointerException
    at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
CommPortIdentifier:addPortName(COM3)
CommPortIdentifier:AddIdentifierToList()
CommPortIdentifier:AddIdentifierToList() null
...


It looks like it  read COM3 from the file, but it had the above 
exception that killed it.  The strange this is this error is from 
RXTXCommDriver initialize function (if statement line):

        OS = System.getProperty("os.name");
                System.out.println("OS NAME: " + OS);
        if(OS.toLowerCase().indexOf("linux") == -1)

OS is returning null, thus the error.

If the file is not present, it scans the ports and reads the OS.

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>Doug Thistlethwaite wrote:
>  
>
>>Trent,
>>
>>I commented out the section in RegisterScannedPorts() that adds the 
>>three LPT ports to the CandidateDeviceNames string array.  The 
>>application started immediately.  This is probably not the way to do 
>>this, but it was quick ,dirty, and worked.
>>
>>It would be nice if there was a way to pole the OS to see if there is 
>>even a port there, though I guess this is what this code is suppose to do...
>>
>>Doug
>>
>>Trent Jarvi wrote:
>>
>>    
>>
>>>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>>
>>> 
>>>
>>>...
>>>
>>>
>>>Does commenting out the LPT enumeration actually help?  There can often be 
>>>differences between debug information printed and whats really going on. 
>>>When you combine various environments the debug info can even come out in 
>>>the wrong order.
>>>
>>>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>>>I do not think this problem is universal.
>>>
>>>--
>>>Trent Jarvi
>>>tjarvi at qbang.org
>>>_______________________________________________
>>>Rxtx mailing list
>>>Rxtx at qbang.org
>>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>>
>>>
>>> 
>>>
>>>      
>>>
>>_______________________________________________
>>Rxtx mailing list
>>Rxtx at qbang.org
>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>    
>>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/bf4cca0e/attachment-0019.html

From doug at dupreeinc.com  Thu Jun  1 16:51:26 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:51:26 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6F6E.5060603@dupreeinc.com>

Jim,

I did not try your suggestion as I do not understand where I would put 
these command line parameters (it that is what they are).  It appears 
that using the properties file should do that same thing...

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>
>  
>


From doug at dupreeinc.com  Thu Jun  1 17:56:19 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 16:56:19 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
Message-ID: <447F7EA3.6050400@dupreeinc.com>

I think there is an error in the registerSpecifiedPorts() method.  When 
I have a gnu.io.rxtx.properties file in the ext directory, this function 
kills the System class  IF I call System.getProperty("os.name") before 
the call  to registerSpecifiedPorts(), it returns the os name, after the 
call, it returns null.  I have not played much with properties, except 
for reading them, so I don't really understand the code.

Doug



From doug at dupreeinc.com  Thu Jun  1 18:11:14 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 17:11:14 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F7EA3.6050400@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com>
Message-ID: <447F8222.3060402@dupreeinc.com>

Ok, I just hacked this thing up and got it to read the 
gnu.io.rxtx.properties file.

I commented out the line:
System.setProperties(p); in the method registerSpecifiedPorts() in 
RXTXCommDriver class.  I really don't understand that much about 
properties, but this call kills the System class.

I used the following in the gnu.io.rxtx.properties file:

gnu.io.rxtx.SerialPorts=COM3
gnu.io.rxtx.ParallelPorts=null

This allows the application to open very quickly without any errors.  
Whomever coded this class or somebody who understands properties should 
look at this method and make sure it is doing what they expect.

Doug




Doug Thistlethwaite wrote:

>I think there is an error in the registerSpecifiedPorts() method.  When 
>I have a gnu.io.rxtx.properties file in the ext directory, this function 
>kills the System class  IF I call System.getProperty("os.name") before 
>the call  to registerSpecifiedPorts(), it returns the os name, after the 
>call, it returns null.  I have not played much with properties, except 
>for reading them, so I don't really understand the code.
>
>Doug
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From tjarvi at qbang.org  Thu Jun  1 18:32:50 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 18:32:50 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F6EF4.7080709@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com> <447F6EF4.7080709@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011831510.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
> folder.  I created this file and added the following to the file:
>
> gnu.io.rxtx.SerialPorts=COM3
>
> and I get the following error on the console:
> CommPortIdentifier:static initialization()
> RXTXCommDriver {}
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
> RXTXCommDriver:
>   Jar version = RXTX-2.1-7
>   native lib Version = RXTX-2.1-7
> RXTXCommDriver:initialize()
> checking for system-known ports of type 1
> checking registry for ports of type 1
>
> RXTXCommDriver:addSpecifiedPorts()
> Exception in thread "main" java.lang.ExceptionInInitializerError
>   at densconnect.SerialConnection.openConnection(SerialConnection.java:136)
>   at densconnect.DensTalk.<init>(DensTalk.java:165)
>   at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
>   at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
>   at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
>   at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
> Caused by: java.lang.NullPointerException
>   at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
> CommPortIdentifier:addPortName(COM3)
> CommPortIdentifier:AddIdentifierToList()
> CommPortIdentifier:AddIdentifierToList() null
> ...
>
>

There is a solution for this bug.

http://bugzilla.qbang.org/show_bug.cgi?id=54

We have been horribly slow at getting the next round of patches in but 
they are comming.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  2 00:58:02 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 08:58:02 +0200
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F8222.3060402@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
Message-ID: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>

Hi Doug,

you wrote in an earlier message, that you would prefer an unchanged  
version. What about simply removing the RXTX parallel lib from the  
ext directory. This does not fix the bug, but it should fix your  
problem.

In general I think it is not a good idea to put the RXTX files in a  
system wide location. Putting the libs in the application folder and  
including the .jar in the application classpath (or application jar)  
is all that is required.

Regards,
Joachim

On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:

> Ok, I just hacked this thing up and got it to read the
> gnu.io.rxtx.properties file.
>
> I commented out the line:
> System.setProperties(p); in the method registerSpecifiedPorts() in
> RXTXCommDriver class.  I really don't understand that much about
> properties, but this call kills the System class.
>
> I used the following in the gnu.io.rxtx.properties file:
>
> gnu.io.rxtx.SerialPorts=COM3
> gnu.io.rxtx.ParallelPorts=null
>
> This allows the application to open very quickly without any errors.
> Whomever coded this class or somebody who understands properties  
> should
> look at this method and make sure it is doing what they expect.
>
> Doug
>
>
>
>
> Doug Thistlethwaite wrote:
>
>> I think there is an error in the registerSpecifiedPorts() method.   
>> When
>> I have a gnu.io.rxtx.properties file in the ext directory, this  
>> function
>> kills the System class  IF I call System.getProperty("os.name")  
>> before
>> the call  to registerSpecifiedPorts(), it returns the os name,  
>> after the
>> call, it returns null.  I have not played much with properties,  
>> except
>> for reading them, so I don't really understand the code.
>>
>> 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 antonio.luis at iscte.pt  Fri Jun  2 02:42:28 2006
From: antonio.luis at iscte.pt (=?ISO-8859-1?Q?Ant=F3nio_Lopes?=)
Date: Fri, 02 Jun 2006 09:42:28 +0100
Subject: [Rxtx] Exception when closing serial port
Message-ID: <447FF9F4.7060209@iscte.pt>

Hello everyone,
I've been using RXTX in a Java application in my Pocket PC.
The communication through the (bluetooth) serial port is working perfectly.

However, when I disconnect the app and close the serial port, sometimes I get 
the following error:

"1149237595000: RXTXPort:close detected bad File Descriptor"

The problem is that after this error occurs, the app is no longer able to 
connect to the serial port and I have to soft-reset the device in order to be 
able to connect to it again.

Any ideas on how to solve this issue?

Any help is appreciated.
Thanks,
regards,
-- 
Ant?nio Lopes

@contact: antonio.luis at iscte.pt
@work: ADETTI - ISCTE
@web: http://antonio.lopes.googlepages.com


From paul.klissner at sun.com  Fri Jun  2 02:44:34 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 01:44:34 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to RXTX
	again
Message-ID: <447FFA72.6040807@sun.com>

After looking into javax.comm 3.1 and what it would take to re-engineer it
to be compatible with RXTX platform libraries, I've decided, due my group's
priorities, complexity of the effort vs. benefit, and limited resources, 
to re-post
javax.comm 2.0 binaries on Sun's software download server, unsupported,
with disclaimers, as it was previously.

I don't think there will be any snags doing this from the standpoint of Sun
management or legality.  I will try to have it  posted there in the next 
week
or two, depending on how fast we can get it pushed through the process.

I'd like to think of this as a stop gap measure... ie. a compromise, 
where, at some
point in the not too distant future RXTX implements their own version of the
Java side of the API, as is normally done by javax.extension porters. 
That way
we avoid uncomfortable dependencies in the future.  And that really is 
the Java
development model.

Since RXTX already has the back-end code, porting the java code shouldn't
be a gargantuan effort at all, and RXTX will be in full control of the 
code top
to bottom. I think RXTX can do at least as good a job as the original 
coder.
Prepping 2.0 to be open sourced is more trouble than it is worth. ie. I 
don't
think the current implementation warrants it.

Ultimately, it would be nice to see someone open up a JSR and re-architect
the comm. API to overcome some of it's current design flaws (ie. be more
adaptable to modern platforms, more pluggable, better defined SPI, better
port ownership handling, etc...). A superior architecture would allow for
better collaboration in the future and better interchangeability of 
components
among projects.

Sun's 3.1 version of javax.comm, which is Sun's currently supported version,
has changes pertaining mostly to Sun platform-specific portmapping and has
some minor additional interactions with our back end code, but generally
has little bearing on RXTX. 

Paul



From joachim at buechse.de  Fri Jun  2 04:00:19 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 12:00:19 +0200
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
	RXTX again
In-Reply-To: <447FFA72.6040807@sun.com>
References: <447FFA72.6040807@sun.com>
Message-ID: <1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>

Good day Paul!

A clean architecture with loadable drivers and reusable code would be  
very beneficial for the future, I think everybody agrees. However  
this could be several years into the future. In the meantime, there  
is a real existing problem with IO support on Java. I have the strong  
feeling that most programmers want to code against one specification  
(javax.comm) and be able to replace the underlying implementation via  
a "plugin" on platforms where the SUN implementation is not  
sufficient. RXTX could be just this plugin (reusing very close to 0%  
of the javax.comm implementation but 100% of its API).

I want to propose an API addition and implementation change that will  
take less then 2 hours of manpower to implement and create a solution  
that can bridge the years until javax.comm has been based on a new  
architecture.

Looking at the javax.comm api at http://java.sun.com/products/ 
javacomm/reference/api/index.html I would like to propose the following:

The only entry point to javax.comm is CommPortIdentifier. It has 3  
static methods plus the constructor.

1) define one additional Interface

public interface CommProvider {
    CommPortIdentifier getPortIdentifier(CommPort port);
    CommPortIdentifier getPortIdentifier(String portName);
    Enumeration getPortIdentifiers ();
}

2) add one method to CommPortIdentifier

   public static setCustomCommProvider (CommProvider);

3) change the three static methods of CommPortIdentifier to dispatch  
to the CommProvider if it is set

4) change the constructor of CommPortIdentifier to

   public CommPortIdentifier(...) {
      if (isProviderSet && this.getClass() ==  
javax.comm.CommPortIdentifier) {
          throw new RuntimeException("illegal creation of  
CommPortIndentifier, custom CommProvider is in use");
      }

5) (this is optional, but would be very nice) automatically set a  
custom CommProvider if it is found on the classpath or defined via a  
system property.


The above 1) - 4) can be implemented in less than 1hour. 5) may take  
another hour. I agree that this is not the most elegant design, but  
it would solve a lot of problems with very little effort. It would  
certainly allow RXTX to move forward. If the javax.comm API needs to  
be redesigned completely this addition will not hurt, as people will  
move to the new API anyway and javax.comm 3.0 was so far never  
included in the main distribution.

Best regards,
Joachim

On 02.06.2006, at 10:44, Paul Klissner wrote:

> After looking into javax.comm 3.1 and what it would take to re- 
> engineer it
> to be compatible with RXTX platform libraries, I've decided, due my  
> group's
> priorities, complexity of the effort vs. benefit, and limited  
> resources,
> to re-post
> javax.comm 2.0 binaries on Sun's software download server,  
> unsupported,
> with disclaimers, as it was previously.
>
> I don't think there will be any snags doing this from the  
> standpoint of Sun
> management or legality.  I will try to have it  posted there in the  
> next
> week
> or two, depending on how fast we can get it pushed through the  
> process.
>
> I'd like to think of this as a stop gap measure... ie. a compromise,
> where, at some
> point in the not too distant future RXTX implements their own  
> version of the
> Java side of the API, as is normally done by javax.extension porters.
> That way
> we avoid uncomfortable dependencies in the future.  And that really is
> the Java
> development model.
>
> Since RXTX already has the back-end code, porting the java code  
> shouldn't
> be a gargantuan effort at all, and RXTX will be in full control of the
> code top
> to bottom. I think RXTX can do at least as good a job as the original
> coder.
> Prepping 2.0 to be open sourced is more trouble than it is worth.  
> ie. I
> don't
> think the current implementation warrants it.
>
> Ultimately, it would be nice to see someone open up a JSR and re- 
> architect
> the comm. API to overcome some of it's current design flaws (ie. be  
> more
> adaptable to modern platforms, more pluggable, better defined SPI,  
> better
> port ownership handling, etc...). A superior architecture would  
> allow for
> better collaboration in the future and better interchangeability of
> components
> among projects.
>
> Sun's 3.1 version of javax.comm, which is Sun's currently supported  
> version,
> has changes pertaining mostly to Sun platform-specific portmapping  
> and has
> some minor additional interactions with our back end code, but  
> generally
> has little bearing on RXTX.
>
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Fri Jun  2 09:10:13 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Fri, 2 Jun 2006 09:10:13 -0600 (MDT)
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <447FFA72.6040807@sun.com>
References: <447FFA72.6040807@sun.com>
Message-ID: <Pine.LNX.4.61.0606020906400.15971@www>

On Fri, 2 Jun 2006, Paul Klissner wrote:

> After looking into javax.comm 3.1 and what it would take to re-engineer it
> to be compatible with RXTX platform libraries, I've decided, due my group's
> priorities, complexity of the effort vs. benefit, and limited resources,
> to re-post
> javax.comm 2.0 binaries on Sun's software download server, unsupported,
> with disclaimers, as it was previously.
>

Hi Paul

To address users' immediate needs, we can release rxtx 2.0-7 (final) to 
match the 2.0 binaries from Sun when they are offered for download.

We can discuss potential long term solutions after that.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Fri Jun  2 10:20:09 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 02 Jun 2006 09:20:09 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
	<9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
Message-ID: <44806539.8080902@dupreeinc.com>

Thanks for the suggestion, I will give it a try.

Doug

Joachim Buechse wrote:

>Hi Doug,
>
>you wrote in an earlier message, that you would prefer an unchanged  
>version. What about simply removing the RXTX parallel lib from the  
>ext directory. This does not fix the bug, but it should fix your  
>problem.
>
>In general I think it is not a good idea to put the RXTX files in a  
>system wide location. Putting the libs in the application folder and  
>including the .jar in the application classpath (or application jar)  
>is all that is required.
>
>Regards,
>Joachim
>
>On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:
>
>  
>
>>Ok, I just hacked this thing up and got it to read the
>>gnu.io.rxtx.properties file.
>>
>>I commented out the line:
>>System.setProperties(p); in the method registerSpecifiedPorts() in
>>RXTXCommDriver class.  I really don't understand that much about
>>properties, but this call kills the System class.
>>
>>I used the following in the gnu.io.rxtx.properties file:
>>
>>gnu.io.rxtx.SerialPorts=COM3
>>gnu.io.rxtx.ParallelPorts=null
>>
>>This allows the application to open very quickly without any errors.
>>Whomever coded this class or somebody who understands properties  
>>should
>>look at this method and make sure it is doing what they expect.
>>
>>Doug
>>
>>
>>
>>
>>Doug Thistlethwaite wrote:
>>
>>    
>>
>>>I think there is an error in the registerSpecifiedPorts() method.   
>>>When
>>>I have a gnu.io.rxtx.properties file in the ext directory, this  
>>>function
>>>kills the System class  IF I call System.getProperty("os.name")  
>>>before
>>>the call  to registerSpecifiedPorts(), it returns the os name,  
>>>after the
>>>call, it returns null.  I have not played much with properties,  
>>>except
>>>for reading them, so I don't really understand the code.
>>>
>>>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
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060602/c8892a46/attachment-0019.html

From paul.klissner at sun.com  Fri Jun  2 12:09:26 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 11:09:26 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
Message-ID: <44807ED6.8000903@sun.com>

Joachim Buechse wrote:
> Good day Paul!
>
> A clean architecture with loadable drivers and reusable code would be  
> very beneficial for the future, I think everybody agrees. However  
> this could be several years into the future. In the meantime, there  
> is a real existing problem with IO support on Java. I have the strong  
> feeling that most programmers want to code against one specification  
> (javax.comm) and be able to replace the underlying implementation via  
> a "plugin" on platforms where the SUN implementation is not  
> sufficient. RXTX could be just this plugin (reusing very close to 0%  
> of the javax.comm implementation but 100% of its API).
>
> I want to propose an API addition and implementation change that will  
> take less then 2 hours of manpower to implement and create a solution  
> that can bridge the years until javax.comm has been based on a new  
> architecture.
>
> Looking at the javax.comm api at http://java.sun.com/products/ 
> javacomm/reference/api/index.html I would like to propose the following:
>
> The only entry point to javax.comm is CommPortIdentifier. It has 3  
> static methods plus the constructor.
>
> 1) define one additional Interface
>
> public interface CommProvider {
>     CommPortIdentifier getPortIdentifier(CommPort port);
>     CommPortIdentifier getPortIdentifier(String portName);
>     Enumeration getPortIdentifiers ();
> }
>
> 2) add one method to CommPortIdentifier
>
>    public static setCustomCommProvider (CommProvider);
>
> 3) change the three static methods of CommPortIdentifier to dispatch  
> to the CommProvider if it is set
>
> 4) change the constructor of CommPortIdentifier to
>
>    public CommPortIdentifier(...) {
>       if (isProviderSet && this.getClass() ==  
> javax.comm.CommPortIdentifier) {
>           throw new RuntimeException("illegal creation of  
> CommPortIndentifier, custom CommProvider is in use");
>       }
>
> 5) (this is optional, but would be very nice) automatically set a  
> custom CommProvider if it is found on the classpath or defined via a  
> system property.
>
>
> The above 1) - 4) can be implemented in less than 1hour. 5) may take  
> another hour. I agree that this is not the most elegant design, but  
> it would solve a lot of problems with very little effort. It would  
> certainly allow RXTX to move forward. If the javax.comm API needs to  
> be redesigned completely this addition will not hurt, as people will  
> move to the new API anyway and javax.comm 3.0 was so far never  
> included in the main distribution.
>
> Best regards,
> Joachi
I'm afraid modifying the interface classes isn't my call.  There was 
actually
a TCK written and one of the tests was to ensure that the interface classes
match the spec.  Thus my hands have already been tied since this project
was essentially grandfathered into the JCP.

That's why we need to open a new JSR and find someone who wants
to be the spec lead, and go in with a new reference implementation.
I'm not sure why it would have to take years, since this isn't bleeding edge
technology and there are only so many things that can be done with it,
and we already have practical experience about many functional aspects
that we could cite precedence on.

As it becomes clear that the specification is being accepted completely
or by-and-large by the community, nothing would stop people from
starting adapting to the new API (using the reference implementation or
porting it) and using it in their projects prior to it's final community and
JCP approval, since approval is required only to make it official and
get the "100% pure java" certification for platform ports.

You have one idea already.  Why don't you implement it, solicit some
design feedback from Sun and the RXTX, and create a functional
implementation that addresses the needs of the community, then
we can document it and open a JSR.  That's it.  It should march through
the approval stages reasonably quickly I would imagine, and meantime
RXTX could start using it.

Paul




From doug at dupreeinc.com  Fri Jun  2 12:45:01 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 02 Jun 2006 11:45:01 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
	<9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
Message-ID: <4480872D.6000605@dupreeinc.com>

Joachim,

Thank you for the suggestion.  I restored the jar file to the one I 
downloaded, moved the dll files into the project directory, and added 
the jar to the classpath.  The SerialDemo program that was included with 
the Sun commapi started in 12 seconds instead of the 58 seconds when the 
parallel dll is present.  I did get the startup time to about a second 
by modifying the java code and adding the properties file but this is 
probably not a good idea.

Doug

Joachim Buechse wrote:

>Hi Doug,
>
>you wrote in an earlier message, that you would prefer an unchanged  
>version. What about simply removing the RXTX parallel lib from the  
>ext directory. This does not fix the bug, but it should fix your  
>problem.
>
>In general I think it is not a good idea to put the RXTX files in a  
>system wide location. Putting the libs in the application folder and  
>including the .jar in the application classpath (or application jar)  
>is all that is required.
>
>Regards,
>Joachim
>
>On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:
>
>  
>
>>Ok, I just hacked this thing up and got it to read the
>>gnu.io.rxtx.properties file.
>>
>>I commented out the line:
>>System.setProperties(p); in the method registerSpecifiedPorts() in
>>RXTXCommDriver class.  I really don't understand that much about
>>properties, but this call kills the System class.
>>
>>I used the following in the gnu.io.rxtx.properties file:
>>
>>gnu.io.rxtx.SerialPorts=COM3
>>gnu.io.rxtx.ParallelPorts=null
>>
>>This allows the application to open very quickly without any errors.
>>Whomever coded this class or somebody who understands properties  
>>should
>>look at this method and make sure it is doing what they expect.
>>
>>Doug
>>
>>
>>
>>
>>Doug Thistlethwaite wrote:
>>
>>    
>>
>>>I think there is an error in the registerSpecifiedPorts() method.   
>>>When
>>>I have a gnu.io.rxtx.properties file in the ext directory, this  
>>>function
>>>kills the System class  IF I call System.getProperty("os.name")  
>>>before
>>>the call  to registerSpecifiedPorts(), it returns the os name,  
>>>after the
>>>call, it returns null.  I have not played much with properties,  
>>>except
>>>for reading them, so I don't really understand the code.
>>>
>>>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
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060602/3c0e420f/attachment-0019.html

From joachim at buechse.de  Fri Jun  2 13:46:36 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 21:46:36 +0200
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
	RXTX again
In-Reply-To: <44807ED6.8000903@sun.com>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
	<44807ED6.8000903@sun.com>
Message-ID: <6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>

Hello Paul,

of course, the basic change I suggested could be done "hidden".  The  
CommProvider interface could live somewhere in sun.xyz.*
The setCustomCommProvider method would not be in CommPortIdentifier  
but also somewhere in sun.xyz.* This would be an unofficial feature,  
the official interface stays exactly the same. However RXTX (and  
others) could access the hidden interface.

Don't get me wrong, I don't want to harass you into making changes  
you don't like (which probably wouldn't work anyway;-). But I'm a  
long time Java programmer and seeing the state of cross platform  
serial support for Java makes me feel really sad. In fact, when I  
started to look into Java serial port programming some months ago I  
was very surprised that javax.comm never made it into the JDK.

I'm sorry that I did not contribute my feedback to the JSR for  
javax.comm 3.0. However at the time I didn't do serial port  
programming in Java. I agree that a new JSR should be opened - I'm  
not an expert on JSRs or the JCP process, but from looking quickly  
over the progress of some JSRs I would be very surprised if we can  
have a new version in less then a year. In the meanwhile some people  
will start using javax.comm 3.0 (which can not be supported by RXTX),  
some will use javax.comm 2.0 (which means the 2.0.7 release of RXTX  
still needs to be maintained). This may get even worse if eg Apple  
decides to port and include javax.comm 3.0 at which point it may get  
very tricky to write a cross platform Java application.

All of this simply means, that we are loosing a lot of man-power that  
could otherwise be invested in building a clean solution and/or to  
add features that are becoming more and more important (USB events...).

In the automation / machine control universe Java makes a lot of  
sense. Right now many people are migrating to Linux or from  
propietary systems (even DOS) to Windows. Writing the control/ 
configuration applications in Java is the kings way to unify the code  
base.

Best regards,
Joachim


On 02.06.2006, at 20:09, Paul Klissner wrote:

> Joachim Buechse wrote:
>> Good day Paul!
>>
>> A clean architecture with loadable drivers and reusable code would be
>> very beneficial for the future, I think everybody agrees. However
>> this could be several years into the future. In the meantime, there
>> is a real existing problem with IO support on Java. I have the strong
>> feeling that most programmers want to code against one specification
>> (javax.comm) and be able to replace the underlying implementation via
>> a "plugin" on platforms where the SUN implementation is not
>> sufficient. RXTX could be just this plugin (reusing very close to 0%
>> of the javax.comm implementation but 100% of its API).
>>
>> I want to propose an API addition and implementation change that will
>> take less then 2 hours of manpower to implement and create a solution
>> that can bridge the years until javax.comm has been based on a new
>> architecture.
>>
>> Looking at the javax.comm api at http://java.sun.com/products/
>> javacomm/reference/api/index.html I would like to propose the  
>> following:
>>
>> The only entry point to javax.comm is CommPortIdentifier. It has 3
>> static methods plus the constructor.
>>
>> 1) define one additional Interface
>>
>> public interface CommProvider {
>>     CommPortIdentifier getPortIdentifier(CommPort port);
>>     CommPortIdentifier getPortIdentifier(String portName);
>>     Enumeration getPortIdentifiers ();
>> }
>>
>> 2) add one method to CommPortIdentifier
>>
>>    public static setCustomCommProvider (CommProvider);
>>
>> 3) change the three static methods of CommPortIdentifier to dispatch
>> to the CommProvider if it is set
>>
>> 4) change the constructor of CommPortIdentifier to
>>
>>    public CommPortIdentifier(...) {
>>       if (isProviderSet && this.getClass() ==
>> javax.comm.CommPortIdentifier) {
>>           throw new RuntimeException("illegal creation of
>> CommPortIndentifier, custom CommProvider is in use");
>>       }
>>
>> 5) (this is optional, but would be very nice) automatically set a
>> custom CommProvider if it is found on the classpath or defined via a
>> system property.
>>
>>
>> The above 1) - 4) can be implemented in less than 1hour. 5) may take
>> another hour. I agree that this is not the most elegant design, but
>> it would solve a lot of problems with very little effort. It would
>> certainly allow RXTX to move forward. If the javax.comm API needs to
>> be redesigned completely this addition will not hurt, as people will
>> move to the new API anyway and javax.comm 3.0 was so far never
>> included in the main distribution.
>>
>> Best regards,
>> Joachi
> I'm afraid modifying the interface classes isn't my call.  There was
> actually
> a TCK written and one of the tests was to ensure that the interface  
> classes
> match the spec.  Thus my hands have already been tied since this  
> project
> was essentially grandfathered into the JCP.
>
> That's why we need to open a new JSR and find someone who wants
> to be the spec lead, and go in with a new reference implementation.
> I'm not sure why it would have to take years, since this isn't  
> bleeding edge
> technology and there are only so many things that can be done with it,
> and we already have practical experience about many functional aspects
> that we could cite precedence on.
>
> As it becomes clear that the specification is being accepted  
> completely
> or by-and-large by the community, nothing would stop people from
> starting adapting to the new API (using the reference  
> implementation or
> porting it) and using it in their projects prior to it's final  
> community and
> JCP approval, since approval is required only to make it official and
> get the "100% pure java" certification for platform ports.
>
> You have one idea already.  Why don't you implement it, solicit some
> design feedback from Sun and the RXTX, and create a functional
> implementation that addresses the needs of the community, then
> we can document it and open a JSR.  That's it.  It should march  
> through
> the approval stages reasonably quickly I would imagine, and meantime
> RXTX could start using it.
>
> Paul
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From paul.klissner at sun.com  Fri Jun  2 14:38:49 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 13:38:49 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
	<44807ED6.8000903@sun.com>
	<6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>
Message-ID: <4480A1D9.5060106@sun.com>

Joachim Buechse wrote:
> Hello Paul,
>
> of course, the basic change I suggested could be done "hidden".  The  
> CommProvider interface could live somewhere in sun.xyz.*
> The setCustomCommProvider method would not be in CommPortIdentifier  
> but also somewhere in sun.xyz.* This would be an unofficial feature,  
> the official interface stays exactly the same. However RXTX (and  
> others) could access the hidden interface.
>
> Don't get me wrong, I don't want to harass you into making changes  
> you don't like (which probably wouldn't work anyway;-). But I'm a  
> long time Java programmer and seeing the state of cross platform  
> serial support for Java makes me feel really sad. In fact, when I  
> started to look into Java serial port programming some months ago I  
> was very surprised that javax.comm never made it into the JDK.
>
> I'm sorry that I did not contribute my feedback to the JSR for  
> javax.comm 3.0. 
There was no JSR for 3.0, because we didn't have the resources to make 
the commitment.
Yet Sun needed to add support for platform-dependent port name mapping, 
which had to
be done 'under the hood', since the API isn't designed to handle that in 
a pluggable way.
But these quick fixes aren't the right approach, they just kick the dog 
down the road,
setting bad precedent, inviting confusion and more intractable problems 
(such as the
one plaguing us now).

My changes could have been layered better, it was a trade off between 
achieving an
ideal architecture, trying to find internal reviewers, and meet the 
needs of big customers
in a timely way.  Thus my namespace changes collided with RXTX's 
dependencies.
I was unaware of Jagane's rogue agreement made with the RXTX community 7 
years ago,
before Jagane left Sun.  I think this was a wag-the-dog situation.

Now it is time to do it right, and I don't think it is going to be as 
much trouble as people
some people fear. If RXTX wants to sponsor the JSR and seed a new spec, 
Sun can join
the Expert Group.  And we'd be largely in agreement, since we're not 
talking about
humongous changes, and looking for mutually beneficial changes. The core 
API is already
largely proved and tested.
> However at the time I didn't do serial port  
> programming in Java. I agree that a new JSR should be opened - I'm  
> not an expert on JSRs or the JCP process, but from looking quickly  
> over the progress of some JSRs I would be very surprised if we can  
> have a new version in less then a year. 
*Approved*  But that doesn't mean the spec couldn't be 99.9% stable 
before that.  Once
the delta rate declines and changes approach nil, people could start 
adapting to the API in
advance of formal approval.   It isn't going to be drawn out like 
javax.usb, which was new
technology, a very complex API, and involved precedent setting corporate 
disputes and
policy issues to resolve.

> In the meanwhile some people  
> will start using javax.comm 3.0 (which can not be supported by RXTX),  
> some will use javax.comm 2.0 (which means the 2.0.7 release of RXTX  
> still needs to be maintained). This may get even worse if eg Apple  
> decides to port and include javax.comm 3.0 at which point it may get  
> very tricky to write a cross platform Java application.
>   
The interfaces haven't changed since 1.0.  If we open a JSR ,we can 
contact Apple and
allow them to be on the E.G., if they want.  That might make the JSR a 
bit more drawn out,
but then we'd arrive ultimately arrive at a best-of-all-worlds API that 
most people would
accept, perhaps forever, and arrive at a respectable set of compromises.

-Paul

> All of this simply means, that we are loosing a lot of man-power that  
> could otherwise be invested in building a clean solution and/or to  
> add features that are becoming more and more important (USB events...).
>
> In the automation / machine control universe Java makes a lot of  
> sense. Right now many people are migrating to Linux or from  
> propietary systems (even DOS) to Windows. Writing the control/ 
> configuration applications in Java is the kings way to unify the code  
> base.
>
> Best regards,
> Joachim
>
>
> On 02.06.2006, at 20:09, Paul Klissner wrote:
>
>   
>> Joachim Buechse wrote:
>>     
>>> Good day Paul!
>>>
>>> A clean architecture with loadable drivers and reusable code would be
>>> very beneficial for the future, I think everybody agrees. However
>>> this could be several years into the future. In the meantime, there
>>> is a real existing problem with IO support on Java. I have the strong
>>> feeling that most programmers want to code against one specification
>>> (javax.comm) and be able to replace the underlying implementation via
>>> a "plugin" on platforms where the SUN implementation is not
>>> sufficient. RXTX could be just this plugin (reusing very close to 0%
>>> of the javax.comm implementation but 100% of its API).
>>>
>>> I want to propose an API addition and implementation change that will
>>> take less then 2 hours of manpower to implement and create a solution
>>> that can bridge the years until javax.comm has been based on a new
>>> architecture.
>>>
>>> Looking at the javax.comm api at http://java.sun.com/products/
>>> javacomm/reference/api/index.html I would like to propose the  
>>> following:
>>>
>>> The only entry point to javax.comm is CommPortIdentifier. It has 3
>>> static methods plus the constructor.
>>>
>>> 1) define one additional Interface
>>>
>>> public interface CommProvider {
>>>     CommPortIdentifier getPortIdentifier(CommPort port);
>>>     CommPortIdentifier getPortIdentifier(String portName);
>>>     Enumeration getPortIdentifiers ();
>>> }
>>>
>>> 2) add one method to CommPortIdentifier
>>>
>>>    public static setCustomCommProvider (CommProvider);
>>>
>>> 3) change the three static methods of CommPortIdentifier to dispatch
>>> to the CommProvider if it is set
>>>
>>> 4) change the constructor of CommPortIdentifier to
>>>
>>>    public CommPortIdentifier(...) {
>>>       if (isProviderSet && this.getClass() ==
>>> javax.comm.CommPortIdentifier) {
>>>           throw new RuntimeException("illegal creation of
>>> CommPortIndentifier, custom CommProvider is in use");
>>>       }
>>>
>>> 5) (this is optional, but would be very nice) automatically set a
>>> custom CommProvider if it is found on the classpath or defined via a
>>> system property.
>>>
>>>
>>> The above 1) - 4) can be implemented in less than 1hour. 5) may take
>>> another hour. I agree that this is not the most elegant design, but
>>> it would solve a lot of problems with very little effort. It would
>>> certainly allow RXTX to move forward. If the javax.comm API needs to
>>> be redesigned completely this addition will not hurt, as people will
>>> move to the new API anyway and javax.comm 3.0 was so far never
>>> included in the main distribution.
>>>
>>> Best regards,
>>> Joachi
>>>       
>> I'm afraid modifying the interface classes isn't my call.  There was
>> actually
>> a TCK written and one of the tests was to ensure that the interface  
>> classes
>> match the spec.  Thus my hands have already been tied since this  
>> project
>> was essentially grandfathered into the JCP.
>>
>> That's why we need to open a new JSR and find someone who wants
>> to be the spec lead, and go in with a new reference implementation.
>> I'm not sure why it would have to take years, since this isn't  
>> bleeding edge
>> technology and there are only so many things that can be done with it,
>> and we already have practical experience about many functional aspects
>> that we could cite precedence on.
>>
>> As it becomes clear that the specification is being accepted  
>> completely
>> or by-and-large by the community, nothing would stop people from
>> starting adapting to the new API (using the reference  
>> implementation or
>> porting it) and using it in their projects prior to it's final  
>> community and
>> JCP approval, since approval is required only to make it official and
>> get the "100% pure java" certification for platform ports.
>>
>> You have one idea already.  Why don't you implement it, solicit some
>> design feedback from Sun and the RXTX, and create a functional
>> implementation that addresses the needs of the community, then
>> we can document it and open a JSR.  That's it.  It should march  
>> through
>> the approval stages reasonably quickly I would imagine, and meantime
>> RXTX could start using it.
>>
>> Paul
>>
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at 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  Sat Jun  3 18:15:24 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 18:15:24 -0600 (MDT)
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
Message-ID: <Pine.LNX.4.61.0606031715100.10890@www>


The attached patch allows baud rates of 14400, 28800, 128000 and 256000.

That was my goal.

[import standard disclaimer]

But I took some time to look a little further.  I got custom baud rates 
working enough that someone (perhaps me) can properly fix them in the 
future.  Proof of concept.

As an undocumented bonus, you can toss random baudrates (say 1953), at the 
API and it will set it to something close to that on windows and linux. 
Solaris should say the baud rate is not supported but I have not tested it 
yet.  Mac OS X behavior is unknown at this point.  Just dont expect 
correct behavior at ~8192-9009 baudrates or baudrates less than 20 on 
windows; these baud rates overlap with defines in win32termios.h.  I 
conveniently closed my eyes there.  Try another value close.  On Linux, a 
baud base and divisor are guestimated and set.  On windows, we wave pixie 
dust over the kernel driver and hope.  Do not expect pixie dust and 
guestimates to be the same on windows and linux.  They may well round to 
different values in yet to be tested ways.  There are only so many 
divisors.  If it isn't working, try a little higher or lower.

In the example of 1953 for instance, there is no divisor for commodity 
hardware that comes to that baudrate.  We just come close on one side or 
the other.  If tools tell you they got 1953 exactly, the tools may be 
questionable and just reading values not directly related to the actual 
hardware settings.

These fixes have been tested on Linux and Windows while using an 
oscilloscope to confirm they change relative to known baudrates at 9600, 
14400*, 19200, 28800* (and 1800, 1953** and 2400).

* = previously unsupported.
** = still not supported but probably works from what I saw.

There could be future discussion in this area.  For now this is working 
for almost all unusual baud rate demands.  Cleaning up the custom baud 
rate should be easier with a working starting point.  Baud bases other 
than 128000 have not been characterized.  Yes.. this overlapps with two of 
the baud rates enabled.

Feedback and ideas are welcome.

--
Trent Jarvi
tjarvi at qbang.org
-------------- next part --------------
Index: SerialImp.c
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v
retrieving revision 1.46.2.187
diff -u -r1.46.2.187 SerialImp.c
--- SerialImp.c	29 Jan 2006 22:19:04 -0000	1.46.2.187
+++ SerialImp.c	3 Jun 2006 23:12:40 -0000
@@ -793,6 +793,19 @@
 		result &= ~TIOCM_DTR;
 		ioctl( fd, TIOCMSET, &result );
 	}
+	/*
+	   B38400 is a special case in Linux for custom baud rates.
+
+	   We just treat this as a custom speed for now.  If you take this ifdef
+	   out and select baud rates 38400 then 28800 then 38400, you will get
+	   a final baud rate of 28800 because you did not update the divisor.
+
+	   See the next ifdef below for the divisor.
+	*/
+#if defined(TIOCGSERIAL)
+	if ( cspeed == B38400 )
+		cspeed = 38400;
+#endif /* TIOCGSERIAL */
 	if(     cfsetispeed( &ttyset, cspeed ) < 0 ||
 		cfsetospeed( &ttyset, cspeed ) < 0 )
 	{
@@ -814,6 +827,7 @@
 		*/
 
 #if defined(TIOCGSERIAL)
+		ioctl( fd, TIOCGSERIAL, &sstruct );
 		sstruct.custom_divisor = ( sstruct.baud_base/cspeed );
 		cspeed = B38400;
 #endif /* TIOCGSERIAL */
@@ -827,7 +841,7 @@
 #if defined(TIOCSSERIAL)
 		/*  It is assumed Win32 does this for us */
 		if (	sstruct.baud_base < 1 ||
-			ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
+		ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
 		{
 			return( 1 );
 		}
Index: termios.c
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v
retrieving revision 1.9.2.56
diff -u -r1.9.2.56 termios.c
--- termios.c	16 Jan 2006 02:50:32 -0000	1.9.2.56
+++ termios.c	3 Jun 2006 23:12:40 -0000
@@ -323,8 +323,8 @@
 		case CBR_3500000:	return( B3500000 );
 		case CBR_4000000:	return( B4000000 );
 		default:
-			set_errno(EINVAL );
-			return -1;
+			/* assume custom baudrate */
+			return( Baud );
 	}
 }
 
@@ -361,12 +361,13 @@
 		case B9600:	ret = CBR_9600;		break;
 		case B14400:	ret = CBR_14400;	break;
 		case B19200:	ret = CBR_19200;	break;
+		case B28800:	ret = CBR_28800;	break;
 		case B38400:	ret = CBR_38400;	break;
 		case B57600:	ret = CBR_57600;	break;
 		case B115200:	ret = CBR_115200;	break;
 		case B128000:	ret = CBR_128000;	break;
-		case B256000: 	ret = CBR_256000;	break;
 		case B230400:	ret = CBR_230400;	break;
+		case B256000: 	ret = CBR_256000;	break;
 		case B460800:	ret = CBR_460800;	break;
 		case B500000:	ret = CBR_500000;	break;
 		case B576000:	ret = CBR_576000;	break;
@@ -381,10 +382,8 @@
 		case B4000000:	ret = CBR_4000000;	break;
 	
 		default:
-			fprintf( stderr, "B_to_CBR: invalid baudrate: %#o\n",
-				Baud );
-			set_errno( EINVAL );
-			return -1;
+			/* assume custom baudrate */
+			return Baud;
 	}
 	LEAVE( "B_to_CBR" );
 	return ret;
@@ -708,12 +707,9 @@
 	ENTER( "init_serial_struct" );
 
 	/*
-	FIXME
-
-	This needs to use inb() to read the actual baud_base
-	and divisor from the UART registers.  Question is how
-	far do we take this?
-
+	use of custom_divisor and baud_base requires access to
+	kernel space.  The kernel does try its best if you just
+	toss a baud rate at it though.
 	*/
 
 	sstruct->custom_divisor = 0;
@@ -1678,16 +1674,17 @@
 {
 	char message[80];
 	ENTER( "cfsetospeed" );
+	/* clear baudrate */
+	s_termios->c_cflag &= ~CBAUD;
 	if ( speed & ~CBAUD )
 	{
 		sprintf( message, "cfsetospeed: not speed: %#o\n", speed );
 		report( message );
-		return 0;
+		/* continue assuming its a custom baudrate */
+		s_termios->c_cflag |= B38400;  /* use 38400 during custom */
+		s_termios->c_cflag |= CBAUDEX; /* use CBAUDEX for custom */
 	}
-	s_termios->c_ispeed = s_termios->c_ospeed = speed;
-	/* clear baudrate */
-	s_termios->c_cflag &= ~CBAUD;
-	if( speed )
+	else if( speed )
 	{
 		s_termios->c_cflag |= speed;
 	}
@@ -1696,6 +1693,7 @@
 		/* PC blows up with speed 0 handled in Java */
 		s_termios->c_cflag |= B9600;
 	}
+	s_termios->c_ispeed = s_termios->c_ospeed = speed;
 	LEAVE( "cfsetospeed" );
 	return 1;
 }
@@ -1767,25 +1765,6 @@
 }
 
 /*----------------------------------------------------------
-serial_struct_to_DCB()
-
-   accept:      
-   perform:     
-   return:      
-   exceptions:  
-   win32api:     None
-   comments:    
-----------------------------------------------------------*/
-int serial_struct_to_DCB( struct serial_struct *sstruct, DCB *dcb )
-{
-	/* 5 Baud rate fix
-	sstruct.baud_base
-	sstruct.custom_divisor = ( sstruct.baud_base/cspeed );
-	*/
-	return(0);
-}
-
-/*----------------------------------------------------------
 termios_to_DCB()
 
    accept:      
@@ -1798,7 +1777,8 @@
 int termios_to_DCB( struct termios *s_termios, DCB *dcb )
 {
 	ENTER( "termios_to_DCB" );
-	s_termios->c_ispeed = s_termios->c_ospeed = s_termios->c_cflag & CBAUD;
+	if ( !(s_termios->c_cflag & CBAUDEX) )
+		s_termios->c_ispeed = s_termios->c_ospeed = s_termios->c_cflag & CBAUD;
 	dcb->BaudRate        = B_to_CBR( s_termios->c_ispeed );
 	dcb->ByteSize = termios_to_bytesize( s_termios->c_cflag );
 
@@ -2863,11 +2843,6 @@
 			GetCommState( index->hComm, dcb );
 
 			index->sstruct = va_arg( ap, struct serial_struct * );
-			if ( serial_struct_to_DCB( index->sstruct, dcb ) < 0 )
-			{
-				va_end( ap );
-				return -1;
-			}
 
 			report( "TIOCSSERIAL\n" );
 			free(dcb);
Index: win32termios.h
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v
retrieving revision 1.5.2.28
diff -u -r1.5.2.28 win32termios.h
--- win32termios.h	30 Jun 2005 20:23:26 -0000	1.5.2.28
+++ win32termios.h	3 Jun 2006 23:12:40 -0000
@@ -279,7 +279,7 @@
 #define XTABS	01000000 /* Hmm.. Linux/i386 considers this part of TABDLY.. */
 
 /* c_cflag bit meaning */
-# define CBAUD	0010017
+#define  CBAUD  0030017
 #define  B0	0000000		/* hang up */
 #define  B50	0000001
 #define  B75	0000002
@@ -312,13 +312,16 @@
 #define  B3500000 0010016
 #define  B4000000 0010017
 
-/* glue for unsupported linux speeds see also SerialImp.h */
-/* hosed */
-
-#define B14400		1010001
-#define B28800		1010002
-#define B128000		1010003
-#define B256000		1010004
+/*
+	glue for unsupported linux speeds see also SerialImp.h 
+	custom baud rates around 8192-9000 will not work because
+	of these.
+*/
+
+#define B14400		0020001
+#define B28800		0020002
+#define B128000		0020003
+#define B256000		0020004
 
 #define EXTA B19200
 #define EXTB B38400
@@ -356,8 +359,10 @@
 
 /* glue for unsupported windows speeds */
 
-#define CBR_230400	230400
 #define CBR_28800	28800
+#define CBR_128000	128000
+#define CBR_230400	230400
+#define CBR_256000	256000
 #define CBR_460800	460800
 #define CBR_500000	500000
 #define CBR_576000	576000

From impakt01 at optusnet.com.au  Sat Jun  3 18:30:37 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 10:30:37 +1000
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
In-Reply-To: <Pine.LNX.4.61.0606031715100.10890@www>
Message-ID: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>

Hi Trent,
I'd love to try the patch but I can't get the latest build compiling, only
pre16. 

Can you attach the rxtxSerial.dll file with this patch?

Also, I hardcoded 1953 in a couple more places last night on pre16 and it
managed to open the port at the right speed, but stopped receiving anything
after 100-150 bytes, even though more data was getting sent to the port.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 10:15 AM
To: rxtx at qbang.org
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.


The attached patch allows baud rates of 14400, 28800, 128000 and 256000.

That was my goal.

[import standard disclaimer]

But I took some time to look a little further.  I got custom baud rates 
working enough that someone (perhaps me) can properly fix them in the 
future.  Proof of concept.

As an undocumented bonus, you can toss random baudrates (say 1953), at the 
API and it will set it to something close to that on windows and linux. 
Solaris should say the baud rate is not supported but I have not tested it 
yet.  Mac OS X behavior is unknown at this point.  Just dont expect 
correct behavior at ~8192-9009 baudrates or baudrates less than 20 on 
windows; these baud rates overlap with defines in win32termios.h.  I 
conveniently closed my eyes there.  Try another value close.  On Linux, a 
baud base and divisor are guestimated and set.  On windows, we wave pixie 
dust over the kernel driver and hope.  Do not expect pixie dust and 
guestimates to be the same on windows and linux.  They may well round to 
different values in yet to be tested ways.  There are only so many 
divisors.  If it isn't working, try a little higher or lower.

In the example of 1953 for instance, there is no divisor for commodity 
hardware that comes to that baudrate.  We just come close on one side or 
the other.  If tools tell you they got 1953 exactly, the tools may be 
questionable and just reading values not directly related to the actual 
hardware settings.

These fixes have been tested on Linux and Windows while using an 
oscilloscope to confirm they change relative to known baudrates at 9600, 
14400*, 19200, 28800* (and 1800, 1953** and 2400).

* = previously unsupported.
** = still not supported but probably works from what I saw.

There could be future discussion in this area.  For now this is working 
for almost all unusual baud rate demands.  Cleaning up the custom baud 
rate should be easier with a working starting point.  Baud bases other 
than 128000 have not been characterized.  Yes.. this overlapps with two of 
the baud rates enabled.

Feedback and ideas are welcome.

--
Trent Jarvi
tjarvi at qbang.org



From tjarvi at qbang.org  Sat Jun  3 19:05:11 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 19:05:11 -0600 (MDT)
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
In-Reply-To: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>
References: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606031840400.10890@www>

On Sun, 4 Jun 2006, Daren wrote:

> Hi Trent,
> I'd love to try the patch but I can't get the latest build compiling, only
> pre16.
>
> Can you attach the rxtxSerial.dll file with this patch?
>
> Also, I hardcoded 1953 in a couple more places last night on pre16 and it
> managed to open the port at the right speed, but stopped receiving anything
> after 100-150 bytes, even though more data was getting sent to the port.
>


ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing

I dont think they will hang.  But I was just testing via loopback/break 
out box/scope.

I'll be putting about 10 patches and another set of binaries in that 
directory shortly.  For now the binaries should just have the baud_rate 
fix.

I'll announce all the patches at once.  but wont be releasing 2.1-8 right 
away.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Sat Jun  3 21:00:01 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 21:00:01 -0600 (MDT)
Subject: [Rxtx] CVS for 2.1 should have everything
Message-ID: <Pine.LNX.4.61.0606032056190.10890@www>


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org


From impakt01 at optusnet.com.au  Sat Jun  3 21:08:14 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 13:08:14 +1000
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <Pine.LNX.4.61.0606032056190.10890@www>
Message-ID: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>

Hi Trent,
I tried the latest dll and it opens the port, receives 100-200 bytes and
then stops receiving anything else..

I'll keep playing with it.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 1:00 PM
To: rxtx at qbang.org
Subject: [Rxtx] CVS for 2.1 should have everything


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From impakt01 at optusnet.com.au  Sat Jun  3 21:22:41 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 13:22:41 +1000
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
Message-ID: <200606040322.k543MqW1008455@mail12.syd.optusnet.com.au>

Played with it, problem, with a while loop in my code, working great now

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Daren
Sent: Sunday, 4 June 2006 1:08 PM
To: 'RXTX Developers and Users'
Subject: Re: [Rxtx] CVS for 2.1 should have everything

Hi Trent,
I tried the latest dll and it opens the port, receives 100-200 bytes and
then stops receiving anything else..

I'll keep playing with it.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 1:00 PM
To: rxtx at qbang.org
Subject: [Rxtx] CVS for 2.1 should have everything


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Sat Jun  3 21:35:41 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 21:35:41 -0600 (MDT)
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
References: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606032131140.10890@www>

On Sun, 4 Jun 2006, Daren wrote:

> Hi Trent,
> I tried the latest dll and it opens the port, receives 100-200 bytes and
> then stops receiving anything else..
>
> I'll keep playing with it.
>
> Daren

The difference may be that I'm talking to something at the exact same baud 
rate (loopback).

You may also try setting the baudrate to ~1933 and ~1973 to force the 
guesses one way or the other.  If you are on windows, we are not doing 
anything fancy in the end.  Thats the kernel guessing.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sun Jun  4 04:12:09 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sun, 4 Jun 2006 12:12:09 +0200
Subject: [Rxtx] Update of OSX installer, Readme, etc
Message-ID: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>

Good day,

after the latest changes a lot of OS X specific files should be  
updated. Especially the installer!

- The "MaxOSX" readme file on the root level is outdated (ie  
CodeWarrior information). Maybe we could even rename it to README.OSX  
to be in line with README.IPAQ, README.SCO (Trent do you mind copying/ 
renaming ,v files in the repository?).

- The lock files are no longer used and hence the user group magic  
and lock folder creation should be removed from the installer.

- MACOSX_IDE/ForPackageMaker/Resources/ReadMe.rtf and Welcome.rtf  
need to be updated.

- I suggest to replace the current installation instruction for OS X:  
Installation should occur into the application directory, not in the  
Java-VM directory. This simplifies things a lot, as the Mac Installer  
can be removed completely.

- The xcodeproject's build settings need to be updated to generate  
JAVA 1.1 format class files.


Dimitry: do you have time to tackle this? I could do it, but as this  
is "your baby" I thought you may prefer to do it yourself.

Regards,
Joachim



From dmarkman at mac.com  Sun Jun  4 11:27:53 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Sun, 4 Jun 2006 13:27:53 -0400
Subject: [Rxtx] Update of OSX installer, Readme, etc
In-Reply-To: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
References: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
Message-ID: <26E7A202-962B-4C19-93B6-29426C467249@mac.com>

Joachim,
unfortunately I don't have time right now to do that
so if you can do that, please do

it's not only my baby
it's yours too :-)

thanks


On Jun 4, 2006, at 6:12 AM, Joachim Buechse wrote:

> Good day,
>
> after the latest changes a lot of OS X specific files should be
> updated. Especially the installer!
>
> - The "MaxOSX" readme file on the root level is outdated (ie
> CodeWarrior information). Maybe we could even rename it to README.OSX
> to be in line with README.IPAQ, README.SCO (Trent do you mind copying/
> renaming ,v files in the repository?).
>
> - The lock files are no longer used and hence the user group magic
> and lock folder creation should be removed from the installer.
>
> - MACOSX_IDE/ForPackageMaker/Resources/ReadMe.rtf and Welcome.rtf
> need to be updated.
>
> - I suggest to replace the current installation instruction for OS X:
> Installation should occur into the application directory, not in the
> Java-VM directory. This simplifies things a lot, as the Mac Installer
> can be removed completely.
>
> - The xcodeproject's build settings need to be updated to generate
> JAVA 1.1 format class files.
>
>
> Dimitry: do you have time to tackle this? I could do it, but as this
> is "your baby" I thought you may prefer to do it yourself.
>
> Regards,
> Joachim
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman



From tjarvi at qbang.org  Sun Jun  4 13:54:02 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 4 Jun 2006 13:54:02 -0600 (MDT)
Subject: [Rxtx] Update of OSX installer, Readme, etc
In-Reply-To: <26E7A202-962B-4C19-93B6-29426C467249@mac.com>
References: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
	<26E7A202-962B-4C19-93B6-29426C467249@mac.com>
Message-ID: <Pine.LNX.4.61.0606041353040.22522@www>

On Sun, 4 Jun 2006, Dmitry Markman wrote:

> Joachim,
> unfortunately I don't have time right now to do that
> so if you can do that, please do
>
> it's not only my baby
> it's yours too :-)
>

I've given Joachim cvs access.  He has shown good work in bugzilla.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Mon Jun  5 10:08:32 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 5 Jun 2006 18:08:32 +0200
Subject: [Rxtx] Build process changes for Mac OS X
Message-ID: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>

Good day,

I have cleaned up some outdated Mac OSX specific build files in the  
repository.

There was not a lot left of the readme file "MacOSX" after cleaning  
it up, so I decided to rename it README.OSX to be in harmony with the  
other files in the directory (ie README.IPAQ, README.SCO, ...)

I added an (uncompressed) XCode 2.3 project file/structure  
with .cvsignore files that will ignore the user specific settings.  
This should work "out of the box" for OSX10.4. Users of 10.2/10.3 may  
have to switch the build settings.

[It's kind of tricky to choose "the right" setting. Afaik there is no  
way to compile a universal binary that will work on 10.3 or before.  
So it's either UniversalBinary OR Legacy. Maybe we should have  
different build targets for these different targets?? I would like to  
get some feedback from the Mac developers on this list regarding the  
subject].

Besides other things the OSX installer is no longer required. Since  
the next version (2.1.8) will no longer use lockfiles on OSX, the  
group/permission magic is no longer required and hence there remains  
basicly no work for the installer - other than copying 2 files to the  
VM extension directory. Then again, this is not the best way to  
install RXTX. So I removed the installer completely without modifying  
it, this should simplify a "resurrection" should it ever get necessary.

I had problems with the (compressed, ie sit.hqx) legacy project files  
on the latest installation of OSX (javac 1.5 creating non JDK1.1  
class files and some minor problems). To reduce potential confusion  
for newcomers I decided to remove them. This means that there is no  
longer a simple way to build RXTX for OSX 10.0 and 10.1 (I deeply  
apologize if anyone still relied on this ... well the files are in  
the Attiq).

Best regards,
Joachim


From joachim at buechse.de  Mon Jun  5 10:16:37 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 5 Jun 2006 18:16:37 +0200
Subject: [Rxtx] RXTX and lockfiles on OSX [it is fixed now]
Message-ID: <7D2C4418-9397-4B59-8091-9FDE4ED67836@buechse.de>

Quite a number of people contacted me in the last couple of weeks  
because of problems installing RXTX on OSX. I told you to wait for  
the "official" fix. Well, it has been fixed.

So if you were among the people waiting for the solution, you can now  
download the source rxtx-2.1-7r2.zip from the website. Once unpacked  
dont forget to use "cvs up" to update the files to the latest  
version. You can then open MACOSX_IDE/XCode/ 
LibSerialUniversal.xcodeproj with XCode 2.3 and build the libraries  
that no longer try to create lock files.

Regards,
Joachim


From brian at mbari.org  Mon Jun  5 10:52:43 2006
From: brian at mbari.org (Brian Schlining)
Date: Mon, 5 Jun 2006 09:52:43 -0700
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
Message-ID: <78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>

Hi Joachim,

> [It's kind of tricky to choose "the right" setting. Afaik there is no
> way to compile a universal binary that will work on 10.3 or before.
> So it's either UniversalBinary OR Legacy. Maybe we should have
> different build targets for these different targets?? I would like to
> get some feedback from the Mac developers on this list regarding the
> subject].

I imagine most developers will be compiling on 10.4 (It's the nature  
of the coder...gotta have the latest and greatest) and deploying to  
both 10.3 and 10.4; both of which will run Universal Binaries (see  
http://forums.macrumors.com/showthread.php?t=205348). So it sounds  
like you've covered the majority of users. Still, you know someone's  
going to pipe up about needing RXTX on 10.2 so it would be nice to  
have a target to make a PPC only build.

Just my 2 cents

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/1cac8c39/attachment-0019.html

From dmarkman at mac.com  Mon Jun  5 13:47:50 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Mon, 5 Jun 2006 15:47:50 -0400
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
Message-ID: <686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>

I don't think it will be a problem to run universal binary
on 10.2
however if binary has some calls that aren't implemented in 10.2
then you'll have a problem


On Jun 5, 2006, at 12:52 PM, Brian Schlining wrote:

> Hi Joachim,
>
>> [It's kind of tricky to choose "the right" setting. Afaik there is no
>> way to compile a universal binary that will work on 10.3 or before.
>> So it's either UniversalBinary OR Legacy. Maybe we should have
>> different build targets for these different targets?? I would like to
>> get some feedback from the Mac developers on this list regarding the
>> subject].
>
> I imagine most developers will be compiling on 10.4 (It's the  
> nature of the coder...gotta have the latest and greatest) and  
> deploying to both 10.3 and 10.4; both of which will run Universal  
> Binaries (see http://forums.macrumors.com/showthread.php?t=205348).  
> So it sounds like you've covered the majority of users. Still, you  
> know someone's going to pipe up about needing RXTX on 10.2 so it  
> would be nice to have a target to make a PPC only build.
>
> Just my 2 cents
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/9fafc878/attachment-0019.html

From brian at mbari.org  Mon Jun  5 14:52:41 2006
From: brian at mbari.org (Brian Schlining)
Date: Mon, 5 Jun 2006 13:52:41 -0700
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
Message-ID: <E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>

Hi Dmitry,

> I don't think it will be a problem to run universal binary
> on 10.2
> however if binary has some calls that aren't implemented in 10.2
> then you'll have a problem

You're right...I stand corrected.

Note however, to deploy a universal binary to 10.2 RXTX will need to  
use the 10.2 SDK to build the PPC side. (see http:// 
developer.apple.com/documentation/DeveloperTools/Conceptual/ 
cross_development/UniversalBinaries/chapter_4_section_1.html). I  
haven't been paying close attention to the new locking mechanism used  
by RXTX on the Mac...does 10.2 support it?

Joachim, which SDK will you be using by default for building the Mac  
PPC binaries?

>> Hi Joachim,
>>
>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>> is no
>>> way to compile a universal binary that will work on 10.3 or before.
>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>> different build targets for these different targets?? I would  
>>> like to
>>> get some feedback from the Mac developers on this list regarding the
>>> subject].
>>
>> I imagine most developers will be compiling on 10.4 (It's the  
>> nature of the coder...gotta have the latest and greatest) and  
>> deploying to both 10.3 and 10.4; both of which will run Universal  
>> Binaries (see http://forums.macrumors.com/showthread.php? 
>> t=205348). So it sounds like you've covered the majority of users.  
>> Still, you know someone's going to pipe up about needing RXTX on  
>> 10.2 so it would be nice to have a target to make a PPC only build.

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/153bf50e/attachment-0019.html

From dmarkman at mac.com  Mon Jun  5 19:02:04 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Mon, 5 Jun 2006 21:02:04 -0400
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
Message-ID: <7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>

if Joachim didn't change xcode project setting

/Developer/SDKs/MacOSX10.4u.sdk is used to build universal binary

so it's quite possible that it won't run properly on 10.2

so we have to change the building process, so ppc part will be built
with
/Developer/SDKs/MacOSX10.2.8.sdk

and finally to use lipo utility to build universal binaries

Joachim, did you use some specific locking API that wasn't implemented

in MacOSX10.2.8.sdk?

thanks


On Jun 5, 2006, at 4:52 PM, Brian Schlining wrote:

> Hi Dmitry,
>
>> I don't think it will be a problem to run universal binary
>> on 10.2
>> however if binary has some calls that aren't implemented in 10.2
>> then you'll have a problem
>
> You're right...I stand corrected.
>
> Note however, to deploy a universal binary to 10.2 RXTX will need  
> to use the 10.2 SDK to build the PPC side. (see http:// 
> developer.apple.com/documentation/DeveloperTools/Conceptual/ 
> cross_development/UniversalBinaries/chapter_4_section_1.html). I  
> haven't been paying close attention to the new locking mechanism  
> used by RXTX on the Mac...does 10.2 support it?
>
> Joachim, which SDK will you be using by default for building the  
> Mac PPC binaries?
>
>>> Hi Joachim,
>>>
>>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>>> is no
>>>> way to compile a universal binary that will work on 10.3 or before.
>>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>>> different build targets for these different targets?? I would  
>>>> like to
>>>> get some feedback from the Mac developers on this list regarding  
>>>> the
>>>> subject].
>>>
>>> I imagine most developers will be compiling on 10.4 (It's the  
>>> nature of the coder...gotta have the latest and greatest) and  
>>> deploying to both 10.3 and 10.4; both of which will run Universal  
>>> Binaries (see http://forums.macrumors.com/showthread.php? 
>>> t=205348). So it sounds like you've covered the majority of  
>>> users. Still, you know someone's going to pipe up about needing  
>>> RXTX on 10.2 so it would be nice to have a target to make a PPC  
>>> only build.
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/84790f80/attachment-0019.html

From joachim at buechse.de  Tue Jun  6 02:40:47 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 6 Jun 2006 10:40:47 +0200
Subject: [Rxtx] Building on OS X, Impl Changes
In-Reply-To: <7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
Message-ID: <CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>

Good day!

What's in the XCode project setting?
----------

The xcode project remained pretty much the same as before. I excluded  
the user specific files from CVS and changed some settings. I kept  
all the built targets (you shouldn't change what you don't understand;-)

Currently we the following build targets:
    RXTXComm (java files)
    librxtxParallel.jnilib (usefull on the Mac???)
    libI2C.jnilib (not yet working in RXTX)
    libRS485.jnilib (not yet working in RXTX)
    librxtxSerial.jnilib (1)
    librxtxSerial.jnilib Dynamic (2)
    rxtxSerial (3)
We also have the following build configurations for each target:
    Development
    Default
    Deployment

What was changed in the xcode project from previous versions:
- java.souce=1.3 and java.target=1.1 in RXTXComm settings
- removed copying of build products into installer directory
- removed "(Upgraded)" from build target names

What remains to be changed:
- choosing a "non-debug" Build-configuration as default
- potentially removing "Default"/"Development" Build-configurations
- reducing the number of build targets
- creating 10.2 compatible universal binaries

I suggest, that the build configurations should be reduced to 2  
(Debug/Deployment), possibly even 1 (Debug).
I have not yet found the deeper meaning of the build targets(1)(2) 
(3), it seems to me like they should be reduced into one "doing the  
right thing" or maybe into two "rxtxSerial.jnilib Legacy" (back to  
10.2, universal if possible) and "rxtxSerial.jnilib 10.4 
+" (universal, 10.4+).

Should the code work on 10.2?
----------

Absolutely. The code should work on NextStep, in fact on any BSD  
unix. I would go as far as saying, this code should work on any  
POSSIX based unix. All that was added is the call "ioctl(fd,  
TIOCEXCL)" to request excusivity of the port:

http://gemma.apple.com/documentation/DeviceDrivers/Conceptual/ 
WorkingWSerial/WWSerial_SerialDevs/chapter_2_section_8.html

It is not yet "the perfect solution". Normally an open /dev/tty  
(listen for incomming connection) should be "preemptable" by opening  
a /dev/cu (outgoing connection) for the same port. This is not yet  
implemented as it needs calls outside of POSSIX on OSX.

On "classic" systems (like NextStep) this worked based on the  
"carried detect line". open() on /dev/tty.xxx would block until the  
carrier detect signal was raised. As the device was not "opened"  
opening /dev/cu.xxx worked without a hitch. When they ported to the  
Mac this broke. On Macs the "carier detect" is usually not wired.  
Furthermore FAX modems did no longer raise the line. So the OSX  
implementor defined a new call, which is documented here:

http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00045.html

Best regards,
Joachim




On 06.06.2006, at 03:02, Dmitry Markman wrote:

> if Joachim didn't change xcode project setting
>
> /Developer/SDKs/MacOSX10.4u.sdk is used to build universal binary
>
> so it's quite possible that it won't run properly on 10.2
>
> so we have to change the building process, so ppc part will be built
> with
> /Developer/SDKs/MacOSX10.2.8.sdk
>
> and finally to use lipo utility to build universal binaries
>
> Joachim, did you use some specific locking API that wasn't implemented
>
> in MacOSX10.2.8.sdk?
>
> thanks
>
>
> On Jun 5, 2006, at 4:52 PM, Brian Schlining wrote:
>
>> Hi Dmitry,
>>
>>> I don't think it will be a problem to run universal binary
>>> on 10.2
>>> however if binary has some calls that aren't implemented in 10.2
>>> then you'll have a problem
>>
>> You're right...I stand corrected.
>>
>> Note however, to deploy a universal binary to 10.2 RXTX will need  
>> to use the 10.2 SDK to build the PPC side. (see http:// 
>> developer.apple.com/documentation/DeveloperTools/Conceptual/ 
>> cross_development/UniversalBinaries/chapter_4_section_1.html). I  
>> haven't been paying close attention to the new locking mechanism  
>> used by RXTX on the Mac...does 10.2 support it?
>>
>> Joachim, which SDK will you be using by default for building the  
>> Mac PPC binaries?
>>
>>>> Hi Joachim,
>>>>
>>>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>>>> is no
>>>>> way to compile a universal binary that will work on 10.3 or  
>>>>> before.
>>>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>>>> different build targets for these different targets?? I would  
>>>>> like to
>>>>> get some feedback from the Mac developers on this list  
>>>>> regarding the
>>>>> subject].
>>>>
>>>> I imagine most developers will be compiling on 10.4 (It's the  
>>>> nature of the coder...gotta have the latest and greatest) and  
>>>> deploying to both 10.3 and 10.4; both of which will run  
>>>> Universal Binaries (see http://forums.macrumors.com/ 
>>>> showthread.php?t=205348). So it sounds like you've covered the  
>>>> majority of users. Still, you know someone's going to pipe up  
>>>> about needing RXTX on 10.2 so it would be nice to have a target  
>>>> to make a PPC only build.
>>
>> Brian Schlining
>> Software Engineer
>> http://www.mbari.org
>>
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> Dmitry Markman
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Tue Jun  6 07:01:06 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 6 Jun 2006 15:01:06 +0200
Subject: [Rxtx] Serial port code for OS X, future steps
In-Reply-To: <CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
	<CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
Message-ID: <8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>

I posted the "wrong link". There is a correction here:

    http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00059.html

In fact, the 2.1.7 implementation of RXTX has quite some deficiencies  
on OSX. I have tried to supply some patches that don't interfere to  
much with the existing RXTX code base, but there are limits to what  
can be done with local patches.

There are some very intrusive changes that should be done. Ie proper  
mapping of /dev/tty <-> /dev/cu handling to correct behaviour of  
CommPortOwnershipListener (http://java.sun.com/products/javacomm/ 
reference/api/index.html). I dont think this can be done with  
patches. Hence I think, RXTX should be rewritten from scratch de- 
unifying the native code base (and implementing thread safe code on  
the Java side).


How "should" /dev/tty vs /dev/cu be implemented?

=====
The Unix contract is this: An open /dev/tty.xxx port (incomming)  
should be interrupted/auto-closed when opening /dev/cu.xxx (outgoing)  
[if /dev/tty.xxx is not currently handling a communication].  /dev/ 
cu.xxx and /dev/tty.xxx refer to the same device, so owning  
"exclusively" should block both. This should be respected across all  
applications native or Java.

This contract is realizable on OSX with the existing javax.comm  
interface while also respecting (to the biggest part) the contract  
defined by javax.comm.PortOwnershipListener.

The one point where the suggested implementation "breaks" the  
javax.comm contract, is by the fact that one can loose a /dev/tty  
port without calling close. However, the only option I see is to  
always open serial ports "non-exclusively" which would outrule Java  
as a platform for (dormant) applications waiting for incoming  
connections/faxes/etc. There could be a system property to choose the  
intended behavior.
=====

Here is how it could be done on OSX:

Calling port=ComportIdentifier.open("/dev/cu.xxx") opens and owns the  
port exclusively until port.close() is called.
- Java applications listening with a PortOwnershipListener should get  
a PORT_OWNED event reasonably soon.
- Any further attempt by a Java or native application to open "/dev/ 
cu.xxx" or "/dev/tty.xxx" fails.
- /dev/cu.xxx is for "outgoing" connections, so receiving  
PORT_OWNERSHIP_REQUESTED makes little to no sense. With native  
applications it can not be implemented. For Java applications it  
could be implemented (by a hidden communication channel). I think  
it's not worth bothering. If anyone is willing to give up a port to  
others he should use /dev/tty.xxx instead of /dev/cu.xxx.

Registering a PortOwnershipListener on "/dev/cu.xxx" without opening  
it, uses /dev/tty.xxx (native open()) non-exclusively and polls its  
state. PORT_OWNED and PORT_UNOWNED can be produced.

Calling port=ComportIdentifier.open("/dev/tty.xxx") should open the  
port non-exclusively.
- Adding a SerialPortEventListener and reading from the port could be  
allowed while keeping it non-exclusive.
- When port.getOutputStream() is called, the state should be changed  
to an "exclusive" ownership. This may be configurable via a system  
property.
- To return to the non-exclusive state the port must be closed and  
reopened.
- While non-exclusively opened, opening the corresponding /dev/cu.xxx  
produces a PORT_OWNERSHIP_REQUESTED event. Which should be responded  
by closing the port from within the callback (as described in  
java.comm.PortOwnershipListener). If there is a pending read, it will  
return after the listener finishes (with -1 or "0 bytes read").
- Calling write() on the /dev/tty.xxx after somebody opened /dev/ 
cu.xxx will fail with a descriptive IOException.
- Calling read() on the /dev/tty.xxx after somebody opened /dev/ 
cu.xxx will fail with a descriptive IOException (or potentially  
block, see side notes below).

CommPortIdentifier.getCurrentOwner() can be implemented by an  
external call to lsof.

CommPortIdentifier.isCurrentlyOwned() can be implemented by trying an  
open on the /dev/tty.
- It returns true if the port is currently held "exclusively".
- Whether it should also return true on /dev/tty if /dev/tty is  
already opened non-exclusively might be a system property option. In  
general, having several applications waiting for incoming connections  
on the same port will require an application level "arbitration"  
protocol...

[[side note1: One interesting question is, what happens if the  
process holding /dev/tty non-exclusively ignores  
PORT_OWNERSHIP_REQUESTED. Ie after "loosing" a non-exclusively opened  
"dev/tty.xxx" port to another process. One possible implementation  
is, that the port is "regained" when the other process gives up the  
port. This would mean that in the meanwhile read() returns no data,  
and any changes to the configuration of the port are stored but not  
forwarded. I guess, the safe (and simple) way to do this is to make  
the close() mandatory (ie setting the port into an "awaiting_close"  
state which produces IOExceptions to any other call than close). ]]

[[side note2:  Another interesting question is, what should happen if  
several applications open the same /dev/tty.xxx port "non- 
exclusively" and start to change the settings of the device.]]

Regards,
Joachim



On 06.06.2006, at 10:40, Joachim Buechse wrote:

> Should the code work on 10.2?
> ----------
>
> Absolutely. The code should work on NextStep, in fact on any BSD
> unix. I would go as far as saying, this code should work on any
> POSSIX based unix. All that was added is the call "ioctl(fd,
> TIOCEXCL)" to request excusivity of the port:
>
> http://gemma.apple.com/documentation/DeviceDrivers/Conceptual/
> WorkingWSerial/WWSerial_SerialDevs/chapter_2_section_8.html
>
> It is not yet "the perfect solution". Normally an open /dev/tty
> (listen for incomming connection) should be "preemptable" by opening
> a /dev/cu (outgoing connection) for the same port. This is not yet
> implemented as it needs calls outside of POSSIX on OSX.
>
> On "classic" systems (like NextStep) this worked based on the
> "carried detect line". open() on /dev/tty.xxx would block until the
> carrier detect signal was raised. As the device was not "opened"
> opening /dev/cu.xxx worked without a hitch. When they ported to the
> Mac this broke. On Macs the "carier detect" is usually not wired.
> Furthermore FAX modems did no longer raise the line. So the OSX
> implementor defined a new call, which is documented here:
>
> http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00045.html
>
> Best regards,
> Joachim



From sds at dcs.gla.ac.uk  Tue Jun  6 11:22:45 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Tue, 06 Jun 2006 18:22:45 +0100
Subject: [Rxtx] Correct compile flag for HP iPAQ hx4700 running Familiar
	Linux?
Message-ID: <1149614565.19496.10.camel@addu>

Hi,

I'd like to use RXTX 2.1 on my HP iPAQ hx4700. The iPAQ is running
Familiar Linux 0.8.2 (as I recall), with Blackdown Java 1.3.1.

I can compile and run a test program which uses RXTX on my i686 machine,
and it works fine. But I can't seem to get things working quite right on
my PDA.

I compile the code on the laptop with the following commands:
	./configure --host=arm-gnu-linux && make
... as suggested in a post to this list, albeit some time ago. This
compiles, I transfer the files, set up LD_LIBRARY_PATH and CLASSPATH
variables, and get the following error on the PDA:

sds at ipaq-pxa-2:~# java Test
java.lang.UnsatisfiedLinkError: /usr/local/lib/ext/librxtxSerial.so: /usr/local/lib/ext/librxtxSerial.so: cannot open shared object file: No such file or directory thrown while loading gnu.io.RXTXCommDriver
Exception in thread "main"
java.lang.UnsatisfiedLinkError: /usr/local/lib/ext/librxtxSerial.so: /usr/local/lib/ext/librxtxSerial.so: cannot open shared object file: No such file or directory
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1382)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1290)
        at java.lang.Runtime.loadLibrary0(Runtime.java:749)
        at java.lang.System.loadLibrary(System.java:820)
        at
gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:83)
        at Test.<init>(Test.java:9)
        at Test.main(Test.java:32)
sds at ipaq-pxa-2:~# 

Note that I'm copying the files to /usr/local/lib/ext/ along with the
RXTXcomm.jar file, purely to keep things separate from the rest of the
system while testing. The location of the .so files doesn't seem to have
any bearing on whether "java Test" will succeed or not. The contents of
this directory are:

sds at ipaq-pxa-2:~$ ls /usr/local/lib/ext/
RXTXcomm.jar              librxtxParallel-2.1-7.so  librxtxRS485.so
librxtxSerial-2.1-7.so
librxtxI2C-2.1-7.so       librxtxParallel.so        librxtxRaw-2.1-7.so
librxtxSerial.so
librxtxI2C.so             librxtxRS485-2.1-7.so     librxtxRaw.so
sds at ipaq-pxa-2:~$

Test.java fails on the first real line of code I'm using to test that
things are working, prior to real development, and was carefully pinched
from the web:
Enumeration portIdentifiers = CommPortIdentifier.getPortIdentifiers();


I assume that I've gotten my --host flag wrong way back up there at
the ./configure step. But if that's the case, what should I set it to?
Or am I missing something more obvious?


Cheers,
Stephen Strowes,
University of Glasgow.




From tjarvi at qbang.org  Tue Jun  6 13:39:41 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 6 Jun 2006 13:39:41 -0600 (MDT)
Subject: [Rxtx] Serial port code for OS X, future steps
In-Reply-To: <8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
	<CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
	<8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>
Message-ID: <Pine.LNX.4.61.0606061315070.9856@www>


>>
There are some very intrusive changes that should be done. Ie proper
mapping of /dev/tty <-> /dev/cu handling to correct behaviour of
CommPortOwnershipListener (http://java.sun.com/products/javacomm/
reference/api/index.html). I dont think this can be done with
patches. Hence I think, RXTX should be rewritten from scratch de-
unifying the native code base (and implementing thread safe code on
the Java side).
<<

This appears to be a very small amount of functionality for a total 
rewrite.  The port ownership only needs maybe 3 native calls if it is done 
with native calls at all.

Those features which are not part of the Unix standard(s) can be special 
cased.  I'm not sure /dev/cu is standard.  We can look.  I know linux 
deprecated /dev/cua years ago.

Thread safe Java code is not a platform specific issue.

--
Trent Jarvi
tjarvi at qbang.org


From sds at dcs.gla.ac.uk  Wed Jun  7 12:36:43 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Wed, 07 Jun 2006 19:36:43 +0100
Subject: [Rxtx] Expected RXTX behaviour?
In-Reply-To: <1149703900.30891.19.camel@addu>
References: <1149703900.30891.19.camel@addu>
Message-ID: <1149705403.30891.25.camel@addu>

Apologies, caught the problem. Had to append '\r' to the end of the AT
string. A non obvious but stupid mistake... :-)

Final quick question though: How might I stop the echoing of
outputStream data back into the inputStream? I still see the ATI
commands on the inputStream, along with the output from the device.


Cheers,
S.



On Wed, 2006-06-07 at 19:11 +0100, Stephen Strowes wrote:
> Hi,
> 
> I managed to get RXTX to compile for my iPAQ following my previous post
> to this list. Quick query though:
> 
> I want to be able to issue AT commands to a device, and interpret the
> responses. For this, I assume I do the following, in psuedo-form:
> 
> 	CommPortIdentifier.getPortIdentifiers();
> 	// find the correct device id
> 	serialPort= (SerialPort)portID.open("Test");
> 	// Set parameters and flow control
> 	outputStream= serialPort.getOutputStream();
> 	inputStream=  serialPort.getInputStream();
> 
> ... following this, I spawn a thread to respond to DATA_AVAILABLE events
> on serialPort with inputStream, and occasionally write and flush an
> "ATI" onto the outputStream. Nothing complex, I just want to see it
> work.
> 
> I would have expected inputStream to give the same information back from
> an "ATI" command as minicom provides, but instead inputStream only sees
> the "ATI" I put onto the outputStream.
> 
> Have I missed something?
> 
> 
> Cheers,
> S.
> 



From sds at dcs.gla.ac.uk  Wed Jun  7 12:11:40 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Wed, 07 Jun 2006 19:11:40 +0100
Subject: [Rxtx] Expected RXTX behaviour?
Message-ID: <1149703900.30891.19.camel@addu>

Hi,

I managed to get RXTX to compile for my iPAQ following my previous post
to this list. Quick query though:

I want to be able to issue AT commands to a device, and interpret the
responses. For this, I assume I do the following, in psuedo-form:

	CommPortIdentifier.getPortIdentifiers();
	// find the correct device id
	serialPort= (SerialPort)portID.open("Test");
	// Set parameters and flow control
	outputStream= serialPort.getOutputStream();
	inputStream=  serialPort.getInputStream();

... following this, I spawn a thread to respond to DATA_AVAILABLE events
on serialPort with inputStream, and occasionally write and flush an
"ATI" onto the outputStream. Nothing complex, I just want to see it
work.

I would have expected inputStream to give the same information back from
an "ATI" command as minicom provides, but instead inputStream only sees
the "ATI" I put onto the outputStream.

Have I missed something?


Cheers,
S.




From joachim at buechse.de  Wed Jun  7 09:02:13 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 7 Jun 2006 17:02:13 +0200
Subject: [Rxtx] Update of build process for OSX (XCode project)
Message-ID: <62EC47B1-46BD-4ECA-B9EC-C4061D147CDA@buechse.de>

With the help of Dmitry Markman and Brian Schilling I have updated  
(and largely simplifed) the XCode project file for Mac OS X.

Changes:
- compiles a universal binary library with intel=OSX10.4+, ppc=OSX10.2 
+ support
- compiles the Java sources into a JRE1.1 compatible, compressed jar.

Please test on your configuration, especially if you have computers  
running 10.2/10.3 or intel.

Best regards,
Joachim


From joachim at buechse.de  Wed Jun  7 14:36:37 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 7 Jun 2006 22:36:37 +0200
Subject: [Rxtx] Expected RXTX behaviour?
In-Reply-To: <1149705403.30891.25.camel@addu>
References: <1149703900.30891.19.camel@addu> <1149705403.30891.25.camel@addu>
Message-ID: <D3AD6EAF-27BB-455E-9697-86C1121920C3@buechse.de>

Echoing is a feature of the modem. Try ATE0 which works with most  
"rockwell" compatible modems.

Regards,
Joachim


On 07.06.2006, at 20:36, Stephen Strowes wrote:

> Apologies, caught the problem. Had to append '\r' to the end of the AT
> string. A non obvious but stupid mistake... :-)
>
> Final quick question though: How might I stop the echoing of
> outputStream data back into the inputStream? I still see the ATI
> commands on the inputStream, along with the output from the device.
>
>
> Cheers,
> S.
>
>
>
> On Wed, 2006-06-07 at 19:11 +0100, Stephen Strowes wrote:
>> Hi,
>>
>> I managed to get RXTX to compile for my iPAQ following my previous  
>> post
>> to this list. Quick query though:
>>
>> I want to be able to issue AT commands to a device, and interpret the
>> responses. For this, I assume I do the following, in psuedo-form:
>>
>> 	CommPortIdentifier.getPortIdentifiers();
>> 	// find the correct device id
>> 	serialPort= (SerialPort)portID.open("Test");
>> 	// Set parameters and flow control
>> 	outputStream= serialPort.getOutputStream();
>> 	inputStream=  serialPort.getInputStream();
>>
>> ... following this, I spawn a thread to respond to DATA_AVAILABLE  
>> events
>> on serialPort with inputStream, and occasionally write and flush an
>> "ATI" onto the outputStream. Nothing complex, I just want to see it
>> work.
>>
>> I would have expected inputStream to give the same information  
>> back from
>> an "ATI" command as minicom provides, but instead inputStream only  
>> sees
>> the "ATI" I put onto the outputStream.
>>
>> Have I missed something?
>>
>>
>> Cheers,
>> S.
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From g_petrini at yahoo.it  Thu Jun  8 01:41:58 2006
From: g_petrini at yahoo.it (Giacomo Petrini)
Date: Thu, 8 Jun 2006 09:41:58 +0200 (CEST)
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from FieldTalk
Message-ID: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>

Hi,
I'm evaluating the library for the modbus protocol
from FieldTalk
(http://www.modbusdriver.com/fieldtalk/.
I'm using J2SE 5.0 and RXTX 2.1 on win XP.
The problem is that the modbus lib has a method (the
openProtocol method, but maybe there are others) tha
throws the
javax.comm.UnsupportedCommOperationException.
Now, in RXTX 2.1 the namespace has changed in gnu.io,
so the modbus library doesn't work anymore (it look
for things in javax.comm). I've already sent an email
to fieldtalk to see if they are aware of the problem.
The solution should be to use JavaComm + RXTX 2.0. But
I've read somewhere that JavaComm 2.0 does not work
with Java 5.0 and JavaComm 3.0 does not work with RXTX
2.0 so I don't know what to do.

Any ideas?

Thanks Jack

PS: can you make a CC to my personal email
(g_petrini at yahoo.it) too please?

Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 


From rxtx at tapastda.co.uk  Thu Jun  8 02:27:57 2006
From: rxtx at tapastda.co.uk (rxtx@tapastda.co.uk)
Date: Thu, 08 Jun 2006 09:27:57 +0100
Subject: [Rxtx] Win XP and Infrared based serial port
Message-ID: <4487DF8D.5050807@tapastda.co.uk>

I'm attempting to use RXTX 2.1.7 on Win XP with J2SE 5.0 to communicate with a
GSM mobile using a COM port. A peculiarity that I've seen is that whilst I can
communicate successfully with a mobile which uses an infrared based COM port
using the SUN provided javax.comm (v2.0) I cannot use RXTX because it fails to
read anything from the port (i.e. read timeout always occurs returning zero bytes).

I assumed that this could be the result of flow control problems and thus I've
tried setting either software or hardware based flow control on the port however
this has no affect.

Can you suggest any other port configuration changes which might be required to
make such a port work with RXTX.

Thanks
Stu
-- 
Stuart
Tapastda Limited


From tjarvi at qbang.org  Thu Jun  8 05:17:12 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 8 Jun 2006 05:17:12 -0600 (MDT)
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from
	FieldTalk
In-Reply-To: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
References: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606080504480.9856@www>

On Thu, 8 Jun 2006, Giacomo Petrini wrote:

> Hi,
> I'm evaluating the library for the modbus protocol
> from FieldTalk
> (http://www.modbusdriver.com/fieldtalk/.
> I'm using J2SE 5.0 and RXTX 2.1 on win XP.
> The problem is that the modbus lib has a method (the
> openProtocol method, but maybe there are others) tha
> throws the
> javax.comm.UnsupportedCommOperationException.
> Now, in RXTX 2.1 the namespace has changed in gnu.io,
> so the modbus library doesn't work anymore (it look
> for things in javax.comm). I've already sent an email
> to fieldtalk to see if they are aware of the problem.
> The solution should be to use JavaComm + RXTX 2.0. But
> I've read somewhere that JavaComm 2.0 does not work
> with Java 5.0 and JavaComm 3.0 does not work with RXTX
> 2.0 so I don't know what to do.
>
> Any ideas?
>
> Thanks Jack
>


Hi Jack

There are plans for Sun to rerelease JavaComm 2.0 mentioned in the rxtx 
mail-list archives.  When this happens rxtx will release a current rxtx 
2.0 library that works with it.

There are no dates promised by either side but rxtx will do it as soon as 
possible after Sun's rerelease.  Just to give you a feel for the time 
frame, this started last year and no significant progress has been made. 
There have been friendly talks pointing towards solutions (rerelease 2.0) 
but that does not get your application working today.  rxtx is preparing 
for its second release in gnu.io since then.

--
Trent Jarvi
tjarvi at qbang.org




From jredman at ergotech.com  Thu Jun  8 08:47:23 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 08 Jun 2006 08:47:23 -0600
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from
	FieldTalk
In-Reply-To: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
References: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
Message-ID: <4488387B.6040903@ergotech.com>

You could always try a different library, eg.

http://sourceforge.net/projects/jamod

I've only used the slave side since we have our own implementation of 
Modbus Client (and a host of other PLC protocols).  However the client 
side seems to be pretty well supported and fairly widely used.  Since 
the source is there you could change to gnu.io.

I think I should take more of an interest in this issue.  We generally 
run 1.4.2 on Linux, but also have some J9 and old platforms that we 
support that are basically Personal Java.  5.0 on Linux has some 
horrible MDI bugs, to the point of being unusable.   Sounds as though we 
are going to have code compatibility problems across these platforms.

Jim


Giacomo Petrini wrote:
> Hi,
> I'm evaluating the library for the modbus protocol
> from FieldTalk
> (http://www.modbusdriver.com/fieldtalk/.
> I'm using J2SE 5.0 and RXTX 2.1 on win XP.
> The problem is that the modbus lib has a method (the
> openProtocol method, but maybe there are others) tha
> throws the
> javax.comm.UnsupportedCommOperationException.
> Now, in RXTX 2.1 the namespace has changed in gnu.io,
> so the modbus library doesn't work anymore (it look
> for things in javax.comm). I've already sent an email
> to fieldtalk to see if they are aware of the problem.
> The solution should be to use JavaComm + RXTX 2.0. But
> I've read somewhere that JavaComm 2.0 does not work
> with Java 5.0 and JavaComm 3.0 does not work with RXTX
> 2.0 so I don't know what to do.
> 
> Any ideas?
> 
> Thanks Jack
> 
> PS: can you make a CC to my personal email
> (g_petrini at yahoo.it) too please?
> 
> Chiacchiera con i tuoi amici in tempo reale! 
>  http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  8 18:17:23 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 08 Jun 2006 17:17:23 -0700
Subject: [Rxtx] rxtx access is denied error
Message-ID: <4488BE13.2050706@dupreeinc.com>

Hello,

I have been trying to replace the commapi from sun with rxtx for a 
project that communicates with a serial port that is a USB-Serial 
interface.  To be exact, I am using the FTDI VCP driver with one of 
their modules connected to a windows XP system.

I have the RXTX package working pretty well as long as nothing goes wrong.

If a user disconnects the USB port while my java application is running, 
my application goes into an endless loop with lots of messages in the  
errors stream  like the ones below:

    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(481):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.


I believe when this happens the COM port completely disappears and the 
rxtx driver has a heart attack.  Obviously, the user should not do this, 
but my application needs to ideally, correct the situation or as a worse 
case, terminate with a little dignity.  Currently, I have not figured 
out how to catch this error.

The closest I have come is to trap an exception to my input stream read  
that says "No error in readByte"  This error appears to be outside of 
the endless loop of the errors listed above.

Does anybody have an idea of how to identify and trap this error?  Any 
suggestions on how to gracefully recover from it would be greatly 
appreciated!

Thank you for your time,

Doug Thistlethwaite




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060608/9cfca302/attachment-0019.html

From tjarvi at qbang.org  Thu Jun  8 20:54:17 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 8 Jun 2006 20:54:17 -0600 (MDT)
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <4488BE13.2050706@dupreeinc.com>
References: <4488BE13.2050706@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606082022580.1323@www>

On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I have been trying to replace the commapi from sun with rxtx for a project 
> that communicates with a serial port that is a USB-Serial interface.  To be 
> exact, I am using the FTDI VCP driver with one of their modules connected to 
> a windows XP system.
>
> I have the RXTX package working pretty well as long as nothing goes wrong.
>
> If a user disconnects the USB port while my java application is running, my 
> application goes into an endless loop with lots of messages in the  errors 
> stream  like the ones below:
>
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(481):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>
>
> I believe when this happens the COM port completely disappears and the rxtx 
> driver has a heart attack.  Obviously, the user should not do this, but my 
> application needs to ideally, correct the situation or as a worse case, 
> terminate with a little dignity.  Currently, I have not figured out how to 
> catch this error.
>
> The closest I have come is to trap an exception to my input stream read  that 
> says "No error in readByte"  This error appears to be outside of the endless 
> loop of the errors listed above.
>
> Does anybody have an idea of how to identify and trap this error?  Any 
> suggestions on how to gracefully recover from it would be greatly 
> appreciated!
>

Hi Doug

Sadly I don't have a quick solution for you.

Termios has no knowlage about the JVM so it wont be throwing exceptions 
you can catch.

We can return error and set the error number to something reasonable that 
results in an exception.  The No Error message simply means we did not set 
an error number in termios.c.  Those are the line numbers in the code you 
see.  SerialImp.c realizes it errored but does not know much more yet. 
Everything touching the file descriptor is going to error after the port 
is gone presumably.

We don't currently have a plan in place for vanishing (or appearing) com 
ports.

Another example of what we need to think about is what happens if you 
start your application and then plug in the dongle?  Or what if you unplug 
and then plug it in again?

So in each of these three cases, what would the behavior of the (yet to 
be) correct implementation do?

How will the enumerated ports be handled during these changes?

There can also be hints from the OS that could be taken into 
consideration.

We can probably get some exceptions thrown that make sense and null the 
file descriptor when it happens to prevent io attempts.  That would be a 
crude way to let applications know something strange has happened.

Is anyone else tinkering with this problem?

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  9 01:31:29 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 9 Jun 2006 09:31:29 +0200
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <Pine.LNX.4.61.0606082022580.1323@www>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
Message-ID: <AC6EDDDD-0A64-401F-B16B-E484788CDF4A@buechse.de>

Hello Trent,

I am not tinkering with this on the Source Level - but I think it  
should work pretty much the same way as it currently does in OSX.  
When the port goes away you get an IOException thrown for any read/ 
write. It will no longer be in the list of ports from  
CommPortIdentifier.getPortIdentifiers(). When a port (re-)appears it  
is added to the list. It's up to the application to re-check the list  
from time to time.

On Windows you can't do much better then that, because the ports  
don't have useful names. Which USB "virtual com port" is on which  
COMx depends on the order the devices were added. So reconnecting to  
the same device may mean connecting to another port.

Regarding the exception thrown: it would be nice to use an  
IOException subclass but the Exception message should definetly be  
informative also as most applications may want to keep compatibility  
with javax.comm.

Regards,
Joachim


On 09.06.2006, at 04:54, Trent Jarvi wrote:

> On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:
>
>> Hello,
>>
>> I have been trying to replace the commapi from sun with rxtx for a  
>> project
>> that communicates with a serial port that is a USB-Serial  
>> interface.  To be
>> exact, I am using the FTDI VCP driver with one of their modules  
>> connected to
>> a windows XP system.
>>
>> I have the RXTX package working pretty well as long as nothing  
>> goes wrong.
>>
>> If a user disconnects the USB port while my java application is  
>> running, my
>> application goes into an endless loop with lots of messages in  
>> the  errors
>> stream  like the ones below:
>>
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (481):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>
>>
>> I believe when this happens the COM port completely disappears and  
>> the rxtx
>> driver has a heart attack.  Obviously, the user should not do  
>> this, but my
>> application needs to ideally, correct the situation or as a worse  
>> case,
>> terminate with a little dignity.  Currently, I have not figured  
>> out how to
>> catch this error.
>>
>> The closest I have come is to trap an exception to my input stream  
>> read  that
>> says "No error in readByte"  This error appears to be outside of  
>> the endless
>> loop of the errors listed above.
>>
>> Does anybody have an idea of how to identify and trap this error?   
>> Any
>> suggestions on how to gracefully recover from it would be greatly
>> appreciated!
>>
>
> Hi Doug
>
> Sadly I don't have a quick solution for you.
>
> Termios has no knowlage about the JVM so it wont be throwing  
> exceptions
> you can catch.
>
> We can return error and set the error number to something  
> reasonable that
> results in an exception.  The No Error message simply means we did  
> not set
> an error number in termios.c.  Those are the line numbers in the  
> code you
> see.  SerialImp.c realizes it errored but does not know much more yet.
> Everything touching the file descriptor is going to error after the  
> port
> is gone presumably.
>
> We don't currently have a plan in place for vanishing (or  
> appearing) com
> ports.
>
> Another example of what we need to think about is what happens if you
> start your application and then plug in the dongle?  Or what if you  
> unplug
> and then plug it in again?
>
> So in each of these three cases, what would the behavior of the  
> (yet to
> be) correct implementation do?
>
> How will the enumerated ports be handled during these changes?
>
> There can also be hints from the OS that could be taken into
> consideration.
>
> We can probably get some exceptions thrown that make sense and null  
> the
> file descriptor when it happens to prevent io attempts.  That would  
> be a
> crude way to let applications know something strange has happened.
>
> Is anyone else tinkering with this problem?
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From doug at dupreeinc.com  Fri Jun  9 13:09:58 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 09 Jun 2006 12:09:58 -0700
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <Pine.LNX.4.61.0606082022580.1323@www>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
Message-ID: <4489C786.9050504@dupreeinc.com>


Ideally, it would be nice if it would throw an exception and terminate 
the loop.  I am still trying to figure out how to detect the condition 
and recover form it in some form...  I am getting the "No error in 
readByte" exception in my serialEvent() method after an input stream 
read.  It appears to me that the only graceful recovery is to close the 
port and then reopen it when it becomes available.  I can pass the event 
up to the update method in my main frame, but I still can't close the 
port from within that thread.  Any suggestions on how to pass this event 
to a location where the port can be safely closed?

Re: Slow startup in windows XP
I have been looking into this a little closer and have found out the 
following:
System Windows XP Pro 3GHz dual core with 1GB RAM and NO parallel port.
Starting the SerialDemo included with the commapi using the rxtx instead 
of javax.comm takes 60 seconds.
Starting the SerialDemo using rxrx with the rxtxParallel.dll file 
removed takes about 20 seconds.
Modify initialize in RXRXCommDriver.java to not test the parallel ports 
takes less than 1 second.

It would be nice if the initialize routine could detect the presence of 
rxtxParallel.dll file and just skip the whole process if not present.  
Is there an easy way to check for the presence of this file without 
running the parallel port test?

Doug


 

Trent Jarvi wrote:

>On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:
>...
>  
>
>
>Hi Doug
>
>Sadly I don't have a quick solution for you.
>
>Termios has no knowlage about the JVM so it wont be throwing exceptions 
>you can catch.
>
>We can return error and set the error number to something reasonable that 
>results in an exception.  The No Error message simply means we did not set 
>an error number in termios.c.  Those are the line numbers in the code you 
>see.  SerialImp.c realizes it errored but does not know much more yet. 
>Everything touching the file descriptor is going to error after the port 
>is gone presumably.
>
>We don't currently have a plan in place for vanishing (or appearing) com 
>ports.
>
>Another example of what we need to think about is what happens if you 
>start your application and then plug in the dongle?  Or what if you unplug 
>and then plug it in again?
>
>So in each of these three cases, what would the behavior of the (yet to 
>be) correct implementation do?
>
>How will the enumerated ports be handled during these changes?
>
>There can also be hints from the OS that could be taken into 
>consideration.
>
>We can probably get some exceptions thrown that make sense and null the 
>file descriptor when it happens to prevent io attempts.  That would be a 
>crude way to let applications know something strange has happened.
>
>Is anyone else tinkering with this problem?
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060609/911ed787/attachment-0019.html

From Ugo.Landini at Sun.COM  Fri Jun  2 14:23:47 2006
From: Ugo.Landini at Sun.COM (Ugo Landini)
Date: Fri, 02 Jun 2006 22:23:47 +0200
Subject: [Rxtx] OSX 10.4.7 and usb
Message-ID: <44809E53.2070905@sun.com>

Hi, I have installed the library and the native libraries on OSX 10.4.7. 
Then I have run this simple code:

...
while (portList.hasMoreElements()) {
             portId = (CommPortIdentifier) portList.nextElement();
             System.out.println("-> " + portId.getName() + " Port Type:" 
+ portId.getPortType());
...

and the output is:

Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7

Ports found:
-> /dev/tty.Bluetooth-PDA-Sync Port Type:1
-> /dev/cu.Bluetooth-PDA-Sync Port Type:1
-> /dev/tty.Bluetooth-Modem Port Type:1
-> /dev/cu.Bluetooth-Modem Port Type:1

I can't see any USB ports... with javax.comm on linux I could see the 
/dev/ttyUSB stuff, but that's not the case with OSX. Any idea?

tia

uL


From tod at todbot.com  Sun Jun 11 12:04:37 2006
From: tod at todbot.com (Tod E. Kurt)
Date: Sun, 11 Jun 2006 11:04:37 -0700
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <44809E53.2070905@sun.com>
References: <44809E53.2070905@sun.com>
Message-ID: <E2EB14A1-20A7-4611-8F1A-E3D2ABE41F48@todbot.com>

A dumb question, but: do you have the USB serial adapters plugged  
in?  They only show up in /dev when plugged in.  Also, you can verify  
they exist independent of RXTX by doing something like "ls -l /dev/ 
cu.*".

On Jun 2, 2006, at 1:23 PM, Ugo Landini wrote:

> Hi, I have installed the library and the native libraries on OSX  
> 10.4.7.
> Then I have run this simple code:
>
> ...
> while (portList.hasMoreElements()) {
>              portId = (CommPortIdentifier) portList.nextElement();
>              System.out.println("-> " + portId.getName() + " Port  
> Type:"
> + portId.getPortType());
> ...
>
> and the output is:
>
> Experimental:  JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
>
> Ports found:
> -> /dev/tty.Bluetooth-PDA-Sync Port Type:1
> -> /dev/cu.Bluetooth-PDA-Sync Port Type:1
> -> /dev/tty.Bluetooth-Modem Port Type:1
> -> /dev/cu.Bluetooth-Modem Port Type:1
>
> I can't see any USB ports... with javax.comm on linux I could see the
> /dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>
> tia
>
> uL
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>



From lyon at docjava.com  Sun Jun 11 12:14:50 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Sun, 11 Jun 2006 14:14:50 -0400
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <44809E53.2070905@sun.com>
References: <44809E53.2070905@sun.com>
Message-ID: <p06020444c0b20de7d248@[192.168.1.152]>

>Hi Ugo,

Do you have any USB serial ports (like the keyspan 19-HS) plugged
into the mac?
Thanks!
  - DL


>Hi, I have installed the library and the native libraries on OSX 10.4.7.
>Then I have run this simple code:
>
>...
>while (portList.hasMoreElements()) {
>              portId = (CommPortIdentifier) portList.nextElement();
>              System.out.println("-> " + portId.getName() + " Port Type:"
>+ portId.getPortType());
>...
>
>and the output is:
>
>Experimental:  JNI_OnLoad called.
>Stable Library
>=========================================
>Native lib Version = RXTX-2.1-7
>Java lib Version   = RXTX-2.1-7
>
>Ports found:
>-> /dev/tty.Bluetooth-PDA-Sync Port Type:1
>-> /dev/cu.Bluetooth-PDA-Sync Port Type:1
>-> /dev/tty.Bluetooth-Modem Port Type:1
>-> /dev/cu.Bluetooth-Modem Port Type:1
>
>I can't see any USB ports... with javax.comm on linux I could see the
>/dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>
>tia
>
>uL
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx



From dmarkman at mac.com  Sun Jun 11 14:30:27 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Sun, 11 Jun 2006 16:30:27 -0400
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <p06020444c0b20de7d248@[192.168.1.152]>
References: <44809E53.2070905@sun.com> <p06020444c0b20de7d248@[192.168.1.152]>
Message-ID: <B9C1606B-4339-4564-A175-FE83DFFA7D76@mac.com>

afaik
10.4.7 wasn't released yet
it will soon, no doubts


On Jun 11, 2006, at 2:14 PM, Dr. Douglas Lyon wrote:

>> Hi Ugo,
>
> Do you have any USB serial ports (like the keyspan 19-HS) plugged
> into the mac?
> Thanks!
>   - DL
>
>
>> Hi, I have installed the library and the native libraries on OSX  
>> 10.4.7.
>> Then I have run this simple code:
>>
>> ...
>> while (portList.hasMoreElements()) {
>>              portId = (CommPortIdentifier) portList.nextElement();
>>              System.out.println("-> " + portId.getName() + " Port  
>> Type:"
>> + portId.getPortType());
>> ...
>>
>> and the output is:
>>
>> Experimental:  JNI_OnLoad called.
>> Stable Library
>> =========================================
>> Native lib Version = RXTX-2.1-7
>> Java lib Version   = RXTX-2.1-7
>>
>> Ports found:
>> -> /dev/tty.Bluetooth-PDA-Sync Port Type:1
>> -> /dev/cu.Bluetooth-PDA-Sync Port Type:1
>> -> /dev/tty.Bluetooth-Modem Port Type:1
>> -> /dev/cu.Bluetooth-Modem Port Type:1
>>
>> I can't see any USB ports... with javax.comm on linux I could see the
>> /dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>>
>> tia
>>
>> uL
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman



From tjarvi at qbang.org  Sun Jun 11 18:52:59 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 11 Jun 2006 18:52:59 -0600 (MDT)
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <4489C786.9050504@dupreeinc.com>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
	<4489C786.9050504@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606111845430.7274@www>

On Fri, 9 Jun 2006, Doug Thistlethwaite wrote:

>
> Ideally, it would be nice if it would throw an exception and terminate the 
> loop.  I am still trying to figure out how to detect the condition and 
> recover form it in some form...  I am getting the "No error in readByte" 
> exception in my serialEvent() method after an input stream read.  It appears 
> to me that the only graceful recovery is to close the port and then reopen it 
> when it becomes available.  I can pass the event up to the update method in 
> my main frame, but I still can't close the port from within that thread.  Any 
> suggestions on how to pass this event to a location where the port can be 
> safely closed?
>

I've gone through and cleaned up the termios.c layer.  I need to get to a 
windows machine with a USB dongle and see where the ioctl() is being 
called.  Probably the eventLoop.  But all of the ioctls should probably 
result in an IOException during this condition.

I'll probably finish this up Monday night when I can borrow a USB 
dongle.

There is no point in putting the code into CVS yet.  If you are tinkering 
I can mail the patch.  I think we will want to make a couple fixes in 
SerialImp.c to handle errors before it's ready.

--
Trent Jarvi
tjarvi at qbang.org



From bob_tai2001 at yahoo.com  Mon Jun 12 09:42:14 2006
From: bob_tai2001 at yahoo.com (Bob Tai)
Date: Mon, 12 Jun 2006 08:42:14 -0700 (PDT)
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to RXTX
	again
Message-ID: <20060612154214.58219.qmail@web32804.mail.mud.yahoo.com>


thank you Paul, Joachim, Trent and everyone try to
workout the java comm and Rxtx situation.  At least
now I have something that is solid enough to make my
decision.  

thank you,
     Bob

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From Ralph.Buchfelder at gmx.net  Mon Jun 12 15:30:20 2006
From: Ralph.Buchfelder at gmx.net (Ralph Buchfelder)
Date: Mon, 12 Jun 2006 23:30:20 +0200
Subject: [Rxtx] rxtx binaries or porting to XSCALE Windows Mobile 2003 / 2005
Message-ID: <448DDCEC.7090506@gmx.net>

dear group,

i have been carefully reading your homepage, wiki and archives
but there seems to be no detailled information on porting to Windows 
Mobile/CE.

as far as i understood from the 'porting' section you can do porting to 
winCE. but how? do i only need to obtain the sourcecode (which one?) and 
compile this in Microsoft eMbedded Visual C++ for ARM/Xscale?
Any other ways?


unfortunately i must admit that i do have little linux skills but i have 
made my way through gcc and makefiles. right now i need to implement com 
  communication in a J2ME application and found your website as >the< 
solution.

best regards
Ralph Buchfelder

University of Regensburg
Department of Geography

PS: i dont care about Javacomm compliancy (ie. 2.0 or 2.1) - i just need 
a working serial port API in IBM J9 VM.


From paul.klissner at sun.com  Wed Jun 14 18:12:58 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Wed, 14 Jun 2006 17:12:58 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
Message-ID: <4490A60A.9090305@sun.com>

Hello RxTx community,

I finally think I have a compromise in place that will stand in the gap.

If you go to http://www.sun.com and search for javax.comm, you'll
get taken to a download page, where now users can get a copy of the
comm.jar file out of 2.0.3, along with just a license and a README.

I trust this will suffice until such time as RxTx decided to implement
their own java classes or we can get a JSR going to mitigate some
of the problems (the readme in the comm.jar 2.0.3 zip file
contains my thoughts on that).

Thanks,
Paul



From tjarvi at qbang.org  Wed Jun 14 21:15:35 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 14 Jun 2006 21:15:35 -0600 (MDT)
Subject: [Rxtx] rxtx-2.0-7 (final) src is in CVS
Message-ID: <Pine.LNX.4.61.0606142100500.2742@www>


I wasn't expecting to be working on rxtx 2.0 tonight :)

Thanks go out to Paul Klissner for his work in making the coming release 
of rxtx-2.0-7 possible for users that require package javax.comm on many 
platforms.

Most people know that rxtx 2.0 is for use with Sun's CommAPI 2.0 for 
Solaris or the Generic CommAPI 2.0-3 available for download at Sun.  If 
you need javax.comm packages on many platforms, you are probably 
interested.  If you use rxtx 2.1 in package gnu.io, then you are not going 
to care much.

I've tried to update the rxtx 2.0 src directory in preparation for 
rxtx-2.0-7 (final).  Linux should compile.  Windows will compile if you 
generate your own .def files (I'll generate these tomorrow).  If you have 
some time to do basic testing of the source, I'd appreciate it.  The 
source should be good but you may find classes not found.  This source is 
a backport from rxtx 2.1.

I wanted to get things started so anyone interested on Mac OS X could get 
a head start.

All of this is in CVS.  http://www.rxtx.org/cvs.html

I suspect we will have binaries for testing in a couple days if you are 
unable to compile.   Consider this a smoke test.

--
Trent Jarvi
tjarvi at qbang.org


From legolas.w at gmail.com  Wed Jun 14 22:04:28 2006
From: legolas.w at gmail.com (Legolas Woodland)
Date: Wed, 14 Jun 2006 21:04:28 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <4490A60A.9090305@sun.com>
References: <4490A60A.9090305@sun.com>
Message-ID: <87ee9b170606142104p745fcef0vea622fbc8f528bfc@mail.gmail.com>

is there anything new in this version of javax.comm ?
thanks


On 6/14/06, Paul Klissner <paul.klissner at sun.com> wrote:
>
> Hello RxTx community,
>
> I finally think I have a compromise in place that will stand in the gap.
>
> If you go to http://www.sun.com and search for javax.comm, you'll
> get taken to a download page, where now users can get a copy of the
> comm.jar file out of 2.0.3, along with just a license and a README.
>
> I trust this will suffice until such time as RxTx decided to implement
> their own java classes or we can get a JSR going to mitigate some
> of the problems (the readme in the comm.jar 2.0.3 zip file
> contains my thoughts on that).
>
> Thanks,
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060614/5ff4dfbc/attachment-0019.html

From joachim at buechse.de  Thu Jun 15 07:22:48 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 15 Jun 2006 15:22:48 +0200
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
Message-ID: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>

Good day!

Some of my users report problems using RXTX 2.1.7 on Windows98 to  
communicate with an FTDI FT245BM chip (using their latest VCP  
driver). Either no ports are being shown (ie returned form  
CommPortIdentifier.getPortIdentifiers()) or the transfers fail.

Did anyone run into similar Problems with Win98??

Best regards,
Joachim



From ajmas at sympatico.ca  Thu Jun 15 08:12:28 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Thu, 15 Jun 2006 10:12:28 -0400
Subject: [Rxtx] API change question
Message-ID: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

How closely do you follow the Java Communication API spec? The reason I ask is because I would be interested in augmenting the CommPortIdentifier class to include a getDisplayName() method. By default it would return the same value as getName(), but would provide the possibility of displaying a 'user friendly' name, for platforms where the display name is not the same as the device name. An example of this is on MacOS X, where currently the names seem to be of the form /dev/cu.* and /dev/tty.*, yet what the expects to see is simply the part after the full-stop. Although I could move this logic into the Java code, it would be nice to see it transparent to the Java code.

Andre




From ajmas at sympatico.ca  Thu Jun 15 08:16:22 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Thu, 15 Jun 2006 10:16:22 -0400
Subject: [Rxtx] Package to use
Message-ID: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

While the Java API spec refers to javax.comm, I see that only gnu.io is provide by the rxtx project. Should our projects refer to the gnu.io package or the javax.comm API?

Andre



From joachim at buechse.de  Thu Jun 15 08:45:05 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 15 Jun 2006 16:45:05 +0200
Subject: [Rxtx] API change question
In-Reply-To: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>

Hello Andre,

the /dev/cu and /dev/tty have different semantics on OS X. It is much  
more than a simply naming issue to unify them, see my recent mail to  
the list...

Best regards,
Joachim


On 15.06.2006, at 16:12, Andre-John Mas wrote:

> Hi,
>
> How closely do you follow the Java Communication API spec? The  
> reason I ask is because I would be interested in augmenting the  
> CommPortIdentifier class to include a getDisplayName() method. By  
> default it would return the same value as getName(), but would  
> provide the possibility of displaying a 'user friendly' name, for  
> platforms where the display name is not the same as the device  
> name. An example of this is on MacOS X, where currently the names  
> seem to be of the form /dev/cu.* and /dev/tty.*, yet what the  
> expects to see is simply the part after the full-stop. Although I  
> could move this logic into the Java code, it would be nice to see  
> it transparent to the Java code.
>
> Andre
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From lyon at docjava.com  Thu Jun 15 10:16:29 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Thu, 15 Jun 2006 12:16:29 -0400
Subject: [Rxtx] cu.modem != /dev/ttya on mac.
In-Reply-To: <763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
	<763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>
Message-ID: <p0602046cc0b7378a95b0@[192.168.1.152]>

>Hi All,

I think that Joachim is correct. For the longest time,
I have been trying to figure out how to direct dial using
the cu.modem on the mac under os x.

As a less-than-optimal approach to auto-dialing, I have used
a keyspan USB 19HS adapter, along with an external modem, to
obtain the dialing feature.

Ideally, it would be better to dial with the built-in modem...but that did not
always seem to work, for some reason. Have others had some experience with
using the built in modem for dialing on the mac?

Thanks!
  - Doug


>Hello Andre,
>
>the /dev/cu and /dev/tty have different semantics on OS X. It is much?
>more than a simply naming issue to unify them, see my recent mail to?
>the list...
>
>Best regards,
>Joachim
>



From doug at dupreeinc.com  Thu Jun 15 14:52:50 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 15 Jun 2006 13:52:50 -0700
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
In-Reply-To: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
References: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
Message-ID: <4491C8A2.8090108@dupreeinc.com>

Hi Joachim,

I have been doing a lot with the new FTDI driver with win XP and have 
not had that particular problem.  I did notice that the new driver 
(dated May19th, 2006) is only for XP, Server 2003, and 2000.  Are they 
trying to use the 2.00.00 drivers or the old 1.09.06 version.  I am 
using a FT232R based module, but it uses the same drivers and I assume 
it would have the same problems.  Let me know which driver they are 
using and I can load up a 98 system here and see if  I can duplicate the 
problem.

Doug

Joachim Buechse wrote:

>Good day!
>
>Some of my users report problems using RXTX 2.1.7 on Windows98 to  
>communicate with an FTDI FT245BM chip (using their latest VCP  
>driver). Either no ports are being shown (ie returned form  
>CommPortIdentifier.getPortIdentifiers()) or the transfers fail.
>
>Did anyone run into similar Problems with Win98??
>
>Best regards,
>Joachim
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From matthewhepp at yahoo.com  Thu Jun 15 17:34:47 2006
From: matthewhepp at yahoo.com (Matthew Hepp)
Date: Thu, 15 Jun 2006 16:34:47 -0700 (PDT)
Subject: [Rxtx] Wither the XCode project?
Message-ID: <20060615233447.48064.qmail@web50311.mail.yahoo.com>

Either I don't know how to properly use CVS (entirely possibl), or the XCode
project is not making through the update properly. Doing a "cvs update" against
2.1-7 creates an XCode folder in MACOSX_IDE, and therein a
LibSerialUniversal.xcodeproj, but trying to open it yields a "Unable to Open
Project - Project rxtx-devel/MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj
cannot be opened because it is missing its project.pbxproj file" error. Showing
package contents reveals just the cvs-related files. Perhaps this is why
previous xcode projects have been saved as an sit.hqx - to retain the resource
fork?

Can someone point me in the right direction?

Thanks,

Matt

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Thu Jun 15 19:53:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 19:53:06 -0600 (MDT)
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
In-Reply-To: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
References: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
Message-ID: <Pine.LNX.4.61.0606151944070.23137@www>

On Thu, 15 Jun 2006, Joachim Buechse wrote:

> Good day!
>
> Some of my users report problems using RXTX 2.1.7 on Windows98 to
> communicate with an FTDI FT245BM chip (using their latest VCP
> driver). Either no ports are being shown (ie returned form
> CommPortIdentifier.getPortIdentifiers()) or the transfers fail.
>
> Did anyone run into similar Problems with Win98??
>

Hi Joachim

It has been a long time since I've tested win98.  I know rxtx-2.1-7pre16 
did get testing on win98 with ~jdk 1.3 though.  I wonder if jdks are still 
tested on that platform.

With win98 you usually have older boxes.  They can be short on CPU and 
memory.  Enumeration should work but I could picture runtime performance 
issues on win98.

The enumeration problems could result from other copies of your 
application if various states of decay still holding onto the port.  When 
things go wrong, people also like to open other terminal software to see 
whats going on which can interfere.  You can't open a windows port with 
two apps.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Thu Jun 15 20:08:53 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 20:08:53 -0600 (MDT)
Subject: [Rxtx] API change question
In-Reply-To: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606151954270.23137@www>

On Thu, 15 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> How closely do you follow the Java Communication API spec?

I can explain how this worked in the past.  How we do it in the future is 
open for discussion.

In the past we have tried to follow it as close as possible in gnu.io 
(rxtx 2.1).  We have added extensions but try to discourage their use. 
The extensions are clearly marked as such in the source code and javadocs.

rxtx 2.0 was intended to be a strict implementation of part of the spec. 
We let Sun's interfaces decide what methods can be called. There are 
differences not covered by the spec such as default values.  Thats not 
intentional but rather hard to avoid.

--
Trent Jarvi
tjarvi at qbang.org





From tjarvi at qbang.org  Thu Jun 15 21:09:11 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 21:09:11 -0600 (MDT)
Subject: [Rxtx] Package to use
In-Reply-To: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606152026120.23137@www>

On Thu, 15 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> While the Java API spec refers to javax.comm, I see that only gnu.io is 
> provide by the rxtx project. Should our projects refer to the gnu.io 
> package or the javax.comm API?
>

Hi Andre

Lets see if I can give a fair and balanced answer to that.

If you are starting a new project and want to use RXTX, I would recommend 
using gnu.io.  The community support for gnu.io will not be going away 
anytime soon.  You can switch between gnu.io (2.1) and javax.comm (2.0) 
fairly easily.  They are not intended to be incompatible.  You just change 
package names and libs.

You can also consider the combination of rxtx 2.0 with Sun's commapi 
2.0-3.  This is considered a stop-gap measure by Sun for previous users of 
that combination.  Together rxtx 2.0 and Sun CommAPI 2.0 work in namespace 
javax.comm for programmers.

Finally, you can opt to just use Sun's oferrings in CommAPI 3.0 without 
rxtx.  That would be in namespace javax.comm also.  CommAPI 3.0 may be 
of more interest to you if you are looking at POS with Sun computers. 
Rxtx does not currently support the changes in CommAPI 3.0 or have firm 
plans to do so.  That does not mean we wouldn't implement them.  It just 
means nobody has contributed code yet.

You can't combine rxtx with CommAPI 3.0 for technical reasons that wont 
likely be fixed soon.

It's up to you as far as what you use.  We like to provide the freedom so 
you can choose.  Realistically, we will be supporting gnu.io mainly 
because we have some control over that name space and can support it.

Things may happen in the future that enable rxtx to provide more support 
in the javax namespace but that has not happened yet.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun 16 00:33:06 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 08:33:06 +0200
Subject: [Rxtx] Wither the XCode project?
In-Reply-To: <20060615233447.48064.qmail@web50311.mail.yahoo.com>
References: <20060615233447.48064.qmail@web50311.mail.yahoo.com>
Message-ID: <D30D660F-A49B-464E-AE4C-6B4563893682@buechse.de>

Hello Matthew,

could you please send me the contents of your

   rxtx-devel/CVS
   rxtx-devel/MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj/CVS

directories as a zip to my personal email address. This should  
indicate why the file is not checked out. I can see that it exists on  
the correct branch in the repository, so something must have gone  
wrong during the "cvs update"...

Best regards,
Joachim

On 16.06.2006, at 01:34, Matthew Hepp wrote:

> Either I don't know how to properly use CVS (entirely possibl), or  
> the XCode
> project is not making through the update properly. Doing a "cvs  
> update" against
> 2.1-7 creates an XCode folder in MACOSX_IDE, and therein a
> LibSerialUniversal.xcodeproj, but trying to open it yields a  
> "Unable to Open
> Project - Project rxtx-devel/MACOSX_IDE/XCode/ 
> LibSerialUniversal.xcodeproj
> cannot be opened because it is missing its project.pbxproj file"  
> error. Showing
> package contents reveals just the cvs-related files. Perhaps this  
> is why
> previous xcode projects have been saved as an sit.hqx - to retain  
> the resource
> fork?
>
> Can someone point me in the right direction?



From joachim at buechse.de  Fri Jun 16 10:41:20 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 18:41:20 +0200
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <p06230903c0b88613dca6@[10.0.1.7]>
References: <p06230903c0b88613dca6@[10.0.1.7]>
Message-ID: <03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>

Hello Bob,

until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was  
behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if  
Trent has migrated all recent changes from 2.1 to 2.0.

I have added the XCode project and updated documentation only to the  
gnu.io branch. Once the 2.0 implementation is up to date I will copy  
over the documentation/build files make them work.

Best regards,
Joachim

On 16.06.2006, at 18:07, Bob Jacobsen wrote:

> I'm one of the developers for the JMRI project, which provides  
> model railroad software in Java.  We've been using RXTX to provide  
> serial port access on MacOS X and Linux; we use the old javax.comm  
> 2.0 on Windows, OS/2 and Solaris.  Because of that, we need to stay  
> with RXTX 2.0, not 2.1
>
> We've been using the 2.0-pre17 installer for a long time, but it's  
> not compatible with Intel macs.
>
> Can you point me to where I can find the right files for RXTX 2.0  
> to package with the program?
>
> The current situation is confusing to me.  I've been pointed to  
> recent 2.1 versions (but we need the javax.comm names), to an even  
> older installer, etc.  I've been reading that some versions require  
> an installer, and others don't, but I haven't been able to figure  
> out which (if any) of those are where in CVS.
>
> I'd really appreciate a clear statement of what files to use and  
> what to do with them that I can pass on to our users.
>
> I'm more than happy to put files in the local classpath, have users  
> run an installer, or anything else.  Whatever is easiest for you.
>
> Thanks!  I really appreciate all that you do to keep RXTX working.
>
> Bob
> -- 
> Bob Jacobsen +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG



From joachim at buechse.de  Fri Jun 16 09:59:28 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 17:59:28 +0200
Subject: [Rxtx] Wither the XCode project?
In-Reply-To: <20060616150240.49464.qmail@web50309.mail.yahoo.com>
References: <20060616150240.49464.qmail@web50309.mail.yahoo.com>
Message-ID: <D9935E05-2B83-488D-86DD-42599E229052@buechse.de>

Hello Matthew,

you have checked out the trunk (which is the 2.0.7 javax.comm.xxx  
release). For rxtx-2.1.7 (gnu.io.xxx release) you need to check out  
the branch

      commapi-0-0-1

The easiest way to do this is to download the rxtx src archive,  
unpack it and then do a cvs up inside the decompressed tree.  
Optionally you could do a

      cvs co -r commapi-0-0-1

but this will take much longer!

Best regards,
Joachim

When you do a cvs status it will show the sticky tag.

41:~/jdevelop/rxtx-2.1-7r2 joachim$ cvs status README.OSX
===================================================================
File: README.OSX        Status: Up-to-date

    Working revision:    1.1.2.1
    Repository revision: 1.1.2.1 /usr/local/cvsroot/rxtx-devel/Attic/ 
README.OSX,v
    Sticky Tag:          commapi-0-0-1 (branch: 1.1.2)
    Sticky Date:         (none)
    Sticky Options:      (none)




On 16.06.2006, at 17:02, Matthew Hepp wrote:

> %cvs status README.MACOSX
> ===================================================================
> File: README.MACOSX     Status: Up-to-date
>
>    Working revision:    1.1
>    Repository revision: 1.1     /usr/local/cvsroot/rxtx-devel/ 
> README.MACOSX,v
>    Sticky Tag:          (none)
>    Sticky Date:         (none)
>    Sticky Options:      (none)



From tjarvi at qbang.org  Fri Jun 16 16:31:18 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Fri, 16 Jun 2006 16:31:18 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
Message-ID: <Pine.LNX.4.61.0606161630030.14139@www>

On Fri, 16 Jun 2006, Joachim Buechse wrote:

> Hello Bob,
>
> until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was
> behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if
> Trent has migrated all recent changes from 2.1 to 2.0.
>

The src/ directory and configure.in/configure files should be fine.  I 
have not touched the Mac OS X directories.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sat Jun 17 02:39:55 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sat, 17 Jun 2006 10:39:55 +0200
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <Pine.LNX.4.61.0606161630030.14139@www>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
Message-ID: <350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>

Hello Trent,

apparently the IOEXCL changes have not made it into 2.0. I will add  
them to achieve a minimal diff between 2.0 and 2.1.

One other thing that bugs me for a while...

Shouldn't we replace "if !defined(TIOCSERGETLSR) && !defined(WIN32)"  
by a definition of its own "if defined(DRAINTHREAD)"? I think this  
would make the code clearer for people starting to read it.

Regards,
Joachim


On 17.06.2006, at 00:31, Trent Jarvi wrote:

> On Fri, 16 Jun 2006, Joachim Buechse wrote:
>
>> Hello Bob,
>>
>> until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was
>> behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if
>> Trent has migrated all recent changes from 2.1 to 2.0.
>>
>
> The src/ directory and configure.in/configure files should be fine.  I
> have not touched the Mac OS X directories.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From tropicsu at hotmail.com  Sat Jun 17 09:32:48 2006
From: tropicsu at hotmail.com (Yoke K)
Date: Sat, 17 Jun 2006 15:32:48 +0000
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
Message-ID: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>

Hi,

I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to work with 
MAC OS X.
I am using iTegno 3000 - USB GPRS Modem.

Files in /dev and a symbolic link as follows:

crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 -> tty.usbserial

In my SendMessage.java, I have this line:
CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");

Appreciate any help ?

- Jon


Errors as follows:

>>INFO: SMSLib API for Java / v1.2.2
>>INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>INFO: JRE Version: 1.5.0_06
>>INFO: JRE Impl Version: 1.5.0_06-64
>>INFO: O/S: Mac OS X / ppc / 10.4.6
>>INFO: Using Wavecom (Generic) AT handler.

SendMessage(): Send a message.
  Using SMSLib API for Java v1.2.2

Connecting ..... :
>>INFO: CSerialDriver(): Connecting...
Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
>>INFO: CSerialDriver(): Disconnecting...
gnu.io.NoSuchPortException
        at 
gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:218)
        at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
        at org.smslib.CService.connect(CService.java:197)
        at SendMessage.main(SendMessage.java:38)

_________________________________________________________________
Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/



From tjarvi at qbang.org  Sat Jun 17 10:12:30 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 10:12:30 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
	<350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
Message-ID: <Pine.LNX.4.61.0606171010060.14139@www>

On Sat, 17 Jun 2006, Joachim Buechse wrote:

> Hello Trent,
>
> apparently the IOEXCL changes have not made it into 2.0. I will add
> them to achieve a minimal diff between 2.0 and 2.1.
>

Hi Joachim

As I recall the IOEXCL change was after 2.1-7.  I was just syncing with 
2.1-7.  We can release 2.1-8 and 2.0-8 with the same changes.

> One other thing that bugs me for a while...
>
> Shouldn't we replace "if !defined(TIOCSERGETLSR) && !defined(WIN32)"
> by a definition of its own "if defined(DRAINTHREAD)"? I think this
> would make the code clearer for people starting to read it.
>


Sure.  We can do that for -8.  The TIOCSERGETLSR code should be a special 
case not the expected.  I think only Linux uses it.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Sat Jun 17 10:48:21 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 10:48:21 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <Pine.LNX.4.61.0606171010060.14139@www>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
	<350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
	<Pine.LNX.4.61.0606171010060.14139@www>
Message-ID: <Pine.LNX.4.61.0606171047310.14139@www>

On Sat, 17 Jun 2006, Trent Jarvi wrote:

> On Sat, 17 Jun 2006, Joachim Buechse wrote:
>
>> Hello Trent,
>>
>> apparently the IOEXCL changes have not made it into 2.0. I will add
>> them to achieve a minimal diff between 2.0 and 2.1.
>>
>
> Hi Joachim
>
> As I recall the IOEXCL change was after 2.1-7.  I was just syncing with
> 2.1-7.  We can release 2.1-8 and 2.0-8 with the same changes.
>

We could just move to 2.1-8 and 2.0-8.

--
Trent Jarvi
tjarvi at qbang.org


From brian.t.lamb at gmail.com  Tue Jun 13 13:54:13 2006
From: brian.t.lamb at gmail.com (Brian Lamb)
Date: Tue, 13 Jun 2006 15:54:13 -0400
Subject: [Rxtx] Windows XP Installation
Message-ID: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>

I've not installed Java packages on Windows before and am unsure how to
proceed. All the documentation I've seen provides detailed instructions on
how to install on Linux or Solaris. I was wondering how to install rxtx on
Windows XP.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060613/6f68cd5c/attachment-0019.html

From tjarvi at qbang.org  Sat Jun 17 13:57:03 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 13:57:03 -0600 (MDT)
Subject: [Rxtx] Windows XP Installation
In-Reply-To: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>
References: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0606171356120.14139@www>

On Tue, 13 Jun 2006, Brian Lamb wrote:

> I've not installed Java packages on Windows before and am unsure how to
> proceed. All the documentation I've seen provides detailed instructions on
> how to install on Linux or Solaris. I was wondering how to install rxtx on
> Windows XP.
>

Hi Brian

Which rxtx version are you trying to install?

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sun Jun 18 10:41:44 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sun, 18 Jun 2006 18:41:44 +0200
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
References: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
Message-ID: <8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>

Hello Jon,

 From OSX's standpoint a symbolic link is not a device (as far as I  
know). What stops you from using tty.usbserial? Did you try hard- 
linking?

Regards,
Joachim

On 17.06.2006, at 17:32, Yoke K wrote:
> Hi,
>
> I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to  
> work with
> MAC OS X.
> I am using iTegno 3000 - USB GPRS Modem.
>
> Files in /dev and a symbolic link as follows:
>
> crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
> crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
> lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->  
> tty.usbserial
>
> In my SendMessage.java, I have this line:
> CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
>
> Appreciate any help ?
>
> - Jon
>
>
> Errors as follows:
>
>>> INFO: SMSLib API for Java / v1.2.2
>>> INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>> INFO: JRE Version: 1.5.0_06
>>> INFO: JRE Impl Version: 1.5.0_06-64
>>> INFO: O/S: Mac OS X / ppc / 10.4.6
>>> INFO: Using Wavecom (Generic) AT handler.
>
> SendMessage(): Send a message.
>   Using SMSLib API for Java v1.2.2
>
> Connecting ..... :
>>> INFO: CSerialDriver(): Connecting...
> Experimental:  JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
>>> INFO: CSerialDriver(): Disconnecting...
> gnu.io.NoSuchPortException
>         at
> gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java: 
> 218)
>         at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
>         at org.smslib.CService.connect(CService.java:197)
>         at SendMessage.main(SendMessage.java:38)
>
> _________________________________________________________________
> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Sun Jun 18 10:56:55 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 12:56:55 -0400
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>
References: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
	<8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>
Message-ID: <7B6834E3-F41D-46B6-B979-55466BC73859@sympatico.ca>

Have you been able to get any other software to talk with your
modem? What port is it using? Have tried using the cu.usbserial
instead?

Andre

On 18-Jun-06, at 12:41 , Joachim Buechse wrote:

> Hello Jon,
>
>  From OSX's standpoint a symbolic link is not a device (as far as I
> know). What stops you from using tty.usbserial? Did you try hard-
> linking?
>
> Regards,
> Joachim
>
> On 17.06.2006, at 17:32, Yoke K wrote:
>> Hi,
>>
>> I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to
>> work with
>> MAC OS X.
>> I am using iTegno 3000 - USB GPRS Modem.
>>
>> Files in /dev and a symbolic link as follows:
>>
>> crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
>> crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
>> lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->
>> tty.usbserial
>>
>> In my SendMessage.java, I have this line:
>> CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
>>
>> Appreciate any help ?
>>
>> - Jon
>>
>>
>> Errors as follows:
>>
>>>> INFO: SMSLib API for Java / v1.2.2
>>>> INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>>> INFO: JRE Version: 1.5.0_06
>>>> INFO: JRE Impl Version: 1.5.0_06-64
>>>> INFO: O/S: Mac OS X / ppc / 10.4.6
>>>> INFO: Using Wavecom (Generic) AT handler.
>>
>> SendMessage(): Send a message.
>>   Using SMSLib API for Java v1.2.2
>>
>> Connecting ..... :
>>>> INFO: CSerialDriver(): Connecting...
>> Experimental:  JNI_OnLoad called.
>> Stable Library
>> =========================================
>> Native lib Version = RXTX-2.1-7
>> Java lib Version   = RXTX-2.1-7
>>>> INFO: CSerialDriver(): Disconnecting...
>> gnu.io.NoSuchPortException
>>         at
>> gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:
>> 218)
>>         at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
>>         at org.smslib.CService.connect(CService.java:197)
>>         at SendMessage.main(SendMessage.java:38)
>>
>> _________________________________________________________________
>> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Sun Jun 18 17:33:08 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 19:33:08 -0400
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
Message-ID: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>

Hi,

I am have a program that I wrote in Java to communicate with a  
Bluetooth GPS device. I am
trying to get this working on my Mac, but I keep getting told that:

gnu.io.PortInUseException: Unknown Application

but

portIdentifier.isCurrentlyOwned()

returns false and when I do lsof on the device I am trying to connect  
to, I see no application
using it. As the same time if I go to the command line and use  
minicom I have no issues. The
exception happens with this call:

CommPort commPort = portIdentifier.open(null,0);

Any suggestions?

Andre


From ajmas at sympatico.ca  Sun Jun 18 17:45:11 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 19:45:11 -0400
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
Message-ID: <30245B30-682D-4EAE-8084-8227B719F10D@sympatico.ca>

BTW My code snippet is:

     private InputStream connectToSerial () throws IOException,  
Exception
     {
         InputStream in = null;

         Enumeration portEnum = CommPortIdentifier.getPortIdentifiers();
         while ( portEnum.hasMoreElements() )
         {
             CommPortIdentifier portIdentifier = (CommPortIdentifier)  
portEnum.nextElement();
             System.out.println(portIdentifier.getName() + " - " +  
portIdentifier.getPortType() );
         }

         CommPortIdentifier portIdentifier =  
CommPortIdentifier.getPortIdentifier("/dev/cu.BTGPS-SPPslave-1");
         System.out.println("current owner: " +  
portIdentifier.getCurrentOwner());
         if ( portIdentifier.isCurrentlyOwned() )
         {
             System.out.println("Error: Port is currently in use");
             return null;
         }
         else
         {
             CommPort commPort = portIdentifier.open(this.getClass 
().getName(),2000);

             if ( commPort instanceof SerialPort )
             {
                 SerialPort serialPort = (SerialPort) commPort;
                 serialPort.setSerialPortParams 
(4800,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE 
);
                 in = serialPort.getInputStream();

                 return in;
             }
             else
             {
                 System.out.println("Error: Only serial ports are  
handled.");
             }
         }


         return in;
     }


On 18-Jun-06, at 19:33 , Andr?-John Mas wrote:

> Hi,
>
> I am have a program that I wrote in Java to communicate with a
> Bluetooth GPS device. I am
> trying to get this working on my Mac, but I keep getting told that:
>
> gnu.io.PortInUseException: Unknown Application
>
> but
>
> portIdentifier.isCurrentlyOwned()
>
> returns false and when I do lsof on the device I am trying to connect
> to, I see no application
> using it. As the same time if I go to the command line and use
> minicom I have no issues. The
> exception happens with this call:
>
> CommPort commPort = portIdentifier.open(null,0);
>
> Any suggestions?
>
> Andre
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From joachim at buechse.de  Mon Jun 19 05:54:49 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 13:54:49 +0200
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de>

This is most likely due to a problem with lock files. If you have  
downloaded the binaries of 2.17 rxtx will try to create non-standard  
lock files on OSX. We have since changed the code to use OSX device  
locking - however the binaries have not been updated yet. The 2.18  
release fixing this issue is due shortly.

Regards,
Joachim

On 19.06.2006, at 01:33, Andr?-John Mas wrote:

> Hi,
>
> I am have a program that I wrote in Java to communicate with a
> Bluetooth GPS device. I am
> trying to get this working on my Mac, but I keep getting told that:
>
> gnu.io.PortInUseException: Unknown Application
>
> but
>
> portIdentifier.isCurrentlyOwned()
>
> returns false and when I do lsof on the device I am trying to connect
> to, I see no application
> using it. As the same time if I go to the command line and use
> minicom I have no issues. The
> exception happens with this call:
>
> CommPort commPort = portIdentifier.open(null,0);
>
> Any suggestions?
>
> Andre
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From joachim at buechse.de  Mon Jun 19 06:44:27 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 14:44:27 +0200
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <4490A60A.9090305@sun.com>
References: <4490A60A.9090305@sun.com>
Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>

Hello Paul,

I just downloaded the "generic" javax.comm version now available. A  
first check indicates, that it was compiled with a JDK 1.4 javac  
without setting the target classfile version. In other words in can  
not be loaded by 1.1-1.3 VMs (or PersonalJava).

Do you see any chance to provide a version compiled with classfile  
format 45.3 (ie JVM1.1).

---
52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose  
javax.comm.SerialPort | head -5
Compiled from "SerialPort.java"
public abstract class javax.comm.SerialPort extends javax.comm.CommPort
   SourceFile: "SerialPort.java"
   minor version: 0
   major version: 48
---

Best regards,
Joachim


On 15.06.2006, at 02:12, Paul Klissner wrote:

> Hello RxTx community,
>
> I finally think I have a compromise in place that will stand in the  
> gap.
>
> If you go to http://www.sun.com and search for javax.comm, you'll
> get taken to a download page, where now users can get a copy of the
> comm.jar file out of 2.0.3, along with just a license and a README.
>
> I trust this will suffice until such time as RxTx decided to implement
> their own java classes or we can get a JSR going to mitigate some
> of the problems (the readme in the comm.jar 2.0.3 zip file
> contains my thoughts on that).
>
> Thanks,
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Mon Jun 19 09:11:45 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Mon, 19 Jun 2006 11:11:45 -0400
Subject: [Rxtx] Examples added to Wiki
Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

I have added a couple of examples to the Wiki:

http://rxtx.qbang.org/wiki/index.php/Examples

If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :)

Andre



From paul.klissner at sun.com  Mon Jun 19 10:42:47 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Mon, 19 Jun 2006 09:42:47 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>
References: <4490A60A.9090305@sun.com>
	<03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>
Message-ID: <4496D407.1090609@sun.com>

Joachim Buechse wrote:
> Hello Paul,
> 
> I just downloaded the "generic" javax.comm version now available. A  
> first check indicates, that it was compiled with a JDK 1.4 javac  
> without setting the target classfile version. In other words in can  
> not be loaded by 1.1-1.3 VMs (or PersonalJava).
> 
> Do you see any chance to provide a version compiled with classfile  
> format 45.3 (ie JVM1.1).
> 
> ---
> 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose  
> javax.comm.SerialPort | head -5
> Compiled from "SerialPort.java"
> public abstract class javax.comm.SerialPort extends javax.comm.CommPort
>    SourceFile: "SerialPort.java"
>    minor version: 0
>    major version: 48
> ---

I cannot promise when I can do that. Since we thought we were done
with javax.comm, the build environment got moved around, and right
now it doesn't even compile in it's new home.  I tried and it was
not cooperative at all. I was never impressed with that workspace
(in fact far far from it, it is a mess, which is why I migrated 3.0
to ant and never looked back).  It will take some real determination
for me to rebuild it, and frankly, right now I'm swamped.  If I can
find a bit of time over the next few weeks to do it, and it isn't
too bad an ordeal, I will.

Posting that will give me an excuse to post javax.comm 3.0, Update 2 as
well, while I'm working with the people who put content up on our
download center.  The only reason for a new update to 3.0 is that
I've changed the distribution to provide ispt (Interactive Serial
Port Tool), such that it can be launched as soon as the zip file
is unpacked, via a provided script.  ISPT is a command line
interactive tool for  manipulating one or two serial port,
sending data, managing events, etc... I've found it to be so useful
for doing certain kinds of validation  that I assume others will
find it useful to.  ISPT is already in 3.0u1, but one has to set
up their own classpath and launch it and since few people ever read
the documentation most won't know about it.  I've added the ability
to set stop bits and parity since 3.0u1 too.  But I digress.

Paul


From joachim at buechse.de  Mon Jun 19 11:01:28 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 19:01:28 +0200
Subject: [Rxtx] load mechanism of 2.0x
Message-ID: <CFD1440C-21AA-4D3B-9EA6-270D0FF9D6FC@buechse.de>

Good day,

I am trying to figure out, how the 2.0x distribution interacts with  
Suns implementation of javax.comm.CommPortIdentifier.

1) Apparently one can put javax.comm.properties in {java.home}/lib
2) The javax.comm package also reacts to -Djavax.comm.properties="...."

Looking at the javap output it also seems like CommPortIdentifier  
tries to find it's jar file and load the properties from there??


What I'm really looking for is a solution that allows using  
javax.comm with RXTX without modifying the VM installation. So I  
would prefer not to use 1) but I can't figure out how to use 2).

Any hints are welcome,
Joachim



From bob_tai2001 at yahoo.com  Mon Jun 19 15:00:35 2006
From: bob_tai2001 at yahoo.com (Bob Tai)
Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT)
Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place
	to start?
Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>

Hi, 

I got  rxtx Windows 2000 installed.  I did not use the
"best" way ... I just follow the insturuction and dump
the necessary files into the jre... I know it's "best"
idea, I got lazy didn't want to change my setting to
my Eclipse and classpath.

I was able to modify SimpleWrite.java to print on my
AddMaster serial printer.  I think I am ready to code!
But I need to make sure I can handle exceptions and so
on.  I notice the \samples\NullDriver\  has two files
seems to have some of the require method done, should
I start coding from those file?  I like the idea it
has the "time out" and basic exceptions done.   I am
slowly digging into the samples, but if you think any
of the code from Sun is good to checkout please let me
know.

btw, http://rxtx.qbang.org/wiki/index.php/Examples/
was very helpful, wish there are more examples.

thank you,

    Bob


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Mon Jun 19 15:55:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT)
Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good
 place to start?
In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>
References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606191542260.14139@www>

> I am
> slowly digging into the samples, but if you think any
> of the code from Sun is good to checkout please let me
> know.
>

I think NullDriver.java was an example stub driver for implementing 
something like rxtx.  It has been a while.  Unless they have been updated, 
you will find the examples are very dated.  You can look at how they use 
the port but avoid the GUI and hard coded variables (number of ports for 
instance).

There was no Swing and nobody knew what requirements today's compilers 
would make on code.  The examples worked fine with jdk 1.1 but times have 
changed.

--
Trent Jarvi
tjarvi at qbang.org


From tropicsu at hotmail.com  Mon Jun 19 19:49:08 2006
From: tropicsu at hotmail.com (Yoke K)
Date: Tue, 20 Jun 2006 01:49:08 +0000
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
Message-ID: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>

An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/fa588f00/attachment-0010.html

From ajmas at sympatico.ca  Mon Jun 19 21:14:37 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Mon, 19 Jun 2006 23:14:37 -0400
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>
References: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>
Message-ID: <CA22AB2A-5712-458B-9984-68477C6042AF@sympatico.ca>

Regarding the PortInUseException, I had a similar issue and got
this response from the mailing list:

   http://mailman.qbang.org/pipermail/rxtx/Week-of- 
Mon-20060619/062838.html

Andre
On 19-Jun-06, at 21:49 , Yoke K wrote:

> Hi Andre, Joachim
>
> I have tried using /dev/tty.usbserial and also /dev/cu.usbserial  
> and it also reported error as  "gnu.io.PortInUseException".
>
> The iTegno modem works in windows environment. As I moving around  
> using my ibook and I need to get it work on MAC OS as well.
>
> >> INFO: SMSLib API for Java / v1.2.2
> >> INFO: Using port: /dev/tty.usbserial @ 115200 baud.
> >> INFO: JRE Version: 1.5.0_06
> >> INFO: JRE Impl Version: 1.5.0_06-64
> >> INFO: O/S: Mac OS X / ppc / 10.4.6
> >> INFO: Using Wavecom (Generic) AT handler.
>
> SendMessage(): Send a message.
> Using SMSLib API for Java v1.2.2
>
> Connecting ..... :
> >> INFO: CSerialDriver(): Connecting...
> Experimental: JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version = RXTX-2.1-7
> >> INFO: CSerialDriver(): Disconnecting...
> gnu.io.PortInUseException: Unknown Application
> at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354)
> at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1)
> at org.smslib.CService.connect(CService.java:197)
> at SendMessage.main(SendMessage.java:38)
>
> Thanks.
>
> - Jon
>
>
>
>
> ====================
>
> Hello Jon,
>
> From OSX's standpoint a symbolic link is not a device (as far as I
> know). What stops you from using tty.usbserial? Did you try hard-
> linking?
>
> Regards,
> Joachim
>
>
>
> From:  "Yoke K" <tropicsu at hotmail.com>
> To:  rxtx at qbang.org
> Subject:  RXTX-2.1-7 / MAC OS X / NoSuchPortException
> Date:  Sat, 17 Jun 2006 15:32:48 +0000
> >Hi,
> >
> >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to
> >work with MAC OS X.
> >I am using iTegno 3000 - USB GPRS Modem.
> >
> >Files in /dev and a symbolic link as follows:
> >
> >crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
> >crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
> >lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->
> >tty.usbserial
> >
> >In my SendMessage.java, I have this line:
> >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
> >
> >Appreciate any help ?
> >
> >- Jon
> >
> >
> >Errors as follows:
> >
> >>>INFO: SMSLib API for Java / v1.2.2
> >>>INFO: Using port: /dev/ttyS1 @ 56000 baud.
> >>>INFO: JRE Version: 1.5.0_06
> >>>INFO: JRE Impl Version: 1.5.0_06-64
> >>>INFO: O/S: Mac OS X / ppc / 10.4.6
> >>>INFO: Using Wavecom (Generic) AT handler.
> >
> >SendMessage(): Send a message.
> >  Using SMSLib API for Java v1.2.2
> >
> >Connecting ..... :
> >>>INFO: CSerialDriver(): Connecting...
> >Experimental:  JNI_OnLoad called.
> >Stable Library
> >=========================================
> >Native lib Version = RXTX-2.1-7
> >Java lib Version   = RXTX-2.1-7
> >>>INFO: CSerialDriver(): Disconnecting...
> >gnu.io.NoSuchPortException
> >        at
> >gnu.io.CommPortIdentifier.getPortIdentifier 
> (CommPortIdentifier.java:218)
> >        at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
> >        at org.smslib.CService.connect(CService.java:197)
> >        at SendMessage.main(SendMessage.java:38)
> >
> >_________________________________________________________________
> >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
> >
>
> Find love online with MSN Personals
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Tue Jun 20 02:35:24 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 10:35:24 +0200
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>

Hello everybody,

I have been fighting a bit with the javax.comm version of RXTX the  
last days. I am working on the README .OSX now and try to figure out  
which should be the "suggested" installation.

The facts:
------

- the "generic" comm.jar version of javax.comm which has been made re- 
available tries to load com.sun.comm.SolarisDriver
- this classname can be overridden ONLY by putting a file  
javax.comm.properties in {java.home}/lib
- if it is not overridden and SolarisDriver.class is not found  
CommPortIdentifier will be disfunctional (in particual it is not  
possible to add CommPort's via CommPortIdentifier.add).
- the license distributed with comm.jar does not allow the  
modification/addition of classes in javax.comm (however no mention of  
com.sun...)


What really bothers me is to suggest putting this config file in the  
"global" vm installation. This is particularly ugly on the Mac as  
there are several VM installations and the file may be forgotten.  
Additionally it may create versioning problems. I prefer an  
installation where all files are local to the application (even  
comm.jar).

In my opinion the ideal situation would be:
------

1) The author of a program compiles against javax.comm.
2a) For platforms supported by Sun the user is free to use the 3.0  
comm.jar download from Sun
2b) For platforms not supported by Sun the user adds RXTXComm.jar to  
the classpath of the application (and librxtxSerial.jnilib to the  
application directory). Also he will need the 2.0.3 generic comm.jar  
from Sun.
3) Nobody messes with the global VM installation.

Of course 2a) and 2b) could be handled by the author of the program  
via an appropriate installer. The author could also decide to always  
use RXTX and include the generic javax.comm classes as well as the  
RXTX classes in his application jar. [If he further uses an explicit  
call to System.load() he may even include the jnilib(s) in the jar,  
extract it (based on the platform name) at runtime to a temp file and  
load it from there.]


Suggested solution:
------

We only need to put the following class in the classpath BEFORE Suns  
comm.jar

   package com.sun.comm;
   public class SolarisDriver extends gnu.io.RXTXCommDriver {
   }

This is not "the pure art" (TM). It depends on an implementation  
detail of the generic driver. However, so does the  
javax.comm.properties file - as we have seen when Sun released 3.0.  
It has the following advantages:

- The "generic" javax.comm implementation will happily load this  
class as its primary driver.
- No javax.comm.properties file is required.
- This does not violate the javax.comm license agreement as there is  
no mention of the "com.sun.comm" package in this license agreement at  
all.
- Authors packaging comm.jar with their application can strip out all  
com.sun.comm classes from comm.jar


Please comment!

Joachim



From joachim at buechse.de  Tue Jun 20 02:50:36 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 10:50:36 +0200
Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar
Message-ID: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>

There has been some discussions about the best way to install RXTX  
and where to place files.

I suggest that,

- we include the native libraries for the most common operating  
systems (in a special version of) RXTXcomm.jar
- we add loader code which tries to extract and load the platform  
specific binary at runtime
- on failure the current mechanism remains as a fallback

Wether the current mechanism should have priority (ie loadLibrary  
before load) remains to be discussed.


The advantages of this solution are
  - users of RXTX do not need to worry about java/platform specific  
file placement.
  - authors of applications may fully merge RXTX into their  
application jar (which provides a double-clickable application for  
Windows and OSX, Linux?).

Please comment,
Joachim

PS: Of course the suggested solution is already possible today,  
however relatively few programmers know how to correctly extract a  
binary resource file via the class loader and load it as a native  
library.


From tjarvi at qbang.org  Tue Jun 20 03:58:12 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT)
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
Message-ID: <Pine.LNX.4.61.0606200335190.14139@www>

> 2a) For platforms supported by Sun the user is free to use the 3.0
> comm.jar download from Sun
> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to
> the classpath of the application (and librxtxSerial.jnilib to the
> application directory). Also he will need the 2.0.3 generic comm.jar
> from Sun.

As there are no plans to support CommAPI 3.0 due to the limitations in its 
implementation mentioned before, I would not recommend projects use Sun's 
3.0 comm.jar.  They will lose the freedom to chose their low level 
implementation by being locked into vendor specific modifications.

Projects should chose between platform neutrality in CommAPI 2.0 and 
reduced platform neutrality in commapi 3.0.  Projects should also strongly 
consider the fact that the 2.0 comm.jar targets only a reduced number of 
JVMs.

Projects can go with rxtx 2.1 or other packages but should probably only 
consider using Sun CommAPI with rxtx if they did so in the past.  They 
should take steps to no longer depend upon this option being available.

> Suggested solution:
> ------
>
> We only need to put the following class in the classpath BEFORE Suns
> comm.jar
>
>   package com.sun.comm;
>   public class SolarisDriver extends gnu.io.RXTXCommDriver {
>   }
>
> This is not "the pure art" (TM). It depends on an implementation
> detail of the generic driver. However, so does the
> javax.comm.properties file - as we have seen when Sun released 3.0.
> It has the following advantages:
>
> - The "generic" javax.comm implementation will happily load this
> class as its primary driver.
> - No javax.comm.properties file is required.
> - This does not violate the javax.comm license agreement as there is
> no mention of the "com.sun.comm" package in this license agreement at
> all.
> - Authors packaging comm.jar with their application can strip out all
> com.sun.comm classes from comm.jar
>

I would not encourage people to place packages in the com.sun.comm 
namespace.  Authors using Sun's commapi 2.0 should just realize it is 
greatly limited in practical utility and consider moving to something that 
isn't being rescued from EOL.

The primary focus of this release is projects previously depending upon 
Sun CommAPI + RXTX.  There are no plans at this time to provide future 
support in this arrangement due to technical incompatabilities we have no 
control over in commapi 3.0 and limited utility of Sun's generic comm.jar 
in commapi 2.0 offered.  Projects should be aware of this so they can make 
appropriate plans.

--
Trent Jarvi
tjarvi at qbang.org


From paul.klissner at sun.com  Tue Jun 20 05:24:00 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Tue, 20 Jun 2006 04:24:00 -0700
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
In-Reply-To: <Pine.LNX.4.61.0606200335190.14139@www>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
	<Pine.LNX.4.61.0606200335190.14139@www>
Message-ID: <4497DAD0.10803@sun.com>

Trent Jarvi wrote:
>> 2a) For platforms supported by Sun the user is free to use the 3.0
>> comm.jar download from Sun
>> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to
>> the classpath of the application (and librxtxSerial.jnilib to the
>> application directory). Also he will need the 2.0.3 generic comm.jar
>> from Sun.
> 
> As there are no plans to support CommAPI 3.0 due to the limitations in its 
> implementation mentioned before, I would not recommend projects use Sun's 
> 3.0 comm.jar.  They will lose the freedom to chose their low level 
> implementation by being locked into vendor specific modifications.
> 
> Projects should chose between platform neutrality in CommAPI 2.0 and 
> reduced platform neutrality in commapi 3.0.  Projects should also strongly 
> consider the fact that the 2.0 comm.jar targets only a reduced number of 
> JVMs.

Well, that's a little ambiguous because the API is the same
either way.  We're talking about Sun's implementation vs.
other implementations.
> 
> Projects can go with rxtx 2.1 or other packages but should probably only 
> consider using Sun CommAPI with rxtx if they did so in the past.  They 
> should take steps to no longer depend upon this option being available.

3.0 is platform centric because there is a need to add some
platform awareness to Sun's implementation, and the choices
for how to do that are limited by the constraints of the API,
as mentioned in the javax.comm 2.0.3 comm.jar download's README.

I am really advocating getting a JSR open (http://www.jcp.org)
to push a new comm API that is more pluggable, platform neutral
and addresses some of the deficiencies of the current API. Then
we can achieve the optimal of platform neutrality while
simulataneously allowing the API to flexibly adapt to
heterogeneous environments.

This is not a question of attitude, this is an issue of resources,
time and commitment.  The current owners of javax.comm within
Sun would like nothing better than to see the ideal reached for
the API and a model that will extend well beyond the foreseeable
future and work for the industry overall.



> 
>> Suggested solution:
>> ------
>>
>> We only need to put the following class in the classpath BEFORE Suns
>> comm.jar
>>
>>   package com.sun.comm;
>>   public class SolarisDriver extends gnu.io.RXTXCommDriver {
>>   }
>>
>> This is not "the pure art" (TM). It depends on an implementation
>> detail of the generic driver. However, so does the
>> javax.comm.properties file - as we have seen when Sun released 3.0.
>> It has the following advantages:
>>
>> - The "generic" javax.comm implementation will happily load this
>> class as its primary driver.
>> - No javax.comm.properties file is required.
>> - This does not violate the javax.comm license agreement as there is
>> no mention of the "com.sun.comm" package in this license agreement at
>> all.
>> - Authors packaging comm.jar with their application can strip out all
>> com.sun.comm classes from comm.jar
>>
> 
> I would not encourage people to place packages in the com.sun.comm 
> namespace.  Authors using Sun's commapi 2.0 should just realize it is 
> greatly limited in practical utility and consider moving to something that 
> isn't being rescued from EOL.
> 
> The primary focus of this release is projects previously depending upon 
> Sun CommAPI + RXTX.  There are no plans at this time to provide future 
> support in this arrangement due to technical incompatabilities we have no 
> control over in commapi 3.0 and limited utility of Sun's generic comm.jar 
> in commapi 2.0 offered.  Projects should be aware of this so they can make 
> appropriate plans.

Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86,
or need the powerful portmapping features in javax.com 3.0, or would like to
acquire the Interactive Serial Port Test utility.

-Paul


From paul.klissner at sun.com  Tue Jun 20 05:33:44 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Tue, 20 Jun 2006 04:33:44 -0700
Subject: [Rxtx] Suggested installation RXTX 2.0x...
In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
Message-ID: <4497DD18.70207@sun.com>

Joachim Buechse wrote:
> Hello everybody,
> 
> I have been fighting a bit with the javax.comm version of RXTX the  
> last days. I am working on the README .OSX now and try to figure out  
> which should be the "suggested" installation.
> 
> The facts:
> ------
> 
> - the "generic" comm.jar version of javax.comm which has been made re- 
> available tries to load com.sun.comm.SolarisDriver
> - this classname can be overridden ONLY by putting a file  
> javax.comm.properties in {java.home}/lib
> - if it is not overridden and SolarisDriver.class is not found  
> CommPortIdentifier will be disfunctional (in particual it is not  
> possible to add CommPort's via CommPortIdentifier.add).
> - the license distributed with comm.jar does not allow the  
> modification/addition of classes in javax.comm (however no mention of  
> com.sun...)
> 
> 
> What really bothers me is to suggest putting this config file in the  
> "global" vm installation. This is particularly ugly on the Mac as  
> there are several VM installations and the file may be forgotten.  
> Additionally it may create versioning problems. I prefer an  
> installation where all files are local to the application (even  
> comm.jar).
> 
> In my opinion the ideal situation would be:
> ------
> 
> 1) The author of a program compiles against javax.comm.
> 2a) For platforms supported by Sun the user is free to use the 3.0  
> comm.jar download from Sun
> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to  
> the classpath of the application (and librxtxSerial.jnilib to the  
> application directory). Also he will need the 2.0.3 generic comm.jar  
> from Sun.
> 3) Nobody messes with the global VM installation.
> 
> Of course 2a) and 2b) could be handled by the author of the program  
> via an appropriate installer. The author could also decide to always  
> use RXTX and include the generic javax.comm classes as well as the  
> RXTX classes in his application jar. [If he further uses an explicit  
> call to System.load() he may even include the jnilib(s) in the jar,  
> extract it (based on the platform name) at runtime to a temp file and  
> load it from there.]
> 

This was how the Sun implementation originated (I did not write
that code).  I completely agree, and I fixed the whole conf file
locating mechanism in 3.0 to avoid the problems youmentioned.
However, I was unaware of how RxTx was using Sun's implementation,
so I didn't architect it in such a way as to avoid namespace pollution
in the native space in for the backend provider.  In retrospect,
I should have done that differently just as a design principle,
but at this point I don't have the spare cycles to get that all
re-factored.  Further, I'm loathe to do it, because the whole
thing will still be an under-the-hood hack due to the constraints
of the API itself.

Paul





From brian at mbari.org  Tue Jun 20 10:23:54 2006
From: brian at mbari.org (Brian Schlining)
Date: Tue, 20 Jun 2006 09:23:54 -0700
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>


Hi Joachim,

> There has been some discussions about the best way to install RXTX
> and where to place files.
>
> I suggest that,
>
> - we include the native libraries for the most common operating
> systems (in a special version of) RXTXcomm.jar
> - we add loader code which tries to extract and load the platform
> specific binary at runtime
> - on failure the current mechanism remains as a fallback

I like your suggestion. However, my understanding is that in general  
the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH  
(Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to  
be loaded by the JVM. The alternative is to point to your native lib  
directory using -Djava.library.path=/my/dir/with/native/libs when you  
launch the JVM. So, I'm very interested to know how you're planning  
to work around this.

> PS: Of course the suggested solution is already possible today,
> however relatively few programmers know how to correctly extract a
> binary resource file via the class loader and load it as a native
> library.

So how do you use it to dynamically load a native lib? I've read that  
you can't really modify the java.library.path after the JVM has been  
launched. (http://forum.java.sun.com/thread.jspa? 
threadID=627890&tstart=90)

Thanks

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0019.html

From joachim at buechse.de  Tue Jun 20 09:20:29 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 17:20:29 +0200
Subject: [Rxtx] 2.0x in sync with 2.1x
Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>

I have added most of the changes from the 2.1 branch to the 2.0 branch.

This includes
  - correction of illegal javadoc comments
  - implementation errors in handling of Thread.interrupt in  
RXTXPort.java
  - MacOS X locking without lock files/special user groups
  - XCode project which builds a universal binary library
  - updated documentation for OSX

I have done some minimal testing (only G4).
[Trent: there are still some changes you made for specific baud  
rates. I will not sync this, as I can not test them. From my  
perspective we are ready for 2.08/2.18]

The updated documentation can be found in the file README.OSX. Here  
it is:

------------------------ Required files -----------------------

To use or compile RXTX 2.0.x you need to downlad the "generic"  
version (2.0.3)
of the javax.comm implementation from Sun. The zip you download  
contains an
archive comm.jar which is required:

- To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar

- To run the app you will need comm.jar in the classpath or in  
{java.lib.path}


------------------------ Installation on MacOSX -----------------------

WARNING: Please read this section until the end.

---
Preparation
---

You may want to spare your users the burden of modifying the global VM
installation. OSX has several different VM versions installed by  
default and
regular users will be unable to figure out which version will load your
application.

If you provide the class

package com.sun.comm;
public class SolarisDriver extends gnu.io.RXTXCommDriver {
}

and make sure, that it is present in the classpath before Suns  
"generic" comm.jar
your users can skip the following step:

Create a file named
    javax.comm.properties
in the directory
    /System/Library/Frameworks/JavaVM.framework/Home/lib/
which contains (only) the following line (no leading space):
    Driver=gnu.io.RXTXCommDriver



----
The unsafe way of using RXTX on OS X:
----

RXTX can be installed by putting the files
   libSerial.jnilib
   RXTXcomm.jar
   comm.jar
into the folder
   /Library/Java/Extensions

This is NOT RECOMMENDED as it creates versioning conflicts among  
applications.
However you may be forced to install it this way if an application  
was written
for Windows or Linux, requires RXTX and you are not able to change  
its starter.


----
The safe way of using RXTX on OS X:
----

Make sure that you have no (older) version of RXTX installed in
   /Library/Java/Extensions
   /System/Library/Java/Extensions
   /usr/lib/java

Put
   libSerial.jnilib
in the directory of the application (the JavaVM will find it there). Add
   RXTXComm.jar
   comm.jar
to the application classpath or include the classes in the  
application jar.
(Some applications already include the RXTX classes in their  
application jar,
in which case only the file libSerial.jnilib is required).


----
History
----

Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation  
of lockfiles
required special permissions for the user executing an application  
based on RXTX.
To simplify the setup RXTX came with an installer modifying group  
permissions
and installing RXTX in the global location /Library/Java/Extensions.  
However
this was prune to versioning conflicts and is no longer recommended.

--------------------- Build instructions for OSX XCode  
-------------------

contributed by Joachim Buechse <joachim at buechse.de>
original version by Dmitry Markman <dmarkman at mac.com>

System requirements for building:
MacOSX 10.4
XCode 2.3

   open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj
   choose libSerial.jnilib target
   build

After the build you will find RXTXcomm.jar and libSerial.jnilib files  
in the
directory build/Development.

In case you can't find RXTXcomm.jar build the RXTXcomm target manually.
In case of (serious) problems feel free to contact joachim at buechse.de .



From tjarvi at qbang.org  Tue Jun 20 22:01:45 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT)
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
Message-ID: <Pine.LNX.4.61.0606202127270.14139@www>

> ---
> Preparation
> ---
>
> You may want to spare your users the burden of modifying the global VM
> installation. OSX has several different VM versions installed by
> default and
> regular users will be unable to figure out which version will load your
> application.
>
> If you provide the class
>
> package com.sun.comm;
> public class SolarisDriver extends gnu.io.RXTXCommDriver {
> }
>
> and make sure, that it is present in the classpath before Suns
> "generic" comm.jar
> your users can skip the following step:

Hi Joachim

With regards to the above, I have not seen that we have Sun's OK to 
promote that.  I'm not very comfortable with the distribution 
documentation advocating this without Sun agreeing.

I see your point but I'd rather not actively promote putting classes in 
Sun's namespace without permission if you don't mind.  This isn't about 
what is in a license.

I'll go through the code tomorrow night.  It was a late night at work 
today.  There is also a w32 fix comming for people opening and closing 
multiple ports.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Wed Jun 21 01:56:45 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 21 Jun 2006 09:56:45 +0200
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <Pine.LNX.4.61.0606202127270.14139@www>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
	<Pine.LNX.4.61.0606202127270.14139@www>
Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>

Hello Trent,

I guess we will not get an explicit OK from Sun for such a hack. I  
think Paul has made it pretty clear, that he does not have the  
resources to modify the 2.x or 3.x code for the needs of RXTX. I'm  
not thrilled but OK with the current API. Hence I dont agree with  
Paul's idea to start a new JSR to fix the implementation - but that's  
mainly because I dont have the time to push it. According to their  
Readme Sun sees no business case in having cross platform support for  
javax.comm - that is sad but it's none of my business. However I  
prefer to program versus javax.comm in my projects as this gives an  
advanced user the chance to exchange the provider without access to  
the code.

I interpret Pauls reponse to my original "Request for comment" as a  
quiet acceptance of the hack I propose (he did respond, but not at  
all to the sun.comm namespace suggestion). This is certainly not  
something we should put into RXTXcomm.jar but hinting a work around  
for implementation errors should be allowed. That's why I've choosen  
the wording "You may want to spare" and "If you provide". The company  
I worked for has choosen similar hacks for years to fix bugs in swing  
for JDK1.1 applications. Those hacks were usually included in their  
own swingpatch.jar.

Having said all that - I do not take it as an insult if you remove  
the paragraph from the Readme. I appreciate that you notified me  
before. It would be interesting to hear some more opinions from the  
list members...

Best regards,
Joachim


On 21.06.2006, at 06:01, Trent Jarvi wrote:

>> ---
>> Preparation
>> ---
>>
>> You may want to spare your users the burden of modifying the  
>> global VM
>> installation. OSX has several different VM versions installed by
>> default and
>> regular users will be unable to figure out which version will load  
>> your
>> application.
>>
>> If you provide the class
>>
>> package com.sun.comm;
>> public class SolarisDriver extends gnu.io.RXTXCommDriver {
>> }
>>
>> and make sure, that it is present in the classpath before Suns
>> "generic" comm.jar
>> your users can skip the following step:
>
> Hi Joachim
>
> With regards to the above, I have not seen that we have Sun's OK to
> promote that.  I'm not very comfortable with the distribution
> documentation advocating this without Sun agreeing.
>
> I see your point but I'd rather not actively promote putting  
> classes in
> Sun's namespace without permission if you don't mind.  This isn't  
> about
> what is in a license.
>
> I'll go through the code tomorrow night.  It was a late night at work
> today.  There is also a w32 fix comming for people opening and closing
> multiple ports.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Wed Jun 21 02:03:33 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 21 Jun 2006 10:03:33 +0200
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
	<6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
Message-ID: <BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>

See System.load(String) [it's also mentioned under the URL you posted].

Regards,
Joachim


On 20.06.2006, at 18:23, Brian Schlining wrote:

> So how do you use it to dynamically load a native lib? I've read  
> that you can't really modify the java.library.path after the JVM  
> has been launched. (http://forum.java.sun.com/thread.jspa? 
> threadID=627890&tstart=90)
>
> Thanks
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From baris.ozkan at elikasu.com.tr  Wed Jun 21 07:58:06 2006
From: baris.ozkan at elikasu.com.tr (Baris)
Date: Wed, 21 Jun 2006 16:58:06 +0300
Subject: [Rxtx] RS 232 ..additional parameters
Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>

Hi,
 
Currently i am developing an application that requires to connect to a
remote rs232 device through  a dialup connection.
 
My problem is that the communication needs several more connection
parameters (i extracted that information from the vendor's dll , listed at
the end of the message)
 
I explored rxtx API and src files and could not find methods to set a
majority  of the parameters.
Am i missing any point or does rxtx is limited to soem standard set of
functionality(e.g. commAPI)? How  is it possible ,if i want to put some
extensions(???) to current rxtx implementation?
 
I am not very good at rs232 programming so excuse me if this message  is
boring one.
 
Thanx
 
Baris Ozkan
 
 
A Listing of Parameters:
 
 
typedef struct _DCB {

DWORD DCBlength; /* sizeof(DCB) */

DWORD BaudRate; /* Baudrate at which running */

DWORD fBinary: 1; /* Binary Mode (skip EOF check) */

DWORD fParity: 1; /* Enable parity checking */

DWORD fOutxCtsFlow:1; /* CTS handshaking on output */

DWORD fOutxDsrFlow:1; /* DSR handshaking on output */

DWORD fDtrControl:2; /* DTR Flow control */

DWORD fDsrSensitivity:1; /* DSR Sensitivity */

DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */

DWORD fOutX: 1; /* Enable output X-ON/X-OFF */

DWORD fInX: 1; /* Enable input X-ON/X-OFF */

DWORD fErrorChar: 1; /* Enable Err Replacement */

DWORD fNull: 1; /* Enable Null stripping */

DWORD fRtsControl:2; /* Rts Flow control */

DWORD fAbortOnError:1; /* Abort all reads and writes on Error */

DWORD fDummy2:17; /* Reserved */

WORD wReserved; /* Not currently used */

WORD XonLim; /* Transmit X-ON threshold */

WORD XoffLim; /* Transmit X-OFF threshold */

BYTE ByteSize; /* Number of bits/byte, 4-8 */

BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */

BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */

char XonChar; /* Tx and Rx X-ON character */

char XoffChar; /* Tx and Rx X-OFF character */

char ErrorChar; /* Error replacement char */

char EofChar; /* End of Input character */

char EvtChar; /* Received Event character */

WORD wReserved1; /* Fill for now. */

} DCB, *LPDCB;

typedef struct _COMMTIMEOUTS {

DWORD ReadIntervalTimeout; /* Maximum time between read chars. */

DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */

DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */

DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */

DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */

} COMMTIMEOUTS,*LPCOMMTIMEOUTS;

dcb.fOutX = FALSE;

dcb.fInX = FALSE;

dcb.fOutxCtsFlow = FALSE;

dcb.fBinary = TRUE;

dcb.fRtsControl = RTS_CONTROL_ENABLE;

SetCommState(hComm , &dcb ); 

COMMTIMEOUTS commTimeOut;

GetCommTimeouts(hComm, &commTimeOut );

commTimeOut.WriteTotalTimeoutMultiplier = 1; 

commTimeOut.WriteTotalTimeoutConstant = 18; 

// commTimeOut.ReadIntervalTimeout = 28; 

commTimeOut.ReadIntervalTimeout = 0; 

// commTimeOut.ReadTotalTimeoutMultiplier = 184; 

commTimeOut.ReadTotalTimeoutMultiplier = 300; 

// commTimeOut.ReadTotalTimeoutConstant = 1200;

commTimeOut.ReadTotalTimeoutConstant = 1200;

SetCommTimeouts(hComm, &commTimeOut);

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0019.html

From ajmas at sympatico.ca  Wed Jun 21 08:14:26 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Wed, 21 Jun 2006 10:14:26 -0400
Subject: [Rxtx] When is 2.18 planned for?
Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

Just curious as to know if there is a target date for 2.18?

Andre



From brian at mbari.org  Wed Jun 21 09:36:00 2006
From: brian at mbari.org (Brian Schlining)
Date: Wed, 21 Jun 2006 08:36:00 -0700
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
	<6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
	<BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>
Message-ID: <A21C9BC0-7894-4B08-AC82-44E11AB3D461@mbari.org>

Ha!!

I suppose I should read my own postings. ;-)

Thanks
B

On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote:

> See System.load(String) [it's also mentioned under the URL you  
> posted].
>
> Regards,
> Joachim
>
>
> On 20.06.2006, at 18:23, Brian Schlining wrote:
>
>> So how do you use it to dynamically load a native lib? I've read
>> that you can't really modify the java.library.path after the JVM
>> has been launched. (http://forum.java.sun.com/thread.jspa?
>> threadID=627890&tstart=90)

Brian Schlining
Software Engineer
http://www.mbari.org




From ajmas at sympatico.ca  Wed Jun 21 16:41:28 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Wed, 21 Jun 2006 18:41:28 -0400
Subject: [Rxtx] CVS build question
Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X:

 The JCL extension to RxTx requires comm.jar
 If you intend to use RxTx for commapi support comm.jar
 needs to be located in  /System/Library/Frameworks/JavaVM.framework/
  Versions/1.5/Home/lib/ext/comm.jar

I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me.

On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native).

Andre






From tjarvi at qbang.org  Wed Jun 21 18:00:04 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT)
Subject: [Rxtx] CVS build question
In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606211756310.14139@www>

On Wed, 21 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> Is the CVS repository meant to build for gnu.io or javax.comm? I ask 
> this, because I see the following when calling ./configure from MacOS X:
>
> The JCL extension to RxTx requires comm.jar
> If you intend to use RxTx for commapi support comm.jar
> needs to be located in  /System/Library/Frameworks/JavaVM.framework/
>  Versions/1.5/Home/lib/ext/comm.jar
>
> I am wanting to build for the gnu.io package, since I want to jump ahead 
> and see if the changes, intended for 2.18 for MacOS X, work for me.
>
> On a side note /Library/Java/Extensions should be included as a valid 
> search path for the JAR, since this is where Apple recommends placing 
> third party extensions (both Java and native).
>

rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel"
rxtx 2.0 src is obtained with "cvs checkout rxtx-devel"

rxtx 2.1 is a complete package in namespace gnu.io
rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 18:02:23 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT)
Subject: [Rxtx] When is 2.18 planned for?
In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606211800180.14139@www>

On Wed, 21 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> Just curious as to know if there is a target date for 2.18?
>

Hi Andre

"When it is ready" :)

Probably this weekend.  Maybe sooner.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 18:10:18 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT)
Subject: [Rxtx] RS 232 ..additional parameters
In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>
References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>
Message-ID: <Pine.LNX.4.61.0606211805010.14139@www>

On Wed, 21 Jun 2006, Baris wrote:

> Hi,
>
> Currently i am developing an application that requires to connect to a
> remote rs232 device through  a dialup connection.
>
> My problem is that the communication needs several more connection
> parameters (i extracted that information from the vendor's dll , listed at
> the end of the message)
>
> I explored rxtx API and src files and could not find methods to set a
> majority  of the parameters.
> Am i missing any point or does rxtx is limited to soem standard set of
> functionality(e.g. commAPI)? How  is it possible ,if i want to put some
> extensions(???) to current rxtx implementation?
>
> I am not very good at rs232 programming so excuse me if this message  is
> boring one.
>
> Thanx
>

Hi Baris

> typedef struct _DCB {
> typedef struct _COMMTIMEOUTS {

These are all handled in termios.c.  It is possible to add extensions to 
rxtx 2.1.  It may well be that the defaults are the same for the variables 
not covered by the existing API.  You can dump the DCB and COMMTIMEOUTS 
from inside termios.c to compare.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 20:23:30 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT)
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
	<Pine.LNX.4.61.0606202127270.14139@www>
	<789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>
Message-ID: <Pine.LNX.4.61.0606212012210.14139@www>

> I'm
> not thrilled but OK with the current API. Hence I dont agree with
> Paul's idea to start a new JSR to fix the implementation - but that's
> mainly because I dont have the time to push it. According to their
> Readme Sun sees no business case in having cross platform support for
> javax.comm - that is sad but it's none of my business. However I
> prefer to program versus javax.comm in my projects as this gives an
> advanced user the chance to exchange the provider without access to
> the code.

Hi Joachim

With regards to the JSR, I think that would be Doug's call.  The effort I 
put in would have to be on my own time which would not be a great deal.  I 
could help things go smoothly but thats not the same as pushing something 
through.

--
Trent Jarvi
tjarvi at qbang.org



From vt at freehold.crocodile.org  Wed Jun 21 21:05:22 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Wed, 21 Jun 2006 20:05:22 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
Message-ID: <449A08F2.3020106@freehold.crocodile.org>

Hello all,

I know this question may belong to JSR lists, but since all interested 
parties are here, I thought I just ask this question here, again...

A while ago I run into a problem and wrote a rant, here: 
http://servomaster.sourceforge.net/dev/serial-usb.html
At the time of writing I didn't think of adding another possible 
solution - changing the CommAPI specs to support removable devices. 
Apparently, Serial/USB bridges are here to stay, and this issue has to 
be addressed.

Wonder if anything changed since, and any abstractions for supporting 
removable devices made it into current or future Java CommAPI drafts - 
Paul, any comments?

--vt



From joachim at buechse.de  Thu Jun 22 01:59:54 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 22 Jun 2006 09:59:54 +0200
Subject: [Rxtx] CVS build question
In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de>

Hello Andre,

I am not sure how well the configure/make mechanism will work on OSX.  
I know that a while ago some contributors tried to get configure/make  
working on OSX but from comments I found in the readmes this work was  
only partially successfull. For compilation on OSX we have used the  
ProjectBuilder/XCode projects you can find in MACOSX_IDE.

Regarding the  ./configure comment:
RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config  
file javax.comm.properties. The later MUST reside in {java.home}/lib.  
As the two only work together putting comm.jar into  /Library/Java/ 
Extensions  and hence making it available to all current and future  
VM installations will only add to confusion.

Regards,
Joachim

On 22.06.2006, at 00:41, Andre-John Mas wrote:

> Hi,
>
> Is the CVS repository meant to build for gnu.io or javax.comm? I  
> ask this, because I see the following when calling ./configure from  
> MacOS X:
>
>  The JCL extension to RxTx requires comm.jar
>  If you intend to use RxTx for commapi support comm.jar
>  needs to be located in  /System/Library/Frameworks/JavaVM.framework/
>   Versions/1.5/Home/lib/ext/comm.jar
>
> I am wanting to build for the gnu.io package, since I want to jump  
> ahead and see if the changes, intended for 2.18 for MacOS X, work  
> for me.
>
> On a side note /Library/Java/Extensions should be included as a  
> valid search path for the JAR, since this is where Apple recommends  
> placing third party extensions (both Java and native).
>
> Andre
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Thu Jun 22 02:51:05 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 22 Jun 2006 10:51:05 +0200
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449A08F2.3020106@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>

Hello Vadim,

I think that your rant is to the point. However it is a bit like  
saying that Windows is at the source of email degradation and the  
only solution is to have users switch to safer operating systems.

I don't see how javax.comm or RXTX can address the problems you  
mention. Of course it would be super cool if javax.comm could magicly  
find the "matching" usb-device and query it's configuration via the  
usb protocol - however this magic (mapping /dev/xyz to its underlying  
USB device) is not supported by any kernel APIs I am aware of. It  
could be supported via POSSIX ioctl calls but then you should address  
your rant to the POSSIX group...

So for the time beeing it's either up to the virtual comm port driver  
to provide a usefull name under /dev/ or to the user choosing the  
right port to use. One example of a smart(er) com port driver is the  
KDDI driver for OSX, which will create device names like "/dev/ 
cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- 
encoded into the bridge chip. The same driver for windows also has  
some options allowing it in theory to recreate the same COMx every  
time a device is plugged/unplugged.

For most industrial applications however it will be up to the user to  
choose the right port (without getting a lot of help doing so).

Probing serial ports can go wrong, that's right. However any serial  
device developper would be well adviced to implement a basic set of  
Hayes AT modem commands (be it a modem or not). Especially AT I0.  
Anyone failing to do so risks that the users favourite TCP/PPP/FAX  
application or stack will kill the device in short time.

Best regards,
Joachim


On 22.06.2006, at 05:05, Vadim Tkachenko wrote:

> Hello all,
>
> I know this question may belong to JSR lists, but since all interested
> parties are here, I thought I just ask this question here, again...
>
> A while ago I run into a problem and wrote a rant, here:
> http://servomaster.sourceforge.net/dev/serial-usb.html
> At the time of writing I didn't think of adding another possible
> solution - changing the CommAPI specs to support removable devices.
> Apparently, Serial/USB bridges are here to stay, and this issue has to
> be addressed.
>
> Wonder if anything changed since, and any abstractions for supporting
> removable devices made it into current or future Java CommAPI drafts -
> Paul, any comments?
>
> --vt
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From vt at freehold.crocodile.org  Thu Jun 22 13:16:03 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 12:16:03 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
Message-ID: <20060622191603.GA17487@freehold.crocodile.org>

Hello Joachim,

> I think that your rant is to the point. However it is a bit like  
> saying that Windows is at the source of email degradation and the  
> only solution is to have users switch to safer operating systems.

I guess the problem is that the rant itself is obsolete and has to be
updated according to latest developments. At the time of writing there
weren't that many bridges around, and the trend didn't manifest itself as it
does now.

> I don't see how javax.comm or RXTX can address the problems you  
> mention.

I would agree that javax.comm won't be able to address the problem, at least
in the short run. As for RxTx - well, nobody prevents it from being a
superset of CommAPI specification, right? RxTx being the de-facto standard
for quite a few platforms, I'd daresay the standard may follow.

> Of course it would be super cool if javax.comm could magicly find the
> "matching" usb-device and query it's configuration via the usb protocol -
> however this magic (mapping /dev/xyz to its underlying USB device) is not
> supported by any kernel APIs I am aware of. It could be supported via
> POSSIX ioctl calls but then you should address your rant to the POSSIX
> group...

As a matter of fact, my bigger concern is addressing the fact that a serial
device can now be removable. This hasn't been the case before, and it
clearly is now. Regarding the above, well, I guess if we accept this fact,
we also need to accept the fact that we need at least rudimentary means of
identification of a serial device. For the USB case, it would usually be the
vendor/product ID, plus possible serial number - but it is irrelevant what
exactly the identifying information is, as long as it allows to identify the
device.

A paradigm shift is required, this is what I wanted to say. Serial devices
can be removed and replaced, it's now our turn to learn to deal with it.

> Joachim

--vt


From jredman at ergotech.com  Thu Jun 22 13:41:44 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 13:41:44 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
Message-ID: <449AF278.6000903@ergotech.com>


Vadim Tkachenko wrote:
> A paradigm shift is required, this is what I wanted to say. Serial devices
> can be removed and replaced, it's now our turn to learn to deal with it.

The removal if the serial port hardly significantly different from the 
removal of the device attached to the serial port.   Different, 
slightly, but not a "paradigm shift".

And yes, someone could unplug a USB serial device and plug it into a 
different USB port so that it has a different name/number, but they 
could do that with the device itself, move it from com1 to com2.

Am I missing something?

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 13:57:27 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 12:57:27 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449AF278.6000903@ergotech.com>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
Message-ID: <20060622195727.GA20247@freehold.crocodile.org>

On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote:
> 
> Vadim Tkachenko wrote:
> > A paradigm shift is required, this is what I wanted to say. Serial devices
> > can be removed and replaced, it's now our turn to learn to deal with it.
> 
> The removal if the serial port hardly significantly different from the 
> removal of the device attached to the serial port.   Different, 
> slightly, but not a "paradigm shift".
> 
> And yes, someone could unplug a USB serial device and plug it into a 
> different USB port so that it has a different name/number, but they 
> could do that with the device itself, move it from com1 to com2.
> 
> Am I missing something?

Yes, the fact that they could unplug a device A and plug a device B. With
the introduction of the concept of removability, the notion of the serial
port itself is not as important anymore, but the notion of the unique device
identifier is.

Consider a situation: long running system (enterprise HVAC, tens of nodes,
tens of thousands square feet area, hundreds of thousand dollars worth of
equipment being conditioned, can't shut down), serial/usb device fails, is
replaced by an identical device with a different serial #.

A little bit farfetched, but hopefully highlighting the point I'm trying to
make.

> Jim

--vt


From jredman at ergotech.com  Thu Jun 22 14:37:38 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 14:37:38 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>	<20060622191603.GA17487@freehold.crocodile.org>	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
Message-ID: <449AFF92.8080003@ergotech.com>


Vadim Tkachenko wrote:
>>
>> Am I missing something?
> 
> Yes, the fact that they could unplug a device A and plug a device B. With
> the introduction of the concept of removability, the notion of the serial
> port itself is not as important anymore, but the notion of the unique device
> identifier is.

Serial devices are always removable.  I could unplug _serial_ device A 
and plug in _serial_ device B.  We have systems running with two RS485 
ports, one talks to a Modbus PLC network one to a number of drives on a 
proprietary protocol.  If you plug the wrong DB9 into the wrong port the 
application doesn't work.

If you dangle a USB 485 converter on the end of the DB9 you've just 
moved the problem from RS485 to USB, but the problem/effect is the same.

> 
> Consider a situation: long running system (enterprise HVAC, tens of nodes,
> tens of thousands square feet area, hundreds of thousand dollars worth of
> equipment being conditioned, can't shut down), serial/usb device fails, is
> replaced by an identical device with a different serial #.
> 
> A little bit farfetched, but hopefully highlighting the point I'm trying to
> make.

Nothing's changed.  If I had a 4 port ISA board and plugged it into my 
new shiny '386 machine.  I could have com ports 9-12.  If I took a board 
off the shelf and didn't set the jumpers, I would have com ports 3-6.

The problem's the same.  If you replace with identical product then the 
com ports  will be the same - no software changes required.  If you 
replace one piece of hardware with hardware from a different 
manufacturer, then the naming/numbering may change.  You're physically 
changing the system, so may reasonably expect to have to make a software 
change.  RXTX actually handles this situation quite well with the -D 
command line option.  (My experience has generally been that the port 
number depends more on the USB port used than the hardware - so the 
chances are even with a hardware change the port number/name will be the 
same.)

Slightly Off Topic - there is a reason why industrial users will pay a 
premium for continued availability of hardware.  Yes you can mail-order 
a $10 USB converter and it will work, but there's no guarantee that the 
next time you buy the same part number from the same vendor it will be 
the same.  The industrial vendors will charge you $100+ for the same 
item, but it will be the same every time you buy it for the next 5 to 10 
years.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 14:37:19 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 13:37:19 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
Message-ID: <20060622203719.GA22521@freehold.crocodile.org>

Hello again,

And while I'm at it, why don't just say this: give me one good reason to
write 3+ different ways of handling removable devices, one for USB, one for
FireWire, one for serial...

I understand very well that this goes way beyond the scope of RxTx and
CommAPI and will require cooperation between them and javax.usb and whatever
JSR is responsible for FireWire implementation - but the end result is well
worth it. Abstract out and generalize arrival/departure/monitoring/discovery
API, provide protocol specific extensions for each, live happily ever after.

--vt


On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote:
> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote:
> > 
> > Vadim Tkachenko wrote:
> > > A paradigm shift is required, this is what I wanted to say. Serial devices
> > > can be removed and replaced, it's now our turn to learn to deal with it.
> > 
> > The removal if the serial port hardly significantly different from the 
> > removal of the device attached to the serial port.   Different, 
> > slightly, but not a "paradigm shift".
> > 
> > And yes, someone could unplug a USB serial device and plug it into a 
> > different USB port so that it has a different name/number, but they 
> > could do that with the device itself, move it from com1 to com2.
> > 
> > Am I missing something?
> 
> Yes, the fact that they could unplug a device A and plug a device B. With
> the introduction of the concept of removability, the notion of the serial
> port itself is not as important anymore, but the notion of the unique device
> identifier is.
> 
> Consider a situation: long running system (enterprise HVAC, tens of nodes,
> tens of thousands square feet area, hundreds of thousand dollars worth of
> equipment being conditioned, can't shut down), serial/usb device fails, is
> replaced by an identical device with a different serial #.
> 
> A little bit farfetched, but hopefully highlighting the point I'm trying to
> make.
> 
> > Jim
> 
> --vt
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx


From jredman at ergotech.com  Thu Jun 22 15:13:49 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 15:13:49 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>	<20060622191603.GA17487@freehold.crocodile.org>	<449AF278.6000903@ergotech.com>	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
Message-ID: <449B080D.9080208@ergotech.com>


Vadim Tkachenko wrote:
> Hello again,
> 
> And while I'm at it, why don't just say this: give me one good reason to
> write 3+ different ways of handling removable devices, one for USB, one for
> FireWire, one for serial...

You don't, they're all the same "I have lost communication with my 
serial device".

The only thing you could really do is improve error reporting by knowing 
the exact sub-system.  ("Device X which is/was attached to USB port Y is 
no longer functioning, please check the USB ports, the device, the 
cables and anything else you can think of that may be a cause of 
failure.")  That just requires an intelligent description of the port.

> I understand very well that this goes way beyond the scope of RxTx and
> CommAPI and will require cooperation between them and javax.usb and whatever
> JSR is responsible for FireWire implementation - but the end result is well
> worth it. Abstract out and generalize arrival/departure/monitoring/discovery
> API, provide protocol specific extensions for each, live happily ever after.

There's a huge list of pseudo-serial devices each with a different set 
of requirements, Bluetooth, RFC 2217, a host of proprietary systems, 
etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I 
have no clue how you'd implement them in a general/cross platform sense.

You haven't convinced me (and only me, others may see something that I 
don't, I'm not speaking for them) that this mechanism can be implemented 
in any practical sense.  That is, that the implementation could be wide 
enough to be consider generally available in RXTX regardless of the 
serial port implementation, platform, etc..  However, if you can come up 
with a general design and a reference implementation for one subsystem, 
I'd like to see it and might get on board.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 15:40:55 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 14:40:55 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449B080D.9080208@ergotech.com>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
Message-ID: <20060622214055.GA25497@freehold.crocodile.org>

On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote:
> 
> Vadim Tkachenko wrote:
> > Hello again,
> > 
> > And while I'm at it, why don't just say this: give me one good reason to
> > write 3+ different ways of handling removable devices, one for USB, one for
> > FireWire, one for serial...
> 
> You don't, they're all the same "I have lost communication with my 
> serial device".

"I have lost communication with my ${protocol} device".

> The only thing you could really do is improve error reporting by knowing 
> the exact sub-system.  ("Device X which is/was attached to USB port Y is 
> no longer functioning, please check the USB ports, the device, the 
> cables and anything else you can think of that may be a cause of 
> failure.")

"Device ${id} which is/was attached to ${protocol} port ${port} is no longer
functioning, please check the ${protocol} ports, the device, the
${protocol_media} and anything else you can think of that may be a cause of
failure".

>  That just requires an intelligent description of the port.

Agree absolutely.

> > I understand very well that this goes way beyond the scope of RxTx and
> > CommAPI and will require cooperation between them and javax.usb and whatever
> > JSR is responsible for FireWire implementation - but the end result is well
> > worth it. Abstract out and generalize arrival/departure/monitoring/discovery
> > API, provide protocol specific extensions for each, live happily ever after.
> 
> There's a huge list of pseudo-serial devices each with a different set 
> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, 
> etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I 
> have no clue how you'd implement them in a general/cross platform sense.

That's because some of the protocols were created decades ago when
autoconfiguration wasn't even conceived, much less practical. RS232/RS485
don't have a clue about identity discovery, and even capabilities discovery
beyond obvious 8N1 etc.

I agree that today all these protocols have generally incompatible
strategies for handling the situations I'm trying to address, but there's
nothing that says it's not an oversight. Besides, we're dealing with the
devices at a level of abstraction that allows some simplifications and
generalizations, at least part of the time - unless it's the protocol
specific features we're dealing with.

> You haven't convinced me (and only me, others may see something that I 
> don't, I'm not speaking for them) that this mechanism can be implemented 
> in any practical sense.  That is, that the implementation could be wide 
> enough to be consider generally available in RXTX regardless of the 
> serial port implementation, platform, etc..  However, if you can come up 
> with a general design and a reference implementation for one subsystem, 
> I'd like to see it and might get on board.

Actually, I wasn't even thinking about all this stuff when I wrote the first
message on the subject :) Now that you mention it - well, I'm not sure I can
chew the piece I just tried to bite in reasonable amount of time.

How do you eat an elephant? One bite at a time. If we could agree that a
small step in the specification is acceptable at this time, and express
further intentions, things may start happening.

To put it succinctly:

- Concept of a "port" should be augmented with a concept of a "device". A
device may be attached to a port in an implicit or explicit way.
- Implicitly connected device is exactly what the current scope of the
specification covers. No new functionality is offered.
- Explicitly connected device supports detachable device semantics, just as
other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a
few).
- The input and output streams are not properties of a port now, but
properties of the device attached to the port.
- A mechanism to allow listening for device arrivals and departures must be
made available.

That's it, off the top of my head.

I understand that this goes completely against current javax.comm specs, but
an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be
difficult to implement without disrupting javax.comm compatibility.

One concern is how to deal with the device identity - but there's no general
way of dealing with this at this time, devices may or may not offer identity
discovery.

> Jim

--vt


From joachim at buechse.de  Fri Jun 23 02:12:43 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 23 Jun 2006 10:12:43 +0200
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
Message-ID: <CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>

Hello++ Vadim,

I would like to repeat that your request is best addressed to the  
POSSIX standardization group - or maybe the BSD/Linux maintainers. If  
you convince the BSD or Linux guys to add this kind of functionality  
(they can as most of there VCP drivers are open source), there is a  
certain chance that other vendors will pick it up. I assure you that  
RXTX will happily provide this functionality once it's possible - I'm  
sure there is more than one maintainer that would love to add it.  
Having this concept penetrate the market may take some years though.

SHORT: The solution you would like to see could be added to the API  
but it can not be implemented (at least not on the platforms I know).  
There are currently no hooks in the kernel that allow you to discover  
"the device" or even the "means of connection" based on an existing  
"device file descriptor" ie COM-port or /dev/... entry. The name  
mapping of the device is handled by the virtual com port driver of  
the device. Unless you are suggesting RXTX should reimplement virtual  
com port drivers for all usb/serial bridges out there your request is  
understandable from a users viewpoint but simply not realizable. It's  
like asking that the Socket api should identify the computer behind  
an IP address (ie by its Ethernet address). While this COULD be  
implemented in TCP/IP, it IS not, and hence there is no point adding  
such a function to the Socket API.

The current trend for USB/Bluetooth/Irda/etc connected devices is  
going away from serial port abstraction towards RPC (ie the drivers  
provide a device specific or device class specific driver that  
provides an application level api to the device functions). The line  
level protocol is often not even published.

Best regards,
Joachim

On 22.06.2006, at 23:40, Vadim Tkachenko wrote:

> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote:
>>
>> Vadim Tkachenko wrote:
>>> Hello again,
>>>
>>> And while I'm at it, why don't just say this: give me one good  
>>> reason to
>>> write 3+ different ways of handling removable devices, one for  
>>> USB, one for
>>> FireWire, one for serial...
>>
>> You don't, they're all the same "I have lost communication with my
>> serial device".
>
> "I have lost communication with my ${protocol} device".
>
>> The only thing you could really do is improve error reporting by  
>> knowing
>> the exact sub-system.  ("Device X which is/was attached to USB  
>> port Y is
>> no longer functioning, please check the USB ports, the device, the
>> cables and anything else you can think of that may be a cause of
>> failure.")
>
> "Device ${id} which is/was attached to ${protocol} port ${port} is  
> no longer
> functioning, please check the ${protocol} ports, the device, the
> ${protocol_media} and anything else you can think of that may be a  
> cause of
> failure".
>
>>  That just requires an intelligent description of the port.
>
> Agree absolutely.
>
>>> I understand very well that this goes way beyond the scope of  
>>> RxTx and
>>> CommAPI and will require cooperation between them and javax.usb  
>>> and whatever
>>> JSR is responsible for FireWire implementation - but the end  
>>> result is well
>>> worth it. Abstract out and generalize arrival/departure/ 
>>> monitoring/discovery
>>> API, provide protocol specific extensions for each, live happily  
>>> ever after.
>>
>> There's a huge list of pseudo-serial devices each with a different  
>> set
>> of requirements, Bluetooth, RFC 2217, a host of proprietary systems,
>> etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I
>> have no clue how you'd implement them in a general/cross platform  
>> sense.
>
> That's because some of the protocols were created decades ago when
> autoconfiguration wasn't even conceived, much less practical. RS232/ 
> RS485
> don't have a clue about identity discovery, and even capabilities  
> discovery
> beyond obvious 8N1 etc.
>
> I agree that today all these protocols have generally incompatible
> strategies for handling the situations I'm trying to address, but  
> there's
> nothing that says it's not an oversight. Besides, we're dealing  
> with the
> devices at a level of abstraction that allows some simplifications and
> generalizations, at least part of the time - unless it's the protocol
> specific features we're dealing with.
>
>> You haven't convinced me (and only me, others may see something  
>> that I
>> don't, I'm not speaking for them) that this mechanism can be  
>> implemented
>> in any practical sense.  That is, that the implementation could be  
>> wide
>> enough to be consider generally available in RXTX regardless of the
>> serial port implementation, platform, etc..  However, if you can  
>> come up
>> with a general design and a reference implementation for one  
>> subsystem,
>> I'd like to see it and might get on board.
>
> Actually, I wasn't even thinking about all this stuff when I wrote  
> the first
> message on the subject :) Now that you mention it - well, I'm not  
> sure I can
> chew the piece I just tried to bite in reasonable amount of time.
>
> How do you eat an elephant? One bite at a time. If we could agree  
> that a
> small step in the specification is acceptable at this time, and  
> express
> further intentions, things may start happening.
>
> To put it succinctly:
>
> - Concept of a "port" should be augmented with a concept of a  
> "device". A
> device may be attached to a port in an implicit or explicit way.
> - Implicitly connected device is exactly what the current scope of the
> specification covers. No new functionality is offered.
> - Explicitly connected device supports detachable device semantics,  
> just as
> other protocols do (USB, FireWire, Wireless USB, Bluetooth, to  
> mention a
> few).
> - The input and output streams are not properties of a port now, but
> properties of the device attached to the port.
> - A mechanism to allow listening for device arrivals and departures  
> must be
> made available.
>
> That's it, off the top of my head.
>
> I understand that this goes completely against current javax.comm  
> specs, but
> an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern )  
> won't be
> difficult to implement without disrupting javax.comm compatibility.
>
> One concern is how to deal with the device identity - but there's  
> no general
> way of dealing with this at this time, devices may or may not offer  
> identity
> discovery.
>
>> Jim
>
> --vt
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From vt at freehold.crocodile.org  Fri Jun 23 11:28:29 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Fri, 23 Jun 2006 10:28:29 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
	<CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
Message-ID: <20060623172829.GA5335@freehold.crocodile.org>

Hello Joachim,

> I would like to repeat that your request is best addressed to the POSSIX
> standardization group - or maybe the BSD/Linux maintainers. If you
> convince the BSD or Linux guys to add this kind of functionality (they can
> as most of there VCP drivers are open source), there is a certain chance
> that other vendors will pick it up. I assure you that RXTX will happily
> provide this functionality once it's possible - I'm sure there is more
> than one maintainer that would love to add it.

I realize this thing is bigger than RxTx itself, and I'm afraid it's too
global not to cause people to laugh before they think about it :)

> Having this concept penetrate the market may take some years though.

Well, I'm sure it'll get there, the only question is - when.

> SHORT: The solution you would like to see could be added to the API but it
> can not be implemented (at least not on the platforms I know).

I guess I'm concerned about the abstraction more than I'm concerned about
the implementation at this point.
  
> There are currently no hooks in the kernel that allow you to discover  
> "the device" or even the "means of connection" based on an existing  
> "device file descriptor" ie COM-port or /dev/... entry.

Well, I'm not so sure you need to keep the literal mapping from /dev
namespace to your device namespace. As long as you can consistently offer a
virtual serial device on top of a virtual serial port, it may be irrelevant
whether you can map it into /dev. The mapping is going be schitzofrenic
anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the
representation...

> The name mapping of the device is handled by the virtual com port driver
> of the device. Unless you are suggesting RXTX should reimplement virtual
> com port drivers for all usb/serial bridges out there your request is
> understandable from a users viewpoint but simply not realizable.

It's not so much a request but rather an offer of participation. I run a few
projects actively using serial communications, as well as USB device
drivers, in different degrees of readiness (Servomaster, Haywire, DIY
Zoning) - and it would be a perfect playground.

You mentioned above that this task is about two things: a) abstraction b)
implementation. I could start the abstraction part of it without changing
the current CommAPI, on top of it, as an adapter. Even if the removable
device semantics are not implemented, but offered, this is already a step
forward.

> It's like asking that the Socket api should identify the computer behind
> an IP address (ie by its Ethernet address). While this COULD be
> implemented in TCP/IP, it IS not, and hence there is no point adding such
> a function to the Socket API.

Thank you for bringing up this example - I guess this is just about the same
thing that I'd like to see. Socket transparently provides you with the
input/output streams, at the same time offering protocol level specifics to
you.

> The current trend for USB/Bluetooth/Irda/etc connected devices is going
> away from serial port abstraction towards RPC (ie the drivers provide a
> device specific or device class specific driver that provides an
> application level api to the device functions). The line level protocol is
> often not even published.

I can't say I'm that happy with it. The best (or, rather, worst) example is
suchlike support for the Phidget servo controller - zealous Linux developers
implemented kernel module support for it, completely hijacking a possibility
of using it on a different level (it's somewhat fixed by now, thankfully).

I believe that whenever an abstraction is offered, it must be made optional
and/or pluggable so it can be replaced by something more suited to the task.

The nature of Java applications is such that they'd probably care much more
about Java API offered, than about no matter how rich application level api
that is offered outside of Java. I've dealt with JNI adapters in the past,
and whereas they can be made reasonably stable, the very fact that you are
forced to deal with things that are not on the critical timing/memory path
and could've been done much easier in Java causes endless grief.

> Joachim

--vt


From lyon at docjava.com  Sat Jun 24 04:54:12 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Sat, 24 Jun 2006 06:54:12 -0400
Subject: [Rxtx] jsr
In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
	<CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
	<20060623172829.GA5335@freehold.crocodile.org>
Message-ID: <p060204a3c0c2c9dde4f8@[192.168.1.152]>

Hi All,
I have had some off-list discussion with Trent.
Opening up a JSR with Sun, as per Peters' suggestion
seems like a reasonable idea, to us.

Does anyone having any concerns about the JSR process
that they would like to raise?

Thanks!
  - Doug



From the.grey.lantern at gmail.com  Sat Jun 24 18:15:26 2006
From: the.grey.lantern at gmail.com (Craig Nicoll)
Date: Sun, 25 Jun 2006 01:15:26 +0100
Subject: [Rxtx] Cannot create virtual serial port
Message-ID: <a1221cc50606241715g2d1e2af6r747347dd4c20e997@mail.gmail.com>

Hello,

This is my first post on this mailing list and I hope someone can help me.

I am having great difficult establishing a virtual serial port for the
Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia
7600.

Every time I try to run the SendMessage program that comes with SMSLib, I
get the following exception: gnu.io.NoSuchPortException

The port names I have tried are:
rfcomm0
rfcomm
/dev/rfcomm0
/dev/rfcomm

This is what I have done so far:
Modified /etc/bluetooth/rfcomm.conf to include the address of my phone:

rfcomm0 {
# Automatically bind the device at startup
bind no;

# Bluetooth address of the device
device 00:0e:6d:7a:98:43;

# RFCOMM channel for the connection
channel 1;

# Description of the connection
comment "Example Bluetooth device";
}

I also tried running the following command: rfcomm bind /dev/rfcomm0

I have searched the mailing list archives and found this post where someone
had a very similar problem to me:
http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried
changing the system properties as suggested and it made no difference.

I have also been scouring Google all day to no avail.

I would be incredibly grateful if anyone could give me some tips.

Thank you,

Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060625/cfa6df35/attachment-0010.html

From tjarvi at qbang.org  Sun Jun 25 19:56:08 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT)
Subject: [Rxtx] Pending release
Message-ID: <Pine.LNX.4.61.0606251942460.15744@www>


With frustration, I was unable to get to the pending release this weekend.
The release should be comming this next week once things calm down.
The source is in CVS except for a fix for multiple ports in windows.

I had planned on doing the release this weekend but that was disrupted by 
my transportation failing in a spectacular fashion.

--
Trent Jarvi
tjarvi at qbang.org


From Pawan.Kharbanda at dot.state.co.us  Tue Jun 27 22:28:51 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 27 Jun 2006 22:28:51 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>

 Trent, 
   I have an application running in a cluster in linux environment and I
am using RXTX2.1.7 (final) with JDK1.5. The application opens and closes
serial comm ports every 30 seconds and exchanges datas. I have
experienced some of my Comm Ports are left hanging (I can see the
LCK..cufXX lock files under /var/lock folder). On putting the debugs I
found out that, it is stuck at a native call line 809 in RXTXPort.java
class (Please see the code snippet below). Can you help me explain what
this method does in the native code? Am I getting into some thread
deadlocks? Thanks in advance.

Pawan Kharbanda 


public void removeEventListener()
	{
		if (debug)
			z.reportln( "RXTXPort:removeEventListener()
called");
		waitForTheNativeCodeSilly();
		//if( monThread != null && monThread.isAlive() )
		if( monThreadisInterrupted == true )
		{
			z.reportln( "	RXTXPort:removeEventListener()
already interrupted");
			monThread = null;
			SPEventListener = null;
			return;
		}
		else if( monThread != null && monThread.isAlive() )
		{
			if (debug)
				z.reportln( "
RXTXPort:Interrupt=true");
			monThreadisInterrupted=true;
			/*
			   Notify all threads in this PID that something
is up
			   They will call back to see if its their
thread
			   using isInterrupted().
			*/
			if (debug)
				z.reportln( "	RXTXPort:calling
interruptEventLoop");
// LINE 809			interruptEventLoop( ); It never returns
out of this 
			
			if (debug)
				z.reportln( "	RXTXPort:calling
monThread.join()");
			try {
				monThread.join(1000);
			} catch (Exception ex) {
				/* yikes */
				ex.printStackTrace();
			}
			if (debug)
				z.reportln( "	RXTXPort:waiting on
isAlive()");
			while( monThread.isAlive() )
			{
				if ( debug )
					z.reportln( "	MonThread is
still alive!");
				try {
					monThread.join(1000);
					Thread.sleep( 1000 );
				} catch( Exception e ){} 
				//monThread.stop();
			}
			
		}
		if (debug)
			z.reportln( "	RXTXPort:calling gc()");
		monThread = null;
		SPEventListener = null;
		MonitorThreadLock = false;
		MonitorThreadAlive=false;
		monThreadisInterrupted=true;
		z.reportln( "RXTXPort:removeEventListener() returning");
	} 

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Sunday, June 25, 2006 7:56 PM
To: rxtx at qbang.org
Subject: [Rxtx] Pending release


With frustration, I was unable to get to the pending release this
weekend.
The release should be comming this next week once things calm down.
The source is in CVS except for a fix for multiple ports in windows.

I had planned on doing the release this weekend but that was disrupted
by my transportation failing in a spectacular fashion.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Wed Jun 28 04:17:29 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 28 Jun 2006 04:17:29 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606280406330.9561@www>



Hi Pawan

You may have found a deadlock but I've not seen on recently on linux.

If you can, please update from CVS.  This will have some close fixes. 
I'm running with the same code as is in CVS.  It is not perfect but I've 
not seen anything like you mention.  Be sure to set timeouts and 
thresholds on the port.  It may be that the port is waiting on pending io 
that never happens.  I think the CVS patches deal with this also but it 
looks like your in a better test environment to know for sure.

The exploded vehicle mentioned below is expected to be fixed today.  It 
was just a ninja small radiator hose.  The pressure test afterwards 
created its own set of problems.  Until this is resolved, I'm spending 
most of my free time commuting by bicycle.

On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>   I have an application running in a cluster in linux environment and I
> am using RXTX2.1.7 (final) with JDK1.5. The application opens and closes
> serial comm ports every 30 seconds and exchanges datas. I have
> experienced some of my Comm Ports are left hanging (I can see the
> LCK..cufXX lock files under /var/lock folder). On putting the debugs I
> found out that, it is stuck at a native call line 809 in RXTXPort.java
> class (Please see the code snippet below). Can you help me explain what
> this method does in the native code? Am I getting into some thread
> deadlocks? Thanks in advance.
>
> Pawan Kharbanda
>
>
> public void removeEventListener()
> 	{
> 		if (debug)
> 			z.reportln( "RXTXPort:removeEventListener()
> called");
> 		waitForTheNativeCodeSilly();
> 		//if( monThread != null && monThread.isAlive() )
> 		if( monThreadisInterrupted == true )
> 		{
> 			z.reportln( "	RXTXPort:removeEventListener()
> already interrupted");
> 			monThread = null;
> 			SPEventListener = null;
> 			return;
> 		}
> 		else if( monThread != null && monThread.isAlive() )
> 		{
> 			if (debug)
> 				z.reportln( "
> RXTXPort:Interrupt=true");
> 			monThreadisInterrupted=true;
> 			/*
> 			   Notify all threads in this PID that something
> is up
> 			   They will call back to see if its their
> thread
> 			   using isInterrupted().
> 			*/
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> interruptEventLoop");
> // LINE 809			interruptEventLoop( ); It never returns
> out of this
>
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> monThread.join()");
> 			try {
> 				monThread.join(1000);
> 			} catch (Exception ex) {
> 				/* yikes */
> 				ex.printStackTrace();
> 			}
> 			if (debug)
> 				z.reportln( "	RXTXPort:waiting on
> isAlive()");
> 			while( monThread.isAlive() )
> 			{
> 				if ( debug )
> 					z.reportln( "	MonThread is
> still alive!");
> 				try {
> 					monThread.join(1000);
> 					Thread.sleep( 1000 );
> 				} catch( Exception e ){}
> 				//monThread.stop();
> 			}
>
> 		}
> 		if (debug)
> 			z.reportln( "	RXTXPort:calling gc()");
> 		monThread = null;
> 		SPEventListener = null;
> 		MonitorThreadLock = false;
> 		MonitorThreadAlive=false;
> 		monThreadisInterrupted=true;
> 		z.reportln( "RXTXPort:removeEventListener() returning");
> 	}
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Sunday, June 25, 2006 7:56 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] Pending release
>
>
> With frustration, I was unable to get to the pending release this
> weekend.
> The release should be comming this next week once things calm down.
> The source is in CVS except for a fix for multiple ports in windows.
>
> I had planned on doing the release this weekend but that was disrupted
> by my transportation failing in a spectacular fashion.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From Pawan.Kharbanda at dot.state.co.us  Wed Jun 28 12:11:06 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Wed, 28 Jun 2006 12:11:06 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>

Trent,
    Again thanks for the reply. First of all I have Receive timeouts set
on all communications including Max no of bytes to expect during the
call. I have noticed the problem is during "closing the connection". I
am not sure if the RXTX is 100% thread-safe yet. There seems to be a
glitch in the native calls. I am sure I have the latest code I did the
update on the Version 2.1.7 from CVS, is this where the latest updates
are located, I have noticed another version in CVS "rxtx-devel".

Regards
Pawan Kharbanda

    

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Wednesday, June 28, 2006 4:17 AM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports



Hi Pawan

You may have found a deadlock but I've not seen on recently on linux.

If you can, please update from CVS.  This will have some close fixes. 
I'm running with the same code as is in CVS.  It is not perfect but I've
not seen anything like you mention.  Be sure to set timeouts and
thresholds on the port.  It may be that the port is waiting on pending
io that never happens.  I think the CVS patches deal with this also but
it looks like your in a better test environment to know for sure.

The exploded vehicle mentioned below is expected to be fixed today.  It
was just a ninja small radiator hose.  The pressure test afterwards
created its own set of problems.  Until this is resolved, I'm spending
most of my free time commuting by bicycle.

On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>   I have an application running in a cluster in linux environment and 
> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and 
> closes serial comm ports every 30 seconds and exchanges datas. I have 
> experienced some of my Comm Ports are left hanging (I can see the 
> LCK..cufXX lock files under /var/lock folder). On putting the debugs I

> found out that, it is stuck at a native call line 809 in RXTXPort.java

> class (Please see the code snippet below). Can you help me explain 
> what this method does in the native code? Am I getting into some 
> thread deadlocks? Thanks in advance.
>
> Pawan Kharbanda
>
>
> public void removeEventListener()
> 	{
> 		if (debug)
> 			z.reportln( "RXTXPort:removeEventListener()
called");
> 		waitForTheNativeCodeSilly();
> 		//if( monThread != null && monThread.isAlive() )
> 		if( monThreadisInterrupted == true )
> 		{
> 			z.reportln( "	RXTXPort:removeEventListener()
> already interrupted");
> 			monThread = null;
> 			SPEventListener = null;
> 			return;
> 		}
> 		else if( monThread != null && monThread.isAlive() )
> 		{
> 			if (debug)
> 				z.reportln( "
> RXTXPort:Interrupt=true");
> 			monThreadisInterrupted=true;
> 			/*
> 			   Notify all threads in this PID that something
is up
> 			   They will call back to see if its their
thread
> 			   using isInterrupted().
> 			*/
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> interruptEventLoop");
> // LINE 809			interruptEventLoop( ); It never returns
> out of this
>
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> monThread.join()");
> 			try {
> 				monThread.join(1000);
> 			} catch (Exception ex) {
> 				/* yikes */
> 				ex.printStackTrace();
> 			}
> 			if (debug)
> 				z.reportln( "	RXTXPort:waiting on
> isAlive()");
> 			while( monThread.isAlive() )
> 			{
> 				if ( debug )
> 					z.reportln( "	MonThread is
> still alive!");
> 				try {
> 					monThread.join(1000);
> 					Thread.sleep( 1000 );
> 				} catch( Exception e ){}
> 				//monThread.stop();
> 			}
>
> 		}
> 		if (debug)
> 			z.reportln( "	RXTXPort:calling gc()");
> 		monThread = null;
> 		SPEventListener = null;
> 		MonitorThreadLock = false;
> 		MonitorThreadAlive=false;
> 		monThreadisInterrupted=true;
> 		z.reportln( "RXTXPort:removeEventListener() returning");
> 	}
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf

> Of Trent Jarvi
> Sent: Sunday, June 25, 2006 7:56 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] Pending release
>
>
> With frustration, I was unable to get to the pending release this 
> weekend.
> The release should be comming this next week once things calm down.
> The source is in CVS except for a fix for multiple ports in windows.
>
> I had planned on doing the release this weekend but that was disrupted

> by my transportation failing in a spectacular fashion.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Wed Jun 28 12:26:21 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 28 Jun 2006 12:26:21 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606281222420.9561@www>


Hi Pawan

If you did a cvs update from the 2.1-7 tar ball, you have the current 
version.  All rxtx in CVS is under rxtx-devel.  The 2.1-7 just has -r
commapi-0-0-1.

You may well have found something.  I have seen win32 fail on closing 
ports but not linux that I can think of.  Your use is much different than 
I normally see too.

Could you give us more information on how we would reproduce this and the 
frequency?


On Wed, 28 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>    Again thanks for the reply. First of all I have Receive timeouts set
> on all communications including Max no of bytes to expect during the
> call. I have noticed the problem is during "closing the connection". I
> am not sure if the RXTX is 100% thread-safe yet. There seems to be a
> glitch in the native calls. I am sure I have the latest code I did the
> update on the Version 2.1.7 from CVS, is this where the latest updates
> are located, I have noticed another version in CVS "rxtx-devel".
>
> Regards
> Pawan Kharbanda
>
>
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Wednesday, June 28, 2006 4:17 AM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] Locked Ports
>
>
>
> Hi Pawan
>
> You may have found a deadlock but I've not seen on recently on linux.
>
> If you can, please update from CVS.  This will have some close fixes.
> I'm running with the same code as is in CVS.  It is not perfect but I've
> not seen anything like you mention.  Be sure to set timeouts and
> thresholds on the port.  It may be that the port is waiting on pending
> io that never happens.  I think the CVS patches deal with this also but
> it looks like your in a better test environment to know for sure.
>
> The exploded vehicle mentioned below is expected to be fixed today.  It
> was just a ninja small radiator hose.  The pressure test afterwards
> created its own set of problems.  Until this is resolved, I'm spending
> most of my free time commuting by bicycle.
>
> On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:
>
>> Trent,
>>   I have an application running in a cluster in linux environment and
>> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and
>> closes serial comm ports every 30 seconds and exchanges datas. I have
>> experienced some of my Comm Ports are left hanging (I can see the
>> LCK..cufXX lock files under /var/lock folder). On putting the debugs I
>
>> found out that, it is stuck at a native call line 809 in RXTXPort.java
>
>> class (Please see the code snippet below). Can you help me explain
>> what this method does in the native code? Am I getting into some
>> thread deadlocks? Thanks in advance.
>>
>> Pawan Kharbanda
>>
>>
>> public void removeEventListener()
>> 	{
>> 		if (debug)
>> 			z.reportln( "RXTXPort:removeEventListener()
> called");
>> 		waitForTheNativeCodeSilly();
>> 		//if( monThread != null && monThread.isAlive() )
>> 		if( monThreadisInterrupted == true )
>> 		{
>> 			z.reportln( "	RXTXPort:removeEventListener()
>> already interrupted");
>> 			monThread = null;
>> 			SPEventListener = null;
>> 			return;
>> 		}
>> 		else if( monThread != null && monThread.isAlive() )
>> 		{
>> 			if (debug)
>> 				z.reportln( "
>> RXTXPort:Interrupt=true");
>> 			monThreadisInterrupted=true;
>> 			/*
>> 			   Notify all threads in this PID that something
> is up
>> 			   They will call back to see if its their
> thread
>> 			   using isInterrupted().
>> 			*/
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> interruptEventLoop");
>> // LINE 809			interruptEventLoop( ); It never returns
>> out of this
>>
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> monThread.join()");
>> 			try {
>> 				monThread.join(1000);
>> 			} catch (Exception ex) {
>> 				/* yikes */
>> 				ex.printStackTrace();
>> 			}
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:waiting on
>> isAlive()");
>> 			while( monThread.isAlive() )
>> 			{
>> 				if ( debug )
>> 					z.reportln( "	MonThread is
>> still alive!");
>> 				try {
>> 					monThread.join(1000);
>> 					Thread.sleep( 1000 );
>> 				} catch( Exception e ){}
>> 				//monThread.stop();
>> 			}
>>
>> 		}
>> 		if (debug)
>> 			z.reportln( "	RXTXPort:calling gc()");
>> 		monThread = null;
>> 		SPEventListener = null;
>> 		MonitorThreadLock = false;
>> 		MonitorThreadAlive=false;
>> 		monThreadisInterrupted=true;
>> 		z.reportln( "RXTXPort:removeEventListener() returning");
>> 	}
>>
>> -----Original Message-----
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
>
>> Of Trent Jarvi
>> Sent: Sunday, June 25, 2006 7:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] Pending release
>>
>>
>> With frustration, I was unable to get to the pending release this
>> weekend.
>> The release should be comming this next week once things calm down.
>> The source is in CVS except for a fix for multiple ports in windows.
>>
>> I had planned on doing the release this weekend but that was disrupted
>
>> by my transportation failing in a spectacular fashion.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From Pawan.Kharbanda at dot.state.co.us  Wed Jun 28 15:42:49 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Wed, 28 Jun 2006 15:42:49 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>

Trent,
    I will try to explain how I am setup and will try to write you a
Sample code little later to reproduce this. On our system we have
DigiBoxes installed on the 2 Linux servers. Both of them have RXTX2.1-7
version installed with the JRE(1.5) and both the machines have the same
port mappings in gnu.io.rxtx.properties (Currently in the production
system I have 64 ports). This is how the system works:

1) A thick Map based client initiates a Action on the Device on the
field. One of the Thread Workers(Asynchronous Call) in the Cluster picks
up the request. 
2) Once the worker gets the request it locks the Device and
Communication port in the DB's(These are our persistent locks, because
most of the devices do one to one communication with the serial ports).
After that the worker (or Comm Server) opens up the connection and after
exchanging the information calls the "Close" and returns.
3) Once the connection is closed , the DB lock is removed on the comm
port and is made available to accept future calls. Here is where the
glitch is the Serial Comm Close method never returns due to the
deadlock. 

I have noticed that the deadlocks are very inconsistent, sometime it
happens right away as soon as Application server starts and sometimes I
don't see any deadlocks for days, but it happens for sure. 

Here is how you can test if you have resources/ test environment. Write
a program and try to open/close  different ports(I will say have a
minimum of four) randomly and very frequently(may be 30 seconds), I am
pretty sure you will see the deadlocks and it happens in the native call
to interrptEventLoop in RXTXPort.java in removeEventListener() method
call.

Also I have noticed that the JVM carshes (without any memrory errors or
JVM errors. Its just not there) when native call is made to eventLoop()
in run() method in MonitorThread inner class. I am still investigating
why this is happening, but at this point I can just tell you the
location. You might have a question How I am so sure about the location?
My application is configured with Log4J and I have enabled the debugs on
the RXTXPort.java, so every time my JVM dies I see these logs at the end
of the file.

"2006-06-28 15:27:15,183 INFO  [STDOUT] RXTXPort:RXTXPort(/dev/cub01)
called
2006-06-28 15:27:15,218 INFO  [STDOUT]
RXTXPort:MontitorThread:MonitorThread()
2006-06-28 15:27:15,219 INFO  [STDOUT] RXTXPort:MontitorThread:run()"

I surely do have a luxury of a testing environment(ports, devices etc.)
and can help you fix these problems? Please advise me how we can resolve
these issues.

Thanks 
Pawan Kharbanda
303-478-2991





-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Wednesday, June 28, 2006 12:26 PM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports


Hi Pawan

If you did a cvs update from the 2.1-7 tar ball, you have the current
version.  All rxtx in CVS is under rxtx-devel.  The 2.1-7 just has -r
commapi-0-0-1.

You may well have found something.  I have seen win32 fail on closing
ports but not linux that I can think of.  Your use is much different
than I normally see too.

Could you give us more information on how we would reproduce this and
the frequency?


On Wed, 28 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>    Again thanks for the reply. First of all I have Receive timeouts
set
> on all communications including Max no of bytes to expect during the
> call. I have noticed the problem is during "closing the connection". I
> am not sure if the RXTX is 100% thread-safe yet. There seems to be a
> glitch in the native calls. I am sure I have the latest code I did the
> update on the Version 2.1.7 from CVS, is this where the latest updates
> are located, I have noticed another version in CVS "rxtx-devel".
>
> Regards
> Pawan Kharbanda
>
>
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Wednesday, June 28, 2006 4:17 AM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] Locked Ports
>
>
>
> Hi Pawan
>
> You may have found a deadlock but I've not seen on recently on linux.
>
> If you can, please update from CVS.  This will have some close fixes.
> I'm running with the same code as is in CVS.  It is not perfect but
I've
> not seen anything like you mention.  Be sure to set timeouts and
> thresholds on the port.  It may be that the port is waiting on pending
> io that never happens.  I think the CVS patches deal with this also
but
> it looks like your in a better test environment to know for sure.
>
> The exploded vehicle mentioned below is expected to be fixed today.
It
> was just a ninja small radiator hose.  The pressure test afterwards
> created its own set of problems.  Until this is resolved, I'm spending
> most of my free time commuting by bicycle.
>
> On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:
>
>> Trent,
>>   I have an application running in a cluster in linux environment and
>> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and
>> closes serial comm ports every 30 seconds and exchanges datas. I have
>> experienced some of my Comm Ports are left hanging (I can see the
>> LCK..cufXX lock files under /var/lock folder). On putting the debugs
I
>
>> found out that, it is stuck at a native call line 809 in
RXTXPort.java
>
>> class (Please see the code snippet below). Can you help me explain
>> what this method does in the native code? Am I getting into some
>> thread deadlocks? Thanks in advance.
>>
>> Pawan Kharbanda
>>
>>
>> public void removeEventListener()
>> 	{
>> 		if (debug)
>> 			z.reportln( "RXTXPort:removeEventListener()
> called");
>> 		waitForTheNativeCodeSilly();
>> 		//if( monThread != null && monThread.isAlive() )
>> 		if( monThreadisInterrupted == true )
>> 		{
>> 			z.reportln( "	RXTXPort:removeEventListener()
>> already interrupted");
>> 			monThread = null;
>> 			SPEventListener = null;
>> 			return;
>> 		}
>> 		else if( monThread != null && monThread.isAlive() )
>> 		{
>> 			if (debug)
>> 				z.reportln( "
>> RXTXPort:Interrupt=true");
>> 			monThreadisInterrupted=true;
>> 			/*
>> 			   Notify all threads in this PID that something
> is up
>> 			   They will call back to see if its their
> thread
>> 			   using isInterrupted().
>> 			*/
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> interruptEventLoop");
>> // LINE 809			interruptEventLoop( ); It never returns
>> out of this
>>
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> monThread.join()");
>> 			try {
>> 				monThread.join(1000);
>> 			} catch (Exception ex) {
>> 				/* yikes */
>> 				ex.printStackTrace();
>> 			}
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:waiting on
>> isAlive()");
>> 			while( monThread.isAlive() )
>> 			{
>> 				if ( debug )
>> 					z.reportln( "	MonThread is
>> still alive!");
>> 				try {
>> 					monThread.join(1000);
>> 					Thread.sleep( 1000 );
>> 				} catch( Exception e ){}
>> 				//monThread.stop();
>> 			}
>>
>> 		}
>> 		if (debug)
>> 			z.reportln( "	RXTXPort:calling gc()");
>> 		monThread = null;
>> 		SPEventListener = null;
>> 		MonitorThreadLock = false;
>> 		MonitorThreadAlive=false;
>> 		monThreadisInterrupted=true;
>> 		z.reportln( "RXTXPort:removeEventListener() returning");
>> 	}
>>
>> -----Original Message-----
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On
Behalf
>
>> Of Trent Jarvi
>> Sent: Sunday, June 25, 2006 7:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] Pending release
>>
>>
>> With frustration, I was unable to get to the pending release this
>> weekend.
>> The release should be comming this next week once things calm down.
>> The source is in CVS except for a fix for multiple ports in windows.
>>
>> I had planned on doing the release this weekend but that was
disrupted
>
>> by my transportation failing in a spectacular fashion.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx 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 khattar31 at yahoo.com  Wed Jun 28 22:04:59 2006
From: khattar31 at yahoo.com (rahul khattar)
Date: Wed, 28 Jun 2006 21:04:59 -0700 (PDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
Message-ID: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>

Hi All,

I was looking at the src file on the last release.
I did notice a missing header file while trying to
compile the parallelport.dll. Would somebody be kind
enoughf to share the missing header file:
gnu_io_LPRPort.h

I am using MinGw to compile the same from Parinya
(which is an execellent tool)


Regards,
Rahul Khattar

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Thu Jun 29 03:43:53 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 03:43:53 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>
References: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606290341210.9561@www>

On Wed, 28 Jun 2006, rahul khattar wrote:

> Hi All,
>
> I was looking at the src file on the last release.
> I did notice a missing header file while trying to
> compile the parallelport.dll. Would somebody be kind
> enoughf to share the missing header file:
> gnu_io_LPRPort.h
>
> I am using MinGw to compile the same from Parinya
> (which is an execellent tool)
>

Hi Rahul

The gnu.io_LPRPort.h file is generated with javah.  You can see the 
command in the Makefile I presume.  You do not need rxtxParallel.dll to 
use w32 serial btw.

--
Trent Jarvi
tjarvi at qbang.org


From khattar31 at yahoo.com  Thu Jun 29 04:47:01 2006
From: khattar31 at yahoo.com (rahul khattar)
Date: Thu, 29 Jun 2006 03:47:01 -0700 (PDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606290341210.9561@www>
Message-ID: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>

Hi Trent 
I did notice this file is required in the source file
ParallelImp.c
on line 38

Attached the O/P 

Regards,
Rahul Khattar




--- Trent Jarvi <tjarvi at qbang.org> wrote:

> On Wed, 28 Jun 2006, rahul khattar wrote:
> 
> > Hi All,
> >
> > I was looking at the src file on the last release.
> > I did notice a missing header file while trying to
> > compile the parallelport.dll. Would somebody be
> kind
> > enoughf to share the missing header file:
> > gnu_io_LPRPort.h
> >
> > I am using MinGw to compile the same from Parinya
> > (which is an execellent tool)
> >
> 
> Hi Rahul
> 
> The gnu.io_LPRPort.h file is generated with javah. 
> You can see the 
> command in the Makefile I presume.  You do not need
> rxtxParallel.dll to 
> use w32 serial btw.
> 
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Error.zip
Type: application/x-zip-compressed
Size: 1746 bytes
Desc: 2948039066-Error.zip
Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060629/a5b6f783/Error-0019.bin

From tjarvi at qbang.org  Thu Jun 29 06:16:24 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 06:16:24 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606290614530.9561@www>

On Thu, 29 Jun 2006, rahul khattar wrote:

> Hi Trent
> I did notice this file is required in the source file
> ParallelImp.c
> on line 38
>
> Attached the O/P
>

The command to generate the .h file will be something like:

javah -classpath . -jni gnu.io.LPRPort

The makefile should have this.  There are several approaches to creating 
or using makefiles so I have no idea which one you used if any.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Thu Jun 29 06:20:51 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 06:20:51 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606290616420.9561@www>

> Here is how you can test if you have resources/ test environment. Write
> a program and try to open/close  different ports(I will say have a
> minimum of four) randomly and very frequently(may be 30 seconds), I am
> pretty sure you will see the deadlocks and it happens in the native call
> to interrptEventLoop in RXTXPort.java in removeEventListener() method
> call.

Hi Pawan

I'll try to find a way to reproduce this.  One thing to note is that you 
are using different kernel drivers (digi) to perform this task.  So I 
probably will not be able to reproduce the exact same environment.

In general, multiport kernel drivers have been tested far less than 
typical serial drivers.  This may or may not be an issue.

--
Trent Jarvi
tjarvi at qbang.org



From jhaysonn at gmail.com  Thu Jun 29 12:29:13 2006
From: jhaysonn at gmail.com (jhaysonn pathak)
Date: Thu, 29 Jun 2006 14:29:13 -0400
Subject: [Rxtx] RXTX install
Message-ID: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>

Hi Guys,

I'm doing trying to write a generative piece of Sonic Art using an EEG
plugged into a mac runnning Max/MSP.  I just recently discovered RXTX
drivers in my search for a piece of software that might give me more
output options for my EEG (I'm using the CEO from MindPeak).  I found
Bioera which uses RXTX drivers.  Thing is - I can't figure out how to
install RXTX correctly.

After I build the 'libSerial.jnilib' target inside of
'LibSerial.pbproj' I can't find the libSerial.jnilib file that
accompanies the RXTXcomm.jar nor do I know where to put them.

I also don't understand this part at the bottom of the OS X instructions at all:

"AFTER INSTALLATION VERY IMPORTANT
	check existence of the folder /var/spool/uucp
	if you don't have it create it with command
	sudo mkdir /var/spool/uucp
	permissions should be: drwxrwxr-x
	if they are not do command
	sudo chmod 775 /var/spool/uucp

	YOU should be a member of the uucp group
	you can check it with command
		niutil -readprop / /groups/uucp users
	you should see your name in output of the niutil command
	if you don't do following:
		sudo niutil -appendprop / /groups/uucp users <yourname>
			substitute  <yourname> with your user's name
			for example if your user name is peter:
				sudo niutil -appendprop / /groups/uucp users peter

	NOTES: RXTX.pkg should create uucp folder and insert your name  in
uucp group automatically"



I really appreciate any help that you guys can offer.  I've been
struggling with this for a while now as part of a research grant that
I was awarded.  Thanks again for the help.

Jhaysonn Pathak


From naranjo.manuel at gmail.com  Thu Jun 29 07:19:15 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 10:19:15 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606290614530.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www>
Message-ID: <44A3D353.6010605@gmail.com>

Speaking about Windows Support, I had seen that inside the 
rxtx-2.1-7-bins-r2 package inside Windows directory it says:
"i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will 
not make harm to anyone, and i'm almost sure that someone has noticed it 
before.
Cheers,
Manuel


From joachim at buechse.de  Thu Jun 29 13:25:16 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 29 Jun 2006 21:25:16 +0200
Subject: [Rxtx] RXTX install
In-Reply-To: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>
References: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>
Message-ID: <2A003E42-97E1-4237-8438-646BDE2E3961@buechse.de>

Hello Jhaysonn,

I assume you are trying to use the javax.comm version of RXTX.

Please use "cvs up" to update your download to the latest version of  
the repository. The latest version does not use lock files, so the  
mentioned process is no longer needed. Updating with CVS will also  
provide you with a new README.OSX file that should be simpler to  
understand.

You will find LibSerialUniversal.xcodeproj in MACOSX_IDE/Xcode. Put  
comm.jar (downloaded from Sun) into MACOSX_IDE/Xcode. Compile the  
library. You will find RXTXcomm.jar and librxtxSerial.jnilib in  
MACOSX_IDE/Xcode/build/Default

Best regards,
Joachim
---
Joachim B?chse
Softwarel?sungen und Beratung
Hadlaubsteig 2
CH-8006 Z?rich


On 29.06.2006, at 20:29, jhaysonn pathak wrote:

> Hi Guys,
>
> I'm doing trying to write a generative piece of Sonic Art using an EEG
> plugged into a mac runnning Max/MSP.  I just recently discovered RXTX
> drivers in my search for a piece of software that might give me more
> output options for my EEG (I'm using the CEO from MindPeak).  I found
> Bioera which uses RXTX drivers.  Thing is - I can't figure out how to
> install RXTX correctly.
>
> After I build the 'libSerial.jnilib' target inside of
> 'LibSerial.pbproj' I can't find the libSerial.jnilib file that
> accompanies the RXTXcomm.jar nor do I know where to put them.
>
> I also don't understand this part at the bottom of the OS X  
> instructions at all:
>
> "AFTER INSTALLATION VERY IMPORTANT
> 	check existence of the folder /var/spool/uucp
> 	if you don't have it create it with command
> 	sudo mkdir /var/spool/uucp
> 	permissions should be: drwxrwxr-x
> 	if they are not do command
> 	sudo chmod 775 /var/spool/uucp
>
> 	YOU should be a member of the uucp group
> 	you can check it with command
> 		niutil -readprop / /groups/uucp users
> 	you should see your name in output of the niutil command
> 	if you don't do following:
> 		sudo niutil -appendprop / /groups/uucp users <yourname>
> 			substitute  <yourname> with your user's name
> 			for example if your user name is peter:
> 				sudo niutil -appendprop / /groups/uucp users peter
>
> 	NOTES: RXTX.pkg should create uucp folder and insert your name  in
> uucp group automatically"
>
>
>
> I really appreciate any help that you guys can offer.  I've been
> struggling with this for a while now as part of a research grant that
> I was awarded.  Thanks again for the help.
>
> Jhaysonn Pathak
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From tjarvi at qbang.org  Thu Jun 29 19:30:00 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 19:30:00 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A3D353.6010605@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
Message-ID: <Pine.LNX.4.61.0606291923000.9561@www>

On Thu, 29 Jun 2006, Manuel Naranjo wrote:

> Speaking about Windows Support, I had seen that inside the
> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
> not make harm to anyone, and i'm almost sure that someone has noticed it
> before.

Hi Manuel

         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
     47421  01-30-06 00:23 
rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
     77759  03-01-06 12:01 
rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README


It looks normal to me.  There are no fancy tools used there :)

--
Trent Jarvi
tjarvi at qbang.org

From naranjo.manuel at gmail.com  Thu Jun 29 19:38:16 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 22:38:16 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606291923000.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com> <Pine.LNX.4.61.0606291923000.9561@www>
Message-ID: <44A48088.2040407@gmail.com>

> On Thu, 29 Jun 2006, Manuel Naranjo wrote:
> 
>> Speaking about Windows Support, I had seen that inside the
>> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
>> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
>> not make harm to anyone, and i'm almost sure that someone has noticed it
>> before.
> 
> Hi Manuel
> 
>         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
>         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
>     47421  01-30-06 00:23 
> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
>     77759  03-01-06 12:01 
> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
>       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README
> 
> 
> It looks normal to me.  There are no fancy tools used there :)
> 
Hi Trent:
Is not the i368 representing the name of the Architecture?? If so the 
name should start with i386 it will not break any system, is simply miss
written, I saw that and wanted to report it. It a silly thing.
Ohh I forgoten I must congratulate you for your GREAT libray, I was able 
to make an .exe with JSmooth that launches an application that uses RXTX 
with out the need to install RXTX on users system :). The .exe tells JVM 
where to find the RXTX Library and Binaries. I tried with Sun's Java 
Comm but it was imposible.
Regards,
Manuel


From tjarvi at qbang.org  Thu Jun 29 19:52:45 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 19:52:45 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A48088.2040407@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
	<Pine.LNX.4.61.0606291923000.9561@www> <44A48088.2040407@gmail.com>
Message-ID: <Pine.LNX.4.61.0606291945060.9561@www>

On Thu, 29 Jun 2006, Manuel Naranjo wrote:

>> On Thu, 29 Jun 2006, Manuel Naranjo wrote:
>>
>>> Speaking about Windows Support, I had seen that inside the
>>> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
>>> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
>>> not make harm to anyone, and i'm almost sure that someone has noticed it
>>> before.
>>
>> Hi Manuel
>>
>>         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
>>         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
>>     47421  01-30-06 00:23
>> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
>>     77759  03-01-06 12:01
>> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
>>       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README
>>
>>
>> It looks normal to me.  There are no fancy tools used there :)
>>
> Hi Trent:
> Is not the i368 representing the name of the Architecture?? If so the
> name should start with i386 it will not break any system, is simply miss
> written, I saw that and wanted to report it. It a silly thing.
> Ohh I forgoten I must congratulate you for your GREAT libray, I was able
> to make an .exe with JSmooth that launches an application that uses RXTX
> with out the need to install RXTX on users system :). The .exe tells JVM
> where to find the RXTX Library and Binaries. I tried with Sun's Java
> Comm but it was imposible.

Hi Manuel

The compiler uses only the i386 instruction set for windows.  I doubt 
there will be any measurable advantages with going to later instruction 
sets.  In theory rxtx would run on a 386 but I doubt anyone does that.

So it looks odd but is not a typo.

We could compile to i686 but don't.  The compiler used does not appear to 
be a problem yet so I don't see any point in changing it.  Right now, we 
could not compile 64 bit windows binaries.  gcc/mingw/... do not support 
them that I know of.  People will have to compile those with closed source 
tools on their own until an option is available.

--
Trent Jarvi
tjarvi at qbang.org

From naranjo.manuel at gmail.com  Thu Jun 29 20:00:48 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 23:00:48 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606291945060.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com>	<Pine.LNX.4.61.0606291923000.9561@www>
	<44A48088.2040407@gmail.com> <Pine.LNX.4.61.0606291945060.9561@www>
Message-ID: <44A485D0.7050202@gmail.com>

Trent you did not get my point
The folder says 368 three hundred sixty eight, when
it should say 386 three hundred eighty six. Is simply a miss writting.
Regards,
Manuel


From tjarvi at qbang.org  Thu Jun 29 20:12:15 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 20:12:15 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A485D0.7050202@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
	<Pine.LNX.4.61.0606291923000.9561@www> <44A48088.2040407@gmail.com>
	<Pine.LNX.4.61.0606291945060.9561@www> <44A485D0.7050202@gmail.com>
Message-ID: <Pine.LNX.4.61.0606292008061.9561@www>


On Thu, 29 Jun 2006, Manuel Naranjo wrote:

> Trent you did not get my point
> The folder says 368 three hundred sixty eight, when
> it should say 386 three hundred eighty six. Is simply a miss writting.

hehe..  OK.  My bad.  It's been a long day.

Nevermind :)

--
Trent Jarvi
tjarvi at qbang.org




From naranjo.manuel at gmail.com  Thu Jun 29 20:18:44 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 23:18:44 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606292008061.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com>	<Pine.LNX.4.61.0606291923000.9561@www>
	<44A48088.2040407@gmail.com>	<Pine.LNX.4.61.0606291945060.9561@www>
	<44A485D0.7050202@gmail.com> <Pine.LNX.4.61.0606292008061.9561@www>
Message-ID: <44A48A04.9040401@gmail.com>

Don't worry Trent.
About 64 bits compilation, I would like to colaborate, I have a Pc with 
64 bits, the only problem is that i do not have windows 64 bits 
installed :(.




From Pawan.Kharbanda at dot.state.co.us  Fri Jun 30 08:49:52 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 30 Jun 2006 08:49:52 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E996@hqexchange3.dot.state.co.us>

Trent,  
    Can you explain what the interruptedEventLoop() native method is
doing is there a possibility that method is somehow getting into the
infinite loop(there are 2 while loops without any break statements).
This might be a very basic question how can I debug the native code(or
print the debug statements).  Again thanks for the help. 

Pawan Kharbanda

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Thursday, June 29, 2006 6:21 AM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports

> Here is how you can test if you have resources/ test environment. 
> Write a program and try to open/close  different ports(I will say have

> a minimum of four) randomly and very frequently(may be 30 seconds), I 
> am pretty sure you will see the deadlocks and it happens in the native

> call to interrptEventLoop in RXTXPort.java in removeEventListener() 
> method call.

Hi Pawan

I'll try to find a way to reproduce this.  One thing to note is that you
are using different kernel drivers (digi) to perform this task.  So I
probably will not be able to reproduce the exact same environment.

In general, multiport kernel drivers have been tested far less than
typical serial drivers.  This may or may not be an issue.

--
Trent Jarvi
tjarvi at qbang.org

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From cpine at wrsystems.com  Thu Jun 29 15:17:12 2006
From: cpine at wrsystems.com (Chris Pine)
Date: Thu, 29 Jun 2006 17:17:12 -0400
Subject: [Rxtx]  Controlling Individual Signals DTR and RTS
Message-ID: <MAIL4FJo0S8ACLEBajJ000005cf@mail4.wrsystems.com>

Dear Moussa Ba,
	I hope I am not being too forward, but we are having the exact same
issue with needing to control DTR from RXTX in Linux.  Did you ever have any
luck figuring it out?

Thank you very much for your time,

Chris Pine




From tjarvi at qbang.org  Thu Jun  1 11:13:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 11:13:40 -0600 (MDT)
Subject: [Rxtx] custom baud rate win32
In-Reply-To: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606011107210.30220@www>


Hi Daren

I can't imagine that 1953 is possibly the actual value on the UART.  Maybe 
if your baud base is very high with a custom serial board.  More likely, 
the driver just remembers that what you asked for and did something else.

I'll have more to say on the dcb->BaudRate after I try some things here. 
I have managed to do something like that in the past as a quick hack but 
it was for 14400.  I may have used the CBR_14400.

If we can't access this through the win32 API with protected mode, there 
is another layer of complication.  With real mode, it would be easy.
With protected mode, I assume there would have to be some kernel driver or 
a hook I'm not aware of to access the MCR directly (bang a memory 
addresss).



On Thu, 1 Jun 2006, Daren wrote:

> Trent,
> I have managed to successfully open the port at this speed using Realterm
> (available on sourceforge). From memory this uses DLPortIO.
>
> Using portmon.exe with realterm, even there it says that the port has opened
> at 1953.
>
> I changed termios.c:560 to
> dcb->BaudRate        = 1953 ;
>
> and it still opens the port at 9600.
>
> Daren
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Trent Jarvi
> Sent: Thursday, 1 June 2006 1:44 PM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] custom baud rate win32
>
> On Thu, 1 Jun 2006, Daren wrote:
>
>> Hi all,
>>
>> I downloaded 2.1.7-pre16 and managed to build it and get it going. I made
>> the changes as suggested by Peter Smith in an old post, by adding his code
>> to SerialImpl.c, uncommenting the TIOCGSERIAL and TIOCSSERIAL, and
> defining
>> ASYNC_SPD_CUST which is equal to 0x0030 (according to linus header
> files)..
>>
>>
>> Still not working, it opens the port at 9600 according to portmon.exe .
> Has
>> anyone managed to get this going at a custom rate?
>>
>> Here is the post I'm referring to:
>> http://marc.theaimsgroup.com/?l=rxtx&m=106270038110713&w=2
>>
>>
>> Thanks,
>> Daren
>>
>> ________________________________________
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
>> Daren
>> Sent: Wednesday, 31 May 2006 10:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] (no subject)
>>
>> Hi All,
>> I have been using rxtx for a little while and needed to get it working at
>> 1953, like a past user in the mailing list, who seemed to have got it
>> working by changing some C code.
>>
>> I wanted to build rxtx myself with these changes but don't know where to
>> start. I have windows here and FC4 at home. I downloaded cygwin and
> mingw32,
>> each build works by building a rxtxSerial.dll file that is ~11k smaller
> than
>> the original, and I always get the following error when testing the dll:
>>
>> Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at
>> PC=0x8077655
>> Function=[Unknown.]
>> Library=C:\opt\java\j2sdk1.4.2\jre\bin\client\jvm.dll
>>
>> NOTE: We are unable to locate the function name symbol for the error
>>      just occurred. Please refer to release documentation for possible
>>      reason and solutions.
>>
>>
>> Current Java thread:
>> 	at gnu.io.RXTXPort.open(Native Method)
>> 	- locked <0x1002c800> (a gnu.io.RXTXPort)
>> 	at gnu.io.RXTXPort.<init>(RXTXPort.java:84)
>>
>> Anyone know what im doing wrong?
>>
>>
>>
>>
>
> Hi Daren
>
> You are running into the same rats nest I'm looking at now.
>
> With win32 and specific custom baud rates, I'm not sure how this will go.
> I've got the Linux custom baud rates working very nicely.  I did much like
> the post you linked.  In fact I had forgot about that post.  You probably
> noticed that it becomes a bunch of dirt roads going noplace fast in
> termios.c for w32.
>
> I'm probably only going to get 14400, 28800, 128000 and 256000 working
> with the next release on w32.  I'll look a little further.  If you have an
> example w32 that works at 1953 I'd really like to hear.  Thats an unusual
> baud rate.
>
> Assuming a baud_base of 128000, your divisor will be 65 or 66.
>
> 128000/66=1939 -14
> 128000/65=1969 +13
>
> One thing I've been wondering about with linux is which would be the right
> answer in cases like this.  Right now it would just go with a baud base of
> 65 and ignore the modulus details.
>
> It appears to be a general trend for kernel developers to hide these
> details thinking that they can come up with a general solution.  Then they
> run out of time.  Perahps the solution is to help out but there are
> ultiple OS's rxtx supports making that nontrivial.
>
> If you look at current linux kernels, the 'tricks' above have been marked
> deprecated with no replacement.  Windows has some hard defines and then
> ancient near magic.  I've not looked at Solaris via Open Solaris yet but
> doubt there is a solution at all.
>
> What I'd try since you have the equipment and the monitor software is to
> hardcode the dcb->Baud in termios.c to 1953 (no define) and see what the
> w32 kernel does with it.  I think if you toss a baud rate at the driver it
> will try to come close.  You may try comming closer to a real baudrate
> based upon the 128000 baud base as shown above.
>
> If it works, it is worth looking at the rest of the ping/pong logic then.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
>
>
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From doug at dupreeinc.com  Thu Jun  1 13:22:13 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 12:22:13 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011107210.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
Message-ID: <447F3E65.1020809@dupreeinc.com>

Hello,

I am still trying to get this startup a little faster so I turned on the 
debug of a few of the classes.  The COM ports are scanned really fast 
and the delay occurs during the LPT scan.  The console output looks like 
this:

    ...
      LPT1
      LPT2
      LPT3
     valid port prefixes:
      LPT
    LPT1 LPT
    1 1
    LPT2 LPT
    2 2                                                                 
      * <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
    CommPortIdentifier:addPortName(LPT2)
    CommPortIdentifier:AddIdentifierToList()
    LPT3 LPT
    3 3
    CommPortIdentifier:addPortName(LPT3)
    CommPortIdentifier:AddIdentifierToList()
    CommPortIdentifier:AddIdentifierToList() index.next
    Leaving registerValidPorts()
    Have not implemented native_psmisc_report_owner(PortName)); in
    CommPortIdentifier
    CommPortIdentifier:getPortIdentifier(COM3)
    CommPortIdentifier:open(densConnect, 30000)
    RXTXCommDriver:getCommPort(COM3,1)
    ...

It would seem to me that if I removed the code for port scanning of LPT 
ports I could solve this problem. I would much prefer to use unmodified 
code if at all possible.  Do any of you have alternate suggestions?

Thank you for your time.

Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/cf433ee7/attachment-0020.html

From tjarvi at qbang.org  Thu Jun  1 13:52:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 13:52:06 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F3E65.1020809@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011348380.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I am still trying to get this startup a little faster so I turned on the 
> debug of a few of the classes.  The COM ports are scanned really fast and the 
> delay occurs during the LPT scan.  The console output looks like this:
>
>   ...
>     LPT1
>     LPT2
>     LPT3
>    valid port prefixes:
>     LPT
>   LPT1 LPT
>   1 1
>   LPT2 LPT
>   2 2                                                                      * 
> <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>   CommPortIdentifier:addPortName(LPT2)
>   CommPortIdentifier:AddIdentifierToList()
>   LPT3 LPT
>   3 3
>   CommPortIdentifier:addPortName(LPT3)
>   CommPortIdentifier:AddIdentifierToList()
>   CommPortIdentifier:AddIdentifierToList() index.next
>   Leaving registerValidPorts()
>   Have not implemented native_psmisc_report_owner(PortName)); in
>   CommPortIdentifier
>   CommPortIdentifier:getPortIdentifier(COM3)
>   CommPortIdentifier:open(densConnect, 30000)
>   RXTXCommDriver:getCommPort(COM3,1)
>   ...
>
> It would seem to me that if I removed the code for port scanning of LPT ports 
> I could solve this problem. I would much prefer to use unmodified code if at 
> all possible.  Do any of you have alternate suggestions?
>
> Thank you for your time.
>
> Doug
>


Does commenting out the LPT enumeration actually help?  There can often be 
differences between debug information printed and whats really going on. 
When you combine various environments the debug info can even come out in 
the wrong order.

I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
I do not think this problem is universal.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Thu Jun  1 14:29:44 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:29:44 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4E38.2060004@dupreeinc.com>

I will give it a try.  One thing to note on this PC is it has no LPT 
Parallel ports.

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
>>Hello,
>>
>>I am still trying to get this startup a little faster so I turned on the 
>>debug of a few of the classes.  The COM ports are scanned really fast and the 
>>delay occurs during the LPT scan.  The console output looks like this:
>>
>>  ...
>>    LPT1
>>    LPT2
>>    LPT3
>>   valid port prefixes:
>>    LPT
>>  LPT1 LPT
>>  1 1
>>  LPT2 LPT
>>  2 2                                                                      * 
>><<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>>  CommPortIdentifier:addPortName(LPT2)
>>  CommPortIdentifier:AddIdentifierToList()
>>  LPT3 LPT
>>  3 3
>>  CommPortIdentifier:addPortName(LPT3)
>>  CommPortIdentifier:AddIdentifierToList()
>>  CommPortIdentifier:AddIdentifierToList() index.next
>>  Leaving registerValidPorts()
>>  Have not implemented native_psmisc_report_owner(PortName)); in
>>  CommPortIdentifier
>>  CommPortIdentifier:getPortIdentifier(COM3)
>>  CommPortIdentifier:open(densConnect, 30000)
>>  RXTXCommDriver:getCommPort(COM3,1)
>>  ...
>>
>>It would seem to me that if I removed the code for port scanning of LPT ports 
>>I could solve this problem. I would much prefer to use unmodified code if at 
>>all possible.  Do any of you have alternate suggestions?
>>
>>Thank you for your time.
>>
>>Doug
>>
>>    
>>
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/dd31fed5/attachment-0020.html

From doug at dupreeinc.com  Thu Jun  1 14:36:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:36:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4FC8.9080106@dupreeinc.com>

Trent,

I commented out the section in RegisterScannedPorts() that adds the 
three LPT ports to the CandidateDeviceNames string array.  The 
application started immediately.  This is probably not the way to do 
this, but it was quick ,dirty, and worked.

It would be nice if there was a way to pole the OS to see if there is 
even a port there, though I guess this is what this code is suppose to do...

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
> ...
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From lynn at swcp.com  Thu Jun  1 14:49:34 2006
From: lynn at swcp.com (lynn@swcp.com)
Date: Thu, 1 Jun 2006 20:49:34 -0000
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>,
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <twig.1149194974.97617@swcp.com>

Perhaps we could add an argument to port enumeration where if not specified,
you get the default behavior that looks for everything.  With a new
constructor that has an argument(or more) you could optionally declare it to
not inspect printer ports.

Existing code would work as it always has.  New code could be smarter.

Lynn



Doug Thistlethwaite <doug at dupreeinc.com> said:

> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
> >On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
> >
> >  
> >
> > ...
> >
> >
> >Does commenting out the LPT enumeration actually help?  There can often be 
> >differences between debug information printed and whats really going on. 
> >When you combine various environments the debug info can even come out in 
> >the wrong order.
> >
> >I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
> >I do not think this problem is universal.
> >
> >--
> >Trent Jarvi
> >tjarvi at qbang.org
> >_______________________________________________
> >Rxtx mailing list
> >Rxtx at qbang.org
> >http://mailman.qbang.org/mailman/listinfo/rxtx
> >
> >
> >  
> >
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



-- 





From jredman at ergotech.com  Thu Jun  1 15:20:20 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 01 Jun 2006 15:20:20 -0600
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
Message-ID: <447F5A14.6010803@ergotech.com>

Doug,

If you specifically request ports, eg:

-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

or
 
-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

Depending upon the version  (Windows is COM1:COM2, etc. I assume).

Does it still enumerate the parallel ports?

Jim

Doug Thistlethwaite wrote:
> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
>> On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>
>>  
>>
>> ...
>>
>>
>> Does commenting out the LPT enumeration actually help?  There can often be 
>> differences between debug information printed and whats really going on. 
>> When you combine various environments the debug info can even come out in 
>> the wrong order.
>>
>> I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>> I do not think this problem is universal.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>>
>>  
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  1 16:49:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:49:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6EF4.7080709@dupreeinc.com>

I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
folder.  I created this file and added the following to the file:

gnu.io.rxtx.SerialPorts=COM3

and I get the following error on the console:
CommPortIdentifier:static initialization()
RXTXCommDriver {}
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
RXTXCommDriver:
    Jar version = RXTX-2.1-7
    native lib Version = RXTX-2.1-7
RXTXCommDriver:initialize()
checking for system-known ports of type 1
checking registry for ports of type 1

RXTXCommDriver:addSpecifiedPorts()
Exception in thread "main" java.lang.ExceptionInInitializerError
    at 
densconnect.SerialConnection.openConnection(SerialConnection.java:136)
    at densconnect.DensTalk.<init>(DensTalk.java:165)
    at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
    at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
    at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
    at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
Caused by: java.lang.NullPointerException
    at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
CommPortIdentifier:addPortName(COM3)
CommPortIdentifier:AddIdentifierToList()
CommPortIdentifier:AddIdentifierToList() null
...


It looks like it  read COM3 from the file, but it had the above 
exception that killed it.  The strange this is this error is from 
RXTXCommDriver initialize function (if statement line):

        OS = System.getProperty("os.name");
                System.out.println("OS NAME: " + OS);
        if(OS.toLowerCase().indexOf("linux") == -1)

OS is returning null, thus the error.

If the file is not present, it scans the ports and reads the OS.

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>Doug Thistlethwaite wrote:
>  
>
>>Trent,
>>
>>I commented out the section in RegisterScannedPorts() that adds the 
>>three LPT ports to the CandidateDeviceNames string array.  The 
>>application started immediately.  This is probably not the way to do 
>>this, but it was quick ,dirty, and worked.
>>
>>It would be nice if there was a way to pole the OS to see if there is 
>>even a port there, though I guess this is what this code is suppose to do...
>>
>>Doug
>>
>>Trent Jarvi wrote:
>>
>>    
>>
>>>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>>
>>> 
>>>
>>>...
>>>
>>>
>>>Does commenting out the LPT enumeration actually help?  There can often be 
>>>differences between debug information printed and whats really going on. 
>>>When you combine various environments the debug info can even come out in 
>>>the wrong order.
>>>
>>>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>>>I do not think this problem is universal.
>>>
>>>--
>>>Trent Jarvi
>>>tjarvi at qbang.org
>>>_______________________________________________
>>>Rxtx mailing list
>>>Rxtx at qbang.org
>>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>>
>>>
>>> 
>>>
>>>      
>>>
>>_______________________________________________
>>Rxtx mailing list
>>Rxtx at qbang.org
>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>    
>>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/bf4cca0e/attachment-0020.html

From doug at dupreeinc.com  Thu Jun  1 16:51:26 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:51:26 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6F6E.5060603@dupreeinc.com>

Jim,

I did not try your suggestion as I do not understand where I would put 
these command line parameters (it that is what they are).  It appears 
that using the properties file should do that same thing...

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>
>  
>


From doug at dupreeinc.com  Thu Jun  1 17:56:19 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 16:56:19 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
Message-ID: <447F7EA3.6050400@dupreeinc.com>

I think there is an error in the registerSpecifiedPorts() method.  When 
I have a gnu.io.rxtx.properties file in the ext directory, this function 
kills the System class  IF I call System.getProperty("os.name") before 
the call  to registerSpecifiedPorts(), it returns the os name, after the 
call, it returns null.  I have not played much with properties, except 
for reading them, so I don't really understand the code.

Doug



From doug at dupreeinc.com  Thu Jun  1 18:11:14 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 17:11:14 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F7EA3.6050400@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com>
Message-ID: <447F8222.3060402@dupreeinc.com>

Ok, I just hacked this thing up and got it to read the 
gnu.io.rxtx.properties file.

I commented out the line:
System.setProperties(p); in the method registerSpecifiedPorts() in 
RXTXCommDriver class.  I really don't understand that much about 
properties, but this call kills the System class.

I used the following in the gnu.io.rxtx.properties file:

gnu.io.rxtx.SerialPorts=COM3
gnu.io.rxtx.ParallelPorts=null

This allows the application to open very quickly without any errors.  
Whomever coded this class or somebody who understands properties should 
look at this method and make sure it is doing what they expect.

Doug




Doug Thistlethwaite wrote:

>I think there is an error in the registerSpecifiedPorts() method.  When 
>I have a gnu.io.rxtx.properties file in the ext directory, this function 
>kills the System class  IF I call System.getProperty("os.name") before 
>the call  to registerSpecifiedPorts(), it returns the os name, after the 
>call, it returns null.  I have not played much with properties, except 
>for reading them, so I don't really understand the code.
>
>Doug
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From tjarvi at qbang.org  Thu Jun  1 18:32:50 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 18:32:50 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F6EF4.7080709@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com> <447F6EF4.7080709@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011831510.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
> folder.  I created this file and added the following to the file:
>
> gnu.io.rxtx.SerialPorts=COM3
>
> and I get the following error on the console:
> CommPortIdentifier:static initialization()
> RXTXCommDriver {}
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
> RXTXCommDriver:
>   Jar version = RXTX-2.1-7
>   native lib Version = RXTX-2.1-7
> RXTXCommDriver:initialize()
> checking for system-known ports of type 1
> checking registry for ports of type 1
>
> RXTXCommDriver:addSpecifiedPorts()
> Exception in thread "main" java.lang.ExceptionInInitializerError
>   at densconnect.SerialConnection.openConnection(SerialConnection.java:136)
>   at densconnect.DensTalk.<init>(DensTalk.java:165)
>   at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
>   at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
>   at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
>   at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
> Caused by: java.lang.NullPointerException
>   at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
> CommPortIdentifier:addPortName(COM3)
> CommPortIdentifier:AddIdentifierToList()
> CommPortIdentifier:AddIdentifierToList() null
> ...
>
>

There is a solution for this bug.

http://bugzilla.qbang.org/show_bug.cgi?id=54

We have been horribly slow at getting the next round of patches in but 
they are comming.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  2 00:58:02 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 08:58:02 +0200
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F8222.3060402@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
Message-ID: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>

Hi Doug,

you wrote in an earlier message, that you would prefer an unchanged  
version. What about simply removing the RXTX parallel lib from the  
ext directory. This does not fix the bug, but it should fix your  
problem.

In general I think it is not a good idea to put the RXTX files in a  
system wide location. Putting the libs in the application folder and  
including the .jar in the application classpath (or application jar)  
is all that is required.

Regards,
Joachim

On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:

> Ok, I just hacked this thing up and got it to read the
> gnu.io.rxtx.properties file.
>
> I commented out the line:
> System.setProperties(p); in the method registerSpecifiedPorts() in
> RXTXCommDriver class.  I really don't understand that much about
> properties, but this call kills the System class.
>
> I used the following in the gnu.io.rxtx.properties file:
>
> gnu.io.rxtx.SerialPorts=COM3
> gnu.io.rxtx.ParallelPorts=null
>
> This allows the application to open very quickly without any errors.
> Whomever coded this class or somebody who understands properties  
> should
> look at this method and make sure it is doing what they expect.
>
> Doug
>
>
>
>
> Doug Thistlethwaite wrote:
>
>> I think there is an error in the registerSpecifiedPorts() method.   
>> When
>> I have a gnu.io.rxtx.properties file in the ext directory, this  
>> function
>> kills the System class  IF I call System.getProperty("os.name")  
>> before
>> the call  to registerSpecifiedPorts(), it returns the os name,  
>> after the
>> call, it returns null.  I have not played much with properties,  
>> except
>> for reading them, so I don't really understand the code.
>>
>> 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 antonio.luis at iscte.pt  Fri Jun  2 02:42:28 2006
From: antonio.luis at iscte.pt (=?ISO-8859-1?Q?Ant=F3nio_Lopes?=)
Date: Fri, 02 Jun 2006 09:42:28 +0100
Subject: [Rxtx] Exception when closing serial port
Message-ID: <447FF9F4.7060209@iscte.pt>

Hello everyone,
I've been using RXTX in a Java application in my Pocket PC.
The communication through the (bluetooth) serial port is working perfectly.

However, when I disconnect the app and close the serial port, sometimes I get 
the following error:

"1149237595000: RXTXPort:close detected bad File Descriptor"

The problem is that after this error occurs, the app is no longer able to 
connect to the serial port and I have to soft-reset the device in order to be 
able to connect to it again.

Any ideas on how to solve this issue?

Any help is appreciated.
Thanks,
regards,
-- 
Ant?nio Lopes

@contact: antonio.luis at iscte.pt
@work: ADETTI - ISCTE
@web: http://antonio.lopes.googlepages.com


From paul.klissner at sun.com  Fri Jun  2 02:44:34 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 01:44:34 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to RXTX
	again
Message-ID: <447FFA72.6040807@sun.com>

After looking into javax.comm 3.1 and what it would take to re-engineer it
to be compatible with RXTX platform libraries, I've decided, due my group's
priorities, complexity of the effort vs. benefit, and limited resources, 
to re-post
javax.comm 2.0 binaries on Sun's software download server, unsupported,
with disclaimers, as it was previously.

I don't think there will be any snags doing this from the standpoint of Sun
management or legality.  I will try to have it  posted there in the next 
week
or two, depending on how fast we can get it pushed through the process.

I'd like to think of this as a stop gap measure... ie. a compromise, 
where, at some
point in the not too distant future RXTX implements their own version of the
Java side of the API, as is normally done by javax.extension porters. 
That way
we avoid uncomfortable dependencies in the future.  And that really is 
the Java
development model.

Since RXTX already has the back-end code, porting the java code shouldn't
be a gargantuan effort at all, and RXTX will be in full control of the 
code top
to bottom. I think RXTX can do at least as good a job as the original 
coder.
Prepping 2.0 to be open sourced is more trouble than it is worth. ie. I 
don't
think the current implementation warrants it.

Ultimately, it would be nice to see someone open up a JSR and re-architect
the comm. API to overcome some of it's current design flaws (ie. be more
adaptable to modern platforms, more pluggable, better defined SPI, better
port ownership handling, etc...). A superior architecture would allow for
better collaboration in the future and better interchangeability of 
components
among projects.

Sun's 3.1 version of javax.comm, which is Sun's currently supported version,
has changes pertaining mostly to Sun platform-specific portmapping and has
some minor additional interactions with our back end code, but generally
has little bearing on RXTX. 

Paul



From joachim at buechse.de  Fri Jun  2 04:00:19 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 12:00:19 +0200
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
	RXTX again
In-Reply-To: <447FFA72.6040807@sun.com>
References: <447FFA72.6040807@sun.com>
Message-ID: <1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>

Good day Paul!

A clean architecture with loadable drivers and reusable code would be  
very beneficial for the future, I think everybody agrees. However  
this could be several years into the future. In the meantime, there  
is a real existing problem with IO support on Java. I have the strong  
feeling that most programmers want to code against one specification  
(javax.comm) and be able to replace the underlying implementation via  
a "plugin" on platforms where the SUN implementation is not  
sufficient. RXTX could be just this plugin (reusing very close to 0%  
of the javax.comm implementation but 100% of its API).

I want to propose an API addition and implementation change that will  
take less then 2 hours of manpower to implement and create a solution  
that can bridge the years until javax.comm has been based on a new  
architecture.

Looking at the javax.comm api at http://java.sun.com/products/ 
javacomm/reference/api/index.html I would like to propose the following:

The only entry point to javax.comm is CommPortIdentifier. It has 3  
static methods plus the constructor.

1) define one additional Interface

public interface CommProvider {
    CommPortIdentifier getPortIdentifier(CommPort port);
    CommPortIdentifier getPortIdentifier(String portName);
    Enumeration getPortIdentifiers ();
}

2) add one method to CommPortIdentifier

   public static setCustomCommProvider (CommProvider);

3) change the three static methods of CommPortIdentifier to dispatch  
to the CommProvider if it is set

4) change the constructor of CommPortIdentifier to

   public CommPortIdentifier(...) {
      if (isProviderSet && this.getClass() ==  
javax.comm.CommPortIdentifier) {
          throw new RuntimeException("illegal creation of  
CommPortIndentifier, custom CommProvider is in use");
      }

5) (this is optional, but would be very nice) automatically set a  
custom CommProvider if it is found on the classpath or defined via a  
system property.


The above 1) - 4) can be implemented in less than 1hour. 5) may take  
another hour. I agree that this is not the most elegant design, but  
it would solve a lot of problems with very little effort. It would  
certainly allow RXTX to move forward. If the javax.comm API needs to  
be redesigned completely this addition will not hurt, as people will  
move to the new API anyway and javax.comm 3.0 was so far never  
included in the main distribution.

Best regards,
Joachim

On 02.06.2006, at 10:44, Paul Klissner wrote:

> After looking into javax.comm 3.1 and what it would take to re- 
> engineer it
> to be compatible with RXTX platform libraries, I've decided, due my  
> group's
> priorities, complexity of the effort vs. benefit, and limited  
> resources,
> to re-post
> javax.comm 2.0 binaries on Sun's software download server,  
> unsupported,
> with disclaimers, as it was previously.
>
> I don't think there will be any snags doing this from the  
> standpoint of Sun
> management or legality.  I will try to have it  posted there in the  
> next
> week
> or two, depending on how fast we can get it pushed through the  
> process.
>
> I'd like to think of this as a stop gap measure... ie. a compromise,
> where, at some
> point in the not too distant future RXTX implements their own  
> version of the
> Java side of the API, as is normally done by javax.extension porters.
> That way
> we avoid uncomfortable dependencies in the future.  And that really is
> the Java
> development model.
>
> Since RXTX already has the back-end code, porting the java code  
> shouldn't
> be a gargantuan effort at all, and RXTX will be in full control of the
> code top
> to bottom. I think RXTX can do at least as good a job as the original
> coder.
> Prepping 2.0 to be open sourced is more trouble than it is worth.  
> ie. I
> don't
> think the current implementation warrants it.
>
> Ultimately, it would be nice to see someone open up a JSR and re- 
> architect
> the comm. API to overcome some of it's current design flaws (ie. be  
> more
> adaptable to modern platforms, more pluggable, better defined SPI,  
> better
> port ownership handling, etc...). A superior architecture would  
> allow for
> better collaboration in the future and better interchangeability of
> components
> among projects.
>
> Sun's 3.1 version of javax.comm, which is Sun's currently supported  
> version,
> has changes pertaining mostly to Sun platform-specific portmapping  
> and has
> some minor additional interactions with our back end code, but  
> generally
> has little bearing on RXTX.
>
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Fri Jun  2 09:10:13 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Fri, 2 Jun 2006 09:10:13 -0600 (MDT)
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <447FFA72.6040807@sun.com>
References: <447FFA72.6040807@sun.com>
Message-ID: <Pine.LNX.4.61.0606020906400.15971@www>

On Fri, 2 Jun 2006, Paul Klissner wrote:

> After looking into javax.comm 3.1 and what it would take to re-engineer it
> to be compatible with RXTX platform libraries, I've decided, due my group's
> priorities, complexity of the effort vs. benefit, and limited resources,
> to re-post
> javax.comm 2.0 binaries on Sun's software download server, unsupported,
> with disclaimers, as it was previously.
>

Hi Paul

To address users' immediate needs, we can release rxtx 2.0-7 (final) to 
match the 2.0 binaries from Sun when they are offered for download.

We can discuss potential long term solutions after that.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Fri Jun  2 10:20:09 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 02 Jun 2006 09:20:09 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
	<9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
Message-ID: <44806539.8080902@dupreeinc.com>

Thanks for the suggestion, I will give it a try.

Doug

Joachim Buechse wrote:

>Hi Doug,
>
>you wrote in an earlier message, that you would prefer an unchanged  
>version. What about simply removing the RXTX parallel lib from the  
>ext directory. This does not fix the bug, but it should fix your  
>problem.
>
>In general I think it is not a good idea to put the RXTX files in a  
>system wide location. Putting the libs in the application folder and  
>including the .jar in the application classpath (or application jar)  
>is all that is required.
>
>Regards,
>Joachim
>
>On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:
>
>  
>
>>Ok, I just hacked this thing up and got it to read the
>>gnu.io.rxtx.properties file.
>>
>>I commented out the line:
>>System.setProperties(p); in the method registerSpecifiedPorts() in
>>RXTXCommDriver class.  I really don't understand that much about
>>properties, but this call kills the System class.
>>
>>I used the following in the gnu.io.rxtx.properties file:
>>
>>gnu.io.rxtx.SerialPorts=COM3
>>gnu.io.rxtx.ParallelPorts=null
>>
>>This allows the application to open very quickly without any errors.
>>Whomever coded this class or somebody who understands properties  
>>should
>>look at this method and make sure it is doing what they expect.
>>
>>Doug
>>
>>
>>
>>
>>Doug Thistlethwaite wrote:
>>
>>    
>>
>>>I think there is an error in the registerSpecifiedPorts() method.   
>>>When
>>>I have a gnu.io.rxtx.properties file in the ext directory, this  
>>>function
>>>kills the System class  IF I call System.getProperty("os.name")  
>>>before
>>>the call  to registerSpecifiedPorts(), it returns the os name,  
>>>after the
>>>call, it returns null.  I have not played much with properties,  
>>>except
>>>for reading them, so I don't really understand the code.
>>>
>>>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
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060602/c8892a46/attachment-0020.html

From paul.klissner at sun.com  Fri Jun  2 12:09:26 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 11:09:26 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
Message-ID: <44807ED6.8000903@sun.com>

Joachim Buechse wrote:
> Good day Paul!
>
> A clean architecture with loadable drivers and reusable code would be  
> very beneficial for the future, I think everybody agrees. However  
> this could be several years into the future. In the meantime, there  
> is a real existing problem with IO support on Java. I have the strong  
> feeling that most programmers want to code against one specification  
> (javax.comm) and be able to replace the underlying implementation via  
> a "plugin" on platforms where the SUN implementation is not  
> sufficient. RXTX could be just this plugin (reusing very close to 0%  
> of the javax.comm implementation but 100% of its API).
>
> I want to propose an API addition and implementation change that will  
> take less then 2 hours of manpower to implement and create a solution  
> that can bridge the years until javax.comm has been based on a new  
> architecture.
>
> Looking at the javax.comm api at http://java.sun.com/products/ 
> javacomm/reference/api/index.html I would like to propose the following:
>
> The only entry point to javax.comm is CommPortIdentifier. It has 3  
> static methods plus the constructor.
>
> 1) define one additional Interface
>
> public interface CommProvider {
>     CommPortIdentifier getPortIdentifier(CommPort port);
>     CommPortIdentifier getPortIdentifier(String portName);
>     Enumeration getPortIdentifiers ();
> }
>
> 2) add one method to CommPortIdentifier
>
>    public static setCustomCommProvider (CommProvider);
>
> 3) change the three static methods of CommPortIdentifier to dispatch  
> to the CommProvider if it is set
>
> 4) change the constructor of CommPortIdentifier to
>
>    public CommPortIdentifier(...) {
>       if (isProviderSet && this.getClass() ==  
> javax.comm.CommPortIdentifier) {
>           throw new RuntimeException("illegal creation of  
> CommPortIndentifier, custom CommProvider is in use");
>       }
>
> 5) (this is optional, but would be very nice) automatically set a  
> custom CommProvider if it is found on the classpath or defined via a  
> system property.
>
>
> The above 1) - 4) can be implemented in less than 1hour. 5) may take  
> another hour. I agree that this is not the most elegant design, but  
> it would solve a lot of problems with very little effort. It would  
> certainly allow RXTX to move forward. If the javax.comm API needs to  
> be redesigned completely this addition will not hurt, as people will  
> move to the new API anyway and javax.comm 3.0 was so far never  
> included in the main distribution.
>
> Best regards,
> Joachi
I'm afraid modifying the interface classes isn't my call.  There was 
actually
a TCK written and one of the tests was to ensure that the interface classes
match the spec.  Thus my hands have already been tied since this project
was essentially grandfathered into the JCP.

That's why we need to open a new JSR and find someone who wants
to be the spec lead, and go in with a new reference implementation.
I'm not sure why it would have to take years, since this isn't bleeding edge
technology and there are only so many things that can be done with it,
and we already have practical experience about many functional aspects
that we could cite precedence on.

As it becomes clear that the specification is being accepted completely
or by-and-large by the community, nothing would stop people from
starting adapting to the new API (using the reference implementation or
porting it) and using it in their projects prior to it's final community and
JCP approval, since approval is required only to make it official and
get the "100% pure java" certification for platform ports.

You have one idea already.  Why don't you implement it, solicit some
design feedback from Sun and the RXTX, and create a functional
implementation that addresses the needs of the community, then
we can document it and open a JSR.  That's it.  It should march through
the approval stages reasonably quickly I would imagine, and meantime
RXTX could start using it.

Paul




From doug at dupreeinc.com  Fri Jun  2 12:45:01 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 02 Jun 2006 11:45:01 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
	<9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
Message-ID: <4480872D.6000605@dupreeinc.com>

Joachim,

Thank you for the suggestion.  I restored the jar file to the one I 
downloaded, moved the dll files into the project directory, and added 
the jar to the classpath.  The SerialDemo program that was included with 
the Sun commapi started in 12 seconds instead of the 58 seconds when the 
parallel dll is present.  I did get the startup time to about a second 
by modifying the java code and adding the properties file but this is 
probably not a good idea.

Doug

Joachim Buechse wrote:

>Hi Doug,
>
>you wrote in an earlier message, that you would prefer an unchanged  
>version. What about simply removing the RXTX parallel lib from the  
>ext directory. This does not fix the bug, but it should fix your  
>problem.
>
>In general I think it is not a good idea to put the RXTX files in a  
>system wide location. Putting the libs in the application folder and  
>including the .jar in the application classpath (or application jar)  
>is all that is required.
>
>Regards,
>Joachim
>
>On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:
>
>  
>
>>Ok, I just hacked this thing up and got it to read the
>>gnu.io.rxtx.properties file.
>>
>>I commented out the line:
>>System.setProperties(p); in the method registerSpecifiedPorts() in
>>RXTXCommDriver class.  I really don't understand that much about
>>properties, but this call kills the System class.
>>
>>I used the following in the gnu.io.rxtx.properties file:
>>
>>gnu.io.rxtx.SerialPorts=COM3
>>gnu.io.rxtx.ParallelPorts=null
>>
>>This allows the application to open very quickly without any errors.
>>Whomever coded this class or somebody who understands properties  
>>should
>>look at this method and make sure it is doing what they expect.
>>
>>Doug
>>
>>
>>
>>
>>Doug Thistlethwaite wrote:
>>
>>    
>>
>>>I think there is an error in the registerSpecifiedPorts() method.   
>>>When
>>>I have a gnu.io.rxtx.properties file in the ext directory, this  
>>>function
>>>kills the System class  IF I call System.getProperty("os.name")  
>>>before
>>>the call  to registerSpecifiedPorts(), it returns the os name,  
>>>after the
>>>call, it returns null.  I have not played much with properties,  
>>>except
>>>for reading them, so I don't really understand the code.
>>>
>>>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
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060602/3c0e420f/attachment-0020.html

From joachim at buechse.de  Fri Jun  2 13:46:36 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 21:46:36 +0200
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
	RXTX again
In-Reply-To: <44807ED6.8000903@sun.com>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
	<44807ED6.8000903@sun.com>
Message-ID: <6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>

Hello Paul,

of course, the basic change I suggested could be done "hidden".  The  
CommProvider interface could live somewhere in sun.xyz.*
The setCustomCommProvider method would not be in CommPortIdentifier  
but also somewhere in sun.xyz.* This would be an unofficial feature,  
the official interface stays exactly the same. However RXTX (and  
others) could access the hidden interface.

Don't get me wrong, I don't want to harass you into making changes  
you don't like (which probably wouldn't work anyway;-). But I'm a  
long time Java programmer and seeing the state of cross platform  
serial support for Java makes me feel really sad. In fact, when I  
started to look into Java serial port programming some months ago I  
was very surprised that javax.comm never made it into the JDK.

I'm sorry that I did not contribute my feedback to the JSR for  
javax.comm 3.0. However at the time I didn't do serial port  
programming in Java. I agree that a new JSR should be opened - I'm  
not an expert on JSRs or the JCP process, but from looking quickly  
over the progress of some JSRs I would be very surprised if we can  
have a new version in less then a year. In the meanwhile some people  
will start using javax.comm 3.0 (which can not be supported by RXTX),  
some will use javax.comm 2.0 (which means the 2.0.7 release of RXTX  
still needs to be maintained). This may get even worse if eg Apple  
decides to port and include javax.comm 3.0 at which point it may get  
very tricky to write a cross platform Java application.

All of this simply means, that we are loosing a lot of man-power that  
could otherwise be invested in building a clean solution and/or to  
add features that are becoming more and more important (USB events...).

In the automation / machine control universe Java makes a lot of  
sense. Right now many people are migrating to Linux or from  
propietary systems (even DOS) to Windows. Writing the control/ 
configuration applications in Java is the kings way to unify the code  
base.

Best regards,
Joachim


On 02.06.2006, at 20:09, Paul Klissner wrote:

> Joachim Buechse wrote:
>> Good day Paul!
>>
>> A clean architecture with loadable drivers and reusable code would be
>> very beneficial for the future, I think everybody agrees. However
>> this could be several years into the future. In the meantime, there
>> is a real existing problem with IO support on Java. I have the strong
>> feeling that most programmers want to code against one specification
>> (javax.comm) and be able to replace the underlying implementation via
>> a "plugin" on platforms where the SUN implementation is not
>> sufficient. RXTX could be just this plugin (reusing very close to 0%
>> of the javax.comm implementation but 100% of its API).
>>
>> I want to propose an API addition and implementation change that will
>> take less then 2 hours of manpower to implement and create a solution
>> that can bridge the years until javax.comm has been based on a new
>> architecture.
>>
>> Looking at the javax.comm api at http://java.sun.com/products/
>> javacomm/reference/api/index.html I would like to propose the  
>> following:
>>
>> The only entry point to javax.comm is CommPortIdentifier. It has 3
>> static methods plus the constructor.
>>
>> 1) define one additional Interface
>>
>> public interface CommProvider {
>>     CommPortIdentifier getPortIdentifier(CommPort port);
>>     CommPortIdentifier getPortIdentifier(String portName);
>>     Enumeration getPortIdentifiers ();
>> }
>>
>> 2) add one method to CommPortIdentifier
>>
>>    public static setCustomCommProvider (CommProvider);
>>
>> 3) change the three static methods of CommPortIdentifier to dispatch
>> to the CommProvider if it is set
>>
>> 4) change the constructor of CommPortIdentifier to
>>
>>    public CommPortIdentifier(...) {
>>       if (isProviderSet && this.getClass() ==
>> javax.comm.CommPortIdentifier) {
>>           throw new RuntimeException("illegal creation of
>> CommPortIndentifier, custom CommProvider is in use");
>>       }
>>
>> 5) (this is optional, but would be very nice) automatically set a
>> custom CommProvider if it is found on the classpath or defined via a
>> system property.
>>
>>
>> The above 1) - 4) can be implemented in less than 1hour. 5) may take
>> another hour. I agree that this is not the most elegant design, but
>> it would solve a lot of problems with very little effort. It would
>> certainly allow RXTX to move forward. If the javax.comm API needs to
>> be redesigned completely this addition will not hurt, as people will
>> move to the new API anyway and javax.comm 3.0 was so far never
>> included in the main distribution.
>>
>> Best regards,
>> Joachi
> I'm afraid modifying the interface classes isn't my call.  There was
> actually
> a TCK written and one of the tests was to ensure that the interface  
> classes
> match the spec.  Thus my hands have already been tied since this  
> project
> was essentially grandfathered into the JCP.
>
> That's why we need to open a new JSR and find someone who wants
> to be the spec lead, and go in with a new reference implementation.
> I'm not sure why it would have to take years, since this isn't  
> bleeding edge
> technology and there are only so many things that can be done with it,
> and we already have practical experience about many functional aspects
> that we could cite precedence on.
>
> As it becomes clear that the specification is being accepted  
> completely
> or by-and-large by the community, nothing would stop people from
> starting adapting to the new API (using the reference  
> implementation or
> porting it) and using it in their projects prior to it's final  
> community and
> JCP approval, since approval is required only to make it official and
> get the "100% pure java" certification for platform ports.
>
> You have one idea already.  Why don't you implement it, solicit some
> design feedback from Sun and the RXTX, and create a functional
> implementation that addresses the needs of the community, then
> we can document it and open a JSR.  That's it.  It should march  
> through
> the approval stages reasonably quickly I would imagine, and meantime
> RXTX could start using it.
>
> Paul
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From paul.klissner at sun.com  Fri Jun  2 14:38:49 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 13:38:49 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
	<44807ED6.8000903@sun.com>
	<6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>
Message-ID: <4480A1D9.5060106@sun.com>

Joachim Buechse wrote:
> Hello Paul,
>
> of course, the basic change I suggested could be done "hidden".  The  
> CommProvider interface could live somewhere in sun.xyz.*
> The setCustomCommProvider method would not be in CommPortIdentifier  
> but also somewhere in sun.xyz.* This would be an unofficial feature,  
> the official interface stays exactly the same. However RXTX (and  
> others) could access the hidden interface.
>
> Don't get me wrong, I don't want to harass you into making changes  
> you don't like (which probably wouldn't work anyway;-). But I'm a  
> long time Java programmer and seeing the state of cross platform  
> serial support for Java makes me feel really sad. In fact, when I  
> started to look into Java serial port programming some months ago I  
> was very surprised that javax.comm never made it into the JDK.
>
> I'm sorry that I did not contribute my feedback to the JSR for  
> javax.comm 3.0. 
There was no JSR for 3.0, because we didn't have the resources to make 
the commitment.
Yet Sun needed to add support for platform-dependent port name mapping, 
which had to
be done 'under the hood', since the API isn't designed to handle that in 
a pluggable way.
But these quick fixes aren't the right approach, they just kick the dog 
down the road,
setting bad precedent, inviting confusion and more intractable problems 
(such as the
one plaguing us now).

My changes could have been layered better, it was a trade off between 
achieving an
ideal architecture, trying to find internal reviewers, and meet the 
needs of big customers
in a timely way.  Thus my namespace changes collided with RXTX's 
dependencies.
I was unaware of Jagane's rogue agreement made with the RXTX community 7 
years ago,
before Jagane left Sun.  I think this was a wag-the-dog situation.

Now it is time to do it right, and I don't think it is going to be as 
much trouble as people
some people fear. If RXTX wants to sponsor the JSR and seed a new spec, 
Sun can join
the Expert Group.  And we'd be largely in agreement, since we're not 
talking about
humongous changes, and looking for mutually beneficial changes. The core 
API is already
largely proved and tested.
> However at the time I didn't do serial port  
> programming in Java. I agree that a new JSR should be opened - I'm  
> not an expert on JSRs or the JCP process, but from looking quickly  
> over the progress of some JSRs I would be very surprised if we can  
> have a new version in less then a year. 
*Approved*  But that doesn't mean the spec couldn't be 99.9% stable 
before that.  Once
the delta rate declines and changes approach nil, people could start 
adapting to the API in
advance of formal approval.   It isn't going to be drawn out like 
javax.usb, which was new
technology, a very complex API, and involved precedent setting corporate 
disputes and
policy issues to resolve.

> In the meanwhile some people  
> will start using javax.comm 3.0 (which can not be supported by RXTX),  
> some will use javax.comm 2.0 (which means the 2.0.7 release of RXTX  
> still needs to be maintained). This may get even worse if eg Apple  
> decides to port and include javax.comm 3.0 at which point it may get  
> very tricky to write a cross platform Java application.
>   
The interfaces haven't changed since 1.0.  If we open a JSR ,we can 
contact Apple and
allow them to be on the E.G., if they want.  That might make the JSR a 
bit more drawn out,
but then we'd arrive ultimately arrive at a best-of-all-worlds API that 
most people would
accept, perhaps forever, and arrive at a respectable set of compromises.

-Paul

> All of this simply means, that we are loosing a lot of man-power that  
> could otherwise be invested in building a clean solution and/or to  
> add features that are becoming more and more important (USB events...).
>
> In the automation / machine control universe Java makes a lot of  
> sense. Right now many people are migrating to Linux or from  
> propietary systems (even DOS) to Windows. Writing the control/ 
> configuration applications in Java is the kings way to unify the code  
> base.
>
> Best regards,
> Joachim
>
>
> On 02.06.2006, at 20:09, Paul Klissner wrote:
>
>   
>> Joachim Buechse wrote:
>>     
>>> Good day Paul!
>>>
>>> A clean architecture with loadable drivers and reusable code would be
>>> very beneficial for the future, I think everybody agrees. However
>>> this could be several years into the future. In the meantime, there
>>> is a real existing problem with IO support on Java. I have the strong
>>> feeling that most programmers want to code against one specification
>>> (javax.comm) and be able to replace the underlying implementation via
>>> a "plugin" on platforms where the SUN implementation is not
>>> sufficient. RXTX could be just this plugin (reusing very close to 0%
>>> of the javax.comm implementation but 100% of its API).
>>>
>>> I want to propose an API addition and implementation change that will
>>> take less then 2 hours of manpower to implement and create a solution
>>> that can bridge the years until javax.comm has been based on a new
>>> architecture.
>>>
>>> Looking at the javax.comm api at http://java.sun.com/products/
>>> javacomm/reference/api/index.html I would like to propose the  
>>> following:
>>>
>>> The only entry point to javax.comm is CommPortIdentifier. It has 3
>>> static methods plus the constructor.
>>>
>>> 1) define one additional Interface
>>>
>>> public interface CommProvider {
>>>     CommPortIdentifier getPortIdentifier(CommPort port);
>>>     CommPortIdentifier getPortIdentifier(String portName);
>>>     Enumeration getPortIdentifiers ();
>>> }
>>>
>>> 2) add one method to CommPortIdentifier
>>>
>>>    public static setCustomCommProvider (CommProvider);
>>>
>>> 3) change the three static methods of CommPortIdentifier to dispatch
>>> to the CommProvider if it is set
>>>
>>> 4) change the constructor of CommPortIdentifier to
>>>
>>>    public CommPortIdentifier(...) {
>>>       if (isProviderSet && this.getClass() ==
>>> javax.comm.CommPortIdentifier) {
>>>           throw new RuntimeException("illegal creation of
>>> CommPortIndentifier, custom CommProvider is in use");
>>>       }
>>>
>>> 5) (this is optional, but would be very nice) automatically set a
>>> custom CommProvider if it is found on the classpath or defined via a
>>> system property.
>>>
>>>
>>> The above 1) - 4) can be implemented in less than 1hour. 5) may take
>>> another hour. I agree that this is not the most elegant design, but
>>> it would solve a lot of problems with very little effort. It would
>>> certainly allow RXTX to move forward. If the javax.comm API needs to
>>> be redesigned completely this addition will not hurt, as people will
>>> move to the new API anyway and javax.comm 3.0 was so far never
>>> included in the main distribution.
>>>
>>> Best regards,
>>> Joachi
>>>       
>> I'm afraid modifying the interface classes isn't my call.  There was
>> actually
>> a TCK written and one of the tests was to ensure that the interface  
>> classes
>> match the spec.  Thus my hands have already been tied since this  
>> project
>> was essentially grandfathered into the JCP.
>>
>> That's why we need to open a new JSR and find someone who wants
>> to be the spec lead, and go in with a new reference implementation.
>> I'm not sure why it would have to take years, since this isn't  
>> bleeding edge
>> technology and there are only so many things that can be done with it,
>> and we already have practical experience about many functional aspects
>> that we could cite precedence on.
>>
>> As it becomes clear that the specification is being accepted  
>> completely
>> or by-and-large by the community, nothing would stop people from
>> starting adapting to the new API (using the reference  
>> implementation or
>> porting it) and using it in their projects prior to it's final  
>> community and
>> JCP approval, since approval is required only to make it official and
>> get the "100% pure java" certification for platform ports.
>>
>> You have one idea already.  Why don't you implement it, solicit some
>> design feedback from Sun and the RXTX, and create a functional
>> implementation that addresses the needs of the community, then
>> we can document it and open a JSR.  That's it.  It should march  
>> through
>> the approval stages reasonably quickly I would imagine, and meantime
>> RXTX could start using it.
>>
>> Paul
>>
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at 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  Sat Jun  3 18:15:24 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 18:15:24 -0600 (MDT)
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
Message-ID: <Pine.LNX.4.61.0606031715100.10890@www>


The attached patch allows baud rates of 14400, 28800, 128000 and 256000.

That was my goal.

[import standard disclaimer]

But I took some time to look a little further.  I got custom baud rates 
working enough that someone (perhaps me) can properly fix them in the 
future.  Proof of concept.

As an undocumented bonus, you can toss random baudrates (say 1953), at the 
API and it will set it to something close to that on windows and linux. 
Solaris should say the baud rate is not supported but I have not tested it 
yet.  Mac OS X behavior is unknown at this point.  Just dont expect 
correct behavior at ~8192-9009 baudrates or baudrates less than 20 on 
windows; these baud rates overlap with defines in win32termios.h.  I 
conveniently closed my eyes there.  Try another value close.  On Linux, a 
baud base and divisor are guestimated and set.  On windows, we wave pixie 
dust over the kernel driver and hope.  Do not expect pixie dust and 
guestimates to be the same on windows and linux.  They may well round to 
different values in yet to be tested ways.  There are only so many 
divisors.  If it isn't working, try a little higher or lower.

In the example of 1953 for instance, there is no divisor for commodity 
hardware that comes to that baudrate.  We just come close on one side or 
the other.  If tools tell you they got 1953 exactly, the tools may be 
questionable and just reading values not directly related to the actual 
hardware settings.

These fixes have been tested on Linux and Windows while using an 
oscilloscope to confirm they change relative to known baudrates at 9600, 
14400*, 19200, 28800* (and 1800, 1953** and 2400).

* = previously unsupported.
** = still not supported but probably works from what I saw.

There could be future discussion in this area.  For now this is working 
for almost all unusual baud rate demands.  Cleaning up the custom baud 
rate should be easier with a working starting point.  Baud bases other 
than 128000 have not been characterized.  Yes.. this overlapps with two of 
the baud rates enabled.

Feedback and ideas are welcome.

--
Trent Jarvi
tjarvi at qbang.org
-------------- next part --------------
Index: SerialImp.c
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v
retrieving revision 1.46.2.187
diff -u -r1.46.2.187 SerialImp.c
--- SerialImp.c	29 Jan 2006 22:19:04 -0000	1.46.2.187
+++ SerialImp.c	3 Jun 2006 23:12:40 -0000
@@ -793,6 +793,19 @@
 		result &= ~TIOCM_DTR;
 		ioctl( fd, TIOCMSET, &result );
 	}
+	/*
+	   B38400 is a special case in Linux for custom baud rates.
+
+	   We just treat this as a custom speed for now.  If you take this ifdef
+	   out and select baud rates 38400 then 28800 then 38400, you will get
+	   a final baud rate of 28800 because you did not update the divisor.
+
+	   See the next ifdef below for the divisor.
+	*/
+#if defined(TIOCGSERIAL)
+	if ( cspeed == B38400 )
+		cspeed = 38400;
+#endif /* TIOCGSERIAL */
 	if(     cfsetispeed( &ttyset, cspeed ) < 0 ||
 		cfsetospeed( &ttyset, cspeed ) < 0 )
 	{
@@ -814,6 +827,7 @@
 		*/
 
 #if defined(TIOCGSERIAL)
+		ioctl( fd, TIOCGSERIAL, &sstruct );
 		sstruct.custom_divisor = ( sstruct.baud_base/cspeed );
 		cspeed = B38400;
 #endif /* TIOCGSERIAL */
@@ -827,7 +841,7 @@
 #if defined(TIOCSSERIAL)
 		/*  It is assumed Win32 does this for us */
 		if (	sstruct.baud_base < 1 ||
-			ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
+		ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
 		{
 			return( 1 );
 		}
Index: termios.c
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v
retrieving revision 1.9.2.56
diff -u -r1.9.2.56 termios.c
--- termios.c	16 Jan 2006 02:50:32 -0000	1.9.2.56
+++ termios.c	3 Jun 2006 23:12:40 -0000
@@ -323,8 +323,8 @@
 		case CBR_3500000:	return( B3500000 );
 		case CBR_4000000:	return( B4000000 );
 		default:
-			set_errno(EINVAL );
-			return -1;
+			/* assume custom baudrate */
+			return( Baud );
 	}
 }
 
@@ -361,12 +361,13 @@
 		case B9600:	ret = CBR_9600;		break;
 		case B14400:	ret = CBR_14400;	break;
 		case B19200:	ret = CBR_19200;	break;
+		case B28800:	ret = CBR_28800;	break;
 		case B38400:	ret = CBR_38400;	break;
 		case B57600:	ret = CBR_57600;	break;
 		case B115200:	ret = CBR_115200;	break;
 		case B128000:	ret = CBR_128000;	break;
-		case B256000: 	ret = CBR_256000;	break;
 		case B230400:	ret = CBR_230400;	break;
+		case B256000: 	ret = CBR_256000;	break;
 		case B460800:	ret = CBR_460800;	break;
 		case B500000:	ret = CBR_500000;	break;
 		case B576000:	ret = CBR_576000;	break;
@@ -381,10 +382,8 @@
 		case B4000000:	ret = CBR_4000000;	break;
 	
 		default:
-			fprintf( stderr, "B_to_CBR: invalid baudrate: %#o\n",
-				Baud );
-			set_errno( EINVAL );
-			return -1;
+			/* assume custom baudrate */
+			return Baud;
 	}
 	LEAVE( "B_to_CBR" );
 	return ret;
@@ -708,12 +707,9 @@
 	ENTER( "init_serial_struct" );
 
 	/*
-	FIXME
-
-	This needs to use inb() to read the actual baud_base
-	and divisor from the UART registers.  Question is how
-	far do we take this?
-
+	use of custom_divisor and baud_base requires access to
+	kernel space.  The kernel does try its best if you just
+	toss a baud rate at it though.
 	*/
 
 	sstruct->custom_divisor = 0;
@@ -1678,16 +1674,17 @@
 {
 	char message[80];
 	ENTER( "cfsetospeed" );
+	/* clear baudrate */
+	s_termios->c_cflag &= ~CBAUD;
 	if ( speed & ~CBAUD )
 	{
 		sprintf( message, "cfsetospeed: not speed: %#o\n", speed );
 		report( message );
-		return 0;
+		/* continue assuming its a custom baudrate */
+		s_termios->c_cflag |= B38400;  /* use 38400 during custom */
+		s_termios->c_cflag |= CBAUDEX; /* use CBAUDEX for custom */
 	}
-	s_termios->c_ispeed = s_termios->c_ospeed = speed;
-	/* clear baudrate */
-	s_termios->c_cflag &= ~CBAUD;
-	if( speed )
+	else if( speed )
 	{
 		s_termios->c_cflag |= speed;
 	}
@@ -1696,6 +1693,7 @@
 		/* PC blows up with speed 0 handled in Java */
 		s_termios->c_cflag |= B9600;
 	}
+	s_termios->c_ispeed = s_termios->c_ospeed = speed;
 	LEAVE( "cfsetospeed" );
 	return 1;
 }
@@ -1767,25 +1765,6 @@
 }
 
 /*----------------------------------------------------------
-serial_struct_to_DCB()
-
-   accept:      
-   perform:     
-   return:      
-   exceptions:  
-   win32api:     None
-   comments:    
-----------------------------------------------------------*/
-int serial_struct_to_DCB( struct serial_struct *sstruct, DCB *dcb )
-{
-	/* 5 Baud rate fix
-	sstruct.baud_base
-	sstruct.custom_divisor = ( sstruct.baud_base/cspeed );
-	*/
-	return(0);
-}
-
-/*----------------------------------------------------------
 termios_to_DCB()
 
    accept:      
@@ -1798,7 +1777,8 @@
 int termios_to_DCB( struct termios *s_termios, DCB *dcb )
 {
 	ENTER( "termios_to_DCB" );
-	s_termios->c_ispeed = s_termios->c_ospeed = s_termios->c_cflag & CBAUD;
+	if ( !(s_termios->c_cflag & CBAUDEX) )
+		s_termios->c_ispeed = s_termios->c_ospeed = s_termios->c_cflag & CBAUD;
 	dcb->BaudRate        = B_to_CBR( s_termios->c_ispeed );
 	dcb->ByteSize = termios_to_bytesize( s_termios->c_cflag );
 
@@ -2863,11 +2843,6 @@
 			GetCommState( index->hComm, dcb );
 
 			index->sstruct = va_arg( ap, struct serial_struct * );
-			if ( serial_struct_to_DCB( index->sstruct, dcb ) < 0 )
-			{
-				va_end( ap );
-				return -1;
-			}
 
 			report( "TIOCSSERIAL\n" );
 			free(dcb);
Index: win32termios.h
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v
retrieving revision 1.5.2.28
diff -u -r1.5.2.28 win32termios.h
--- win32termios.h	30 Jun 2005 20:23:26 -0000	1.5.2.28
+++ win32termios.h	3 Jun 2006 23:12:40 -0000
@@ -279,7 +279,7 @@
 #define XTABS	01000000 /* Hmm.. Linux/i386 considers this part of TABDLY.. */
 
 /* c_cflag bit meaning */
-# define CBAUD	0010017
+#define  CBAUD  0030017
 #define  B0	0000000		/* hang up */
 #define  B50	0000001
 #define  B75	0000002
@@ -312,13 +312,16 @@
 #define  B3500000 0010016
 #define  B4000000 0010017
 
-/* glue for unsupported linux speeds see also SerialImp.h */
-/* hosed */
-
-#define B14400		1010001
-#define B28800		1010002
-#define B128000		1010003
-#define B256000		1010004
+/*
+	glue for unsupported linux speeds see also SerialImp.h 
+	custom baud rates around 8192-9000 will not work because
+	of these.
+*/
+
+#define B14400		0020001
+#define B28800		0020002
+#define B128000		0020003
+#define B256000		0020004
 
 #define EXTA B19200
 #define EXTB B38400
@@ -356,8 +359,10 @@
 
 /* glue for unsupported windows speeds */
 
-#define CBR_230400	230400
 #define CBR_28800	28800
+#define CBR_128000	128000
+#define CBR_230400	230400
+#define CBR_256000	256000
 #define CBR_460800	460800
 #define CBR_500000	500000
 #define CBR_576000	576000

From impakt01 at optusnet.com.au  Sat Jun  3 18:30:37 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 10:30:37 +1000
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
In-Reply-To: <Pine.LNX.4.61.0606031715100.10890@www>
Message-ID: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>

Hi Trent,
I'd love to try the patch but I can't get the latest build compiling, only
pre16. 

Can you attach the rxtxSerial.dll file with this patch?

Also, I hardcoded 1953 in a couple more places last night on pre16 and it
managed to open the port at the right speed, but stopped receiving anything
after 100-150 bytes, even though more data was getting sent to the port.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 10:15 AM
To: rxtx at qbang.org
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.


The attached patch allows baud rates of 14400, 28800, 128000 and 256000.

That was my goal.

[import standard disclaimer]

But I took some time to look a little further.  I got custom baud rates 
working enough that someone (perhaps me) can properly fix them in the 
future.  Proof of concept.

As an undocumented bonus, you can toss random baudrates (say 1953), at the 
API and it will set it to something close to that on windows and linux. 
Solaris should say the baud rate is not supported but I have not tested it 
yet.  Mac OS X behavior is unknown at this point.  Just dont expect 
correct behavior at ~8192-9009 baudrates or baudrates less than 20 on 
windows; these baud rates overlap with defines in win32termios.h.  I 
conveniently closed my eyes there.  Try another value close.  On Linux, a 
baud base and divisor are guestimated and set.  On windows, we wave pixie 
dust over the kernel driver and hope.  Do not expect pixie dust and 
guestimates to be the same on windows and linux.  They may well round to 
different values in yet to be tested ways.  There are only so many 
divisors.  If it isn't working, try a little higher or lower.

In the example of 1953 for instance, there is no divisor for commodity 
hardware that comes to that baudrate.  We just come close on one side or 
the other.  If tools tell you they got 1953 exactly, the tools may be 
questionable and just reading values not directly related to the actual 
hardware settings.

These fixes have been tested on Linux and Windows while using an 
oscilloscope to confirm they change relative to known baudrates at 9600, 
14400*, 19200, 28800* (and 1800, 1953** and 2400).

* = previously unsupported.
** = still not supported but probably works from what I saw.

There could be future discussion in this area.  For now this is working 
for almost all unusual baud rate demands.  Cleaning up the custom baud 
rate should be easier with a working starting point.  Baud bases other 
than 128000 have not been characterized.  Yes.. this overlapps with two of 
the baud rates enabled.

Feedback and ideas are welcome.

--
Trent Jarvi
tjarvi at qbang.org



From tjarvi at qbang.org  Sat Jun  3 19:05:11 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 19:05:11 -0600 (MDT)
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
In-Reply-To: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>
References: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606031840400.10890@www>

On Sun, 4 Jun 2006, Daren wrote:

> Hi Trent,
> I'd love to try the patch but I can't get the latest build compiling, only
> pre16.
>
> Can you attach the rxtxSerial.dll file with this patch?
>
> Also, I hardcoded 1953 in a couple more places last night on pre16 and it
> managed to open the port at the right speed, but stopped receiving anything
> after 100-150 bytes, even though more data was getting sent to the port.
>


ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing

I dont think they will hang.  But I was just testing via loopback/break 
out box/scope.

I'll be putting about 10 patches and another set of binaries in that 
directory shortly.  For now the binaries should just have the baud_rate 
fix.

I'll announce all the patches at once.  but wont be releasing 2.1-8 right 
away.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Sat Jun  3 21:00:01 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 21:00:01 -0600 (MDT)
Subject: [Rxtx] CVS for 2.1 should have everything
Message-ID: <Pine.LNX.4.61.0606032056190.10890@www>


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org


From impakt01 at optusnet.com.au  Sat Jun  3 21:08:14 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 13:08:14 +1000
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <Pine.LNX.4.61.0606032056190.10890@www>
Message-ID: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>

Hi Trent,
I tried the latest dll and it opens the port, receives 100-200 bytes and
then stops receiving anything else..

I'll keep playing with it.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 1:00 PM
To: rxtx at qbang.org
Subject: [Rxtx] CVS for 2.1 should have everything


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From impakt01 at optusnet.com.au  Sat Jun  3 21:22:41 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 13:22:41 +1000
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
Message-ID: <200606040322.k543MqW1008455@mail12.syd.optusnet.com.au>

Played with it, problem, with a while loop in my code, working great now

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Daren
Sent: Sunday, 4 June 2006 1:08 PM
To: 'RXTX Developers and Users'
Subject: Re: [Rxtx] CVS for 2.1 should have everything

Hi Trent,
I tried the latest dll and it opens the port, receives 100-200 bytes and
then stops receiving anything else..

I'll keep playing with it.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 1:00 PM
To: rxtx at qbang.org
Subject: [Rxtx] CVS for 2.1 should have everything


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Sat Jun  3 21:35:41 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 21:35:41 -0600 (MDT)
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
References: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606032131140.10890@www>

On Sun, 4 Jun 2006, Daren wrote:

> Hi Trent,
> I tried the latest dll and it opens the port, receives 100-200 bytes and
> then stops receiving anything else..
>
> I'll keep playing with it.
>
> Daren

The difference may be that I'm talking to something at the exact same baud 
rate (loopback).

You may also try setting the baudrate to ~1933 and ~1973 to force the 
guesses one way or the other.  If you are on windows, we are not doing 
anything fancy in the end.  Thats the kernel guessing.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sun Jun  4 04:12:09 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sun, 4 Jun 2006 12:12:09 +0200
Subject: [Rxtx] Update of OSX installer, Readme, etc
Message-ID: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>

Good day,

after the latest changes a lot of OS X specific files should be  
updated. Especially the installer!

- The "MaxOSX" readme file on the root level is outdated (ie  
CodeWarrior information). Maybe we could even rename it to README.OSX  
to be in line with README.IPAQ, README.SCO (Trent do you mind copying/ 
renaming ,v files in the repository?).

- The lock files are no longer used and hence the user group magic  
and lock folder creation should be removed from the installer.

- MACOSX_IDE/ForPackageMaker/Resources/ReadMe.rtf and Welcome.rtf  
need to be updated.

- I suggest to replace the current installation instruction for OS X:  
Installation should occur into the application directory, not in the  
Java-VM directory. This simplifies things a lot, as the Mac Installer  
can be removed completely.

- The xcodeproject's build settings need to be updated to generate  
JAVA 1.1 format class files.


Dimitry: do you have time to tackle this? I could do it, but as this  
is "your baby" I thought you may prefer to do it yourself.

Regards,
Joachim



From dmarkman at mac.com  Sun Jun  4 11:27:53 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Sun, 4 Jun 2006 13:27:53 -0400
Subject: [Rxtx] Update of OSX installer, Readme, etc
In-Reply-To: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
References: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
Message-ID: <26E7A202-962B-4C19-93B6-29426C467249@mac.com>

Joachim,
unfortunately I don't have time right now to do that
so if you can do that, please do

it's not only my baby
it's yours too :-)

thanks


On Jun 4, 2006, at 6:12 AM, Joachim Buechse wrote:

> Good day,
>
> after the latest changes a lot of OS X specific files should be
> updated. Especially the installer!
>
> - The "MaxOSX" readme file on the root level is outdated (ie
> CodeWarrior information). Maybe we could even rename it to README.OSX
> to be in line with README.IPAQ, README.SCO (Trent do you mind copying/
> renaming ,v files in the repository?).
>
> - The lock files are no longer used and hence the user group magic
> and lock folder creation should be removed from the installer.
>
> - MACOSX_IDE/ForPackageMaker/Resources/ReadMe.rtf and Welcome.rtf
> need to be updated.
>
> - I suggest to replace the current installation instruction for OS X:
> Installation should occur into the application directory, not in the
> Java-VM directory. This simplifies things a lot, as the Mac Installer
> can be removed completely.
>
> - The xcodeproject's build settings need to be updated to generate
> JAVA 1.1 format class files.
>
>
> Dimitry: do you have time to tackle this? I could do it, but as this
> is "your baby" I thought you may prefer to do it yourself.
>
> Regards,
> Joachim
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman



From tjarvi at qbang.org  Sun Jun  4 13:54:02 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 4 Jun 2006 13:54:02 -0600 (MDT)
Subject: [Rxtx] Update of OSX installer, Readme, etc
In-Reply-To: <26E7A202-962B-4C19-93B6-29426C467249@mac.com>
References: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
	<26E7A202-962B-4C19-93B6-29426C467249@mac.com>
Message-ID: <Pine.LNX.4.61.0606041353040.22522@www>

On Sun, 4 Jun 2006, Dmitry Markman wrote:

> Joachim,
> unfortunately I don't have time right now to do that
> so if you can do that, please do
>
> it's not only my baby
> it's yours too :-)
>

I've given Joachim cvs access.  He has shown good work in bugzilla.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Mon Jun  5 10:08:32 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 5 Jun 2006 18:08:32 +0200
Subject: [Rxtx] Build process changes for Mac OS X
Message-ID: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>

Good day,

I have cleaned up some outdated Mac OSX specific build files in the  
repository.

There was not a lot left of the readme file "MacOSX" after cleaning  
it up, so I decided to rename it README.OSX to be in harmony with the  
other files in the directory (ie README.IPAQ, README.SCO, ...)

I added an (uncompressed) XCode 2.3 project file/structure  
with .cvsignore files that will ignore the user specific settings.  
This should work "out of the box" for OSX10.4. Users of 10.2/10.3 may  
have to switch the build settings.

[It's kind of tricky to choose "the right" setting. Afaik there is no  
way to compile a universal binary that will work on 10.3 or before.  
So it's either UniversalBinary OR Legacy. Maybe we should have  
different build targets for these different targets?? I would like to  
get some feedback from the Mac developers on this list regarding the  
subject].

Besides other things the OSX installer is no longer required. Since  
the next version (2.1.8) will no longer use lockfiles on OSX, the  
group/permission magic is no longer required and hence there remains  
basicly no work for the installer - other than copying 2 files to the  
VM extension directory. Then again, this is not the best way to  
install RXTX. So I removed the installer completely without modifying  
it, this should simplify a "resurrection" should it ever get necessary.

I had problems with the (compressed, ie sit.hqx) legacy project files  
on the latest installation of OSX (javac 1.5 creating non JDK1.1  
class files and some minor problems). To reduce potential confusion  
for newcomers I decided to remove them. This means that there is no  
longer a simple way to build RXTX for OSX 10.0 and 10.1 (I deeply  
apologize if anyone still relied on this ... well the files are in  
the Attiq).

Best regards,
Joachim


From joachim at buechse.de  Mon Jun  5 10:16:37 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 5 Jun 2006 18:16:37 +0200
Subject: [Rxtx] RXTX and lockfiles on OSX [it is fixed now]
Message-ID: <7D2C4418-9397-4B59-8091-9FDE4ED67836@buechse.de>

Quite a number of people contacted me in the last couple of weeks  
because of problems installing RXTX on OSX. I told you to wait for  
the "official" fix. Well, it has been fixed.

So if you were among the people waiting for the solution, you can now  
download the source rxtx-2.1-7r2.zip from the website. Once unpacked  
dont forget to use "cvs up" to update the files to the latest  
version. You can then open MACOSX_IDE/XCode/ 
LibSerialUniversal.xcodeproj with XCode 2.3 and build the libraries  
that no longer try to create lock files.

Regards,
Joachim


From brian at mbari.org  Mon Jun  5 10:52:43 2006
From: brian at mbari.org (Brian Schlining)
Date: Mon, 5 Jun 2006 09:52:43 -0700
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
Message-ID: <78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>

Hi Joachim,

> [It's kind of tricky to choose "the right" setting. Afaik there is no
> way to compile a universal binary that will work on 10.3 or before.
> So it's either UniversalBinary OR Legacy. Maybe we should have
> different build targets for these different targets?? I would like to
> get some feedback from the Mac developers on this list regarding the
> subject].

I imagine most developers will be compiling on 10.4 (It's the nature  
of the coder...gotta have the latest and greatest) and deploying to  
both 10.3 and 10.4; both of which will run Universal Binaries (see  
http://forums.macrumors.com/showthread.php?t=205348). So it sounds  
like you've covered the majority of users. Still, you know someone's  
going to pipe up about needing RXTX on 10.2 so it would be nice to  
have a target to make a PPC only build.

Just my 2 cents

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/1cac8c39/attachment-0020.html

From dmarkman at mac.com  Mon Jun  5 13:47:50 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Mon, 5 Jun 2006 15:47:50 -0400
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
Message-ID: <686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>

I don't think it will be a problem to run universal binary
on 10.2
however if binary has some calls that aren't implemented in 10.2
then you'll have a problem


On Jun 5, 2006, at 12:52 PM, Brian Schlining wrote:

> Hi Joachim,
>
>> [It's kind of tricky to choose "the right" setting. Afaik there is no
>> way to compile a universal binary that will work on 10.3 or before.
>> So it's either UniversalBinary OR Legacy. Maybe we should have
>> different build targets for these different targets?? I would like to
>> get some feedback from the Mac developers on this list regarding the
>> subject].
>
> I imagine most developers will be compiling on 10.4 (It's the  
> nature of the coder...gotta have the latest and greatest) and  
> deploying to both 10.3 and 10.4; both of which will run Universal  
> Binaries (see http://forums.macrumors.com/showthread.php?t=205348).  
> So it sounds like you've covered the majority of users. Still, you  
> know someone's going to pipe up about needing RXTX on 10.2 so it  
> would be nice to have a target to make a PPC only build.
>
> Just my 2 cents
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/9fafc878/attachment-0020.html

From brian at mbari.org  Mon Jun  5 14:52:41 2006
From: brian at mbari.org (Brian Schlining)
Date: Mon, 5 Jun 2006 13:52:41 -0700
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
Message-ID: <E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>

Hi Dmitry,

> I don't think it will be a problem to run universal binary
> on 10.2
> however if binary has some calls that aren't implemented in 10.2
> then you'll have a problem

You're right...I stand corrected.

Note however, to deploy a universal binary to 10.2 RXTX will need to  
use the 10.2 SDK to build the PPC side. (see http:// 
developer.apple.com/documentation/DeveloperTools/Conceptual/ 
cross_development/UniversalBinaries/chapter_4_section_1.html). I  
haven't been paying close attention to the new locking mechanism used  
by RXTX on the Mac...does 10.2 support it?

Joachim, which SDK will you be using by default for building the Mac  
PPC binaries?

>> Hi Joachim,
>>
>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>> is no
>>> way to compile a universal binary that will work on 10.3 or before.
>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>> different build targets for these different targets?? I would  
>>> like to
>>> get some feedback from the Mac developers on this list regarding the
>>> subject].
>>
>> I imagine most developers will be compiling on 10.4 (It's the  
>> nature of the coder...gotta have the latest and greatest) and  
>> deploying to both 10.3 and 10.4; both of which will run Universal  
>> Binaries (see http://forums.macrumors.com/showthread.php? 
>> t=205348). So it sounds like you've covered the majority of users.  
>> Still, you know someone's going to pipe up about needing RXTX on  
>> 10.2 so it would be nice to have a target to make a PPC only build.

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/153bf50e/attachment-0020.html

From dmarkman at mac.com  Mon Jun  5 19:02:04 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Mon, 5 Jun 2006 21:02:04 -0400
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
Message-ID: <7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>

if Joachim didn't change xcode project setting

/Developer/SDKs/MacOSX10.4u.sdk is used to build universal binary

so it's quite possible that it won't run properly on 10.2

so we have to change the building process, so ppc part will be built
with
/Developer/SDKs/MacOSX10.2.8.sdk

and finally to use lipo utility to build universal binaries

Joachim, did you use some specific locking API that wasn't implemented

in MacOSX10.2.8.sdk?

thanks


On Jun 5, 2006, at 4:52 PM, Brian Schlining wrote:

> Hi Dmitry,
>
>> I don't think it will be a problem to run universal binary
>> on 10.2
>> however if binary has some calls that aren't implemented in 10.2
>> then you'll have a problem
>
> You're right...I stand corrected.
>
> Note however, to deploy a universal binary to 10.2 RXTX will need  
> to use the 10.2 SDK to build the PPC side. (see http:// 
> developer.apple.com/documentation/DeveloperTools/Conceptual/ 
> cross_development/UniversalBinaries/chapter_4_section_1.html). I  
> haven't been paying close attention to the new locking mechanism  
> used by RXTX on the Mac...does 10.2 support it?
>
> Joachim, which SDK will you be using by default for building the  
> Mac PPC binaries?
>
>>> Hi Joachim,
>>>
>>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>>> is no
>>>> way to compile a universal binary that will work on 10.3 or before.
>>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>>> different build targets for these different targets?? I would  
>>>> like to
>>>> get some feedback from the Mac developers on this list regarding  
>>>> the
>>>> subject].
>>>
>>> I imagine most developers will be compiling on 10.4 (It's the  
>>> nature of the coder...gotta have the latest and greatest) and  
>>> deploying to both 10.3 and 10.4; both of which will run Universal  
>>> Binaries (see http://forums.macrumors.com/showthread.php? 
>>> t=205348). So it sounds like you've covered the majority of  
>>> users. Still, you know someone's going to pipe up about needing  
>>> RXTX on 10.2 so it would be nice to have a target to make a PPC  
>>> only build.
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/84790f80/attachment-0020.html

From joachim at buechse.de  Tue Jun  6 02:40:47 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 6 Jun 2006 10:40:47 +0200
Subject: [Rxtx] Building on OS X, Impl Changes
In-Reply-To: <7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
Message-ID: <CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>

Good day!

What's in the XCode project setting?
----------

The xcode project remained pretty much the same as before. I excluded  
the user specific files from CVS and changed some settings. I kept  
all the built targets (you shouldn't change what you don't understand;-)

Currently we the following build targets:
    RXTXComm (java files)
    librxtxParallel.jnilib (usefull on the Mac???)
    libI2C.jnilib (not yet working in RXTX)
    libRS485.jnilib (not yet working in RXTX)
    librxtxSerial.jnilib (1)
    librxtxSerial.jnilib Dynamic (2)
    rxtxSerial (3)
We also have the following build configurations for each target:
    Development
    Default
    Deployment

What was changed in the xcode project from previous versions:
- java.souce=1.3 and java.target=1.1 in RXTXComm settings
- removed copying of build products into installer directory
- removed "(Upgraded)" from build target names

What remains to be changed:
- choosing a "non-debug" Build-configuration as default
- potentially removing "Default"/"Development" Build-configurations
- reducing the number of build targets
- creating 10.2 compatible universal binaries

I suggest, that the build configurations should be reduced to 2  
(Debug/Deployment), possibly even 1 (Debug).
I have not yet found the deeper meaning of the build targets(1)(2) 
(3), it seems to me like they should be reduced into one "doing the  
right thing" or maybe into two "rxtxSerial.jnilib Legacy" (back to  
10.2, universal if possible) and "rxtxSerial.jnilib 10.4 
+" (universal, 10.4+).

Should the code work on 10.2?
----------

Absolutely. The code should work on NextStep, in fact on any BSD  
unix. I would go as far as saying, this code should work on any  
POSSIX based unix. All that was added is the call "ioctl(fd,  
TIOCEXCL)" to request excusivity of the port:

http://gemma.apple.com/documentation/DeviceDrivers/Conceptual/ 
WorkingWSerial/WWSerial_SerialDevs/chapter_2_section_8.html

It is not yet "the perfect solution". Normally an open /dev/tty  
(listen for incomming connection) should be "preemptable" by opening  
a /dev/cu (outgoing connection) for the same port. This is not yet  
implemented as it needs calls outside of POSSIX on OSX.

On "classic" systems (like NextStep) this worked based on the  
"carried detect line". open() on /dev/tty.xxx would block until the  
carrier detect signal was raised. As the device was not "opened"  
opening /dev/cu.xxx worked without a hitch. When they ported to the  
Mac this broke. On Macs the "carier detect" is usually not wired.  
Furthermore FAX modems did no longer raise the line. So the OSX  
implementor defined a new call, which is documented here:

http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00045.html

Best regards,
Joachim




On 06.06.2006, at 03:02, Dmitry Markman wrote:

> if Joachim didn't change xcode project setting
>
> /Developer/SDKs/MacOSX10.4u.sdk is used to build universal binary
>
> so it's quite possible that it won't run properly on 10.2
>
> so we have to change the building process, so ppc part will be built
> with
> /Developer/SDKs/MacOSX10.2.8.sdk
>
> and finally to use lipo utility to build universal binaries
>
> Joachim, did you use some specific locking API that wasn't implemented
>
> in MacOSX10.2.8.sdk?
>
> thanks
>
>
> On Jun 5, 2006, at 4:52 PM, Brian Schlining wrote:
>
>> Hi Dmitry,
>>
>>> I don't think it will be a problem to run universal binary
>>> on 10.2
>>> however if binary has some calls that aren't implemented in 10.2
>>> then you'll have a problem
>>
>> You're right...I stand corrected.
>>
>> Note however, to deploy a universal binary to 10.2 RXTX will need  
>> to use the 10.2 SDK to build the PPC side. (see http:// 
>> developer.apple.com/documentation/DeveloperTools/Conceptual/ 
>> cross_development/UniversalBinaries/chapter_4_section_1.html). I  
>> haven't been paying close attention to the new locking mechanism  
>> used by RXTX on the Mac...does 10.2 support it?
>>
>> Joachim, which SDK will you be using by default for building the  
>> Mac PPC binaries?
>>
>>>> Hi Joachim,
>>>>
>>>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>>>> is no
>>>>> way to compile a universal binary that will work on 10.3 or  
>>>>> before.
>>>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>>>> different build targets for these different targets?? I would  
>>>>> like to
>>>>> get some feedback from the Mac developers on this list  
>>>>> regarding the
>>>>> subject].
>>>>
>>>> I imagine most developers will be compiling on 10.4 (It's the  
>>>> nature of the coder...gotta have the latest and greatest) and  
>>>> deploying to both 10.3 and 10.4; both of which will run  
>>>> Universal Binaries (see http://forums.macrumors.com/ 
>>>> showthread.php?t=205348). So it sounds like you've covered the  
>>>> majority of users. Still, you know someone's going to pipe up  
>>>> about needing RXTX on 10.2 so it would be nice to have a target  
>>>> to make a PPC only build.
>>
>> Brian Schlining
>> Software Engineer
>> http://www.mbari.org
>>
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> Dmitry Markman
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Tue Jun  6 07:01:06 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 6 Jun 2006 15:01:06 +0200
Subject: [Rxtx] Serial port code for OS X, future steps
In-Reply-To: <CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
	<CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
Message-ID: <8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>

I posted the "wrong link". There is a correction here:

    http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00059.html

In fact, the 2.1.7 implementation of RXTX has quite some deficiencies  
on OSX. I have tried to supply some patches that don't interfere to  
much with the existing RXTX code base, but there are limits to what  
can be done with local patches.

There are some very intrusive changes that should be done. Ie proper  
mapping of /dev/tty <-> /dev/cu handling to correct behaviour of  
CommPortOwnershipListener (http://java.sun.com/products/javacomm/ 
reference/api/index.html). I dont think this can be done with  
patches. Hence I think, RXTX should be rewritten from scratch de- 
unifying the native code base (and implementing thread safe code on  
the Java side).


How "should" /dev/tty vs /dev/cu be implemented?

=====
The Unix contract is this: An open /dev/tty.xxx port (incomming)  
should be interrupted/auto-closed when opening /dev/cu.xxx (outgoing)  
[if /dev/tty.xxx is not currently handling a communication].  /dev/ 
cu.xxx and /dev/tty.xxx refer to the same device, so owning  
"exclusively" should block both. This should be respected across all  
applications native or Java.

This contract is realizable on OSX with the existing javax.comm  
interface while also respecting (to the biggest part) the contract  
defined by javax.comm.PortOwnershipListener.

The one point where the suggested implementation "breaks" the  
javax.comm contract, is by the fact that one can loose a /dev/tty  
port without calling close. However, the only option I see is to  
always open serial ports "non-exclusively" which would outrule Java  
as a platform for (dormant) applications waiting for incoming  
connections/faxes/etc. There could be a system property to choose the  
intended behavior.
=====

Here is how it could be done on OSX:

Calling port=ComportIdentifier.open("/dev/cu.xxx") opens and owns the  
port exclusively until port.close() is called.
- Java applications listening with a PortOwnershipListener should get  
a PORT_OWNED event reasonably soon.
- Any further attempt by a Java or native application to open "/dev/ 
cu.xxx" or "/dev/tty.xxx" fails.
- /dev/cu.xxx is for "outgoing" connections, so receiving  
PORT_OWNERSHIP_REQUESTED makes little to no sense. With native  
applications it can not be implemented. For Java applications it  
could be implemented (by a hidden communication channel). I think  
it's not worth bothering. If anyone is willing to give up a port to  
others he should use /dev/tty.xxx instead of /dev/cu.xxx.

Registering a PortOwnershipListener on "/dev/cu.xxx" without opening  
it, uses /dev/tty.xxx (native open()) non-exclusively and polls its  
state. PORT_OWNED and PORT_UNOWNED can be produced.

Calling port=ComportIdentifier.open("/dev/tty.xxx") should open the  
port non-exclusively.
- Adding a SerialPortEventListener and reading from the port could be  
allowed while keeping it non-exclusive.
- When port.getOutputStream() is called, the state should be changed  
to an "exclusive" ownership. This may be configurable via a system  
property.
- To return to the non-exclusive state the port must be closed and  
reopened.
- While non-exclusively opened, opening the corresponding /dev/cu.xxx  
produces a PORT_OWNERSHIP_REQUESTED event. Which should be responded  
by closing the port from within the callback (as described in  
java.comm.PortOwnershipListener). If there is a pending read, it will  
return after the listener finishes (with -1 or "0 bytes read").
- Calling write() on the /dev/tty.xxx after somebody opened /dev/ 
cu.xxx will fail with a descriptive IOException.
- Calling read() on the /dev/tty.xxx after somebody opened /dev/ 
cu.xxx will fail with a descriptive IOException (or potentially  
block, see side notes below).

CommPortIdentifier.getCurrentOwner() can be implemented by an  
external call to lsof.

CommPortIdentifier.isCurrentlyOwned() can be implemented by trying an  
open on the /dev/tty.
- It returns true if the port is currently held "exclusively".
- Whether it should also return true on /dev/tty if /dev/tty is  
already opened non-exclusively might be a system property option. In  
general, having several applications waiting for incoming connections  
on the same port will require an application level "arbitration"  
protocol...

[[side note1: One interesting question is, what happens if the  
process holding /dev/tty non-exclusively ignores  
PORT_OWNERSHIP_REQUESTED. Ie after "loosing" a non-exclusively opened  
"dev/tty.xxx" port to another process. One possible implementation  
is, that the port is "regained" when the other process gives up the  
port. This would mean that in the meanwhile read() returns no data,  
and any changes to the configuration of the port are stored but not  
forwarded. I guess, the safe (and simple) way to do this is to make  
the close() mandatory (ie setting the port into an "awaiting_close"  
state which produces IOExceptions to any other call than close). ]]

[[side note2:  Another interesting question is, what should happen if  
several applications open the same /dev/tty.xxx port "non- 
exclusively" and start to change the settings of the device.]]

Regards,
Joachim



On 06.06.2006, at 10:40, Joachim Buechse wrote:

> Should the code work on 10.2?
> ----------
>
> Absolutely. The code should work on NextStep, in fact on any BSD
> unix. I would go as far as saying, this code should work on any
> POSSIX based unix. All that was added is the call "ioctl(fd,
> TIOCEXCL)" to request excusivity of the port:
>
> http://gemma.apple.com/documentation/DeviceDrivers/Conceptual/
> WorkingWSerial/WWSerial_SerialDevs/chapter_2_section_8.html
>
> It is not yet "the perfect solution". Normally an open /dev/tty
> (listen for incomming connection) should be "preemptable" by opening
> a /dev/cu (outgoing connection) for the same port. This is not yet
> implemented as it needs calls outside of POSSIX on OSX.
>
> On "classic" systems (like NextStep) this worked based on the
> "carried detect line". open() on /dev/tty.xxx would block until the
> carrier detect signal was raised. As the device was not "opened"
> opening /dev/cu.xxx worked without a hitch. When they ported to the
> Mac this broke. On Macs the "carier detect" is usually not wired.
> Furthermore FAX modems did no longer raise the line. So the OSX
> implementor defined a new call, which is documented here:
>
> http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00045.html
>
> Best regards,
> Joachim



From sds at dcs.gla.ac.uk  Tue Jun  6 11:22:45 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Tue, 06 Jun 2006 18:22:45 +0100
Subject: [Rxtx] Correct compile flag for HP iPAQ hx4700 running Familiar
	Linux?
Message-ID: <1149614565.19496.10.camel@addu>

Hi,

I'd like to use RXTX 2.1 on my HP iPAQ hx4700. The iPAQ is running
Familiar Linux 0.8.2 (as I recall), with Blackdown Java 1.3.1.

I can compile and run a test program which uses RXTX on my i686 machine,
and it works fine. But I can't seem to get things working quite right on
my PDA.

I compile the code on the laptop with the following commands:
	./configure --host=arm-gnu-linux && make
... as suggested in a post to this list, albeit some time ago. This
compiles, I transfer the files, set up LD_LIBRARY_PATH and CLASSPATH
variables, and get the following error on the PDA:

sds at ipaq-pxa-2:~# java Test
java.lang.UnsatisfiedLinkError: /usr/local/lib/ext/librxtxSerial.so: /usr/local/lib/ext/librxtxSerial.so: cannot open shared object file: No such file or directory thrown while loading gnu.io.RXTXCommDriver
Exception in thread "main"
java.lang.UnsatisfiedLinkError: /usr/local/lib/ext/librxtxSerial.so: /usr/local/lib/ext/librxtxSerial.so: cannot open shared object file: No such file or directory
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1382)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1290)
        at java.lang.Runtime.loadLibrary0(Runtime.java:749)
        at java.lang.System.loadLibrary(System.java:820)
        at
gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:83)
        at Test.<init>(Test.java:9)
        at Test.main(Test.java:32)
sds at ipaq-pxa-2:~# 

Note that I'm copying the files to /usr/local/lib/ext/ along with the
RXTXcomm.jar file, purely to keep things separate from the rest of the
system while testing. The location of the .so files doesn't seem to have
any bearing on whether "java Test" will succeed or not. The contents of
this directory are:

sds at ipaq-pxa-2:~$ ls /usr/local/lib/ext/
RXTXcomm.jar              librxtxParallel-2.1-7.so  librxtxRS485.so
librxtxSerial-2.1-7.so
librxtxI2C-2.1-7.so       librxtxParallel.so        librxtxRaw-2.1-7.so
librxtxSerial.so
librxtxI2C.so             librxtxRS485-2.1-7.so     librxtxRaw.so
sds at ipaq-pxa-2:~$

Test.java fails on the first real line of code I'm using to test that
things are working, prior to real development, and was carefully pinched
from the web:
Enumeration portIdentifiers = CommPortIdentifier.getPortIdentifiers();


I assume that I've gotten my --host flag wrong way back up there at
the ./configure step. But if that's the case, what should I set it to?
Or am I missing something more obvious?


Cheers,
Stephen Strowes,
University of Glasgow.




From tjarvi at qbang.org  Tue Jun  6 13:39:41 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 6 Jun 2006 13:39:41 -0600 (MDT)
Subject: [Rxtx] Serial port code for OS X, future steps
In-Reply-To: <8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
	<CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
	<8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>
Message-ID: <Pine.LNX.4.61.0606061315070.9856@www>


>>
There are some very intrusive changes that should be done. Ie proper
mapping of /dev/tty <-> /dev/cu handling to correct behaviour of
CommPortOwnershipListener (http://java.sun.com/products/javacomm/
reference/api/index.html). I dont think this can be done with
patches. Hence I think, RXTX should be rewritten from scratch de-
unifying the native code base (and implementing thread safe code on
the Java side).
<<

This appears to be a very small amount of functionality for a total 
rewrite.  The port ownership only needs maybe 3 native calls if it is done 
with native calls at all.

Those features which are not part of the Unix standard(s) can be special 
cased.  I'm not sure /dev/cu is standard.  We can look.  I know linux 
deprecated /dev/cua years ago.

Thread safe Java code is not a platform specific issue.

--
Trent Jarvi
tjarvi at qbang.org


From sds at dcs.gla.ac.uk  Wed Jun  7 12:36:43 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Wed, 07 Jun 2006 19:36:43 +0100
Subject: [Rxtx] Expected RXTX behaviour?
In-Reply-To: <1149703900.30891.19.camel@addu>
References: <1149703900.30891.19.camel@addu>
Message-ID: <1149705403.30891.25.camel@addu>

Apologies, caught the problem. Had to append '\r' to the end of the AT
string. A non obvious but stupid mistake... :-)

Final quick question though: How might I stop the echoing of
outputStream data back into the inputStream? I still see the ATI
commands on the inputStream, along with the output from the device.


Cheers,
S.



On Wed, 2006-06-07 at 19:11 +0100, Stephen Strowes wrote:
> Hi,
> 
> I managed to get RXTX to compile for my iPAQ following my previous post
> to this list. Quick query though:
> 
> I want to be able to issue AT commands to a device, and interpret the
> responses. For this, I assume I do the following, in psuedo-form:
> 
> 	CommPortIdentifier.getPortIdentifiers();
> 	// find the correct device id
> 	serialPort= (SerialPort)portID.open("Test");
> 	// Set parameters and flow control
> 	outputStream= serialPort.getOutputStream();
> 	inputStream=  serialPort.getInputStream();
> 
> ... following this, I spawn a thread to respond to DATA_AVAILABLE events
> on serialPort with inputStream, and occasionally write and flush an
> "ATI" onto the outputStream. Nothing complex, I just want to see it
> work.
> 
> I would have expected inputStream to give the same information back from
> an "ATI" command as minicom provides, but instead inputStream only sees
> the "ATI" I put onto the outputStream.
> 
> Have I missed something?
> 
> 
> Cheers,
> S.
> 



From sds at dcs.gla.ac.uk  Wed Jun  7 12:11:40 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Wed, 07 Jun 2006 19:11:40 +0100
Subject: [Rxtx] Expected RXTX behaviour?
Message-ID: <1149703900.30891.19.camel@addu>

Hi,

I managed to get RXTX to compile for my iPAQ following my previous post
to this list. Quick query though:

I want to be able to issue AT commands to a device, and interpret the
responses. For this, I assume I do the following, in psuedo-form:

	CommPortIdentifier.getPortIdentifiers();
	// find the correct device id
	serialPort= (SerialPort)portID.open("Test");
	// Set parameters and flow control
	outputStream= serialPort.getOutputStream();
	inputStream=  serialPort.getInputStream();

... following this, I spawn a thread to respond to DATA_AVAILABLE events
on serialPort with inputStream, and occasionally write and flush an
"ATI" onto the outputStream. Nothing complex, I just want to see it
work.

I would have expected inputStream to give the same information back from
an "ATI" command as minicom provides, but instead inputStream only sees
the "ATI" I put onto the outputStream.

Have I missed something?


Cheers,
S.




From joachim at buechse.de  Wed Jun  7 09:02:13 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 7 Jun 2006 17:02:13 +0200
Subject: [Rxtx] Update of build process for OSX (XCode project)
Message-ID: <62EC47B1-46BD-4ECA-B9EC-C4061D147CDA@buechse.de>

With the help of Dmitry Markman and Brian Schilling I have updated  
(and largely simplifed) the XCode project file for Mac OS X.

Changes:
- compiles a universal binary library with intel=OSX10.4+, ppc=OSX10.2 
+ support
- compiles the Java sources into a JRE1.1 compatible, compressed jar.

Please test on your configuration, especially if you have computers  
running 10.2/10.3 or intel.

Best regards,
Joachim


From joachim at buechse.de  Wed Jun  7 14:36:37 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 7 Jun 2006 22:36:37 +0200
Subject: [Rxtx] Expected RXTX behaviour?
In-Reply-To: <1149705403.30891.25.camel@addu>
References: <1149703900.30891.19.camel@addu> <1149705403.30891.25.camel@addu>
Message-ID: <D3AD6EAF-27BB-455E-9697-86C1121920C3@buechse.de>

Echoing is a feature of the modem. Try ATE0 which works with most  
"rockwell" compatible modems.

Regards,
Joachim


On 07.06.2006, at 20:36, Stephen Strowes wrote:

> Apologies, caught the problem. Had to append '\r' to the end of the AT
> string. A non obvious but stupid mistake... :-)
>
> Final quick question though: How might I stop the echoing of
> outputStream data back into the inputStream? I still see the ATI
> commands on the inputStream, along with the output from the device.
>
>
> Cheers,
> S.
>
>
>
> On Wed, 2006-06-07 at 19:11 +0100, Stephen Strowes wrote:
>> Hi,
>>
>> I managed to get RXTX to compile for my iPAQ following my previous  
>> post
>> to this list. Quick query though:
>>
>> I want to be able to issue AT commands to a device, and interpret the
>> responses. For this, I assume I do the following, in psuedo-form:
>>
>> 	CommPortIdentifier.getPortIdentifiers();
>> 	// find the correct device id
>> 	serialPort= (SerialPort)portID.open("Test");
>> 	// Set parameters and flow control
>> 	outputStream= serialPort.getOutputStream();
>> 	inputStream=  serialPort.getInputStream();
>>
>> ... following this, I spawn a thread to respond to DATA_AVAILABLE  
>> events
>> on serialPort with inputStream, and occasionally write and flush an
>> "ATI" onto the outputStream. Nothing complex, I just want to see it
>> work.
>>
>> I would have expected inputStream to give the same information  
>> back from
>> an "ATI" command as minicom provides, but instead inputStream only  
>> sees
>> the "ATI" I put onto the outputStream.
>>
>> Have I missed something?
>>
>>
>> Cheers,
>> S.
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From g_petrini at yahoo.it  Thu Jun  8 01:41:58 2006
From: g_petrini at yahoo.it (Giacomo Petrini)
Date: Thu, 8 Jun 2006 09:41:58 +0200 (CEST)
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from FieldTalk
Message-ID: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>

Hi,
I'm evaluating the library for the modbus protocol
from FieldTalk
(http://www.modbusdriver.com/fieldtalk/.
I'm using J2SE 5.0 and RXTX 2.1 on win XP.
The problem is that the modbus lib has a method (the
openProtocol method, but maybe there are others) tha
throws the
javax.comm.UnsupportedCommOperationException.
Now, in RXTX 2.1 the namespace has changed in gnu.io,
so the modbus library doesn't work anymore (it look
for things in javax.comm). I've already sent an email
to fieldtalk to see if they are aware of the problem.
The solution should be to use JavaComm + RXTX 2.0. But
I've read somewhere that JavaComm 2.0 does not work
with Java 5.0 and JavaComm 3.0 does not work with RXTX
2.0 so I don't know what to do.

Any ideas?

Thanks Jack

PS: can you make a CC to my personal email
(g_petrini at yahoo.it) too please?

Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 


From rxtx at tapastda.co.uk  Thu Jun  8 02:27:57 2006
From: rxtx at tapastda.co.uk (rxtx@tapastda.co.uk)
Date: Thu, 08 Jun 2006 09:27:57 +0100
Subject: [Rxtx] Win XP and Infrared based serial port
Message-ID: <4487DF8D.5050807@tapastda.co.uk>

I'm attempting to use RXTX 2.1.7 on Win XP with J2SE 5.0 to communicate with a
GSM mobile using a COM port. A peculiarity that I've seen is that whilst I can
communicate successfully with a mobile which uses an infrared based COM port
using the SUN provided javax.comm (v2.0) I cannot use RXTX because it fails to
read anything from the port (i.e. read timeout always occurs returning zero bytes).

I assumed that this could be the result of flow control problems and thus I've
tried setting either software or hardware based flow control on the port however
this has no affect.

Can you suggest any other port configuration changes which might be required to
make such a port work with RXTX.

Thanks
Stu
-- 
Stuart
Tapastda Limited


From tjarvi at qbang.org  Thu Jun  8 05:17:12 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 8 Jun 2006 05:17:12 -0600 (MDT)
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from
	FieldTalk
In-Reply-To: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
References: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606080504480.9856@www>

On Thu, 8 Jun 2006, Giacomo Petrini wrote:

> Hi,
> I'm evaluating the library for the modbus protocol
> from FieldTalk
> (http://www.modbusdriver.com/fieldtalk/.
> I'm using J2SE 5.0 and RXTX 2.1 on win XP.
> The problem is that the modbus lib has a method (the
> openProtocol method, but maybe there are others) tha
> throws the
> javax.comm.UnsupportedCommOperationException.
> Now, in RXTX 2.1 the namespace has changed in gnu.io,
> so the modbus library doesn't work anymore (it look
> for things in javax.comm). I've already sent an email
> to fieldtalk to see if they are aware of the problem.
> The solution should be to use JavaComm + RXTX 2.0. But
> I've read somewhere that JavaComm 2.0 does not work
> with Java 5.0 and JavaComm 3.0 does not work with RXTX
> 2.0 so I don't know what to do.
>
> Any ideas?
>
> Thanks Jack
>


Hi Jack

There are plans for Sun to rerelease JavaComm 2.0 mentioned in the rxtx 
mail-list archives.  When this happens rxtx will release a current rxtx 
2.0 library that works with it.

There are no dates promised by either side but rxtx will do it as soon as 
possible after Sun's rerelease.  Just to give you a feel for the time 
frame, this started last year and no significant progress has been made. 
There have been friendly talks pointing towards solutions (rerelease 2.0) 
but that does not get your application working today.  rxtx is preparing 
for its second release in gnu.io since then.

--
Trent Jarvi
tjarvi at qbang.org




From jredman at ergotech.com  Thu Jun  8 08:47:23 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 08 Jun 2006 08:47:23 -0600
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from
	FieldTalk
In-Reply-To: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
References: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
Message-ID: <4488387B.6040903@ergotech.com>

You could always try a different library, eg.

http://sourceforge.net/projects/jamod

I've only used the slave side since we have our own implementation of 
Modbus Client (and a host of other PLC protocols).  However the client 
side seems to be pretty well supported and fairly widely used.  Since 
the source is there you could change to gnu.io.

I think I should take more of an interest in this issue.  We generally 
run 1.4.2 on Linux, but also have some J9 and old platforms that we 
support that are basically Personal Java.  5.0 on Linux has some 
horrible MDI bugs, to the point of being unusable.   Sounds as though we 
are going to have code compatibility problems across these platforms.

Jim


Giacomo Petrini wrote:
> Hi,
> I'm evaluating the library for the modbus protocol
> from FieldTalk
> (http://www.modbusdriver.com/fieldtalk/.
> I'm using J2SE 5.0 and RXTX 2.1 on win XP.
> The problem is that the modbus lib has a method (the
> openProtocol method, but maybe there are others) tha
> throws the
> javax.comm.UnsupportedCommOperationException.
> Now, in RXTX 2.1 the namespace has changed in gnu.io,
> so the modbus library doesn't work anymore (it look
> for things in javax.comm). I've already sent an email
> to fieldtalk to see if they are aware of the problem.
> The solution should be to use JavaComm + RXTX 2.0. But
> I've read somewhere that JavaComm 2.0 does not work
> with Java 5.0 and JavaComm 3.0 does not work with RXTX
> 2.0 so I don't know what to do.
> 
> Any ideas?
> 
> Thanks Jack
> 
> PS: can you make a CC to my personal email
> (g_petrini at yahoo.it) too please?
> 
> Chiacchiera con i tuoi amici in tempo reale! 
>  http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  8 18:17:23 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 08 Jun 2006 17:17:23 -0700
Subject: [Rxtx] rxtx access is denied error
Message-ID: <4488BE13.2050706@dupreeinc.com>

Hello,

I have been trying to replace the commapi from sun with rxtx for a 
project that communicates with a serial port that is a USB-Serial 
interface.  To be exact, I am using the FTDI VCP driver with one of 
their modules connected to a windows XP system.

I have the RXTX package working pretty well as long as nothing goes wrong.

If a user disconnects the USB port while my java application is running, 
my application goes into an endless loop with lots of messages in the  
errors stream  like the ones below:

    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(481):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.


I believe when this happens the COM port completely disappears and the 
rxtx driver has a heart attack.  Obviously, the user should not do this, 
but my application needs to ideally, correct the situation or as a worse 
case, terminate with a little dignity.  Currently, I have not figured 
out how to catch this error.

The closest I have come is to trap an exception to my input stream read  
that says "No error in readByte"  This error appears to be outside of 
the endless loop of the errors listed above.

Does anybody have an idea of how to identify and trap this error?  Any 
suggestions on how to gracefully recover from it would be greatly 
appreciated!

Thank you for your time,

Doug Thistlethwaite




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060608/9cfca302/attachment-0020.html

From tjarvi at qbang.org  Thu Jun  8 20:54:17 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 8 Jun 2006 20:54:17 -0600 (MDT)
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <4488BE13.2050706@dupreeinc.com>
References: <4488BE13.2050706@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606082022580.1323@www>

On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I have been trying to replace the commapi from sun with rxtx for a project 
> that communicates with a serial port that is a USB-Serial interface.  To be 
> exact, I am using the FTDI VCP driver with one of their modules connected to 
> a windows XP system.
>
> I have the RXTX package working pretty well as long as nothing goes wrong.
>
> If a user disconnects the USB port while my java application is running, my 
> application goes into an endless loop with lots of messages in the  errors 
> stream  like the ones below:
>
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(481):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>
>
> I believe when this happens the COM port completely disappears and the rxtx 
> driver has a heart attack.  Obviously, the user should not do this, but my 
> application needs to ideally, correct the situation or as a worse case, 
> terminate with a little dignity.  Currently, I have not figured out how to 
> catch this error.
>
> The closest I have come is to trap an exception to my input stream read  that 
> says "No error in readByte"  This error appears to be outside of the endless 
> loop of the errors listed above.
>
> Does anybody have an idea of how to identify and trap this error?  Any 
> suggestions on how to gracefully recover from it would be greatly 
> appreciated!
>

Hi Doug

Sadly I don't have a quick solution for you.

Termios has no knowlage about the JVM so it wont be throwing exceptions 
you can catch.

We can return error and set the error number to something reasonable that 
results in an exception.  The No Error message simply means we did not set 
an error number in termios.c.  Those are the line numbers in the code you 
see.  SerialImp.c realizes it errored but does not know much more yet. 
Everything touching the file descriptor is going to error after the port 
is gone presumably.

We don't currently have a plan in place for vanishing (or appearing) com 
ports.

Another example of what we need to think about is what happens if you 
start your application and then plug in the dongle?  Or what if you unplug 
and then plug it in again?

So in each of these three cases, what would the behavior of the (yet to 
be) correct implementation do?

How will the enumerated ports be handled during these changes?

There can also be hints from the OS that could be taken into 
consideration.

We can probably get some exceptions thrown that make sense and null the 
file descriptor when it happens to prevent io attempts.  That would be a 
crude way to let applications know something strange has happened.

Is anyone else tinkering with this problem?

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  9 01:31:29 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 9 Jun 2006 09:31:29 +0200
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <Pine.LNX.4.61.0606082022580.1323@www>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
Message-ID: <AC6EDDDD-0A64-401F-B16B-E484788CDF4A@buechse.de>

Hello Trent,

I am not tinkering with this on the Source Level - but I think it  
should work pretty much the same way as it currently does in OSX.  
When the port goes away you get an IOException thrown for any read/ 
write. It will no longer be in the list of ports from  
CommPortIdentifier.getPortIdentifiers(). When a port (re-)appears it  
is added to the list. It's up to the application to re-check the list  
from time to time.

On Windows you can't do much better then that, because the ports  
don't have useful names. Which USB "virtual com port" is on which  
COMx depends on the order the devices were added. So reconnecting to  
the same device may mean connecting to another port.

Regarding the exception thrown: it would be nice to use an  
IOException subclass but the Exception message should definetly be  
informative also as most applications may want to keep compatibility  
with javax.comm.

Regards,
Joachim


On 09.06.2006, at 04:54, Trent Jarvi wrote:

> On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:
>
>> Hello,
>>
>> I have been trying to replace the commapi from sun with rxtx for a  
>> project
>> that communicates with a serial port that is a USB-Serial  
>> interface.  To be
>> exact, I am using the FTDI VCP driver with one of their modules  
>> connected to
>> a windows XP system.
>>
>> I have the RXTX package working pretty well as long as nothing  
>> goes wrong.
>>
>> If a user disconnects the USB port while my java application is  
>> running, my
>> application goes into an endless loop with lots of messages in  
>> the  errors
>> stream  like the ones below:
>>
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (481):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>
>>
>> I believe when this happens the COM port completely disappears and  
>> the rxtx
>> driver has a heart attack.  Obviously, the user should not do  
>> this, but my
>> application needs to ideally, correct the situation or as a worse  
>> case,
>> terminate with a little dignity.  Currently, I have not figured  
>> out how to
>> catch this error.
>>
>> The closest I have come is to trap an exception to my input stream  
>> read  that
>> says "No error in readByte"  This error appears to be outside of  
>> the endless
>> loop of the errors listed above.
>>
>> Does anybody have an idea of how to identify and trap this error?   
>> Any
>> suggestions on how to gracefully recover from it would be greatly
>> appreciated!
>>
>
> Hi Doug
>
> Sadly I don't have a quick solution for you.
>
> Termios has no knowlage about the JVM so it wont be throwing  
> exceptions
> you can catch.
>
> We can return error and set the error number to something  
> reasonable that
> results in an exception.  The No Error message simply means we did  
> not set
> an error number in termios.c.  Those are the line numbers in the  
> code you
> see.  SerialImp.c realizes it errored but does not know much more yet.
> Everything touching the file descriptor is going to error after the  
> port
> is gone presumably.
>
> We don't currently have a plan in place for vanishing (or  
> appearing) com
> ports.
>
> Another example of what we need to think about is what happens if you
> start your application and then plug in the dongle?  Or what if you  
> unplug
> and then plug it in again?
>
> So in each of these three cases, what would the behavior of the  
> (yet to
> be) correct implementation do?
>
> How will the enumerated ports be handled during these changes?
>
> There can also be hints from the OS that could be taken into
> consideration.
>
> We can probably get some exceptions thrown that make sense and null  
> the
> file descriptor when it happens to prevent io attempts.  That would  
> be a
> crude way to let applications know something strange has happened.
>
> Is anyone else tinkering with this problem?
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From doug at dupreeinc.com  Fri Jun  9 13:09:58 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 09 Jun 2006 12:09:58 -0700
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <Pine.LNX.4.61.0606082022580.1323@www>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
Message-ID: <4489C786.9050504@dupreeinc.com>


Ideally, it would be nice if it would throw an exception and terminate 
the loop.  I am still trying to figure out how to detect the condition 
and recover form it in some form...  I am getting the "No error in 
readByte" exception in my serialEvent() method after an input stream 
read.  It appears to me that the only graceful recovery is to close the 
port and then reopen it when it becomes available.  I can pass the event 
up to the update method in my main frame, but I still can't close the 
port from within that thread.  Any suggestions on how to pass this event 
to a location where the port can be safely closed?

Re: Slow startup in windows XP
I have been looking into this a little closer and have found out the 
following:
System Windows XP Pro 3GHz dual core with 1GB RAM and NO parallel port.
Starting the SerialDemo included with the commapi using the rxtx instead 
of javax.comm takes 60 seconds.
Starting the SerialDemo using rxrx with the rxtxParallel.dll file 
removed takes about 20 seconds.
Modify initialize in RXRXCommDriver.java to not test the parallel ports 
takes less than 1 second.

It would be nice if the initialize routine could detect the presence of 
rxtxParallel.dll file and just skip the whole process if not present.  
Is there an easy way to check for the presence of this file without 
running the parallel port test?

Doug


 

Trent Jarvi wrote:

>On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:
>...
>  
>
>
>Hi Doug
>
>Sadly I don't have a quick solution for you.
>
>Termios has no knowlage about the JVM so it wont be throwing exceptions 
>you can catch.
>
>We can return error and set the error number to something reasonable that 
>results in an exception.  The No Error message simply means we did not set 
>an error number in termios.c.  Those are the line numbers in the code you 
>see.  SerialImp.c realizes it errored but does not know much more yet. 
>Everything touching the file descriptor is going to error after the port 
>is gone presumably.
>
>We don't currently have a plan in place for vanishing (or appearing) com 
>ports.
>
>Another example of what we need to think about is what happens if you 
>start your application and then plug in the dongle?  Or what if you unplug 
>and then plug it in again?
>
>So in each of these three cases, what would the behavior of the (yet to 
>be) correct implementation do?
>
>How will the enumerated ports be handled during these changes?
>
>There can also be hints from the OS that could be taken into 
>consideration.
>
>We can probably get some exceptions thrown that make sense and null the 
>file descriptor when it happens to prevent io attempts.  That would be a 
>crude way to let applications know something strange has happened.
>
>Is anyone else tinkering with this problem?
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060609/911ed787/attachment-0020.html

From Ugo.Landini at Sun.COM  Fri Jun  2 14:23:47 2006
From: Ugo.Landini at Sun.COM (Ugo Landini)
Date: Fri, 02 Jun 2006 22:23:47 +0200
Subject: [Rxtx] OSX 10.4.7 and usb
Message-ID: <44809E53.2070905@sun.com>

Hi, I have installed the library and the native libraries on OSX 10.4.7. 
Then I have run this simple code:

...
while (portList.hasMoreElements()) {
             portId = (CommPortIdentifier) portList.nextElement();
             System.out.println("-> " + portId.getName() + " Port Type:" 
+ portId.getPortType());
...

and the output is:

Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7

Ports found:
-> /dev/tty.Bluetooth-PDA-Sync Port Type:1
-> /dev/cu.Bluetooth-PDA-Sync Port Type:1
-> /dev/tty.Bluetooth-Modem Port Type:1
-> /dev/cu.Bluetooth-Modem Port Type:1

I can't see any USB ports... with javax.comm on linux I could see the 
/dev/ttyUSB stuff, but that's not the case with OSX. Any idea?

tia

uL


From tod at todbot.com  Sun Jun 11 12:04:37 2006
From: tod at todbot.com (Tod E. Kurt)
Date: Sun, 11 Jun 2006 11:04:37 -0700
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <44809E53.2070905@sun.com>
References: <44809E53.2070905@sun.com>
Message-ID: <E2EB14A1-20A7-4611-8F1A-E3D2ABE41F48@todbot.com>

A dumb question, but: do you have the USB serial adapters plugged  
in?  They only show up in /dev when plugged in.  Also, you can verify  
they exist independent of RXTX by doing something like "ls -l /dev/ 
cu.*".

On Jun 2, 2006, at 1:23 PM, Ugo Landini wrote:

> Hi, I have installed the library and the native libraries on OSX  
> 10.4.7.
> Then I have run this simple code:
>
> ...
> while (portList.hasMoreElements()) {
>              portId = (CommPortIdentifier) portList.nextElement();
>              System.out.println("-> " + portId.getName() + " Port  
> Type:"
> + portId.getPortType());
> ...
>
> and the output is:
>
> Experimental:  JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
>
> Ports found:
> -> /dev/tty.Bluetooth-PDA-Sync Port Type:1
> -> /dev/cu.Bluetooth-PDA-Sync Port Type:1
> -> /dev/tty.Bluetooth-Modem Port Type:1
> -> /dev/cu.Bluetooth-Modem Port Type:1
>
> I can't see any USB ports... with javax.comm on linux I could see the
> /dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>
> tia
>
> uL
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>



From lyon at docjava.com  Sun Jun 11 12:14:50 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Sun, 11 Jun 2006 14:14:50 -0400
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <44809E53.2070905@sun.com>
References: <44809E53.2070905@sun.com>
Message-ID: <p06020444c0b20de7d248@[192.168.1.152]>

>Hi Ugo,

Do you have any USB serial ports (like the keyspan 19-HS) plugged
into the mac?
Thanks!
  - DL


>Hi, I have installed the library and the native libraries on OSX 10.4.7.
>Then I have run this simple code:
>
>...
>while (portList.hasMoreElements()) {
>              portId = (CommPortIdentifier) portList.nextElement();
>              System.out.println("-> " + portId.getName() + " Port Type:"
>+ portId.getPortType());
>...
>
>and the output is:
>
>Experimental:  JNI_OnLoad called.
>Stable Library
>=========================================
>Native lib Version = RXTX-2.1-7
>Java lib Version   = RXTX-2.1-7
>
>Ports found:
>-> /dev/tty.Bluetooth-PDA-Sync Port Type:1
>-> /dev/cu.Bluetooth-PDA-Sync Port Type:1
>-> /dev/tty.Bluetooth-Modem Port Type:1
>-> /dev/cu.Bluetooth-Modem Port Type:1
>
>I can't see any USB ports... with javax.comm on linux I could see the
>/dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>
>tia
>
>uL
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx



From dmarkman at mac.com  Sun Jun 11 14:30:27 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Sun, 11 Jun 2006 16:30:27 -0400
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <p06020444c0b20de7d248@[192.168.1.152]>
References: <44809E53.2070905@sun.com> <p06020444c0b20de7d248@[192.168.1.152]>
Message-ID: <B9C1606B-4339-4564-A175-FE83DFFA7D76@mac.com>

afaik
10.4.7 wasn't released yet
it will soon, no doubts


On Jun 11, 2006, at 2:14 PM, Dr. Douglas Lyon wrote:

>> Hi Ugo,
>
> Do you have any USB serial ports (like the keyspan 19-HS) plugged
> into the mac?
> Thanks!
>   - DL
>
>
>> Hi, I have installed the library and the native libraries on OSX  
>> 10.4.7.
>> Then I have run this simple code:
>>
>> ...
>> while (portList.hasMoreElements()) {
>>              portId = (CommPortIdentifier) portList.nextElement();
>>              System.out.println("-> " + portId.getName() + " Port  
>> Type:"
>> + portId.getPortType());
>> ...
>>
>> and the output is:
>>
>> Experimental:  JNI_OnLoad called.
>> Stable Library
>> =========================================
>> Native lib Version = RXTX-2.1-7
>> Java lib Version   = RXTX-2.1-7
>>
>> Ports found:
>> -> /dev/tty.Bluetooth-PDA-Sync Port Type:1
>> -> /dev/cu.Bluetooth-PDA-Sync Port Type:1
>> -> /dev/tty.Bluetooth-Modem Port Type:1
>> -> /dev/cu.Bluetooth-Modem Port Type:1
>>
>> I can't see any USB ports... with javax.comm on linux I could see the
>> /dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>>
>> tia
>>
>> uL
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman



From tjarvi at qbang.org  Sun Jun 11 18:52:59 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 11 Jun 2006 18:52:59 -0600 (MDT)
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <4489C786.9050504@dupreeinc.com>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
	<4489C786.9050504@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606111845430.7274@www>

On Fri, 9 Jun 2006, Doug Thistlethwaite wrote:

>
> Ideally, it would be nice if it would throw an exception and terminate the 
> loop.  I am still trying to figure out how to detect the condition and 
> recover form it in some form...  I am getting the "No error in readByte" 
> exception in my serialEvent() method after an input stream read.  It appears 
> to me that the only graceful recovery is to close the port and then reopen it 
> when it becomes available.  I can pass the event up to the update method in 
> my main frame, but I still can't close the port from within that thread.  Any 
> suggestions on how to pass this event to a location where the port can be 
> safely closed?
>

I've gone through and cleaned up the termios.c layer.  I need to get to a 
windows machine with a USB dongle and see where the ioctl() is being 
called.  Probably the eventLoop.  But all of the ioctls should probably 
result in an IOException during this condition.

I'll probably finish this up Monday night when I can borrow a USB 
dongle.

There is no point in putting the code into CVS yet.  If you are tinkering 
I can mail the patch.  I think we will want to make a couple fixes in 
SerialImp.c to handle errors before it's ready.

--
Trent Jarvi
tjarvi at qbang.org



From bob_tai2001 at yahoo.com  Mon Jun 12 09:42:14 2006
From: bob_tai2001 at yahoo.com (Bob Tai)
Date: Mon, 12 Jun 2006 08:42:14 -0700 (PDT)
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to RXTX
	again
Message-ID: <20060612154214.58219.qmail@web32804.mail.mud.yahoo.com>


thank you Paul, Joachim, Trent and everyone try to
workout the java comm and Rxtx situation.  At least
now I have something that is solid enough to make my
decision.  

thank you,
     Bob

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From Ralph.Buchfelder at gmx.net  Mon Jun 12 15:30:20 2006
From: Ralph.Buchfelder at gmx.net (Ralph Buchfelder)
Date: Mon, 12 Jun 2006 23:30:20 +0200
Subject: [Rxtx] rxtx binaries or porting to XSCALE Windows Mobile 2003 / 2005
Message-ID: <448DDCEC.7090506@gmx.net>

dear group,

i have been carefully reading your homepage, wiki and archives
but there seems to be no detailled information on porting to Windows 
Mobile/CE.

as far as i understood from the 'porting' section you can do porting to 
winCE. but how? do i only need to obtain the sourcecode (which one?) and 
compile this in Microsoft eMbedded Visual C++ for ARM/Xscale?
Any other ways?


unfortunately i must admit that i do have little linux skills but i have 
made my way through gcc and makefiles. right now i need to implement com 
  communication in a J2ME application and found your website as >the< 
solution.

best regards
Ralph Buchfelder

University of Regensburg
Department of Geography

PS: i dont care about Javacomm compliancy (ie. 2.0 or 2.1) - i just need 
a working serial port API in IBM J9 VM.


From paul.klissner at sun.com  Wed Jun 14 18:12:58 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Wed, 14 Jun 2006 17:12:58 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
Message-ID: <4490A60A.9090305@sun.com>

Hello RxTx community,

I finally think I have a compromise in place that will stand in the gap.

If you go to http://www.sun.com and search for javax.comm, you'll
get taken to a download page, where now users can get a copy of the
comm.jar file out of 2.0.3, along with just a license and a README.

I trust this will suffice until such time as RxTx decided to implement
their own java classes or we can get a JSR going to mitigate some
of the problems (the readme in the comm.jar 2.0.3 zip file
contains my thoughts on that).

Thanks,
Paul



From tjarvi at qbang.org  Wed Jun 14 21:15:35 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 14 Jun 2006 21:15:35 -0600 (MDT)
Subject: [Rxtx] rxtx-2.0-7 (final) src is in CVS
Message-ID: <Pine.LNX.4.61.0606142100500.2742@www>


I wasn't expecting to be working on rxtx 2.0 tonight :)

Thanks go out to Paul Klissner for his work in making the coming release 
of rxtx-2.0-7 possible for users that require package javax.comm on many 
platforms.

Most people know that rxtx 2.0 is for use with Sun's CommAPI 2.0 for 
Solaris or the Generic CommAPI 2.0-3 available for download at Sun.  If 
you need javax.comm packages on many platforms, you are probably 
interested.  If you use rxtx 2.1 in package gnu.io, then you are not going 
to care much.

I've tried to update the rxtx 2.0 src directory in preparation for 
rxtx-2.0-7 (final).  Linux should compile.  Windows will compile if you 
generate your own .def files (I'll generate these tomorrow).  If you have 
some time to do basic testing of the source, I'd appreciate it.  The 
source should be good but you may find classes not found.  This source is 
a backport from rxtx 2.1.

I wanted to get things started so anyone interested on Mac OS X could get 
a head start.

All of this is in CVS.  http://www.rxtx.org/cvs.html

I suspect we will have binaries for testing in a couple days if you are 
unable to compile.   Consider this a smoke test.

--
Trent Jarvi
tjarvi at qbang.org


From legolas.w at gmail.com  Wed Jun 14 22:04:28 2006
From: legolas.w at gmail.com (Legolas Woodland)
Date: Wed, 14 Jun 2006 21:04:28 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <4490A60A.9090305@sun.com>
References: <4490A60A.9090305@sun.com>
Message-ID: <87ee9b170606142104p745fcef0vea622fbc8f528bfc@mail.gmail.com>

is there anything new in this version of javax.comm ?
thanks


On 6/14/06, Paul Klissner <paul.klissner at sun.com> wrote:
>
> Hello RxTx community,
>
> I finally think I have a compromise in place that will stand in the gap.
>
> If you go to http://www.sun.com and search for javax.comm, you'll
> get taken to a download page, where now users can get a copy of the
> comm.jar file out of 2.0.3, along with just a license and a README.
>
> I trust this will suffice until such time as RxTx decided to implement
> their own java classes or we can get a JSR going to mitigate some
> of the problems (the readme in the comm.jar 2.0.3 zip file
> contains my thoughts on that).
>
> Thanks,
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060614/5ff4dfbc/attachment-0020.html

From joachim at buechse.de  Thu Jun 15 07:22:48 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 15 Jun 2006 15:22:48 +0200
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
Message-ID: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>

Good day!

Some of my users report problems using RXTX 2.1.7 on Windows98 to  
communicate with an FTDI FT245BM chip (using their latest VCP  
driver). Either no ports are being shown (ie returned form  
CommPortIdentifier.getPortIdentifiers()) or the transfers fail.

Did anyone run into similar Problems with Win98??

Best regards,
Joachim



From ajmas at sympatico.ca  Thu Jun 15 08:12:28 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Thu, 15 Jun 2006 10:12:28 -0400
Subject: [Rxtx] API change question
Message-ID: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

How closely do you follow the Java Communication API spec? The reason I ask is because I would be interested in augmenting the CommPortIdentifier class to include a getDisplayName() method. By default it would return the same value as getName(), but would provide the possibility of displaying a 'user friendly' name, for platforms where the display name is not the same as the device name. An example of this is on MacOS X, where currently the names seem to be of the form /dev/cu.* and /dev/tty.*, yet what the expects to see is simply the part after the full-stop. Although I could move this logic into the Java code, it would be nice to see it transparent to the Java code.

Andre




From ajmas at sympatico.ca  Thu Jun 15 08:16:22 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Thu, 15 Jun 2006 10:16:22 -0400
Subject: [Rxtx] Package to use
Message-ID: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

While the Java API spec refers to javax.comm, I see that only gnu.io is provide by the rxtx project. Should our projects refer to the gnu.io package or the javax.comm API?

Andre



From joachim at buechse.de  Thu Jun 15 08:45:05 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 15 Jun 2006 16:45:05 +0200
Subject: [Rxtx] API change question
In-Reply-To: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>

Hello Andre,

the /dev/cu and /dev/tty have different semantics on OS X. It is much  
more than a simply naming issue to unify them, see my recent mail to  
the list...

Best regards,
Joachim


On 15.06.2006, at 16:12, Andre-John Mas wrote:

> Hi,
>
> How closely do you follow the Java Communication API spec? The  
> reason I ask is because I would be interested in augmenting the  
> CommPortIdentifier class to include a getDisplayName() method. By  
> default it would return the same value as getName(), but would  
> provide the possibility of displaying a 'user friendly' name, for  
> platforms where the display name is not the same as the device  
> name. An example of this is on MacOS X, where currently the names  
> seem to be of the form /dev/cu.* and /dev/tty.*, yet what the  
> expects to see is simply the part after the full-stop. Although I  
> could move this logic into the Java code, it would be nice to see  
> it transparent to the Java code.
>
> Andre
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From lyon at docjava.com  Thu Jun 15 10:16:29 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Thu, 15 Jun 2006 12:16:29 -0400
Subject: [Rxtx] cu.modem != /dev/ttya on mac.
In-Reply-To: <763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
	<763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>
Message-ID: <p0602046cc0b7378a95b0@[192.168.1.152]>

>Hi All,

I think that Joachim is correct. For the longest time,
I have been trying to figure out how to direct dial using
the cu.modem on the mac under os x.

As a less-than-optimal approach to auto-dialing, I have used
a keyspan USB 19HS adapter, along with an external modem, to
obtain the dialing feature.

Ideally, it would be better to dial with the built-in modem...but that did not
always seem to work, for some reason. Have others had some experience with
using the built in modem for dialing on the mac?

Thanks!
  - Doug


>Hello Andre,
>
>the /dev/cu and /dev/tty have different semantics on OS X. It is much?
>more than a simply naming issue to unify them, see my recent mail to?
>the list...
>
>Best regards,
>Joachim
>



From doug at dupreeinc.com  Thu Jun 15 14:52:50 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 15 Jun 2006 13:52:50 -0700
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
In-Reply-To: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
References: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
Message-ID: <4491C8A2.8090108@dupreeinc.com>

Hi Joachim,

I have been doing a lot with the new FTDI driver with win XP and have 
not had that particular problem.  I did notice that the new driver 
(dated May19th, 2006) is only for XP, Server 2003, and 2000.  Are they 
trying to use the 2.00.00 drivers or the old 1.09.06 version.  I am 
using a FT232R based module, but it uses the same drivers and I assume 
it would have the same problems.  Let me know which driver they are 
using and I can load up a 98 system here and see if  I can duplicate the 
problem.

Doug

Joachim Buechse wrote:

>Good day!
>
>Some of my users report problems using RXTX 2.1.7 on Windows98 to  
>communicate with an FTDI FT245BM chip (using their latest VCP  
>driver). Either no ports are being shown (ie returned form  
>CommPortIdentifier.getPortIdentifiers()) or the transfers fail.
>
>Did anyone run into similar Problems with Win98??
>
>Best regards,
>Joachim
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From matthewhepp at yahoo.com  Thu Jun 15 17:34:47 2006
From: matthewhepp at yahoo.com (Matthew Hepp)
Date: Thu, 15 Jun 2006 16:34:47 -0700 (PDT)
Subject: [Rxtx] Wither the XCode project?
Message-ID: <20060615233447.48064.qmail@web50311.mail.yahoo.com>

Either I don't know how to properly use CVS (entirely possibl), or the XCode
project is not making through the update properly. Doing a "cvs update" against
2.1-7 creates an XCode folder in MACOSX_IDE, and therein a
LibSerialUniversal.xcodeproj, but trying to open it yields a "Unable to Open
Project - Project rxtx-devel/MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj
cannot be opened because it is missing its project.pbxproj file" error. Showing
package contents reveals just the cvs-related files. Perhaps this is why
previous xcode projects have been saved as an sit.hqx - to retain the resource
fork?

Can someone point me in the right direction?

Thanks,

Matt

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Thu Jun 15 19:53:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 19:53:06 -0600 (MDT)
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
In-Reply-To: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
References: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
Message-ID: <Pine.LNX.4.61.0606151944070.23137@www>

On Thu, 15 Jun 2006, Joachim Buechse wrote:

> Good day!
>
> Some of my users report problems using RXTX 2.1.7 on Windows98 to
> communicate with an FTDI FT245BM chip (using their latest VCP
> driver). Either no ports are being shown (ie returned form
> CommPortIdentifier.getPortIdentifiers()) or the transfers fail.
>
> Did anyone run into similar Problems with Win98??
>

Hi Joachim

It has been a long time since I've tested win98.  I know rxtx-2.1-7pre16 
did get testing on win98 with ~jdk 1.3 though.  I wonder if jdks are still 
tested on that platform.

With win98 you usually have older boxes.  They can be short on CPU and 
memory.  Enumeration should work but I could picture runtime performance 
issues on win98.

The enumeration problems could result from other copies of your 
application if various states of decay still holding onto the port.  When 
things go wrong, people also like to open other terminal software to see 
whats going on which can interfere.  You can't open a windows port with 
two apps.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Thu Jun 15 20:08:53 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 20:08:53 -0600 (MDT)
Subject: [Rxtx] API change question
In-Reply-To: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606151954270.23137@www>

On Thu, 15 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> How closely do you follow the Java Communication API spec?

I can explain how this worked in the past.  How we do it in the future is 
open for discussion.

In the past we have tried to follow it as close as possible in gnu.io 
(rxtx 2.1).  We have added extensions but try to discourage their use. 
The extensions are clearly marked as such in the source code and javadocs.

rxtx 2.0 was intended to be a strict implementation of part of the spec. 
We let Sun's interfaces decide what methods can be called. There are 
differences not covered by the spec such as default values.  Thats not 
intentional but rather hard to avoid.

--
Trent Jarvi
tjarvi at qbang.org





From tjarvi at qbang.org  Thu Jun 15 21:09:11 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 21:09:11 -0600 (MDT)
Subject: [Rxtx] Package to use
In-Reply-To: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606152026120.23137@www>

On Thu, 15 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> While the Java API spec refers to javax.comm, I see that only gnu.io is 
> provide by the rxtx project. Should our projects refer to the gnu.io 
> package or the javax.comm API?
>

Hi Andre

Lets see if I can give a fair and balanced answer to that.

If you are starting a new project and want to use RXTX, I would recommend 
using gnu.io.  The community support for gnu.io will not be going away 
anytime soon.  You can switch between gnu.io (2.1) and javax.comm (2.0) 
fairly easily.  They are not intended to be incompatible.  You just change 
package names and libs.

You can also consider the combination of rxtx 2.0 with Sun's commapi 
2.0-3.  This is considered a stop-gap measure by Sun for previous users of 
that combination.  Together rxtx 2.0 and Sun CommAPI 2.0 work in namespace 
javax.comm for programmers.

Finally, you can opt to just use Sun's oferrings in CommAPI 3.0 without 
rxtx.  That would be in namespace javax.comm also.  CommAPI 3.0 may be 
of more interest to you if you are looking at POS with Sun computers. 
Rxtx does not currently support the changes in CommAPI 3.0 or have firm 
plans to do so.  That does not mean we wouldn't implement them.  It just 
means nobody has contributed code yet.

You can't combine rxtx with CommAPI 3.0 for technical reasons that wont 
likely be fixed soon.

It's up to you as far as what you use.  We like to provide the freedom so 
you can choose.  Realistically, we will be supporting gnu.io mainly 
because we have some control over that name space and can support it.

Things may happen in the future that enable rxtx to provide more support 
in the javax namespace but that has not happened yet.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun 16 00:33:06 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 08:33:06 +0200
Subject: [Rxtx] Wither the XCode project?
In-Reply-To: <20060615233447.48064.qmail@web50311.mail.yahoo.com>
References: <20060615233447.48064.qmail@web50311.mail.yahoo.com>
Message-ID: <D30D660F-A49B-464E-AE4C-6B4563893682@buechse.de>

Hello Matthew,

could you please send me the contents of your

   rxtx-devel/CVS
   rxtx-devel/MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj/CVS

directories as a zip to my personal email address. This should  
indicate why the file is not checked out. I can see that it exists on  
the correct branch in the repository, so something must have gone  
wrong during the "cvs update"...

Best regards,
Joachim

On 16.06.2006, at 01:34, Matthew Hepp wrote:

> Either I don't know how to properly use CVS (entirely possibl), or  
> the XCode
> project is not making through the update properly. Doing a "cvs  
> update" against
> 2.1-7 creates an XCode folder in MACOSX_IDE, and therein a
> LibSerialUniversal.xcodeproj, but trying to open it yields a  
> "Unable to Open
> Project - Project rxtx-devel/MACOSX_IDE/XCode/ 
> LibSerialUniversal.xcodeproj
> cannot be opened because it is missing its project.pbxproj file"  
> error. Showing
> package contents reveals just the cvs-related files. Perhaps this  
> is why
> previous xcode projects have been saved as an sit.hqx - to retain  
> the resource
> fork?
>
> Can someone point me in the right direction?



From joachim at buechse.de  Fri Jun 16 10:41:20 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 18:41:20 +0200
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <p06230903c0b88613dca6@[10.0.1.7]>
References: <p06230903c0b88613dca6@[10.0.1.7]>
Message-ID: <03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>

Hello Bob,

until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was  
behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if  
Trent has migrated all recent changes from 2.1 to 2.0.

I have added the XCode project and updated documentation only to the  
gnu.io branch. Once the 2.0 implementation is up to date I will copy  
over the documentation/build files make them work.

Best regards,
Joachim

On 16.06.2006, at 18:07, Bob Jacobsen wrote:

> I'm one of the developers for the JMRI project, which provides  
> model railroad software in Java.  We've been using RXTX to provide  
> serial port access on MacOS X and Linux; we use the old javax.comm  
> 2.0 on Windows, OS/2 and Solaris.  Because of that, we need to stay  
> with RXTX 2.0, not 2.1
>
> We've been using the 2.0-pre17 installer for a long time, but it's  
> not compatible with Intel macs.
>
> Can you point me to where I can find the right files for RXTX 2.0  
> to package with the program?
>
> The current situation is confusing to me.  I've been pointed to  
> recent 2.1 versions (but we need the javax.comm names), to an even  
> older installer, etc.  I've been reading that some versions require  
> an installer, and others don't, but I haven't been able to figure  
> out which (if any) of those are where in CVS.
>
> I'd really appreciate a clear statement of what files to use and  
> what to do with them that I can pass on to our users.
>
> I'm more than happy to put files in the local classpath, have users  
> run an installer, or anything else.  Whatever is easiest for you.
>
> Thanks!  I really appreciate all that you do to keep RXTX working.
>
> Bob
> -- 
> Bob Jacobsen +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG



From joachim at buechse.de  Fri Jun 16 09:59:28 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 17:59:28 +0200
Subject: [Rxtx] Wither the XCode project?
In-Reply-To: <20060616150240.49464.qmail@web50309.mail.yahoo.com>
References: <20060616150240.49464.qmail@web50309.mail.yahoo.com>
Message-ID: <D9935E05-2B83-488D-86DD-42599E229052@buechse.de>

Hello Matthew,

you have checked out the trunk (which is the 2.0.7 javax.comm.xxx  
release). For rxtx-2.1.7 (gnu.io.xxx release) you need to check out  
the branch

      commapi-0-0-1

The easiest way to do this is to download the rxtx src archive,  
unpack it and then do a cvs up inside the decompressed tree.  
Optionally you could do a

      cvs co -r commapi-0-0-1

but this will take much longer!

Best regards,
Joachim

When you do a cvs status it will show the sticky tag.

41:~/jdevelop/rxtx-2.1-7r2 joachim$ cvs status README.OSX
===================================================================
File: README.OSX        Status: Up-to-date

    Working revision:    1.1.2.1
    Repository revision: 1.1.2.1 /usr/local/cvsroot/rxtx-devel/Attic/ 
README.OSX,v
    Sticky Tag:          commapi-0-0-1 (branch: 1.1.2)
    Sticky Date:         (none)
    Sticky Options:      (none)




On 16.06.2006, at 17:02, Matthew Hepp wrote:

> %cvs status README.MACOSX
> ===================================================================
> File: README.MACOSX     Status: Up-to-date
>
>    Working revision:    1.1
>    Repository revision: 1.1     /usr/local/cvsroot/rxtx-devel/ 
> README.MACOSX,v
>    Sticky Tag:          (none)
>    Sticky Date:         (none)
>    Sticky Options:      (none)



From tjarvi at qbang.org  Fri Jun 16 16:31:18 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Fri, 16 Jun 2006 16:31:18 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
Message-ID: <Pine.LNX.4.61.0606161630030.14139@www>

On Fri, 16 Jun 2006, Joachim Buechse wrote:

> Hello Bob,
>
> until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was
> behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if
> Trent has migrated all recent changes from 2.1 to 2.0.
>

The src/ directory and configure.in/configure files should be fine.  I 
have not touched the Mac OS X directories.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sat Jun 17 02:39:55 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sat, 17 Jun 2006 10:39:55 +0200
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <Pine.LNX.4.61.0606161630030.14139@www>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
Message-ID: <350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>

Hello Trent,

apparently the IOEXCL changes have not made it into 2.0. I will add  
them to achieve a minimal diff between 2.0 and 2.1.

One other thing that bugs me for a while...

Shouldn't we replace "if !defined(TIOCSERGETLSR) && !defined(WIN32)"  
by a definition of its own "if defined(DRAINTHREAD)"? I think this  
would make the code clearer for people starting to read it.

Regards,
Joachim


On 17.06.2006, at 00:31, Trent Jarvi wrote:

> On Fri, 16 Jun 2006, Joachim Buechse wrote:
>
>> Hello Bob,
>>
>> until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was
>> behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if
>> Trent has migrated all recent changes from 2.1 to 2.0.
>>
>
> The src/ directory and configure.in/configure files should be fine.  I
> have not touched the Mac OS X directories.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From tropicsu at hotmail.com  Sat Jun 17 09:32:48 2006
From: tropicsu at hotmail.com (Yoke K)
Date: Sat, 17 Jun 2006 15:32:48 +0000
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
Message-ID: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>

Hi,

I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to work with 
MAC OS X.
I am using iTegno 3000 - USB GPRS Modem.

Files in /dev and a symbolic link as follows:

crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 -> tty.usbserial

In my SendMessage.java, I have this line:
CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");

Appreciate any help ?

- Jon


Errors as follows:

>>INFO: SMSLib API for Java / v1.2.2
>>INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>INFO: JRE Version: 1.5.0_06
>>INFO: JRE Impl Version: 1.5.0_06-64
>>INFO: O/S: Mac OS X / ppc / 10.4.6
>>INFO: Using Wavecom (Generic) AT handler.

SendMessage(): Send a message.
  Using SMSLib API for Java v1.2.2

Connecting ..... :
>>INFO: CSerialDriver(): Connecting...
Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
>>INFO: CSerialDriver(): Disconnecting...
gnu.io.NoSuchPortException
        at 
gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:218)
        at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
        at org.smslib.CService.connect(CService.java:197)
        at SendMessage.main(SendMessage.java:38)

_________________________________________________________________
Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/



From tjarvi at qbang.org  Sat Jun 17 10:12:30 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 10:12:30 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
	<350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
Message-ID: <Pine.LNX.4.61.0606171010060.14139@www>

On Sat, 17 Jun 2006, Joachim Buechse wrote:

> Hello Trent,
>
> apparently the IOEXCL changes have not made it into 2.0. I will add
> them to achieve a minimal diff between 2.0 and 2.1.
>

Hi Joachim

As I recall the IOEXCL change was after 2.1-7.  I was just syncing with 
2.1-7.  We can release 2.1-8 and 2.0-8 with the same changes.

> One other thing that bugs me for a while...
>
> Shouldn't we replace "if !defined(TIOCSERGETLSR) && !defined(WIN32)"
> by a definition of its own "if defined(DRAINTHREAD)"? I think this
> would make the code clearer for people starting to read it.
>


Sure.  We can do that for -8.  The TIOCSERGETLSR code should be a special 
case not the expected.  I think only Linux uses it.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Sat Jun 17 10:48:21 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 10:48:21 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <Pine.LNX.4.61.0606171010060.14139@www>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
	<350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
	<Pine.LNX.4.61.0606171010060.14139@www>
Message-ID: <Pine.LNX.4.61.0606171047310.14139@www>

On Sat, 17 Jun 2006, Trent Jarvi wrote:

> On Sat, 17 Jun 2006, Joachim Buechse wrote:
>
>> Hello Trent,
>>
>> apparently the IOEXCL changes have not made it into 2.0. I will add
>> them to achieve a minimal diff between 2.0 and 2.1.
>>
>
> Hi Joachim
>
> As I recall the IOEXCL change was after 2.1-7.  I was just syncing with
> 2.1-7.  We can release 2.1-8 and 2.0-8 with the same changes.
>

We could just move to 2.1-8 and 2.0-8.

--
Trent Jarvi
tjarvi at qbang.org


From brian.t.lamb at gmail.com  Tue Jun 13 13:54:13 2006
From: brian.t.lamb at gmail.com (Brian Lamb)
Date: Tue, 13 Jun 2006 15:54:13 -0400
Subject: [Rxtx] Windows XP Installation
Message-ID: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>

I've not installed Java packages on Windows before and am unsure how to
proceed. All the documentation I've seen provides detailed instructions on
how to install on Linux or Solaris. I was wondering how to install rxtx on
Windows XP.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060613/6f68cd5c/attachment-0020.html

From tjarvi at qbang.org  Sat Jun 17 13:57:03 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 13:57:03 -0600 (MDT)
Subject: [Rxtx] Windows XP Installation
In-Reply-To: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>
References: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0606171356120.14139@www>

On Tue, 13 Jun 2006, Brian Lamb wrote:

> I've not installed Java packages on Windows before and am unsure how to
> proceed. All the documentation I've seen provides detailed instructions on
> how to install on Linux or Solaris. I was wondering how to install rxtx on
> Windows XP.
>

Hi Brian

Which rxtx version are you trying to install?

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sun Jun 18 10:41:44 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sun, 18 Jun 2006 18:41:44 +0200
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
References: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
Message-ID: <8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>

Hello Jon,

 From OSX's standpoint a symbolic link is not a device (as far as I  
know). What stops you from using tty.usbserial? Did you try hard- 
linking?

Regards,
Joachim

On 17.06.2006, at 17:32, Yoke K wrote:
> Hi,
>
> I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to  
> work with
> MAC OS X.
> I am using iTegno 3000 - USB GPRS Modem.
>
> Files in /dev and a symbolic link as follows:
>
> crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
> crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
> lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->  
> tty.usbserial
>
> In my SendMessage.java, I have this line:
> CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
>
> Appreciate any help ?
>
> - Jon
>
>
> Errors as follows:
>
>>> INFO: SMSLib API for Java / v1.2.2
>>> INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>> INFO: JRE Version: 1.5.0_06
>>> INFO: JRE Impl Version: 1.5.0_06-64
>>> INFO: O/S: Mac OS X / ppc / 10.4.6
>>> INFO: Using Wavecom (Generic) AT handler.
>
> SendMessage(): Send a message.
>   Using SMSLib API for Java v1.2.2
>
> Connecting ..... :
>>> INFO: CSerialDriver(): Connecting...
> Experimental:  JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
>>> INFO: CSerialDriver(): Disconnecting...
> gnu.io.NoSuchPortException
>         at
> gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java: 
> 218)
>         at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
>         at org.smslib.CService.connect(CService.java:197)
>         at SendMessage.main(SendMessage.java:38)
>
> _________________________________________________________________
> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Sun Jun 18 10:56:55 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 12:56:55 -0400
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>
References: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
	<8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>
Message-ID: <7B6834E3-F41D-46B6-B979-55466BC73859@sympatico.ca>

Have you been able to get any other software to talk with your
modem? What port is it using? Have tried using the cu.usbserial
instead?

Andre

On 18-Jun-06, at 12:41 , Joachim Buechse wrote:

> Hello Jon,
>
>  From OSX's standpoint a symbolic link is not a device (as far as I
> know). What stops you from using tty.usbserial? Did you try hard-
> linking?
>
> Regards,
> Joachim
>
> On 17.06.2006, at 17:32, Yoke K wrote:
>> Hi,
>>
>> I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to
>> work with
>> MAC OS X.
>> I am using iTegno 3000 - USB GPRS Modem.
>>
>> Files in /dev and a symbolic link as follows:
>>
>> crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
>> crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
>> lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->
>> tty.usbserial
>>
>> In my SendMessage.java, I have this line:
>> CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
>>
>> Appreciate any help ?
>>
>> - Jon
>>
>>
>> Errors as follows:
>>
>>>> INFO: SMSLib API for Java / v1.2.2
>>>> INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>>> INFO: JRE Version: 1.5.0_06
>>>> INFO: JRE Impl Version: 1.5.0_06-64
>>>> INFO: O/S: Mac OS X / ppc / 10.4.6
>>>> INFO: Using Wavecom (Generic) AT handler.
>>
>> SendMessage(): Send a message.
>>   Using SMSLib API for Java v1.2.2
>>
>> Connecting ..... :
>>>> INFO: CSerialDriver(): Connecting...
>> Experimental:  JNI_OnLoad called.
>> Stable Library
>> =========================================
>> Native lib Version = RXTX-2.1-7
>> Java lib Version   = RXTX-2.1-7
>>>> INFO: CSerialDriver(): Disconnecting...
>> gnu.io.NoSuchPortException
>>         at
>> gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:
>> 218)
>>         at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
>>         at org.smslib.CService.connect(CService.java:197)
>>         at SendMessage.main(SendMessage.java:38)
>>
>> _________________________________________________________________
>> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Sun Jun 18 17:33:08 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 19:33:08 -0400
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
Message-ID: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>

Hi,

I am have a program that I wrote in Java to communicate with a  
Bluetooth GPS device. I am
trying to get this working on my Mac, but I keep getting told that:

gnu.io.PortInUseException: Unknown Application

but

portIdentifier.isCurrentlyOwned()

returns false and when I do lsof on the device I am trying to connect  
to, I see no application
using it. As the same time if I go to the command line and use  
minicom I have no issues. The
exception happens with this call:

CommPort commPort = portIdentifier.open(null,0);

Any suggestions?

Andre


From ajmas at sympatico.ca  Sun Jun 18 17:45:11 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 19:45:11 -0400
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
Message-ID: <30245B30-682D-4EAE-8084-8227B719F10D@sympatico.ca>

BTW My code snippet is:

     private InputStream connectToSerial () throws IOException,  
Exception
     {
         InputStream in = null;

         Enumeration portEnum = CommPortIdentifier.getPortIdentifiers();
         while ( portEnum.hasMoreElements() )
         {
             CommPortIdentifier portIdentifier = (CommPortIdentifier)  
portEnum.nextElement();
             System.out.println(portIdentifier.getName() + " - " +  
portIdentifier.getPortType() );
         }

         CommPortIdentifier portIdentifier =  
CommPortIdentifier.getPortIdentifier("/dev/cu.BTGPS-SPPslave-1");
         System.out.println("current owner: " +  
portIdentifier.getCurrentOwner());
         if ( portIdentifier.isCurrentlyOwned() )
         {
             System.out.println("Error: Port is currently in use");
             return null;
         }
         else
         {
             CommPort commPort = portIdentifier.open(this.getClass 
().getName(),2000);

             if ( commPort instanceof SerialPort )
             {
                 SerialPort serialPort = (SerialPort) commPort;
                 serialPort.setSerialPortParams 
(4800,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE 
);
                 in = serialPort.getInputStream();

                 return in;
             }
             else
             {
                 System.out.println("Error: Only serial ports are  
handled.");
             }
         }


         return in;
     }


On 18-Jun-06, at 19:33 , Andr?-John Mas wrote:

> Hi,
>
> I am have a program that I wrote in Java to communicate with a
> Bluetooth GPS device. I am
> trying to get this working on my Mac, but I keep getting told that:
>
> gnu.io.PortInUseException: Unknown Application
>
> but
>
> portIdentifier.isCurrentlyOwned()
>
> returns false and when I do lsof on the device I am trying to connect
> to, I see no application
> using it. As the same time if I go to the command line and use
> minicom I have no issues. The
> exception happens with this call:
>
> CommPort commPort = portIdentifier.open(null,0);
>
> Any suggestions?
>
> Andre
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From joachim at buechse.de  Mon Jun 19 05:54:49 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 13:54:49 +0200
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de>

This is most likely due to a problem with lock files. If you have  
downloaded the binaries of 2.17 rxtx will try to create non-standard  
lock files on OSX. We have since changed the code to use OSX device  
locking - however the binaries have not been updated yet. The 2.18  
release fixing this issue is due shortly.

Regards,
Joachim

On 19.06.2006, at 01:33, Andr?-John Mas wrote:

> Hi,
>
> I am have a program that I wrote in Java to communicate with a
> Bluetooth GPS device. I am
> trying to get this working on my Mac, but I keep getting told that:
>
> gnu.io.PortInUseException: Unknown Application
>
> but
>
> portIdentifier.isCurrentlyOwned()
>
> returns false and when I do lsof on the device I am trying to connect
> to, I see no application
> using it. As the same time if I go to the command line and use
> minicom I have no issues. The
> exception happens with this call:
>
> CommPort commPort = portIdentifier.open(null,0);
>
> Any suggestions?
>
> Andre
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From joachim at buechse.de  Mon Jun 19 06:44:27 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 14:44:27 +0200
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <4490A60A.9090305@sun.com>
References: <4490A60A.9090305@sun.com>
Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>

Hello Paul,

I just downloaded the "generic" javax.comm version now available. A  
first check indicates, that it was compiled with a JDK 1.4 javac  
without setting the target classfile version. In other words in can  
not be loaded by 1.1-1.3 VMs (or PersonalJava).

Do you see any chance to provide a version compiled with classfile  
format 45.3 (ie JVM1.1).

---
52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose  
javax.comm.SerialPort | head -5
Compiled from "SerialPort.java"
public abstract class javax.comm.SerialPort extends javax.comm.CommPort
   SourceFile: "SerialPort.java"
   minor version: 0
   major version: 48
---

Best regards,
Joachim


On 15.06.2006, at 02:12, Paul Klissner wrote:

> Hello RxTx community,
>
> I finally think I have a compromise in place that will stand in the  
> gap.
>
> If you go to http://www.sun.com and search for javax.comm, you'll
> get taken to a download page, where now users can get a copy of the
> comm.jar file out of 2.0.3, along with just a license and a README.
>
> I trust this will suffice until such time as RxTx decided to implement
> their own java classes or we can get a JSR going to mitigate some
> of the problems (the readme in the comm.jar 2.0.3 zip file
> contains my thoughts on that).
>
> Thanks,
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Mon Jun 19 09:11:45 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Mon, 19 Jun 2006 11:11:45 -0400
Subject: [Rxtx] Examples added to Wiki
Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

I have added a couple of examples to the Wiki:

http://rxtx.qbang.org/wiki/index.php/Examples

If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :)

Andre



From paul.klissner at sun.com  Mon Jun 19 10:42:47 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Mon, 19 Jun 2006 09:42:47 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>
References: <4490A60A.9090305@sun.com>
	<03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>
Message-ID: <4496D407.1090609@sun.com>

Joachim Buechse wrote:
> Hello Paul,
> 
> I just downloaded the "generic" javax.comm version now available. A  
> first check indicates, that it was compiled with a JDK 1.4 javac  
> without setting the target classfile version. In other words in can  
> not be loaded by 1.1-1.3 VMs (or PersonalJava).
> 
> Do you see any chance to provide a version compiled with classfile  
> format 45.3 (ie JVM1.1).
> 
> ---
> 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose  
> javax.comm.SerialPort | head -5
> Compiled from "SerialPort.java"
> public abstract class javax.comm.SerialPort extends javax.comm.CommPort
>    SourceFile: "SerialPort.java"
>    minor version: 0
>    major version: 48
> ---

I cannot promise when I can do that. Since we thought we were done
with javax.comm, the build environment got moved around, and right
now it doesn't even compile in it's new home.  I tried and it was
not cooperative at all. I was never impressed with that workspace
(in fact far far from it, it is a mess, which is why I migrated 3.0
to ant and never looked back).  It will take some real determination
for me to rebuild it, and frankly, right now I'm swamped.  If I can
find a bit of time over the next few weeks to do it, and it isn't
too bad an ordeal, I will.

Posting that will give me an excuse to post javax.comm 3.0, Update 2 as
well, while I'm working with the people who put content up on our
download center.  The only reason for a new update to 3.0 is that
I've changed the distribution to provide ispt (Interactive Serial
Port Tool), such that it can be launched as soon as the zip file
is unpacked, via a provided script.  ISPT is a command line
interactive tool for  manipulating one or two serial port,
sending data, managing events, etc... I've found it to be so useful
for doing certain kinds of validation  that I assume others will
find it useful to.  ISPT is already in 3.0u1, but one has to set
up their own classpath and launch it and since few people ever read
the documentation most won't know about it.  I've added the ability
to set stop bits and parity since 3.0u1 too.  But I digress.

Paul


From joachim at buechse.de  Mon Jun 19 11:01:28 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 19:01:28 +0200
Subject: [Rxtx] load mechanism of 2.0x
Message-ID: <CFD1440C-21AA-4D3B-9EA6-270D0FF9D6FC@buechse.de>

Good day,

I am trying to figure out, how the 2.0x distribution interacts with  
Suns implementation of javax.comm.CommPortIdentifier.

1) Apparently one can put javax.comm.properties in {java.home}/lib
2) The javax.comm package also reacts to -Djavax.comm.properties="...."

Looking at the javap output it also seems like CommPortIdentifier  
tries to find it's jar file and load the properties from there??


What I'm really looking for is a solution that allows using  
javax.comm with RXTX without modifying the VM installation. So I  
would prefer not to use 1) but I can't figure out how to use 2).

Any hints are welcome,
Joachim



From bob_tai2001 at yahoo.com  Mon Jun 19 15:00:35 2006
From: bob_tai2001 at yahoo.com (Bob Tai)
Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT)
Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place
	to start?
Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>

Hi, 

I got  rxtx Windows 2000 installed.  I did not use the
"best" way ... I just follow the insturuction and dump
the necessary files into the jre... I know it's "best"
idea, I got lazy didn't want to change my setting to
my Eclipse and classpath.

I was able to modify SimpleWrite.java to print on my
AddMaster serial printer.  I think I am ready to code!
But I need to make sure I can handle exceptions and so
on.  I notice the \samples\NullDriver\  has two files
seems to have some of the require method done, should
I start coding from those file?  I like the idea it
has the "time out" and basic exceptions done.   I am
slowly digging into the samples, but if you think any
of the code from Sun is good to checkout please let me
know.

btw, http://rxtx.qbang.org/wiki/index.php/Examples/
was very helpful, wish there are more examples.

thank you,

    Bob


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Mon Jun 19 15:55:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT)
Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good
 place to start?
In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>
References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606191542260.14139@www>

> I am
> slowly digging into the samples, but if you think any
> of the code from Sun is good to checkout please let me
> know.
>

I think NullDriver.java was an example stub driver for implementing 
something like rxtx.  It has been a while.  Unless they have been updated, 
you will find the examples are very dated.  You can look at how they use 
the port but avoid the GUI and hard coded variables (number of ports for 
instance).

There was no Swing and nobody knew what requirements today's compilers 
would make on code.  The examples worked fine with jdk 1.1 but times have 
changed.

--
Trent Jarvi
tjarvi at qbang.org


From tropicsu at hotmail.com  Mon Jun 19 19:49:08 2006
From: tropicsu at hotmail.com (Yoke K)
Date: Tue, 20 Jun 2006 01:49:08 +0000
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
Message-ID: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>

An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/fa588f00/attachment-0011.html

From ajmas at sympatico.ca  Mon Jun 19 21:14:37 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Mon, 19 Jun 2006 23:14:37 -0400
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>
References: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>
Message-ID: <CA22AB2A-5712-458B-9984-68477C6042AF@sympatico.ca>

Regarding the PortInUseException, I had a similar issue and got
this response from the mailing list:

   http://mailman.qbang.org/pipermail/rxtx/Week-of- 
Mon-20060619/062838.html

Andre
On 19-Jun-06, at 21:49 , Yoke K wrote:

> Hi Andre, Joachim
>
> I have tried using /dev/tty.usbserial and also /dev/cu.usbserial  
> and it also reported error as  "gnu.io.PortInUseException".
>
> The iTegno modem works in windows environment. As I moving around  
> using my ibook and I need to get it work on MAC OS as well.
>
> >> INFO: SMSLib API for Java / v1.2.2
> >> INFO: Using port: /dev/tty.usbserial @ 115200 baud.
> >> INFO: JRE Version: 1.5.0_06
> >> INFO: JRE Impl Version: 1.5.0_06-64
> >> INFO: O/S: Mac OS X / ppc / 10.4.6
> >> INFO: Using Wavecom (Generic) AT handler.
>
> SendMessage(): Send a message.
> Using SMSLib API for Java v1.2.2
>
> Connecting ..... :
> >> INFO: CSerialDriver(): Connecting...
> Experimental: JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version = RXTX-2.1-7
> >> INFO: CSerialDriver(): Disconnecting...
> gnu.io.PortInUseException: Unknown Application
> at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354)
> at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1)
> at org.smslib.CService.connect(CService.java:197)
> at SendMessage.main(SendMessage.java:38)
>
> Thanks.
>
> - Jon
>
>
>
>
> ====================
>
> Hello Jon,
>
> From OSX's standpoint a symbolic link is not a device (as far as I
> know). What stops you from using tty.usbserial? Did you try hard-
> linking?
>
> Regards,
> Joachim
>
>
>
> From:  "Yoke K" <tropicsu at hotmail.com>
> To:  rxtx at qbang.org
> Subject:  RXTX-2.1-7 / MAC OS X / NoSuchPortException
> Date:  Sat, 17 Jun 2006 15:32:48 +0000
> >Hi,
> >
> >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to
> >work with MAC OS X.
> >I am using iTegno 3000 - USB GPRS Modem.
> >
> >Files in /dev and a symbolic link as follows:
> >
> >crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
> >crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
> >lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->
> >tty.usbserial
> >
> >In my SendMessage.java, I have this line:
> >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
> >
> >Appreciate any help ?
> >
> >- Jon
> >
> >
> >Errors as follows:
> >
> >>>INFO: SMSLib API for Java / v1.2.2
> >>>INFO: Using port: /dev/ttyS1 @ 56000 baud.
> >>>INFO: JRE Version: 1.5.0_06
> >>>INFO: JRE Impl Version: 1.5.0_06-64
> >>>INFO: O/S: Mac OS X / ppc / 10.4.6
> >>>INFO: Using Wavecom (Generic) AT handler.
> >
> >SendMessage(): Send a message.
> >  Using SMSLib API for Java v1.2.2
> >
> >Connecting ..... :
> >>>INFO: CSerialDriver(): Connecting...
> >Experimental:  JNI_OnLoad called.
> >Stable Library
> >=========================================
> >Native lib Version = RXTX-2.1-7
> >Java lib Version   = RXTX-2.1-7
> >>>INFO: CSerialDriver(): Disconnecting...
> >gnu.io.NoSuchPortException
> >        at
> >gnu.io.CommPortIdentifier.getPortIdentifier 
> (CommPortIdentifier.java:218)
> >        at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
> >        at org.smslib.CService.connect(CService.java:197)
> >        at SendMessage.main(SendMessage.java:38)
> >
> >_________________________________________________________________
> >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
> >
>
> Find love online with MSN Personals
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Tue Jun 20 02:35:24 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 10:35:24 +0200
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>

Hello everybody,

I have been fighting a bit with the javax.comm version of RXTX the  
last days. I am working on the README .OSX now and try to figure out  
which should be the "suggested" installation.

The facts:
------

- the "generic" comm.jar version of javax.comm which has been made re- 
available tries to load com.sun.comm.SolarisDriver
- this classname can be overridden ONLY by putting a file  
javax.comm.properties in {java.home}/lib
- if it is not overridden and SolarisDriver.class is not found  
CommPortIdentifier will be disfunctional (in particual it is not  
possible to add CommPort's via CommPortIdentifier.add).
- the license distributed with comm.jar does not allow the  
modification/addition of classes in javax.comm (however no mention of  
com.sun...)


What really bothers me is to suggest putting this config file in the  
"global" vm installation. This is particularly ugly on the Mac as  
there are several VM installations and the file may be forgotten.  
Additionally it may create versioning problems. I prefer an  
installation where all files are local to the application (even  
comm.jar).

In my opinion the ideal situation would be:
------

1) The author of a program compiles against javax.comm.
2a) For platforms supported by Sun the user is free to use the 3.0  
comm.jar download from Sun
2b) For platforms not supported by Sun the user adds RXTXComm.jar to  
the classpath of the application (and librxtxSerial.jnilib to the  
application directory). Also he will need the 2.0.3 generic comm.jar  
from Sun.
3) Nobody messes with the global VM installation.

Of course 2a) and 2b) could be handled by the author of the program  
via an appropriate installer. The author could also decide to always  
use RXTX and include the generic javax.comm classes as well as the  
RXTX classes in his application jar. [If he further uses an explicit  
call to System.load() he may even include the jnilib(s) in the jar,  
extract it (based on the platform name) at runtime to a temp file and  
load it from there.]


Suggested solution:
------

We only need to put the following class in the classpath BEFORE Suns  
comm.jar

   package com.sun.comm;
   public class SolarisDriver extends gnu.io.RXTXCommDriver {
   }

This is not "the pure art" (TM). It depends on an implementation  
detail of the generic driver. However, so does the  
javax.comm.properties file - as we have seen when Sun released 3.0.  
It has the following advantages:

- The "generic" javax.comm implementation will happily load this  
class as its primary driver.
- No javax.comm.properties file is required.
- This does not violate the javax.comm license agreement as there is  
no mention of the "com.sun.comm" package in this license agreement at  
all.
- Authors packaging comm.jar with their application can strip out all  
com.sun.comm classes from comm.jar


Please comment!

Joachim



From joachim at buechse.de  Tue Jun 20 02:50:36 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 10:50:36 +0200
Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar
Message-ID: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>

There has been some discussions about the best way to install RXTX  
and where to place files.

I suggest that,

- we include the native libraries for the most common operating  
systems (in a special version of) RXTXcomm.jar
- we add loader code which tries to extract and load the platform  
specific binary at runtime
- on failure the current mechanism remains as a fallback

Wether the current mechanism should have priority (ie loadLibrary  
before load) remains to be discussed.


The advantages of this solution are
  - users of RXTX do not need to worry about java/platform specific  
file placement.
  - authors of applications may fully merge RXTX into their  
application jar (which provides a double-clickable application for  
Windows and OSX, Linux?).

Please comment,
Joachim

PS: Of course the suggested solution is already possible today,  
however relatively few programmers know how to correctly extract a  
binary resource file via the class loader and load it as a native  
library.


From tjarvi at qbang.org  Tue Jun 20 03:58:12 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT)
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
Message-ID: <Pine.LNX.4.61.0606200335190.14139@www>

> 2a) For platforms supported by Sun the user is free to use the 3.0
> comm.jar download from Sun
> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to
> the classpath of the application (and librxtxSerial.jnilib to the
> application directory). Also he will need the 2.0.3 generic comm.jar
> from Sun.

As there are no plans to support CommAPI 3.0 due to the limitations in its 
implementation mentioned before, I would not recommend projects use Sun's 
3.0 comm.jar.  They will lose the freedom to chose their low level 
implementation by being locked into vendor specific modifications.

Projects should chose between platform neutrality in CommAPI 2.0 and 
reduced platform neutrality in commapi 3.0.  Projects should also strongly 
consider the fact that the 2.0 comm.jar targets only a reduced number of 
JVMs.

Projects can go with rxtx 2.1 or other packages but should probably only 
consider using Sun CommAPI with rxtx if they did so in the past.  They 
should take steps to no longer depend upon this option being available.

> Suggested solution:
> ------
>
> We only need to put the following class in the classpath BEFORE Suns
> comm.jar
>
>   package com.sun.comm;
>   public class SolarisDriver extends gnu.io.RXTXCommDriver {
>   }
>
> This is not "the pure art" (TM). It depends on an implementation
> detail of the generic driver. However, so does the
> javax.comm.properties file - as we have seen when Sun released 3.0.
> It has the following advantages:
>
> - The "generic" javax.comm implementation will happily load this
> class as its primary driver.
> - No javax.comm.properties file is required.
> - This does not violate the javax.comm license agreement as there is
> no mention of the "com.sun.comm" package in this license agreement at
> all.
> - Authors packaging comm.jar with their application can strip out all
> com.sun.comm classes from comm.jar
>

I would not encourage people to place packages in the com.sun.comm 
namespace.  Authors using Sun's commapi 2.0 should just realize it is 
greatly limited in practical utility and consider moving to something that 
isn't being rescued from EOL.

The primary focus of this release is projects previously depending upon 
Sun CommAPI + RXTX.  There are no plans at this time to provide future 
support in this arrangement due to technical incompatabilities we have no 
control over in commapi 3.0 and limited utility of Sun's generic comm.jar 
in commapi 2.0 offered.  Projects should be aware of this so they can make 
appropriate plans.

--
Trent Jarvi
tjarvi at qbang.org


From paul.klissner at sun.com  Tue Jun 20 05:24:00 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Tue, 20 Jun 2006 04:24:00 -0700
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
In-Reply-To: <Pine.LNX.4.61.0606200335190.14139@www>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
	<Pine.LNX.4.61.0606200335190.14139@www>
Message-ID: <4497DAD0.10803@sun.com>

Trent Jarvi wrote:
>> 2a) For platforms supported by Sun the user is free to use the 3.0
>> comm.jar download from Sun
>> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to
>> the classpath of the application (and librxtxSerial.jnilib to the
>> application directory). Also he will need the 2.0.3 generic comm.jar
>> from Sun.
> 
> As there are no plans to support CommAPI 3.0 due to the limitations in its 
> implementation mentioned before, I would not recommend projects use Sun's 
> 3.0 comm.jar.  They will lose the freedom to chose their low level 
> implementation by being locked into vendor specific modifications.
> 
> Projects should chose between platform neutrality in CommAPI 2.0 and 
> reduced platform neutrality in commapi 3.0.  Projects should also strongly 
> consider the fact that the 2.0 comm.jar targets only a reduced number of 
> JVMs.

Well, that's a little ambiguous because the API is the same
either way.  We're talking about Sun's implementation vs.
other implementations.
> 
> Projects can go with rxtx 2.1 or other packages but should probably only 
> consider using Sun CommAPI with rxtx if they did so in the past.  They 
> should take steps to no longer depend upon this option being available.

3.0 is platform centric because there is a need to add some
platform awareness to Sun's implementation, and the choices
for how to do that are limited by the constraints of the API,
as mentioned in the javax.comm 2.0.3 comm.jar download's README.

I am really advocating getting a JSR open (http://www.jcp.org)
to push a new comm API that is more pluggable, platform neutral
and addresses some of the deficiencies of the current API. Then
we can achieve the optimal of platform neutrality while
simulataneously allowing the API to flexibly adapt to
heterogeneous environments.

This is not a question of attitude, this is an issue of resources,
time and commitment.  The current owners of javax.comm within
Sun would like nothing better than to see the ideal reached for
the API and a model that will extend well beyond the foreseeable
future and work for the industry overall.



> 
>> Suggested solution:
>> ------
>>
>> We only need to put the following class in the classpath BEFORE Suns
>> comm.jar
>>
>>   package com.sun.comm;
>>   public class SolarisDriver extends gnu.io.RXTXCommDriver {
>>   }
>>
>> This is not "the pure art" (TM). It depends on an implementation
>> detail of the generic driver. However, so does the
>> javax.comm.properties file - as we have seen when Sun released 3.0.
>> It has the following advantages:
>>
>> - The "generic" javax.comm implementation will happily load this
>> class as its primary driver.
>> - No javax.comm.properties file is required.
>> - This does not violate the javax.comm license agreement as there is
>> no mention of the "com.sun.comm" package in this license agreement at
>> all.
>> - Authors packaging comm.jar with their application can strip out all
>> com.sun.comm classes from comm.jar
>>
> 
> I would not encourage people to place packages in the com.sun.comm 
> namespace.  Authors using Sun's commapi 2.0 should just realize it is 
> greatly limited in practical utility and consider moving to something that 
> isn't being rescued from EOL.
> 
> The primary focus of this release is projects previously depending upon 
> Sun CommAPI + RXTX.  There are no plans at this time to provide future 
> support in this arrangement due to technical incompatabilities we have no 
> control over in commapi 3.0 and limited utility of Sun's generic comm.jar 
> in commapi 2.0 offered.  Projects should be aware of this so they can make 
> appropriate plans.

Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86,
or need the powerful portmapping features in javax.com 3.0, or would like to
acquire the Interactive Serial Port Test utility.

-Paul


From paul.klissner at sun.com  Tue Jun 20 05:33:44 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Tue, 20 Jun 2006 04:33:44 -0700
Subject: [Rxtx] Suggested installation RXTX 2.0x...
In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
Message-ID: <4497DD18.70207@sun.com>

Joachim Buechse wrote:
> Hello everybody,
> 
> I have been fighting a bit with the javax.comm version of RXTX the  
> last days. I am working on the README .OSX now and try to figure out  
> which should be the "suggested" installation.
> 
> The facts:
> ------
> 
> - the "generic" comm.jar version of javax.comm which has been made re- 
> available tries to load com.sun.comm.SolarisDriver
> - this classname can be overridden ONLY by putting a file  
> javax.comm.properties in {java.home}/lib
> - if it is not overridden and SolarisDriver.class is not found  
> CommPortIdentifier will be disfunctional (in particual it is not  
> possible to add CommPort's via CommPortIdentifier.add).
> - the license distributed with comm.jar does not allow the  
> modification/addition of classes in javax.comm (however no mention of  
> com.sun...)
> 
> 
> What really bothers me is to suggest putting this config file in the  
> "global" vm installation. This is particularly ugly on the Mac as  
> there are several VM installations and the file may be forgotten.  
> Additionally it may create versioning problems. I prefer an  
> installation where all files are local to the application (even  
> comm.jar).
> 
> In my opinion the ideal situation would be:
> ------
> 
> 1) The author of a program compiles against javax.comm.
> 2a) For platforms supported by Sun the user is free to use the 3.0  
> comm.jar download from Sun
> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to  
> the classpath of the application (and librxtxSerial.jnilib to the  
> application directory). Also he will need the 2.0.3 generic comm.jar  
> from Sun.
> 3) Nobody messes with the global VM installation.
> 
> Of course 2a) and 2b) could be handled by the author of the program  
> via an appropriate installer. The author could also decide to always  
> use RXTX and include the generic javax.comm classes as well as the  
> RXTX classes in his application jar. [If he further uses an explicit  
> call to System.load() he may even include the jnilib(s) in the jar,  
> extract it (based on the platform name) at runtime to a temp file and  
> load it from there.]
> 

This was how the Sun implementation originated (I did not write
that code).  I completely agree, and I fixed the whole conf file
locating mechanism in 3.0 to avoid the problems youmentioned.
However, I was unaware of how RxTx was using Sun's implementation,
so I didn't architect it in such a way as to avoid namespace pollution
in the native space in for the backend provider.  In retrospect,
I should have done that differently just as a design principle,
but at this point I don't have the spare cycles to get that all
re-factored.  Further, I'm loathe to do it, because the whole
thing will still be an under-the-hood hack due to the constraints
of the API itself.

Paul





From brian at mbari.org  Tue Jun 20 10:23:54 2006
From: brian at mbari.org (Brian Schlining)
Date: Tue, 20 Jun 2006 09:23:54 -0700
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>


Hi Joachim,

> There has been some discussions about the best way to install RXTX
> and where to place files.
>
> I suggest that,
>
> - we include the native libraries for the most common operating
> systems (in a special version of) RXTXcomm.jar
> - we add loader code which tries to extract and load the platform
> specific binary at runtime
> - on failure the current mechanism remains as a fallback

I like your suggestion. However, my understanding is that in general  
the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH  
(Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to  
be loaded by the JVM. The alternative is to point to your native lib  
directory using -Djava.library.path=/my/dir/with/native/libs when you  
launch the JVM. So, I'm very interested to know how you're planning  
to work around this.

> PS: Of course the suggested solution is already possible today,
> however relatively few programmers know how to correctly extract a
> binary resource file via the class loader and load it as a native
> library.

So how do you use it to dynamically load a native lib? I've read that  
you can't really modify the java.library.path after the JVM has been  
launched. (http://forum.java.sun.com/thread.jspa? 
threadID=627890&tstart=90)

Thanks

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0020.html

From joachim at buechse.de  Tue Jun 20 09:20:29 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 17:20:29 +0200
Subject: [Rxtx] 2.0x in sync with 2.1x
Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>

I have added most of the changes from the 2.1 branch to the 2.0 branch.

This includes
  - correction of illegal javadoc comments
  - implementation errors in handling of Thread.interrupt in  
RXTXPort.java
  - MacOS X locking without lock files/special user groups
  - XCode project which builds a universal binary library
  - updated documentation for OSX

I have done some minimal testing (only G4).
[Trent: there are still some changes you made for specific baud  
rates. I will not sync this, as I can not test them. From my  
perspective we are ready for 2.08/2.18]

The updated documentation can be found in the file README.OSX. Here  
it is:

------------------------ Required files -----------------------

To use or compile RXTX 2.0.x you need to downlad the "generic"  
version (2.0.3)
of the javax.comm implementation from Sun. The zip you download  
contains an
archive comm.jar which is required:

- To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar

- To run the app you will need comm.jar in the classpath or in  
{java.lib.path}


------------------------ Installation on MacOSX -----------------------

WARNING: Please read this section until the end.

---
Preparation
---

You may want to spare your users the burden of modifying the global VM
installation. OSX has several different VM versions installed by  
default and
regular users will be unable to figure out which version will load your
application.

If you provide the class

package com.sun.comm;
public class SolarisDriver extends gnu.io.RXTXCommDriver {
}

and make sure, that it is present in the classpath before Suns  
"generic" comm.jar
your users can skip the following step:

Create a file named
    javax.comm.properties
in the directory
    /System/Library/Frameworks/JavaVM.framework/Home/lib/
which contains (only) the following line (no leading space):
    Driver=gnu.io.RXTXCommDriver



----
The unsafe way of using RXTX on OS X:
----

RXTX can be installed by putting the files
   libSerial.jnilib
   RXTXcomm.jar
   comm.jar
into the folder
   /Library/Java/Extensions

This is NOT RECOMMENDED as it creates versioning conflicts among  
applications.
However you may be forced to install it this way if an application  
was written
for Windows or Linux, requires RXTX and you are not able to change  
its starter.


----
The safe way of using RXTX on OS X:
----

Make sure that you have no (older) version of RXTX installed in
   /Library/Java/Extensions
   /System/Library/Java/Extensions
   /usr/lib/java

Put
   libSerial.jnilib
in the directory of the application (the JavaVM will find it there). Add
   RXTXComm.jar
   comm.jar
to the application classpath or include the classes in the  
application jar.
(Some applications already include the RXTX classes in their  
application jar,
in which case only the file libSerial.jnilib is required).


----
History
----

Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation  
of lockfiles
required special permissions for the user executing an application  
based on RXTX.
To simplify the setup RXTX came with an installer modifying group  
permissions
and installing RXTX in the global location /Library/Java/Extensions.  
However
this was prune to versioning conflicts and is no longer recommended.

--------------------- Build instructions for OSX XCode  
-------------------

contributed by Joachim Buechse <joachim at buechse.de>
original version by Dmitry Markman <dmarkman at mac.com>

System requirements for building:
MacOSX 10.4
XCode 2.3

   open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj
   choose libSerial.jnilib target
   build

After the build you will find RXTXcomm.jar and libSerial.jnilib files  
in the
directory build/Development.

In case you can't find RXTXcomm.jar build the RXTXcomm target manually.
In case of (serious) problems feel free to contact joachim at buechse.de .



From tjarvi at qbang.org  Tue Jun 20 22:01:45 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT)
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
Message-ID: <Pine.LNX.4.61.0606202127270.14139@www>

> ---
> Preparation
> ---
>
> You may want to spare your users the burden of modifying the global VM
> installation. OSX has several different VM versions installed by
> default and
> regular users will be unable to figure out which version will load your
> application.
>
> If you provide the class
>
> package com.sun.comm;
> public class SolarisDriver extends gnu.io.RXTXCommDriver {
> }
>
> and make sure, that it is present in the classpath before Suns
> "generic" comm.jar
> your users can skip the following step:

Hi Joachim

With regards to the above, I have not seen that we have Sun's OK to 
promote that.  I'm not very comfortable with the distribution 
documentation advocating this without Sun agreeing.

I see your point but I'd rather not actively promote putting classes in 
Sun's namespace without permission if you don't mind.  This isn't about 
what is in a license.

I'll go through the code tomorrow night.  It was a late night at work 
today.  There is also a w32 fix comming for people opening and closing 
multiple ports.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Wed Jun 21 01:56:45 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 21 Jun 2006 09:56:45 +0200
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <Pine.LNX.4.61.0606202127270.14139@www>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
	<Pine.LNX.4.61.0606202127270.14139@www>
Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>

Hello Trent,

I guess we will not get an explicit OK from Sun for such a hack. I  
think Paul has made it pretty clear, that he does not have the  
resources to modify the 2.x or 3.x code for the needs of RXTX. I'm  
not thrilled but OK with the current API. Hence I dont agree with  
Paul's idea to start a new JSR to fix the implementation - but that's  
mainly because I dont have the time to push it. According to their  
Readme Sun sees no business case in having cross platform support for  
javax.comm - that is sad but it's none of my business. However I  
prefer to program versus javax.comm in my projects as this gives an  
advanced user the chance to exchange the provider without access to  
the code.

I interpret Pauls reponse to my original "Request for comment" as a  
quiet acceptance of the hack I propose (he did respond, but not at  
all to the sun.comm namespace suggestion). This is certainly not  
something we should put into RXTXcomm.jar but hinting a work around  
for implementation errors should be allowed. That's why I've choosen  
the wording "You may want to spare" and "If you provide". The company  
I worked for has choosen similar hacks for years to fix bugs in swing  
for JDK1.1 applications. Those hacks were usually included in their  
own swingpatch.jar.

Having said all that - I do not take it as an insult if you remove  
the paragraph from the Readme. I appreciate that you notified me  
before. It would be interesting to hear some more opinions from the  
list members...

Best regards,
Joachim


On 21.06.2006, at 06:01, Trent Jarvi wrote:

>> ---
>> Preparation
>> ---
>>
>> You may want to spare your users the burden of modifying the  
>> global VM
>> installation. OSX has several different VM versions installed by
>> default and
>> regular users will be unable to figure out which version will load  
>> your
>> application.
>>
>> If you provide the class
>>
>> package com.sun.comm;
>> public class SolarisDriver extends gnu.io.RXTXCommDriver {
>> }
>>
>> and make sure, that it is present in the classpath before Suns
>> "generic" comm.jar
>> your users can skip the following step:
>
> Hi Joachim
>
> With regards to the above, I have not seen that we have Sun's OK to
> promote that.  I'm not very comfortable with the distribution
> documentation advocating this without Sun agreeing.
>
> I see your point but I'd rather not actively promote putting  
> classes in
> Sun's namespace without permission if you don't mind.  This isn't  
> about
> what is in a license.
>
> I'll go through the code tomorrow night.  It was a late night at work
> today.  There is also a w32 fix comming for people opening and closing
> multiple ports.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Wed Jun 21 02:03:33 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 21 Jun 2006 10:03:33 +0200
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
	<6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
Message-ID: <BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>

See System.load(String) [it's also mentioned under the URL you posted].

Regards,
Joachim


On 20.06.2006, at 18:23, Brian Schlining wrote:

> So how do you use it to dynamically load a native lib? I've read  
> that you can't really modify the java.library.path after the JVM  
> has been launched. (http://forum.java.sun.com/thread.jspa? 
> threadID=627890&tstart=90)
>
> Thanks
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From baris.ozkan at elikasu.com.tr  Wed Jun 21 07:58:06 2006
From: baris.ozkan at elikasu.com.tr (Baris)
Date: Wed, 21 Jun 2006 16:58:06 +0300
Subject: [Rxtx] RS 232 ..additional parameters
Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>

Hi,
 
Currently i am developing an application that requires to connect to a
remote rs232 device through  a dialup connection.
 
My problem is that the communication needs several more connection
parameters (i extracted that information from the vendor's dll , listed at
the end of the message)
 
I explored rxtx API and src files and could not find methods to set a
majority  of the parameters.
Am i missing any point or does rxtx is limited to soem standard set of
functionality(e.g. commAPI)? How  is it possible ,if i want to put some
extensions(???) to current rxtx implementation?
 
I am not very good at rs232 programming so excuse me if this message  is
boring one.
 
Thanx
 
Baris Ozkan
 
 
A Listing of Parameters:
 
 
typedef struct _DCB {

DWORD DCBlength; /* sizeof(DCB) */

DWORD BaudRate; /* Baudrate at which running */

DWORD fBinary: 1; /* Binary Mode (skip EOF check) */

DWORD fParity: 1; /* Enable parity checking */

DWORD fOutxCtsFlow:1; /* CTS handshaking on output */

DWORD fOutxDsrFlow:1; /* DSR handshaking on output */

DWORD fDtrControl:2; /* DTR Flow control */

DWORD fDsrSensitivity:1; /* DSR Sensitivity */

DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */

DWORD fOutX: 1; /* Enable output X-ON/X-OFF */

DWORD fInX: 1; /* Enable input X-ON/X-OFF */

DWORD fErrorChar: 1; /* Enable Err Replacement */

DWORD fNull: 1; /* Enable Null stripping */

DWORD fRtsControl:2; /* Rts Flow control */

DWORD fAbortOnError:1; /* Abort all reads and writes on Error */

DWORD fDummy2:17; /* Reserved */

WORD wReserved; /* Not currently used */

WORD XonLim; /* Transmit X-ON threshold */

WORD XoffLim; /* Transmit X-OFF threshold */

BYTE ByteSize; /* Number of bits/byte, 4-8 */

BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */

BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */

char XonChar; /* Tx and Rx X-ON character */

char XoffChar; /* Tx and Rx X-OFF character */

char ErrorChar; /* Error replacement char */

char EofChar; /* End of Input character */

char EvtChar; /* Received Event character */

WORD wReserved1; /* Fill for now. */

} DCB, *LPDCB;

typedef struct _COMMTIMEOUTS {

DWORD ReadIntervalTimeout; /* Maximum time between read chars. */

DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */

DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */

DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */

DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */

} COMMTIMEOUTS,*LPCOMMTIMEOUTS;

dcb.fOutX = FALSE;

dcb.fInX = FALSE;

dcb.fOutxCtsFlow = FALSE;

dcb.fBinary = TRUE;

dcb.fRtsControl = RTS_CONTROL_ENABLE;

SetCommState(hComm , &dcb ); 

COMMTIMEOUTS commTimeOut;

GetCommTimeouts(hComm, &commTimeOut );

commTimeOut.WriteTotalTimeoutMultiplier = 1; 

commTimeOut.WriteTotalTimeoutConstant = 18; 

// commTimeOut.ReadIntervalTimeout = 28; 

commTimeOut.ReadIntervalTimeout = 0; 

// commTimeOut.ReadTotalTimeoutMultiplier = 184; 

commTimeOut.ReadTotalTimeoutMultiplier = 300; 

// commTimeOut.ReadTotalTimeoutConstant = 1200;

commTimeOut.ReadTotalTimeoutConstant = 1200;

SetCommTimeouts(hComm, &commTimeOut);

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0020.html

From ajmas at sympatico.ca  Wed Jun 21 08:14:26 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Wed, 21 Jun 2006 10:14:26 -0400
Subject: [Rxtx] When is 2.18 planned for?
Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

Just curious as to know if there is a target date for 2.18?

Andre



From brian at mbari.org  Wed Jun 21 09:36:00 2006
From: brian at mbari.org (Brian Schlining)
Date: Wed, 21 Jun 2006 08:36:00 -0700
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
	<6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
	<BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>
Message-ID: <A21C9BC0-7894-4B08-AC82-44E11AB3D461@mbari.org>

Ha!!

I suppose I should read my own postings. ;-)

Thanks
B

On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote:

> See System.load(String) [it's also mentioned under the URL you  
> posted].
>
> Regards,
> Joachim
>
>
> On 20.06.2006, at 18:23, Brian Schlining wrote:
>
>> So how do you use it to dynamically load a native lib? I've read
>> that you can't really modify the java.library.path after the JVM
>> has been launched. (http://forum.java.sun.com/thread.jspa?
>> threadID=627890&tstart=90)

Brian Schlining
Software Engineer
http://www.mbari.org




From ajmas at sympatico.ca  Wed Jun 21 16:41:28 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Wed, 21 Jun 2006 18:41:28 -0400
Subject: [Rxtx] CVS build question
Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X:

 The JCL extension to RxTx requires comm.jar
 If you intend to use RxTx for commapi support comm.jar
 needs to be located in  /System/Library/Frameworks/JavaVM.framework/
  Versions/1.5/Home/lib/ext/comm.jar

I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me.

On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native).

Andre






From tjarvi at qbang.org  Wed Jun 21 18:00:04 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT)
Subject: [Rxtx] CVS build question
In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606211756310.14139@www>

On Wed, 21 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> Is the CVS repository meant to build for gnu.io or javax.comm? I ask 
> this, because I see the following when calling ./configure from MacOS X:
>
> The JCL extension to RxTx requires comm.jar
> If you intend to use RxTx for commapi support comm.jar
> needs to be located in  /System/Library/Frameworks/JavaVM.framework/
>  Versions/1.5/Home/lib/ext/comm.jar
>
> I am wanting to build for the gnu.io package, since I want to jump ahead 
> and see if the changes, intended for 2.18 for MacOS X, work for me.
>
> On a side note /Library/Java/Extensions should be included as a valid 
> search path for the JAR, since this is where Apple recommends placing 
> third party extensions (both Java and native).
>

rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel"
rxtx 2.0 src is obtained with "cvs checkout rxtx-devel"

rxtx 2.1 is a complete package in namespace gnu.io
rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 18:02:23 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT)
Subject: [Rxtx] When is 2.18 planned for?
In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606211800180.14139@www>

On Wed, 21 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> Just curious as to know if there is a target date for 2.18?
>

Hi Andre

"When it is ready" :)

Probably this weekend.  Maybe sooner.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 18:10:18 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT)
Subject: [Rxtx] RS 232 ..additional parameters
In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>
References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>
Message-ID: <Pine.LNX.4.61.0606211805010.14139@www>

On Wed, 21 Jun 2006, Baris wrote:

> Hi,
>
> Currently i am developing an application that requires to connect to a
> remote rs232 device through  a dialup connection.
>
> My problem is that the communication needs several more connection
> parameters (i extracted that information from the vendor's dll , listed at
> the end of the message)
>
> I explored rxtx API and src files and could not find methods to set a
> majority  of the parameters.
> Am i missing any point or does rxtx is limited to soem standard set of
> functionality(e.g. commAPI)? How  is it possible ,if i want to put some
> extensions(???) to current rxtx implementation?
>
> I am not very good at rs232 programming so excuse me if this message  is
> boring one.
>
> Thanx
>

Hi Baris

> typedef struct _DCB {
> typedef struct _COMMTIMEOUTS {

These are all handled in termios.c.  It is possible to add extensions to 
rxtx 2.1.  It may well be that the defaults are the same for the variables 
not covered by the existing API.  You can dump the DCB and COMMTIMEOUTS 
from inside termios.c to compare.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 20:23:30 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT)
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
	<Pine.LNX.4.61.0606202127270.14139@www>
	<789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>
Message-ID: <Pine.LNX.4.61.0606212012210.14139@www>

> I'm
> not thrilled but OK with the current API. Hence I dont agree with
> Paul's idea to start a new JSR to fix the implementation - but that's
> mainly because I dont have the time to push it. According to their
> Readme Sun sees no business case in having cross platform support for
> javax.comm - that is sad but it's none of my business. However I
> prefer to program versus javax.comm in my projects as this gives an
> advanced user the chance to exchange the provider without access to
> the code.

Hi Joachim

With regards to the JSR, I think that would be Doug's call.  The effort I 
put in would have to be on my own time which would not be a great deal.  I 
could help things go smoothly but thats not the same as pushing something 
through.

--
Trent Jarvi
tjarvi at qbang.org



From vt at freehold.crocodile.org  Wed Jun 21 21:05:22 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Wed, 21 Jun 2006 20:05:22 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
Message-ID: <449A08F2.3020106@freehold.crocodile.org>

Hello all,

I know this question may belong to JSR lists, but since all interested 
parties are here, I thought I just ask this question here, again...

A while ago I run into a problem and wrote a rant, here: 
http://servomaster.sourceforge.net/dev/serial-usb.html
At the time of writing I didn't think of adding another possible 
solution - changing the CommAPI specs to support removable devices. 
Apparently, Serial/USB bridges are here to stay, and this issue has to 
be addressed.

Wonder if anything changed since, and any abstractions for supporting 
removable devices made it into current or future Java CommAPI drafts - 
Paul, any comments?

--vt



From joachim at buechse.de  Thu Jun 22 01:59:54 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 22 Jun 2006 09:59:54 +0200
Subject: [Rxtx] CVS build question
In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de>

Hello Andre,

I am not sure how well the configure/make mechanism will work on OSX.  
I know that a while ago some contributors tried to get configure/make  
working on OSX but from comments I found in the readmes this work was  
only partially successfull. For compilation on OSX we have used the  
ProjectBuilder/XCode projects you can find in MACOSX_IDE.

Regarding the  ./configure comment:
RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config  
file javax.comm.properties. The later MUST reside in {java.home}/lib.  
As the two only work together putting comm.jar into  /Library/Java/ 
Extensions  and hence making it available to all current and future  
VM installations will only add to confusion.

Regards,
Joachim

On 22.06.2006, at 00:41, Andre-John Mas wrote:

> Hi,
>
> Is the CVS repository meant to build for gnu.io or javax.comm? I  
> ask this, because I see the following when calling ./configure from  
> MacOS X:
>
>  The JCL extension to RxTx requires comm.jar
>  If you intend to use RxTx for commapi support comm.jar
>  needs to be located in  /System/Library/Frameworks/JavaVM.framework/
>   Versions/1.5/Home/lib/ext/comm.jar
>
> I am wanting to build for the gnu.io package, since I want to jump  
> ahead and see if the changes, intended for 2.18 for MacOS X, work  
> for me.
>
> On a side note /Library/Java/Extensions should be included as a  
> valid search path for the JAR, since this is where Apple recommends  
> placing third party extensions (both Java and native).
>
> Andre
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Thu Jun 22 02:51:05 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 22 Jun 2006 10:51:05 +0200
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449A08F2.3020106@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>

Hello Vadim,

I think that your rant is to the point. However it is a bit like  
saying that Windows is at the source of email degradation and the  
only solution is to have users switch to safer operating systems.

I don't see how javax.comm or RXTX can address the problems you  
mention. Of course it would be super cool if javax.comm could magicly  
find the "matching" usb-device and query it's configuration via the  
usb protocol - however this magic (mapping /dev/xyz to its underlying  
USB device) is not supported by any kernel APIs I am aware of. It  
could be supported via POSSIX ioctl calls but then you should address  
your rant to the POSSIX group...

So for the time beeing it's either up to the virtual comm port driver  
to provide a usefull name under /dev/ or to the user choosing the  
right port to use. One example of a smart(er) com port driver is the  
KDDI driver for OSX, which will create device names like "/dev/ 
cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- 
encoded into the bridge chip. The same driver for windows also has  
some options allowing it in theory to recreate the same COMx every  
time a device is plugged/unplugged.

For most industrial applications however it will be up to the user to  
choose the right port (without getting a lot of help doing so).

Probing serial ports can go wrong, that's right. However any serial  
device developper would be well adviced to implement a basic set of  
Hayes AT modem commands (be it a modem or not). Especially AT I0.  
Anyone failing to do so risks that the users favourite TCP/PPP/FAX  
application or stack will kill the device in short time.

Best regards,
Joachim


On 22.06.2006, at 05:05, Vadim Tkachenko wrote:

> Hello all,
>
> I know this question may belong to JSR lists, but since all interested
> parties are here, I thought I just ask this question here, again...
>
> A while ago I run into a problem and wrote a rant, here:
> http://servomaster.sourceforge.net/dev/serial-usb.html
> At the time of writing I didn't think of adding another possible
> solution - changing the CommAPI specs to support removable devices.
> Apparently, Serial/USB bridges are here to stay, and this issue has to
> be addressed.
>
> Wonder if anything changed since, and any abstractions for supporting
> removable devices made it into current or future Java CommAPI drafts -
> Paul, any comments?
>
> --vt
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From vt at freehold.crocodile.org  Thu Jun 22 13:16:03 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 12:16:03 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
Message-ID: <20060622191603.GA17487@freehold.crocodile.org>

Hello Joachim,

> I think that your rant is to the point. However it is a bit like  
> saying that Windows is at the source of email degradation and the  
> only solution is to have users switch to safer operating systems.

I guess the problem is that the rant itself is obsolete and has to be
updated according to latest developments. At the time of writing there
weren't that many bridges around, and the trend didn't manifest itself as it
does now.

> I don't see how javax.comm or RXTX can address the problems you  
> mention.

I would agree that javax.comm won't be able to address the problem, at least
in the short run. As for RxTx - well, nobody prevents it from being a
superset of CommAPI specification, right? RxTx being the de-facto standard
for quite a few platforms, I'd daresay the standard may follow.

> Of course it would be super cool if javax.comm could magicly find the
> "matching" usb-device and query it's configuration via the usb protocol -
> however this magic (mapping /dev/xyz to its underlying USB device) is not
> supported by any kernel APIs I am aware of. It could be supported via
> POSSIX ioctl calls but then you should address your rant to the POSSIX
> group...

As a matter of fact, my bigger concern is addressing the fact that a serial
device can now be removable. This hasn't been the case before, and it
clearly is now. Regarding the above, well, I guess if we accept this fact,
we also need to accept the fact that we need at least rudimentary means of
identification of a serial device. For the USB case, it would usually be the
vendor/product ID, plus possible serial number - but it is irrelevant what
exactly the identifying information is, as long as it allows to identify the
device.

A paradigm shift is required, this is what I wanted to say. Serial devices
can be removed and replaced, it's now our turn to learn to deal with it.

> Joachim

--vt


From jredman at ergotech.com  Thu Jun 22 13:41:44 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 13:41:44 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
Message-ID: <449AF278.6000903@ergotech.com>


Vadim Tkachenko wrote:
> A paradigm shift is required, this is what I wanted to say. Serial devices
> can be removed and replaced, it's now our turn to learn to deal with it.

The removal if the serial port hardly significantly different from the 
removal of the device attached to the serial port.   Different, 
slightly, but not a "paradigm shift".

And yes, someone could unplug a USB serial device and plug it into a 
different USB port so that it has a different name/number, but they 
could do that with the device itself, move it from com1 to com2.

Am I missing something?

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 13:57:27 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 12:57:27 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449AF278.6000903@ergotech.com>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
Message-ID: <20060622195727.GA20247@freehold.crocodile.org>

On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote:
> 
> Vadim Tkachenko wrote:
> > A paradigm shift is required, this is what I wanted to say. Serial devices
> > can be removed and replaced, it's now our turn to learn to deal with it.
> 
> The removal if the serial port hardly significantly different from the 
> removal of the device attached to the serial port.   Different, 
> slightly, but not a "paradigm shift".
> 
> And yes, someone could unplug a USB serial device and plug it into a 
> different USB port so that it has a different name/number, but they 
> could do that with the device itself, move it from com1 to com2.
> 
> Am I missing something?

Yes, the fact that they could unplug a device A and plug a device B. With
the introduction of the concept of removability, the notion of the serial
port itself is not as important anymore, but the notion of the unique device
identifier is.

Consider a situation: long running system (enterprise HVAC, tens of nodes,
tens of thousands square feet area, hundreds of thousand dollars worth of
equipment being conditioned, can't shut down), serial/usb device fails, is
replaced by an identical device with a different serial #.

A little bit farfetched, but hopefully highlighting the point I'm trying to
make.

> Jim

--vt


From jredman at ergotech.com  Thu Jun 22 14:37:38 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 14:37:38 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>	<20060622191603.GA17487@freehold.crocodile.org>	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
Message-ID: <449AFF92.8080003@ergotech.com>


Vadim Tkachenko wrote:
>>
>> Am I missing something?
> 
> Yes, the fact that they could unplug a device A and plug a device B. With
> the introduction of the concept of removability, the notion of the serial
> port itself is not as important anymore, but the notion of the unique device
> identifier is.

Serial devices are always removable.  I could unplug _serial_ device A 
and plug in _serial_ device B.  We have systems running with two RS485 
ports, one talks to a Modbus PLC network one to a number of drives on a 
proprietary protocol.  If you plug the wrong DB9 into the wrong port the 
application doesn't work.

If you dangle a USB 485 converter on the end of the DB9 you've just 
moved the problem from RS485 to USB, but the problem/effect is the same.

> 
> Consider a situation: long running system (enterprise HVAC, tens of nodes,
> tens of thousands square feet area, hundreds of thousand dollars worth of
> equipment being conditioned, can't shut down), serial/usb device fails, is
> replaced by an identical device with a different serial #.
> 
> A little bit farfetched, but hopefully highlighting the point I'm trying to
> make.

Nothing's changed.  If I had a 4 port ISA board and plugged it into my 
new shiny '386 machine.  I could have com ports 9-12.  If I took a board 
off the shelf and didn't set the jumpers, I would have com ports 3-6.

The problem's the same.  If you replace with identical product then the 
com ports  will be the same - no software changes required.  If you 
replace one piece of hardware with hardware from a different 
manufacturer, then the naming/numbering may change.  You're physically 
changing the system, so may reasonably expect to have to make a software 
change.  RXTX actually handles this situation quite well with the -D 
command line option.  (My experience has generally been that the port 
number depends more on the USB port used than the hardware - so the 
chances are even with a hardware change the port number/name will be the 
same.)

Slightly Off Topic - there is a reason why industrial users will pay a 
premium for continued availability of hardware.  Yes you can mail-order 
a $10 USB converter and it will work, but there's no guarantee that the 
next time you buy the same part number from the same vendor it will be 
the same.  The industrial vendors will charge you $100+ for the same 
item, but it will be the same every time you buy it for the next 5 to 10 
years.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 14:37:19 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 13:37:19 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
Message-ID: <20060622203719.GA22521@freehold.crocodile.org>

Hello again,

And while I'm at it, why don't just say this: give me one good reason to
write 3+ different ways of handling removable devices, one for USB, one for
FireWire, one for serial...

I understand very well that this goes way beyond the scope of RxTx and
CommAPI and will require cooperation between them and javax.usb and whatever
JSR is responsible for FireWire implementation - but the end result is well
worth it. Abstract out and generalize arrival/departure/monitoring/discovery
API, provide protocol specific extensions for each, live happily ever after.

--vt


On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote:
> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote:
> > 
> > Vadim Tkachenko wrote:
> > > A paradigm shift is required, this is what I wanted to say. Serial devices
> > > can be removed and replaced, it's now our turn to learn to deal with it.
> > 
> > The removal if the serial port hardly significantly different from the 
> > removal of the device attached to the serial port.   Different, 
> > slightly, but not a "paradigm shift".
> > 
> > And yes, someone could unplug a USB serial device and plug it into a 
> > different USB port so that it has a different name/number, but they 
> > could do that with the device itself, move it from com1 to com2.
> > 
> > Am I missing something?
> 
> Yes, the fact that they could unplug a device A and plug a device B. With
> the introduction of the concept of removability, the notion of the serial
> port itself is not as important anymore, but the notion of the unique device
> identifier is.
> 
> Consider a situation: long running system (enterprise HVAC, tens of nodes,
> tens of thousands square feet area, hundreds of thousand dollars worth of
> equipment being conditioned, can't shut down), serial/usb device fails, is
> replaced by an identical device with a different serial #.
> 
> A little bit farfetched, but hopefully highlighting the point I'm trying to
> make.
> 
> > Jim
> 
> --vt
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx


From jredman at ergotech.com  Thu Jun 22 15:13:49 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 15:13:49 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>	<20060622191603.GA17487@freehold.crocodile.org>	<449AF278.6000903@ergotech.com>	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
Message-ID: <449B080D.9080208@ergotech.com>


Vadim Tkachenko wrote:
> Hello again,
> 
> And while I'm at it, why don't just say this: give me one good reason to
> write 3+ different ways of handling removable devices, one for USB, one for
> FireWire, one for serial...

You don't, they're all the same "I have lost communication with my 
serial device".

The only thing you could really do is improve error reporting by knowing 
the exact sub-system.  ("Device X which is/was attached to USB port Y is 
no longer functioning, please check the USB ports, the device, the 
cables and anything else you can think of that may be a cause of 
failure.")  That just requires an intelligent description of the port.

> I understand very well that this goes way beyond the scope of RxTx and
> CommAPI and will require cooperation between them and javax.usb and whatever
> JSR is responsible for FireWire implementation - but the end result is well
> worth it. Abstract out and generalize arrival/departure/monitoring/discovery
> API, provide protocol specific extensions for each, live happily ever after.

There's a huge list of pseudo-serial devices each with a different set 
of requirements, Bluetooth, RFC 2217, a host of proprietary systems, 
etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I 
have no clue how you'd implement them in a general/cross platform sense.

You haven't convinced me (and only me, others may see something that I 
don't, I'm not speaking for them) that this mechanism can be implemented 
in any practical sense.  That is, that the implementation could be wide 
enough to be consider generally available in RXTX regardless of the 
serial port implementation, platform, etc..  However, if you can come up 
with a general design and a reference implementation for one subsystem, 
I'd like to see it and might get on board.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 15:40:55 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 14:40:55 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449B080D.9080208@ergotech.com>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
Message-ID: <20060622214055.GA25497@freehold.crocodile.org>

On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote:
> 
> Vadim Tkachenko wrote:
> > Hello again,
> > 
> > And while I'm at it, why don't just say this: give me one good reason to
> > write 3+ different ways of handling removable devices, one for USB, one for
> > FireWire, one for serial...
> 
> You don't, they're all the same "I have lost communication with my 
> serial device".

"I have lost communication with my ${protocol} device".

> The only thing you could really do is improve error reporting by knowing 
> the exact sub-system.  ("Device X which is/was attached to USB port Y is 
> no longer functioning, please check the USB ports, the device, the 
> cables and anything else you can think of that may be a cause of 
> failure.")

"Device ${id} which is/was attached to ${protocol} port ${port} is no longer
functioning, please check the ${protocol} ports, the device, the
${protocol_media} and anything else you can think of that may be a cause of
failure".

>  That just requires an intelligent description of the port.

Agree absolutely.

> > I understand very well that this goes way beyond the scope of RxTx and
> > CommAPI and will require cooperation between them and javax.usb and whatever
> > JSR is responsible for FireWire implementation - but the end result is well
> > worth it. Abstract out and generalize arrival/departure/monitoring/discovery
> > API, provide protocol specific extensions for each, live happily ever after.
> 
> There's a huge list of pseudo-serial devices each with a different set 
> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, 
> etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I 
> have no clue how you'd implement them in a general/cross platform sense.

That's because some of the protocols were created decades ago when
autoconfiguration wasn't even conceived, much less practical. RS232/RS485
don't have a clue about identity discovery, and even capabilities discovery
beyond obvious 8N1 etc.

I agree that today all these protocols have generally incompatible
strategies for handling the situations I'm trying to address, but there's
nothing that says it's not an oversight. Besides, we're dealing with the
devices at a level of abstraction that allows some simplifications and
generalizations, at least part of the time - unless it's the protocol
specific features we're dealing with.

> You haven't convinced me (and only me, others may see something that I 
> don't, I'm not speaking for them) that this mechanism can be implemented 
> in any practical sense.  That is, that the implementation could be wide 
> enough to be consider generally available in RXTX regardless of the 
> serial port implementation, platform, etc..  However, if you can come up 
> with a general design and a reference implementation for one subsystem, 
> I'd like to see it and might get on board.

Actually, I wasn't even thinking about all this stuff when I wrote the first
message on the subject :) Now that you mention it - well, I'm not sure I can
chew the piece I just tried to bite in reasonable amount of time.

How do you eat an elephant? One bite at a time. If we could agree that a
small step in the specification is acceptable at this time, and express
further intentions, things may start happening.

To put it succinctly:

- Concept of a "port" should be augmented with a concept of a "device". A
device may be attached to a port in an implicit or explicit way.
- Implicitly connected device is exactly what the current scope of the
specification covers. No new functionality is offered.
- Explicitly connected device supports detachable device semantics, just as
other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a
few).
- The input and output streams are not properties of a port now, but
properties of the device attached to the port.
- A mechanism to allow listening for device arrivals and departures must be
made available.

That's it, off the top of my head.

I understand that this goes completely against current javax.comm specs, but
an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be
difficult to implement without disrupting javax.comm compatibility.

One concern is how to deal with the device identity - but there's no general
way of dealing with this at this time, devices may or may not offer identity
discovery.

> Jim

--vt


From joachim at buechse.de  Fri Jun 23 02:12:43 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 23 Jun 2006 10:12:43 +0200
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
Message-ID: <CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>

Hello++ Vadim,

I would like to repeat that your request is best addressed to the  
POSSIX standardization group - or maybe the BSD/Linux maintainers. If  
you convince the BSD or Linux guys to add this kind of functionality  
(they can as most of there VCP drivers are open source), there is a  
certain chance that other vendors will pick it up. I assure you that  
RXTX will happily provide this functionality once it's possible - I'm  
sure there is more than one maintainer that would love to add it.  
Having this concept penetrate the market may take some years though.

SHORT: The solution you would like to see could be added to the API  
but it can not be implemented (at least not on the platforms I know).  
There are currently no hooks in the kernel that allow you to discover  
"the device" or even the "means of connection" based on an existing  
"device file descriptor" ie COM-port or /dev/... entry. The name  
mapping of the device is handled by the virtual com port driver of  
the device. Unless you are suggesting RXTX should reimplement virtual  
com port drivers for all usb/serial bridges out there your request is  
understandable from a users viewpoint but simply not realizable. It's  
like asking that the Socket api should identify the computer behind  
an IP address (ie by its Ethernet address). While this COULD be  
implemented in TCP/IP, it IS not, and hence there is no point adding  
such a function to the Socket API.

The current trend for USB/Bluetooth/Irda/etc connected devices is  
going away from serial port abstraction towards RPC (ie the drivers  
provide a device specific or device class specific driver that  
provides an application level api to the device functions). The line  
level protocol is often not even published.

Best regards,
Joachim

On 22.06.2006, at 23:40, Vadim Tkachenko wrote:

> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote:
>>
>> Vadim Tkachenko wrote:
>>> Hello again,
>>>
>>> And while I'm at it, why don't just say this: give me one good  
>>> reason to
>>> write 3+ different ways of handling removable devices, one for  
>>> USB, one for
>>> FireWire, one for serial...
>>
>> You don't, they're all the same "I have lost communication with my
>> serial device".
>
> "I have lost communication with my ${protocol} device".
>
>> The only thing you could really do is improve error reporting by  
>> knowing
>> the exact sub-system.  ("Device X which is/was attached to USB  
>> port Y is
>> no longer functioning, please check the USB ports, the device, the
>> cables and anything else you can think of that may be a cause of
>> failure.")
>
> "Device ${id} which is/was attached to ${protocol} port ${port} is  
> no longer
> functioning, please check the ${protocol} ports, the device, the
> ${protocol_media} and anything else you can think of that may be a  
> cause of
> failure".
>
>>  That just requires an intelligent description of the port.
>
> Agree absolutely.
>
>>> I understand very well that this goes way beyond the scope of  
>>> RxTx and
>>> CommAPI and will require cooperation between them and javax.usb  
>>> and whatever
>>> JSR is responsible for FireWire implementation - but the end  
>>> result is well
>>> worth it. Abstract out and generalize arrival/departure/ 
>>> monitoring/discovery
>>> API, provide protocol specific extensions for each, live happily  
>>> ever after.
>>
>> There's a huge list of pseudo-serial devices each with a different  
>> set
>> of requirements, Bluetooth, RFC 2217, a host of proprietary systems,
>> etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I
>> have no clue how you'd implement them in a general/cross platform  
>> sense.
>
> That's because some of the protocols were created decades ago when
> autoconfiguration wasn't even conceived, much less practical. RS232/ 
> RS485
> don't have a clue about identity discovery, and even capabilities  
> discovery
> beyond obvious 8N1 etc.
>
> I agree that today all these protocols have generally incompatible
> strategies for handling the situations I'm trying to address, but  
> there's
> nothing that says it's not an oversight. Besides, we're dealing  
> with the
> devices at a level of abstraction that allows some simplifications and
> generalizations, at least part of the time - unless it's the protocol
> specific features we're dealing with.
>
>> You haven't convinced me (and only me, others may see something  
>> that I
>> don't, I'm not speaking for them) that this mechanism can be  
>> implemented
>> in any practical sense.  That is, that the implementation could be  
>> wide
>> enough to be consider generally available in RXTX regardless of the
>> serial port implementation, platform, etc..  However, if you can  
>> come up
>> with a general design and a reference implementation for one  
>> subsystem,
>> I'd like to see it and might get on board.
>
> Actually, I wasn't even thinking about all this stuff when I wrote  
> the first
> message on the subject :) Now that you mention it - well, I'm not  
> sure I can
> chew the piece I just tried to bite in reasonable amount of time.
>
> How do you eat an elephant? One bite at a time. If we could agree  
> that a
> small step in the specification is acceptable at this time, and  
> express
> further intentions, things may start happening.
>
> To put it succinctly:
>
> - Concept of a "port" should be augmented with a concept of a  
> "device". A
> device may be attached to a port in an implicit or explicit way.
> - Implicitly connected device is exactly what the current scope of the
> specification covers. No new functionality is offered.
> - Explicitly connected device supports detachable device semantics,  
> just as
> other protocols do (USB, FireWire, Wireless USB, Bluetooth, to  
> mention a
> few).
> - The input and output streams are not properties of a port now, but
> properties of the device attached to the port.
> - A mechanism to allow listening for device arrivals and departures  
> must be
> made available.
>
> That's it, off the top of my head.
>
> I understand that this goes completely against current javax.comm  
> specs, but
> an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern )  
> won't be
> difficult to implement without disrupting javax.comm compatibility.
>
> One concern is how to deal with the device identity - but there's  
> no general
> way of dealing with this at this time, devices may or may not offer  
> identity
> discovery.
>
>> Jim
>
> --vt
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From vt at freehold.crocodile.org  Fri Jun 23 11:28:29 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Fri, 23 Jun 2006 10:28:29 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
	<CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
Message-ID: <20060623172829.GA5335@freehold.crocodile.org>

Hello Joachim,

> I would like to repeat that your request is best addressed to the POSSIX
> standardization group - or maybe the BSD/Linux maintainers. If you
> convince the BSD or Linux guys to add this kind of functionality (they can
> as most of there VCP drivers are open source), there is a certain chance
> that other vendors will pick it up. I assure you that RXTX will happily
> provide this functionality once it's possible - I'm sure there is more
> than one maintainer that would love to add it.

I realize this thing is bigger than RxTx itself, and I'm afraid it's too
global not to cause people to laugh before they think about it :)

> Having this concept penetrate the market may take some years though.

Well, I'm sure it'll get there, the only question is - when.

> SHORT: The solution you would like to see could be added to the API but it
> can not be implemented (at least not on the platforms I know).

I guess I'm concerned about the abstraction more than I'm concerned about
the implementation at this point.
  
> There are currently no hooks in the kernel that allow you to discover  
> "the device" or even the "means of connection" based on an existing  
> "device file descriptor" ie COM-port or /dev/... entry.

Well, I'm not so sure you need to keep the literal mapping from /dev
namespace to your device namespace. As long as you can consistently offer a
virtual serial device on top of a virtual serial port, it may be irrelevant
whether you can map it into /dev. The mapping is going be schitzofrenic
anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the
representation...

> The name mapping of the device is handled by the virtual com port driver
> of the device. Unless you are suggesting RXTX should reimplement virtual
> com port drivers for all usb/serial bridges out there your request is
> understandable from a users viewpoint but simply not realizable.

It's not so much a request but rather an offer of participation. I run a few
projects actively using serial communications, as well as USB device
drivers, in different degrees of readiness (Servomaster, Haywire, DIY
Zoning) - and it would be a perfect playground.

You mentioned above that this task is about two things: a) abstraction b)
implementation. I could start the abstraction part of it without changing
the current CommAPI, on top of it, as an adapter. Even if the removable
device semantics are not implemented, but offered, this is already a step
forward.

> It's like asking that the Socket api should identify the computer behind
> an IP address (ie by its Ethernet address). While this COULD be
> implemented in TCP/IP, it IS not, and hence there is no point adding such
> a function to the Socket API.

Thank you for bringing up this example - I guess this is just about the same
thing that I'd like to see. Socket transparently provides you with the
input/output streams, at the same time offering protocol level specifics to
you.

> The current trend for USB/Bluetooth/Irda/etc connected devices is going
> away from serial port abstraction towards RPC (ie the drivers provide a
> device specific or device class specific driver that provides an
> application level api to the device functions). The line level protocol is
> often not even published.

I can't say I'm that happy with it. The best (or, rather, worst) example is
suchlike support for the Phidget servo controller - zealous Linux developers
implemented kernel module support for it, completely hijacking a possibility
of using it on a different level (it's somewhat fixed by now, thankfully).

I believe that whenever an abstraction is offered, it must be made optional
and/or pluggable so it can be replaced by something more suited to the task.

The nature of Java applications is such that they'd probably care much more
about Java API offered, than about no matter how rich application level api
that is offered outside of Java. I've dealt with JNI adapters in the past,
and whereas they can be made reasonably stable, the very fact that you are
forced to deal with things that are not on the critical timing/memory path
and could've been done much easier in Java causes endless grief.

> Joachim

--vt


From lyon at docjava.com  Sat Jun 24 04:54:12 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Sat, 24 Jun 2006 06:54:12 -0400
Subject: [Rxtx] jsr
In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
	<CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
	<20060623172829.GA5335@freehold.crocodile.org>
Message-ID: <p060204a3c0c2c9dde4f8@[192.168.1.152]>

Hi All,
I have had some off-list discussion with Trent.
Opening up a JSR with Sun, as per Peters' suggestion
seems like a reasonable idea, to us.

Does anyone having any concerns about the JSR process
that they would like to raise?

Thanks!
  - Doug



From the.grey.lantern at gmail.com  Sat Jun 24 18:15:26 2006
From: the.grey.lantern at gmail.com (Craig Nicoll)
Date: Sun, 25 Jun 2006 01:15:26 +0100
Subject: [Rxtx] Cannot create virtual serial port
Message-ID: <a1221cc50606241715g2d1e2af6r747347dd4c20e997@mail.gmail.com>

Hello,

This is my first post on this mailing list and I hope someone can help me.

I am having great difficult establishing a virtual serial port for the
Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia
7600.

Every time I try to run the SendMessage program that comes with SMSLib, I
get the following exception: gnu.io.NoSuchPortException

The port names I have tried are:
rfcomm0
rfcomm
/dev/rfcomm0
/dev/rfcomm

This is what I have done so far:
Modified /etc/bluetooth/rfcomm.conf to include the address of my phone:

rfcomm0 {
# Automatically bind the device at startup
bind no;

# Bluetooth address of the device
device 00:0e:6d:7a:98:43;

# RFCOMM channel for the connection
channel 1;

# Description of the connection
comment "Example Bluetooth device";
}

I also tried running the following command: rfcomm bind /dev/rfcomm0

I have searched the mailing list archives and found this post where someone
had a very similar problem to me:
http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried
changing the system properties as suggested and it made no difference.

I have also been scouring Google all day to no avail.

I would be incredibly grateful if anyone could give me some tips.

Thank you,

Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060625/cfa6df35/attachment-0011.html

From tjarvi at qbang.org  Sun Jun 25 19:56:08 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT)
Subject: [Rxtx] Pending release
Message-ID: <Pine.LNX.4.61.0606251942460.15744@www>


With frustration, I was unable to get to the pending release this weekend.
The release should be comming this next week once things calm down.
The source is in CVS except for a fix for multiple ports in windows.

I had planned on doing the release this weekend but that was disrupted by 
my transportation failing in a spectacular fashion.

--
Trent Jarvi
tjarvi at qbang.org


From Pawan.Kharbanda at dot.state.co.us  Tue Jun 27 22:28:51 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 27 Jun 2006 22:28:51 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>

 Trent, 
   I have an application running in a cluster in linux environment and I
am using RXTX2.1.7 (final) with JDK1.5. The application opens and closes
serial comm ports every 30 seconds and exchanges datas. I have
experienced some of my Comm Ports are left hanging (I can see the
LCK..cufXX lock files under /var/lock folder). On putting the debugs I
found out that, it is stuck at a native call line 809 in RXTXPort.java
class (Please see the code snippet below). Can you help me explain what
this method does in the native code? Am I getting into some thread
deadlocks? Thanks in advance.

Pawan Kharbanda 


public void removeEventListener()
	{
		if (debug)
			z.reportln( "RXTXPort:removeEventListener()
called");
		waitForTheNativeCodeSilly();
		//if( monThread != null && monThread.isAlive() )
		if( monThreadisInterrupted == true )
		{
			z.reportln( "	RXTXPort:removeEventListener()
already interrupted");
			monThread = null;
			SPEventListener = null;
			return;
		}
		else if( monThread != null && monThread.isAlive() )
		{
			if (debug)
				z.reportln( "
RXTXPort:Interrupt=true");
			monThreadisInterrupted=true;
			/*
			   Notify all threads in this PID that something
is up
			   They will call back to see if its their
thread
			   using isInterrupted().
			*/
			if (debug)
				z.reportln( "	RXTXPort:calling
interruptEventLoop");
// LINE 809			interruptEventLoop( ); It never returns
out of this 
			
			if (debug)
				z.reportln( "	RXTXPort:calling
monThread.join()");
			try {
				monThread.join(1000);
			} catch (Exception ex) {
				/* yikes */
				ex.printStackTrace();
			}
			if (debug)
				z.reportln( "	RXTXPort:waiting on
isAlive()");
			while( monThread.isAlive() )
			{
				if ( debug )
					z.reportln( "	MonThread is
still alive!");
				try {
					monThread.join(1000);
					Thread.sleep( 1000 );
				} catch( Exception e ){} 
				//monThread.stop();
			}
			
		}
		if (debug)
			z.reportln( "	RXTXPort:calling gc()");
		monThread = null;
		SPEventListener = null;
		MonitorThreadLock = false;
		MonitorThreadAlive=false;
		monThreadisInterrupted=true;
		z.reportln( "RXTXPort:removeEventListener() returning");
	} 

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Sunday, June 25, 2006 7:56 PM
To: rxtx at qbang.org
Subject: [Rxtx] Pending release


With frustration, I was unable to get to the pending release this
weekend.
The release should be comming this next week once things calm down.
The source is in CVS except for a fix for multiple ports in windows.

I had planned on doing the release this weekend but that was disrupted
by my transportation failing in a spectacular fashion.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Wed Jun 28 04:17:29 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 28 Jun 2006 04:17:29 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606280406330.9561@www>



Hi Pawan

You may have found a deadlock but I've not seen on recently on linux.

If you can, please update from CVS.  This will have some close fixes. 
I'm running with the same code as is in CVS.  It is not perfect but I've 
not seen anything like you mention.  Be sure to set timeouts and 
thresholds on the port.  It may be that the port is waiting on pending io 
that never happens.  I think the CVS patches deal with this also but it 
looks like your in a better test environment to know for sure.

The exploded vehicle mentioned below is expected to be fixed today.  It 
was just a ninja small radiator hose.  The pressure test afterwards 
created its own set of problems.  Until this is resolved, I'm spending 
most of my free time commuting by bicycle.

On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>   I have an application running in a cluster in linux environment and I
> am using RXTX2.1.7 (final) with JDK1.5. The application opens and closes
> serial comm ports every 30 seconds and exchanges datas. I have
> experienced some of my Comm Ports are left hanging (I can see the
> LCK..cufXX lock files under /var/lock folder). On putting the debugs I
> found out that, it is stuck at a native call line 809 in RXTXPort.java
> class (Please see the code snippet below). Can you help me explain what
> this method does in the native code? Am I getting into some thread
> deadlocks? Thanks in advance.
>
> Pawan Kharbanda
>
>
> public void removeEventListener()
> 	{
> 		if (debug)
> 			z.reportln( "RXTXPort:removeEventListener()
> called");
> 		waitForTheNativeCodeSilly();
> 		//if( monThread != null && monThread.isAlive() )
> 		if( monThreadisInterrupted == true )
> 		{
> 			z.reportln( "	RXTXPort:removeEventListener()
> already interrupted");
> 			monThread = null;
> 			SPEventListener = null;
> 			return;
> 		}
> 		else if( monThread != null && monThread.isAlive() )
> 		{
> 			if (debug)
> 				z.reportln( "
> RXTXPort:Interrupt=true");
> 			monThreadisInterrupted=true;
> 			/*
> 			   Notify all threads in this PID that something
> is up
> 			   They will call back to see if its their
> thread
> 			   using isInterrupted().
> 			*/
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> interruptEventLoop");
> // LINE 809			interruptEventLoop( ); It never returns
> out of this
>
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> monThread.join()");
> 			try {
> 				monThread.join(1000);
> 			} catch (Exception ex) {
> 				/* yikes */
> 				ex.printStackTrace();
> 			}
> 			if (debug)
> 				z.reportln( "	RXTXPort:waiting on
> isAlive()");
> 			while( monThread.isAlive() )
> 			{
> 				if ( debug )
> 					z.reportln( "	MonThread is
> still alive!");
> 				try {
> 					monThread.join(1000);
> 					Thread.sleep( 1000 );
> 				} catch( Exception e ){}
> 				//monThread.stop();
> 			}
>
> 		}
> 		if (debug)
> 			z.reportln( "	RXTXPort:calling gc()");
> 		monThread = null;
> 		SPEventListener = null;
> 		MonitorThreadLock = false;
> 		MonitorThreadAlive=false;
> 		monThreadisInterrupted=true;
> 		z.reportln( "RXTXPort:removeEventListener() returning");
> 	}
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Sunday, June 25, 2006 7:56 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] Pending release
>
>
> With frustration, I was unable to get to the pending release this
> weekend.
> The release should be comming this next week once things calm down.
> The source is in CVS except for a fix for multiple ports in windows.
>
> I had planned on doing the release this weekend but that was disrupted
> by my transportation failing in a spectacular fashion.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From Pawan.Kharbanda at dot.state.co.us  Wed Jun 28 12:11:06 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Wed, 28 Jun 2006 12:11:06 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>

Trent,
    Again thanks for the reply. First of all I have Receive timeouts set
on all communications including Max no of bytes to expect during the
call. I have noticed the problem is during "closing the connection". I
am not sure if the RXTX is 100% thread-safe yet. There seems to be a
glitch in the native calls. I am sure I have the latest code I did the
update on the Version 2.1.7 from CVS, is this where the latest updates
are located, I have noticed another version in CVS "rxtx-devel".

Regards
Pawan Kharbanda

    

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Wednesday, June 28, 2006 4:17 AM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports



Hi Pawan

You may have found a deadlock but I've not seen on recently on linux.

If you can, please update from CVS.  This will have some close fixes. 
I'm running with the same code as is in CVS.  It is not perfect but I've
not seen anything like you mention.  Be sure to set timeouts and
thresholds on the port.  It may be that the port is waiting on pending
io that never happens.  I think the CVS patches deal with this also but
it looks like your in a better test environment to know for sure.

The exploded vehicle mentioned below is expected to be fixed today.  It
was just a ninja small radiator hose.  The pressure test afterwards
created its own set of problems.  Until this is resolved, I'm spending
most of my free time commuting by bicycle.

On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>   I have an application running in a cluster in linux environment and 
> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and 
> closes serial comm ports every 30 seconds and exchanges datas. I have 
> experienced some of my Comm Ports are left hanging (I can see the 
> LCK..cufXX lock files under /var/lock folder). On putting the debugs I

> found out that, it is stuck at a native call line 809 in RXTXPort.java

> class (Please see the code snippet below). Can you help me explain 
> what this method does in the native code? Am I getting into some 
> thread deadlocks? Thanks in advance.
>
> Pawan Kharbanda
>
>
> public void removeEventListener()
> 	{
> 		if (debug)
> 			z.reportln( "RXTXPort:removeEventListener()
called");
> 		waitForTheNativeCodeSilly();
> 		//if( monThread != null && monThread.isAlive() )
> 		if( monThreadisInterrupted == true )
> 		{
> 			z.reportln( "	RXTXPort:removeEventListener()
> already interrupted");
> 			monThread = null;
> 			SPEventListener = null;
> 			return;
> 		}
> 		else if( monThread != null && monThread.isAlive() )
> 		{
> 			if (debug)
> 				z.reportln( "
> RXTXPort:Interrupt=true");
> 			monThreadisInterrupted=true;
> 			/*
> 			   Notify all threads in this PID that something
is up
> 			   They will call back to see if its their
thread
> 			   using isInterrupted().
> 			*/
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> interruptEventLoop");
> // LINE 809			interruptEventLoop( ); It never returns
> out of this
>
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> monThread.join()");
> 			try {
> 				monThread.join(1000);
> 			} catch (Exception ex) {
> 				/* yikes */
> 				ex.printStackTrace();
> 			}
> 			if (debug)
> 				z.reportln( "	RXTXPort:waiting on
> isAlive()");
> 			while( monThread.isAlive() )
> 			{
> 				if ( debug )
> 					z.reportln( "	MonThread is
> still alive!");
> 				try {
> 					monThread.join(1000);
> 					Thread.sleep( 1000 );
> 				} catch( Exception e ){}
> 				//monThread.stop();
> 			}
>
> 		}
> 		if (debug)
> 			z.reportln( "	RXTXPort:calling gc()");
> 		monThread = null;
> 		SPEventListener = null;
> 		MonitorThreadLock = false;
> 		MonitorThreadAlive=false;
> 		monThreadisInterrupted=true;
> 		z.reportln( "RXTXPort:removeEventListener() returning");
> 	}
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf

> Of Trent Jarvi
> Sent: Sunday, June 25, 2006 7:56 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] Pending release
>
>
> With frustration, I was unable to get to the pending release this 
> weekend.
> The release should be comming this next week once things calm down.
> The source is in CVS except for a fix for multiple ports in windows.
>
> I had planned on doing the release this weekend but that was disrupted

> by my transportation failing in a spectacular fashion.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Wed Jun 28 12:26:21 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 28 Jun 2006 12:26:21 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606281222420.9561@www>


Hi Pawan

If you did a cvs update from the 2.1-7 tar ball, you have the current 
version.  All rxtx in CVS is under rxtx-devel.  The 2.1-7 just has -r
commapi-0-0-1.

You may well have found something.  I have seen win32 fail on closing 
ports but not linux that I can think of.  Your use is much different than 
I normally see too.

Could you give us more information on how we would reproduce this and the 
frequency?


On Wed, 28 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>    Again thanks for the reply. First of all I have Receive timeouts set
> on all communications including Max no of bytes to expect during the
> call. I have noticed the problem is during "closing the connection". I
> am not sure if the RXTX is 100% thread-safe yet. There seems to be a
> glitch in the native calls. I am sure I have the latest code I did the
> update on the Version 2.1.7 from CVS, is this where the latest updates
> are located, I have noticed another version in CVS "rxtx-devel".
>
> Regards
> Pawan Kharbanda
>
>
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Wednesday, June 28, 2006 4:17 AM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] Locked Ports
>
>
>
> Hi Pawan
>
> You may have found a deadlock but I've not seen on recently on linux.
>
> If you can, please update from CVS.  This will have some close fixes.
> I'm running with the same code as is in CVS.  It is not perfect but I've
> not seen anything like you mention.  Be sure to set timeouts and
> thresholds on the port.  It may be that the port is waiting on pending
> io that never happens.  I think the CVS patches deal with this also but
> it looks like your in a better test environment to know for sure.
>
> The exploded vehicle mentioned below is expected to be fixed today.  It
> was just a ninja small radiator hose.  The pressure test afterwards
> created its own set of problems.  Until this is resolved, I'm spending
> most of my free time commuting by bicycle.
>
> On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:
>
>> Trent,
>>   I have an application running in a cluster in linux environment and
>> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and
>> closes serial comm ports every 30 seconds and exchanges datas. I have
>> experienced some of my Comm Ports are left hanging (I can see the
>> LCK..cufXX lock files under /var/lock folder). On putting the debugs I
>
>> found out that, it is stuck at a native call line 809 in RXTXPort.java
>
>> class (Please see the code snippet below). Can you help me explain
>> what this method does in the native code? Am I getting into some
>> thread deadlocks? Thanks in advance.
>>
>> Pawan Kharbanda
>>
>>
>> public void removeEventListener()
>> 	{
>> 		if (debug)
>> 			z.reportln( "RXTXPort:removeEventListener()
> called");
>> 		waitForTheNativeCodeSilly();
>> 		//if( monThread != null && monThread.isAlive() )
>> 		if( monThreadisInterrupted == true )
>> 		{
>> 			z.reportln( "	RXTXPort:removeEventListener()
>> already interrupted");
>> 			monThread = null;
>> 			SPEventListener = null;
>> 			return;
>> 		}
>> 		else if( monThread != null && monThread.isAlive() )
>> 		{
>> 			if (debug)
>> 				z.reportln( "
>> RXTXPort:Interrupt=true");
>> 			monThreadisInterrupted=true;
>> 			/*
>> 			   Notify all threads in this PID that something
> is up
>> 			   They will call back to see if its their
> thread
>> 			   using isInterrupted().
>> 			*/
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> interruptEventLoop");
>> // LINE 809			interruptEventLoop( ); It never returns
>> out of this
>>
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> monThread.join()");
>> 			try {
>> 				monThread.join(1000);
>> 			} catch (Exception ex) {
>> 				/* yikes */
>> 				ex.printStackTrace();
>> 			}
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:waiting on
>> isAlive()");
>> 			while( monThread.isAlive() )
>> 			{
>> 				if ( debug )
>> 					z.reportln( "	MonThread is
>> still alive!");
>> 				try {
>> 					monThread.join(1000);
>> 					Thread.sleep( 1000 );
>> 				} catch( Exception e ){}
>> 				//monThread.stop();
>> 			}
>>
>> 		}
>> 		if (debug)
>> 			z.reportln( "	RXTXPort:calling gc()");
>> 		monThread = null;
>> 		SPEventListener = null;
>> 		MonitorThreadLock = false;
>> 		MonitorThreadAlive=false;
>> 		monThreadisInterrupted=true;
>> 		z.reportln( "RXTXPort:removeEventListener() returning");
>> 	}
>>
>> -----Original Message-----
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
>
>> Of Trent Jarvi
>> Sent: Sunday, June 25, 2006 7:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] Pending release
>>
>>
>> With frustration, I was unable to get to the pending release this
>> weekend.
>> The release should be comming this next week once things calm down.
>> The source is in CVS except for a fix for multiple ports in windows.
>>
>> I had planned on doing the release this weekend but that was disrupted
>
>> by my transportation failing in a spectacular fashion.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From Pawan.Kharbanda at dot.state.co.us  Wed Jun 28 15:42:49 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Wed, 28 Jun 2006 15:42:49 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>

Trent,
    I will try to explain how I am setup and will try to write you a
Sample code little later to reproduce this. On our system we have
DigiBoxes installed on the 2 Linux servers. Both of them have RXTX2.1-7
version installed with the JRE(1.5) and both the machines have the same
port mappings in gnu.io.rxtx.properties (Currently in the production
system I have 64 ports). This is how the system works:

1) A thick Map based client initiates a Action on the Device on the
field. One of the Thread Workers(Asynchronous Call) in the Cluster picks
up the request. 
2) Once the worker gets the request it locks the Device and
Communication port in the DB's(These are our persistent locks, because
most of the devices do one to one communication with the serial ports).
After that the worker (or Comm Server) opens up the connection and after
exchanging the information calls the "Close" and returns.
3) Once the connection is closed , the DB lock is removed on the comm
port and is made available to accept future calls. Here is where the
glitch is the Serial Comm Close method never returns due to the
deadlock. 

I have noticed that the deadlocks are very inconsistent, sometime it
happens right away as soon as Application server starts and sometimes I
don't see any deadlocks for days, but it happens for sure. 

Here is how you can test if you have resources/ test environment. Write
a program and try to open/close  different ports(I will say have a
minimum of four) randomly and very frequently(may be 30 seconds), I am
pretty sure you will see the deadlocks and it happens in the native call
to interrptEventLoop in RXTXPort.java in removeEventListener() method
call.

Also I have noticed that the JVM carshes (without any memrory errors or
JVM errors. Its just not there) when native call is made to eventLoop()
in run() method in MonitorThread inner class. I am still investigating
why this is happening, but at this point I can just tell you the
location. You might have a question How I am so sure about the location?
My application is configured with Log4J and I have enabled the debugs on
the RXTXPort.java, so every time my JVM dies I see these logs at the end
of the file.

"2006-06-28 15:27:15,183 INFO  [STDOUT] RXTXPort:RXTXPort(/dev/cub01)
called
2006-06-28 15:27:15,218 INFO  [STDOUT]
RXTXPort:MontitorThread:MonitorThread()
2006-06-28 15:27:15,219 INFO  [STDOUT] RXTXPort:MontitorThread:run()"

I surely do have a luxury of a testing environment(ports, devices etc.)
and can help you fix these problems? Please advise me how we can resolve
these issues.

Thanks 
Pawan Kharbanda
303-478-2991





-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Wednesday, June 28, 2006 12:26 PM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports


Hi Pawan

If you did a cvs update from the 2.1-7 tar ball, you have the current
version.  All rxtx in CVS is under rxtx-devel.  The 2.1-7 just has -r
commapi-0-0-1.

You may well have found something.  I have seen win32 fail on closing
ports but not linux that I can think of.  Your use is much different
than I normally see too.

Could you give us more information on how we would reproduce this and
the frequency?


On Wed, 28 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>    Again thanks for the reply. First of all I have Receive timeouts
set
> on all communications including Max no of bytes to expect during the
> call. I have noticed the problem is during "closing the connection". I
> am not sure if the RXTX is 100% thread-safe yet. There seems to be a
> glitch in the native calls. I am sure I have the latest code I did the
> update on the Version 2.1.7 from CVS, is this where the latest updates
> are located, I have noticed another version in CVS "rxtx-devel".
>
> Regards
> Pawan Kharbanda
>
>
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Wednesday, June 28, 2006 4:17 AM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] Locked Ports
>
>
>
> Hi Pawan
>
> You may have found a deadlock but I've not seen on recently on linux.
>
> If you can, please update from CVS.  This will have some close fixes.
> I'm running with the same code as is in CVS.  It is not perfect but
I've
> not seen anything like you mention.  Be sure to set timeouts and
> thresholds on the port.  It may be that the port is waiting on pending
> io that never happens.  I think the CVS patches deal with this also
but
> it looks like your in a better test environment to know for sure.
>
> The exploded vehicle mentioned below is expected to be fixed today.
It
> was just a ninja small radiator hose.  The pressure test afterwards
> created its own set of problems.  Until this is resolved, I'm spending
> most of my free time commuting by bicycle.
>
> On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:
>
>> Trent,
>>   I have an application running in a cluster in linux environment and
>> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and
>> closes serial comm ports every 30 seconds and exchanges datas. I have
>> experienced some of my Comm Ports are left hanging (I can see the
>> LCK..cufXX lock files under /var/lock folder). On putting the debugs
I
>
>> found out that, it is stuck at a native call line 809 in
RXTXPort.java
>
>> class (Please see the code snippet below). Can you help me explain
>> what this method does in the native code? Am I getting into some
>> thread deadlocks? Thanks in advance.
>>
>> Pawan Kharbanda
>>
>>
>> public void removeEventListener()
>> 	{
>> 		if (debug)
>> 			z.reportln( "RXTXPort:removeEventListener()
> called");
>> 		waitForTheNativeCodeSilly();
>> 		//if( monThread != null && monThread.isAlive() )
>> 		if( monThreadisInterrupted == true )
>> 		{
>> 			z.reportln( "	RXTXPort:removeEventListener()
>> already interrupted");
>> 			monThread = null;
>> 			SPEventListener = null;
>> 			return;
>> 		}
>> 		else if( monThread != null && monThread.isAlive() )
>> 		{
>> 			if (debug)
>> 				z.reportln( "
>> RXTXPort:Interrupt=true");
>> 			monThreadisInterrupted=true;
>> 			/*
>> 			   Notify all threads in this PID that something
> is up
>> 			   They will call back to see if its their
> thread
>> 			   using isInterrupted().
>> 			*/
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> interruptEventLoop");
>> // LINE 809			interruptEventLoop( ); It never returns
>> out of this
>>
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> monThread.join()");
>> 			try {
>> 				monThread.join(1000);
>> 			} catch (Exception ex) {
>> 				/* yikes */
>> 				ex.printStackTrace();
>> 			}
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:waiting on
>> isAlive()");
>> 			while( monThread.isAlive() )
>> 			{
>> 				if ( debug )
>> 					z.reportln( "	MonThread is
>> still alive!");
>> 				try {
>> 					monThread.join(1000);
>> 					Thread.sleep( 1000 );
>> 				} catch( Exception e ){}
>> 				//monThread.stop();
>> 			}
>>
>> 		}
>> 		if (debug)
>> 			z.reportln( "	RXTXPort:calling gc()");
>> 		monThread = null;
>> 		SPEventListener = null;
>> 		MonitorThreadLock = false;
>> 		MonitorThreadAlive=false;
>> 		monThreadisInterrupted=true;
>> 		z.reportln( "RXTXPort:removeEventListener() returning");
>> 	}
>>
>> -----Original Message-----
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On
Behalf
>
>> Of Trent Jarvi
>> Sent: Sunday, June 25, 2006 7:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] Pending release
>>
>>
>> With frustration, I was unable to get to the pending release this
>> weekend.
>> The release should be comming this next week once things calm down.
>> The source is in CVS except for a fix for multiple ports in windows.
>>
>> I had planned on doing the release this weekend but that was
disrupted
>
>> by my transportation failing in a spectacular fashion.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx 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 khattar31 at yahoo.com  Wed Jun 28 22:04:59 2006
From: khattar31 at yahoo.com (rahul khattar)
Date: Wed, 28 Jun 2006 21:04:59 -0700 (PDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
Message-ID: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>

Hi All,

I was looking at the src file on the last release.
I did notice a missing header file while trying to
compile the parallelport.dll. Would somebody be kind
enoughf to share the missing header file:
gnu_io_LPRPort.h

I am using MinGw to compile the same from Parinya
(which is an execellent tool)


Regards,
Rahul Khattar

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Thu Jun 29 03:43:53 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 03:43:53 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>
References: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606290341210.9561@www>

On Wed, 28 Jun 2006, rahul khattar wrote:

> Hi All,
>
> I was looking at the src file on the last release.
> I did notice a missing header file while trying to
> compile the parallelport.dll. Would somebody be kind
> enoughf to share the missing header file:
> gnu_io_LPRPort.h
>
> I am using MinGw to compile the same from Parinya
> (which is an execellent tool)
>

Hi Rahul

The gnu.io_LPRPort.h file is generated with javah.  You can see the 
command in the Makefile I presume.  You do not need rxtxParallel.dll to 
use w32 serial btw.

--
Trent Jarvi
tjarvi at qbang.org


From khattar31 at yahoo.com  Thu Jun 29 04:47:01 2006
From: khattar31 at yahoo.com (rahul khattar)
Date: Thu, 29 Jun 2006 03:47:01 -0700 (PDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606290341210.9561@www>
Message-ID: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>

Hi Trent 
I did notice this file is required in the source file
ParallelImp.c
on line 38

Attached the O/P 

Regards,
Rahul Khattar




--- Trent Jarvi <tjarvi at qbang.org> wrote:

> On Wed, 28 Jun 2006, rahul khattar wrote:
> 
> > Hi All,
> >
> > I was looking at the src file on the last release.
> > I did notice a missing header file while trying to
> > compile the parallelport.dll. Would somebody be
> kind
> > enoughf to share the missing header file:
> > gnu_io_LPRPort.h
> >
> > I am using MinGw to compile the same from Parinya
> > (which is an execellent tool)
> >
> 
> Hi Rahul
> 
> The gnu.io_LPRPort.h file is generated with javah. 
> You can see the 
> command in the Makefile I presume.  You do not need
> rxtxParallel.dll to 
> use w32 serial btw.
> 
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Error.zip
Type: application/x-zip-compressed
Size: 1746 bytes
Desc: 2948039066-Error.zip
Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060629/a5b6f783/Error-0020.bin

From tjarvi at qbang.org  Thu Jun 29 06:16:24 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 06:16:24 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606290614530.9561@www>

On Thu, 29 Jun 2006, rahul khattar wrote:

> Hi Trent
> I did notice this file is required in the source file
> ParallelImp.c
> on line 38
>
> Attached the O/P
>

The command to generate the .h file will be something like:

javah -classpath . -jni gnu.io.LPRPort

The makefile should have this.  There are several approaches to creating 
or using makefiles so I have no idea which one you used if any.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Thu Jun 29 06:20:51 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 06:20:51 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606290616420.9561@www>

> Here is how you can test if you have resources/ test environment. Write
> a program and try to open/close  different ports(I will say have a
> minimum of four) randomly and very frequently(may be 30 seconds), I am
> pretty sure you will see the deadlocks and it happens in the native call
> to interrptEventLoop in RXTXPort.java in removeEventListener() method
> call.

Hi Pawan

I'll try to find a way to reproduce this.  One thing to note is that you 
are using different kernel drivers (digi) to perform this task.  So I 
probably will not be able to reproduce the exact same environment.

In general, multiport kernel drivers have been tested far less than 
typical serial drivers.  This may or may not be an issue.

--
Trent Jarvi
tjarvi at qbang.org



From jhaysonn at gmail.com  Thu Jun 29 12:29:13 2006
From: jhaysonn at gmail.com (jhaysonn pathak)
Date: Thu, 29 Jun 2006 14:29:13 -0400
Subject: [Rxtx] RXTX install
Message-ID: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>

Hi Guys,

I'm doing trying to write a generative piece of Sonic Art using an EEG
plugged into a mac runnning Max/MSP.  I just recently discovered RXTX
drivers in my search for a piece of software that might give me more
output options for my EEG (I'm using the CEO from MindPeak).  I found
Bioera which uses RXTX drivers.  Thing is - I can't figure out how to
install RXTX correctly.

After I build the 'libSerial.jnilib' target inside of
'LibSerial.pbproj' I can't find the libSerial.jnilib file that
accompanies the RXTXcomm.jar nor do I know where to put them.

I also don't understand this part at the bottom of the OS X instructions at all:

"AFTER INSTALLATION VERY IMPORTANT
	check existence of the folder /var/spool/uucp
	if you don't have it create it with command
	sudo mkdir /var/spool/uucp
	permissions should be: drwxrwxr-x
	if they are not do command
	sudo chmod 775 /var/spool/uucp

	YOU should be a member of the uucp group
	you can check it with command
		niutil -readprop / /groups/uucp users
	you should see your name in output of the niutil command
	if you don't do following:
		sudo niutil -appendprop / /groups/uucp users <yourname>
			substitute  <yourname> with your user's name
			for example if your user name is peter:
				sudo niutil -appendprop / /groups/uucp users peter

	NOTES: RXTX.pkg should create uucp folder and insert your name  in
uucp group automatically"



I really appreciate any help that you guys can offer.  I've been
struggling with this for a while now as part of a research grant that
I was awarded.  Thanks again for the help.

Jhaysonn Pathak


From naranjo.manuel at gmail.com  Thu Jun 29 07:19:15 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 10:19:15 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606290614530.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www>
Message-ID: <44A3D353.6010605@gmail.com>

Speaking about Windows Support, I had seen that inside the 
rxtx-2.1-7-bins-r2 package inside Windows directory it says:
"i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will 
not make harm to anyone, and i'm almost sure that someone has noticed it 
before.
Cheers,
Manuel


From joachim at buechse.de  Thu Jun 29 13:25:16 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 29 Jun 2006 21:25:16 +0200
Subject: [Rxtx] RXTX install
In-Reply-To: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>
References: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>
Message-ID: <2A003E42-97E1-4237-8438-646BDE2E3961@buechse.de>

Hello Jhaysonn,

I assume you are trying to use the javax.comm version of RXTX.

Please use "cvs up" to update your download to the latest version of  
the repository. The latest version does not use lock files, so the  
mentioned process is no longer needed. Updating with CVS will also  
provide you with a new README.OSX file that should be simpler to  
understand.

You will find LibSerialUniversal.xcodeproj in MACOSX_IDE/Xcode. Put  
comm.jar (downloaded from Sun) into MACOSX_IDE/Xcode. Compile the  
library. You will find RXTXcomm.jar and librxtxSerial.jnilib in  
MACOSX_IDE/Xcode/build/Default

Best regards,
Joachim
---
Joachim B?chse
Softwarel?sungen und Beratung
Hadlaubsteig 2
CH-8006 Z?rich


On 29.06.2006, at 20:29, jhaysonn pathak wrote:

> Hi Guys,
>
> I'm doing trying to write a generative piece of Sonic Art using an EEG
> plugged into a mac runnning Max/MSP.  I just recently discovered RXTX
> drivers in my search for a piece of software that might give me more
> output options for my EEG (I'm using the CEO from MindPeak).  I found
> Bioera which uses RXTX drivers.  Thing is - I can't figure out how to
> install RXTX correctly.
>
> After I build the 'libSerial.jnilib' target inside of
> 'LibSerial.pbproj' I can't find the libSerial.jnilib file that
> accompanies the RXTXcomm.jar nor do I know where to put them.
>
> I also don't understand this part at the bottom of the OS X  
> instructions at all:
>
> "AFTER INSTALLATION VERY IMPORTANT
> 	check existence of the folder /var/spool/uucp
> 	if you don't have it create it with command
> 	sudo mkdir /var/spool/uucp
> 	permissions should be: drwxrwxr-x
> 	if they are not do command
> 	sudo chmod 775 /var/spool/uucp
>
> 	YOU should be a member of the uucp group
> 	you can check it with command
> 		niutil -readprop / /groups/uucp users
> 	you should see your name in output of the niutil command
> 	if you don't do following:
> 		sudo niutil -appendprop / /groups/uucp users <yourname>
> 			substitute  <yourname> with your user's name
> 			for example if your user name is peter:
> 				sudo niutil -appendprop / /groups/uucp users peter
>
> 	NOTES: RXTX.pkg should create uucp folder and insert your name  in
> uucp group automatically"
>
>
>
> I really appreciate any help that you guys can offer.  I've been
> struggling with this for a while now as part of a research grant that
> I was awarded.  Thanks again for the help.
>
> Jhaysonn Pathak
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From tjarvi at qbang.org  Thu Jun 29 19:30:00 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 19:30:00 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A3D353.6010605@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
Message-ID: <Pine.LNX.4.61.0606291923000.9561@www>

On Thu, 29 Jun 2006, Manuel Naranjo wrote:

> Speaking about Windows Support, I had seen that inside the
> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
> not make harm to anyone, and i'm almost sure that someone has noticed it
> before.

Hi Manuel

         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
     47421  01-30-06 00:23 
rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
     77759  03-01-06 12:01 
rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README


It looks normal to me.  There are no fancy tools used there :)

--
Trent Jarvi
tjarvi at qbang.org

From naranjo.manuel at gmail.com  Thu Jun 29 19:38:16 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 22:38:16 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606291923000.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com> <Pine.LNX.4.61.0606291923000.9561@www>
Message-ID: <44A48088.2040407@gmail.com>

> On Thu, 29 Jun 2006, Manuel Naranjo wrote:
> 
>> Speaking about Windows Support, I had seen that inside the
>> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
>> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
>> not make harm to anyone, and i'm almost sure that someone has noticed it
>> before.
> 
> Hi Manuel
> 
>         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
>         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
>     47421  01-30-06 00:23 
> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
>     77759  03-01-06 12:01 
> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
>       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README
> 
> 
> It looks normal to me.  There are no fancy tools used there :)
> 
Hi Trent:
Is not the i368 representing the name of the Architecture?? If so the 
name should start with i386 it will not break any system, is simply miss
written, I saw that and wanted to report it. It a silly thing.
Ohh I forgoten I must congratulate you for your GREAT libray, I was able 
to make an .exe with JSmooth that launches an application that uses RXTX 
with out the need to install RXTX on users system :). The .exe tells JVM 
where to find the RXTX Library and Binaries. I tried with Sun's Java 
Comm but it was imposible.
Regards,
Manuel


From tjarvi at qbang.org  Thu Jun 29 19:52:45 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 19:52:45 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A48088.2040407@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
	<Pine.LNX.4.61.0606291923000.9561@www> <44A48088.2040407@gmail.com>
Message-ID: <Pine.LNX.4.61.0606291945060.9561@www>

On Thu, 29 Jun 2006, Manuel Naranjo wrote:

>> On Thu, 29 Jun 2006, Manuel Naranjo wrote:
>>
>>> Speaking about Windows Support, I had seen that inside the
>>> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
>>> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
>>> not make harm to anyone, and i'm almost sure that someone has noticed it
>>> before.
>>
>> Hi Manuel
>>
>>         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
>>         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
>>     47421  01-30-06 00:23
>> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
>>     77759  03-01-06 12:01
>> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
>>       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README
>>
>>
>> It looks normal to me.  There are no fancy tools used there :)
>>
> Hi Trent:
> Is not the i368 representing the name of the Architecture?? If so the
> name should start with i386 it will not break any system, is simply miss
> written, I saw that and wanted to report it. It a silly thing.
> Ohh I forgoten I must congratulate you for your GREAT libray, I was able
> to make an .exe with JSmooth that launches an application that uses RXTX
> with out the need to install RXTX on users system :). The .exe tells JVM
> where to find the RXTX Library and Binaries. I tried with Sun's Java
> Comm but it was imposible.

Hi Manuel

The compiler uses only the i386 instruction set for windows.  I doubt 
there will be any measurable advantages with going to later instruction 
sets.  In theory rxtx would run on a 386 but I doubt anyone does that.

So it looks odd but is not a typo.

We could compile to i686 but don't.  The compiler used does not appear to 
be a problem yet so I don't see any point in changing it.  Right now, we 
could not compile 64 bit windows binaries.  gcc/mingw/... do not support 
them that I know of.  People will have to compile those with closed source 
tools on their own until an option is available.

--
Trent Jarvi
tjarvi at qbang.org

From naranjo.manuel at gmail.com  Thu Jun 29 20:00:48 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 23:00:48 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606291945060.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com>	<Pine.LNX.4.61.0606291923000.9561@www>
	<44A48088.2040407@gmail.com> <Pine.LNX.4.61.0606291945060.9561@www>
Message-ID: <44A485D0.7050202@gmail.com>

Trent you did not get my point
The folder says 368 three hundred sixty eight, when
it should say 386 three hundred eighty six. Is simply a miss writting.
Regards,
Manuel


From tjarvi at qbang.org  Thu Jun 29 20:12:15 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 20:12:15 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A485D0.7050202@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
	<Pine.LNX.4.61.0606291923000.9561@www> <44A48088.2040407@gmail.com>
	<Pine.LNX.4.61.0606291945060.9561@www> <44A485D0.7050202@gmail.com>
Message-ID: <Pine.LNX.4.61.0606292008061.9561@www>


On Thu, 29 Jun 2006, Manuel Naranjo wrote:

> Trent you did not get my point
> The folder says 368 three hundred sixty eight, when
> it should say 386 three hundred eighty six. Is simply a miss writting.

hehe..  OK.  My bad.  It's been a long day.

Nevermind :)

--
Trent Jarvi
tjarvi at qbang.org




From naranjo.manuel at gmail.com  Thu Jun 29 20:18:44 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 23:18:44 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606292008061.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com>	<Pine.LNX.4.61.0606291923000.9561@www>
	<44A48088.2040407@gmail.com>	<Pine.LNX.4.61.0606291945060.9561@www>
	<44A485D0.7050202@gmail.com> <Pine.LNX.4.61.0606292008061.9561@www>
Message-ID: <44A48A04.9040401@gmail.com>

Don't worry Trent.
About 64 bits compilation, I would like to colaborate, I have a Pc with 
64 bits, the only problem is that i do not have windows 64 bits 
installed :(.




From Pawan.Kharbanda at dot.state.co.us  Fri Jun 30 08:49:52 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 30 Jun 2006 08:49:52 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E996@hqexchange3.dot.state.co.us>

Trent,  
    Can you explain what the interruptedEventLoop() native method is
doing is there a possibility that method is somehow getting into the
infinite loop(there are 2 while loops without any break statements).
This might be a very basic question how can I debug the native code(or
print the debug statements).  Again thanks for the help. 

Pawan Kharbanda

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Thursday, June 29, 2006 6:21 AM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports

> Here is how you can test if you have resources/ test environment. 
> Write a program and try to open/close  different ports(I will say have

> a minimum of four) randomly and very frequently(may be 30 seconds), I 
> am pretty sure you will see the deadlocks and it happens in the native

> call to interrptEventLoop in RXTXPort.java in removeEventListener() 
> method call.

Hi Pawan

I'll try to find a way to reproduce this.  One thing to note is that you
are using different kernel drivers (digi) to perform this task.  So I
probably will not be able to reproduce the exact same environment.

In general, multiport kernel drivers have been tested far less than
typical serial drivers.  This may or may not be an issue.

--
Trent Jarvi
tjarvi at qbang.org

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From cpine at wrsystems.com  Thu Jun 29 15:17:12 2006
From: cpine at wrsystems.com (Chris Pine)
Date: Thu, 29 Jun 2006 17:17:12 -0400
Subject: [Rxtx]  Controlling Individual Signals DTR and RTS
Message-ID: <MAIL4FJo0S8ACLEBajJ000005cf@mail4.wrsystems.com>

Dear Moussa Ba,
	I hope I am not being too forward, but we are having the exact same
issue with needing to control DTR from RXTX in Linux.  Did you ever have any
luck figuring it out?

Thank you very much for your time,

Chris Pine




From tjarvi at qbang.org  Thu Jun  1 11:13:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 11:13:40 -0600 (MDT)
Subject: [Rxtx] custom baud rate win32
In-Reply-To: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606011107210.30220@www>


Hi Daren

I can't imagine that 1953 is possibly the actual value on the UART.  Maybe 
if your baud base is very high with a custom serial board.  More likely, 
the driver just remembers that what you asked for and did something else.

I'll have more to say on the dcb->BaudRate after I try some things here. 
I have managed to do something like that in the past as a quick hack but 
it was for 14400.  I may have used the CBR_14400.

If we can't access this through the win32 API with protected mode, there 
is another layer of complication.  With real mode, it would be easy.
With protected mode, I assume there would have to be some kernel driver or 
a hook I'm not aware of to access the MCR directly (bang a memory 
addresss).



On Thu, 1 Jun 2006, Daren wrote:

> Trent,
> I have managed to successfully open the port at this speed using Realterm
> (available on sourceforge). From memory this uses DLPortIO.
>
> Using portmon.exe with realterm, even there it says that the port has opened
> at 1953.
>
> I changed termios.c:560 to
> dcb->BaudRate        = 1953 ;
>
> and it still opens the port at 9600.
>
> Daren
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Trent Jarvi
> Sent: Thursday, 1 June 2006 1:44 PM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] custom baud rate win32
>
> On Thu, 1 Jun 2006, Daren wrote:
>
>> Hi all,
>>
>> I downloaded 2.1.7-pre16 and managed to build it and get it going. I made
>> the changes as suggested by Peter Smith in an old post, by adding his code
>> to SerialImpl.c, uncommenting the TIOCGSERIAL and TIOCSSERIAL, and
> defining
>> ASYNC_SPD_CUST which is equal to 0x0030 (according to linus header
> files)..
>>
>>
>> Still not working, it opens the port at 9600 according to portmon.exe .
> Has
>> anyone managed to get this going at a custom rate?
>>
>> Here is the post I'm referring to:
>> http://marc.theaimsgroup.com/?l=rxtx&m=106270038110713&w=2
>>
>>
>> Thanks,
>> Daren
>>
>> ________________________________________
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
>> Daren
>> Sent: Wednesday, 31 May 2006 10:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] (no subject)
>>
>> Hi All,
>> I have been using rxtx for a little while and needed to get it working at
>> 1953, like a past user in the mailing list, who seemed to have got it
>> working by changing some C code.
>>
>> I wanted to build rxtx myself with these changes but don't know where to
>> start. I have windows here and FC4 at home. I downloaded cygwin and
> mingw32,
>> each build works by building a rxtxSerial.dll file that is ~11k smaller
> than
>> the original, and I always get the following error when testing the dll:
>>
>> Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at
>> PC=0x8077655
>> Function=[Unknown.]
>> Library=C:\opt\java\j2sdk1.4.2\jre\bin\client\jvm.dll
>>
>> NOTE: We are unable to locate the function name symbol for the error
>>      just occurred. Please refer to release documentation for possible
>>      reason and solutions.
>>
>>
>> Current Java thread:
>> 	at gnu.io.RXTXPort.open(Native Method)
>> 	- locked <0x1002c800> (a gnu.io.RXTXPort)
>> 	at gnu.io.RXTXPort.<init>(RXTXPort.java:84)
>>
>> Anyone know what im doing wrong?
>>
>>
>>
>>
>
> Hi Daren
>
> You are running into the same rats nest I'm looking at now.
>
> With win32 and specific custom baud rates, I'm not sure how this will go.
> I've got the Linux custom baud rates working very nicely.  I did much like
> the post you linked.  In fact I had forgot about that post.  You probably
> noticed that it becomes a bunch of dirt roads going noplace fast in
> termios.c for w32.
>
> I'm probably only going to get 14400, 28800, 128000 and 256000 working
> with the next release on w32.  I'll look a little further.  If you have an
> example w32 that works at 1953 I'd really like to hear.  Thats an unusual
> baud rate.
>
> Assuming a baud_base of 128000, your divisor will be 65 or 66.
>
> 128000/66=1939 -14
> 128000/65=1969 +13
>
> One thing I've been wondering about with linux is which would be the right
> answer in cases like this.  Right now it would just go with a baud base of
> 65 and ignore the modulus details.
>
> It appears to be a general trend for kernel developers to hide these
> details thinking that they can come up with a general solution.  Then they
> run out of time.  Perahps the solution is to help out but there are
> ultiple OS's rxtx supports making that nontrivial.
>
> If you look at current linux kernels, the 'tricks' above have been marked
> deprecated with no replacement.  Windows has some hard defines and then
> ancient near magic.  I've not looked at Solaris via Open Solaris yet but
> doubt there is a solution at all.
>
> What I'd try since you have the equipment and the monitor software is to
> hardcode the dcb->Baud in termios.c to 1953 (no define) and see what the
> w32 kernel does with it.  I think if you toss a baud rate at the driver it
> will try to come close.  You may try comming closer to a real baudrate
> based upon the 128000 baud base as shown above.
>
> If it works, it is worth looking at the rest of the ping/pong logic then.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
>
>
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From doug at dupreeinc.com  Thu Jun  1 13:22:13 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 12:22:13 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011107210.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
Message-ID: <447F3E65.1020809@dupreeinc.com>

Hello,

I am still trying to get this startup a little faster so I turned on the 
debug of a few of the classes.  The COM ports are scanned really fast 
and the delay occurs during the LPT scan.  The console output looks like 
this:

    ...
      LPT1
      LPT2
      LPT3
     valid port prefixes:
      LPT
    LPT1 LPT
    1 1
    LPT2 LPT
    2 2                                                                 
      * <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
    CommPortIdentifier:addPortName(LPT2)
    CommPortIdentifier:AddIdentifierToList()
    LPT3 LPT
    3 3
    CommPortIdentifier:addPortName(LPT3)
    CommPortIdentifier:AddIdentifierToList()
    CommPortIdentifier:AddIdentifierToList() index.next
    Leaving registerValidPorts()
    Have not implemented native_psmisc_report_owner(PortName)); in
    CommPortIdentifier
    CommPortIdentifier:getPortIdentifier(COM3)
    CommPortIdentifier:open(densConnect, 30000)
    RXTXCommDriver:getCommPort(COM3,1)
    ...

It would seem to me that if I removed the code for port scanning of LPT 
ports I could solve this problem. I would much prefer to use unmodified 
code if at all possible.  Do any of you have alternate suggestions?

Thank you for your time.

Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/cf433ee7/attachment-0021.html

From tjarvi at qbang.org  Thu Jun  1 13:52:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 13:52:06 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F3E65.1020809@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011348380.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I am still trying to get this startup a little faster so I turned on the 
> debug of a few of the classes.  The COM ports are scanned really fast and the 
> delay occurs during the LPT scan.  The console output looks like this:
>
>   ...
>     LPT1
>     LPT2
>     LPT3
>    valid port prefixes:
>     LPT
>   LPT1 LPT
>   1 1
>   LPT2 LPT
>   2 2                                                                      * 
> <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>   CommPortIdentifier:addPortName(LPT2)
>   CommPortIdentifier:AddIdentifierToList()
>   LPT3 LPT
>   3 3
>   CommPortIdentifier:addPortName(LPT3)
>   CommPortIdentifier:AddIdentifierToList()
>   CommPortIdentifier:AddIdentifierToList() index.next
>   Leaving registerValidPorts()
>   Have not implemented native_psmisc_report_owner(PortName)); in
>   CommPortIdentifier
>   CommPortIdentifier:getPortIdentifier(COM3)
>   CommPortIdentifier:open(densConnect, 30000)
>   RXTXCommDriver:getCommPort(COM3,1)
>   ...
>
> It would seem to me that if I removed the code for port scanning of LPT ports 
> I could solve this problem. I would much prefer to use unmodified code if at 
> all possible.  Do any of you have alternate suggestions?
>
> Thank you for your time.
>
> Doug
>


Does commenting out the LPT enumeration actually help?  There can often be 
differences between debug information printed and whats really going on. 
When you combine various environments the debug info can even come out in 
the wrong order.

I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
I do not think this problem is universal.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Thu Jun  1 14:29:44 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:29:44 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4E38.2060004@dupreeinc.com>

I will give it a try.  One thing to note on this PC is it has no LPT 
Parallel ports.

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
>>Hello,
>>
>>I am still trying to get this startup a little faster so I turned on the 
>>debug of a few of the classes.  The COM ports are scanned really fast and the 
>>delay occurs during the LPT scan.  The console output looks like this:
>>
>>  ...
>>    LPT1
>>    LPT2
>>    LPT3
>>   valid port prefixes:
>>    LPT
>>  LPT1 LPT
>>  1 1
>>  LPT2 LPT
>>  2 2                                                                      * 
>><<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>>  CommPortIdentifier:addPortName(LPT2)
>>  CommPortIdentifier:AddIdentifierToList()
>>  LPT3 LPT
>>  3 3
>>  CommPortIdentifier:addPortName(LPT3)
>>  CommPortIdentifier:AddIdentifierToList()
>>  CommPortIdentifier:AddIdentifierToList() index.next
>>  Leaving registerValidPorts()
>>  Have not implemented native_psmisc_report_owner(PortName)); in
>>  CommPortIdentifier
>>  CommPortIdentifier:getPortIdentifier(COM3)
>>  CommPortIdentifier:open(densConnect, 30000)
>>  RXTXCommDriver:getCommPort(COM3,1)
>>  ...
>>
>>It would seem to me that if I removed the code for port scanning of LPT ports 
>>I could solve this problem. I would much prefer to use unmodified code if at 
>>all possible.  Do any of you have alternate suggestions?
>>
>>Thank you for your time.
>>
>>Doug
>>
>>    
>>
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/dd31fed5/attachment-0021.html

From doug at dupreeinc.com  Thu Jun  1 14:36:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:36:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4FC8.9080106@dupreeinc.com>

Trent,

I commented out the section in RegisterScannedPorts() that adds the 
three LPT ports to the CandidateDeviceNames string array.  The 
application started immediately.  This is probably not the way to do 
this, but it was quick ,dirty, and worked.

It would be nice if there was a way to pole the OS to see if there is 
even a port there, though I guess this is what this code is suppose to do...

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
> ...
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From lynn at swcp.com  Thu Jun  1 14:49:34 2006
From: lynn at swcp.com (lynn@swcp.com)
Date: Thu, 1 Jun 2006 20:49:34 -0000
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>,
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <twig.1149194974.97617@swcp.com>

Perhaps we could add an argument to port enumeration where if not specified,
you get the default behavior that looks for everything.  With a new
constructor that has an argument(or more) you could optionally declare it to
not inspect printer ports.

Existing code would work as it always has.  New code could be smarter.

Lynn



Doug Thistlethwaite <doug at dupreeinc.com> said:

> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
> >On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
> >
> >  
> >
> > ...
> >
> >
> >Does commenting out the LPT enumeration actually help?  There can often be 
> >differences between debug information printed and whats really going on. 
> >When you combine various environments the debug info can even come out in 
> >the wrong order.
> >
> >I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
> >I do not think this problem is universal.
> >
> >--
> >Trent Jarvi
> >tjarvi at qbang.org
> >_______________________________________________
> >Rxtx mailing list
> >Rxtx at qbang.org
> >http://mailman.qbang.org/mailman/listinfo/rxtx
> >
> >
> >  
> >
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



-- 





From jredman at ergotech.com  Thu Jun  1 15:20:20 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 01 Jun 2006 15:20:20 -0600
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
Message-ID: <447F5A14.6010803@ergotech.com>

Doug,

If you specifically request ports, eg:

-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

or
 
-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

Depending upon the version  (Windows is COM1:COM2, etc. I assume).

Does it still enumerate the parallel ports?

Jim

Doug Thistlethwaite wrote:
> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
>> On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>
>>  
>>
>> ...
>>
>>
>> Does commenting out the LPT enumeration actually help?  There can often be 
>> differences between debug information printed and whats really going on. 
>> When you combine various environments the debug info can even come out in 
>> the wrong order.
>>
>> I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>> I do not think this problem is universal.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>>
>>  
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  1 16:49:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:49:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6EF4.7080709@dupreeinc.com>

I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
folder.  I created this file and added the following to the file:

gnu.io.rxtx.SerialPorts=COM3

and I get the following error on the console:
CommPortIdentifier:static initialization()
RXTXCommDriver {}
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
RXTXCommDriver:
    Jar version = RXTX-2.1-7
    native lib Version = RXTX-2.1-7
RXTXCommDriver:initialize()
checking for system-known ports of type 1
checking registry for ports of type 1

RXTXCommDriver:addSpecifiedPorts()
Exception in thread "main" java.lang.ExceptionInInitializerError
    at 
densconnect.SerialConnection.openConnection(SerialConnection.java:136)
    at densconnect.DensTalk.<init>(DensTalk.java:165)
    at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
    at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
    at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
    at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
Caused by: java.lang.NullPointerException
    at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
CommPortIdentifier:addPortName(COM3)
CommPortIdentifier:AddIdentifierToList()
CommPortIdentifier:AddIdentifierToList() null
...


It looks like it  read COM3 from the file, but it had the above 
exception that killed it.  The strange this is this error is from 
RXTXCommDriver initialize function (if statement line):

        OS = System.getProperty("os.name");
                System.out.println("OS NAME: " + OS);
        if(OS.toLowerCase().indexOf("linux") == -1)

OS is returning null, thus the error.

If the file is not present, it scans the ports and reads the OS.

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>Doug Thistlethwaite wrote:
>  
>
>>Trent,
>>
>>I commented out the section in RegisterScannedPorts() that adds the 
>>three LPT ports to the CandidateDeviceNames string array.  The 
>>application started immediately.  This is probably not the way to do 
>>this, but it was quick ,dirty, and worked.
>>
>>It would be nice if there was a way to pole the OS to see if there is 
>>even a port there, though I guess this is what this code is suppose to do...
>>
>>Doug
>>
>>Trent Jarvi wrote:
>>
>>    
>>
>>>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>>
>>> 
>>>
>>>...
>>>
>>>
>>>Does commenting out the LPT enumeration actually help?  There can often be 
>>>differences between debug information printed and whats really going on. 
>>>When you combine various environments the debug info can even come out in 
>>>the wrong order.
>>>
>>>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>>>I do not think this problem is universal.
>>>
>>>--
>>>Trent Jarvi
>>>tjarvi at qbang.org
>>>_______________________________________________
>>>Rxtx mailing list
>>>Rxtx at qbang.org
>>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>>
>>>
>>> 
>>>
>>>      
>>>
>>_______________________________________________
>>Rxtx mailing list
>>Rxtx at qbang.org
>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>    
>>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/bf4cca0e/attachment-0021.html

From doug at dupreeinc.com  Thu Jun  1 16:51:26 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:51:26 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6F6E.5060603@dupreeinc.com>

Jim,

I did not try your suggestion as I do not understand where I would put 
these command line parameters (it that is what they are).  It appears 
that using the properties file should do that same thing...

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>
>  
>


From doug at dupreeinc.com  Thu Jun  1 17:56:19 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 16:56:19 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
Message-ID: <447F7EA3.6050400@dupreeinc.com>

I think there is an error in the registerSpecifiedPorts() method.  When 
I have a gnu.io.rxtx.properties file in the ext directory, this function 
kills the System class  IF I call System.getProperty("os.name") before 
the call  to registerSpecifiedPorts(), it returns the os name, after the 
call, it returns null.  I have not played much with properties, except 
for reading them, so I don't really understand the code.

Doug



From doug at dupreeinc.com  Thu Jun  1 18:11:14 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 17:11:14 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F7EA3.6050400@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com>
Message-ID: <447F8222.3060402@dupreeinc.com>

Ok, I just hacked this thing up and got it to read the 
gnu.io.rxtx.properties file.

I commented out the line:
System.setProperties(p); in the method registerSpecifiedPorts() in 
RXTXCommDriver class.  I really don't understand that much about 
properties, but this call kills the System class.

I used the following in the gnu.io.rxtx.properties file:

gnu.io.rxtx.SerialPorts=COM3
gnu.io.rxtx.ParallelPorts=null

This allows the application to open very quickly without any errors.  
Whomever coded this class or somebody who understands properties should 
look at this method and make sure it is doing what they expect.

Doug




Doug Thistlethwaite wrote:

>I think there is an error in the registerSpecifiedPorts() method.  When 
>I have a gnu.io.rxtx.properties file in the ext directory, this function 
>kills the System class  IF I call System.getProperty("os.name") before 
>the call  to registerSpecifiedPorts(), it returns the os name, after the 
>call, it returns null.  I have not played much with properties, except 
>for reading them, so I don't really understand the code.
>
>Doug
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From tjarvi at qbang.org  Thu Jun  1 18:32:50 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 18:32:50 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F6EF4.7080709@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com> <447F6EF4.7080709@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011831510.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
> folder.  I created this file and added the following to the file:
>
> gnu.io.rxtx.SerialPorts=COM3
>
> and I get the following error on the console:
> CommPortIdentifier:static initialization()
> RXTXCommDriver {}
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
> RXTXCommDriver:
>   Jar version = RXTX-2.1-7
>   native lib Version = RXTX-2.1-7
> RXTXCommDriver:initialize()
> checking for system-known ports of type 1
> checking registry for ports of type 1
>
> RXTXCommDriver:addSpecifiedPorts()
> Exception in thread "main" java.lang.ExceptionInInitializerError
>   at densconnect.SerialConnection.openConnection(SerialConnection.java:136)
>   at densconnect.DensTalk.<init>(DensTalk.java:165)
>   at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
>   at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
>   at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
>   at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
> Caused by: java.lang.NullPointerException
>   at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
> CommPortIdentifier:addPortName(COM3)
> CommPortIdentifier:AddIdentifierToList()
> CommPortIdentifier:AddIdentifierToList() null
> ...
>
>

There is a solution for this bug.

http://bugzilla.qbang.org/show_bug.cgi?id=54

We have been horribly slow at getting the next round of patches in but 
they are comming.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  2 00:58:02 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 08:58:02 +0200
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F8222.3060402@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
Message-ID: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>

Hi Doug,

you wrote in an earlier message, that you would prefer an unchanged  
version. What about simply removing the RXTX parallel lib from the  
ext directory. This does not fix the bug, but it should fix your  
problem.

In general I think it is not a good idea to put the RXTX files in a  
system wide location. Putting the libs in the application folder and  
including the .jar in the application classpath (or application jar)  
is all that is required.

Regards,
Joachim

On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:

> Ok, I just hacked this thing up and got it to read the
> gnu.io.rxtx.properties file.
>
> I commented out the line:
> System.setProperties(p); in the method registerSpecifiedPorts() in
> RXTXCommDriver class.  I really don't understand that much about
> properties, but this call kills the System class.
>
> I used the following in the gnu.io.rxtx.properties file:
>
> gnu.io.rxtx.SerialPorts=COM3
> gnu.io.rxtx.ParallelPorts=null
>
> This allows the application to open very quickly without any errors.
> Whomever coded this class or somebody who understands properties  
> should
> look at this method and make sure it is doing what they expect.
>
> Doug
>
>
>
>
> Doug Thistlethwaite wrote:
>
>> I think there is an error in the registerSpecifiedPorts() method.   
>> When
>> I have a gnu.io.rxtx.properties file in the ext directory, this  
>> function
>> kills the System class  IF I call System.getProperty("os.name")  
>> before
>> the call  to registerSpecifiedPorts(), it returns the os name,  
>> after the
>> call, it returns null.  I have not played much with properties,  
>> except
>> for reading them, so I don't really understand the code.
>>
>> 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 antonio.luis at iscte.pt  Fri Jun  2 02:42:28 2006
From: antonio.luis at iscte.pt (=?ISO-8859-1?Q?Ant=F3nio_Lopes?=)
Date: Fri, 02 Jun 2006 09:42:28 +0100
Subject: [Rxtx] Exception when closing serial port
Message-ID: <447FF9F4.7060209@iscte.pt>

Hello everyone,
I've been using RXTX in a Java application in my Pocket PC.
The communication through the (bluetooth) serial port is working perfectly.

However, when I disconnect the app and close the serial port, sometimes I get 
the following error:

"1149237595000: RXTXPort:close detected bad File Descriptor"

The problem is that after this error occurs, the app is no longer able to 
connect to the serial port and I have to soft-reset the device in order to be 
able to connect to it again.

Any ideas on how to solve this issue?

Any help is appreciated.
Thanks,
regards,
-- 
Ant?nio Lopes

@contact: antonio.luis at iscte.pt
@work: ADETTI - ISCTE
@web: http://antonio.lopes.googlepages.com


From paul.klissner at sun.com  Fri Jun  2 02:44:34 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 01:44:34 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to RXTX
	again
Message-ID: <447FFA72.6040807@sun.com>

After looking into javax.comm 3.1 and what it would take to re-engineer it
to be compatible with RXTX platform libraries, I've decided, due my group's
priorities, complexity of the effort vs. benefit, and limited resources, 
to re-post
javax.comm 2.0 binaries on Sun's software download server, unsupported,
with disclaimers, as it was previously.

I don't think there will be any snags doing this from the standpoint of Sun
management or legality.  I will try to have it  posted there in the next 
week
or two, depending on how fast we can get it pushed through the process.

I'd like to think of this as a stop gap measure... ie. a compromise, 
where, at some
point in the not too distant future RXTX implements their own version of the
Java side of the API, as is normally done by javax.extension porters. 
That way
we avoid uncomfortable dependencies in the future.  And that really is 
the Java
development model.

Since RXTX already has the back-end code, porting the java code shouldn't
be a gargantuan effort at all, and RXTX will be in full control of the 
code top
to bottom. I think RXTX can do at least as good a job as the original 
coder.
Prepping 2.0 to be open sourced is more trouble than it is worth. ie. I 
don't
think the current implementation warrants it.

Ultimately, it would be nice to see someone open up a JSR and re-architect
the comm. API to overcome some of it's current design flaws (ie. be more
adaptable to modern platforms, more pluggable, better defined SPI, better
port ownership handling, etc...). A superior architecture would allow for
better collaboration in the future and better interchangeability of 
components
among projects.

Sun's 3.1 version of javax.comm, which is Sun's currently supported version,
has changes pertaining mostly to Sun platform-specific portmapping and has
some minor additional interactions with our back end code, but generally
has little bearing on RXTX. 

Paul



From joachim at buechse.de  Fri Jun  2 04:00:19 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 12:00:19 +0200
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
	RXTX again
In-Reply-To: <447FFA72.6040807@sun.com>
References: <447FFA72.6040807@sun.com>
Message-ID: <1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>

Good day Paul!

A clean architecture with loadable drivers and reusable code would be  
very beneficial for the future, I think everybody agrees. However  
this could be several years into the future. In the meantime, there  
is a real existing problem with IO support on Java. I have the strong  
feeling that most programmers want to code against one specification  
(javax.comm) and be able to replace the underlying implementation via  
a "plugin" on platforms where the SUN implementation is not  
sufficient. RXTX could be just this plugin (reusing very close to 0%  
of the javax.comm implementation but 100% of its API).

I want to propose an API addition and implementation change that will  
take less then 2 hours of manpower to implement and create a solution  
that can bridge the years until javax.comm has been based on a new  
architecture.

Looking at the javax.comm api at http://java.sun.com/products/ 
javacomm/reference/api/index.html I would like to propose the following:

The only entry point to javax.comm is CommPortIdentifier. It has 3  
static methods plus the constructor.

1) define one additional Interface

public interface CommProvider {
    CommPortIdentifier getPortIdentifier(CommPort port);
    CommPortIdentifier getPortIdentifier(String portName);
    Enumeration getPortIdentifiers ();
}

2) add one method to CommPortIdentifier

   public static setCustomCommProvider (CommProvider);

3) change the three static methods of CommPortIdentifier to dispatch  
to the CommProvider if it is set

4) change the constructor of CommPortIdentifier to

   public CommPortIdentifier(...) {
      if (isProviderSet && this.getClass() ==  
javax.comm.CommPortIdentifier) {
          throw new RuntimeException("illegal creation of  
CommPortIndentifier, custom CommProvider is in use");
      }

5) (this is optional, but would be very nice) automatically set a  
custom CommProvider if it is found on the classpath or defined via a  
system property.


The above 1) - 4) can be implemented in less than 1hour. 5) may take  
another hour. I agree that this is not the most elegant design, but  
it would solve a lot of problems with very little effort. It would  
certainly allow RXTX to move forward. If the javax.comm API needs to  
be redesigned completely this addition will not hurt, as people will  
move to the new API anyway and javax.comm 3.0 was so far never  
included in the main distribution.

Best regards,
Joachim

On 02.06.2006, at 10:44, Paul Klissner wrote:

> After looking into javax.comm 3.1 and what it would take to re- 
> engineer it
> to be compatible with RXTX platform libraries, I've decided, due my  
> group's
> priorities, complexity of the effort vs. benefit, and limited  
> resources,
> to re-post
> javax.comm 2.0 binaries on Sun's software download server,  
> unsupported,
> with disclaimers, as it was previously.
>
> I don't think there will be any snags doing this from the  
> standpoint of Sun
> management or legality.  I will try to have it  posted there in the  
> next
> week
> or two, depending on how fast we can get it pushed through the  
> process.
>
> I'd like to think of this as a stop gap measure... ie. a compromise,
> where, at some
> point in the not too distant future RXTX implements their own  
> version of the
> Java side of the API, as is normally done by javax.extension porters.
> That way
> we avoid uncomfortable dependencies in the future.  And that really is
> the Java
> development model.
>
> Since RXTX already has the back-end code, porting the java code  
> shouldn't
> be a gargantuan effort at all, and RXTX will be in full control of the
> code top
> to bottom. I think RXTX can do at least as good a job as the original
> coder.
> Prepping 2.0 to be open sourced is more trouble than it is worth.  
> ie. I
> don't
> think the current implementation warrants it.
>
> Ultimately, it would be nice to see someone open up a JSR and re- 
> architect
> the comm. API to overcome some of it's current design flaws (ie. be  
> more
> adaptable to modern platforms, more pluggable, better defined SPI,  
> better
> port ownership handling, etc...). A superior architecture would  
> allow for
> better collaboration in the future and better interchangeability of
> components
> among projects.
>
> Sun's 3.1 version of javax.comm, which is Sun's currently supported  
> version,
> has changes pertaining mostly to Sun platform-specific portmapping  
> and has
> some minor additional interactions with our back end code, but  
> generally
> has little bearing on RXTX.
>
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Fri Jun  2 09:10:13 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Fri, 2 Jun 2006 09:10:13 -0600 (MDT)
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <447FFA72.6040807@sun.com>
References: <447FFA72.6040807@sun.com>
Message-ID: <Pine.LNX.4.61.0606020906400.15971@www>

On Fri, 2 Jun 2006, Paul Klissner wrote:

> After looking into javax.comm 3.1 and what it would take to re-engineer it
> to be compatible with RXTX platform libraries, I've decided, due my group's
> priorities, complexity of the effort vs. benefit, and limited resources,
> to re-post
> javax.comm 2.0 binaries on Sun's software download server, unsupported,
> with disclaimers, as it was previously.
>

Hi Paul

To address users' immediate needs, we can release rxtx 2.0-7 (final) to 
match the 2.0 binaries from Sun when they are offered for download.

We can discuss potential long term solutions after that.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Fri Jun  2 10:20:09 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 02 Jun 2006 09:20:09 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
	<9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
Message-ID: <44806539.8080902@dupreeinc.com>

Thanks for the suggestion, I will give it a try.

Doug

Joachim Buechse wrote:

>Hi Doug,
>
>you wrote in an earlier message, that you would prefer an unchanged  
>version. What about simply removing the RXTX parallel lib from the  
>ext directory. This does not fix the bug, but it should fix your  
>problem.
>
>In general I think it is not a good idea to put the RXTX files in a  
>system wide location. Putting the libs in the application folder and  
>including the .jar in the application classpath (or application jar)  
>is all that is required.
>
>Regards,
>Joachim
>
>On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:
>
>  
>
>>Ok, I just hacked this thing up and got it to read the
>>gnu.io.rxtx.properties file.
>>
>>I commented out the line:
>>System.setProperties(p); in the method registerSpecifiedPorts() in
>>RXTXCommDriver class.  I really don't understand that much about
>>properties, but this call kills the System class.
>>
>>I used the following in the gnu.io.rxtx.properties file:
>>
>>gnu.io.rxtx.SerialPorts=COM3
>>gnu.io.rxtx.ParallelPorts=null
>>
>>This allows the application to open very quickly without any errors.
>>Whomever coded this class or somebody who understands properties  
>>should
>>look at this method and make sure it is doing what they expect.
>>
>>Doug
>>
>>
>>
>>
>>Doug Thistlethwaite wrote:
>>
>>    
>>
>>>I think there is an error in the registerSpecifiedPorts() method.   
>>>When
>>>I have a gnu.io.rxtx.properties file in the ext directory, this  
>>>function
>>>kills the System class  IF I call System.getProperty("os.name")  
>>>before
>>>the call  to registerSpecifiedPorts(), it returns the os name,  
>>>after the
>>>call, it returns null.  I have not played much with properties,  
>>>except
>>>for reading them, so I don't really understand the code.
>>>
>>>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
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060602/c8892a46/attachment-0021.html

From paul.klissner at sun.com  Fri Jun  2 12:09:26 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 11:09:26 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
Message-ID: <44807ED6.8000903@sun.com>

Joachim Buechse wrote:
> Good day Paul!
>
> A clean architecture with loadable drivers and reusable code would be  
> very beneficial for the future, I think everybody agrees. However  
> this could be several years into the future. In the meantime, there  
> is a real existing problem with IO support on Java. I have the strong  
> feeling that most programmers want to code against one specification  
> (javax.comm) and be able to replace the underlying implementation via  
> a "plugin" on platforms where the SUN implementation is not  
> sufficient. RXTX could be just this plugin (reusing very close to 0%  
> of the javax.comm implementation but 100% of its API).
>
> I want to propose an API addition and implementation change that will  
> take less then 2 hours of manpower to implement and create a solution  
> that can bridge the years until javax.comm has been based on a new  
> architecture.
>
> Looking at the javax.comm api at http://java.sun.com/products/ 
> javacomm/reference/api/index.html I would like to propose the following:
>
> The only entry point to javax.comm is CommPortIdentifier. It has 3  
> static methods plus the constructor.
>
> 1) define one additional Interface
>
> public interface CommProvider {
>     CommPortIdentifier getPortIdentifier(CommPort port);
>     CommPortIdentifier getPortIdentifier(String portName);
>     Enumeration getPortIdentifiers ();
> }
>
> 2) add one method to CommPortIdentifier
>
>    public static setCustomCommProvider (CommProvider);
>
> 3) change the three static methods of CommPortIdentifier to dispatch  
> to the CommProvider if it is set
>
> 4) change the constructor of CommPortIdentifier to
>
>    public CommPortIdentifier(...) {
>       if (isProviderSet && this.getClass() ==  
> javax.comm.CommPortIdentifier) {
>           throw new RuntimeException("illegal creation of  
> CommPortIndentifier, custom CommProvider is in use");
>       }
>
> 5) (this is optional, but would be very nice) automatically set a  
> custom CommProvider if it is found on the classpath or defined via a  
> system property.
>
>
> The above 1) - 4) can be implemented in less than 1hour. 5) may take  
> another hour. I agree that this is not the most elegant design, but  
> it would solve a lot of problems with very little effort. It would  
> certainly allow RXTX to move forward. If the javax.comm API needs to  
> be redesigned completely this addition will not hurt, as people will  
> move to the new API anyway and javax.comm 3.0 was so far never  
> included in the main distribution.
>
> Best regards,
> Joachi
I'm afraid modifying the interface classes isn't my call.  There was 
actually
a TCK written and one of the tests was to ensure that the interface classes
match the spec.  Thus my hands have already been tied since this project
was essentially grandfathered into the JCP.

That's why we need to open a new JSR and find someone who wants
to be the spec lead, and go in with a new reference implementation.
I'm not sure why it would have to take years, since this isn't bleeding edge
technology and there are only so many things that can be done with it,
and we already have practical experience about many functional aspects
that we could cite precedence on.

As it becomes clear that the specification is being accepted completely
or by-and-large by the community, nothing would stop people from
starting adapting to the new API (using the reference implementation or
porting it) and using it in their projects prior to it's final community and
JCP approval, since approval is required only to make it official and
get the "100% pure java" certification for platform ports.

You have one idea already.  Why don't you implement it, solicit some
design feedback from Sun and the RXTX, and create a functional
implementation that addresses the needs of the community, then
we can document it and open a JSR.  That's it.  It should march through
the approval stages reasonably quickly I would imagine, and meantime
RXTX could start using it.

Paul




From doug at dupreeinc.com  Fri Jun  2 12:45:01 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 02 Jun 2006 11:45:01 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
	<9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
Message-ID: <4480872D.6000605@dupreeinc.com>

Joachim,

Thank you for the suggestion.  I restored the jar file to the one I 
downloaded, moved the dll files into the project directory, and added 
the jar to the classpath.  The SerialDemo program that was included with 
the Sun commapi started in 12 seconds instead of the 58 seconds when the 
parallel dll is present.  I did get the startup time to about a second 
by modifying the java code and adding the properties file but this is 
probably not a good idea.

Doug

Joachim Buechse wrote:

>Hi Doug,
>
>you wrote in an earlier message, that you would prefer an unchanged  
>version. What about simply removing the RXTX parallel lib from the  
>ext directory. This does not fix the bug, but it should fix your  
>problem.
>
>In general I think it is not a good idea to put the RXTX files in a  
>system wide location. Putting the libs in the application folder and  
>including the .jar in the application classpath (or application jar)  
>is all that is required.
>
>Regards,
>Joachim
>
>On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:
>
>  
>
>>Ok, I just hacked this thing up and got it to read the
>>gnu.io.rxtx.properties file.
>>
>>I commented out the line:
>>System.setProperties(p); in the method registerSpecifiedPorts() in
>>RXTXCommDriver class.  I really don't understand that much about
>>properties, but this call kills the System class.
>>
>>I used the following in the gnu.io.rxtx.properties file:
>>
>>gnu.io.rxtx.SerialPorts=COM3
>>gnu.io.rxtx.ParallelPorts=null
>>
>>This allows the application to open very quickly without any errors.
>>Whomever coded this class or somebody who understands properties  
>>should
>>look at this method and make sure it is doing what they expect.
>>
>>Doug
>>
>>
>>
>>
>>Doug Thistlethwaite wrote:
>>
>>    
>>
>>>I think there is an error in the registerSpecifiedPorts() method.   
>>>When
>>>I have a gnu.io.rxtx.properties file in the ext directory, this  
>>>function
>>>kills the System class  IF I call System.getProperty("os.name")  
>>>before
>>>the call  to registerSpecifiedPorts(), it returns the os name,  
>>>after the
>>>call, it returns null.  I have not played much with properties,  
>>>except
>>>for reading them, so I don't really understand the code.
>>>
>>>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
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060602/3c0e420f/attachment-0021.html

From joachim at buechse.de  Fri Jun  2 13:46:36 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 21:46:36 +0200
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
	RXTX again
In-Reply-To: <44807ED6.8000903@sun.com>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
	<44807ED6.8000903@sun.com>
Message-ID: <6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>

Hello Paul,

of course, the basic change I suggested could be done "hidden".  The  
CommProvider interface could live somewhere in sun.xyz.*
The setCustomCommProvider method would not be in CommPortIdentifier  
but also somewhere in sun.xyz.* This would be an unofficial feature,  
the official interface stays exactly the same. However RXTX (and  
others) could access the hidden interface.

Don't get me wrong, I don't want to harass you into making changes  
you don't like (which probably wouldn't work anyway;-). But I'm a  
long time Java programmer and seeing the state of cross platform  
serial support for Java makes me feel really sad. In fact, when I  
started to look into Java serial port programming some months ago I  
was very surprised that javax.comm never made it into the JDK.

I'm sorry that I did not contribute my feedback to the JSR for  
javax.comm 3.0. However at the time I didn't do serial port  
programming in Java. I agree that a new JSR should be opened - I'm  
not an expert on JSRs or the JCP process, but from looking quickly  
over the progress of some JSRs I would be very surprised if we can  
have a new version in less then a year. In the meanwhile some people  
will start using javax.comm 3.0 (which can not be supported by RXTX),  
some will use javax.comm 2.0 (which means the 2.0.7 release of RXTX  
still needs to be maintained). This may get even worse if eg Apple  
decides to port and include javax.comm 3.0 at which point it may get  
very tricky to write a cross platform Java application.

All of this simply means, that we are loosing a lot of man-power that  
could otherwise be invested in building a clean solution and/or to  
add features that are becoming more and more important (USB events...).

In the automation / machine control universe Java makes a lot of  
sense. Right now many people are migrating to Linux or from  
propietary systems (even DOS) to Windows. Writing the control/ 
configuration applications in Java is the kings way to unify the code  
base.

Best regards,
Joachim


On 02.06.2006, at 20:09, Paul Klissner wrote:

> Joachim Buechse wrote:
>> Good day Paul!
>>
>> A clean architecture with loadable drivers and reusable code would be
>> very beneficial for the future, I think everybody agrees. However
>> this could be several years into the future. In the meantime, there
>> is a real existing problem with IO support on Java. I have the strong
>> feeling that most programmers want to code against one specification
>> (javax.comm) and be able to replace the underlying implementation via
>> a "plugin" on platforms where the SUN implementation is not
>> sufficient. RXTX could be just this plugin (reusing very close to 0%
>> of the javax.comm implementation but 100% of its API).
>>
>> I want to propose an API addition and implementation change that will
>> take less then 2 hours of manpower to implement and create a solution
>> that can bridge the years until javax.comm has been based on a new
>> architecture.
>>
>> Looking at the javax.comm api at http://java.sun.com/products/
>> javacomm/reference/api/index.html I would like to propose the  
>> following:
>>
>> The only entry point to javax.comm is CommPortIdentifier. It has 3
>> static methods plus the constructor.
>>
>> 1) define one additional Interface
>>
>> public interface CommProvider {
>>     CommPortIdentifier getPortIdentifier(CommPort port);
>>     CommPortIdentifier getPortIdentifier(String portName);
>>     Enumeration getPortIdentifiers ();
>> }
>>
>> 2) add one method to CommPortIdentifier
>>
>>    public static setCustomCommProvider (CommProvider);
>>
>> 3) change the three static methods of CommPortIdentifier to dispatch
>> to the CommProvider if it is set
>>
>> 4) change the constructor of CommPortIdentifier to
>>
>>    public CommPortIdentifier(...) {
>>       if (isProviderSet && this.getClass() ==
>> javax.comm.CommPortIdentifier) {
>>           throw new RuntimeException("illegal creation of
>> CommPortIndentifier, custom CommProvider is in use");
>>       }
>>
>> 5) (this is optional, but would be very nice) automatically set a
>> custom CommProvider if it is found on the classpath or defined via a
>> system property.
>>
>>
>> The above 1) - 4) can be implemented in less than 1hour. 5) may take
>> another hour. I agree that this is not the most elegant design, but
>> it would solve a lot of problems with very little effort. It would
>> certainly allow RXTX to move forward. If the javax.comm API needs to
>> be redesigned completely this addition will not hurt, as people will
>> move to the new API anyway and javax.comm 3.0 was so far never
>> included in the main distribution.
>>
>> Best regards,
>> Joachi
> I'm afraid modifying the interface classes isn't my call.  There was
> actually
> a TCK written and one of the tests was to ensure that the interface  
> classes
> match the spec.  Thus my hands have already been tied since this  
> project
> was essentially grandfathered into the JCP.
>
> That's why we need to open a new JSR and find someone who wants
> to be the spec lead, and go in with a new reference implementation.
> I'm not sure why it would have to take years, since this isn't  
> bleeding edge
> technology and there are only so many things that can be done with it,
> and we already have practical experience about many functional aspects
> that we could cite precedence on.
>
> As it becomes clear that the specification is being accepted  
> completely
> or by-and-large by the community, nothing would stop people from
> starting adapting to the new API (using the reference  
> implementation or
> porting it) and using it in their projects prior to it's final  
> community and
> JCP approval, since approval is required only to make it official and
> get the "100% pure java" certification for platform ports.
>
> You have one idea already.  Why don't you implement it, solicit some
> design feedback from Sun and the RXTX, and create a functional
> implementation that addresses the needs of the community, then
> we can document it and open a JSR.  That's it.  It should march  
> through
> the approval stages reasonably quickly I would imagine, and meantime
> RXTX could start using it.
>
> Paul
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From paul.klissner at sun.com  Fri Jun  2 14:38:49 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 13:38:49 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
	<44807ED6.8000903@sun.com>
	<6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>
Message-ID: <4480A1D9.5060106@sun.com>

Joachim Buechse wrote:
> Hello Paul,
>
> of course, the basic change I suggested could be done "hidden".  The  
> CommProvider interface could live somewhere in sun.xyz.*
> The setCustomCommProvider method would not be in CommPortIdentifier  
> but also somewhere in sun.xyz.* This would be an unofficial feature,  
> the official interface stays exactly the same. However RXTX (and  
> others) could access the hidden interface.
>
> Don't get me wrong, I don't want to harass you into making changes  
> you don't like (which probably wouldn't work anyway;-). But I'm a  
> long time Java programmer and seeing the state of cross platform  
> serial support for Java makes me feel really sad. In fact, when I  
> started to look into Java serial port programming some months ago I  
> was very surprised that javax.comm never made it into the JDK.
>
> I'm sorry that I did not contribute my feedback to the JSR for  
> javax.comm 3.0. 
There was no JSR for 3.0, because we didn't have the resources to make 
the commitment.
Yet Sun needed to add support for platform-dependent port name mapping, 
which had to
be done 'under the hood', since the API isn't designed to handle that in 
a pluggable way.
But these quick fixes aren't the right approach, they just kick the dog 
down the road,
setting bad precedent, inviting confusion and more intractable problems 
(such as the
one plaguing us now).

My changes could have been layered better, it was a trade off between 
achieving an
ideal architecture, trying to find internal reviewers, and meet the 
needs of big customers
in a timely way.  Thus my namespace changes collided with RXTX's 
dependencies.
I was unaware of Jagane's rogue agreement made with the RXTX community 7 
years ago,
before Jagane left Sun.  I think this was a wag-the-dog situation.

Now it is time to do it right, and I don't think it is going to be as 
much trouble as people
some people fear. If RXTX wants to sponsor the JSR and seed a new spec, 
Sun can join
the Expert Group.  And we'd be largely in agreement, since we're not 
talking about
humongous changes, and looking for mutually beneficial changes. The core 
API is already
largely proved and tested.
> However at the time I didn't do serial port  
> programming in Java. I agree that a new JSR should be opened - I'm  
> not an expert on JSRs or the JCP process, but from looking quickly  
> over the progress of some JSRs I would be very surprised if we can  
> have a new version in less then a year. 
*Approved*  But that doesn't mean the spec couldn't be 99.9% stable 
before that.  Once
the delta rate declines and changes approach nil, people could start 
adapting to the API in
advance of formal approval.   It isn't going to be drawn out like 
javax.usb, which was new
technology, a very complex API, and involved precedent setting corporate 
disputes and
policy issues to resolve.

> In the meanwhile some people  
> will start using javax.comm 3.0 (which can not be supported by RXTX),  
> some will use javax.comm 2.0 (which means the 2.0.7 release of RXTX  
> still needs to be maintained). This may get even worse if eg Apple  
> decides to port and include javax.comm 3.0 at which point it may get  
> very tricky to write a cross platform Java application.
>   
The interfaces haven't changed since 1.0.  If we open a JSR ,we can 
contact Apple and
allow them to be on the E.G., if they want.  That might make the JSR a 
bit more drawn out,
but then we'd arrive ultimately arrive at a best-of-all-worlds API that 
most people would
accept, perhaps forever, and arrive at a respectable set of compromises.

-Paul

> All of this simply means, that we are loosing a lot of man-power that  
> could otherwise be invested in building a clean solution and/or to  
> add features that are becoming more and more important (USB events...).
>
> In the automation / machine control universe Java makes a lot of  
> sense. Right now many people are migrating to Linux or from  
> propietary systems (even DOS) to Windows. Writing the control/ 
> configuration applications in Java is the kings way to unify the code  
> base.
>
> Best regards,
> Joachim
>
>
> On 02.06.2006, at 20:09, Paul Klissner wrote:
>
>   
>> Joachim Buechse wrote:
>>     
>>> Good day Paul!
>>>
>>> A clean architecture with loadable drivers and reusable code would be
>>> very beneficial for the future, I think everybody agrees. However
>>> this could be several years into the future. In the meantime, there
>>> is a real existing problem with IO support on Java. I have the strong
>>> feeling that most programmers want to code against one specification
>>> (javax.comm) and be able to replace the underlying implementation via
>>> a "plugin" on platforms where the SUN implementation is not
>>> sufficient. RXTX could be just this plugin (reusing very close to 0%
>>> of the javax.comm implementation but 100% of its API).
>>>
>>> I want to propose an API addition and implementation change that will
>>> take less then 2 hours of manpower to implement and create a solution
>>> that can bridge the years until javax.comm has been based on a new
>>> architecture.
>>>
>>> Looking at the javax.comm api at http://java.sun.com/products/
>>> javacomm/reference/api/index.html I would like to propose the  
>>> following:
>>>
>>> The only entry point to javax.comm is CommPortIdentifier. It has 3
>>> static methods plus the constructor.
>>>
>>> 1) define one additional Interface
>>>
>>> public interface CommProvider {
>>>     CommPortIdentifier getPortIdentifier(CommPort port);
>>>     CommPortIdentifier getPortIdentifier(String portName);
>>>     Enumeration getPortIdentifiers ();
>>> }
>>>
>>> 2) add one method to CommPortIdentifier
>>>
>>>    public static setCustomCommProvider (CommProvider);
>>>
>>> 3) change the three static methods of CommPortIdentifier to dispatch
>>> to the CommProvider if it is set
>>>
>>> 4) change the constructor of CommPortIdentifier to
>>>
>>>    public CommPortIdentifier(...) {
>>>       if (isProviderSet && this.getClass() ==
>>> javax.comm.CommPortIdentifier) {
>>>           throw new RuntimeException("illegal creation of
>>> CommPortIndentifier, custom CommProvider is in use");
>>>       }
>>>
>>> 5) (this is optional, but would be very nice) automatically set a
>>> custom CommProvider if it is found on the classpath or defined via a
>>> system property.
>>>
>>>
>>> The above 1) - 4) can be implemented in less than 1hour. 5) may take
>>> another hour. I agree that this is not the most elegant design, but
>>> it would solve a lot of problems with very little effort. It would
>>> certainly allow RXTX to move forward. If the javax.comm API needs to
>>> be redesigned completely this addition will not hurt, as people will
>>> move to the new API anyway and javax.comm 3.0 was so far never
>>> included in the main distribution.
>>>
>>> Best regards,
>>> Joachi
>>>       
>> I'm afraid modifying the interface classes isn't my call.  There was
>> actually
>> a TCK written and one of the tests was to ensure that the interface  
>> classes
>> match the spec.  Thus my hands have already been tied since this  
>> project
>> was essentially grandfathered into the JCP.
>>
>> That's why we need to open a new JSR and find someone who wants
>> to be the spec lead, and go in with a new reference implementation.
>> I'm not sure why it would have to take years, since this isn't  
>> bleeding edge
>> technology and there are only so many things that can be done with it,
>> and we already have practical experience about many functional aspects
>> that we could cite precedence on.
>>
>> As it becomes clear that the specification is being accepted  
>> completely
>> or by-and-large by the community, nothing would stop people from
>> starting adapting to the new API (using the reference  
>> implementation or
>> porting it) and using it in their projects prior to it's final  
>> community and
>> JCP approval, since approval is required only to make it official and
>> get the "100% pure java" certification for platform ports.
>>
>> You have one idea already.  Why don't you implement it, solicit some
>> design feedback from Sun and the RXTX, and create a functional
>> implementation that addresses the needs of the community, then
>> we can document it and open a JSR.  That's it.  It should march  
>> through
>> the approval stages reasonably quickly I would imagine, and meantime
>> RXTX could start using it.
>>
>> Paul
>>
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at 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  Sat Jun  3 18:15:24 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 18:15:24 -0600 (MDT)
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
Message-ID: <Pine.LNX.4.61.0606031715100.10890@www>


The attached patch allows baud rates of 14400, 28800, 128000 and 256000.

That was my goal.

[import standard disclaimer]

But I took some time to look a little further.  I got custom baud rates 
working enough that someone (perhaps me) can properly fix them in the 
future.  Proof of concept.

As an undocumented bonus, you can toss random baudrates (say 1953), at the 
API and it will set it to something close to that on windows and linux. 
Solaris should say the baud rate is not supported but I have not tested it 
yet.  Mac OS X behavior is unknown at this point.  Just dont expect 
correct behavior at ~8192-9009 baudrates or baudrates less than 20 on 
windows; these baud rates overlap with defines in win32termios.h.  I 
conveniently closed my eyes there.  Try another value close.  On Linux, a 
baud base and divisor are guestimated and set.  On windows, we wave pixie 
dust over the kernel driver and hope.  Do not expect pixie dust and 
guestimates to be the same on windows and linux.  They may well round to 
different values in yet to be tested ways.  There are only so many 
divisors.  If it isn't working, try a little higher or lower.

In the example of 1953 for instance, there is no divisor for commodity 
hardware that comes to that baudrate.  We just come close on one side or 
the other.  If tools tell you they got 1953 exactly, the tools may be 
questionable and just reading values not directly related to the actual 
hardware settings.

These fixes have been tested on Linux and Windows while using an 
oscilloscope to confirm they change relative to known baudrates at 9600, 
14400*, 19200, 28800* (and 1800, 1953** and 2400).

* = previously unsupported.
** = still not supported but probably works from what I saw.

There could be future discussion in this area.  For now this is working 
for almost all unusual baud rate demands.  Cleaning up the custom baud 
rate should be easier with a working starting point.  Baud bases other 
than 128000 have not been characterized.  Yes.. this overlapps with two of 
the baud rates enabled.

Feedback and ideas are welcome.

--
Trent Jarvi
tjarvi at qbang.org
-------------- next part --------------
Index: SerialImp.c
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v
retrieving revision 1.46.2.187
diff -u -r1.46.2.187 SerialImp.c
--- SerialImp.c	29 Jan 2006 22:19:04 -0000	1.46.2.187
+++ SerialImp.c	3 Jun 2006 23:12:40 -0000
@@ -793,6 +793,19 @@
 		result &= ~TIOCM_DTR;
 		ioctl( fd, TIOCMSET, &result );
 	}
+	/*
+	   B38400 is a special case in Linux for custom baud rates.
+
+	   We just treat this as a custom speed for now.  If you take this ifdef
+	   out and select baud rates 38400 then 28800 then 38400, you will get
+	   a final baud rate of 28800 because you did not update the divisor.
+
+	   See the next ifdef below for the divisor.
+	*/
+#if defined(TIOCGSERIAL)
+	if ( cspeed == B38400 )
+		cspeed = 38400;
+#endif /* TIOCGSERIAL */
 	if(     cfsetispeed( &ttyset, cspeed ) < 0 ||
 		cfsetospeed( &ttyset, cspeed ) < 0 )
 	{
@@ -814,6 +827,7 @@
 		*/
 
 #if defined(TIOCGSERIAL)
+		ioctl( fd, TIOCGSERIAL, &sstruct );
 		sstruct.custom_divisor = ( sstruct.baud_base/cspeed );
 		cspeed = B38400;
 #endif /* TIOCGSERIAL */
@@ -827,7 +841,7 @@
 #if defined(TIOCSSERIAL)
 		/*  It is assumed Win32 does this for us */
 		if (	sstruct.baud_base < 1 ||
-			ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
+		ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
 		{
 			return( 1 );
 		}
Index: termios.c
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v
retrieving revision 1.9.2.56
diff -u -r1.9.2.56 termios.c
--- termios.c	16 Jan 2006 02:50:32 -0000	1.9.2.56
+++ termios.c	3 Jun 2006 23:12:40 -0000
@@ -323,8 +323,8 @@
 		case CBR_3500000:	return( B3500000 );
 		case CBR_4000000:	return( B4000000 );
 		default:
-			set_errno(EINVAL );
-			return -1;
+			/* assume custom baudrate */
+			return( Baud );
 	}
 }
 
@@ -361,12 +361,13 @@
 		case B9600:	ret = CBR_9600;		break;
 		case B14400:	ret = CBR_14400;	break;
 		case B19200:	ret = CBR_19200;	break;
+		case B28800:	ret = CBR_28800;	break;
 		case B38400:	ret = CBR_38400;	break;
 		case B57600:	ret = CBR_57600;	break;
 		case B115200:	ret = CBR_115200;	break;
 		case B128000:	ret = CBR_128000;	break;
-		case B256000: 	ret = CBR_256000;	break;
 		case B230400:	ret = CBR_230400;	break;
+		case B256000: 	ret = CBR_256000;	break;
 		case B460800:	ret = CBR_460800;	break;
 		case B500000:	ret = CBR_500000;	break;
 		case B576000:	ret = CBR_576000;	break;
@@ -381,10 +382,8 @@
 		case B4000000:	ret = CBR_4000000;	break;
 	
 		default:
-			fprintf( stderr, "B_to_CBR: invalid baudrate: %#o\n",
-				Baud );
-			set_errno( EINVAL );
-			return -1;
+			/* assume custom baudrate */
+			return Baud;
 	}
 	LEAVE( "B_to_CBR" );
 	return ret;
@@ -708,12 +707,9 @@
 	ENTER( "init_serial_struct" );
 
 	/*
-	FIXME
-
-	This needs to use inb() to read the actual baud_base
-	and divisor from the UART registers.  Question is how
-	far do we take this?
-
+	use of custom_divisor and baud_base requires access to
+	kernel space.  The kernel does try its best if you just
+	toss a baud rate at it though.
 	*/
 
 	sstruct->custom_divisor = 0;
@@ -1678,16 +1674,17 @@
 {
 	char message[80];
 	ENTER( "cfsetospeed" );
+	/* clear baudrate */
+	s_termios->c_cflag &= ~CBAUD;
 	if ( speed & ~CBAUD )
 	{
 		sprintf( message, "cfsetospeed: not speed: %#o\n", speed );
 		report( message );
-		return 0;
+		/* continue assuming its a custom baudrate */
+		s_termios->c_cflag |= B38400;  /* use 38400 during custom */
+		s_termios->c_cflag |= CBAUDEX; /* use CBAUDEX for custom */
 	}
-	s_termios->c_ispeed = s_termios->c_ospeed = speed;
-	/* clear baudrate */
-	s_termios->c_cflag &= ~CBAUD;
-	if( speed )
+	else if( speed )
 	{
 		s_termios->c_cflag |= speed;
 	}
@@ -1696,6 +1693,7 @@
 		/* PC blows up with speed 0 handled in Java */
 		s_termios->c_cflag |= B9600;
 	}
+	s_termios->c_ispeed = s_termios->c_ospeed = speed;
 	LEAVE( "cfsetospeed" );
 	return 1;
 }
@@ -1767,25 +1765,6 @@
 }
 
 /*----------------------------------------------------------
-serial_struct_to_DCB()
-
-   accept:      
-   perform:     
-   return:      
-   exceptions:  
-   win32api:     None
-   comments:    
-----------------------------------------------------------*/
-int serial_struct_to_DCB( struct serial_struct *sstruct, DCB *dcb )
-{
-	/* 5 Baud rate fix
-	sstruct.baud_base
-	sstruct.custom_divisor = ( sstruct.baud_base/cspeed );
-	*/
-	return(0);
-}
-
-/*----------------------------------------------------------
 termios_to_DCB()
 
    accept:      
@@ -1798,7 +1777,8 @@
 int termios_to_DCB( struct termios *s_termios, DCB *dcb )
 {
 	ENTER( "termios_to_DCB" );
-	s_termios->c_ispeed = s_termios->c_ospeed = s_termios->c_cflag & CBAUD;
+	if ( !(s_termios->c_cflag & CBAUDEX) )
+		s_termios->c_ispeed = s_termios->c_ospeed = s_termios->c_cflag & CBAUD;
 	dcb->BaudRate        = B_to_CBR( s_termios->c_ispeed );
 	dcb->ByteSize = termios_to_bytesize( s_termios->c_cflag );
 
@@ -2863,11 +2843,6 @@
 			GetCommState( index->hComm, dcb );
 
 			index->sstruct = va_arg( ap, struct serial_struct * );
-			if ( serial_struct_to_DCB( index->sstruct, dcb ) < 0 )
-			{
-				va_end( ap );
-				return -1;
-			}
 
 			report( "TIOCSSERIAL\n" );
 			free(dcb);
Index: win32termios.h
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v
retrieving revision 1.5.2.28
diff -u -r1.5.2.28 win32termios.h
--- win32termios.h	30 Jun 2005 20:23:26 -0000	1.5.2.28
+++ win32termios.h	3 Jun 2006 23:12:40 -0000
@@ -279,7 +279,7 @@
 #define XTABS	01000000 /* Hmm.. Linux/i386 considers this part of TABDLY.. */
 
 /* c_cflag bit meaning */
-# define CBAUD	0010017
+#define  CBAUD  0030017
 #define  B0	0000000		/* hang up */
 #define  B50	0000001
 #define  B75	0000002
@@ -312,13 +312,16 @@
 #define  B3500000 0010016
 #define  B4000000 0010017
 
-/* glue for unsupported linux speeds see also SerialImp.h */
-/* hosed */
-
-#define B14400		1010001
-#define B28800		1010002
-#define B128000		1010003
-#define B256000		1010004
+/*
+	glue for unsupported linux speeds see also SerialImp.h 
+	custom baud rates around 8192-9000 will not work because
+	of these.
+*/
+
+#define B14400		0020001
+#define B28800		0020002
+#define B128000		0020003
+#define B256000		0020004
 
 #define EXTA B19200
 #define EXTB B38400
@@ -356,8 +359,10 @@
 
 /* glue for unsupported windows speeds */
 
-#define CBR_230400	230400
 #define CBR_28800	28800
+#define CBR_128000	128000
+#define CBR_230400	230400
+#define CBR_256000	256000
 #define CBR_460800	460800
 #define CBR_500000	500000
 #define CBR_576000	576000

From impakt01 at optusnet.com.au  Sat Jun  3 18:30:37 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 10:30:37 +1000
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
In-Reply-To: <Pine.LNX.4.61.0606031715100.10890@www>
Message-ID: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>

Hi Trent,
I'd love to try the patch but I can't get the latest build compiling, only
pre16. 

Can you attach the rxtxSerial.dll file with this patch?

Also, I hardcoded 1953 in a couple more places last night on pre16 and it
managed to open the port at the right speed, but stopped receiving anything
after 100-150 bytes, even though more data was getting sent to the port.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 10:15 AM
To: rxtx at qbang.org
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.


The attached patch allows baud rates of 14400, 28800, 128000 and 256000.

That was my goal.

[import standard disclaimer]

But I took some time to look a little further.  I got custom baud rates 
working enough that someone (perhaps me) can properly fix them in the 
future.  Proof of concept.

As an undocumented bonus, you can toss random baudrates (say 1953), at the 
API and it will set it to something close to that on windows and linux. 
Solaris should say the baud rate is not supported but I have not tested it 
yet.  Mac OS X behavior is unknown at this point.  Just dont expect 
correct behavior at ~8192-9009 baudrates or baudrates less than 20 on 
windows; these baud rates overlap with defines in win32termios.h.  I 
conveniently closed my eyes there.  Try another value close.  On Linux, a 
baud base and divisor are guestimated and set.  On windows, we wave pixie 
dust over the kernel driver and hope.  Do not expect pixie dust and 
guestimates to be the same on windows and linux.  They may well round to 
different values in yet to be tested ways.  There are only so many 
divisors.  If it isn't working, try a little higher or lower.

In the example of 1953 for instance, there is no divisor for commodity 
hardware that comes to that baudrate.  We just come close on one side or 
the other.  If tools tell you they got 1953 exactly, the tools may be 
questionable and just reading values not directly related to the actual 
hardware settings.

These fixes have been tested on Linux and Windows while using an 
oscilloscope to confirm they change relative to known baudrates at 9600, 
14400*, 19200, 28800* (and 1800, 1953** and 2400).

* = previously unsupported.
** = still not supported but probably works from what I saw.

There could be future discussion in this area.  For now this is working 
for almost all unusual baud rate demands.  Cleaning up the custom baud 
rate should be easier with a working starting point.  Baud bases other 
than 128000 have not been characterized.  Yes.. this overlapps with two of 
the baud rates enabled.

Feedback and ideas are welcome.

--
Trent Jarvi
tjarvi at qbang.org



From tjarvi at qbang.org  Sat Jun  3 19:05:11 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 19:05:11 -0600 (MDT)
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
In-Reply-To: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>
References: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606031840400.10890@www>

On Sun, 4 Jun 2006, Daren wrote:

> Hi Trent,
> I'd love to try the patch but I can't get the latest build compiling, only
> pre16.
>
> Can you attach the rxtxSerial.dll file with this patch?
>
> Also, I hardcoded 1953 in a couple more places last night on pre16 and it
> managed to open the port at the right speed, but stopped receiving anything
> after 100-150 bytes, even though more data was getting sent to the port.
>


ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing

I dont think they will hang.  But I was just testing via loopback/break 
out box/scope.

I'll be putting about 10 patches and another set of binaries in that 
directory shortly.  For now the binaries should just have the baud_rate 
fix.

I'll announce all the patches at once.  but wont be releasing 2.1-8 right 
away.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Sat Jun  3 21:00:01 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 21:00:01 -0600 (MDT)
Subject: [Rxtx] CVS for 2.1 should have everything
Message-ID: <Pine.LNX.4.61.0606032056190.10890@www>


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org


From impakt01 at optusnet.com.au  Sat Jun  3 21:08:14 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 13:08:14 +1000
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <Pine.LNX.4.61.0606032056190.10890@www>
Message-ID: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>

Hi Trent,
I tried the latest dll and it opens the port, receives 100-200 bytes and
then stops receiving anything else..

I'll keep playing with it.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 1:00 PM
To: rxtx at qbang.org
Subject: [Rxtx] CVS for 2.1 should have everything


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From impakt01 at optusnet.com.au  Sat Jun  3 21:22:41 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 13:22:41 +1000
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
Message-ID: <200606040322.k543MqW1008455@mail12.syd.optusnet.com.au>

Played with it, problem, with a while loop in my code, working great now

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Daren
Sent: Sunday, 4 June 2006 1:08 PM
To: 'RXTX Developers and Users'
Subject: Re: [Rxtx] CVS for 2.1 should have everything

Hi Trent,
I tried the latest dll and it opens the port, receives 100-200 bytes and
then stops receiving anything else..

I'll keep playing with it.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 1:00 PM
To: rxtx at qbang.org
Subject: [Rxtx] CVS for 2.1 should have everything


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Sat Jun  3 21:35:41 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 21:35:41 -0600 (MDT)
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
References: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606032131140.10890@www>

On Sun, 4 Jun 2006, Daren wrote:

> Hi Trent,
> I tried the latest dll and it opens the port, receives 100-200 bytes and
> then stops receiving anything else..
>
> I'll keep playing with it.
>
> Daren

The difference may be that I'm talking to something at the exact same baud 
rate (loopback).

You may also try setting the baudrate to ~1933 and ~1973 to force the 
guesses one way or the other.  If you are on windows, we are not doing 
anything fancy in the end.  Thats the kernel guessing.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sun Jun  4 04:12:09 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sun, 4 Jun 2006 12:12:09 +0200
Subject: [Rxtx] Update of OSX installer, Readme, etc
Message-ID: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>

Good day,

after the latest changes a lot of OS X specific files should be  
updated. Especially the installer!

- The "MaxOSX" readme file on the root level is outdated (ie  
CodeWarrior information). Maybe we could even rename it to README.OSX  
to be in line with README.IPAQ, README.SCO (Trent do you mind copying/ 
renaming ,v files in the repository?).

- The lock files are no longer used and hence the user group magic  
and lock folder creation should be removed from the installer.

- MACOSX_IDE/ForPackageMaker/Resources/ReadMe.rtf and Welcome.rtf  
need to be updated.

- I suggest to replace the current installation instruction for OS X:  
Installation should occur into the application directory, not in the  
Java-VM directory. This simplifies things a lot, as the Mac Installer  
can be removed completely.

- The xcodeproject's build settings need to be updated to generate  
JAVA 1.1 format class files.


Dimitry: do you have time to tackle this? I could do it, but as this  
is "your baby" I thought you may prefer to do it yourself.

Regards,
Joachim



From dmarkman at mac.com  Sun Jun  4 11:27:53 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Sun, 4 Jun 2006 13:27:53 -0400
Subject: [Rxtx] Update of OSX installer, Readme, etc
In-Reply-To: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
References: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
Message-ID: <26E7A202-962B-4C19-93B6-29426C467249@mac.com>

Joachim,
unfortunately I don't have time right now to do that
so if you can do that, please do

it's not only my baby
it's yours too :-)

thanks


On Jun 4, 2006, at 6:12 AM, Joachim Buechse wrote:

> Good day,
>
> after the latest changes a lot of OS X specific files should be
> updated. Especially the installer!
>
> - The "MaxOSX" readme file on the root level is outdated (ie
> CodeWarrior information). Maybe we could even rename it to README.OSX
> to be in line with README.IPAQ, README.SCO (Trent do you mind copying/
> renaming ,v files in the repository?).
>
> - The lock files are no longer used and hence the user group magic
> and lock folder creation should be removed from the installer.
>
> - MACOSX_IDE/ForPackageMaker/Resources/ReadMe.rtf and Welcome.rtf
> need to be updated.
>
> - I suggest to replace the current installation instruction for OS X:
> Installation should occur into the application directory, not in the
> Java-VM directory. This simplifies things a lot, as the Mac Installer
> can be removed completely.
>
> - The xcodeproject's build settings need to be updated to generate
> JAVA 1.1 format class files.
>
>
> Dimitry: do you have time to tackle this? I could do it, but as this
> is "your baby" I thought you may prefer to do it yourself.
>
> Regards,
> Joachim
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman



From tjarvi at qbang.org  Sun Jun  4 13:54:02 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 4 Jun 2006 13:54:02 -0600 (MDT)
Subject: [Rxtx] Update of OSX installer, Readme, etc
In-Reply-To: <26E7A202-962B-4C19-93B6-29426C467249@mac.com>
References: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
	<26E7A202-962B-4C19-93B6-29426C467249@mac.com>
Message-ID: <Pine.LNX.4.61.0606041353040.22522@www>

On Sun, 4 Jun 2006, Dmitry Markman wrote:

> Joachim,
> unfortunately I don't have time right now to do that
> so if you can do that, please do
>
> it's not only my baby
> it's yours too :-)
>

I've given Joachim cvs access.  He has shown good work in bugzilla.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Mon Jun  5 10:08:32 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 5 Jun 2006 18:08:32 +0200
Subject: [Rxtx] Build process changes for Mac OS X
Message-ID: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>

Good day,

I have cleaned up some outdated Mac OSX specific build files in the  
repository.

There was not a lot left of the readme file "MacOSX" after cleaning  
it up, so I decided to rename it README.OSX to be in harmony with the  
other files in the directory (ie README.IPAQ, README.SCO, ...)

I added an (uncompressed) XCode 2.3 project file/structure  
with .cvsignore files that will ignore the user specific settings.  
This should work "out of the box" for OSX10.4. Users of 10.2/10.3 may  
have to switch the build settings.

[It's kind of tricky to choose "the right" setting. Afaik there is no  
way to compile a universal binary that will work on 10.3 or before.  
So it's either UniversalBinary OR Legacy. Maybe we should have  
different build targets for these different targets?? I would like to  
get some feedback from the Mac developers on this list regarding the  
subject].

Besides other things the OSX installer is no longer required. Since  
the next version (2.1.8) will no longer use lockfiles on OSX, the  
group/permission magic is no longer required and hence there remains  
basicly no work for the installer - other than copying 2 files to the  
VM extension directory. Then again, this is not the best way to  
install RXTX. So I removed the installer completely without modifying  
it, this should simplify a "resurrection" should it ever get necessary.

I had problems with the (compressed, ie sit.hqx) legacy project files  
on the latest installation of OSX (javac 1.5 creating non JDK1.1  
class files and some minor problems). To reduce potential confusion  
for newcomers I decided to remove them. This means that there is no  
longer a simple way to build RXTX for OSX 10.0 and 10.1 (I deeply  
apologize if anyone still relied on this ... well the files are in  
the Attiq).

Best regards,
Joachim


From joachim at buechse.de  Mon Jun  5 10:16:37 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 5 Jun 2006 18:16:37 +0200
Subject: [Rxtx] RXTX and lockfiles on OSX [it is fixed now]
Message-ID: <7D2C4418-9397-4B59-8091-9FDE4ED67836@buechse.de>

Quite a number of people contacted me in the last couple of weeks  
because of problems installing RXTX on OSX. I told you to wait for  
the "official" fix. Well, it has been fixed.

So if you were among the people waiting for the solution, you can now  
download the source rxtx-2.1-7r2.zip from the website. Once unpacked  
dont forget to use "cvs up" to update the files to the latest  
version. You can then open MACOSX_IDE/XCode/ 
LibSerialUniversal.xcodeproj with XCode 2.3 and build the libraries  
that no longer try to create lock files.

Regards,
Joachim


From brian at mbari.org  Mon Jun  5 10:52:43 2006
From: brian at mbari.org (Brian Schlining)
Date: Mon, 5 Jun 2006 09:52:43 -0700
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
Message-ID: <78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>

Hi Joachim,

> [It's kind of tricky to choose "the right" setting. Afaik there is no
> way to compile a universal binary that will work on 10.3 or before.
> So it's either UniversalBinary OR Legacy. Maybe we should have
> different build targets for these different targets?? I would like to
> get some feedback from the Mac developers on this list regarding the
> subject].

I imagine most developers will be compiling on 10.4 (It's the nature  
of the coder...gotta have the latest and greatest) and deploying to  
both 10.3 and 10.4; both of which will run Universal Binaries (see  
http://forums.macrumors.com/showthread.php?t=205348). So it sounds  
like you've covered the majority of users. Still, you know someone's  
going to pipe up about needing RXTX on 10.2 so it would be nice to  
have a target to make a PPC only build.

Just my 2 cents

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/1cac8c39/attachment-0021.html

From dmarkman at mac.com  Mon Jun  5 13:47:50 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Mon, 5 Jun 2006 15:47:50 -0400
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
Message-ID: <686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>

I don't think it will be a problem to run universal binary
on 10.2
however if binary has some calls that aren't implemented in 10.2
then you'll have a problem


On Jun 5, 2006, at 12:52 PM, Brian Schlining wrote:

> Hi Joachim,
>
>> [It's kind of tricky to choose "the right" setting. Afaik there is no
>> way to compile a universal binary that will work on 10.3 or before.
>> So it's either UniversalBinary OR Legacy. Maybe we should have
>> different build targets for these different targets?? I would like to
>> get some feedback from the Mac developers on this list regarding the
>> subject].
>
> I imagine most developers will be compiling on 10.4 (It's the  
> nature of the coder...gotta have the latest and greatest) and  
> deploying to both 10.3 and 10.4; both of which will run Universal  
> Binaries (see http://forums.macrumors.com/showthread.php?t=205348).  
> So it sounds like you've covered the majority of users. Still, you  
> know someone's going to pipe up about needing RXTX on 10.2 so it  
> would be nice to have a target to make a PPC only build.
>
> Just my 2 cents
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/9fafc878/attachment-0021.html

From brian at mbari.org  Mon Jun  5 14:52:41 2006
From: brian at mbari.org (Brian Schlining)
Date: Mon, 5 Jun 2006 13:52:41 -0700
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
Message-ID: <E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>

Hi Dmitry,

> I don't think it will be a problem to run universal binary
> on 10.2
> however if binary has some calls that aren't implemented in 10.2
> then you'll have a problem

You're right...I stand corrected.

Note however, to deploy a universal binary to 10.2 RXTX will need to  
use the 10.2 SDK to build the PPC side. (see http:// 
developer.apple.com/documentation/DeveloperTools/Conceptual/ 
cross_development/UniversalBinaries/chapter_4_section_1.html). I  
haven't been paying close attention to the new locking mechanism used  
by RXTX on the Mac...does 10.2 support it?

Joachim, which SDK will you be using by default for building the Mac  
PPC binaries?

>> Hi Joachim,
>>
>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>> is no
>>> way to compile a universal binary that will work on 10.3 or before.
>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>> different build targets for these different targets?? I would  
>>> like to
>>> get some feedback from the Mac developers on this list regarding the
>>> subject].
>>
>> I imagine most developers will be compiling on 10.4 (It's the  
>> nature of the coder...gotta have the latest and greatest) and  
>> deploying to both 10.3 and 10.4; both of which will run Universal  
>> Binaries (see http://forums.macrumors.com/showthread.php? 
>> t=205348). So it sounds like you've covered the majority of users.  
>> Still, you know someone's going to pipe up about needing RXTX on  
>> 10.2 so it would be nice to have a target to make a PPC only build.

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/153bf50e/attachment-0021.html

From dmarkman at mac.com  Mon Jun  5 19:02:04 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Mon, 5 Jun 2006 21:02:04 -0400
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
Message-ID: <7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>

if Joachim didn't change xcode project setting

/Developer/SDKs/MacOSX10.4u.sdk is used to build universal binary

so it's quite possible that it won't run properly on 10.2

so we have to change the building process, so ppc part will be built
with
/Developer/SDKs/MacOSX10.2.8.sdk

and finally to use lipo utility to build universal binaries

Joachim, did you use some specific locking API that wasn't implemented

in MacOSX10.2.8.sdk?

thanks


On Jun 5, 2006, at 4:52 PM, Brian Schlining wrote:

> Hi Dmitry,
>
>> I don't think it will be a problem to run universal binary
>> on 10.2
>> however if binary has some calls that aren't implemented in 10.2
>> then you'll have a problem
>
> You're right...I stand corrected.
>
> Note however, to deploy a universal binary to 10.2 RXTX will need  
> to use the 10.2 SDK to build the PPC side. (see http:// 
> developer.apple.com/documentation/DeveloperTools/Conceptual/ 
> cross_development/UniversalBinaries/chapter_4_section_1.html). I  
> haven't been paying close attention to the new locking mechanism  
> used by RXTX on the Mac...does 10.2 support it?
>
> Joachim, which SDK will you be using by default for building the  
> Mac PPC binaries?
>
>>> Hi Joachim,
>>>
>>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>>> is no
>>>> way to compile a universal binary that will work on 10.3 or before.
>>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>>> different build targets for these different targets?? I would  
>>>> like to
>>>> get some feedback from the Mac developers on this list regarding  
>>>> the
>>>> subject].
>>>
>>> I imagine most developers will be compiling on 10.4 (It's the  
>>> nature of the coder...gotta have the latest and greatest) and  
>>> deploying to both 10.3 and 10.4; both of which will run Universal  
>>> Binaries (see http://forums.macrumors.com/showthread.php? 
>>> t=205348). So it sounds like you've covered the majority of  
>>> users. Still, you know someone's going to pipe up about needing  
>>> RXTX on 10.2 so it would be nice to have a target to make a PPC  
>>> only build.
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/84790f80/attachment-0021.html

From joachim at buechse.de  Tue Jun  6 02:40:47 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 6 Jun 2006 10:40:47 +0200
Subject: [Rxtx] Building on OS X, Impl Changes
In-Reply-To: <7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
Message-ID: <CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>

Good day!

What's in the XCode project setting?
----------

The xcode project remained pretty much the same as before. I excluded  
the user specific files from CVS and changed some settings. I kept  
all the built targets (you shouldn't change what you don't understand;-)

Currently we the following build targets:
    RXTXComm (java files)
    librxtxParallel.jnilib (usefull on the Mac???)
    libI2C.jnilib (not yet working in RXTX)
    libRS485.jnilib (not yet working in RXTX)
    librxtxSerial.jnilib (1)
    librxtxSerial.jnilib Dynamic (2)
    rxtxSerial (3)
We also have the following build configurations for each target:
    Development
    Default
    Deployment

What was changed in the xcode project from previous versions:
- java.souce=1.3 and java.target=1.1 in RXTXComm settings
- removed copying of build products into installer directory
- removed "(Upgraded)" from build target names

What remains to be changed:
- choosing a "non-debug" Build-configuration as default
- potentially removing "Default"/"Development" Build-configurations
- reducing the number of build targets
- creating 10.2 compatible universal binaries

I suggest, that the build configurations should be reduced to 2  
(Debug/Deployment), possibly even 1 (Debug).
I have not yet found the deeper meaning of the build targets(1)(2) 
(3), it seems to me like they should be reduced into one "doing the  
right thing" or maybe into two "rxtxSerial.jnilib Legacy" (back to  
10.2, universal if possible) and "rxtxSerial.jnilib 10.4 
+" (universal, 10.4+).

Should the code work on 10.2?
----------

Absolutely. The code should work on NextStep, in fact on any BSD  
unix. I would go as far as saying, this code should work on any  
POSSIX based unix. All that was added is the call "ioctl(fd,  
TIOCEXCL)" to request excusivity of the port:

http://gemma.apple.com/documentation/DeviceDrivers/Conceptual/ 
WorkingWSerial/WWSerial_SerialDevs/chapter_2_section_8.html

It is not yet "the perfect solution". Normally an open /dev/tty  
(listen for incomming connection) should be "preemptable" by opening  
a /dev/cu (outgoing connection) for the same port. This is not yet  
implemented as it needs calls outside of POSSIX on OSX.

On "classic" systems (like NextStep) this worked based on the  
"carried detect line". open() on /dev/tty.xxx would block until the  
carrier detect signal was raised. As the device was not "opened"  
opening /dev/cu.xxx worked without a hitch. When they ported to the  
Mac this broke. On Macs the "carier detect" is usually not wired.  
Furthermore FAX modems did no longer raise the line. So the OSX  
implementor defined a new call, which is documented here:

http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00045.html

Best regards,
Joachim




On 06.06.2006, at 03:02, Dmitry Markman wrote:

> if Joachim didn't change xcode project setting
>
> /Developer/SDKs/MacOSX10.4u.sdk is used to build universal binary
>
> so it's quite possible that it won't run properly on 10.2
>
> so we have to change the building process, so ppc part will be built
> with
> /Developer/SDKs/MacOSX10.2.8.sdk
>
> and finally to use lipo utility to build universal binaries
>
> Joachim, did you use some specific locking API that wasn't implemented
>
> in MacOSX10.2.8.sdk?
>
> thanks
>
>
> On Jun 5, 2006, at 4:52 PM, Brian Schlining wrote:
>
>> Hi Dmitry,
>>
>>> I don't think it will be a problem to run universal binary
>>> on 10.2
>>> however if binary has some calls that aren't implemented in 10.2
>>> then you'll have a problem
>>
>> You're right...I stand corrected.
>>
>> Note however, to deploy a universal binary to 10.2 RXTX will need  
>> to use the 10.2 SDK to build the PPC side. (see http:// 
>> developer.apple.com/documentation/DeveloperTools/Conceptual/ 
>> cross_development/UniversalBinaries/chapter_4_section_1.html). I  
>> haven't been paying close attention to the new locking mechanism  
>> used by RXTX on the Mac...does 10.2 support it?
>>
>> Joachim, which SDK will you be using by default for building the  
>> Mac PPC binaries?
>>
>>>> Hi Joachim,
>>>>
>>>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>>>> is no
>>>>> way to compile a universal binary that will work on 10.3 or  
>>>>> before.
>>>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>>>> different build targets for these different targets?? I would  
>>>>> like to
>>>>> get some feedback from the Mac developers on this list  
>>>>> regarding the
>>>>> subject].
>>>>
>>>> I imagine most developers will be compiling on 10.4 (It's the  
>>>> nature of the coder...gotta have the latest and greatest) and  
>>>> deploying to both 10.3 and 10.4; both of which will run  
>>>> Universal Binaries (see http://forums.macrumors.com/ 
>>>> showthread.php?t=205348). So it sounds like you've covered the  
>>>> majority of users. Still, you know someone's going to pipe up  
>>>> about needing RXTX on 10.2 so it would be nice to have a target  
>>>> to make a PPC only build.
>>
>> Brian Schlining
>> Software Engineer
>> http://www.mbari.org
>>
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> Dmitry Markman
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Tue Jun  6 07:01:06 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 6 Jun 2006 15:01:06 +0200
Subject: [Rxtx] Serial port code for OS X, future steps
In-Reply-To: <CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
	<CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
Message-ID: <8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>

I posted the "wrong link". There is a correction here:

    http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00059.html

In fact, the 2.1.7 implementation of RXTX has quite some deficiencies  
on OSX. I have tried to supply some patches that don't interfere to  
much with the existing RXTX code base, but there are limits to what  
can be done with local patches.

There are some very intrusive changes that should be done. Ie proper  
mapping of /dev/tty <-> /dev/cu handling to correct behaviour of  
CommPortOwnershipListener (http://java.sun.com/products/javacomm/ 
reference/api/index.html). I dont think this can be done with  
patches. Hence I think, RXTX should be rewritten from scratch de- 
unifying the native code base (and implementing thread safe code on  
the Java side).


How "should" /dev/tty vs /dev/cu be implemented?

=====
The Unix contract is this: An open /dev/tty.xxx port (incomming)  
should be interrupted/auto-closed when opening /dev/cu.xxx (outgoing)  
[if /dev/tty.xxx is not currently handling a communication].  /dev/ 
cu.xxx and /dev/tty.xxx refer to the same device, so owning  
"exclusively" should block both. This should be respected across all  
applications native or Java.

This contract is realizable on OSX with the existing javax.comm  
interface while also respecting (to the biggest part) the contract  
defined by javax.comm.PortOwnershipListener.

The one point where the suggested implementation "breaks" the  
javax.comm contract, is by the fact that one can loose a /dev/tty  
port without calling close. However, the only option I see is to  
always open serial ports "non-exclusively" which would outrule Java  
as a platform for (dormant) applications waiting for incoming  
connections/faxes/etc. There could be a system property to choose the  
intended behavior.
=====

Here is how it could be done on OSX:

Calling port=ComportIdentifier.open("/dev/cu.xxx") opens and owns the  
port exclusively until port.close() is called.
- Java applications listening with a PortOwnershipListener should get  
a PORT_OWNED event reasonably soon.
- Any further attempt by a Java or native application to open "/dev/ 
cu.xxx" or "/dev/tty.xxx" fails.
- /dev/cu.xxx is for "outgoing" connections, so receiving  
PORT_OWNERSHIP_REQUESTED makes little to no sense. With native  
applications it can not be implemented. For Java applications it  
could be implemented (by a hidden communication channel). I think  
it's not worth bothering. If anyone is willing to give up a port to  
others he should use /dev/tty.xxx instead of /dev/cu.xxx.

Registering a PortOwnershipListener on "/dev/cu.xxx" without opening  
it, uses /dev/tty.xxx (native open()) non-exclusively and polls its  
state. PORT_OWNED and PORT_UNOWNED can be produced.

Calling port=ComportIdentifier.open("/dev/tty.xxx") should open the  
port non-exclusively.
- Adding a SerialPortEventListener and reading from the port could be  
allowed while keeping it non-exclusive.
- When port.getOutputStream() is called, the state should be changed  
to an "exclusive" ownership. This may be configurable via a system  
property.
- To return to the non-exclusive state the port must be closed and  
reopened.
- While non-exclusively opened, opening the corresponding /dev/cu.xxx  
produces a PORT_OWNERSHIP_REQUESTED event. Which should be responded  
by closing the port from within the callback (as described in  
java.comm.PortOwnershipListener). If there is a pending read, it will  
return after the listener finishes (with -1 or "0 bytes read").
- Calling write() on the /dev/tty.xxx after somebody opened /dev/ 
cu.xxx will fail with a descriptive IOException.
- Calling read() on the /dev/tty.xxx after somebody opened /dev/ 
cu.xxx will fail with a descriptive IOException (or potentially  
block, see side notes below).

CommPortIdentifier.getCurrentOwner() can be implemented by an  
external call to lsof.

CommPortIdentifier.isCurrentlyOwned() can be implemented by trying an  
open on the /dev/tty.
- It returns true if the port is currently held "exclusively".
- Whether it should also return true on /dev/tty if /dev/tty is  
already opened non-exclusively might be a system property option. In  
general, having several applications waiting for incoming connections  
on the same port will require an application level "arbitration"  
protocol...

[[side note1: One interesting question is, what happens if the  
process holding /dev/tty non-exclusively ignores  
PORT_OWNERSHIP_REQUESTED. Ie after "loosing" a non-exclusively opened  
"dev/tty.xxx" port to another process. One possible implementation  
is, that the port is "regained" when the other process gives up the  
port. This would mean that in the meanwhile read() returns no data,  
and any changes to the configuration of the port are stored but not  
forwarded. I guess, the safe (and simple) way to do this is to make  
the close() mandatory (ie setting the port into an "awaiting_close"  
state which produces IOExceptions to any other call than close). ]]

[[side note2:  Another interesting question is, what should happen if  
several applications open the same /dev/tty.xxx port "non- 
exclusively" and start to change the settings of the device.]]

Regards,
Joachim



On 06.06.2006, at 10:40, Joachim Buechse wrote:

> Should the code work on 10.2?
> ----------
>
> Absolutely. The code should work on NextStep, in fact on any BSD
> unix. I would go as far as saying, this code should work on any
> POSSIX based unix. All that was added is the call "ioctl(fd,
> TIOCEXCL)" to request excusivity of the port:
>
> http://gemma.apple.com/documentation/DeviceDrivers/Conceptual/
> WorkingWSerial/WWSerial_SerialDevs/chapter_2_section_8.html
>
> It is not yet "the perfect solution". Normally an open /dev/tty
> (listen for incomming connection) should be "preemptable" by opening
> a /dev/cu (outgoing connection) for the same port. This is not yet
> implemented as it needs calls outside of POSSIX on OSX.
>
> On "classic" systems (like NextStep) this worked based on the
> "carried detect line". open() on /dev/tty.xxx would block until the
> carrier detect signal was raised. As the device was not "opened"
> opening /dev/cu.xxx worked without a hitch. When they ported to the
> Mac this broke. On Macs the "carier detect" is usually not wired.
> Furthermore FAX modems did no longer raise the line. So the OSX
> implementor defined a new call, which is documented here:
>
> http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00045.html
>
> Best regards,
> Joachim



From sds at dcs.gla.ac.uk  Tue Jun  6 11:22:45 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Tue, 06 Jun 2006 18:22:45 +0100
Subject: [Rxtx] Correct compile flag for HP iPAQ hx4700 running Familiar
	Linux?
Message-ID: <1149614565.19496.10.camel@addu>

Hi,

I'd like to use RXTX 2.1 on my HP iPAQ hx4700. The iPAQ is running
Familiar Linux 0.8.2 (as I recall), with Blackdown Java 1.3.1.

I can compile and run a test program which uses RXTX on my i686 machine,
and it works fine. But I can't seem to get things working quite right on
my PDA.

I compile the code on the laptop with the following commands:
	./configure --host=arm-gnu-linux && make
... as suggested in a post to this list, albeit some time ago. This
compiles, I transfer the files, set up LD_LIBRARY_PATH and CLASSPATH
variables, and get the following error on the PDA:

sds at ipaq-pxa-2:~# java Test
java.lang.UnsatisfiedLinkError: /usr/local/lib/ext/librxtxSerial.so: /usr/local/lib/ext/librxtxSerial.so: cannot open shared object file: No such file or directory thrown while loading gnu.io.RXTXCommDriver
Exception in thread "main"
java.lang.UnsatisfiedLinkError: /usr/local/lib/ext/librxtxSerial.so: /usr/local/lib/ext/librxtxSerial.so: cannot open shared object file: No such file or directory
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1382)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1290)
        at java.lang.Runtime.loadLibrary0(Runtime.java:749)
        at java.lang.System.loadLibrary(System.java:820)
        at
gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:83)
        at Test.<init>(Test.java:9)
        at Test.main(Test.java:32)
sds at ipaq-pxa-2:~# 

Note that I'm copying the files to /usr/local/lib/ext/ along with the
RXTXcomm.jar file, purely to keep things separate from the rest of the
system while testing. The location of the .so files doesn't seem to have
any bearing on whether "java Test" will succeed or not. The contents of
this directory are:

sds at ipaq-pxa-2:~$ ls /usr/local/lib/ext/
RXTXcomm.jar              librxtxParallel-2.1-7.so  librxtxRS485.so
librxtxSerial-2.1-7.so
librxtxI2C-2.1-7.so       librxtxParallel.so        librxtxRaw-2.1-7.so
librxtxSerial.so
librxtxI2C.so             librxtxRS485-2.1-7.so     librxtxRaw.so
sds at ipaq-pxa-2:~$

Test.java fails on the first real line of code I'm using to test that
things are working, prior to real development, and was carefully pinched
from the web:
Enumeration portIdentifiers = CommPortIdentifier.getPortIdentifiers();


I assume that I've gotten my --host flag wrong way back up there at
the ./configure step. But if that's the case, what should I set it to?
Or am I missing something more obvious?


Cheers,
Stephen Strowes,
University of Glasgow.




From tjarvi at qbang.org  Tue Jun  6 13:39:41 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 6 Jun 2006 13:39:41 -0600 (MDT)
Subject: [Rxtx] Serial port code for OS X, future steps
In-Reply-To: <8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
	<CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
	<8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>
Message-ID: <Pine.LNX.4.61.0606061315070.9856@www>


>>
There are some very intrusive changes that should be done. Ie proper
mapping of /dev/tty <-> /dev/cu handling to correct behaviour of
CommPortOwnershipListener (http://java.sun.com/products/javacomm/
reference/api/index.html). I dont think this can be done with
patches. Hence I think, RXTX should be rewritten from scratch de-
unifying the native code base (and implementing thread safe code on
the Java side).
<<

This appears to be a very small amount of functionality for a total 
rewrite.  The port ownership only needs maybe 3 native calls if it is done 
with native calls at all.

Those features which are not part of the Unix standard(s) can be special 
cased.  I'm not sure /dev/cu is standard.  We can look.  I know linux 
deprecated /dev/cua years ago.

Thread safe Java code is not a platform specific issue.

--
Trent Jarvi
tjarvi at qbang.org


From sds at dcs.gla.ac.uk  Wed Jun  7 12:36:43 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Wed, 07 Jun 2006 19:36:43 +0100
Subject: [Rxtx] Expected RXTX behaviour?
In-Reply-To: <1149703900.30891.19.camel@addu>
References: <1149703900.30891.19.camel@addu>
Message-ID: <1149705403.30891.25.camel@addu>

Apologies, caught the problem. Had to append '\r' to the end of the AT
string. A non obvious but stupid mistake... :-)

Final quick question though: How might I stop the echoing of
outputStream data back into the inputStream? I still see the ATI
commands on the inputStream, along with the output from the device.


Cheers,
S.



On Wed, 2006-06-07 at 19:11 +0100, Stephen Strowes wrote:
> Hi,
> 
> I managed to get RXTX to compile for my iPAQ following my previous post
> to this list. Quick query though:
> 
> I want to be able to issue AT commands to a device, and interpret the
> responses. For this, I assume I do the following, in psuedo-form:
> 
> 	CommPortIdentifier.getPortIdentifiers();
> 	// find the correct device id
> 	serialPort= (SerialPort)portID.open("Test");
> 	// Set parameters and flow control
> 	outputStream= serialPort.getOutputStream();
> 	inputStream=  serialPort.getInputStream();
> 
> ... following this, I spawn a thread to respond to DATA_AVAILABLE events
> on serialPort with inputStream, and occasionally write and flush an
> "ATI" onto the outputStream. Nothing complex, I just want to see it
> work.
> 
> I would have expected inputStream to give the same information back from
> an "ATI" command as minicom provides, but instead inputStream only sees
> the "ATI" I put onto the outputStream.
> 
> Have I missed something?
> 
> 
> Cheers,
> S.
> 



From sds at dcs.gla.ac.uk  Wed Jun  7 12:11:40 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Wed, 07 Jun 2006 19:11:40 +0100
Subject: [Rxtx] Expected RXTX behaviour?
Message-ID: <1149703900.30891.19.camel@addu>

Hi,

I managed to get RXTX to compile for my iPAQ following my previous post
to this list. Quick query though:

I want to be able to issue AT commands to a device, and interpret the
responses. For this, I assume I do the following, in psuedo-form:

	CommPortIdentifier.getPortIdentifiers();
	// find the correct device id
	serialPort= (SerialPort)portID.open("Test");
	// Set parameters and flow control
	outputStream= serialPort.getOutputStream();
	inputStream=  serialPort.getInputStream();

... following this, I spawn a thread to respond to DATA_AVAILABLE events
on serialPort with inputStream, and occasionally write and flush an
"ATI" onto the outputStream. Nothing complex, I just want to see it
work.

I would have expected inputStream to give the same information back from
an "ATI" command as minicom provides, but instead inputStream only sees
the "ATI" I put onto the outputStream.

Have I missed something?


Cheers,
S.




From joachim at buechse.de  Wed Jun  7 09:02:13 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 7 Jun 2006 17:02:13 +0200
Subject: [Rxtx] Update of build process for OSX (XCode project)
Message-ID: <62EC47B1-46BD-4ECA-B9EC-C4061D147CDA@buechse.de>

With the help of Dmitry Markman and Brian Schilling I have updated  
(and largely simplifed) the XCode project file for Mac OS X.

Changes:
- compiles a universal binary library with intel=OSX10.4+, ppc=OSX10.2 
+ support
- compiles the Java sources into a JRE1.1 compatible, compressed jar.

Please test on your configuration, especially if you have computers  
running 10.2/10.3 or intel.

Best regards,
Joachim


From joachim at buechse.de  Wed Jun  7 14:36:37 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 7 Jun 2006 22:36:37 +0200
Subject: [Rxtx] Expected RXTX behaviour?
In-Reply-To: <1149705403.30891.25.camel@addu>
References: <1149703900.30891.19.camel@addu> <1149705403.30891.25.camel@addu>
Message-ID: <D3AD6EAF-27BB-455E-9697-86C1121920C3@buechse.de>

Echoing is a feature of the modem. Try ATE0 which works with most  
"rockwell" compatible modems.

Regards,
Joachim


On 07.06.2006, at 20:36, Stephen Strowes wrote:

> Apologies, caught the problem. Had to append '\r' to the end of the AT
> string. A non obvious but stupid mistake... :-)
>
> Final quick question though: How might I stop the echoing of
> outputStream data back into the inputStream? I still see the ATI
> commands on the inputStream, along with the output from the device.
>
>
> Cheers,
> S.
>
>
>
> On Wed, 2006-06-07 at 19:11 +0100, Stephen Strowes wrote:
>> Hi,
>>
>> I managed to get RXTX to compile for my iPAQ following my previous  
>> post
>> to this list. Quick query though:
>>
>> I want to be able to issue AT commands to a device, and interpret the
>> responses. For this, I assume I do the following, in psuedo-form:
>>
>> 	CommPortIdentifier.getPortIdentifiers();
>> 	// find the correct device id
>> 	serialPort= (SerialPort)portID.open("Test");
>> 	// Set parameters and flow control
>> 	outputStream= serialPort.getOutputStream();
>> 	inputStream=  serialPort.getInputStream();
>>
>> ... following this, I spawn a thread to respond to DATA_AVAILABLE  
>> events
>> on serialPort with inputStream, and occasionally write and flush an
>> "ATI" onto the outputStream. Nothing complex, I just want to see it
>> work.
>>
>> I would have expected inputStream to give the same information  
>> back from
>> an "ATI" command as minicom provides, but instead inputStream only  
>> sees
>> the "ATI" I put onto the outputStream.
>>
>> Have I missed something?
>>
>>
>> Cheers,
>> S.
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From g_petrini at yahoo.it  Thu Jun  8 01:41:58 2006
From: g_petrini at yahoo.it (Giacomo Petrini)
Date: Thu, 8 Jun 2006 09:41:58 +0200 (CEST)
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from FieldTalk
Message-ID: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>

Hi,
I'm evaluating the library for the modbus protocol
from FieldTalk
(http://www.modbusdriver.com/fieldtalk/.
I'm using J2SE 5.0 and RXTX 2.1 on win XP.
The problem is that the modbus lib has a method (the
openProtocol method, but maybe there are others) tha
throws the
javax.comm.UnsupportedCommOperationException.
Now, in RXTX 2.1 the namespace has changed in gnu.io,
so the modbus library doesn't work anymore (it look
for things in javax.comm). I've already sent an email
to fieldtalk to see if they are aware of the problem.
The solution should be to use JavaComm + RXTX 2.0. But
I've read somewhere that JavaComm 2.0 does not work
with Java 5.0 and JavaComm 3.0 does not work with RXTX
2.0 so I don't know what to do.

Any ideas?

Thanks Jack

PS: can you make a CC to my personal email
(g_petrini at yahoo.it) too please?

Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 


From rxtx at tapastda.co.uk  Thu Jun  8 02:27:57 2006
From: rxtx at tapastda.co.uk (rxtx@tapastda.co.uk)
Date: Thu, 08 Jun 2006 09:27:57 +0100
Subject: [Rxtx] Win XP and Infrared based serial port
Message-ID: <4487DF8D.5050807@tapastda.co.uk>

I'm attempting to use RXTX 2.1.7 on Win XP with J2SE 5.0 to communicate with a
GSM mobile using a COM port. A peculiarity that I've seen is that whilst I can
communicate successfully with a mobile which uses an infrared based COM port
using the SUN provided javax.comm (v2.0) I cannot use RXTX because it fails to
read anything from the port (i.e. read timeout always occurs returning zero bytes).

I assumed that this could be the result of flow control problems and thus I've
tried setting either software or hardware based flow control on the port however
this has no affect.

Can you suggest any other port configuration changes which might be required to
make such a port work with RXTX.

Thanks
Stu
-- 
Stuart
Tapastda Limited


From tjarvi at qbang.org  Thu Jun  8 05:17:12 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 8 Jun 2006 05:17:12 -0600 (MDT)
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from
	FieldTalk
In-Reply-To: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
References: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606080504480.9856@www>

On Thu, 8 Jun 2006, Giacomo Petrini wrote:

> Hi,
> I'm evaluating the library for the modbus protocol
> from FieldTalk
> (http://www.modbusdriver.com/fieldtalk/.
> I'm using J2SE 5.0 and RXTX 2.1 on win XP.
> The problem is that the modbus lib has a method (the
> openProtocol method, but maybe there are others) tha
> throws the
> javax.comm.UnsupportedCommOperationException.
> Now, in RXTX 2.1 the namespace has changed in gnu.io,
> so the modbus library doesn't work anymore (it look
> for things in javax.comm). I've already sent an email
> to fieldtalk to see if they are aware of the problem.
> The solution should be to use JavaComm + RXTX 2.0. But
> I've read somewhere that JavaComm 2.0 does not work
> with Java 5.0 and JavaComm 3.0 does not work with RXTX
> 2.0 so I don't know what to do.
>
> Any ideas?
>
> Thanks Jack
>


Hi Jack

There are plans for Sun to rerelease JavaComm 2.0 mentioned in the rxtx 
mail-list archives.  When this happens rxtx will release a current rxtx 
2.0 library that works with it.

There are no dates promised by either side but rxtx will do it as soon as 
possible after Sun's rerelease.  Just to give you a feel for the time 
frame, this started last year and no significant progress has been made. 
There have been friendly talks pointing towards solutions (rerelease 2.0) 
but that does not get your application working today.  rxtx is preparing 
for its second release in gnu.io since then.

--
Trent Jarvi
tjarvi at qbang.org




From jredman at ergotech.com  Thu Jun  8 08:47:23 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 08 Jun 2006 08:47:23 -0600
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from
	FieldTalk
In-Reply-To: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
References: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
Message-ID: <4488387B.6040903@ergotech.com>

You could always try a different library, eg.

http://sourceforge.net/projects/jamod

I've only used the slave side since we have our own implementation of 
Modbus Client (and a host of other PLC protocols).  However the client 
side seems to be pretty well supported and fairly widely used.  Since 
the source is there you could change to gnu.io.

I think I should take more of an interest in this issue.  We generally 
run 1.4.2 on Linux, but also have some J9 and old platforms that we 
support that are basically Personal Java.  5.0 on Linux has some 
horrible MDI bugs, to the point of being unusable.   Sounds as though we 
are going to have code compatibility problems across these platforms.

Jim


Giacomo Petrini wrote:
> Hi,
> I'm evaluating the library for the modbus protocol
> from FieldTalk
> (http://www.modbusdriver.com/fieldtalk/.
> I'm using J2SE 5.0 and RXTX 2.1 on win XP.
> The problem is that the modbus lib has a method (the
> openProtocol method, but maybe there are others) tha
> throws the
> javax.comm.UnsupportedCommOperationException.
> Now, in RXTX 2.1 the namespace has changed in gnu.io,
> so the modbus library doesn't work anymore (it look
> for things in javax.comm). I've already sent an email
> to fieldtalk to see if they are aware of the problem.
> The solution should be to use JavaComm + RXTX 2.0. But
> I've read somewhere that JavaComm 2.0 does not work
> with Java 5.0 and JavaComm 3.0 does not work with RXTX
> 2.0 so I don't know what to do.
> 
> Any ideas?
> 
> Thanks Jack
> 
> PS: can you make a CC to my personal email
> (g_petrini at yahoo.it) too please?
> 
> Chiacchiera con i tuoi amici in tempo reale! 
>  http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  8 18:17:23 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 08 Jun 2006 17:17:23 -0700
Subject: [Rxtx] rxtx access is denied error
Message-ID: <4488BE13.2050706@dupreeinc.com>

Hello,

I have been trying to replace the commapi from sun with rxtx for a 
project that communicates with a serial port that is a USB-Serial 
interface.  To be exact, I am using the FTDI VCP driver with one of 
their modules connected to a windows XP system.

I have the RXTX package working pretty well as long as nothing goes wrong.

If a user disconnects the USB port while my java application is running, 
my application goes into an endless loop with lots of messages in the  
errors stream  like the ones below:

    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(481):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.


I believe when this happens the COM port completely disappears and the 
rxtx driver has a heart attack.  Obviously, the user should not do this, 
but my application needs to ideally, correct the situation or as a worse 
case, terminate with a little dignity.  Currently, I have not figured 
out how to catch this error.

The closest I have come is to trap an exception to my input stream read  
that says "No error in readByte"  This error appears to be outside of 
the endless loop of the errors listed above.

Does anybody have an idea of how to identify and trap this error?  Any 
suggestions on how to gracefully recover from it would be greatly 
appreciated!

Thank you for your time,

Doug Thistlethwaite




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060608/9cfca302/attachment-0021.html

From tjarvi at qbang.org  Thu Jun  8 20:54:17 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 8 Jun 2006 20:54:17 -0600 (MDT)
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <4488BE13.2050706@dupreeinc.com>
References: <4488BE13.2050706@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606082022580.1323@www>

On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I have been trying to replace the commapi from sun with rxtx for a project 
> that communicates with a serial port that is a USB-Serial interface.  To be 
> exact, I am using the FTDI VCP driver with one of their modules connected to 
> a windows XP system.
>
> I have the RXTX package working pretty well as long as nothing goes wrong.
>
> If a user disconnects the USB port while my java application is running, my 
> application goes into an endless loop with lots of messages in the  errors 
> stream  like the ones below:
>
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(481):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>
>
> I believe when this happens the COM port completely disappears and the rxtx 
> driver has a heart attack.  Obviously, the user should not do this, but my 
> application needs to ideally, correct the situation or as a worse case, 
> terminate with a little dignity.  Currently, I have not figured out how to 
> catch this error.
>
> The closest I have come is to trap an exception to my input stream read  that 
> says "No error in readByte"  This error appears to be outside of the endless 
> loop of the errors listed above.
>
> Does anybody have an idea of how to identify and trap this error?  Any 
> suggestions on how to gracefully recover from it would be greatly 
> appreciated!
>

Hi Doug

Sadly I don't have a quick solution for you.

Termios has no knowlage about the JVM so it wont be throwing exceptions 
you can catch.

We can return error and set the error number to something reasonable that 
results in an exception.  The No Error message simply means we did not set 
an error number in termios.c.  Those are the line numbers in the code you 
see.  SerialImp.c realizes it errored but does not know much more yet. 
Everything touching the file descriptor is going to error after the port 
is gone presumably.

We don't currently have a plan in place for vanishing (or appearing) com 
ports.

Another example of what we need to think about is what happens if you 
start your application and then plug in the dongle?  Or what if you unplug 
and then plug it in again?

So in each of these three cases, what would the behavior of the (yet to 
be) correct implementation do?

How will the enumerated ports be handled during these changes?

There can also be hints from the OS that could be taken into 
consideration.

We can probably get some exceptions thrown that make sense and null the 
file descriptor when it happens to prevent io attempts.  That would be a 
crude way to let applications know something strange has happened.

Is anyone else tinkering with this problem?

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  9 01:31:29 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 9 Jun 2006 09:31:29 +0200
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <Pine.LNX.4.61.0606082022580.1323@www>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
Message-ID: <AC6EDDDD-0A64-401F-B16B-E484788CDF4A@buechse.de>

Hello Trent,

I am not tinkering with this on the Source Level - but I think it  
should work pretty much the same way as it currently does in OSX.  
When the port goes away you get an IOException thrown for any read/ 
write. It will no longer be in the list of ports from  
CommPortIdentifier.getPortIdentifiers(). When a port (re-)appears it  
is added to the list. It's up to the application to re-check the list  
from time to time.

On Windows you can't do much better then that, because the ports  
don't have useful names. Which USB "virtual com port" is on which  
COMx depends on the order the devices were added. So reconnecting to  
the same device may mean connecting to another port.

Regarding the exception thrown: it would be nice to use an  
IOException subclass but the Exception message should definetly be  
informative also as most applications may want to keep compatibility  
with javax.comm.

Regards,
Joachim


On 09.06.2006, at 04:54, Trent Jarvi wrote:

> On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:
>
>> Hello,
>>
>> I have been trying to replace the commapi from sun with rxtx for a  
>> project
>> that communicates with a serial port that is a USB-Serial  
>> interface.  To be
>> exact, I am using the FTDI VCP driver with one of their modules  
>> connected to
>> a windows XP system.
>>
>> I have the RXTX package working pretty well as long as nothing  
>> goes wrong.
>>
>> If a user disconnects the USB port while my java application is  
>> running, my
>> application goes into an endless loop with lots of messages in  
>> the  errors
>> stream  like the ones below:
>>
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (481):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>
>>
>> I believe when this happens the COM port completely disappears and  
>> the rxtx
>> driver has a heart attack.  Obviously, the user should not do  
>> this, but my
>> application needs to ideally, correct the situation or as a worse  
>> case,
>> terminate with a little dignity.  Currently, I have not figured  
>> out how to
>> catch this error.
>>
>> The closest I have come is to trap an exception to my input stream  
>> read  that
>> says "No error in readByte"  This error appears to be outside of  
>> the endless
>> loop of the errors listed above.
>>
>> Does anybody have an idea of how to identify and trap this error?   
>> Any
>> suggestions on how to gracefully recover from it would be greatly
>> appreciated!
>>
>
> Hi Doug
>
> Sadly I don't have a quick solution for you.
>
> Termios has no knowlage about the JVM so it wont be throwing  
> exceptions
> you can catch.
>
> We can return error and set the error number to something  
> reasonable that
> results in an exception.  The No Error message simply means we did  
> not set
> an error number in termios.c.  Those are the line numbers in the  
> code you
> see.  SerialImp.c realizes it errored but does not know much more yet.
> Everything touching the file descriptor is going to error after the  
> port
> is gone presumably.
>
> We don't currently have a plan in place for vanishing (or  
> appearing) com
> ports.
>
> Another example of what we need to think about is what happens if you
> start your application and then plug in the dongle?  Or what if you  
> unplug
> and then plug it in again?
>
> So in each of these three cases, what would the behavior of the  
> (yet to
> be) correct implementation do?
>
> How will the enumerated ports be handled during these changes?
>
> There can also be hints from the OS that could be taken into
> consideration.
>
> We can probably get some exceptions thrown that make sense and null  
> the
> file descriptor when it happens to prevent io attempts.  That would  
> be a
> crude way to let applications know something strange has happened.
>
> Is anyone else tinkering with this problem?
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From doug at dupreeinc.com  Fri Jun  9 13:09:58 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 09 Jun 2006 12:09:58 -0700
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <Pine.LNX.4.61.0606082022580.1323@www>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
Message-ID: <4489C786.9050504@dupreeinc.com>


Ideally, it would be nice if it would throw an exception and terminate 
the loop.  I am still trying to figure out how to detect the condition 
and recover form it in some form...  I am getting the "No error in 
readByte" exception in my serialEvent() method after an input stream 
read.  It appears to me that the only graceful recovery is to close the 
port and then reopen it when it becomes available.  I can pass the event 
up to the update method in my main frame, but I still can't close the 
port from within that thread.  Any suggestions on how to pass this event 
to a location where the port can be safely closed?

Re: Slow startup in windows XP
I have been looking into this a little closer and have found out the 
following:
System Windows XP Pro 3GHz dual core with 1GB RAM and NO parallel port.
Starting the SerialDemo included with the commapi using the rxtx instead 
of javax.comm takes 60 seconds.
Starting the SerialDemo using rxrx with the rxtxParallel.dll file 
removed takes about 20 seconds.
Modify initialize in RXRXCommDriver.java to not test the parallel ports 
takes less than 1 second.

It would be nice if the initialize routine could detect the presence of 
rxtxParallel.dll file and just skip the whole process if not present.  
Is there an easy way to check for the presence of this file without 
running the parallel port test?

Doug


 

Trent Jarvi wrote:

>On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:
>...
>  
>
>
>Hi Doug
>
>Sadly I don't have a quick solution for you.
>
>Termios has no knowlage about the JVM so it wont be throwing exceptions 
>you can catch.
>
>We can return error and set the error number to something reasonable that 
>results in an exception.  The No Error message simply means we did not set 
>an error number in termios.c.  Those are the line numbers in the code you 
>see.  SerialImp.c realizes it errored but does not know much more yet. 
>Everything touching the file descriptor is going to error after the port 
>is gone presumably.
>
>We don't currently have a plan in place for vanishing (or appearing) com 
>ports.
>
>Another example of what we need to think about is what happens if you 
>start your application and then plug in the dongle?  Or what if you unplug 
>and then plug it in again?
>
>So in each of these three cases, what would the behavior of the (yet to 
>be) correct implementation do?
>
>How will the enumerated ports be handled during these changes?
>
>There can also be hints from the OS that could be taken into 
>consideration.
>
>We can probably get some exceptions thrown that make sense and null the 
>file descriptor when it happens to prevent io attempts.  That would be a 
>crude way to let applications know something strange has happened.
>
>Is anyone else tinkering with this problem?
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060609/911ed787/attachment-0021.html

From Ugo.Landini at Sun.COM  Fri Jun  2 14:23:47 2006
From: Ugo.Landini at Sun.COM (Ugo Landini)
Date: Fri, 02 Jun 2006 22:23:47 +0200
Subject: [Rxtx] OSX 10.4.7 and usb
Message-ID: <44809E53.2070905@sun.com>

Hi, I have installed the library and the native libraries on OSX 10.4.7. 
Then I have run this simple code:

...
while (portList.hasMoreElements()) {
             portId = (CommPortIdentifier) portList.nextElement();
             System.out.println("-> " + portId.getName() + " Port Type:" 
+ portId.getPortType());
...

and the output is:

Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7

Ports found:
-> /dev/tty.Bluetooth-PDA-Sync Port Type:1
-> /dev/cu.Bluetooth-PDA-Sync Port Type:1
-> /dev/tty.Bluetooth-Modem Port Type:1
-> /dev/cu.Bluetooth-Modem Port Type:1

I can't see any USB ports... with javax.comm on linux I could see the 
/dev/ttyUSB stuff, but that's not the case with OSX. Any idea?

tia

uL


From tod at todbot.com  Sun Jun 11 12:04:37 2006
From: tod at todbot.com (Tod E. Kurt)
Date: Sun, 11 Jun 2006 11:04:37 -0700
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <44809E53.2070905@sun.com>
References: <44809E53.2070905@sun.com>
Message-ID: <E2EB14A1-20A7-4611-8F1A-E3D2ABE41F48@todbot.com>

A dumb question, but: do you have the USB serial adapters plugged  
in?  They only show up in /dev when plugged in.  Also, you can verify  
they exist independent of RXTX by doing something like "ls -l /dev/ 
cu.*".

On Jun 2, 2006, at 1:23 PM, Ugo Landini wrote:

> Hi, I have installed the library and the native libraries on OSX  
> 10.4.7.
> Then I have run this simple code:
>
> ...
> while (portList.hasMoreElements()) {
>              portId = (CommPortIdentifier) portList.nextElement();
>              System.out.println("-> " + portId.getName() + " Port  
> Type:"
> + portId.getPortType());
> ...
>
> and the output is:
>
> Experimental:  JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
>
> Ports found:
> -> /dev/tty.Bluetooth-PDA-Sync Port Type:1
> -> /dev/cu.Bluetooth-PDA-Sync Port Type:1
> -> /dev/tty.Bluetooth-Modem Port Type:1
> -> /dev/cu.Bluetooth-Modem Port Type:1
>
> I can't see any USB ports... with javax.comm on linux I could see the
> /dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>
> tia
>
> uL
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>



From lyon at docjava.com  Sun Jun 11 12:14:50 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Sun, 11 Jun 2006 14:14:50 -0400
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <44809E53.2070905@sun.com>
References: <44809E53.2070905@sun.com>
Message-ID: <p06020444c0b20de7d248@[192.168.1.152]>

>Hi Ugo,

Do you have any USB serial ports (like the keyspan 19-HS) plugged
into the mac?
Thanks!
  - DL


>Hi, I have installed the library and the native libraries on OSX 10.4.7.
>Then I have run this simple code:
>
>...
>while (portList.hasMoreElements()) {
>              portId = (CommPortIdentifier) portList.nextElement();
>              System.out.println("-> " + portId.getName() + " Port Type:"
>+ portId.getPortType());
>...
>
>and the output is:
>
>Experimental:  JNI_OnLoad called.
>Stable Library
>=========================================
>Native lib Version = RXTX-2.1-7
>Java lib Version   = RXTX-2.1-7
>
>Ports found:
>-> /dev/tty.Bluetooth-PDA-Sync Port Type:1
>-> /dev/cu.Bluetooth-PDA-Sync Port Type:1
>-> /dev/tty.Bluetooth-Modem Port Type:1
>-> /dev/cu.Bluetooth-Modem Port Type:1
>
>I can't see any USB ports... with javax.comm on linux I could see the
>/dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>
>tia
>
>uL
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx



From dmarkman at mac.com  Sun Jun 11 14:30:27 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Sun, 11 Jun 2006 16:30:27 -0400
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <p06020444c0b20de7d248@[192.168.1.152]>
References: <44809E53.2070905@sun.com> <p06020444c0b20de7d248@[192.168.1.152]>
Message-ID: <B9C1606B-4339-4564-A175-FE83DFFA7D76@mac.com>

afaik
10.4.7 wasn't released yet
it will soon, no doubts


On Jun 11, 2006, at 2:14 PM, Dr. Douglas Lyon wrote:

>> Hi Ugo,
>
> Do you have any USB serial ports (like the keyspan 19-HS) plugged
> into the mac?
> Thanks!
>   - DL
>
>
>> Hi, I have installed the library and the native libraries on OSX  
>> 10.4.7.
>> Then I have run this simple code:
>>
>> ...
>> while (portList.hasMoreElements()) {
>>              portId = (CommPortIdentifier) portList.nextElement();
>>              System.out.println("-> " + portId.getName() + " Port  
>> Type:"
>> + portId.getPortType());
>> ...
>>
>> and the output is:
>>
>> Experimental:  JNI_OnLoad called.
>> Stable Library
>> =========================================
>> Native lib Version = RXTX-2.1-7
>> Java lib Version   = RXTX-2.1-7
>>
>> Ports found:
>> -> /dev/tty.Bluetooth-PDA-Sync Port Type:1
>> -> /dev/cu.Bluetooth-PDA-Sync Port Type:1
>> -> /dev/tty.Bluetooth-Modem Port Type:1
>> -> /dev/cu.Bluetooth-Modem Port Type:1
>>
>> I can't see any USB ports... with javax.comm on linux I could see the
>> /dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>>
>> tia
>>
>> uL
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman



From tjarvi at qbang.org  Sun Jun 11 18:52:59 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 11 Jun 2006 18:52:59 -0600 (MDT)
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <4489C786.9050504@dupreeinc.com>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
	<4489C786.9050504@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606111845430.7274@www>

On Fri, 9 Jun 2006, Doug Thistlethwaite wrote:

>
> Ideally, it would be nice if it would throw an exception and terminate the 
> loop.  I am still trying to figure out how to detect the condition and 
> recover form it in some form...  I am getting the "No error in readByte" 
> exception in my serialEvent() method after an input stream read.  It appears 
> to me that the only graceful recovery is to close the port and then reopen it 
> when it becomes available.  I can pass the event up to the update method in 
> my main frame, but I still can't close the port from within that thread.  Any 
> suggestions on how to pass this event to a location where the port can be 
> safely closed?
>

I've gone through and cleaned up the termios.c layer.  I need to get to a 
windows machine with a USB dongle and see where the ioctl() is being 
called.  Probably the eventLoop.  But all of the ioctls should probably 
result in an IOException during this condition.

I'll probably finish this up Monday night when I can borrow a USB 
dongle.

There is no point in putting the code into CVS yet.  If you are tinkering 
I can mail the patch.  I think we will want to make a couple fixes in 
SerialImp.c to handle errors before it's ready.

--
Trent Jarvi
tjarvi at qbang.org



From bob_tai2001 at yahoo.com  Mon Jun 12 09:42:14 2006
From: bob_tai2001 at yahoo.com (Bob Tai)
Date: Mon, 12 Jun 2006 08:42:14 -0700 (PDT)
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to RXTX
	again
Message-ID: <20060612154214.58219.qmail@web32804.mail.mud.yahoo.com>


thank you Paul, Joachim, Trent and everyone try to
workout the java comm and Rxtx situation.  At least
now I have something that is solid enough to make my
decision.  

thank you,
     Bob

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From Ralph.Buchfelder at gmx.net  Mon Jun 12 15:30:20 2006
From: Ralph.Buchfelder at gmx.net (Ralph Buchfelder)
Date: Mon, 12 Jun 2006 23:30:20 +0200
Subject: [Rxtx] rxtx binaries or porting to XSCALE Windows Mobile 2003 / 2005
Message-ID: <448DDCEC.7090506@gmx.net>

dear group,

i have been carefully reading your homepage, wiki and archives
but there seems to be no detailled information on porting to Windows 
Mobile/CE.

as far as i understood from the 'porting' section you can do porting to 
winCE. but how? do i only need to obtain the sourcecode (which one?) and 
compile this in Microsoft eMbedded Visual C++ for ARM/Xscale?
Any other ways?


unfortunately i must admit that i do have little linux skills but i have 
made my way through gcc and makefiles. right now i need to implement com 
  communication in a J2ME application and found your website as >the< 
solution.

best regards
Ralph Buchfelder

University of Regensburg
Department of Geography

PS: i dont care about Javacomm compliancy (ie. 2.0 or 2.1) - i just need 
a working serial port API in IBM J9 VM.


From paul.klissner at sun.com  Wed Jun 14 18:12:58 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Wed, 14 Jun 2006 17:12:58 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
Message-ID: <4490A60A.9090305@sun.com>

Hello RxTx community,

I finally think I have a compromise in place that will stand in the gap.

If you go to http://www.sun.com and search for javax.comm, you'll
get taken to a download page, where now users can get a copy of the
comm.jar file out of 2.0.3, along with just a license and a README.

I trust this will suffice until such time as RxTx decided to implement
their own java classes or we can get a JSR going to mitigate some
of the problems (the readme in the comm.jar 2.0.3 zip file
contains my thoughts on that).

Thanks,
Paul



From tjarvi at qbang.org  Wed Jun 14 21:15:35 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 14 Jun 2006 21:15:35 -0600 (MDT)
Subject: [Rxtx] rxtx-2.0-7 (final) src is in CVS
Message-ID: <Pine.LNX.4.61.0606142100500.2742@www>


I wasn't expecting to be working on rxtx 2.0 tonight :)

Thanks go out to Paul Klissner for his work in making the coming release 
of rxtx-2.0-7 possible for users that require package javax.comm on many 
platforms.

Most people know that rxtx 2.0 is for use with Sun's CommAPI 2.0 for 
Solaris or the Generic CommAPI 2.0-3 available for download at Sun.  If 
you need javax.comm packages on many platforms, you are probably 
interested.  If you use rxtx 2.1 in package gnu.io, then you are not going 
to care much.

I've tried to update the rxtx 2.0 src directory in preparation for 
rxtx-2.0-7 (final).  Linux should compile.  Windows will compile if you 
generate your own .def files (I'll generate these tomorrow).  If you have 
some time to do basic testing of the source, I'd appreciate it.  The 
source should be good but you may find classes not found.  This source is 
a backport from rxtx 2.1.

I wanted to get things started so anyone interested on Mac OS X could get 
a head start.

All of this is in CVS.  http://www.rxtx.org/cvs.html

I suspect we will have binaries for testing in a couple days if you are 
unable to compile.   Consider this a smoke test.

--
Trent Jarvi
tjarvi at qbang.org


From legolas.w at gmail.com  Wed Jun 14 22:04:28 2006
From: legolas.w at gmail.com (Legolas Woodland)
Date: Wed, 14 Jun 2006 21:04:28 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <4490A60A.9090305@sun.com>
References: <4490A60A.9090305@sun.com>
Message-ID: <87ee9b170606142104p745fcef0vea622fbc8f528bfc@mail.gmail.com>

is there anything new in this version of javax.comm ?
thanks


On 6/14/06, Paul Klissner <paul.klissner at sun.com> wrote:
>
> Hello RxTx community,
>
> I finally think I have a compromise in place that will stand in the gap.
>
> If you go to http://www.sun.com and search for javax.comm, you'll
> get taken to a download page, where now users can get a copy of the
> comm.jar file out of 2.0.3, along with just a license and a README.
>
> I trust this will suffice until such time as RxTx decided to implement
> their own java classes or we can get a JSR going to mitigate some
> of the problems (the readme in the comm.jar 2.0.3 zip file
> contains my thoughts on that).
>
> Thanks,
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060614/5ff4dfbc/attachment-0021.html

From joachim at buechse.de  Thu Jun 15 07:22:48 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 15 Jun 2006 15:22:48 +0200
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
Message-ID: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>

Good day!

Some of my users report problems using RXTX 2.1.7 on Windows98 to  
communicate with an FTDI FT245BM chip (using their latest VCP  
driver). Either no ports are being shown (ie returned form  
CommPortIdentifier.getPortIdentifiers()) or the transfers fail.

Did anyone run into similar Problems with Win98??

Best regards,
Joachim



From ajmas at sympatico.ca  Thu Jun 15 08:12:28 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Thu, 15 Jun 2006 10:12:28 -0400
Subject: [Rxtx] API change question
Message-ID: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

How closely do you follow the Java Communication API spec? The reason I ask is because I would be interested in augmenting the CommPortIdentifier class to include a getDisplayName() method. By default it would return the same value as getName(), but would provide the possibility of displaying a 'user friendly' name, for platforms where the display name is not the same as the device name. An example of this is on MacOS X, where currently the names seem to be of the form /dev/cu.* and /dev/tty.*, yet what the expects to see is simply the part after the full-stop. Although I could move this logic into the Java code, it would be nice to see it transparent to the Java code.

Andre




From ajmas at sympatico.ca  Thu Jun 15 08:16:22 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Thu, 15 Jun 2006 10:16:22 -0400
Subject: [Rxtx] Package to use
Message-ID: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

While the Java API spec refers to javax.comm, I see that only gnu.io is provide by the rxtx project. Should our projects refer to the gnu.io package or the javax.comm API?

Andre



From joachim at buechse.de  Thu Jun 15 08:45:05 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 15 Jun 2006 16:45:05 +0200
Subject: [Rxtx] API change question
In-Reply-To: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>

Hello Andre,

the /dev/cu and /dev/tty have different semantics on OS X. It is much  
more than a simply naming issue to unify them, see my recent mail to  
the list...

Best regards,
Joachim


On 15.06.2006, at 16:12, Andre-John Mas wrote:

> Hi,
>
> How closely do you follow the Java Communication API spec? The  
> reason I ask is because I would be interested in augmenting the  
> CommPortIdentifier class to include a getDisplayName() method. By  
> default it would return the same value as getName(), but would  
> provide the possibility of displaying a 'user friendly' name, for  
> platforms where the display name is not the same as the device  
> name. An example of this is on MacOS X, where currently the names  
> seem to be of the form /dev/cu.* and /dev/tty.*, yet what the  
> expects to see is simply the part after the full-stop. Although I  
> could move this logic into the Java code, it would be nice to see  
> it transparent to the Java code.
>
> Andre
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From lyon at docjava.com  Thu Jun 15 10:16:29 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Thu, 15 Jun 2006 12:16:29 -0400
Subject: [Rxtx] cu.modem != /dev/ttya on mac.
In-Reply-To: <763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
	<763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>
Message-ID: <p0602046cc0b7378a95b0@[192.168.1.152]>

>Hi All,

I think that Joachim is correct. For the longest time,
I have been trying to figure out how to direct dial using
the cu.modem on the mac under os x.

As a less-than-optimal approach to auto-dialing, I have used
a keyspan USB 19HS adapter, along with an external modem, to
obtain the dialing feature.

Ideally, it would be better to dial with the built-in modem...but that did not
always seem to work, for some reason. Have others had some experience with
using the built in modem for dialing on the mac?

Thanks!
  - Doug


>Hello Andre,
>
>the /dev/cu and /dev/tty have different semantics on OS X. It is much?
>more than a simply naming issue to unify them, see my recent mail to?
>the list...
>
>Best regards,
>Joachim
>



From doug at dupreeinc.com  Thu Jun 15 14:52:50 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 15 Jun 2006 13:52:50 -0700
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
In-Reply-To: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
References: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
Message-ID: <4491C8A2.8090108@dupreeinc.com>

Hi Joachim,

I have been doing a lot with the new FTDI driver with win XP and have 
not had that particular problem.  I did notice that the new driver 
(dated May19th, 2006) is only for XP, Server 2003, and 2000.  Are they 
trying to use the 2.00.00 drivers or the old 1.09.06 version.  I am 
using a FT232R based module, but it uses the same drivers and I assume 
it would have the same problems.  Let me know which driver they are 
using and I can load up a 98 system here and see if  I can duplicate the 
problem.

Doug

Joachim Buechse wrote:

>Good day!
>
>Some of my users report problems using RXTX 2.1.7 on Windows98 to  
>communicate with an FTDI FT245BM chip (using their latest VCP  
>driver). Either no ports are being shown (ie returned form  
>CommPortIdentifier.getPortIdentifiers()) or the transfers fail.
>
>Did anyone run into similar Problems with Win98??
>
>Best regards,
>Joachim
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From matthewhepp at yahoo.com  Thu Jun 15 17:34:47 2006
From: matthewhepp at yahoo.com (Matthew Hepp)
Date: Thu, 15 Jun 2006 16:34:47 -0700 (PDT)
Subject: [Rxtx] Wither the XCode project?
Message-ID: <20060615233447.48064.qmail@web50311.mail.yahoo.com>

Either I don't know how to properly use CVS (entirely possibl), or the XCode
project is not making through the update properly. Doing a "cvs update" against
2.1-7 creates an XCode folder in MACOSX_IDE, and therein a
LibSerialUniversal.xcodeproj, but trying to open it yields a "Unable to Open
Project - Project rxtx-devel/MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj
cannot be opened because it is missing its project.pbxproj file" error. Showing
package contents reveals just the cvs-related files. Perhaps this is why
previous xcode projects have been saved as an sit.hqx - to retain the resource
fork?

Can someone point me in the right direction?

Thanks,

Matt

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Thu Jun 15 19:53:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 19:53:06 -0600 (MDT)
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
In-Reply-To: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
References: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
Message-ID: <Pine.LNX.4.61.0606151944070.23137@www>

On Thu, 15 Jun 2006, Joachim Buechse wrote:

> Good day!
>
> Some of my users report problems using RXTX 2.1.7 on Windows98 to
> communicate with an FTDI FT245BM chip (using their latest VCP
> driver). Either no ports are being shown (ie returned form
> CommPortIdentifier.getPortIdentifiers()) or the transfers fail.
>
> Did anyone run into similar Problems with Win98??
>

Hi Joachim

It has been a long time since I've tested win98.  I know rxtx-2.1-7pre16 
did get testing on win98 with ~jdk 1.3 though.  I wonder if jdks are still 
tested on that platform.

With win98 you usually have older boxes.  They can be short on CPU and 
memory.  Enumeration should work but I could picture runtime performance 
issues on win98.

The enumeration problems could result from other copies of your 
application if various states of decay still holding onto the port.  When 
things go wrong, people also like to open other terminal software to see 
whats going on which can interfere.  You can't open a windows port with 
two apps.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Thu Jun 15 20:08:53 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 20:08:53 -0600 (MDT)
Subject: [Rxtx] API change question
In-Reply-To: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606151954270.23137@www>

On Thu, 15 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> How closely do you follow the Java Communication API spec?

I can explain how this worked in the past.  How we do it in the future is 
open for discussion.

In the past we have tried to follow it as close as possible in gnu.io 
(rxtx 2.1).  We have added extensions but try to discourage their use. 
The extensions are clearly marked as such in the source code and javadocs.

rxtx 2.0 was intended to be a strict implementation of part of the spec. 
We let Sun's interfaces decide what methods can be called. There are 
differences not covered by the spec such as default values.  Thats not 
intentional but rather hard to avoid.

--
Trent Jarvi
tjarvi at qbang.org





From tjarvi at qbang.org  Thu Jun 15 21:09:11 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 21:09:11 -0600 (MDT)
Subject: [Rxtx] Package to use
In-Reply-To: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606152026120.23137@www>

On Thu, 15 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> While the Java API spec refers to javax.comm, I see that only gnu.io is 
> provide by the rxtx project. Should our projects refer to the gnu.io 
> package or the javax.comm API?
>

Hi Andre

Lets see if I can give a fair and balanced answer to that.

If you are starting a new project and want to use RXTX, I would recommend 
using gnu.io.  The community support for gnu.io will not be going away 
anytime soon.  You can switch between gnu.io (2.1) and javax.comm (2.0) 
fairly easily.  They are not intended to be incompatible.  You just change 
package names and libs.

You can also consider the combination of rxtx 2.0 with Sun's commapi 
2.0-3.  This is considered a stop-gap measure by Sun for previous users of 
that combination.  Together rxtx 2.0 and Sun CommAPI 2.0 work in namespace 
javax.comm for programmers.

Finally, you can opt to just use Sun's oferrings in CommAPI 3.0 without 
rxtx.  That would be in namespace javax.comm also.  CommAPI 3.0 may be 
of more interest to you if you are looking at POS with Sun computers. 
Rxtx does not currently support the changes in CommAPI 3.0 or have firm 
plans to do so.  That does not mean we wouldn't implement them.  It just 
means nobody has contributed code yet.

You can't combine rxtx with CommAPI 3.0 for technical reasons that wont 
likely be fixed soon.

It's up to you as far as what you use.  We like to provide the freedom so 
you can choose.  Realistically, we will be supporting gnu.io mainly 
because we have some control over that name space and can support it.

Things may happen in the future that enable rxtx to provide more support 
in the javax namespace but that has not happened yet.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun 16 00:33:06 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 08:33:06 +0200
Subject: [Rxtx] Wither the XCode project?
In-Reply-To: <20060615233447.48064.qmail@web50311.mail.yahoo.com>
References: <20060615233447.48064.qmail@web50311.mail.yahoo.com>
Message-ID: <D30D660F-A49B-464E-AE4C-6B4563893682@buechse.de>

Hello Matthew,

could you please send me the contents of your

   rxtx-devel/CVS
   rxtx-devel/MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj/CVS

directories as a zip to my personal email address. This should  
indicate why the file is not checked out. I can see that it exists on  
the correct branch in the repository, so something must have gone  
wrong during the "cvs update"...

Best regards,
Joachim

On 16.06.2006, at 01:34, Matthew Hepp wrote:

> Either I don't know how to properly use CVS (entirely possibl), or  
> the XCode
> project is not making through the update properly. Doing a "cvs  
> update" against
> 2.1-7 creates an XCode folder in MACOSX_IDE, and therein a
> LibSerialUniversal.xcodeproj, but trying to open it yields a  
> "Unable to Open
> Project - Project rxtx-devel/MACOSX_IDE/XCode/ 
> LibSerialUniversal.xcodeproj
> cannot be opened because it is missing its project.pbxproj file"  
> error. Showing
> package contents reveals just the cvs-related files. Perhaps this  
> is why
> previous xcode projects have been saved as an sit.hqx - to retain  
> the resource
> fork?
>
> Can someone point me in the right direction?



From joachim at buechse.de  Fri Jun 16 10:41:20 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 18:41:20 +0200
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <p06230903c0b88613dca6@[10.0.1.7]>
References: <p06230903c0b88613dca6@[10.0.1.7]>
Message-ID: <03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>

Hello Bob,

until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was  
behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if  
Trent has migrated all recent changes from 2.1 to 2.0.

I have added the XCode project and updated documentation only to the  
gnu.io branch. Once the 2.0 implementation is up to date I will copy  
over the documentation/build files make them work.

Best regards,
Joachim

On 16.06.2006, at 18:07, Bob Jacobsen wrote:

> I'm one of the developers for the JMRI project, which provides  
> model railroad software in Java.  We've been using RXTX to provide  
> serial port access on MacOS X and Linux; we use the old javax.comm  
> 2.0 on Windows, OS/2 and Solaris.  Because of that, we need to stay  
> with RXTX 2.0, not 2.1
>
> We've been using the 2.0-pre17 installer for a long time, but it's  
> not compatible with Intel macs.
>
> Can you point me to where I can find the right files for RXTX 2.0  
> to package with the program?
>
> The current situation is confusing to me.  I've been pointed to  
> recent 2.1 versions (but we need the javax.comm names), to an even  
> older installer, etc.  I've been reading that some versions require  
> an installer, and others don't, but I haven't been able to figure  
> out which (if any) of those are where in CVS.
>
> I'd really appreciate a clear statement of what files to use and  
> what to do with them that I can pass on to our users.
>
> I'm more than happy to put files in the local classpath, have users  
> run an installer, or anything else.  Whatever is easiest for you.
>
> Thanks!  I really appreciate all that you do to keep RXTX working.
>
> Bob
> -- 
> Bob Jacobsen +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG



From joachim at buechse.de  Fri Jun 16 09:59:28 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 17:59:28 +0200
Subject: [Rxtx] Wither the XCode project?
In-Reply-To: <20060616150240.49464.qmail@web50309.mail.yahoo.com>
References: <20060616150240.49464.qmail@web50309.mail.yahoo.com>
Message-ID: <D9935E05-2B83-488D-86DD-42599E229052@buechse.de>

Hello Matthew,

you have checked out the trunk (which is the 2.0.7 javax.comm.xxx  
release). For rxtx-2.1.7 (gnu.io.xxx release) you need to check out  
the branch

      commapi-0-0-1

The easiest way to do this is to download the rxtx src archive,  
unpack it and then do a cvs up inside the decompressed tree.  
Optionally you could do a

      cvs co -r commapi-0-0-1

but this will take much longer!

Best regards,
Joachim

When you do a cvs status it will show the sticky tag.

41:~/jdevelop/rxtx-2.1-7r2 joachim$ cvs status README.OSX
===================================================================
File: README.OSX        Status: Up-to-date

    Working revision:    1.1.2.1
    Repository revision: 1.1.2.1 /usr/local/cvsroot/rxtx-devel/Attic/ 
README.OSX,v
    Sticky Tag:          commapi-0-0-1 (branch: 1.1.2)
    Sticky Date:         (none)
    Sticky Options:      (none)




On 16.06.2006, at 17:02, Matthew Hepp wrote:

> %cvs status README.MACOSX
> ===================================================================
> File: README.MACOSX     Status: Up-to-date
>
>    Working revision:    1.1
>    Repository revision: 1.1     /usr/local/cvsroot/rxtx-devel/ 
> README.MACOSX,v
>    Sticky Tag:          (none)
>    Sticky Date:         (none)
>    Sticky Options:      (none)



From tjarvi at qbang.org  Fri Jun 16 16:31:18 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Fri, 16 Jun 2006 16:31:18 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
Message-ID: <Pine.LNX.4.61.0606161630030.14139@www>

On Fri, 16 Jun 2006, Joachim Buechse wrote:

> Hello Bob,
>
> until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was
> behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if
> Trent has migrated all recent changes from 2.1 to 2.0.
>

The src/ directory and configure.in/configure files should be fine.  I 
have not touched the Mac OS X directories.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sat Jun 17 02:39:55 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sat, 17 Jun 2006 10:39:55 +0200
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <Pine.LNX.4.61.0606161630030.14139@www>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
Message-ID: <350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>

Hello Trent,

apparently the IOEXCL changes have not made it into 2.0. I will add  
them to achieve a minimal diff between 2.0 and 2.1.

One other thing that bugs me for a while...

Shouldn't we replace "if !defined(TIOCSERGETLSR) && !defined(WIN32)"  
by a definition of its own "if defined(DRAINTHREAD)"? I think this  
would make the code clearer for people starting to read it.

Regards,
Joachim


On 17.06.2006, at 00:31, Trent Jarvi wrote:

> On Fri, 16 Jun 2006, Joachim Buechse wrote:
>
>> Hello Bob,
>>
>> until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was
>> behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if
>> Trent has migrated all recent changes from 2.1 to 2.0.
>>
>
> The src/ directory and configure.in/configure files should be fine.  I
> have not touched the Mac OS X directories.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From tropicsu at hotmail.com  Sat Jun 17 09:32:48 2006
From: tropicsu at hotmail.com (Yoke K)
Date: Sat, 17 Jun 2006 15:32:48 +0000
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
Message-ID: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>

Hi,

I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to work with 
MAC OS X.
I am using iTegno 3000 - USB GPRS Modem.

Files in /dev and a symbolic link as follows:

crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 -> tty.usbserial

In my SendMessage.java, I have this line:
CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");

Appreciate any help ?

- Jon


Errors as follows:

>>INFO: SMSLib API for Java / v1.2.2
>>INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>INFO: JRE Version: 1.5.0_06
>>INFO: JRE Impl Version: 1.5.0_06-64
>>INFO: O/S: Mac OS X / ppc / 10.4.6
>>INFO: Using Wavecom (Generic) AT handler.

SendMessage(): Send a message.
  Using SMSLib API for Java v1.2.2

Connecting ..... :
>>INFO: CSerialDriver(): Connecting...
Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
>>INFO: CSerialDriver(): Disconnecting...
gnu.io.NoSuchPortException
        at 
gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:218)
        at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
        at org.smslib.CService.connect(CService.java:197)
        at SendMessage.main(SendMessage.java:38)

_________________________________________________________________
Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/



From tjarvi at qbang.org  Sat Jun 17 10:12:30 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 10:12:30 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
	<350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
Message-ID: <Pine.LNX.4.61.0606171010060.14139@www>

On Sat, 17 Jun 2006, Joachim Buechse wrote:

> Hello Trent,
>
> apparently the IOEXCL changes have not made it into 2.0. I will add
> them to achieve a minimal diff between 2.0 and 2.1.
>

Hi Joachim

As I recall the IOEXCL change was after 2.1-7.  I was just syncing with 
2.1-7.  We can release 2.1-8 and 2.0-8 with the same changes.

> One other thing that bugs me for a while...
>
> Shouldn't we replace "if !defined(TIOCSERGETLSR) && !defined(WIN32)"
> by a definition of its own "if defined(DRAINTHREAD)"? I think this
> would make the code clearer for people starting to read it.
>


Sure.  We can do that for -8.  The TIOCSERGETLSR code should be a special 
case not the expected.  I think only Linux uses it.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Sat Jun 17 10:48:21 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 10:48:21 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <Pine.LNX.4.61.0606171010060.14139@www>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
	<350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
	<Pine.LNX.4.61.0606171010060.14139@www>
Message-ID: <Pine.LNX.4.61.0606171047310.14139@www>

On Sat, 17 Jun 2006, Trent Jarvi wrote:

> On Sat, 17 Jun 2006, Joachim Buechse wrote:
>
>> Hello Trent,
>>
>> apparently the IOEXCL changes have not made it into 2.0. I will add
>> them to achieve a minimal diff between 2.0 and 2.1.
>>
>
> Hi Joachim
>
> As I recall the IOEXCL change was after 2.1-7.  I was just syncing with
> 2.1-7.  We can release 2.1-8 and 2.0-8 with the same changes.
>

We could just move to 2.1-8 and 2.0-8.

--
Trent Jarvi
tjarvi at qbang.org


From brian.t.lamb at gmail.com  Tue Jun 13 13:54:13 2006
From: brian.t.lamb at gmail.com (Brian Lamb)
Date: Tue, 13 Jun 2006 15:54:13 -0400
Subject: [Rxtx] Windows XP Installation
Message-ID: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>

I've not installed Java packages on Windows before and am unsure how to
proceed. All the documentation I've seen provides detailed instructions on
how to install on Linux or Solaris. I was wondering how to install rxtx on
Windows XP.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060613/6f68cd5c/attachment-0021.html

From tjarvi at qbang.org  Sat Jun 17 13:57:03 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 13:57:03 -0600 (MDT)
Subject: [Rxtx] Windows XP Installation
In-Reply-To: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>
References: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0606171356120.14139@www>

On Tue, 13 Jun 2006, Brian Lamb wrote:

> I've not installed Java packages on Windows before and am unsure how to
> proceed. All the documentation I've seen provides detailed instructions on
> how to install on Linux or Solaris. I was wondering how to install rxtx on
> Windows XP.
>

Hi Brian

Which rxtx version are you trying to install?

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sun Jun 18 10:41:44 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sun, 18 Jun 2006 18:41:44 +0200
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
References: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
Message-ID: <8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>

Hello Jon,

 From OSX's standpoint a symbolic link is not a device (as far as I  
know). What stops you from using tty.usbserial? Did you try hard- 
linking?

Regards,
Joachim

On 17.06.2006, at 17:32, Yoke K wrote:
> Hi,
>
> I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to  
> work with
> MAC OS X.
> I am using iTegno 3000 - USB GPRS Modem.
>
> Files in /dev and a symbolic link as follows:
>
> crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
> crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
> lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->  
> tty.usbserial
>
> In my SendMessage.java, I have this line:
> CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
>
> Appreciate any help ?
>
> - Jon
>
>
> Errors as follows:
>
>>> INFO: SMSLib API for Java / v1.2.2
>>> INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>> INFO: JRE Version: 1.5.0_06
>>> INFO: JRE Impl Version: 1.5.0_06-64
>>> INFO: O/S: Mac OS X / ppc / 10.4.6
>>> INFO: Using Wavecom (Generic) AT handler.
>
> SendMessage(): Send a message.
>   Using SMSLib API for Java v1.2.2
>
> Connecting ..... :
>>> INFO: CSerialDriver(): Connecting...
> Experimental:  JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
>>> INFO: CSerialDriver(): Disconnecting...
> gnu.io.NoSuchPortException
>         at
> gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java: 
> 218)
>         at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
>         at org.smslib.CService.connect(CService.java:197)
>         at SendMessage.main(SendMessage.java:38)
>
> _________________________________________________________________
> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Sun Jun 18 10:56:55 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 12:56:55 -0400
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>
References: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
	<8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>
Message-ID: <7B6834E3-F41D-46B6-B979-55466BC73859@sympatico.ca>

Have you been able to get any other software to talk with your
modem? What port is it using? Have tried using the cu.usbserial
instead?

Andre

On 18-Jun-06, at 12:41 , Joachim Buechse wrote:

> Hello Jon,
>
>  From OSX's standpoint a symbolic link is not a device (as far as I
> know). What stops you from using tty.usbserial? Did you try hard-
> linking?
>
> Regards,
> Joachim
>
> On 17.06.2006, at 17:32, Yoke K wrote:
>> Hi,
>>
>> I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to
>> work with
>> MAC OS X.
>> I am using iTegno 3000 - USB GPRS Modem.
>>
>> Files in /dev and a symbolic link as follows:
>>
>> crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
>> crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
>> lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->
>> tty.usbserial
>>
>> In my SendMessage.java, I have this line:
>> CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
>>
>> Appreciate any help ?
>>
>> - Jon
>>
>>
>> Errors as follows:
>>
>>>> INFO: SMSLib API for Java / v1.2.2
>>>> INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>>> INFO: JRE Version: 1.5.0_06
>>>> INFO: JRE Impl Version: 1.5.0_06-64
>>>> INFO: O/S: Mac OS X / ppc / 10.4.6
>>>> INFO: Using Wavecom (Generic) AT handler.
>>
>> SendMessage(): Send a message.
>>   Using SMSLib API for Java v1.2.2
>>
>> Connecting ..... :
>>>> INFO: CSerialDriver(): Connecting...
>> Experimental:  JNI_OnLoad called.
>> Stable Library
>> =========================================
>> Native lib Version = RXTX-2.1-7
>> Java lib Version   = RXTX-2.1-7
>>>> INFO: CSerialDriver(): Disconnecting...
>> gnu.io.NoSuchPortException
>>         at
>> gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:
>> 218)
>>         at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
>>         at org.smslib.CService.connect(CService.java:197)
>>         at SendMessage.main(SendMessage.java:38)
>>
>> _________________________________________________________________
>> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Sun Jun 18 17:33:08 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 19:33:08 -0400
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
Message-ID: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>

Hi,

I am have a program that I wrote in Java to communicate with a  
Bluetooth GPS device. I am
trying to get this working on my Mac, but I keep getting told that:

gnu.io.PortInUseException: Unknown Application

but

portIdentifier.isCurrentlyOwned()

returns false and when I do lsof on the device I am trying to connect  
to, I see no application
using it. As the same time if I go to the command line and use  
minicom I have no issues. The
exception happens with this call:

CommPort commPort = portIdentifier.open(null,0);

Any suggestions?

Andre


From ajmas at sympatico.ca  Sun Jun 18 17:45:11 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 19:45:11 -0400
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
Message-ID: <30245B30-682D-4EAE-8084-8227B719F10D@sympatico.ca>

BTW My code snippet is:

     private InputStream connectToSerial () throws IOException,  
Exception
     {
         InputStream in = null;

         Enumeration portEnum = CommPortIdentifier.getPortIdentifiers();
         while ( portEnum.hasMoreElements() )
         {
             CommPortIdentifier portIdentifier = (CommPortIdentifier)  
portEnum.nextElement();
             System.out.println(portIdentifier.getName() + " - " +  
portIdentifier.getPortType() );
         }

         CommPortIdentifier portIdentifier =  
CommPortIdentifier.getPortIdentifier("/dev/cu.BTGPS-SPPslave-1");
         System.out.println("current owner: " +  
portIdentifier.getCurrentOwner());
         if ( portIdentifier.isCurrentlyOwned() )
         {
             System.out.println("Error: Port is currently in use");
             return null;
         }
         else
         {
             CommPort commPort = portIdentifier.open(this.getClass 
().getName(),2000);

             if ( commPort instanceof SerialPort )
             {
                 SerialPort serialPort = (SerialPort) commPort;
                 serialPort.setSerialPortParams 
(4800,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE 
);
                 in = serialPort.getInputStream();

                 return in;
             }
             else
             {
                 System.out.println("Error: Only serial ports are  
handled.");
             }
         }


         return in;
     }


On 18-Jun-06, at 19:33 , Andr?-John Mas wrote:

> Hi,
>
> I am have a program that I wrote in Java to communicate with a
> Bluetooth GPS device. I am
> trying to get this working on my Mac, but I keep getting told that:
>
> gnu.io.PortInUseException: Unknown Application
>
> but
>
> portIdentifier.isCurrentlyOwned()
>
> returns false and when I do lsof on the device I am trying to connect
> to, I see no application
> using it. As the same time if I go to the command line and use
> minicom I have no issues. The
> exception happens with this call:
>
> CommPort commPort = portIdentifier.open(null,0);
>
> Any suggestions?
>
> Andre
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From joachim at buechse.de  Mon Jun 19 05:54:49 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 13:54:49 +0200
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de>

This is most likely due to a problem with lock files. If you have  
downloaded the binaries of 2.17 rxtx will try to create non-standard  
lock files on OSX. We have since changed the code to use OSX device  
locking - however the binaries have not been updated yet. The 2.18  
release fixing this issue is due shortly.

Regards,
Joachim

On 19.06.2006, at 01:33, Andr?-John Mas wrote:

> Hi,
>
> I am have a program that I wrote in Java to communicate with a
> Bluetooth GPS device. I am
> trying to get this working on my Mac, but I keep getting told that:
>
> gnu.io.PortInUseException: Unknown Application
>
> but
>
> portIdentifier.isCurrentlyOwned()
>
> returns false and when I do lsof on the device I am trying to connect
> to, I see no application
> using it. As the same time if I go to the command line and use
> minicom I have no issues. The
> exception happens with this call:
>
> CommPort commPort = portIdentifier.open(null,0);
>
> Any suggestions?
>
> Andre
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From joachim at buechse.de  Mon Jun 19 06:44:27 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 14:44:27 +0200
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <4490A60A.9090305@sun.com>
References: <4490A60A.9090305@sun.com>
Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>

Hello Paul,

I just downloaded the "generic" javax.comm version now available. A  
first check indicates, that it was compiled with a JDK 1.4 javac  
without setting the target classfile version. In other words in can  
not be loaded by 1.1-1.3 VMs (or PersonalJava).

Do you see any chance to provide a version compiled with classfile  
format 45.3 (ie JVM1.1).

---
52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose  
javax.comm.SerialPort | head -5
Compiled from "SerialPort.java"
public abstract class javax.comm.SerialPort extends javax.comm.CommPort
   SourceFile: "SerialPort.java"
   minor version: 0
   major version: 48
---

Best regards,
Joachim


On 15.06.2006, at 02:12, Paul Klissner wrote:

> Hello RxTx community,
>
> I finally think I have a compromise in place that will stand in the  
> gap.
>
> If you go to http://www.sun.com and search for javax.comm, you'll
> get taken to a download page, where now users can get a copy of the
> comm.jar file out of 2.0.3, along with just a license and a README.
>
> I trust this will suffice until such time as RxTx decided to implement
> their own java classes or we can get a JSR going to mitigate some
> of the problems (the readme in the comm.jar 2.0.3 zip file
> contains my thoughts on that).
>
> Thanks,
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Mon Jun 19 09:11:45 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Mon, 19 Jun 2006 11:11:45 -0400
Subject: [Rxtx] Examples added to Wiki
Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

I have added a couple of examples to the Wiki:

http://rxtx.qbang.org/wiki/index.php/Examples

If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :)

Andre



From paul.klissner at sun.com  Mon Jun 19 10:42:47 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Mon, 19 Jun 2006 09:42:47 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>
References: <4490A60A.9090305@sun.com>
	<03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>
Message-ID: <4496D407.1090609@sun.com>

Joachim Buechse wrote:
> Hello Paul,
> 
> I just downloaded the "generic" javax.comm version now available. A  
> first check indicates, that it was compiled with a JDK 1.4 javac  
> without setting the target classfile version. In other words in can  
> not be loaded by 1.1-1.3 VMs (or PersonalJava).
> 
> Do you see any chance to provide a version compiled with classfile  
> format 45.3 (ie JVM1.1).
> 
> ---
> 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose  
> javax.comm.SerialPort | head -5
> Compiled from "SerialPort.java"
> public abstract class javax.comm.SerialPort extends javax.comm.CommPort
>    SourceFile: "SerialPort.java"
>    minor version: 0
>    major version: 48
> ---

I cannot promise when I can do that. Since we thought we were done
with javax.comm, the build environment got moved around, and right
now it doesn't even compile in it's new home.  I tried and it was
not cooperative at all. I was never impressed with that workspace
(in fact far far from it, it is a mess, which is why I migrated 3.0
to ant and never looked back).  It will take some real determination
for me to rebuild it, and frankly, right now I'm swamped.  If I can
find a bit of time over the next few weeks to do it, and it isn't
too bad an ordeal, I will.

Posting that will give me an excuse to post javax.comm 3.0, Update 2 as
well, while I'm working with the people who put content up on our
download center.  The only reason for a new update to 3.0 is that
I've changed the distribution to provide ispt (Interactive Serial
Port Tool), such that it can be launched as soon as the zip file
is unpacked, via a provided script.  ISPT is a command line
interactive tool for  manipulating one or two serial port,
sending data, managing events, etc... I've found it to be so useful
for doing certain kinds of validation  that I assume others will
find it useful to.  ISPT is already in 3.0u1, but one has to set
up their own classpath and launch it and since few people ever read
the documentation most won't know about it.  I've added the ability
to set stop bits and parity since 3.0u1 too.  But I digress.

Paul


From joachim at buechse.de  Mon Jun 19 11:01:28 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 19:01:28 +0200
Subject: [Rxtx] load mechanism of 2.0x
Message-ID: <CFD1440C-21AA-4D3B-9EA6-270D0FF9D6FC@buechse.de>

Good day,

I am trying to figure out, how the 2.0x distribution interacts with  
Suns implementation of javax.comm.CommPortIdentifier.

1) Apparently one can put javax.comm.properties in {java.home}/lib
2) The javax.comm package also reacts to -Djavax.comm.properties="...."

Looking at the javap output it also seems like CommPortIdentifier  
tries to find it's jar file and load the properties from there??


What I'm really looking for is a solution that allows using  
javax.comm with RXTX without modifying the VM installation. So I  
would prefer not to use 1) but I can't figure out how to use 2).

Any hints are welcome,
Joachim



From bob_tai2001 at yahoo.com  Mon Jun 19 15:00:35 2006
From: bob_tai2001 at yahoo.com (Bob Tai)
Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT)
Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place
	to start?
Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>

Hi, 

I got  rxtx Windows 2000 installed.  I did not use the
"best" way ... I just follow the insturuction and dump
the necessary files into the jre... I know it's "best"
idea, I got lazy didn't want to change my setting to
my Eclipse and classpath.

I was able to modify SimpleWrite.java to print on my
AddMaster serial printer.  I think I am ready to code!
But I need to make sure I can handle exceptions and so
on.  I notice the \samples\NullDriver\  has two files
seems to have some of the require method done, should
I start coding from those file?  I like the idea it
has the "time out" and basic exceptions done.   I am
slowly digging into the samples, but if you think any
of the code from Sun is good to checkout please let me
know.

btw, http://rxtx.qbang.org/wiki/index.php/Examples/
was very helpful, wish there are more examples.

thank you,

    Bob


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Mon Jun 19 15:55:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT)
Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good
 place to start?
In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>
References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606191542260.14139@www>

> I am
> slowly digging into the samples, but if you think any
> of the code from Sun is good to checkout please let me
> know.
>

I think NullDriver.java was an example stub driver for implementing 
something like rxtx.  It has been a while.  Unless they have been updated, 
you will find the examples are very dated.  You can look at how they use 
the port but avoid the GUI and hard coded variables (number of ports for 
instance).

There was no Swing and nobody knew what requirements today's compilers 
would make on code.  The examples worked fine with jdk 1.1 but times have 
changed.

--
Trent Jarvi
tjarvi at qbang.org


From tropicsu at hotmail.com  Mon Jun 19 19:49:08 2006
From: tropicsu at hotmail.com (Yoke K)
Date: Tue, 20 Jun 2006 01:49:08 +0000
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
Message-ID: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>

An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/fa588f00/attachment-0012.html

From ajmas at sympatico.ca  Mon Jun 19 21:14:37 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Mon, 19 Jun 2006 23:14:37 -0400
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>
References: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>
Message-ID: <CA22AB2A-5712-458B-9984-68477C6042AF@sympatico.ca>

Regarding the PortInUseException, I had a similar issue and got
this response from the mailing list:

   http://mailman.qbang.org/pipermail/rxtx/Week-of- 
Mon-20060619/062838.html

Andre
On 19-Jun-06, at 21:49 , Yoke K wrote:

> Hi Andre, Joachim
>
> I have tried using /dev/tty.usbserial and also /dev/cu.usbserial  
> and it also reported error as  "gnu.io.PortInUseException".
>
> The iTegno modem works in windows environment. As I moving around  
> using my ibook and I need to get it work on MAC OS as well.
>
> >> INFO: SMSLib API for Java / v1.2.2
> >> INFO: Using port: /dev/tty.usbserial @ 115200 baud.
> >> INFO: JRE Version: 1.5.0_06
> >> INFO: JRE Impl Version: 1.5.0_06-64
> >> INFO: O/S: Mac OS X / ppc / 10.4.6
> >> INFO: Using Wavecom (Generic) AT handler.
>
> SendMessage(): Send a message.
> Using SMSLib API for Java v1.2.2
>
> Connecting ..... :
> >> INFO: CSerialDriver(): Connecting...
> Experimental: JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version = RXTX-2.1-7
> >> INFO: CSerialDriver(): Disconnecting...
> gnu.io.PortInUseException: Unknown Application
> at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354)
> at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1)
> at org.smslib.CService.connect(CService.java:197)
> at SendMessage.main(SendMessage.java:38)
>
> Thanks.
>
> - Jon
>
>
>
>
> ====================
>
> Hello Jon,
>
> From OSX's standpoint a symbolic link is not a device (as far as I
> know). What stops you from using tty.usbserial? Did you try hard-
> linking?
>
> Regards,
> Joachim
>
>
>
> From:  "Yoke K" <tropicsu at hotmail.com>
> To:  rxtx at qbang.org
> Subject:  RXTX-2.1-7 / MAC OS X / NoSuchPortException
> Date:  Sat, 17 Jun 2006 15:32:48 +0000
> >Hi,
> >
> >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to
> >work with MAC OS X.
> >I am using iTegno 3000 - USB GPRS Modem.
> >
> >Files in /dev and a symbolic link as follows:
> >
> >crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
> >crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
> >lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->
> >tty.usbserial
> >
> >In my SendMessage.java, I have this line:
> >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
> >
> >Appreciate any help ?
> >
> >- Jon
> >
> >
> >Errors as follows:
> >
> >>>INFO: SMSLib API for Java / v1.2.2
> >>>INFO: Using port: /dev/ttyS1 @ 56000 baud.
> >>>INFO: JRE Version: 1.5.0_06
> >>>INFO: JRE Impl Version: 1.5.0_06-64
> >>>INFO: O/S: Mac OS X / ppc / 10.4.6
> >>>INFO: Using Wavecom (Generic) AT handler.
> >
> >SendMessage(): Send a message.
> >  Using SMSLib API for Java v1.2.2
> >
> >Connecting ..... :
> >>>INFO: CSerialDriver(): Connecting...
> >Experimental:  JNI_OnLoad called.
> >Stable Library
> >=========================================
> >Native lib Version = RXTX-2.1-7
> >Java lib Version   = RXTX-2.1-7
> >>>INFO: CSerialDriver(): Disconnecting...
> >gnu.io.NoSuchPortException
> >        at
> >gnu.io.CommPortIdentifier.getPortIdentifier 
> (CommPortIdentifier.java:218)
> >        at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
> >        at org.smslib.CService.connect(CService.java:197)
> >        at SendMessage.main(SendMessage.java:38)
> >
> >_________________________________________________________________
> >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
> >
>
> Find love online with MSN Personals
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Tue Jun 20 02:35:24 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 10:35:24 +0200
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>

Hello everybody,

I have been fighting a bit with the javax.comm version of RXTX the  
last days. I am working on the README .OSX now and try to figure out  
which should be the "suggested" installation.

The facts:
------

- the "generic" comm.jar version of javax.comm which has been made re- 
available tries to load com.sun.comm.SolarisDriver
- this classname can be overridden ONLY by putting a file  
javax.comm.properties in {java.home}/lib
- if it is not overridden and SolarisDriver.class is not found  
CommPortIdentifier will be disfunctional (in particual it is not  
possible to add CommPort's via CommPortIdentifier.add).
- the license distributed with comm.jar does not allow the  
modification/addition of classes in javax.comm (however no mention of  
com.sun...)


What really bothers me is to suggest putting this config file in the  
"global" vm installation. This is particularly ugly on the Mac as  
there are several VM installations and the file may be forgotten.  
Additionally it may create versioning problems. I prefer an  
installation where all files are local to the application (even  
comm.jar).

In my opinion the ideal situation would be:
------

1) The author of a program compiles against javax.comm.
2a) For platforms supported by Sun the user is free to use the 3.0  
comm.jar download from Sun
2b) For platforms not supported by Sun the user adds RXTXComm.jar to  
the classpath of the application (and librxtxSerial.jnilib to the  
application directory). Also he will need the 2.0.3 generic comm.jar  
from Sun.
3) Nobody messes with the global VM installation.

Of course 2a) and 2b) could be handled by the author of the program  
via an appropriate installer. The author could also decide to always  
use RXTX and include the generic javax.comm classes as well as the  
RXTX classes in his application jar. [If he further uses an explicit  
call to System.load() he may even include the jnilib(s) in the jar,  
extract it (based on the platform name) at runtime to a temp file and  
load it from there.]


Suggested solution:
------

We only need to put the following class in the classpath BEFORE Suns  
comm.jar

   package com.sun.comm;
   public class SolarisDriver extends gnu.io.RXTXCommDriver {
   }

This is not "the pure art" (TM). It depends on an implementation  
detail of the generic driver. However, so does the  
javax.comm.properties file - as we have seen when Sun released 3.0.  
It has the following advantages:

- The "generic" javax.comm implementation will happily load this  
class as its primary driver.
- No javax.comm.properties file is required.
- This does not violate the javax.comm license agreement as there is  
no mention of the "com.sun.comm" package in this license agreement at  
all.
- Authors packaging comm.jar with their application can strip out all  
com.sun.comm classes from comm.jar


Please comment!

Joachim



From joachim at buechse.de  Tue Jun 20 02:50:36 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 10:50:36 +0200
Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar
Message-ID: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>

There has been some discussions about the best way to install RXTX  
and where to place files.

I suggest that,

- we include the native libraries for the most common operating  
systems (in a special version of) RXTXcomm.jar
- we add loader code which tries to extract and load the platform  
specific binary at runtime
- on failure the current mechanism remains as a fallback

Wether the current mechanism should have priority (ie loadLibrary  
before load) remains to be discussed.


The advantages of this solution are
  - users of RXTX do not need to worry about java/platform specific  
file placement.
  - authors of applications may fully merge RXTX into their  
application jar (which provides a double-clickable application for  
Windows and OSX, Linux?).

Please comment,
Joachim

PS: Of course the suggested solution is already possible today,  
however relatively few programmers know how to correctly extract a  
binary resource file via the class loader and load it as a native  
library.


From tjarvi at qbang.org  Tue Jun 20 03:58:12 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT)
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
Message-ID: <Pine.LNX.4.61.0606200335190.14139@www>

> 2a) For platforms supported by Sun the user is free to use the 3.0
> comm.jar download from Sun
> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to
> the classpath of the application (and librxtxSerial.jnilib to the
> application directory). Also he will need the 2.0.3 generic comm.jar
> from Sun.

As there are no plans to support CommAPI 3.0 due to the limitations in its 
implementation mentioned before, I would not recommend projects use Sun's 
3.0 comm.jar.  They will lose the freedom to chose their low level 
implementation by being locked into vendor specific modifications.

Projects should chose between platform neutrality in CommAPI 2.0 and 
reduced platform neutrality in commapi 3.0.  Projects should also strongly 
consider the fact that the 2.0 comm.jar targets only a reduced number of 
JVMs.

Projects can go with rxtx 2.1 or other packages but should probably only 
consider using Sun CommAPI with rxtx if they did so in the past.  They 
should take steps to no longer depend upon this option being available.

> Suggested solution:
> ------
>
> We only need to put the following class in the classpath BEFORE Suns
> comm.jar
>
>   package com.sun.comm;
>   public class SolarisDriver extends gnu.io.RXTXCommDriver {
>   }
>
> This is not "the pure art" (TM). It depends on an implementation
> detail of the generic driver. However, so does the
> javax.comm.properties file - as we have seen when Sun released 3.0.
> It has the following advantages:
>
> - The "generic" javax.comm implementation will happily load this
> class as its primary driver.
> - No javax.comm.properties file is required.
> - This does not violate the javax.comm license agreement as there is
> no mention of the "com.sun.comm" package in this license agreement at
> all.
> - Authors packaging comm.jar with their application can strip out all
> com.sun.comm classes from comm.jar
>

I would not encourage people to place packages in the com.sun.comm 
namespace.  Authors using Sun's commapi 2.0 should just realize it is 
greatly limited in practical utility and consider moving to something that 
isn't being rescued from EOL.

The primary focus of this release is projects previously depending upon 
Sun CommAPI + RXTX.  There are no plans at this time to provide future 
support in this arrangement due to technical incompatabilities we have no 
control over in commapi 3.0 and limited utility of Sun's generic comm.jar 
in commapi 2.0 offered.  Projects should be aware of this so they can make 
appropriate plans.

--
Trent Jarvi
tjarvi at qbang.org


From paul.klissner at sun.com  Tue Jun 20 05:24:00 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Tue, 20 Jun 2006 04:24:00 -0700
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
In-Reply-To: <Pine.LNX.4.61.0606200335190.14139@www>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
	<Pine.LNX.4.61.0606200335190.14139@www>
Message-ID: <4497DAD0.10803@sun.com>

Trent Jarvi wrote:
>> 2a) For platforms supported by Sun the user is free to use the 3.0
>> comm.jar download from Sun
>> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to
>> the classpath of the application (and librxtxSerial.jnilib to the
>> application directory). Also he will need the 2.0.3 generic comm.jar
>> from Sun.
> 
> As there are no plans to support CommAPI 3.0 due to the limitations in its 
> implementation mentioned before, I would not recommend projects use Sun's 
> 3.0 comm.jar.  They will lose the freedom to chose their low level 
> implementation by being locked into vendor specific modifications.
> 
> Projects should chose between platform neutrality in CommAPI 2.0 and 
> reduced platform neutrality in commapi 3.0.  Projects should also strongly 
> consider the fact that the 2.0 comm.jar targets only a reduced number of 
> JVMs.

Well, that's a little ambiguous because the API is the same
either way.  We're talking about Sun's implementation vs.
other implementations.
> 
> Projects can go with rxtx 2.1 or other packages but should probably only 
> consider using Sun CommAPI with rxtx if they did so in the past.  They 
> should take steps to no longer depend upon this option being available.

3.0 is platform centric because there is a need to add some
platform awareness to Sun's implementation, and the choices
for how to do that are limited by the constraints of the API,
as mentioned in the javax.comm 2.0.3 comm.jar download's README.

I am really advocating getting a JSR open (http://www.jcp.org)
to push a new comm API that is more pluggable, platform neutral
and addresses some of the deficiencies of the current API. Then
we can achieve the optimal of platform neutrality while
simulataneously allowing the API to flexibly adapt to
heterogeneous environments.

This is not a question of attitude, this is an issue of resources,
time and commitment.  The current owners of javax.comm within
Sun would like nothing better than to see the ideal reached for
the API and a model that will extend well beyond the foreseeable
future and work for the industry overall.



> 
>> Suggested solution:
>> ------
>>
>> We only need to put the following class in the classpath BEFORE Suns
>> comm.jar
>>
>>   package com.sun.comm;
>>   public class SolarisDriver extends gnu.io.RXTXCommDriver {
>>   }
>>
>> This is not "the pure art" (TM). It depends on an implementation
>> detail of the generic driver. However, so does the
>> javax.comm.properties file - as we have seen when Sun released 3.0.
>> It has the following advantages:
>>
>> - The "generic" javax.comm implementation will happily load this
>> class as its primary driver.
>> - No javax.comm.properties file is required.
>> - This does not violate the javax.comm license agreement as there is
>> no mention of the "com.sun.comm" package in this license agreement at
>> all.
>> - Authors packaging comm.jar with their application can strip out all
>> com.sun.comm classes from comm.jar
>>
> 
> I would not encourage people to place packages in the com.sun.comm 
> namespace.  Authors using Sun's commapi 2.0 should just realize it is 
> greatly limited in practical utility and consider moving to something that 
> isn't being rescued from EOL.
> 
> The primary focus of this release is projects previously depending upon 
> Sun CommAPI + RXTX.  There are no plans at this time to provide future 
> support in this arrangement due to technical incompatabilities we have no 
> control over in commapi 3.0 and limited utility of Sun's generic comm.jar 
> in commapi 2.0 offered.  Projects should be aware of this so they can make 
> appropriate plans.

Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86,
or need the powerful portmapping features in javax.com 3.0, or would like to
acquire the Interactive Serial Port Test utility.

-Paul


From paul.klissner at sun.com  Tue Jun 20 05:33:44 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Tue, 20 Jun 2006 04:33:44 -0700
Subject: [Rxtx] Suggested installation RXTX 2.0x...
In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
Message-ID: <4497DD18.70207@sun.com>

Joachim Buechse wrote:
> Hello everybody,
> 
> I have been fighting a bit with the javax.comm version of RXTX the  
> last days. I am working on the README .OSX now and try to figure out  
> which should be the "suggested" installation.
> 
> The facts:
> ------
> 
> - the "generic" comm.jar version of javax.comm which has been made re- 
> available tries to load com.sun.comm.SolarisDriver
> - this classname can be overridden ONLY by putting a file  
> javax.comm.properties in {java.home}/lib
> - if it is not overridden and SolarisDriver.class is not found  
> CommPortIdentifier will be disfunctional (in particual it is not  
> possible to add CommPort's via CommPortIdentifier.add).
> - the license distributed with comm.jar does not allow the  
> modification/addition of classes in javax.comm (however no mention of  
> com.sun...)
> 
> 
> What really bothers me is to suggest putting this config file in the  
> "global" vm installation. This is particularly ugly on the Mac as  
> there are several VM installations and the file may be forgotten.  
> Additionally it may create versioning problems. I prefer an  
> installation where all files are local to the application (even  
> comm.jar).
> 
> In my opinion the ideal situation would be:
> ------
> 
> 1) The author of a program compiles against javax.comm.
> 2a) For platforms supported by Sun the user is free to use the 3.0  
> comm.jar download from Sun
> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to  
> the classpath of the application (and librxtxSerial.jnilib to the  
> application directory). Also he will need the 2.0.3 generic comm.jar  
> from Sun.
> 3) Nobody messes with the global VM installation.
> 
> Of course 2a) and 2b) could be handled by the author of the program  
> via an appropriate installer. The author could also decide to always  
> use RXTX and include the generic javax.comm classes as well as the  
> RXTX classes in his application jar. [If he further uses an explicit  
> call to System.load() he may even include the jnilib(s) in the jar,  
> extract it (based on the platform name) at runtime to a temp file and  
> load it from there.]
> 

This was how the Sun implementation originated (I did not write
that code).  I completely agree, and I fixed the whole conf file
locating mechanism in 3.0 to avoid the problems youmentioned.
However, I was unaware of how RxTx was using Sun's implementation,
so I didn't architect it in such a way as to avoid namespace pollution
in the native space in for the backend provider.  In retrospect,
I should have done that differently just as a design principle,
but at this point I don't have the spare cycles to get that all
re-factored.  Further, I'm loathe to do it, because the whole
thing will still be an under-the-hood hack due to the constraints
of the API itself.

Paul





From brian at mbari.org  Tue Jun 20 10:23:54 2006
From: brian at mbari.org (Brian Schlining)
Date: Tue, 20 Jun 2006 09:23:54 -0700
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>


Hi Joachim,

> There has been some discussions about the best way to install RXTX
> and where to place files.
>
> I suggest that,
>
> - we include the native libraries for the most common operating
> systems (in a special version of) RXTXcomm.jar
> - we add loader code which tries to extract and load the platform
> specific binary at runtime
> - on failure the current mechanism remains as a fallback

I like your suggestion. However, my understanding is that in general  
the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH  
(Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to  
be loaded by the JVM. The alternative is to point to your native lib  
directory using -Djava.library.path=/my/dir/with/native/libs when you  
launch the JVM. So, I'm very interested to know how you're planning  
to work around this.

> PS: Of course the suggested solution is already possible today,
> however relatively few programmers know how to correctly extract a
> binary resource file via the class loader and load it as a native
> library.

So how do you use it to dynamically load a native lib? I've read that  
you can't really modify the java.library.path after the JVM has been  
launched. (http://forum.java.sun.com/thread.jspa? 
threadID=627890&tstart=90)

Thanks

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0021.html

From joachim at buechse.de  Tue Jun 20 09:20:29 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 17:20:29 +0200
Subject: [Rxtx] 2.0x in sync with 2.1x
Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>

I have added most of the changes from the 2.1 branch to the 2.0 branch.

This includes
  - correction of illegal javadoc comments
  - implementation errors in handling of Thread.interrupt in  
RXTXPort.java
  - MacOS X locking without lock files/special user groups
  - XCode project which builds a universal binary library
  - updated documentation for OSX

I have done some minimal testing (only G4).
[Trent: there are still some changes you made for specific baud  
rates. I will not sync this, as I can not test them. From my  
perspective we are ready for 2.08/2.18]

The updated documentation can be found in the file README.OSX. Here  
it is:

------------------------ Required files -----------------------

To use or compile RXTX 2.0.x you need to downlad the "generic"  
version (2.0.3)
of the javax.comm implementation from Sun. The zip you download  
contains an
archive comm.jar which is required:

- To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar

- To run the app you will need comm.jar in the classpath or in  
{java.lib.path}


------------------------ Installation on MacOSX -----------------------

WARNING: Please read this section until the end.

---
Preparation
---

You may want to spare your users the burden of modifying the global VM
installation. OSX has several different VM versions installed by  
default and
regular users will be unable to figure out which version will load your
application.

If you provide the class

package com.sun.comm;
public class SolarisDriver extends gnu.io.RXTXCommDriver {
}

and make sure, that it is present in the classpath before Suns  
"generic" comm.jar
your users can skip the following step:

Create a file named
    javax.comm.properties
in the directory
    /System/Library/Frameworks/JavaVM.framework/Home/lib/
which contains (only) the following line (no leading space):
    Driver=gnu.io.RXTXCommDriver



----
The unsafe way of using RXTX on OS X:
----

RXTX can be installed by putting the files
   libSerial.jnilib
   RXTXcomm.jar
   comm.jar
into the folder
   /Library/Java/Extensions

This is NOT RECOMMENDED as it creates versioning conflicts among  
applications.
However you may be forced to install it this way if an application  
was written
for Windows or Linux, requires RXTX and you are not able to change  
its starter.


----
The safe way of using RXTX on OS X:
----

Make sure that you have no (older) version of RXTX installed in
   /Library/Java/Extensions
   /System/Library/Java/Extensions
   /usr/lib/java

Put
   libSerial.jnilib
in the directory of the application (the JavaVM will find it there). Add
   RXTXComm.jar
   comm.jar
to the application classpath or include the classes in the  
application jar.
(Some applications already include the RXTX classes in their  
application jar,
in which case only the file libSerial.jnilib is required).


----
History
----

Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation  
of lockfiles
required special permissions for the user executing an application  
based on RXTX.
To simplify the setup RXTX came with an installer modifying group  
permissions
and installing RXTX in the global location /Library/Java/Extensions.  
However
this was prune to versioning conflicts and is no longer recommended.

--------------------- Build instructions for OSX XCode  
-------------------

contributed by Joachim Buechse <joachim at buechse.de>
original version by Dmitry Markman <dmarkman at mac.com>

System requirements for building:
MacOSX 10.4
XCode 2.3

   open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj
   choose libSerial.jnilib target
   build

After the build you will find RXTXcomm.jar and libSerial.jnilib files  
in the
directory build/Development.

In case you can't find RXTXcomm.jar build the RXTXcomm target manually.
In case of (serious) problems feel free to contact joachim at buechse.de .



From tjarvi at qbang.org  Tue Jun 20 22:01:45 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT)
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
Message-ID: <Pine.LNX.4.61.0606202127270.14139@www>

> ---
> Preparation
> ---
>
> You may want to spare your users the burden of modifying the global VM
> installation. OSX has several different VM versions installed by
> default and
> regular users will be unable to figure out which version will load your
> application.
>
> If you provide the class
>
> package com.sun.comm;
> public class SolarisDriver extends gnu.io.RXTXCommDriver {
> }
>
> and make sure, that it is present in the classpath before Suns
> "generic" comm.jar
> your users can skip the following step:

Hi Joachim

With regards to the above, I have not seen that we have Sun's OK to 
promote that.  I'm not very comfortable with the distribution 
documentation advocating this without Sun agreeing.

I see your point but I'd rather not actively promote putting classes in 
Sun's namespace without permission if you don't mind.  This isn't about 
what is in a license.

I'll go through the code tomorrow night.  It was a late night at work 
today.  There is also a w32 fix comming for people opening and closing 
multiple ports.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Wed Jun 21 01:56:45 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 21 Jun 2006 09:56:45 +0200
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <Pine.LNX.4.61.0606202127270.14139@www>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
	<Pine.LNX.4.61.0606202127270.14139@www>
Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>

Hello Trent,

I guess we will not get an explicit OK from Sun for such a hack. I  
think Paul has made it pretty clear, that he does not have the  
resources to modify the 2.x or 3.x code for the needs of RXTX. I'm  
not thrilled but OK with the current API. Hence I dont agree with  
Paul's idea to start a new JSR to fix the implementation - but that's  
mainly because I dont have the time to push it. According to their  
Readme Sun sees no business case in having cross platform support for  
javax.comm - that is sad but it's none of my business. However I  
prefer to program versus javax.comm in my projects as this gives an  
advanced user the chance to exchange the provider without access to  
the code.

I interpret Pauls reponse to my original "Request for comment" as a  
quiet acceptance of the hack I propose (he did respond, but not at  
all to the sun.comm namespace suggestion). This is certainly not  
something we should put into RXTXcomm.jar but hinting a work around  
for implementation errors should be allowed. That's why I've choosen  
the wording "You may want to spare" and "If you provide". The company  
I worked for has choosen similar hacks for years to fix bugs in swing  
for JDK1.1 applications. Those hacks were usually included in their  
own swingpatch.jar.

Having said all that - I do not take it as an insult if you remove  
the paragraph from the Readme. I appreciate that you notified me  
before. It would be interesting to hear some more opinions from the  
list members...

Best regards,
Joachim


On 21.06.2006, at 06:01, Trent Jarvi wrote:

>> ---
>> Preparation
>> ---
>>
>> You may want to spare your users the burden of modifying the  
>> global VM
>> installation. OSX has several different VM versions installed by
>> default and
>> regular users will be unable to figure out which version will load  
>> your
>> application.
>>
>> If you provide the class
>>
>> package com.sun.comm;
>> public class SolarisDriver extends gnu.io.RXTXCommDriver {
>> }
>>
>> and make sure, that it is present in the classpath before Suns
>> "generic" comm.jar
>> your users can skip the following step:
>
> Hi Joachim
>
> With regards to the above, I have not seen that we have Sun's OK to
> promote that.  I'm not very comfortable with the distribution
> documentation advocating this without Sun agreeing.
>
> I see your point but I'd rather not actively promote putting  
> classes in
> Sun's namespace without permission if you don't mind.  This isn't  
> about
> what is in a license.
>
> I'll go through the code tomorrow night.  It was a late night at work
> today.  There is also a w32 fix comming for people opening and closing
> multiple ports.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Wed Jun 21 02:03:33 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 21 Jun 2006 10:03:33 +0200
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
	<6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
Message-ID: <BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>

See System.load(String) [it's also mentioned under the URL you posted].

Regards,
Joachim


On 20.06.2006, at 18:23, Brian Schlining wrote:

> So how do you use it to dynamically load a native lib? I've read  
> that you can't really modify the java.library.path after the JVM  
> has been launched. (http://forum.java.sun.com/thread.jspa? 
> threadID=627890&tstart=90)
>
> Thanks
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From baris.ozkan at elikasu.com.tr  Wed Jun 21 07:58:06 2006
From: baris.ozkan at elikasu.com.tr (Baris)
Date: Wed, 21 Jun 2006 16:58:06 +0300
Subject: [Rxtx] RS 232 ..additional parameters
Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>

Hi,
 
Currently i am developing an application that requires to connect to a
remote rs232 device through  a dialup connection.
 
My problem is that the communication needs several more connection
parameters (i extracted that information from the vendor's dll , listed at
the end of the message)
 
I explored rxtx API and src files and could not find methods to set a
majority  of the parameters.
Am i missing any point or does rxtx is limited to soem standard set of
functionality(e.g. commAPI)? How  is it possible ,if i want to put some
extensions(???) to current rxtx implementation?
 
I am not very good at rs232 programming so excuse me if this message  is
boring one.
 
Thanx
 
Baris Ozkan
 
 
A Listing of Parameters:
 
 
typedef struct _DCB {

DWORD DCBlength; /* sizeof(DCB) */

DWORD BaudRate; /* Baudrate at which running */

DWORD fBinary: 1; /* Binary Mode (skip EOF check) */

DWORD fParity: 1; /* Enable parity checking */

DWORD fOutxCtsFlow:1; /* CTS handshaking on output */

DWORD fOutxDsrFlow:1; /* DSR handshaking on output */

DWORD fDtrControl:2; /* DTR Flow control */

DWORD fDsrSensitivity:1; /* DSR Sensitivity */

DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */

DWORD fOutX: 1; /* Enable output X-ON/X-OFF */

DWORD fInX: 1; /* Enable input X-ON/X-OFF */

DWORD fErrorChar: 1; /* Enable Err Replacement */

DWORD fNull: 1; /* Enable Null stripping */

DWORD fRtsControl:2; /* Rts Flow control */

DWORD fAbortOnError:1; /* Abort all reads and writes on Error */

DWORD fDummy2:17; /* Reserved */

WORD wReserved; /* Not currently used */

WORD XonLim; /* Transmit X-ON threshold */

WORD XoffLim; /* Transmit X-OFF threshold */

BYTE ByteSize; /* Number of bits/byte, 4-8 */

BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */

BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */

char XonChar; /* Tx and Rx X-ON character */

char XoffChar; /* Tx and Rx X-OFF character */

char ErrorChar; /* Error replacement char */

char EofChar; /* End of Input character */

char EvtChar; /* Received Event character */

WORD wReserved1; /* Fill for now. */

} DCB, *LPDCB;

typedef struct _COMMTIMEOUTS {

DWORD ReadIntervalTimeout; /* Maximum time between read chars. */

DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */

DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */

DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */

DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */

} COMMTIMEOUTS,*LPCOMMTIMEOUTS;

dcb.fOutX = FALSE;

dcb.fInX = FALSE;

dcb.fOutxCtsFlow = FALSE;

dcb.fBinary = TRUE;

dcb.fRtsControl = RTS_CONTROL_ENABLE;

SetCommState(hComm , &dcb ); 

COMMTIMEOUTS commTimeOut;

GetCommTimeouts(hComm, &commTimeOut );

commTimeOut.WriteTotalTimeoutMultiplier = 1; 

commTimeOut.WriteTotalTimeoutConstant = 18; 

// commTimeOut.ReadIntervalTimeout = 28; 

commTimeOut.ReadIntervalTimeout = 0; 

// commTimeOut.ReadTotalTimeoutMultiplier = 184; 

commTimeOut.ReadTotalTimeoutMultiplier = 300; 

// commTimeOut.ReadTotalTimeoutConstant = 1200;

commTimeOut.ReadTotalTimeoutConstant = 1200;

SetCommTimeouts(hComm, &commTimeOut);

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0021.html

From ajmas at sympatico.ca  Wed Jun 21 08:14:26 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Wed, 21 Jun 2006 10:14:26 -0400
Subject: [Rxtx] When is 2.18 planned for?
Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

Just curious as to know if there is a target date for 2.18?

Andre



From brian at mbari.org  Wed Jun 21 09:36:00 2006
From: brian at mbari.org (Brian Schlining)
Date: Wed, 21 Jun 2006 08:36:00 -0700
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
	<6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
	<BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>
Message-ID: <A21C9BC0-7894-4B08-AC82-44E11AB3D461@mbari.org>

Ha!!

I suppose I should read my own postings. ;-)

Thanks
B

On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote:

> See System.load(String) [it's also mentioned under the URL you  
> posted].
>
> Regards,
> Joachim
>
>
> On 20.06.2006, at 18:23, Brian Schlining wrote:
>
>> So how do you use it to dynamically load a native lib? I've read
>> that you can't really modify the java.library.path after the JVM
>> has been launched. (http://forum.java.sun.com/thread.jspa?
>> threadID=627890&tstart=90)

Brian Schlining
Software Engineer
http://www.mbari.org




From ajmas at sympatico.ca  Wed Jun 21 16:41:28 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Wed, 21 Jun 2006 18:41:28 -0400
Subject: [Rxtx] CVS build question
Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X:

 The JCL extension to RxTx requires comm.jar
 If you intend to use RxTx for commapi support comm.jar
 needs to be located in  /System/Library/Frameworks/JavaVM.framework/
  Versions/1.5/Home/lib/ext/comm.jar

I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me.

On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native).

Andre






From tjarvi at qbang.org  Wed Jun 21 18:00:04 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT)
Subject: [Rxtx] CVS build question
In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606211756310.14139@www>

On Wed, 21 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> Is the CVS repository meant to build for gnu.io or javax.comm? I ask 
> this, because I see the following when calling ./configure from MacOS X:
>
> The JCL extension to RxTx requires comm.jar
> If you intend to use RxTx for commapi support comm.jar
> needs to be located in  /System/Library/Frameworks/JavaVM.framework/
>  Versions/1.5/Home/lib/ext/comm.jar
>
> I am wanting to build for the gnu.io package, since I want to jump ahead 
> and see if the changes, intended for 2.18 for MacOS X, work for me.
>
> On a side note /Library/Java/Extensions should be included as a valid 
> search path for the JAR, since this is where Apple recommends placing 
> third party extensions (both Java and native).
>

rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel"
rxtx 2.0 src is obtained with "cvs checkout rxtx-devel"

rxtx 2.1 is a complete package in namespace gnu.io
rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 18:02:23 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT)
Subject: [Rxtx] When is 2.18 planned for?
In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606211800180.14139@www>

On Wed, 21 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> Just curious as to know if there is a target date for 2.18?
>

Hi Andre

"When it is ready" :)

Probably this weekend.  Maybe sooner.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 18:10:18 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT)
Subject: [Rxtx] RS 232 ..additional parameters
In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>
References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>
Message-ID: <Pine.LNX.4.61.0606211805010.14139@www>

On Wed, 21 Jun 2006, Baris wrote:

> Hi,
>
> Currently i am developing an application that requires to connect to a
> remote rs232 device through  a dialup connection.
>
> My problem is that the communication needs several more connection
> parameters (i extracted that information from the vendor's dll , listed at
> the end of the message)
>
> I explored rxtx API and src files and could not find methods to set a
> majority  of the parameters.
> Am i missing any point or does rxtx is limited to soem standard set of
> functionality(e.g. commAPI)? How  is it possible ,if i want to put some
> extensions(???) to current rxtx implementation?
>
> I am not very good at rs232 programming so excuse me if this message  is
> boring one.
>
> Thanx
>

Hi Baris

> typedef struct _DCB {
> typedef struct _COMMTIMEOUTS {

These are all handled in termios.c.  It is possible to add extensions to 
rxtx 2.1.  It may well be that the defaults are the same for the variables 
not covered by the existing API.  You can dump the DCB and COMMTIMEOUTS 
from inside termios.c to compare.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 20:23:30 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT)
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
	<Pine.LNX.4.61.0606202127270.14139@www>
	<789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>
Message-ID: <Pine.LNX.4.61.0606212012210.14139@www>

> I'm
> not thrilled but OK with the current API. Hence I dont agree with
> Paul's idea to start a new JSR to fix the implementation - but that's
> mainly because I dont have the time to push it. According to their
> Readme Sun sees no business case in having cross platform support for
> javax.comm - that is sad but it's none of my business. However I
> prefer to program versus javax.comm in my projects as this gives an
> advanced user the chance to exchange the provider without access to
> the code.

Hi Joachim

With regards to the JSR, I think that would be Doug's call.  The effort I 
put in would have to be on my own time which would not be a great deal.  I 
could help things go smoothly but thats not the same as pushing something 
through.

--
Trent Jarvi
tjarvi at qbang.org



From vt at freehold.crocodile.org  Wed Jun 21 21:05:22 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Wed, 21 Jun 2006 20:05:22 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
Message-ID: <449A08F2.3020106@freehold.crocodile.org>

Hello all,

I know this question may belong to JSR lists, but since all interested 
parties are here, I thought I just ask this question here, again...

A while ago I run into a problem and wrote a rant, here: 
http://servomaster.sourceforge.net/dev/serial-usb.html
At the time of writing I didn't think of adding another possible 
solution - changing the CommAPI specs to support removable devices. 
Apparently, Serial/USB bridges are here to stay, and this issue has to 
be addressed.

Wonder if anything changed since, and any abstractions for supporting 
removable devices made it into current or future Java CommAPI drafts - 
Paul, any comments?

--vt



From joachim at buechse.de  Thu Jun 22 01:59:54 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 22 Jun 2006 09:59:54 +0200
Subject: [Rxtx] CVS build question
In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de>

Hello Andre,

I am not sure how well the configure/make mechanism will work on OSX.  
I know that a while ago some contributors tried to get configure/make  
working on OSX but from comments I found in the readmes this work was  
only partially successfull. For compilation on OSX we have used the  
ProjectBuilder/XCode projects you can find in MACOSX_IDE.

Regarding the  ./configure comment:
RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config  
file javax.comm.properties. The later MUST reside in {java.home}/lib.  
As the two only work together putting comm.jar into  /Library/Java/ 
Extensions  and hence making it available to all current and future  
VM installations will only add to confusion.

Regards,
Joachim

On 22.06.2006, at 00:41, Andre-John Mas wrote:

> Hi,
>
> Is the CVS repository meant to build for gnu.io or javax.comm? I  
> ask this, because I see the following when calling ./configure from  
> MacOS X:
>
>  The JCL extension to RxTx requires comm.jar
>  If you intend to use RxTx for commapi support comm.jar
>  needs to be located in  /System/Library/Frameworks/JavaVM.framework/
>   Versions/1.5/Home/lib/ext/comm.jar
>
> I am wanting to build for the gnu.io package, since I want to jump  
> ahead and see if the changes, intended for 2.18 for MacOS X, work  
> for me.
>
> On a side note /Library/Java/Extensions should be included as a  
> valid search path for the JAR, since this is where Apple recommends  
> placing third party extensions (both Java and native).
>
> Andre
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Thu Jun 22 02:51:05 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 22 Jun 2006 10:51:05 +0200
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449A08F2.3020106@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>

Hello Vadim,

I think that your rant is to the point. However it is a bit like  
saying that Windows is at the source of email degradation and the  
only solution is to have users switch to safer operating systems.

I don't see how javax.comm or RXTX can address the problems you  
mention. Of course it would be super cool if javax.comm could magicly  
find the "matching" usb-device and query it's configuration via the  
usb protocol - however this magic (mapping /dev/xyz to its underlying  
USB device) is not supported by any kernel APIs I am aware of. It  
could be supported via POSSIX ioctl calls but then you should address  
your rant to the POSSIX group...

So for the time beeing it's either up to the virtual comm port driver  
to provide a usefull name under /dev/ or to the user choosing the  
right port to use. One example of a smart(er) com port driver is the  
KDDI driver for OSX, which will create device names like "/dev/ 
cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- 
encoded into the bridge chip. The same driver for windows also has  
some options allowing it in theory to recreate the same COMx every  
time a device is plugged/unplugged.

For most industrial applications however it will be up to the user to  
choose the right port (without getting a lot of help doing so).

Probing serial ports can go wrong, that's right. However any serial  
device developper would be well adviced to implement a basic set of  
Hayes AT modem commands (be it a modem or not). Especially AT I0.  
Anyone failing to do so risks that the users favourite TCP/PPP/FAX  
application or stack will kill the device in short time.

Best regards,
Joachim


On 22.06.2006, at 05:05, Vadim Tkachenko wrote:

> Hello all,
>
> I know this question may belong to JSR lists, but since all interested
> parties are here, I thought I just ask this question here, again...
>
> A while ago I run into a problem and wrote a rant, here:
> http://servomaster.sourceforge.net/dev/serial-usb.html
> At the time of writing I didn't think of adding another possible
> solution - changing the CommAPI specs to support removable devices.
> Apparently, Serial/USB bridges are here to stay, and this issue has to
> be addressed.
>
> Wonder if anything changed since, and any abstractions for supporting
> removable devices made it into current or future Java CommAPI drafts -
> Paul, any comments?
>
> --vt
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From vt at freehold.crocodile.org  Thu Jun 22 13:16:03 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 12:16:03 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
Message-ID: <20060622191603.GA17487@freehold.crocodile.org>

Hello Joachim,

> I think that your rant is to the point. However it is a bit like  
> saying that Windows is at the source of email degradation and the  
> only solution is to have users switch to safer operating systems.

I guess the problem is that the rant itself is obsolete and has to be
updated according to latest developments. At the time of writing there
weren't that many bridges around, and the trend didn't manifest itself as it
does now.

> I don't see how javax.comm or RXTX can address the problems you  
> mention.

I would agree that javax.comm won't be able to address the problem, at least
in the short run. As for RxTx - well, nobody prevents it from being a
superset of CommAPI specification, right? RxTx being the de-facto standard
for quite a few platforms, I'd daresay the standard may follow.

> Of course it would be super cool if javax.comm could magicly find the
> "matching" usb-device and query it's configuration via the usb protocol -
> however this magic (mapping /dev/xyz to its underlying USB device) is not
> supported by any kernel APIs I am aware of. It could be supported via
> POSSIX ioctl calls but then you should address your rant to the POSSIX
> group...

As a matter of fact, my bigger concern is addressing the fact that a serial
device can now be removable. This hasn't been the case before, and it
clearly is now. Regarding the above, well, I guess if we accept this fact,
we also need to accept the fact that we need at least rudimentary means of
identification of a serial device. For the USB case, it would usually be the
vendor/product ID, plus possible serial number - but it is irrelevant what
exactly the identifying information is, as long as it allows to identify the
device.

A paradigm shift is required, this is what I wanted to say. Serial devices
can be removed and replaced, it's now our turn to learn to deal with it.

> Joachim

--vt


From jredman at ergotech.com  Thu Jun 22 13:41:44 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 13:41:44 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
Message-ID: <449AF278.6000903@ergotech.com>


Vadim Tkachenko wrote:
> A paradigm shift is required, this is what I wanted to say. Serial devices
> can be removed and replaced, it's now our turn to learn to deal with it.

The removal if the serial port hardly significantly different from the 
removal of the device attached to the serial port.   Different, 
slightly, but not a "paradigm shift".

And yes, someone could unplug a USB serial device and plug it into a 
different USB port so that it has a different name/number, but they 
could do that with the device itself, move it from com1 to com2.

Am I missing something?

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 13:57:27 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 12:57:27 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449AF278.6000903@ergotech.com>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
Message-ID: <20060622195727.GA20247@freehold.crocodile.org>

On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote:
> 
> Vadim Tkachenko wrote:
> > A paradigm shift is required, this is what I wanted to say. Serial devices
> > can be removed and replaced, it's now our turn to learn to deal with it.
> 
> The removal if the serial port hardly significantly different from the 
> removal of the device attached to the serial port.   Different, 
> slightly, but not a "paradigm shift".
> 
> And yes, someone could unplug a USB serial device and plug it into a 
> different USB port so that it has a different name/number, but they 
> could do that with the device itself, move it from com1 to com2.
> 
> Am I missing something?

Yes, the fact that they could unplug a device A and plug a device B. With
the introduction of the concept of removability, the notion of the serial
port itself is not as important anymore, but the notion of the unique device
identifier is.

Consider a situation: long running system (enterprise HVAC, tens of nodes,
tens of thousands square feet area, hundreds of thousand dollars worth of
equipment being conditioned, can't shut down), serial/usb device fails, is
replaced by an identical device with a different serial #.

A little bit farfetched, but hopefully highlighting the point I'm trying to
make.

> Jim

--vt


From jredman at ergotech.com  Thu Jun 22 14:37:38 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 14:37:38 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>	<20060622191603.GA17487@freehold.crocodile.org>	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
Message-ID: <449AFF92.8080003@ergotech.com>


Vadim Tkachenko wrote:
>>
>> Am I missing something?
> 
> Yes, the fact that they could unplug a device A and plug a device B. With
> the introduction of the concept of removability, the notion of the serial
> port itself is not as important anymore, but the notion of the unique device
> identifier is.

Serial devices are always removable.  I could unplug _serial_ device A 
and plug in _serial_ device B.  We have systems running with two RS485 
ports, one talks to a Modbus PLC network one to a number of drives on a 
proprietary protocol.  If you plug the wrong DB9 into the wrong port the 
application doesn't work.

If you dangle a USB 485 converter on the end of the DB9 you've just 
moved the problem from RS485 to USB, but the problem/effect is the same.

> 
> Consider a situation: long running system (enterprise HVAC, tens of nodes,
> tens of thousands square feet area, hundreds of thousand dollars worth of
> equipment being conditioned, can't shut down), serial/usb device fails, is
> replaced by an identical device with a different serial #.
> 
> A little bit farfetched, but hopefully highlighting the point I'm trying to
> make.

Nothing's changed.  If I had a 4 port ISA board and plugged it into my 
new shiny '386 machine.  I could have com ports 9-12.  If I took a board 
off the shelf and didn't set the jumpers, I would have com ports 3-6.

The problem's the same.  If you replace with identical product then the 
com ports  will be the same - no software changes required.  If you 
replace one piece of hardware with hardware from a different 
manufacturer, then the naming/numbering may change.  You're physically 
changing the system, so may reasonably expect to have to make a software 
change.  RXTX actually handles this situation quite well with the -D 
command line option.  (My experience has generally been that the port 
number depends more on the USB port used than the hardware - so the 
chances are even with a hardware change the port number/name will be the 
same.)

Slightly Off Topic - there is a reason why industrial users will pay a 
premium for continued availability of hardware.  Yes you can mail-order 
a $10 USB converter and it will work, but there's no guarantee that the 
next time you buy the same part number from the same vendor it will be 
the same.  The industrial vendors will charge you $100+ for the same 
item, but it will be the same every time you buy it for the next 5 to 10 
years.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 14:37:19 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 13:37:19 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
Message-ID: <20060622203719.GA22521@freehold.crocodile.org>

Hello again,

And while I'm at it, why don't just say this: give me one good reason to
write 3+ different ways of handling removable devices, one for USB, one for
FireWire, one for serial...

I understand very well that this goes way beyond the scope of RxTx and
CommAPI and will require cooperation between them and javax.usb and whatever
JSR is responsible for FireWire implementation - but the end result is well
worth it. Abstract out and generalize arrival/departure/monitoring/discovery
API, provide protocol specific extensions for each, live happily ever after.

--vt


On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote:
> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote:
> > 
> > Vadim Tkachenko wrote:
> > > A paradigm shift is required, this is what I wanted to say. Serial devices
> > > can be removed and replaced, it's now our turn to learn to deal with it.
> > 
> > The removal if the serial port hardly significantly different from the 
> > removal of the device attached to the serial port.   Different, 
> > slightly, but not a "paradigm shift".
> > 
> > And yes, someone could unplug a USB serial device and plug it into a 
> > different USB port so that it has a different name/number, but they 
> > could do that with the device itself, move it from com1 to com2.
> > 
> > Am I missing something?
> 
> Yes, the fact that they could unplug a device A and plug a device B. With
> the introduction of the concept of removability, the notion of the serial
> port itself is not as important anymore, but the notion of the unique device
> identifier is.
> 
> Consider a situation: long running system (enterprise HVAC, tens of nodes,
> tens of thousands square feet area, hundreds of thousand dollars worth of
> equipment being conditioned, can't shut down), serial/usb device fails, is
> replaced by an identical device with a different serial #.
> 
> A little bit farfetched, but hopefully highlighting the point I'm trying to
> make.
> 
> > Jim
> 
> --vt
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx


From jredman at ergotech.com  Thu Jun 22 15:13:49 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 15:13:49 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>	<20060622191603.GA17487@freehold.crocodile.org>	<449AF278.6000903@ergotech.com>	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
Message-ID: <449B080D.9080208@ergotech.com>


Vadim Tkachenko wrote:
> Hello again,
> 
> And while I'm at it, why don't just say this: give me one good reason to
> write 3+ different ways of handling removable devices, one for USB, one for
> FireWire, one for serial...

You don't, they're all the same "I have lost communication with my 
serial device".

The only thing you could really do is improve error reporting by knowing 
the exact sub-system.  ("Device X which is/was attached to USB port Y is 
no longer functioning, please check the USB ports, the device, the 
cables and anything else you can think of that may be a cause of 
failure.")  That just requires an intelligent description of the port.

> I understand very well that this goes way beyond the scope of RxTx and
> CommAPI and will require cooperation between them and javax.usb and whatever
> JSR is responsible for FireWire implementation - but the end result is well
> worth it. Abstract out and generalize arrival/departure/monitoring/discovery
> API, provide protocol specific extensions for each, live happily ever after.

There's a huge list of pseudo-serial devices each with a different set 
of requirements, Bluetooth, RFC 2217, a host of proprietary systems, 
etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I 
have no clue how you'd implement them in a general/cross platform sense.

You haven't convinced me (and only me, others may see something that I 
don't, I'm not speaking for them) that this mechanism can be implemented 
in any practical sense.  That is, that the implementation could be wide 
enough to be consider generally available in RXTX regardless of the 
serial port implementation, platform, etc..  However, if you can come up 
with a general design and a reference implementation for one subsystem, 
I'd like to see it and might get on board.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 15:40:55 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 14:40:55 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449B080D.9080208@ergotech.com>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
Message-ID: <20060622214055.GA25497@freehold.crocodile.org>

On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote:
> 
> Vadim Tkachenko wrote:
> > Hello again,
> > 
> > And while I'm at it, why don't just say this: give me one good reason to
> > write 3+ different ways of handling removable devices, one for USB, one for
> > FireWire, one for serial...
> 
> You don't, they're all the same "I have lost communication with my 
> serial device".

"I have lost communication with my ${protocol} device".

> The only thing you could really do is improve error reporting by knowing 
> the exact sub-system.  ("Device X which is/was attached to USB port Y is 
> no longer functioning, please check the USB ports, the device, the 
> cables and anything else you can think of that may be a cause of 
> failure.")

"Device ${id} which is/was attached to ${protocol} port ${port} is no longer
functioning, please check the ${protocol} ports, the device, the
${protocol_media} and anything else you can think of that may be a cause of
failure".

>  That just requires an intelligent description of the port.

Agree absolutely.

> > I understand very well that this goes way beyond the scope of RxTx and
> > CommAPI and will require cooperation between them and javax.usb and whatever
> > JSR is responsible for FireWire implementation - but the end result is well
> > worth it. Abstract out and generalize arrival/departure/monitoring/discovery
> > API, provide protocol specific extensions for each, live happily ever after.
> 
> There's a huge list of pseudo-serial devices each with a different set 
> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, 
> etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I 
> have no clue how you'd implement them in a general/cross platform sense.

That's because some of the protocols were created decades ago when
autoconfiguration wasn't even conceived, much less practical. RS232/RS485
don't have a clue about identity discovery, and even capabilities discovery
beyond obvious 8N1 etc.

I agree that today all these protocols have generally incompatible
strategies for handling the situations I'm trying to address, but there's
nothing that says it's not an oversight. Besides, we're dealing with the
devices at a level of abstraction that allows some simplifications and
generalizations, at least part of the time - unless it's the protocol
specific features we're dealing with.

> You haven't convinced me (and only me, others may see something that I 
> don't, I'm not speaking for them) that this mechanism can be implemented 
> in any practical sense.  That is, that the implementation could be wide 
> enough to be consider generally available in RXTX regardless of the 
> serial port implementation, platform, etc..  However, if you can come up 
> with a general design and a reference implementation for one subsystem, 
> I'd like to see it and might get on board.

Actually, I wasn't even thinking about all this stuff when I wrote the first
message on the subject :) Now that you mention it - well, I'm not sure I can
chew the piece I just tried to bite in reasonable amount of time.

How do you eat an elephant? One bite at a time. If we could agree that a
small step in the specification is acceptable at this time, and express
further intentions, things may start happening.

To put it succinctly:

- Concept of a "port" should be augmented with a concept of a "device". A
device may be attached to a port in an implicit or explicit way.
- Implicitly connected device is exactly what the current scope of the
specification covers. No new functionality is offered.
- Explicitly connected device supports detachable device semantics, just as
other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a
few).
- The input and output streams are not properties of a port now, but
properties of the device attached to the port.
- A mechanism to allow listening for device arrivals and departures must be
made available.

That's it, off the top of my head.

I understand that this goes completely against current javax.comm specs, but
an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be
difficult to implement without disrupting javax.comm compatibility.

One concern is how to deal with the device identity - but there's no general
way of dealing with this at this time, devices may or may not offer identity
discovery.

> Jim

--vt


From joachim at buechse.de  Fri Jun 23 02:12:43 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 23 Jun 2006 10:12:43 +0200
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
Message-ID: <CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>

Hello++ Vadim,

I would like to repeat that your request is best addressed to the  
POSSIX standardization group - or maybe the BSD/Linux maintainers. If  
you convince the BSD or Linux guys to add this kind of functionality  
(they can as most of there VCP drivers are open source), there is a  
certain chance that other vendors will pick it up. I assure you that  
RXTX will happily provide this functionality once it's possible - I'm  
sure there is more than one maintainer that would love to add it.  
Having this concept penetrate the market may take some years though.

SHORT: The solution you would like to see could be added to the API  
but it can not be implemented (at least not on the platforms I know).  
There are currently no hooks in the kernel that allow you to discover  
"the device" or even the "means of connection" based on an existing  
"device file descriptor" ie COM-port or /dev/... entry. The name  
mapping of the device is handled by the virtual com port driver of  
the device. Unless you are suggesting RXTX should reimplement virtual  
com port drivers for all usb/serial bridges out there your request is  
understandable from a users viewpoint but simply not realizable. It's  
like asking that the Socket api should identify the computer behind  
an IP address (ie by its Ethernet address). While this COULD be  
implemented in TCP/IP, it IS not, and hence there is no point adding  
such a function to the Socket API.

The current trend for USB/Bluetooth/Irda/etc connected devices is  
going away from serial port abstraction towards RPC (ie the drivers  
provide a device specific or device class specific driver that  
provides an application level api to the device functions). The line  
level protocol is often not even published.

Best regards,
Joachim

On 22.06.2006, at 23:40, Vadim Tkachenko wrote:

> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote:
>>
>> Vadim Tkachenko wrote:
>>> Hello again,
>>>
>>> And while I'm at it, why don't just say this: give me one good  
>>> reason to
>>> write 3+ different ways of handling removable devices, one for  
>>> USB, one for
>>> FireWire, one for serial...
>>
>> You don't, they're all the same "I have lost communication with my
>> serial device".
>
> "I have lost communication with my ${protocol} device".
>
>> The only thing you could really do is improve error reporting by  
>> knowing
>> the exact sub-system.  ("Device X which is/was attached to USB  
>> port Y is
>> no longer functioning, please check the USB ports, the device, the
>> cables and anything else you can think of that may be a cause of
>> failure.")
>
> "Device ${id} which is/was attached to ${protocol} port ${port} is  
> no longer
> functioning, please check the ${protocol} ports, the device, the
> ${protocol_media} and anything else you can think of that may be a  
> cause of
> failure".
>
>>  That just requires an intelligent description of the port.
>
> Agree absolutely.
>
>>> I understand very well that this goes way beyond the scope of  
>>> RxTx and
>>> CommAPI and will require cooperation between them and javax.usb  
>>> and whatever
>>> JSR is responsible for FireWire implementation - but the end  
>>> result is well
>>> worth it. Abstract out and generalize arrival/departure/ 
>>> monitoring/discovery
>>> API, provide protocol specific extensions for each, live happily  
>>> ever after.
>>
>> There's a huge list of pseudo-serial devices each with a different  
>> set
>> of requirements, Bluetooth, RFC 2217, a host of proprietary systems,
>> etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I
>> have no clue how you'd implement them in a general/cross platform  
>> sense.
>
> That's because some of the protocols were created decades ago when
> autoconfiguration wasn't even conceived, much less practical. RS232/ 
> RS485
> don't have a clue about identity discovery, and even capabilities  
> discovery
> beyond obvious 8N1 etc.
>
> I agree that today all these protocols have generally incompatible
> strategies for handling the situations I'm trying to address, but  
> there's
> nothing that says it's not an oversight. Besides, we're dealing  
> with the
> devices at a level of abstraction that allows some simplifications and
> generalizations, at least part of the time - unless it's the protocol
> specific features we're dealing with.
>
>> You haven't convinced me (and only me, others may see something  
>> that I
>> don't, I'm not speaking for them) that this mechanism can be  
>> implemented
>> in any practical sense.  That is, that the implementation could be  
>> wide
>> enough to be consider generally available in RXTX regardless of the
>> serial port implementation, platform, etc..  However, if you can  
>> come up
>> with a general design and a reference implementation for one  
>> subsystem,
>> I'd like to see it and might get on board.
>
> Actually, I wasn't even thinking about all this stuff when I wrote  
> the first
> message on the subject :) Now that you mention it - well, I'm not  
> sure I can
> chew the piece I just tried to bite in reasonable amount of time.
>
> How do you eat an elephant? One bite at a time. If we could agree  
> that a
> small step in the specification is acceptable at this time, and  
> express
> further intentions, things may start happening.
>
> To put it succinctly:
>
> - Concept of a "port" should be augmented with a concept of a  
> "device". A
> device may be attached to a port in an implicit or explicit way.
> - Implicitly connected device is exactly what the current scope of the
> specification covers. No new functionality is offered.
> - Explicitly connected device supports detachable device semantics,  
> just as
> other protocols do (USB, FireWire, Wireless USB, Bluetooth, to  
> mention a
> few).
> - The input and output streams are not properties of a port now, but
> properties of the device attached to the port.
> - A mechanism to allow listening for device arrivals and departures  
> must be
> made available.
>
> That's it, off the top of my head.
>
> I understand that this goes completely against current javax.comm  
> specs, but
> an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern )  
> won't be
> difficult to implement without disrupting javax.comm compatibility.
>
> One concern is how to deal with the device identity - but there's  
> no general
> way of dealing with this at this time, devices may or may not offer  
> identity
> discovery.
>
>> Jim
>
> --vt
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From vt at freehold.crocodile.org  Fri Jun 23 11:28:29 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Fri, 23 Jun 2006 10:28:29 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
	<CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
Message-ID: <20060623172829.GA5335@freehold.crocodile.org>

Hello Joachim,

> I would like to repeat that your request is best addressed to the POSSIX
> standardization group - or maybe the BSD/Linux maintainers. If you
> convince the BSD or Linux guys to add this kind of functionality (they can
> as most of there VCP drivers are open source), there is a certain chance
> that other vendors will pick it up. I assure you that RXTX will happily
> provide this functionality once it's possible - I'm sure there is more
> than one maintainer that would love to add it.

I realize this thing is bigger than RxTx itself, and I'm afraid it's too
global not to cause people to laugh before they think about it :)

> Having this concept penetrate the market may take some years though.

Well, I'm sure it'll get there, the only question is - when.

> SHORT: The solution you would like to see could be added to the API but it
> can not be implemented (at least not on the platforms I know).

I guess I'm concerned about the abstraction more than I'm concerned about
the implementation at this point.
  
> There are currently no hooks in the kernel that allow you to discover  
> "the device" or even the "means of connection" based on an existing  
> "device file descriptor" ie COM-port or /dev/... entry.

Well, I'm not so sure you need to keep the literal mapping from /dev
namespace to your device namespace. As long as you can consistently offer a
virtual serial device on top of a virtual serial port, it may be irrelevant
whether you can map it into /dev. The mapping is going be schitzofrenic
anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the
representation...

> The name mapping of the device is handled by the virtual com port driver
> of the device. Unless you are suggesting RXTX should reimplement virtual
> com port drivers for all usb/serial bridges out there your request is
> understandable from a users viewpoint but simply not realizable.

It's not so much a request but rather an offer of participation. I run a few
projects actively using serial communications, as well as USB device
drivers, in different degrees of readiness (Servomaster, Haywire, DIY
Zoning) - and it would be a perfect playground.

You mentioned above that this task is about two things: a) abstraction b)
implementation. I could start the abstraction part of it without changing
the current CommAPI, on top of it, as an adapter. Even if the removable
device semantics are not implemented, but offered, this is already a step
forward.

> It's like asking that the Socket api should identify the computer behind
> an IP address (ie by its Ethernet address). While this COULD be
> implemented in TCP/IP, it IS not, and hence there is no point adding such
> a function to the Socket API.

Thank you for bringing up this example - I guess this is just about the same
thing that I'd like to see. Socket transparently provides you with the
input/output streams, at the same time offering protocol level specifics to
you.

> The current trend for USB/Bluetooth/Irda/etc connected devices is going
> away from serial port abstraction towards RPC (ie the drivers provide a
> device specific or device class specific driver that provides an
> application level api to the device functions). The line level protocol is
> often not even published.

I can't say I'm that happy with it. The best (or, rather, worst) example is
suchlike support for the Phidget servo controller - zealous Linux developers
implemented kernel module support for it, completely hijacking a possibility
of using it on a different level (it's somewhat fixed by now, thankfully).

I believe that whenever an abstraction is offered, it must be made optional
and/or pluggable so it can be replaced by something more suited to the task.

The nature of Java applications is such that they'd probably care much more
about Java API offered, than about no matter how rich application level api
that is offered outside of Java. I've dealt with JNI adapters in the past,
and whereas they can be made reasonably stable, the very fact that you are
forced to deal with things that are not on the critical timing/memory path
and could've been done much easier in Java causes endless grief.

> Joachim

--vt


From lyon at docjava.com  Sat Jun 24 04:54:12 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Sat, 24 Jun 2006 06:54:12 -0400
Subject: [Rxtx] jsr
In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
	<CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
	<20060623172829.GA5335@freehold.crocodile.org>
Message-ID: <p060204a3c0c2c9dde4f8@[192.168.1.152]>

Hi All,
I have had some off-list discussion with Trent.
Opening up a JSR with Sun, as per Peters' suggestion
seems like a reasonable idea, to us.

Does anyone having any concerns about the JSR process
that they would like to raise?

Thanks!
  - Doug



From the.grey.lantern at gmail.com  Sat Jun 24 18:15:26 2006
From: the.grey.lantern at gmail.com (Craig Nicoll)
Date: Sun, 25 Jun 2006 01:15:26 +0100
Subject: [Rxtx] Cannot create virtual serial port
Message-ID: <a1221cc50606241715g2d1e2af6r747347dd4c20e997@mail.gmail.com>

Hello,

This is my first post on this mailing list and I hope someone can help me.

I am having great difficult establishing a virtual serial port for the
Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia
7600.

Every time I try to run the SendMessage program that comes with SMSLib, I
get the following exception: gnu.io.NoSuchPortException

The port names I have tried are:
rfcomm0
rfcomm
/dev/rfcomm0
/dev/rfcomm

This is what I have done so far:
Modified /etc/bluetooth/rfcomm.conf to include the address of my phone:

rfcomm0 {
# Automatically bind the device at startup
bind no;

# Bluetooth address of the device
device 00:0e:6d:7a:98:43;

# RFCOMM channel for the connection
channel 1;

# Description of the connection
comment "Example Bluetooth device";
}

I also tried running the following command: rfcomm bind /dev/rfcomm0

I have searched the mailing list archives and found this post where someone
had a very similar problem to me:
http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried
changing the system properties as suggested and it made no difference.

I have also been scouring Google all day to no avail.

I would be incredibly grateful if anyone could give me some tips.

Thank you,

Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060625/cfa6df35/attachment-0012.html

From tjarvi at qbang.org  Sun Jun 25 19:56:08 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT)
Subject: [Rxtx] Pending release
Message-ID: <Pine.LNX.4.61.0606251942460.15744@www>


With frustration, I was unable to get to the pending release this weekend.
The release should be comming this next week once things calm down.
The source is in CVS except for a fix for multiple ports in windows.

I had planned on doing the release this weekend but that was disrupted by 
my transportation failing in a spectacular fashion.

--
Trent Jarvi
tjarvi at qbang.org


From Pawan.Kharbanda at dot.state.co.us  Tue Jun 27 22:28:51 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 27 Jun 2006 22:28:51 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>

 Trent, 
   I have an application running in a cluster in linux environment and I
am using RXTX2.1.7 (final) with JDK1.5. The application opens and closes
serial comm ports every 30 seconds and exchanges datas. I have
experienced some of my Comm Ports are left hanging (I can see the
LCK..cufXX lock files under /var/lock folder). On putting the debugs I
found out that, it is stuck at a native call line 809 in RXTXPort.java
class (Please see the code snippet below). Can you help me explain what
this method does in the native code? Am I getting into some thread
deadlocks? Thanks in advance.

Pawan Kharbanda 


public void removeEventListener()
	{
		if (debug)
			z.reportln( "RXTXPort:removeEventListener()
called");
		waitForTheNativeCodeSilly();
		//if( monThread != null && monThread.isAlive() )
		if( monThreadisInterrupted == true )
		{
			z.reportln( "	RXTXPort:removeEventListener()
already interrupted");
			monThread = null;
			SPEventListener = null;
			return;
		}
		else if( monThread != null && monThread.isAlive() )
		{
			if (debug)
				z.reportln( "
RXTXPort:Interrupt=true");
			monThreadisInterrupted=true;
			/*
			   Notify all threads in this PID that something
is up
			   They will call back to see if its their
thread
			   using isInterrupted().
			*/
			if (debug)
				z.reportln( "	RXTXPort:calling
interruptEventLoop");
// LINE 809			interruptEventLoop( ); It never returns
out of this 
			
			if (debug)
				z.reportln( "	RXTXPort:calling
monThread.join()");
			try {
				monThread.join(1000);
			} catch (Exception ex) {
				/* yikes */
				ex.printStackTrace();
			}
			if (debug)
				z.reportln( "	RXTXPort:waiting on
isAlive()");
			while( monThread.isAlive() )
			{
				if ( debug )
					z.reportln( "	MonThread is
still alive!");
				try {
					monThread.join(1000);
					Thread.sleep( 1000 );
				} catch( Exception e ){} 
				//monThread.stop();
			}
			
		}
		if (debug)
			z.reportln( "	RXTXPort:calling gc()");
		monThread = null;
		SPEventListener = null;
		MonitorThreadLock = false;
		MonitorThreadAlive=false;
		monThreadisInterrupted=true;
		z.reportln( "RXTXPort:removeEventListener() returning");
	} 

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Sunday, June 25, 2006 7:56 PM
To: rxtx at qbang.org
Subject: [Rxtx] Pending release


With frustration, I was unable to get to the pending release this
weekend.
The release should be comming this next week once things calm down.
The source is in CVS except for a fix for multiple ports in windows.

I had planned on doing the release this weekend but that was disrupted
by my transportation failing in a spectacular fashion.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Wed Jun 28 04:17:29 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 28 Jun 2006 04:17:29 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606280406330.9561@www>



Hi Pawan

You may have found a deadlock but I've not seen on recently on linux.

If you can, please update from CVS.  This will have some close fixes. 
I'm running with the same code as is in CVS.  It is not perfect but I've 
not seen anything like you mention.  Be sure to set timeouts and 
thresholds on the port.  It may be that the port is waiting on pending io 
that never happens.  I think the CVS patches deal with this also but it 
looks like your in a better test environment to know for sure.

The exploded vehicle mentioned below is expected to be fixed today.  It 
was just a ninja small radiator hose.  The pressure test afterwards 
created its own set of problems.  Until this is resolved, I'm spending 
most of my free time commuting by bicycle.

On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>   I have an application running in a cluster in linux environment and I
> am using RXTX2.1.7 (final) with JDK1.5. The application opens and closes
> serial comm ports every 30 seconds and exchanges datas. I have
> experienced some of my Comm Ports are left hanging (I can see the
> LCK..cufXX lock files under /var/lock folder). On putting the debugs I
> found out that, it is stuck at a native call line 809 in RXTXPort.java
> class (Please see the code snippet below). Can you help me explain what
> this method does in the native code? Am I getting into some thread
> deadlocks? Thanks in advance.
>
> Pawan Kharbanda
>
>
> public void removeEventListener()
> 	{
> 		if (debug)
> 			z.reportln( "RXTXPort:removeEventListener()
> called");
> 		waitForTheNativeCodeSilly();
> 		//if( monThread != null && monThread.isAlive() )
> 		if( monThreadisInterrupted == true )
> 		{
> 			z.reportln( "	RXTXPort:removeEventListener()
> already interrupted");
> 			monThread = null;
> 			SPEventListener = null;
> 			return;
> 		}
> 		else if( monThread != null && monThread.isAlive() )
> 		{
> 			if (debug)
> 				z.reportln( "
> RXTXPort:Interrupt=true");
> 			monThreadisInterrupted=true;
> 			/*
> 			   Notify all threads in this PID that something
> is up
> 			   They will call back to see if its their
> thread
> 			   using isInterrupted().
> 			*/
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> interruptEventLoop");
> // LINE 809			interruptEventLoop( ); It never returns
> out of this
>
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> monThread.join()");
> 			try {
> 				monThread.join(1000);
> 			} catch (Exception ex) {
> 				/* yikes */
> 				ex.printStackTrace();
> 			}
> 			if (debug)
> 				z.reportln( "	RXTXPort:waiting on
> isAlive()");
> 			while( monThread.isAlive() )
> 			{
> 				if ( debug )
> 					z.reportln( "	MonThread is
> still alive!");
> 				try {
> 					monThread.join(1000);
> 					Thread.sleep( 1000 );
> 				} catch( Exception e ){}
> 				//monThread.stop();
> 			}
>
> 		}
> 		if (debug)
> 			z.reportln( "	RXTXPort:calling gc()");
> 		monThread = null;
> 		SPEventListener = null;
> 		MonitorThreadLock = false;
> 		MonitorThreadAlive=false;
> 		monThreadisInterrupted=true;
> 		z.reportln( "RXTXPort:removeEventListener() returning");
> 	}
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Sunday, June 25, 2006 7:56 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] Pending release
>
>
> With frustration, I was unable to get to the pending release this
> weekend.
> The release should be comming this next week once things calm down.
> The source is in CVS except for a fix for multiple ports in windows.
>
> I had planned on doing the release this weekend but that was disrupted
> by my transportation failing in a spectacular fashion.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From Pawan.Kharbanda at dot.state.co.us  Wed Jun 28 12:11:06 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Wed, 28 Jun 2006 12:11:06 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>

Trent,
    Again thanks for the reply. First of all I have Receive timeouts set
on all communications including Max no of bytes to expect during the
call. I have noticed the problem is during "closing the connection". I
am not sure if the RXTX is 100% thread-safe yet. There seems to be a
glitch in the native calls. I am sure I have the latest code I did the
update on the Version 2.1.7 from CVS, is this where the latest updates
are located, I have noticed another version in CVS "rxtx-devel".

Regards
Pawan Kharbanda

    

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Wednesday, June 28, 2006 4:17 AM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports



Hi Pawan

You may have found a deadlock but I've not seen on recently on linux.

If you can, please update from CVS.  This will have some close fixes. 
I'm running with the same code as is in CVS.  It is not perfect but I've
not seen anything like you mention.  Be sure to set timeouts and
thresholds on the port.  It may be that the port is waiting on pending
io that never happens.  I think the CVS patches deal with this also but
it looks like your in a better test environment to know for sure.

The exploded vehicle mentioned below is expected to be fixed today.  It
was just a ninja small radiator hose.  The pressure test afterwards
created its own set of problems.  Until this is resolved, I'm spending
most of my free time commuting by bicycle.

On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>   I have an application running in a cluster in linux environment and 
> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and 
> closes serial comm ports every 30 seconds and exchanges datas. I have 
> experienced some of my Comm Ports are left hanging (I can see the 
> LCK..cufXX lock files under /var/lock folder). On putting the debugs I

> found out that, it is stuck at a native call line 809 in RXTXPort.java

> class (Please see the code snippet below). Can you help me explain 
> what this method does in the native code? Am I getting into some 
> thread deadlocks? Thanks in advance.
>
> Pawan Kharbanda
>
>
> public void removeEventListener()
> 	{
> 		if (debug)
> 			z.reportln( "RXTXPort:removeEventListener()
called");
> 		waitForTheNativeCodeSilly();
> 		//if( monThread != null && monThread.isAlive() )
> 		if( monThreadisInterrupted == true )
> 		{
> 			z.reportln( "	RXTXPort:removeEventListener()
> already interrupted");
> 			monThread = null;
> 			SPEventListener = null;
> 			return;
> 		}
> 		else if( monThread != null && monThread.isAlive() )
> 		{
> 			if (debug)
> 				z.reportln( "
> RXTXPort:Interrupt=true");
> 			monThreadisInterrupted=true;
> 			/*
> 			   Notify all threads in this PID that something
is up
> 			   They will call back to see if its their
thread
> 			   using isInterrupted().
> 			*/
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> interruptEventLoop");
> // LINE 809			interruptEventLoop( ); It never returns
> out of this
>
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> monThread.join()");
> 			try {
> 				monThread.join(1000);
> 			} catch (Exception ex) {
> 				/* yikes */
> 				ex.printStackTrace();
> 			}
> 			if (debug)
> 				z.reportln( "	RXTXPort:waiting on
> isAlive()");
> 			while( monThread.isAlive() )
> 			{
> 				if ( debug )
> 					z.reportln( "	MonThread is
> still alive!");
> 				try {
> 					monThread.join(1000);
> 					Thread.sleep( 1000 );
> 				} catch( Exception e ){}
> 				//monThread.stop();
> 			}
>
> 		}
> 		if (debug)
> 			z.reportln( "	RXTXPort:calling gc()");
> 		monThread = null;
> 		SPEventListener = null;
> 		MonitorThreadLock = false;
> 		MonitorThreadAlive=false;
> 		monThreadisInterrupted=true;
> 		z.reportln( "RXTXPort:removeEventListener() returning");
> 	}
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf

> Of Trent Jarvi
> Sent: Sunday, June 25, 2006 7:56 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] Pending release
>
>
> With frustration, I was unable to get to the pending release this 
> weekend.
> The release should be comming this next week once things calm down.
> The source is in CVS except for a fix for multiple ports in windows.
>
> I had planned on doing the release this weekend but that was disrupted

> by my transportation failing in a spectacular fashion.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Wed Jun 28 12:26:21 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 28 Jun 2006 12:26:21 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606281222420.9561@www>


Hi Pawan

If you did a cvs update from the 2.1-7 tar ball, you have the current 
version.  All rxtx in CVS is under rxtx-devel.  The 2.1-7 just has -r
commapi-0-0-1.

You may well have found something.  I have seen win32 fail on closing 
ports but not linux that I can think of.  Your use is much different than 
I normally see too.

Could you give us more information on how we would reproduce this and the 
frequency?


On Wed, 28 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>    Again thanks for the reply. First of all I have Receive timeouts set
> on all communications including Max no of bytes to expect during the
> call. I have noticed the problem is during "closing the connection". I
> am not sure if the RXTX is 100% thread-safe yet. There seems to be a
> glitch in the native calls. I am sure I have the latest code I did the
> update on the Version 2.1.7 from CVS, is this where the latest updates
> are located, I have noticed another version in CVS "rxtx-devel".
>
> Regards
> Pawan Kharbanda
>
>
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Wednesday, June 28, 2006 4:17 AM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] Locked Ports
>
>
>
> Hi Pawan
>
> You may have found a deadlock but I've not seen on recently on linux.
>
> If you can, please update from CVS.  This will have some close fixes.
> I'm running with the same code as is in CVS.  It is not perfect but I've
> not seen anything like you mention.  Be sure to set timeouts and
> thresholds on the port.  It may be that the port is waiting on pending
> io that never happens.  I think the CVS patches deal with this also but
> it looks like your in a better test environment to know for sure.
>
> The exploded vehicle mentioned below is expected to be fixed today.  It
> was just a ninja small radiator hose.  The pressure test afterwards
> created its own set of problems.  Until this is resolved, I'm spending
> most of my free time commuting by bicycle.
>
> On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:
>
>> Trent,
>>   I have an application running in a cluster in linux environment and
>> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and
>> closes serial comm ports every 30 seconds and exchanges datas. I have
>> experienced some of my Comm Ports are left hanging (I can see the
>> LCK..cufXX lock files under /var/lock folder). On putting the debugs I
>
>> found out that, it is stuck at a native call line 809 in RXTXPort.java
>
>> class (Please see the code snippet below). Can you help me explain
>> what this method does in the native code? Am I getting into some
>> thread deadlocks? Thanks in advance.
>>
>> Pawan Kharbanda
>>
>>
>> public void removeEventListener()
>> 	{
>> 		if (debug)
>> 			z.reportln( "RXTXPort:removeEventListener()
> called");
>> 		waitForTheNativeCodeSilly();
>> 		//if( monThread != null && monThread.isAlive() )
>> 		if( monThreadisInterrupted == true )
>> 		{
>> 			z.reportln( "	RXTXPort:removeEventListener()
>> already interrupted");
>> 			monThread = null;
>> 			SPEventListener = null;
>> 			return;
>> 		}
>> 		else if( monThread != null && monThread.isAlive() )
>> 		{
>> 			if (debug)
>> 				z.reportln( "
>> RXTXPort:Interrupt=true");
>> 			monThreadisInterrupted=true;
>> 			/*
>> 			   Notify all threads in this PID that something
> is up
>> 			   They will call back to see if its their
> thread
>> 			   using isInterrupted().
>> 			*/
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> interruptEventLoop");
>> // LINE 809			interruptEventLoop( ); It never returns
>> out of this
>>
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> monThread.join()");
>> 			try {
>> 				monThread.join(1000);
>> 			} catch (Exception ex) {
>> 				/* yikes */
>> 				ex.printStackTrace();
>> 			}
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:waiting on
>> isAlive()");
>> 			while( monThread.isAlive() )
>> 			{
>> 				if ( debug )
>> 					z.reportln( "	MonThread is
>> still alive!");
>> 				try {
>> 					monThread.join(1000);
>> 					Thread.sleep( 1000 );
>> 				} catch( Exception e ){}
>> 				//monThread.stop();
>> 			}
>>
>> 		}
>> 		if (debug)
>> 			z.reportln( "	RXTXPort:calling gc()");
>> 		monThread = null;
>> 		SPEventListener = null;
>> 		MonitorThreadLock = false;
>> 		MonitorThreadAlive=false;
>> 		monThreadisInterrupted=true;
>> 		z.reportln( "RXTXPort:removeEventListener() returning");
>> 	}
>>
>> -----Original Message-----
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
>
>> Of Trent Jarvi
>> Sent: Sunday, June 25, 2006 7:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] Pending release
>>
>>
>> With frustration, I was unable to get to the pending release this
>> weekend.
>> The release should be comming this next week once things calm down.
>> The source is in CVS except for a fix for multiple ports in windows.
>>
>> I had planned on doing the release this weekend but that was disrupted
>
>> by my transportation failing in a spectacular fashion.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From Pawan.Kharbanda at dot.state.co.us  Wed Jun 28 15:42:49 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Wed, 28 Jun 2006 15:42:49 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>

Trent,
    I will try to explain how I am setup and will try to write you a
Sample code little later to reproduce this. On our system we have
DigiBoxes installed on the 2 Linux servers. Both of them have RXTX2.1-7
version installed with the JRE(1.5) and both the machines have the same
port mappings in gnu.io.rxtx.properties (Currently in the production
system I have 64 ports). This is how the system works:

1) A thick Map based client initiates a Action on the Device on the
field. One of the Thread Workers(Asynchronous Call) in the Cluster picks
up the request. 
2) Once the worker gets the request it locks the Device and
Communication port in the DB's(These are our persistent locks, because
most of the devices do one to one communication with the serial ports).
After that the worker (or Comm Server) opens up the connection and after
exchanging the information calls the "Close" and returns.
3) Once the connection is closed , the DB lock is removed on the comm
port and is made available to accept future calls. Here is where the
glitch is the Serial Comm Close method never returns due to the
deadlock. 

I have noticed that the deadlocks are very inconsistent, sometime it
happens right away as soon as Application server starts and sometimes I
don't see any deadlocks for days, but it happens for sure. 

Here is how you can test if you have resources/ test environment. Write
a program and try to open/close  different ports(I will say have a
minimum of four) randomly and very frequently(may be 30 seconds), I am
pretty sure you will see the deadlocks and it happens in the native call
to interrptEventLoop in RXTXPort.java in removeEventListener() method
call.

Also I have noticed that the JVM carshes (without any memrory errors or
JVM errors. Its just not there) when native call is made to eventLoop()
in run() method in MonitorThread inner class. I am still investigating
why this is happening, but at this point I can just tell you the
location. You might have a question How I am so sure about the location?
My application is configured with Log4J and I have enabled the debugs on
the RXTXPort.java, so every time my JVM dies I see these logs at the end
of the file.

"2006-06-28 15:27:15,183 INFO  [STDOUT] RXTXPort:RXTXPort(/dev/cub01)
called
2006-06-28 15:27:15,218 INFO  [STDOUT]
RXTXPort:MontitorThread:MonitorThread()
2006-06-28 15:27:15,219 INFO  [STDOUT] RXTXPort:MontitorThread:run()"

I surely do have a luxury of a testing environment(ports, devices etc.)
and can help you fix these problems? Please advise me how we can resolve
these issues.

Thanks 
Pawan Kharbanda
303-478-2991





-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Wednesday, June 28, 2006 12:26 PM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports


Hi Pawan

If you did a cvs update from the 2.1-7 tar ball, you have the current
version.  All rxtx in CVS is under rxtx-devel.  The 2.1-7 just has -r
commapi-0-0-1.

You may well have found something.  I have seen win32 fail on closing
ports but not linux that I can think of.  Your use is much different
than I normally see too.

Could you give us more information on how we would reproduce this and
the frequency?


On Wed, 28 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>    Again thanks for the reply. First of all I have Receive timeouts
set
> on all communications including Max no of bytes to expect during the
> call. I have noticed the problem is during "closing the connection". I
> am not sure if the RXTX is 100% thread-safe yet. There seems to be a
> glitch in the native calls. I am sure I have the latest code I did the
> update on the Version 2.1.7 from CVS, is this where the latest updates
> are located, I have noticed another version in CVS "rxtx-devel".
>
> Regards
> Pawan Kharbanda
>
>
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Wednesday, June 28, 2006 4:17 AM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] Locked Ports
>
>
>
> Hi Pawan
>
> You may have found a deadlock but I've not seen on recently on linux.
>
> If you can, please update from CVS.  This will have some close fixes.
> I'm running with the same code as is in CVS.  It is not perfect but
I've
> not seen anything like you mention.  Be sure to set timeouts and
> thresholds on the port.  It may be that the port is waiting on pending
> io that never happens.  I think the CVS patches deal with this also
but
> it looks like your in a better test environment to know for sure.
>
> The exploded vehicle mentioned below is expected to be fixed today.
It
> was just a ninja small radiator hose.  The pressure test afterwards
> created its own set of problems.  Until this is resolved, I'm spending
> most of my free time commuting by bicycle.
>
> On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:
>
>> Trent,
>>   I have an application running in a cluster in linux environment and
>> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and
>> closes serial comm ports every 30 seconds and exchanges datas. I have
>> experienced some of my Comm Ports are left hanging (I can see the
>> LCK..cufXX lock files under /var/lock folder). On putting the debugs
I
>
>> found out that, it is stuck at a native call line 809 in
RXTXPort.java
>
>> class (Please see the code snippet below). Can you help me explain
>> what this method does in the native code? Am I getting into some
>> thread deadlocks? Thanks in advance.
>>
>> Pawan Kharbanda
>>
>>
>> public void removeEventListener()
>> 	{
>> 		if (debug)
>> 			z.reportln( "RXTXPort:removeEventListener()
> called");
>> 		waitForTheNativeCodeSilly();
>> 		//if( monThread != null && monThread.isAlive() )
>> 		if( monThreadisInterrupted == true )
>> 		{
>> 			z.reportln( "	RXTXPort:removeEventListener()
>> already interrupted");
>> 			monThread = null;
>> 			SPEventListener = null;
>> 			return;
>> 		}
>> 		else if( monThread != null && monThread.isAlive() )
>> 		{
>> 			if (debug)
>> 				z.reportln( "
>> RXTXPort:Interrupt=true");
>> 			monThreadisInterrupted=true;
>> 			/*
>> 			   Notify all threads in this PID that something
> is up
>> 			   They will call back to see if its their
> thread
>> 			   using isInterrupted().
>> 			*/
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> interruptEventLoop");
>> // LINE 809			interruptEventLoop( ); It never returns
>> out of this
>>
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> monThread.join()");
>> 			try {
>> 				monThread.join(1000);
>> 			} catch (Exception ex) {
>> 				/* yikes */
>> 				ex.printStackTrace();
>> 			}
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:waiting on
>> isAlive()");
>> 			while( monThread.isAlive() )
>> 			{
>> 				if ( debug )
>> 					z.reportln( "	MonThread is
>> still alive!");
>> 				try {
>> 					monThread.join(1000);
>> 					Thread.sleep( 1000 );
>> 				} catch( Exception e ){}
>> 				//monThread.stop();
>> 			}
>>
>> 		}
>> 		if (debug)
>> 			z.reportln( "	RXTXPort:calling gc()");
>> 		monThread = null;
>> 		SPEventListener = null;
>> 		MonitorThreadLock = false;
>> 		MonitorThreadAlive=false;
>> 		monThreadisInterrupted=true;
>> 		z.reportln( "RXTXPort:removeEventListener() returning");
>> 	}
>>
>> -----Original Message-----
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On
Behalf
>
>> Of Trent Jarvi
>> Sent: Sunday, June 25, 2006 7:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] Pending release
>>
>>
>> With frustration, I was unable to get to the pending release this
>> weekend.
>> The release should be comming this next week once things calm down.
>> The source is in CVS except for a fix for multiple ports in windows.
>>
>> I had planned on doing the release this weekend but that was
disrupted
>
>> by my transportation failing in a spectacular fashion.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx 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 khattar31 at yahoo.com  Wed Jun 28 22:04:59 2006
From: khattar31 at yahoo.com (rahul khattar)
Date: Wed, 28 Jun 2006 21:04:59 -0700 (PDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
Message-ID: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>

Hi All,

I was looking at the src file on the last release.
I did notice a missing header file while trying to
compile the parallelport.dll. Would somebody be kind
enoughf to share the missing header file:
gnu_io_LPRPort.h

I am using MinGw to compile the same from Parinya
(which is an execellent tool)


Regards,
Rahul Khattar

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Thu Jun 29 03:43:53 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 03:43:53 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>
References: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606290341210.9561@www>

On Wed, 28 Jun 2006, rahul khattar wrote:

> Hi All,
>
> I was looking at the src file on the last release.
> I did notice a missing header file while trying to
> compile the parallelport.dll. Would somebody be kind
> enoughf to share the missing header file:
> gnu_io_LPRPort.h
>
> I am using MinGw to compile the same from Parinya
> (which is an execellent tool)
>

Hi Rahul

The gnu.io_LPRPort.h file is generated with javah.  You can see the 
command in the Makefile I presume.  You do not need rxtxParallel.dll to 
use w32 serial btw.

--
Trent Jarvi
tjarvi at qbang.org


From khattar31 at yahoo.com  Thu Jun 29 04:47:01 2006
From: khattar31 at yahoo.com (rahul khattar)
Date: Thu, 29 Jun 2006 03:47:01 -0700 (PDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606290341210.9561@www>
Message-ID: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>

Hi Trent 
I did notice this file is required in the source file
ParallelImp.c
on line 38

Attached the O/P 

Regards,
Rahul Khattar




--- Trent Jarvi <tjarvi at qbang.org> wrote:

> On Wed, 28 Jun 2006, rahul khattar wrote:
> 
> > Hi All,
> >
> > I was looking at the src file on the last release.
> > I did notice a missing header file while trying to
> > compile the parallelport.dll. Would somebody be
> kind
> > enoughf to share the missing header file:
> > gnu_io_LPRPort.h
> >
> > I am using MinGw to compile the same from Parinya
> > (which is an execellent tool)
> >
> 
> Hi Rahul
> 
> The gnu.io_LPRPort.h file is generated with javah. 
> You can see the 
> command in the Makefile I presume.  You do not need
> rxtxParallel.dll to 
> use w32 serial btw.
> 
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Error.zip
Type: application/x-zip-compressed
Size: 1746 bytes
Desc: 2948039066-Error.zip
Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060629/a5b6f783/Error-0021.bin

From tjarvi at qbang.org  Thu Jun 29 06:16:24 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 06:16:24 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606290614530.9561@www>

On Thu, 29 Jun 2006, rahul khattar wrote:

> Hi Trent
> I did notice this file is required in the source file
> ParallelImp.c
> on line 38
>
> Attached the O/P
>

The command to generate the .h file will be something like:

javah -classpath . -jni gnu.io.LPRPort

The makefile should have this.  There are several approaches to creating 
or using makefiles so I have no idea which one you used if any.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Thu Jun 29 06:20:51 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 06:20:51 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606290616420.9561@www>

> Here is how you can test if you have resources/ test environment. Write
> a program and try to open/close  different ports(I will say have a
> minimum of four) randomly and very frequently(may be 30 seconds), I am
> pretty sure you will see the deadlocks and it happens in the native call
> to interrptEventLoop in RXTXPort.java in removeEventListener() method
> call.

Hi Pawan

I'll try to find a way to reproduce this.  One thing to note is that you 
are using different kernel drivers (digi) to perform this task.  So I 
probably will not be able to reproduce the exact same environment.

In general, multiport kernel drivers have been tested far less than 
typical serial drivers.  This may or may not be an issue.

--
Trent Jarvi
tjarvi at qbang.org



From jhaysonn at gmail.com  Thu Jun 29 12:29:13 2006
From: jhaysonn at gmail.com (jhaysonn pathak)
Date: Thu, 29 Jun 2006 14:29:13 -0400
Subject: [Rxtx] RXTX install
Message-ID: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>

Hi Guys,

I'm doing trying to write a generative piece of Sonic Art using an EEG
plugged into a mac runnning Max/MSP.  I just recently discovered RXTX
drivers in my search for a piece of software that might give me more
output options for my EEG (I'm using the CEO from MindPeak).  I found
Bioera which uses RXTX drivers.  Thing is - I can't figure out how to
install RXTX correctly.

After I build the 'libSerial.jnilib' target inside of
'LibSerial.pbproj' I can't find the libSerial.jnilib file that
accompanies the RXTXcomm.jar nor do I know where to put them.

I also don't understand this part at the bottom of the OS X instructions at all:

"AFTER INSTALLATION VERY IMPORTANT
	check existence of the folder /var/spool/uucp
	if you don't have it create it with command
	sudo mkdir /var/spool/uucp
	permissions should be: drwxrwxr-x
	if they are not do command
	sudo chmod 775 /var/spool/uucp

	YOU should be a member of the uucp group
	you can check it with command
		niutil -readprop / /groups/uucp users
	you should see your name in output of the niutil command
	if you don't do following:
		sudo niutil -appendprop / /groups/uucp users <yourname>
			substitute  <yourname> with your user's name
			for example if your user name is peter:
				sudo niutil -appendprop / /groups/uucp users peter

	NOTES: RXTX.pkg should create uucp folder and insert your name  in
uucp group automatically"



I really appreciate any help that you guys can offer.  I've been
struggling with this for a while now as part of a research grant that
I was awarded.  Thanks again for the help.

Jhaysonn Pathak


From naranjo.manuel at gmail.com  Thu Jun 29 07:19:15 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 10:19:15 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606290614530.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www>
Message-ID: <44A3D353.6010605@gmail.com>

Speaking about Windows Support, I had seen that inside the 
rxtx-2.1-7-bins-r2 package inside Windows directory it says:
"i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will 
not make harm to anyone, and i'm almost sure that someone has noticed it 
before.
Cheers,
Manuel


From joachim at buechse.de  Thu Jun 29 13:25:16 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 29 Jun 2006 21:25:16 +0200
Subject: [Rxtx] RXTX install
In-Reply-To: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>
References: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>
Message-ID: <2A003E42-97E1-4237-8438-646BDE2E3961@buechse.de>

Hello Jhaysonn,

I assume you are trying to use the javax.comm version of RXTX.

Please use "cvs up" to update your download to the latest version of  
the repository. The latest version does not use lock files, so the  
mentioned process is no longer needed. Updating with CVS will also  
provide you with a new README.OSX file that should be simpler to  
understand.

You will find LibSerialUniversal.xcodeproj in MACOSX_IDE/Xcode. Put  
comm.jar (downloaded from Sun) into MACOSX_IDE/Xcode. Compile the  
library. You will find RXTXcomm.jar and librxtxSerial.jnilib in  
MACOSX_IDE/Xcode/build/Default

Best regards,
Joachim
---
Joachim B?chse
Softwarel?sungen und Beratung
Hadlaubsteig 2
CH-8006 Z?rich


On 29.06.2006, at 20:29, jhaysonn pathak wrote:

> Hi Guys,
>
> I'm doing trying to write a generative piece of Sonic Art using an EEG
> plugged into a mac runnning Max/MSP.  I just recently discovered RXTX
> drivers in my search for a piece of software that might give me more
> output options for my EEG (I'm using the CEO from MindPeak).  I found
> Bioera which uses RXTX drivers.  Thing is - I can't figure out how to
> install RXTX correctly.
>
> After I build the 'libSerial.jnilib' target inside of
> 'LibSerial.pbproj' I can't find the libSerial.jnilib file that
> accompanies the RXTXcomm.jar nor do I know where to put them.
>
> I also don't understand this part at the bottom of the OS X  
> instructions at all:
>
> "AFTER INSTALLATION VERY IMPORTANT
> 	check existence of the folder /var/spool/uucp
> 	if you don't have it create it with command
> 	sudo mkdir /var/spool/uucp
> 	permissions should be: drwxrwxr-x
> 	if they are not do command
> 	sudo chmod 775 /var/spool/uucp
>
> 	YOU should be a member of the uucp group
> 	you can check it with command
> 		niutil -readprop / /groups/uucp users
> 	you should see your name in output of the niutil command
> 	if you don't do following:
> 		sudo niutil -appendprop / /groups/uucp users <yourname>
> 			substitute  <yourname> with your user's name
> 			for example if your user name is peter:
> 				sudo niutil -appendprop / /groups/uucp users peter
>
> 	NOTES: RXTX.pkg should create uucp folder and insert your name  in
> uucp group automatically"
>
>
>
> I really appreciate any help that you guys can offer.  I've been
> struggling with this for a while now as part of a research grant that
> I was awarded.  Thanks again for the help.
>
> Jhaysonn Pathak
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From tjarvi at qbang.org  Thu Jun 29 19:30:00 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 19:30:00 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A3D353.6010605@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
Message-ID: <Pine.LNX.4.61.0606291923000.9561@www>

On Thu, 29 Jun 2006, Manuel Naranjo wrote:

> Speaking about Windows Support, I had seen that inside the
> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
> not make harm to anyone, and i'm almost sure that someone has noticed it
> before.

Hi Manuel

         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
     47421  01-30-06 00:23 
rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
     77759  03-01-06 12:01 
rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README


It looks normal to me.  There are no fancy tools used there :)

--
Trent Jarvi
tjarvi at qbang.org

From naranjo.manuel at gmail.com  Thu Jun 29 19:38:16 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 22:38:16 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606291923000.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com> <Pine.LNX.4.61.0606291923000.9561@www>
Message-ID: <44A48088.2040407@gmail.com>

> On Thu, 29 Jun 2006, Manuel Naranjo wrote:
> 
>> Speaking about Windows Support, I had seen that inside the
>> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
>> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
>> not make harm to anyone, and i'm almost sure that someone has noticed it
>> before.
> 
> Hi Manuel
> 
>         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
>         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
>     47421  01-30-06 00:23 
> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
>     77759  03-01-06 12:01 
> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
>       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README
> 
> 
> It looks normal to me.  There are no fancy tools used there :)
> 
Hi Trent:
Is not the i368 representing the name of the Architecture?? If so the 
name should start with i386 it will not break any system, is simply miss
written, I saw that and wanted to report it. It a silly thing.
Ohh I forgoten I must congratulate you for your GREAT libray, I was able 
to make an .exe with JSmooth that launches an application that uses RXTX 
with out the need to install RXTX on users system :). The .exe tells JVM 
where to find the RXTX Library and Binaries. I tried with Sun's Java 
Comm but it was imposible.
Regards,
Manuel


From tjarvi at qbang.org  Thu Jun 29 19:52:45 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 19:52:45 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A48088.2040407@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
	<Pine.LNX.4.61.0606291923000.9561@www> <44A48088.2040407@gmail.com>
Message-ID: <Pine.LNX.4.61.0606291945060.9561@www>

On Thu, 29 Jun 2006, Manuel Naranjo wrote:

>> On Thu, 29 Jun 2006, Manuel Naranjo wrote:
>>
>>> Speaking about Windows Support, I had seen that inside the
>>> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
>>> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
>>> not make harm to anyone, and i'm almost sure that someone has noticed it
>>> before.
>>
>> Hi Manuel
>>
>>         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
>>         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
>>     47421  01-30-06 00:23
>> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
>>     77759  03-01-06 12:01
>> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
>>       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README
>>
>>
>> It looks normal to me.  There are no fancy tools used there :)
>>
> Hi Trent:
> Is not the i368 representing the name of the Architecture?? If so the
> name should start with i386 it will not break any system, is simply miss
> written, I saw that and wanted to report it. It a silly thing.
> Ohh I forgoten I must congratulate you for your GREAT libray, I was able
> to make an .exe with JSmooth that launches an application that uses RXTX
> with out the need to install RXTX on users system :). The .exe tells JVM
> where to find the RXTX Library and Binaries. I tried with Sun's Java
> Comm but it was imposible.

Hi Manuel

The compiler uses only the i386 instruction set for windows.  I doubt 
there will be any measurable advantages with going to later instruction 
sets.  In theory rxtx would run on a 386 but I doubt anyone does that.

So it looks odd but is not a typo.

We could compile to i686 but don't.  The compiler used does not appear to 
be a problem yet so I don't see any point in changing it.  Right now, we 
could not compile 64 bit windows binaries.  gcc/mingw/... do not support 
them that I know of.  People will have to compile those with closed source 
tools on their own until an option is available.

--
Trent Jarvi
tjarvi at qbang.org

From naranjo.manuel at gmail.com  Thu Jun 29 20:00:48 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 23:00:48 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606291945060.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com>	<Pine.LNX.4.61.0606291923000.9561@www>
	<44A48088.2040407@gmail.com> <Pine.LNX.4.61.0606291945060.9561@www>
Message-ID: <44A485D0.7050202@gmail.com>

Trent you did not get my point
The folder says 368 three hundred sixty eight, when
it should say 386 three hundred eighty six. Is simply a miss writting.
Regards,
Manuel


From tjarvi at qbang.org  Thu Jun 29 20:12:15 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 20:12:15 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A485D0.7050202@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
	<Pine.LNX.4.61.0606291923000.9561@www> <44A48088.2040407@gmail.com>
	<Pine.LNX.4.61.0606291945060.9561@www> <44A485D0.7050202@gmail.com>
Message-ID: <Pine.LNX.4.61.0606292008061.9561@www>


On Thu, 29 Jun 2006, Manuel Naranjo wrote:

> Trent you did not get my point
> The folder says 368 three hundred sixty eight, when
> it should say 386 three hundred eighty six. Is simply a miss writting.

hehe..  OK.  My bad.  It's been a long day.

Nevermind :)

--
Trent Jarvi
tjarvi at qbang.org




From naranjo.manuel at gmail.com  Thu Jun 29 20:18:44 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 23:18:44 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606292008061.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com>	<Pine.LNX.4.61.0606291923000.9561@www>
	<44A48088.2040407@gmail.com>	<Pine.LNX.4.61.0606291945060.9561@www>
	<44A485D0.7050202@gmail.com> <Pine.LNX.4.61.0606292008061.9561@www>
Message-ID: <44A48A04.9040401@gmail.com>

Don't worry Trent.
About 64 bits compilation, I would like to colaborate, I have a Pc with 
64 bits, the only problem is that i do not have windows 64 bits 
installed :(.




From Pawan.Kharbanda at dot.state.co.us  Fri Jun 30 08:49:52 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 30 Jun 2006 08:49:52 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E996@hqexchange3.dot.state.co.us>

Trent,  
    Can you explain what the interruptedEventLoop() native method is
doing is there a possibility that method is somehow getting into the
infinite loop(there are 2 while loops without any break statements).
This might be a very basic question how can I debug the native code(or
print the debug statements).  Again thanks for the help. 

Pawan Kharbanda

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Thursday, June 29, 2006 6:21 AM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports

> Here is how you can test if you have resources/ test environment. 
> Write a program and try to open/close  different ports(I will say have

> a minimum of four) randomly and very frequently(may be 30 seconds), I 
> am pretty sure you will see the deadlocks and it happens in the native

> call to interrptEventLoop in RXTXPort.java in removeEventListener() 
> method call.

Hi Pawan

I'll try to find a way to reproduce this.  One thing to note is that you
are using different kernel drivers (digi) to perform this task.  So I
probably will not be able to reproduce the exact same environment.

In general, multiport kernel drivers have been tested far less than
typical serial drivers.  This may or may not be an issue.

--
Trent Jarvi
tjarvi at qbang.org

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From cpine at wrsystems.com  Thu Jun 29 15:17:12 2006
From: cpine at wrsystems.com (Chris Pine)
Date: Thu, 29 Jun 2006 17:17:12 -0400
Subject: [Rxtx]  Controlling Individual Signals DTR and RTS
Message-ID: <MAIL4FJo0S8ACLEBajJ000005cf@mail4.wrsystems.com>

Dear Moussa Ba,
	I hope I am not being too forward, but we are having the exact same
issue with needing to control DTR from RXTX in Linux.  Did you ever have any
luck figuring it out?

Thank you very much for your time,

Chris Pine




From tjarvi at qbang.org  Thu Jun  1 11:13:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 11:13:40 -0600 (MDT)
Subject: [Rxtx] custom baud rate win32
In-Reply-To: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606011107210.30220@www>


Hi Daren

I can't imagine that 1953 is possibly the actual value on the UART.  Maybe 
if your baud base is very high with a custom serial board.  More likely, 
the driver just remembers that what you asked for and did something else.

I'll have more to say on the dcb->BaudRate after I try some things here. 
I have managed to do something like that in the past as a quick hack but 
it was for 14400.  I may have used the CBR_14400.

If we can't access this through the win32 API with protected mode, there 
is another layer of complication.  With real mode, it would be easy.
With protected mode, I assume there would have to be some kernel driver or 
a hook I'm not aware of to access the MCR directly (bang a memory 
addresss).



On Thu, 1 Jun 2006, Daren wrote:

> Trent,
> I have managed to successfully open the port at this speed using Realterm
> (available on sourceforge). From memory this uses DLPortIO.
>
> Using portmon.exe with realterm, even there it says that the port has opened
> at 1953.
>
> I changed termios.c:560 to
> dcb->BaudRate        = 1953 ;
>
> and it still opens the port at 9600.
>
> Daren
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Trent Jarvi
> Sent: Thursday, 1 June 2006 1:44 PM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] custom baud rate win32
>
> On Thu, 1 Jun 2006, Daren wrote:
>
>> Hi all,
>>
>> I downloaded 2.1.7-pre16 and managed to build it and get it going. I made
>> the changes as suggested by Peter Smith in an old post, by adding his code
>> to SerialImpl.c, uncommenting the TIOCGSERIAL and TIOCSSERIAL, and
> defining
>> ASYNC_SPD_CUST which is equal to 0x0030 (according to linus header
> files)..
>>
>>
>> Still not working, it opens the port at 9600 according to portmon.exe .
> Has
>> anyone managed to get this going at a custom rate?
>>
>> Here is the post I'm referring to:
>> http://marc.theaimsgroup.com/?l=rxtx&m=106270038110713&w=2
>>
>>
>> Thanks,
>> Daren
>>
>> ________________________________________
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
>> Daren
>> Sent: Wednesday, 31 May 2006 10:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] (no subject)
>>
>> Hi All,
>> I have been using rxtx for a little while and needed to get it working at
>> 1953, like a past user in the mailing list, who seemed to have got it
>> working by changing some C code.
>>
>> I wanted to build rxtx myself with these changes but don't know where to
>> start. I have windows here and FC4 at home. I downloaded cygwin and
> mingw32,
>> each build works by building a rxtxSerial.dll file that is ~11k smaller
> than
>> the original, and I always get the following error when testing the dll:
>>
>> Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at
>> PC=0x8077655
>> Function=[Unknown.]
>> Library=C:\opt\java\j2sdk1.4.2\jre\bin\client\jvm.dll
>>
>> NOTE: We are unable to locate the function name symbol for the error
>>      just occurred. Please refer to release documentation for possible
>>      reason and solutions.
>>
>>
>> Current Java thread:
>> 	at gnu.io.RXTXPort.open(Native Method)
>> 	- locked <0x1002c800> (a gnu.io.RXTXPort)
>> 	at gnu.io.RXTXPort.<init>(RXTXPort.java:84)
>>
>> Anyone know what im doing wrong?
>>
>>
>>
>>
>
> Hi Daren
>
> You are running into the same rats nest I'm looking at now.
>
> With win32 and specific custom baud rates, I'm not sure how this will go.
> I've got the Linux custom baud rates working very nicely.  I did much like
> the post you linked.  In fact I had forgot about that post.  You probably
> noticed that it becomes a bunch of dirt roads going noplace fast in
> termios.c for w32.
>
> I'm probably only going to get 14400, 28800, 128000 and 256000 working
> with the next release on w32.  I'll look a little further.  If you have an
> example w32 that works at 1953 I'd really like to hear.  Thats an unusual
> baud rate.
>
> Assuming a baud_base of 128000, your divisor will be 65 or 66.
>
> 128000/66=1939 -14
> 128000/65=1969 +13
>
> One thing I've been wondering about with linux is which would be the right
> answer in cases like this.  Right now it would just go with a baud base of
> 65 and ignore the modulus details.
>
> It appears to be a general trend for kernel developers to hide these
> details thinking that they can come up with a general solution.  Then they
> run out of time.  Perahps the solution is to help out but there are
> ultiple OS's rxtx supports making that nontrivial.
>
> If you look at current linux kernels, the 'tricks' above have been marked
> deprecated with no replacement.  Windows has some hard defines and then
> ancient near magic.  I've not looked at Solaris via Open Solaris yet but
> doubt there is a solution at all.
>
> What I'd try since you have the equipment and the monitor software is to
> hardcode the dcb->Baud in termios.c to 1953 (no define) and see what the
> w32 kernel does with it.  I think if you toss a baud rate at the driver it
> will try to come close.  You may try comming closer to a real baudrate
> based upon the 128000 baud base as shown above.
>
> If it works, it is worth looking at the rest of the ping/pong logic then.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
>
>
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From doug at dupreeinc.com  Thu Jun  1 13:22:13 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 12:22:13 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011107210.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
Message-ID: <447F3E65.1020809@dupreeinc.com>

Hello,

I am still trying to get this startup a little faster so I turned on the 
debug of a few of the classes.  The COM ports are scanned really fast 
and the delay occurs during the LPT scan.  The console output looks like 
this:

    ...
      LPT1
      LPT2
      LPT3
     valid port prefixes:
      LPT
    LPT1 LPT
    1 1
    LPT2 LPT
    2 2                                                                 
      * <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
    CommPortIdentifier:addPortName(LPT2)
    CommPortIdentifier:AddIdentifierToList()
    LPT3 LPT
    3 3
    CommPortIdentifier:addPortName(LPT3)
    CommPortIdentifier:AddIdentifierToList()
    CommPortIdentifier:AddIdentifierToList() index.next
    Leaving registerValidPorts()
    Have not implemented native_psmisc_report_owner(PortName)); in
    CommPortIdentifier
    CommPortIdentifier:getPortIdentifier(COM3)
    CommPortIdentifier:open(densConnect, 30000)
    RXTXCommDriver:getCommPort(COM3,1)
    ...

It would seem to me that if I removed the code for port scanning of LPT 
ports I could solve this problem. I would much prefer to use unmodified 
code if at all possible.  Do any of you have alternate suggestions?

Thank you for your time.

Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/cf433ee7/attachment-0022.html

From tjarvi at qbang.org  Thu Jun  1 13:52:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 13:52:06 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F3E65.1020809@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011348380.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I am still trying to get this startup a little faster so I turned on the 
> debug of a few of the classes.  The COM ports are scanned really fast and the 
> delay occurs during the LPT scan.  The console output looks like this:
>
>   ...
>     LPT1
>     LPT2
>     LPT3
>    valid port prefixes:
>     LPT
>   LPT1 LPT
>   1 1
>   LPT2 LPT
>   2 2                                                                      * 
> <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>   CommPortIdentifier:addPortName(LPT2)
>   CommPortIdentifier:AddIdentifierToList()
>   LPT3 LPT
>   3 3
>   CommPortIdentifier:addPortName(LPT3)
>   CommPortIdentifier:AddIdentifierToList()
>   CommPortIdentifier:AddIdentifierToList() index.next
>   Leaving registerValidPorts()
>   Have not implemented native_psmisc_report_owner(PortName)); in
>   CommPortIdentifier
>   CommPortIdentifier:getPortIdentifier(COM3)
>   CommPortIdentifier:open(densConnect, 30000)
>   RXTXCommDriver:getCommPort(COM3,1)
>   ...
>
> It would seem to me that if I removed the code for port scanning of LPT ports 
> I could solve this problem. I would much prefer to use unmodified code if at 
> all possible.  Do any of you have alternate suggestions?
>
> Thank you for your time.
>
> Doug
>


Does commenting out the LPT enumeration actually help?  There can often be 
differences between debug information printed and whats really going on. 
When you combine various environments the debug info can even come out in 
the wrong order.

I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
I do not think this problem is universal.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Thu Jun  1 14:29:44 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:29:44 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4E38.2060004@dupreeinc.com>

I will give it a try.  One thing to note on this PC is it has no LPT 
Parallel ports.

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
>>Hello,
>>
>>I am still trying to get this startup a little faster so I turned on the 
>>debug of a few of the classes.  The COM ports are scanned really fast and the 
>>delay occurs during the LPT scan.  The console output looks like this:
>>
>>  ...
>>    LPT1
>>    LPT2
>>    LPT3
>>   valid port prefixes:
>>    LPT
>>  LPT1 LPT
>>  1 1
>>  LPT2 LPT
>>  2 2                                                                      * 
>><<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>>  CommPortIdentifier:addPortName(LPT2)
>>  CommPortIdentifier:AddIdentifierToList()
>>  LPT3 LPT
>>  3 3
>>  CommPortIdentifier:addPortName(LPT3)
>>  CommPortIdentifier:AddIdentifierToList()
>>  CommPortIdentifier:AddIdentifierToList() index.next
>>  Leaving registerValidPorts()
>>  Have not implemented native_psmisc_report_owner(PortName)); in
>>  CommPortIdentifier
>>  CommPortIdentifier:getPortIdentifier(COM3)
>>  CommPortIdentifier:open(densConnect, 30000)
>>  RXTXCommDriver:getCommPort(COM3,1)
>>  ...
>>
>>It would seem to me that if I removed the code for port scanning of LPT ports 
>>I could solve this problem. I would much prefer to use unmodified code if at 
>>all possible.  Do any of you have alternate suggestions?
>>
>>Thank you for your time.
>>
>>Doug
>>
>>    
>>
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/dd31fed5/attachment-0022.html

From doug at dupreeinc.com  Thu Jun  1 14:36:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:36:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4FC8.9080106@dupreeinc.com>

Trent,

I commented out the section in RegisterScannedPorts() that adds the 
three LPT ports to the CandidateDeviceNames string array.  The 
application started immediately.  This is probably not the way to do 
this, but it was quick ,dirty, and worked.

It would be nice if there was a way to pole the OS to see if there is 
even a port there, though I guess this is what this code is suppose to do...

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
> ...
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From lynn at swcp.com  Thu Jun  1 14:49:34 2006
From: lynn at swcp.com (lynn@swcp.com)
Date: Thu, 1 Jun 2006 20:49:34 -0000
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>,
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <twig.1149194974.97617@swcp.com>

Perhaps we could add an argument to port enumeration where if not specified,
you get the default behavior that looks for everything.  With a new
constructor that has an argument(or more) you could optionally declare it to
not inspect printer ports.

Existing code would work as it always has.  New code could be smarter.

Lynn



Doug Thistlethwaite <doug at dupreeinc.com> said:

> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
> >On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
> >
> >  
> >
> > ...
> >
> >
> >Does commenting out the LPT enumeration actually help?  There can often be 
> >differences between debug information printed and whats really going on. 
> >When you combine various environments the debug info can even come out in 
> >the wrong order.
> >
> >I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
> >I do not think this problem is universal.
> >
> >--
> >Trent Jarvi
> >tjarvi at qbang.org
> >_______________________________________________
> >Rxtx mailing list
> >Rxtx at qbang.org
> >http://mailman.qbang.org/mailman/listinfo/rxtx
> >
> >
> >  
> >
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



-- 





From jredman at ergotech.com  Thu Jun  1 15:20:20 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 01 Jun 2006 15:20:20 -0600
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
Message-ID: <447F5A14.6010803@ergotech.com>

Doug,

If you specifically request ports, eg:

-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

or
 
-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

Depending upon the version  (Windows is COM1:COM2, etc. I assume).

Does it still enumerate the parallel ports?

Jim

Doug Thistlethwaite wrote:
> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
>> On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>
>>  
>>
>> ...
>>
>>
>> Does commenting out the LPT enumeration actually help?  There can often be 
>> differences between debug information printed and whats really going on. 
>> When you combine various environments the debug info can even come out in 
>> the wrong order.
>>
>> I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>> I do not think this problem is universal.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>>
>>  
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  1 16:49:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:49:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6EF4.7080709@dupreeinc.com>

I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
folder.  I created this file and added the following to the file:

gnu.io.rxtx.SerialPorts=COM3

and I get the following error on the console:
CommPortIdentifier:static initialization()
RXTXCommDriver {}
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
RXTXCommDriver:
    Jar version = RXTX-2.1-7
    native lib Version = RXTX-2.1-7
RXTXCommDriver:initialize()
checking for system-known ports of type 1
checking registry for ports of type 1

RXTXCommDriver:addSpecifiedPorts()
Exception in thread "main" java.lang.ExceptionInInitializerError
    at 
densconnect.SerialConnection.openConnection(SerialConnection.java:136)
    at densconnect.DensTalk.<init>(DensTalk.java:165)
    at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
    at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
    at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
    at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
Caused by: java.lang.NullPointerException
    at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
CommPortIdentifier:addPortName(COM3)
CommPortIdentifier:AddIdentifierToList()
CommPortIdentifier:AddIdentifierToList() null
...


It looks like it  read COM3 from the file, but it had the above 
exception that killed it.  The strange this is this error is from 
RXTXCommDriver initialize function (if statement line):

        OS = System.getProperty("os.name");
                System.out.println("OS NAME: " + OS);
        if(OS.toLowerCase().indexOf("linux") == -1)

OS is returning null, thus the error.

If the file is not present, it scans the ports and reads the OS.

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>Doug Thistlethwaite wrote:
>  
>
>>Trent,
>>
>>I commented out the section in RegisterScannedPorts() that adds the 
>>three LPT ports to the CandidateDeviceNames string array.  The 
>>application started immediately.  This is probably not the way to do 
>>this, but it was quick ,dirty, and worked.
>>
>>It would be nice if there was a way to pole the OS to see if there is 
>>even a port there, though I guess this is what this code is suppose to do...
>>
>>Doug
>>
>>Trent Jarvi wrote:
>>
>>    
>>
>>>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>>
>>> 
>>>
>>>...
>>>
>>>
>>>Does commenting out the LPT enumeration actually help?  There can often be 
>>>differences between debug information printed and whats really going on. 
>>>When you combine various environments the debug info can even come out in 
>>>the wrong order.
>>>
>>>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>>>I do not think this problem is universal.
>>>
>>>--
>>>Trent Jarvi
>>>tjarvi at qbang.org
>>>_______________________________________________
>>>Rxtx mailing list
>>>Rxtx at qbang.org
>>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>>
>>>
>>> 
>>>
>>>      
>>>
>>_______________________________________________
>>Rxtx mailing list
>>Rxtx at qbang.org
>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>    
>>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/bf4cca0e/attachment-0022.html

From doug at dupreeinc.com  Thu Jun  1 16:51:26 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:51:26 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6F6E.5060603@dupreeinc.com>

Jim,

I did not try your suggestion as I do not understand where I would put 
these command line parameters (it that is what they are).  It appears 
that using the properties file should do that same thing...

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>
>  
>


From doug at dupreeinc.com  Thu Jun  1 17:56:19 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 16:56:19 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
Message-ID: <447F7EA3.6050400@dupreeinc.com>

I think there is an error in the registerSpecifiedPorts() method.  When 
I have a gnu.io.rxtx.properties file in the ext directory, this function 
kills the System class  IF I call System.getProperty("os.name") before 
the call  to registerSpecifiedPorts(), it returns the os name, after the 
call, it returns null.  I have not played much with properties, except 
for reading them, so I don't really understand the code.

Doug



From doug at dupreeinc.com  Thu Jun  1 18:11:14 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 17:11:14 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F7EA3.6050400@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com>
Message-ID: <447F8222.3060402@dupreeinc.com>

Ok, I just hacked this thing up and got it to read the 
gnu.io.rxtx.properties file.

I commented out the line:
System.setProperties(p); in the method registerSpecifiedPorts() in 
RXTXCommDriver class.  I really don't understand that much about 
properties, but this call kills the System class.

I used the following in the gnu.io.rxtx.properties file:

gnu.io.rxtx.SerialPorts=COM3
gnu.io.rxtx.ParallelPorts=null

This allows the application to open very quickly without any errors.  
Whomever coded this class or somebody who understands properties should 
look at this method and make sure it is doing what they expect.

Doug




Doug Thistlethwaite wrote:

>I think there is an error in the registerSpecifiedPorts() method.  When 
>I have a gnu.io.rxtx.properties file in the ext directory, this function 
>kills the System class  IF I call System.getProperty("os.name") before 
>the call  to registerSpecifiedPorts(), it returns the os name, after the 
>call, it returns null.  I have not played much with properties, except 
>for reading them, so I don't really understand the code.
>
>Doug
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From tjarvi at qbang.org  Thu Jun  1 18:32:50 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 18:32:50 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F6EF4.7080709@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com> <447F6EF4.7080709@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011831510.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
> folder.  I created this file and added the following to the file:
>
> gnu.io.rxtx.SerialPorts=COM3
>
> and I get the following error on the console:
> CommPortIdentifier:static initialization()
> RXTXCommDriver {}
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
> RXTXCommDriver:
>   Jar version = RXTX-2.1-7
>   native lib Version = RXTX-2.1-7
> RXTXCommDriver:initialize()
> checking for system-known ports of type 1
> checking registry for ports of type 1
>
> RXTXCommDriver:addSpecifiedPorts()
> Exception in thread "main" java.lang.ExceptionInInitializerError
>   at densconnect.SerialConnection.openConnection(SerialConnection.java:136)
>   at densconnect.DensTalk.<init>(DensTalk.java:165)
>   at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
>   at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
>   at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
>   at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
> Caused by: java.lang.NullPointerException
>   at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
> CommPortIdentifier:addPortName(COM3)
> CommPortIdentifier:AddIdentifierToList()
> CommPortIdentifier:AddIdentifierToList() null
> ...
>
>

There is a solution for this bug.

http://bugzilla.qbang.org/show_bug.cgi?id=54

We have been horribly slow at getting the next round of patches in but 
they are comming.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  2 00:58:02 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 08:58:02 +0200
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F8222.3060402@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
Message-ID: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>

Hi Doug,

you wrote in an earlier message, that you would prefer an unchanged  
version. What about simply removing the RXTX parallel lib from the  
ext directory. This does not fix the bug, but it should fix your  
problem.

In general I think it is not a good idea to put the RXTX files in a  
system wide location. Putting the libs in the application folder and  
including the .jar in the application classpath (or application jar)  
is all that is required.

Regards,
Joachim

On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:

> Ok, I just hacked this thing up and got it to read the
> gnu.io.rxtx.properties file.
>
> I commented out the line:
> System.setProperties(p); in the method registerSpecifiedPorts() in
> RXTXCommDriver class.  I really don't understand that much about
> properties, but this call kills the System class.
>
> I used the following in the gnu.io.rxtx.properties file:
>
> gnu.io.rxtx.SerialPorts=COM3
> gnu.io.rxtx.ParallelPorts=null
>
> This allows the application to open very quickly without any errors.
> Whomever coded this class or somebody who understands properties  
> should
> look at this method and make sure it is doing what they expect.
>
> Doug
>
>
>
>
> Doug Thistlethwaite wrote:
>
>> I think there is an error in the registerSpecifiedPorts() method.   
>> When
>> I have a gnu.io.rxtx.properties file in the ext directory, this  
>> function
>> kills the System class  IF I call System.getProperty("os.name")  
>> before
>> the call  to registerSpecifiedPorts(), it returns the os name,  
>> after the
>> call, it returns null.  I have not played much with properties,  
>> except
>> for reading them, so I don't really understand the code.
>>
>> 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 antonio.luis at iscte.pt  Fri Jun  2 02:42:28 2006
From: antonio.luis at iscte.pt (=?ISO-8859-1?Q?Ant=F3nio_Lopes?=)
Date: Fri, 02 Jun 2006 09:42:28 +0100
Subject: [Rxtx] Exception when closing serial port
Message-ID: <447FF9F4.7060209@iscte.pt>

Hello everyone,
I've been using RXTX in a Java application in my Pocket PC.
The communication through the (bluetooth) serial port is working perfectly.

However, when I disconnect the app and close the serial port, sometimes I get 
the following error:

"1149237595000: RXTXPort:close detected bad File Descriptor"

The problem is that after this error occurs, the app is no longer able to 
connect to the serial port and I have to soft-reset the device in order to be 
able to connect to it again.

Any ideas on how to solve this issue?

Any help is appreciated.
Thanks,
regards,
-- 
Ant?nio Lopes

@contact: antonio.luis at iscte.pt
@work: ADETTI - ISCTE
@web: http://antonio.lopes.googlepages.com


From paul.klissner at sun.com  Fri Jun  2 02:44:34 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 01:44:34 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to RXTX
	again
Message-ID: <447FFA72.6040807@sun.com>

After looking into javax.comm 3.1 and what it would take to re-engineer it
to be compatible with RXTX platform libraries, I've decided, due my group's
priorities, complexity of the effort vs. benefit, and limited resources, 
to re-post
javax.comm 2.0 binaries on Sun's software download server, unsupported,
with disclaimers, as it was previously.

I don't think there will be any snags doing this from the standpoint of Sun
management or legality.  I will try to have it  posted there in the next 
week
or two, depending on how fast we can get it pushed through the process.

I'd like to think of this as a stop gap measure... ie. a compromise, 
where, at some
point in the not too distant future RXTX implements their own version of the
Java side of the API, as is normally done by javax.extension porters. 
That way
we avoid uncomfortable dependencies in the future.  And that really is 
the Java
development model.

Since RXTX already has the back-end code, porting the java code shouldn't
be a gargantuan effort at all, and RXTX will be in full control of the 
code top
to bottom. I think RXTX can do at least as good a job as the original 
coder.
Prepping 2.0 to be open sourced is more trouble than it is worth. ie. I 
don't
think the current implementation warrants it.

Ultimately, it would be nice to see someone open up a JSR and re-architect
the comm. API to overcome some of it's current design flaws (ie. be more
adaptable to modern platforms, more pluggable, better defined SPI, better
port ownership handling, etc...). A superior architecture would allow for
better collaboration in the future and better interchangeability of 
components
among projects.

Sun's 3.1 version of javax.comm, which is Sun's currently supported version,
has changes pertaining mostly to Sun platform-specific portmapping and has
some minor additional interactions with our back end code, but generally
has little bearing on RXTX. 

Paul



From joachim at buechse.de  Fri Jun  2 04:00:19 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 12:00:19 +0200
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
	RXTX again
In-Reply-To: <447FFA72.6040807@sun.com>
References: <447FFA72.6040807@sun.com>
Message-ID: <1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>

Good day Paul!

A clean architecture with loadable drivers and reusable code would be  
very beneficial for the future, I think everybody agrees. However  
this could be several years into the future. In the meantime, there  
is a real existing problem with IO support on Java. I have the strong  
feeling that most programmers want to code against one specification  
(javax.comm) and be able to replace the underlying implementation via  
a "plugin" on platforms where the SUN implementation is not  
sufficient. RXTX could be just this plugin (reusing very close to 0%  
of the javax.comm implementation but 100% of its API).

I want to propose an API addition and implementation change that will  
take less then 2 hours of manpower to implement and create a solution  
that can bridge the years until javax.comm has been based on a new  
architecture.

Looking at the javax.comm api at http://java.sun.com/products/ 
javacomm/reference/api/index.html I would like to propose the following:

The only entry point to javax.comm is CommPortIdentifier. It has 3  
static methods plus the constructor.

1) define one additional Interface

public interface CommProvider {
    CommPortIdentifier getPortIdentifier(CommPort port);
    CommPortIdentifier getPortIdentifier(String portName);
    Enumeration getPortIdentifiers ();
}

2) add one method to CommPortIdentifier

   public static setCustomCommProvider (CommProvider);

3) change the three static methods of CommPortIdentifier to dispatch  
to the CommProvider if it is set

4) change the constructor of CommPortIdentifier to

   public CommPortIdentifier(...) {
      if (isProviderSet && this.getClass() ==  
javax.comm.CommPortIdentifier) {
          throw new RuntimeException("illegal creation of  
CommPortIndentifier, custom CommProvider is in use");
      }

5) (this is optional, but would be very nice) automatically set a  
custom CommProvider if it is found on the classpath or defined via a  
system property.


The above 1) - 4) can be implemented in less than 1hour. 5) may take  
another hour. I agree that this is not the most elegant design, but  
it would solve a lot of problems with very little effort. It would  
certainly allow RXTX to move forward. If the javax.comm API needs to  
be redesigned completely this addition will not hurt, as people will  
move to the new API anyway and javax.comm 3.0 was so far never  
included in the main distribution.

Best regards,
Joachim

On 02.06.2006, at 10:44, Paul Klissner wrote:

> After looking into javax.comm 3.1 and what it would take to re- 
> engineer it
> to be compatible with RXTX platform libraries, I've decided, due my  
> group's
> priorities, complexity of the effort vs. benefit, and limited  
> resources,
> to re-post
> javax.comm 2.0 binaries on Sun's software download server,  
> unsupported,
> with disclaimers, as it was previously.
>
> I don't think there will be any snags doing this from the  
> standpoint of Sun
> management or legality.  I will try to have it  posted there in the  
> next
> week
> or two, depending on how fast we can get it pushed through the  
> process.
>
> I'd like to think of this as a stop gap measure... ie. a compromise,
> where, at some
> point in the not too distant future RXTX implements their own  
> version of the
> Java side of the API, as is normally done by javax.extension porters.
> That way
> we avoid uncomfortable dependencies in the future.  And that really is
> the Java
> development model.
>
> Since RXTX already has the back-end code, porting the java code  
> shouldn't
> be a gargantuan effort at all, and RXTX will be in full control of the
> code top
> to bottom. I think RXTX can do at least as good a job as the original
> coder.
> Prepping 2.0 to be open sourced is more trouble than it is worth.  
> ie. I
> don't
> think the current implementation warrants it.
>
> Ultimately, it would be nice to see someone open up a JSR and re- 
> architect
> the comm. API to overcome some of it's current design flaws (ie. be  
> more
> adaptable to modern platforms, more pluggable, better defined SPI,  
> better
> port ownership handling, etc...). A superior architecture would  
> allow for
> better collaboration in the future and better interchangeability of
> components
> among projects.
>
> Sun's 3.1 version of javax.comm, which is Sun's currently supported  
> version,
> has changes pertaining mostly to Sun platform-specific portmapping  
> and has
> some minor additional interactions with our back end code, but  
> generally
> has little bearing on RXTX.
>
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Fri Jun  2 09:10:13 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Fri, 2 Jun 2006 09:10:13 -0600 (MDT)
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <447FFA72.6040807@sun.com>
References: <447FFA72.6040807@sun.com>
Message-ID: <Pine.LNX.4.61.0606020906400.15971@www>

On Fri, 2 Jun 2006, Paul Klissner wrote:

> After looking into javax.comm 3.1 and what it would take to re-engineer it
> to be compatible with RXTX platform libraries, I've decided, due my group's
> priorities, complexity of the effort vs. benefit, and limited resources,
> to re-post
> javax.comm 2.0 binaries on Sun's software download server, unsupported,
> with disclaimers, as it was previously.
>

Hi Paul

To address users' immediate needs, we can release rxtx 2.0-7 (final) to 
match the 2.0 binaries from Sun when they are offered for download.

We can discuss potential long term solutions after that.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Fri Jun  2 10:20:09 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 02 Jun 2006 09:20:09 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
	<9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
Message-ID: <44806539.8080902@dupreeinc.com>

Thanks for the suggestion, I will give it a try.

Doug

Joachim Buechse wrote:

>Hi Doug,
>
>you wrote in an earlier message, that you would prefer an unchanged  
>version. What about simply removing the RXTX parallel lib from the  
>ext directory. This does not fix the bug, but it should fix your  
>problem.
>
>In general I think it is not a good idea to put the RXTX files in a  
>system wide location. Putting the libs in the application folder and  
>including the .jar in the application classpath (or application jar)  
>is all that is required.
>
>Regards,
>Joachim
>
>On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:
>
>  
>
>>Ok, I just hacked this thing up and got it to read the
>>gnu.io.rxtx.properties file.
>>
>>I commented out the line:
>>System.setProperties(p); in the method registerSpecifiedPorts() in
>>RXTXCommDriver class.  I really don't understand that much about
>>properties, but this call kills the System class.
>>
>>I used the following in the gnu.io.rxtx.properties file:
>>
>>gnu.io.rxtx.SerialPorts=COM3
>>gnu.io.rxtx.ParallelPorts=null
>>
>>This allows the application to open very quickly without any errors.
>>Whomever coded this class or somebody who understands properties  
>>should
>>look at this method and make sure it is doing what they expect.
>>
>>Doug
>>
>>
>>
>>
>>Doug Thistlethwaite wrote:
>>
>>    
>>
>>>I think there is an error in the registerSpecifiedPorts() method.   
>>>When
>>>I have a gnu.io.rxtx.properties file in the ext directory, this  
>>>function
>>>kills the System class  IF I call System.getProperty("os.name")  
>>>before
>>>the call  to registerSpecifiedPorts(), it returns the os name,  
>>>after the
>>>call, it returns null.  I have not played much with properties,  
>>>except
>>>for reading them, so I don't really understand the code.
>>>
>>>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
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060602/c8892a46/attachment-0022.html

From paul.klissner at sun.com  Fri Jun  2 12:09:26 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 11:09:26 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
Message-ID: <44807ED6.8000903@sun.com>

Joachim Buechse wrote:
> Good day Paul!
>
> A clean architecture with loadable drivers and reusable code would be  
> very beneficial for the future, I think everybody agrees. However  
> this could be several years into the future. In the meantime, there  
> is a real existing problem with IO support on Java. I have the strong  
> feeling that most programmers want to code against one specification  
> (javax.comm) and be able to replace the underlying implementation via  
> a "plugin" on platforms where the SUN implementation is not  
> sufficient. RXTX could be just this plugin (reusing very close to 0%  
> of the javax.comm implementation but 100% of its API).
>
> I want to propose an API addition and implementation change that will  
> take less then 2 hours of manpower to implement and create a solution  
> that can bridge the years until javax.comm has been based on a new  
> architecture.
>
> Looking at the javax.comm api at http://java.sun.com/products/ 
> javacomm/reference/api/index.html I would like to propose the following:
>
> The only entry point to javax.comm is CommPortIdentifier. It has 3  
> static methods plus the constructor.
>
> 1) define one additional Interface
>
> public interface CommProvider {
>     CommPortIdentifier getPortIdentifier(CommPort port);
>     CommPortIdentifier getPortIdentifier(String portName);
>     Enumeration getPortIdentifiers ();
> }
>
> 2) add one method to CommPortIdentifier
>
>    public static setCustomCommProvider (CommProvider);
>
> 3) change the three static methods of CommPortIdentifier to dispatch  
> to the CommProvider if it is set
>
> 4) change the constructor of CommPortIdentifier to
>
>    public CommPortIdentifier(...) {
>       if (isProviderSet && this.getClass() ==  
> javax.comm.CommPortIdentifier) {
>           throw new RuntimeException("illegal creation of  
> CommPortIndentifier, custom CommProvider is in use");
>       }
>
> 5) (this is optional, but would be very nice) automatically set a  
> custom CommProvider if it is found on the classpath or defined via a  
> system property.
>
>
> The above 1) - 4) can be implemented in less than 1hour. 5) may take  
> another hour. I agree that this is not the most elegant design, but  
> it would solve a lot of problems with very little effort. It would  
> certainly allow RXTX to move forward. If the javax.comm API needs to  
> be redesigned completely this addition will not hurt, as people will  
> move to the new API anyway and javax.comm 3.0 was so far never  
> included in the main distribution.
>
> Best regards,
> Joachi
I'm afraid modifying the interface classes isn't my call.  There was 
actually
a TCK written and one of the tests was to ensure that the interface classes
match the spec.  Thus my hands have already been tied since this project
was essentially grandfathered into the JCP.

That's why we need to open a new JSR and find someone who wants
to be the spec lead, and go in with a new reference implementation.
I'm not sure why it would have to take years, since this isn't bleeding edge
technology and there are only so many things that can be done with it,
and we already have practical experience about many functional aspects
that we could cite precedence on.

As it becomes clear that the specification is being accepted completely
or by-and-large by the community, nothing would stop people from
starting adapting to the new API (using the reference implementation or
porting it) and using it in their projects prior to it's final community and
JCP approval, since approval is required only to make it official and
get the "100% pure java" certification for platform ports.

You have one idea already.  Why don't you implement it, solicit some
design feedback from Sun and the RXTX, and create a functional
implementation that addresses the needs of the community, then
we can document it and open a JSR.  That's it.  It should march through
the approval stages reasonably quickly I would imagine, and meantime
RXTX could start using it.

Paul




From doug at dupreeinc.com  Fri Jun  2 12:45:01 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 02 Jun 2006 11:45:01 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
	<9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
Message-ID: <4480872D.6000605@dupreeinc.com>

Joachim,

Thank you for the suggestion.  I restored the jar file to the one I 
downloaded, moved the dll files into the project directory, and added 
the jar to the classpath.  The SerialDemo program that was included with 
the Sun commapi started in 12 seconds instead of the 58 seconds when the 
parallel dll is present.  I did get the startup time to about a second 
by modifying the java code and adding the properties file but this is 
probably not a good idea.

Doug

Joachim Buechse wrote:

>Hi Doug,
>
>you wrote in an earlier message, that you would prefer an unchanged  
>version. What about simply removing the RXTX parallel lib from the  
>ext directory. This does not fix the bug, but it should fix your  
>problem.
>
>In general I think it is not a good idea to put the RXTX files in a  
>system wide location. Putting the libs in the application folder and  
>including the .jar in the application classpath (or application jar)  
>is all that is required.
>
>Regards,
>Joachim
>
>On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:
>
>  
>
>>Ok, I just hacked this thing up and got it to read the
>>gnu.io.rxtx.properties file.
>>
>>I commented out the line:
>>System.setProperties(p); in the method registerSpecifiedPorts() in
>>RXTXCommDriver class.  I really don't understand that much about
>>properties, but this call kills the System class.
>>
>>I used the following in the gnu.io.rxtx.properties file:
>>
>>gnu.io.rxtx.SerialPorts=COM3
>>gnu.io.rxtx.ParallelPorts=null
>>
>>This allows the application to open very quickly without any errors.
>>Whomever coded this class or somebody who understands properties  
>>should
>>look at this method and make sure it is doing what they expect.
>>
>>Doug
>>
>>
>>
>>
>>Doug Thistlethwaite wrote:
>>
>>    
>>
>>>I think there is an error in the registerSpecifiedPorts() method.   
>>>When
>>>I have a gnu.io.rxtx.properties file in the ext directory, this  
>>>function
>>>kills the System class  IF I call System.getProperty("os.name")  
>>>before
>>>the call  to registerSpecifiedPorts(), it returns the os name,  
>>>after the
>>>call, it returns null.  I have not played much with properties,  
>>>except
>>>for reading them, so I don't really understand the code.
>>>
>>>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
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060602/3c0e420f/attachment-0022.html

From joachim at buechse.de  Fri Jun  2 13:46:36 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 21:46:36 +0200
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
	RXTX again
In-Reply-To: <44807ED6.8000903@sun.com>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
	<44807ED6.8000903@sun.com>
Message-ID: <6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>

Hello Paul,

of course, the basic change I suggested could be done "hidden".  The  
CommProvider interface could live somewhere in sun.xyz.*
The setCustomCommProvider method would not be in CommPortIdentifier  
but also somewhere in sun.xyz.* This would be an unofficial feature,  
the official interface stays exactly the same. However RXTX (and  
others) could access the hidden interface.

Don't get me wrong, I don't want to harass you into making changes  
you don't like (which probably wouldn't work anyway;-). But I'm a  
long time Java programmer and seeing the state of cross platform  
serial support for Java makes me feel really sad. In fact, when I  
started to look into Java serial port programming some months ago I  
was very surprised that javax.comm never made it into the JDK.

I'm sorry that I did not contribute my feedback to the JSR for  
javax.comm 3.0. However at the time I didn't do serial port  
programming in Java. I agree that a new JSR should be opened - I'm  
not an expert on JSRs or the JCP process, but from looking quickly  
over the progress of some JSRs I would be very surprised if we can  
have a new version in less then a year. In the meanwhile some people  
will start using javax.comm 3.0 (which can not be supported by RXTX),  
some will use javax.comm 2.0 (which means the 2.0.7 release of RXTX  
still needs to be maintained). This may get even worse if eg Apple  
decides to port and include javax.comm 3.0 at which point it may get  
very tricky to write a cross platform Java application.

All of this simply means, that we are loosing a lot of man-power that  
could otherwise be invested in building a clean solution and/or to  
add features that are becoming more and more important (USB events...).

In the automation / machine control universe Java makes a lot of  
sense. Right now many people are migrating to Linux or from  
propietary systems (even DOS) to Windows. Writing the control/ 
configuration applications in Java is the kings way to unify the code  
base.

Best regards,
Joachim


On 02.06.2006, at 20:09, Paul Klissner wrote:

> Joachim Buechse wrote:
>> Good day Paul!
>>
>> A clean architecture with loadable drivers and reusable code would be
>> very beneficial for the future, I think everybody agrees. However
>> this could be several years into the future. In the meantime, there
>> is a real existing problem with IO support on Java. I have the strong
>> feeling that most programmers want to code against one specification
>> (javax.comm) and be able to replace the underlying implementation via
>> a "plugin" on platforms where the SUN implementation is not
>> sufficient. RXTX could be just this plugin (reusing very close to 0%
>> of the javax.comm implementation but 100% of its API).
>>
>> I want to propose an API addition and implementation change that will
>> take less then 2 hours of manpower to implement and create a solution
>> that can bridge the years until javax.comm has been based on a new
>> architecture.
>>
>> Looking at the javax.comm api at http://java.sun.com/products/
>> javacomm/reference/api/index.html I would like to propose the  
>> following:
>>
>> The only entry point to javax.comm is CommPortIdentifier. It has 3
>> static methods plus the constructor.
>>
>> 1) define one additional Interface
>>
>> public interface CommProvider {
>>     CommPortIdentifier getPortIdentifier(CommPort port);
>>     CommPortIdentifier getPortIdentifier(String portName);
>>     Enumeration getPortIdentifiers ();
>> }
>>
>> 2) add one method to CommPortIdentifier
>>
>>    public static setCustomCommProvider (CommProvider);
>>
>> 3) change the three static methods of CommPortIdentifier to dispatch
>> to the CommProvider if it is set
>>
>> 4) change the constructor of CommPortIdentifier to
>>
>>    public CommPortIdentifier(...) {
>>       if (isProviderSet && this.getClass() ==
>> javax.comm.CommPortIdentifier) {
>>           throw new RuntimeException("illegal creation of
>> CommPortIndentifier, custom CommProvider is in use");
>>       }
>>
>> 5) (this is optional, but would be very nice) automatically set a
>> custom CommProvider if it is found on the classpath or defined via a
>> system property.
>>
>>
>> The above 1) - 4) can be implemented in less than 1hour. 5) may take
>> another hour. I agree that this is not the most elegant design, but
>> it would solve a lot of problems with very little effort. It would
>> certainly allow RXTX to move forward. If the javax.comm API needs to
>> be redesigned completely this addition will not hurt, as people will
>> move to the new API anyway and javax.comm 3.0 was so far never
>> included in the main distribution.
>>
>> Best regards,
>> Joachi
> I'm afraid modifying the interface classes isn't my call.  There was
> actually
> a TCK written and one of the tests was to ensure that the interface  
> classes
> match the spec.  Thus my hands have already been tied since this  
> project
> was essentially grandfathered into the JCP.
>
> That's why we need to open a new JSR and find someone who wants
> to be the spec lead, and go in with a new reference implementation.
> I'm not sure why it would have to take years, since this isn't  
> bleeding edge
> technology and there are only so many things that can be done with it,
> and we already have practical experience about many functional aspects
> that we could cite precedence on.
>
> As it becomes clear that the specification is being accepted  
> completely
> or by-and-large by the community, nothing would stop people from
> starting adapting to the new API (using the reference  
> implementation or
> porting it) and using it in their projects prior to it's final  
> community and
> JCP approval, since approval is required only to make it official and
> get the "100% pure java" certification for platform ports.
>
> You have one idea already.  Why don't you implement it, solicit some
> design feedback from Sun and the RXTX, and create a functional
> implementation that addresses the needs of the community, then
> we can document it and open a JSR.  That's it.  It should march  
> through
> the approval stages reasonably quickly I would imagine, and meantime
> RXTX could start using it.
>
> Paul
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From paul.klissner at sun.com  Fri Jun  2 14:38:49 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 13:38:49 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
	<44807ED6.8000903@sun.com>
	<6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>
Message-ID: <4480A1D9.5060106@sun.com>

Joachim Buechse wrote:
> Hello Paul,
>
> of course, the basic change I suggested could be done "hidden".  The  
> CommProvider interface could live somewhere in sun.xyz.*
> The setCustomCommProvider method would not be in CommPortIdentifier  
> but also somewhere in sun.xyz.* This would be an unofficial feature,  
> the official interface stays exactly the same. However RXTX (and  
> others) could access the hidden interface.
>
> Don't get me wrong, I don't want to harass you into making changes  
> you don't like (which probably wouldn't work anyway;-). But I'm a  
> long time Java programmer and seeing the state of cross platform  
> serial support for Java makes me feel really sad. In fact, when I  
> started to look into Java serial port programming some months ago I  
> was very surprised that javax.comm never made it into the JDK.
>
> I'm sorry that I did not contribute my feedback to the JSR for  
> javax.comm 3.0. 
There was no JSR for 3.0, because we didn't have the resources to make 
the commitment.
Yet Sun needed to add support for platform-dependent port name mapping, 
which had to
be done 'under the hood', since the API isn't designed to handle that in 
a pluggable way.
But these quick fixes aren't the right approach, they just kick the dog 
down the road,
setting bad precedent, inviting confusion and more intractable problems 
(such as the
one plaguing us now).

My changes could have been layered better, it was a trade off between 
achieving an
ideal architecture, trying to find internal reviewers, and meet the 
needs of big customers
in a timely way.  Thus my namespace changes collided with RXTX's 
dependencies.
I was unaware of Jagane's rogue agreement made with the RXTX community 7 
years ago,
before Jagane left Sun.  I think this was a wag-the-dog situation.

Now it is time to do it right, and I don't think it is going to be as 
much trouble as people
some people fear. If RXTX wants to sponsor the JSR and seed a new spec, 
Sun can join
the Expert Group.  And we'd be largely in agreement, since we're not 
talking about
humongous changes, and looking for mutually beneficial changes. The core 
API is already
largely proved and tested.
> However at the time I didn't do serial port  
> programming in Java. I agree that a new JSR should be opened - I'm  
> not an expert on JSRs or the JCP process, but from looking quickly  
> over the progress of some JSRs I would be very surprised if we can  
> have a new version in less then a year. 
*Approved*  But that doesn't mean the spec couldn't be 99.9% stable 
before that.  Once
the delta rate declines and changes approach nil, people could start 
adapting to the API in
advance of formal approval.   It isn't going to be drawn out like 
javax.usb, which was new
technology, a very complex API, and involved precedent setting corporate 
disputes and
policy issues to resolve.

> In the meanwhile some people  
> will start using javax.comm 3.0 (which can not be supported by RXTX),  
> some will use javax.comm 2.0 (which means the 2.0.7 release of RXTX  
> still needs to be maintained). This may get even worse if eg Apple  
> decides to port and include javax.comm 3.0 at which point it may get  
> very tricky to write a cross platform Java application.
>   
The interfaces haven't changed since 1.0.  If we open a JSR ,we can 
contact Apple and
allow them to be on the E.G., if they want.  That might make the JSR a 
bit more drawn out,
but then we'd arrive ultimately arrive at a best-of-all-worlds API that 
most people would
accept, perhaps forever, and arrive at a respectable set of compromises.

-Paul

> All of this simply means, that we are loosing a lot of man-power that  
> could otherwise be invested in building a clean solution and/or to  
> add features that are becoming more and more important (USB events...).
>
> In the automation / machine control universe Java makes a lot of  
> sense. Right now many people are migrating to Linux or from  
> propietary systems (even DOS) to Windows. Writing the control/ 
> configuration applications in Java is the kings way to unify the code  
> base.
>
> Best regards,
> Joachim
>
>
> On 02.06.2006, at 20:09, Paul Klissner wrote:
>
>   
>> Joachim Buechse wrote:
>>     
>>> Good day Paul!
>>>
>>> A clean architecture with loadable drivers and reusable code would be
>>> very beneficial for the future, I think everybody agrees. However
>>> this could be several years into the future. In the meantime, there
>>> is a real existing problem with IO support on Java. I have the strong
>>> feeling that most programmers want to code against one specification
>>> (javax.comm) and be able to replace the underlying implementation via
>>> a "plugin" on platforms where the SUN implementation is not
>>> sufficient. RXTX could be just this plugin (reusing very close to 0%
>>> of the javax.comm implementation but 100% of its API).
>>>
>>> I want to propose an API addition and implementation change that will
>>> take less then 2 hours of manpower to implement and create a solution
>>> that can bridge the years until javax.comm has been based on a new
>>> architecture.
>>>
>>> Looking at the javax.comm api at http://java.sun.com/products/
>>> javacomm/reference/api/index.html I would like to propose the  
>>> following:
>>>
>>> The only entry point to javax.comm is CommPortIdentifier. It has 3
>>> static methods plus the constructor.
>>>
>>> 1) define one additional Interface
>>>
>>> public interface CommProvider {
>>>     CommPortIdentifier getPortIdentifier(CommPort port);
>>>     CommPortIdentifier getPortIdentifier(String portName);
>>>     Enumeration getPortIdentifiers ();
>>> }
>>>
>>> 2) add one method to CommPortIdentifier
>>>
>>>    public static setCustomCommProvider (CommProvider);
>>>
>>> 3) change the three static methods of CommPortIdentifier to dispatch
>>> to the CommProvider if it is set
>>>
>>> 4) change the constructor of CommPortIdentifier to
>>>
>>>    public CommPortIdentifier(...) {
>>>       if (isProviderSet && this.getClass() ==
>>> javax.comm.CommPortIdentifier) {
>>>           throw new RuntimeException("illegal creation of
>>> CommPortIndentifier, custom CommProvider is in use");
>>>       }
>>>
>>> 5) (this is optional, but would be very nice) automatically set a
>>> custom CommProvider if it is found on the classpath or defined via a
>>> system property.
>>>
>>>
>>> The above 1) - 4) can be implemented in less than 1hour. 5) may take
>>> another hour. I agree that this is not the most elegant design, but
>>> it would solve a lot of problems with very little effort. It would
>>> certainly allow RXTX to move forward. If the javax.comm API needs to
>>> be redesigned completely this addition will not hurt, as people will
>>> move to the new API anyway and javax.comm 3.0 was so far never
>>> included in the main distribution.
>>>
>>> Best regards,
>>> Joachi
>>>       
>> I'm afraid modifying the interface classes isn't my call.  There was
>> actually
>> a TCK written and one of the tests was to ensure that the interface  
>> classes
>> match the spec.  Thus my hands have already been tied since this  
>> project
>> was essentially grandfathered into the JCP.
>>
>> That's why we need to open a new JSR and find someone who wants
>> to be the spec lead, and go in with a new reference implementation.
>> I'm not sure why it would have to take years, since this isn't  
>> bleeding edge
>> technology and there are only so many things that can be done with it,
>> and we already have practical experience about many functional aspects
>> that we could cite precedence on.
>>
>> As it becomes clear that the specification is being accepted  
>> completely
>> or by-and-large by the community, nothing would stop people from
>> starting adapting to the new API (using the reference  
>> implementation or
>> porting it) and using it in their projects prior to it's final  
>> community and
>> JCP approval, since approval is required only to make it official and
>> get the "100% pure java" certification for platform ports.
>>
>> You have one idea already.  Why don't you implement it, solicit some
>> design feedback from Sun and the RXTX, and create a functional
>> implementation that addresses the needs of the community, then
>> we can document it and open a JSR.  That's it.  It should march  
>> through
>> the approval stages reasonably quickly I would imagine, and meantime
>> RXTX could start using it.
>>
>> Paul
>>
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at 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  Sat Jun  3 18:15:24 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 18:15:24 -0600 (MDT)
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
Message-ID: <Pine.LNX.4.61.0606031715100.10890@www>


The attached patch allows baud rates of 14400, 28800, 128000 and 256000.

That was my goal.

[import standard disclaimer]

But I took some time to look a little further.  I got custom baud rates 
working enough that someone (perhaps me) can properly fix them in the 
future.  Proof of concept.

As an undocumented bonus, you can toss random baudrates (say 1953), at the 
API and it will set it to something close to that on windows and linux. 
Solaris should say the baud rate is not supported but I have not tested it 
yet.  Mac OS X behavior is unknown at this point.  Just dont expect 
correct behavior at ~8192-9009 baudrates or baudrates less than 20 on 
windows; these baud rates overlap with defines in win32termios.h.  I 
conveniently closed my eyes there.  Try another value close.  On Linux, a 
baud base and divisor are guestimated and set.  On windows, we wave pixie 
dust over the kernel driver and hope.  Do not expect pixie dust and 
guestimates to be the same on windows and linux.  They may well round to 
different values in yet to be tested ways.  There are only so many 
divisors.  If it isn't working, try a little higher or lower.

In the example of 1953 for instance, there is no divisor for commodity 
hardware that comes to that baudrate.  We just come close on one side or 
the other.  If tools tell you they got 1953 exactly, the tools may be 
questionable and just reading values not directly related to the actual 
hardware settings.

These fixes have been tested on Linux and Windows while using an 
oscilloscope to confirm they change relative to known baudrates at 9600, 
14400*, 19200, 28800* (and 1800, 1953** and 2400).

* = previously unsupported.
** = still not supported but probably works from what I saw.

There could be future discussion in this area.  For now this is working 
for almost all unusual baud rate demands.  Cleaning up the custom baud 
rate should be easier with a working starting point.  Baud bases other 
than 128000 have not been characterized.  Yes.. this overlapps with two of 
the baud rates enabled.

Feedback and ideas are welcome.

--
Trent Jarvi
tjarvi at qbang.org
-------------- next part --------------
Index: SerialImp.c
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v
retrieving revision 1.46.2.187
diff -u -r1.46.2.187 SerialImp.c
--- SerialImp.c	29 Jan 2006 22:19:04 -0000	1.46.2.187
+++ SerialImp.c	3 Jun 2006 23:12:40 -0000
@@ -793,6 +793,19 @@
 		result &= ~TIOCM_DTR;
 		ioctl( fd, TIOCMSET, &result );
 	}
+	/*
+	   B38400 is a special case in Linux for custom baud rates.
+
+	   We just treat this as a custom speed for now.  If you take this ifdef
+	   out and select baud rates 38400 then 28800 then 38400, you will get
+	   a final baud rate of 28800 because you did not update the divisor.
+
+	   See the next ifdef below for the divisor.
+	*/
+#if defined(TIOCGSERIAL)
+	if ( cspeed == B38400 )
+		cspeed = 38400;
+#endif /* TIOCGSERIAL */
 	if(     cfsetispeed( &ttyset, cspeed ) < 0 ||
 		cfsetospeed( &ttyset, cspeed ) < 0 )
 	{
@@ -814,6 +827,7 @@
 		*/
 
 #if defined(TIOCGSERIAL)
+		ioctl( fd, TIOCGSERIAL, &sstruct );
 		sstruct.custom_divisor = ( sstruct.baud_base/cspeed );
 		cspeed = B38400;
 #endif /* TIOCGSERIAL */
@@ -827,7 +841,7 @@
 #if defined(TIOCSSERIAL)
 		/*  It is assumed Win32 does this for us */
 		if (	sstruct.baud_base < 1 ||
-			ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
+		ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
 		{
 			return( 1 );
 		}
Index: termios.c
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v
retrieving revision 1.9.2.56
diff -u -r1.9.2.56 termios.c
--- termios.c	16 Jan 2006 02:50:32 -0000	1.9.2.56
+++ termios.c	3 Jun 2006 23:12:40 -0000
@@ -323,8 +323,8 @@
 		case CBR_3500000:	return( B3500000 );
 		case CBR_4000000:	return( B4000000 );
 		default:
-			set_errno(EINVAL );
-			return -1;
+			/* assume custom baudrate */
+			return( Baud );
 	}
 }
 
@@ -361,12 +361,13 @@
 		case B9600:	ret = CBR_9600;		break;
 		case B14400:	ret = CBR_14400;	break;
 		case B19200:	ret = CBR_19200;	break;
+		case B28800:	ret = CBR_28800;	break;
 		case B38400:	ret = CBR_38400;	break;
 		case B57600:	ret = CBR_57600;	break;
 		case B115200:	ret = CBR_115200;	break;
 		case B128000:	ret = CBR_128000;	break;
-		case B256000: 	ret = CBR_256000;	break;
 		case B230400:	ret = CBR_230400;	break;
+		case B256000: 	ret = CBR_256000;	break;
 		case B460800:	ret = CBR_460800;	break;
 		case B500000:	ret = CBR_500000;	break;
 		case B576000:	ret = CBR_576000;	break;
@@ -381,10 +382,8 @@
 		case B4000000:	ret = CBR_4000000;	break;
 	
 		default:
-			fprintf( stderr, "B_to_CBR: invalid baudrate: %#o\n",
-				Baud );
-			set_errno( EINVAL );
-			return -1;
+			/* assume custom baudrate */
+			return Baud;
 	}
 	LEAVE( "B_to_CBR" );
 	return ret;
@@ -708,12 +707,9 @@
 	ENTER( "init_serial_struct" );
 
 	/*
-	FIXME
-
-	This needs to use inb() to read the actual baud_base
-	and divisor from the UART registers.  Question is how
-	far do we take this?
-
+	use of custom_divisor and baud_base requires access to
+	kernel space.  The kernel does try its best if you just
+	toss a baud rate at it though.
 	*/
 
 	sstruct->custom_divisor = 0;
@@ -1678,16 +1674,17 @@
 {
 	char message[80];
 	ENTER( "cfsetospeed" );
+	/* clear baudrate */
+	s_termios->c_cflag &= ~CBAUD;
 	if ( speed & ~CBAUD )
 	{
 		sprintf( message, "cfsetospeed: not speed: %#o\n", speed );
 		report( message );
-		return 0;
+		/* continue assuming its a custom baudrate */
+		s_termios->c_cflag |= B38400;  /* use 38400 during custom */
+		s_termios->c_cflag |= CBAUDEX; /* use CBAUDEX for custom */
 	}
-	s_termios->c_ispeed = s_termios->c_ospeed = speed;
-	/* clear baudrate */
-	s_termios->c_cflag &= ~CBAUD;
-	if( speed )
+	else if( speed )
 	{
 		s_termios->c_cflag |= speed;
 	}
@@ -1696,6 +1693,7 @@
 		/* PC blows up with speed 0 handled in Java */
 		s_termios->c_cflag |= B9600;
 	}
+	s_termios->c_ispeed = s_termios->c_ospeed = speed;
 	LEAVE( "cfsetospeed" );
 	return 1;
 }
@@ -1767,25 +1765,6 @@
 }
 
 /*----------------------------------------------------------
-serial_struct_to_DCB()
-
-   accept:      
-   perform:     
-   return:      
-   exceptions:  
-   win32api:     None
-   comments:    
-----------------------------------------------------------*/
-int serial_struct_to_DCB( struct serial_struct *sstruct, DCB *dcb )
-{
-	/* 5 Baud rate fix
-	sstruct.baud_base
-	sstruct.custom_divisor = ( sstruct.baud_base/cspeed );
-	*/
-	return(0);
-}
-
-/*----------------------------------------------------------
 termios_to_DCB()
 
    accept:      
@@ -1798,7 +1777,8 @@
 int termios_to_DCB( struct termios *s_termios, DCB *dcb )
 {
 	ENTER( "termios_to_DCB" );
-	s_termios->c_ispeed = s_termios->c_ospeed = s_termios->c_cflag & CBAUD;
+	if ( !(s_termios->c_cflag & CBAUDEX) )
+		s_termios->c_ispeed = s_termios->c_ospeed = s_termios->c_cflag & CBAUD;
 	dcb->BaudRate        = B_to_CBR( s_termios->c_ispeed );
 	dcb->ByteSize = termios_to_bytesize( s_termios->c_cflag );
 
@@ -2863,11 +2843,6 @@
 			GetCommState( index->hComm, dcb );
 
 			index->sstruct = va_arg( ap, struct serial_struct * );
-			if ( serial_struct_to_DCB( index->sstruct, dcb ) < 0 )
-			{
-				va_end( ap );
-				return -1;
-			}
 
 			report( "TIOCSSERIAL\n" );
 			free(dcb);
Index: win32termios.h
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v
retrieving revision 1.5.2.28
diff -u -r1.5.2.28 win32termios.h
--- win32termios.h	30 Jun 2005 20:23:26 -0000	1.5.2.28
+++ win32termios.h	3 Jun 2006 23:12:40 -0000
@@ -279,7 +279,7 @@
 #define XTABS	01000000 /* Hmm.. Linux/i386 considers this part of TABDLY.. */
 
 /* c_cflag bit meaning */
-# define CBAUD	0010017
+#define  CBAUD  0030017
 #define  B0	0000000		/* hang up */
 #define  B50	0000001
 #define  B75	0000002
@@ -312,13 +312,16 @@
 #define  B3500000 0010016
 #define  B4000000 0010017
 
-/* glue for unsupported linux speeds see also SerialImp.h */
-/* hosed */
-
-#define B14400		1010001
-#define B28800		1010002
-#define B128000		1010003
-#define B256000		1010004
+/*
+	glue for unsupported linux speeds see also SerialImp.h 
+	custom baud rates around 8192-9000 will not work because
+	of these.
+*/
+
+#define B14400		0020001
+#define B28800		0020002
+#define B128000		0020003
+#define B256000		0020004
 
 #define EXTA B19200
 #define EXTB B38400
@@ -356,8 +359,10 @@
 
 /* glue for unsupported windows speeds */
 
-#define CBR_230400	230400
 #define CBR_28800	28800
+#define CBR_128000	128000
+#define CBR_230400	230400
+#define CBR_256000	256000
 #define CBR_460800	460800
 #define CBR_500000	500000
 #define CBR_576000	576000

From impakt01 at optusnet.com.au  Sat Jun  3 18:30:37 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 10:30:37 +1000
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
In-Reply-To: <Pine.LNX.4.61.0606031715100.10890@www>
Message-ID: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>

Hi Trent,
I'd love to try the patch but I can't get the latest build compiling, only
pre16. 

Can you attach the rxtxSerial.dll file with this patch?

Also, I hardcoded 1953 in a couple more places last night on pre16 and it
managed to open the port at the right speed, but stopped receiving anything
after 100-150 bytes, even though more data was getting sent to the port.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 10:15 AM
To: rxtx at qbang.org
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.


The attached patch allows baud rates of 14400, 28800, 128000 and 256000.

That was my goal.

[import standard disclaimer]

But I took some time to look a little further.  I got custom baud rates 
working enough that someone (perhaps me) can properly fix them in the 
future.  Proof of concept.

As an undocumented bonus, you can toss random baudrates (say 1953), at the 
API and it will set it to something close to that on windows and linux. 
Solaris should say the baud rate is not supported but I have not tested it 
yet.  Mac OS X behavior is unknown at this point.  Just dont expect 
correct behavior at ~8192-9009 baudrates or baudrates less than 20 on 
windows; these baud rates overlap with defines in win32termios.h.  I 
conveniently closed my eyes there.  Try another value close.  On Linux, a 
baud base and divisor are guestimated and set.  On windows, we wave pixie 
dust over the kernel driver and hope.  Do not expect pixie dust and 
guestimates to be the same on windows and linux.  They may well round to 
different values in yet to be tested ways.  There are only so many 
divisors.  If it isn't working, try a little higher or lower.

In the example of 1953 for instance, there is no divisor for commodity 
hardware that comes to that baudrate.  We just come close on one side or 
the other.  If tools tell you they got 1953 exactly, the tools may be 
questionable and just reading values not directly related to the actual 
hardware settings.

These fixes have been tested on Linux and Windows while using an 
oscilloscope to confirm they change relative to known baudrates at 9600, 
14400*, 19200, 28800* (and 1800, 1953** and 2400).

* = previously unsupported.
** = still not supported but probably works from what I saw.

There could be future discussion in this area.  For now this is working 
for almost all unusual baud rate demands.  Cleaning up the custom baud 
rate should be easier with a working starting point.  Baud bases other 
than 128000 have not been characterized.  Yes.. this overlapps with two of 
the baud rates enabled.

Feedback and ideas are welcome.

--
Trent Jarvi
tjarvi at qbang.org



From tjarvi at qbang.org  Sat Jun  3 19:05:11 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 19:05:11 -0600 (MDT)
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
In-Reply-To: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>
References: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606031840400.10890@www>

On Sun, 4 Jun 2006, Daren wrote:

> Hi Trent,
> I'd love to try the patch but I can't get the latest build compiling, only
> pre16.
>
> Can you attach the rxtxSerial.dll file with this patch?
>
> Also, I hardcoded 1953 in a couple more places last night on pre16 and it
> managed to open the port at the right speed, but stopped receiving anything
> after 100-150 bytes, even though more data was getting sent to the port.
>


ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing

I dont think they will hang.  But I was just testing via loopback/break 
out box/scope.

I'll be putting about 10 patches and another set of binaries in that 
directory shortly.  For now the binaries should just have the baud_rate 
fix.

I'll announce all the patches at once.  but wont be releasing 2.1-8 right 
away.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Sat Jun  3 21:00:01 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 21:00:01 -0600 (MDT)
Subject: [Rxtx] CVS for 2.1 should have everything
Message-ID: <Pine.LNX.4.61.0606032056190.10890@www>


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org


From impakt01 at optusnet.com.au  Sat Jun  3 21:08:14 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 13:08:14 +1000
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <Pine.LNX.4.61.0606032056190.10890@www>
Message-ID: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>

Hi Trent,
I tried the latest dll and it opens the port, receives 100-200 bytes and
then stops receiving anything else..

I'll keep playing with it.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 1:00 PM
To: rxtx at qbang.org
Subject: [Rxtx] CVS for 2.1 should have everything


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From impakt01 at optusnet.com.au  Sat Jun  3 21:22:41 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 13:22:41 +1000
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
Message-ID: <200606040322.k543MqW1008455@mail12.syd.optusnet.com.au>

Played with it, problem, with a while loop in my code, working great now

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Daren
Sent: Sunday, 4 June 2006 1:08 PM
To: 'RXTX Developers and Users'
Subject: Re: [Rxtx] CVS for 2.1 should have everything

Hi Trent,
I tried the latest dll and it opens the port, receives 100-200 bytes and
then stops receiving anything else..

I'll keep playing with it.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 1:00 PM
To: rxtx at qbang.org
Subject: [Rxtx] CVS for 2.1 should have everything


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Sat Jun  3 21:35:41 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 21:35:41 -0600 (MDT)
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
References: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606032131140.10890@www>

On Sun, 4 Jun 2006, Daren wrote:

> Hi Trent,
> I tried the latest dll and it opens the port, receives 100-200 bytes and
> then stops receiving anything else..
>
> I'll keep playing with it.
>
> Daren

The difference may be that I'm talking to something at the exact same baud 
rate (loopback).

You may also try setting the baudrate to ~1933 and ~1973 to force the 
guesses one way or the other.  If you are on windows, we are not doing 
anything fancy in the end.  Thats the kernel guessing.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sun Jun  4 04:12:09 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sun, 4 Jun 2006 12:12:09 +0200
Subject: [Rxtx] Update of OSX installer, Readme, etc
Message-ID: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>

Good day,

after the latest changes a lot of OS X specific files should be  
updated. Especially the installer!

- The "MaxOSX" readme file on the root level is outdated (ie  
CodeWarrior information). Maybe we could even rename it to README.OSX  
to be in line with README.IPAQ, README.SCO (Trent do you mind copying/ 
renaming ,v files in the repository?).

- The lock files are no longer used and hence the user group magic  
and lock folder creation should be removed from the installer.

- MACOSX_IDE/ForPackageMaker/Resources/ReadMe.rtf and Welcome.rtf  
need to be updated.

- I suggest to replace the current installation instruction for OS X:  
Installation should occur into the application directory, not in the  
Java-VM directory. This simplifies things a lot, as the Mac Installer  
can be removed completely.

- The xcodeproject's build settings need to be updated to generate  
JAVA 1.1 format class files.


Dimitry: do you have time to tackle this? I could do it, but as this  
is "your baby" I thought you may prefer to do it yourself.

Regards,
Joachim



From dmarkman at mac.com  Sun Jun  4 11:27:53 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Sun, 4 Jun 2006 13:27:53 -0400
Subject: [Rxtx] Update of OSX installer, Readme, etc
In-Reply-To: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
References: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
Message-ID: <26E7A202-962B-4C19-93B6-29426C467249@mac.com>

Joachim,
unfortunately I don't have time right now to do that
so if you can do that, please do

it's not only my baby
it's yours too :-)

thanks


On Jun 4, 2006, at 6:12 AM, Joachim Buechse wrote:

> Good day,
>
> after the latest changes a lot of OS X specific files should be
> updated. Especially the installer!
>
> - The "MaxOSX" readme file on the root level is outdated (ie
> CodeWarrior information). Maybe we could even rename it to README.OSX
> to be in line with README.IPAQ, README.SCO (Trent do you mind copying/
> renaming ,v files in the repository?).
>
> - The lock files are no longer used and hence the user group magic
> and lock folder creation should be removed from the installer.
>
> - MACOSX_IDE/ForPackageMaker/Resources/ReadMe.rtf and Welcome.rtf
> need to be updated.
>
> - I suggest to replace the current installation instruction for OS X:
> Installation should occur into the application directory, not in the
> Java-VM directory. This simplifies things a lot, as the Mac Installer
> can be removed completely.
>
> - The xcodeproject's build settings need to be updated to generate
> JAVA 1.1 format class files.
>
>
> Dimitry: do you have time to tackle this? I could do it, but as this
> is "your baby" I thought you may prefer to do it yourself.
>
> Regards,
> Joachim
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman



From tjarvi at qbang.org  Sun Jun  4 13:54:02 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 4 Jun 2006 13:54:02 -0600 (MDT)
Subject: [Rxtx] Update of OSX installer, Readme, etc
In-Reply-To: <26E7A202-962B-4C19-93B6-29426C467249@mac.com>
References: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
	<26E7A202-962B-4C19-93B6-29426C467249@mac.com>
Message-ID: <Pine.LNX.4.61.0606041353040.22522@www>

On Sun, 4 Jun 2006, Dmitry Markman wrote:

> Joachim,
> unfortunately I don't have time right now to do that
> so if you can do that, please do
>
> it's not only my baby
> it's yours too :-)
>

I've given Joachim cvs access.  He has shown good work in bugzilla.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Mon Jun  5 10:08:32 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 5 Jun 2006 18:08:32 +0200
Subject: [Rxtx] Build process changes for Mac OS X
Message-ID: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>

Good day,

I have cleaned up some outdated Mac OSX specific build files in the  
repository.

There was not a lot left of the readme file "MacOSX" after cleaning  
it up, so I decided to rename it README.OSX to be in harmony with the  
other files in the directory (ie README.IPAQ, README.SCO, ...)

I added an (uncompressed) XCode 2.3 project file/structure  
with .cvsignore files that will ignore the user specific settings.  
This should work "out of the box" for OSX10.4. Users of 10.2/10.3 may  
have to switch the build settings.

[It's kind of tricky to choose "the right" setting. Afaik there is no  
way to compile a universal binary that will work on 10.3 or before.  
So it's either UniversalBinary OR Legacy. Maybe we should have  
different build targets for these different targets?? I would like to  
get some feedback from the Mac developers on this list regarding the  
subject].

Besides other things the OSX installer is no longer required. Since  
the next version (2.1.8) will no longer use lockfiles on OSX, the  
group/permission magic is no longer required and hence there remains  
basicly no work for the installer - other than copying 2 files to the  
VM extension directory. Then again, this is not the best way to  
install RXTX. So I removed the installer completely without modifying  
it, this should simplify a "resurrection" should it ever get necessary.

I had problems with the (compressed, ie sit.hqx) legacy project files  
on the latest installation of OSX (javac 1.5 creating non JDK1.1  
class files and some minor problems). To reduce potential confusion  
for newcomers I decided to remove them. This means that there is no  
longer a simple way to build RXTX for OSX 10.0 and 10.1 (I deeply  
apologize if anyone still relied on this ... well the files are in  
the Attiq).

Best regards,
Joachim


From joachim at buechse.de  Mon Jun  5 10:16:37 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 5 Jun 2006 18:16:37 +0200
Subject: [Rxtx] RXTX and lockfiles on OSX [it is fixed now]
Message-ID: <7D2C4418-9397-4B59-8091-9FDE4ED67836@buechse.de>

Quite a number of people contacted me in the last couple of weeks  
because of problems installing RXTX on OSX. I told you to wait for  
the "official" fix. Well, it has been fixed.

So if you were among the people waiting for the solution, you can now  
download the source rxtx-2.1-7r2.zip from the website. Once unpacked  
dont forget to use "cvs up" to update the files to the latest  
version. You can then open MACOSX_IDE/XCode/ 
LibSerialUniversal.xcodeproj with XCode 2.3 and build the libraries  
that no longer try to create lock files.

Regards,
Joachim


From brian at mbari.org  Mon Jun  5 10:52:43 2006
From: brian at mbari.org (Brian Schlining)
Date: Mon, 5 Jun 2006 09:52:43 -0700
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
Message-ID: <78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>

Hi Joachim,

> [It's kind of tricky to choose "the right" setting. Afaik there is no
> way to compile a universal binary that will work on 10.3 or before.
> So it's either UniversalBinary OR Legacy. Maybe we should have
> different build targets for these different targets?? I would like to
> get some feedback from the Mac developers on this list regarding the
> subject].

I imagine most developers will be compiling on 10.4 (It's the nature  
of the coder...gotta have the latest and greatest) and deploying to  
both 10.3 and 10.4; both of which will run Universal Binaries (see  
http://forums.macrumors.com/showthread.php?t=205348). So it sounds  
like you've covered the majority of users. Still, you know someone's  
going to pipe up about needing RXTX on 10.2 so it would be nice to  
have a target to make a PPC only build.

Just my 2 cents

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/1cac8c39/attachment-0022.html

From dmarkman at mac.com  Mon Jun  5 13:47:50 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Mon, 5 Jun 2006 15:47:50 -0400
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
Message-ID: <686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>

I don't think it will be a problem to run universal binary
on 10.2
however if binary has some calls that aren't implemented in 10.2
then you'll have a problem


On Jun 5, 2006, at 12:52 PM, Brian Schlining wrote:

> Hi Joachim,
>
>> [It's kind of tricky to choose "the right" setting. Afaik there is no
>> way to compile a universal binary that will work on 10.3 or before.
>> So it's either UniversalBinary OR Legacy. Maybe we should have
>> different build targets for these different targets?? I would like to
>> get some feedback from the Mac developers on this list regarding the
>> subject].
>
> I imagine most developers will be compiling on 10.4 (It's the  
> nature of the coder...gotta have the latest and greatest) and  
> deploying to both 10.3 and 10.4; both of which will run Universal  
> Binaries (see http://forums.macrumors.com/showthread.php?t=205348).  
> So it sounds like you've covered the majority of users. Still, you  
> know someone's going to pipe up about needing RXTX on 10.2 so it  
> would be nice to have a target to make a PPC only build.
>
> Just my 2 cents
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/9fafc878/attachment-0022.html

From brian at mbari.org  Mon Jun  5 14:52:41 2006
From: brian at mbari.org (Brian Schlining)
Date: Mon, 5 Jun 2006 13:52:41 -0700
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
Message-ID: <E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>

Hi Dmitry,

> I don't think it will be a problem to run universal binary
> on 10.2
> however if binary has some calls that aren't implemented in 10.2
> then you'll have a problem

You're right...I stand corrected.

Note however, to deploy a universal binary to 10.2 RXTX will need to  
use the 10.2 SDK to build the PPC side. (see http:// 
developer.apple.com/documentation/DeveloperTools/Conceptual/ 
cross_development/UniversalBinaries/chapter_4_section_1.html). I  
haven't been paying close attention to the new locking mechanism used  
by RXTX on the Mac...does 10.2 support it?

Joachim, which SDK will you be using by default for building the Mac  
PPC binaries?

>> Hi Joachim,
>>
>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>> is no
>>> way to compile a universal binary that will work on 10.3 or before.
>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>> different build targets for these different targets?? I would  
>>> like to
>>> get some feedback from the Mac developers on this list regarding the
>>> subject].
>>
>> I imagine most developers will be compiling on 10.4 (It's the  
>> nature of the coder...gotta have the latest and greatest) and  
>> deploying to both 10.3 and 10.4; both of which will run Universal  
>> Binaries (see http://forums.macrumors.com/showthread.php? 
>> t=205348). So it sounds like you've covered the majority of users.  
>> Still, you know someone's going to pipe up about needing RXTX on  
>> 10.2 so it would be nice to have a target to make a PPC only build.

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/153bf50e/attachment-0022.html

From dmarkman at mac.com  Mon Jun  5 19:02:04 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Mon, 5 Jun 2006 21:02:04 -0400
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
Message-ID: <7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>

if Joachim didn't change xcode project setting

/Developer/SDKs/MacOSX10.4u.sdk is used to build universal binary

so it's quite possible that it won't run properly on 10.2

so we have to change the building process, so ppc part will be built
with
/Developer/SDKs/MacOSX10.2.8.sdk

and finally to use lipo utility to build universal binaries

Joachim, did you use some specific locking API that wasn't implemented

in MacOSX10.2.8.sdk?

thanks


On Jun 5, 2006, at 4:52 PM, Brian Schlining wrote:

> Hi Dmitry,
>
>> I don't think it will be a problem to run universal binary
>> on 10.2
>> however if binary has some calls that aren't implemented in 10.2
>> then you'll have a problem
>
> You're right...I stand corrected.
>
> Note however, to deploy a universal binary to 10.2 RXTX will need  
> to use the 10.2 SDK to build the PPC side. (see http:// 
> developer.apple.com/documentation/DeveloperTools/Conceptual/ 
> cross_development/UniversalBinaries/chapter_4_section_1.html). I  
> haven't been paying close attention to the new locking mechanism  
> used by RXTX on the Mac...does 10.2 support it?
>
> Joachim, which SDK will you be using by default for building the  
> Mac PPC binaries?
>
>>> Hi Joachim,
>>>
>>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>>> is no
>>>> way to compile a universal binary that will work on 10.3 or before.
>>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>>> different build targets for these different targets?? I would  
>>>> like to
>>>> get some feedback from the Mac developers on this list regarding  
>>>> the
>>>> subject].
>>>
>>> I imagine most developers will be compiling on 10.4 (It's the  
>>> nature of the coder...gotta have the latest and greatest) and  
>>> deploying to both 10.3 and 10.4; both of which will run Universal  
>>> Binaries (see http://forums.macrumors.com/showthread.php? 
>>> t=205348). So it sounds like you've covered the majority of  
>>> users. Still, you know someone's going to pipe up about needing  
>>> RXTX on 10.2 so it would be nice to have a target to make a PPC  
>>> only build.
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/84790f80/attachment-0022.html

From joachim at buechse.de  Tue Jun  6 02:40:47 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 6 Jun 2006 10:40:47 +0200
Subject: [Rxtx] Building on OS X, Impl Changes
In-Reply-To: <7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
Message-ID: <CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>

Good day!

What's in the XCode project setting?
----------

The xcode project remained pretty much the same as before. I excluded  
the user specific files from CVS and changed some settings. I kept  
all the built targets (you shouldn't change what you don't understand;-)

Currently we the following build targets:
    RXTXComm (java files)
    librxtxParallel.jnilib (usefull on the Mac???)
    libI2C.jnilib (not yet working in RXTX)
    libRS485.jnilib (not yet working in RXTX)
    librxtxSerial.jnilib (1)
    librxtxSerial.jnilib Dynamic (2)
    rxtxSerial (3)
We also have the following build configurations for each target:
    Development
    Default
    Deployment

What was changed in the xcode project from previous versions:
- java.souce=1.3 and java.target=1.1 in RXTXComm settings
- removed copying of build products into installer directory
- removed "(Upgraded)" from build target names

What remains to be changed:
- choosing a "non-debug" Build-configuration as default
- potentially removing "Default"/"Development" Build-configurations
- reducing the number of build targets
- creating 10.2 compatible universal binaries

I suggest, that the build configurations should be reduced to 2  
(Debug/Deployment), possibly even 1 (Debug).
I have not yet found the deeper meaning of the build targets(1)(2) 
(3), it seems to me like they should be reduced into one "doing the  
right thing" or maybe into two "rxtxSerial.jnilib Legacy" (back to  
10.2, universal if possible) and "rxtxSerial.jnilib 10.4 
+" (universal, 10.4+).

Should the code work on 10.2?
----------

Absolutely. The code should work on NextStep, in fact on any BSD  
unix. I would go as far as saying, this code should work on any  
POSSIX based unix. All that was added is the call "ioctl(fd,  
TIOCEXCL)" to request excusivity of the port:

http://gemma.apple.com/documentation/DeviceDrivers/Conceptual/ 
WorkingWSerial/WWSerial_SerialDevs/chapter_2_section_8.html

It is not yet "the perfect solution". Normally an open /dev/tty  
(listen for incomming connection) should be "preemptable" by opening  
a /dev/cu (outgoing connection) for the same port. This is not yet  
implemented as it needs calls outside of POSSIX on OSX.

On "classic" systems (like NextStep) this worked based on the  
"carried detect line". open() on /dev/tty.xxx would block until the  
carrier detect signal was raised. As the device was not "opened"  
opening /dev/cu.xxx worked without a hitch. When they ported to the  
Mac this broke. On Macs the "carier detect" is usually not wired.  
Furthermore FAX modems did no longer raise the line. So the OSX  
implementor defined a new call, which is documented here:

http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00045.html

Best regards,
Joachim




On 06.06.2006, at 03:02, Dmitry Markman wrote:

> if Joachim didn't change xcode project setting
>
> /Developer/SDKs/MacOSX10.4u.sdk is used to build universal binary
>
> so it's quite possible that it won't run properly on 10.2
>
> so we have to change the building process, so ppc part will be built
> with
> /Developer/SDKs/MacOSX10.2.8.sdk
>
> and finally to use lipo utility to build universal binaries
>
> Joachim, did you use some specific locking API that wasn't implemented
>
> in MacOSX10.2.8.sdk?
>
> thanks
>
>
> On Jun 5, 2006, at 4:52 PM, Brian Schlining wrote:
>
>> Hi Dmitry,
>>
>>> I don't think it will be a problem to run universal binary
>>> on 10.2
>>> however if binary has some calls that aren't implemented in 10.2
>>> then you'll have a problem
>>
>> You're right...I stand corrected.
>>
>> Note however, to deploy a universal binary to 10.2 RXTX will need  
>> to use the 10.2 SDK to build the PPC side. (see http:// 
>> developer.apple.com/documentation/DeveloperTools/Conceptual/ 
>> cross_development/UniversalBinaries/chapter_4_section_1.html). I  
>> haven't been paying close attention to the new locking mechanism  
>> used by RXTX on the Mac...does 10.2 support it?
>>
>> Joachim, which SDK will you be using by default for building the  
>> Mac PPC binaries?
>>
>>>> Hi Joachim,
>>>>
>>>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>>>> is no
>>>>> way to compile a universal binary that will work on 10.3 or  
>>>>> before.
>>>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>>>> different build targets for these different targets?? I would  
>>>>> like to
>>>>> get some feedback from the Mac developers on this list  
>>>>> regarding the
>>>>> subject].
>>>>
>>>> I imagine most developers will be compiling on 10.4 (It's the  
>>>> nature of the coder...gotta have the latest and greatest) and  
>>>> deploying to both 10.3 and 10.4; both of which will run  
>>>> Universal Binaries (see http://forums.macrumors.com/ 
>>>> showthread.php?t=205348). So it sounds like you've covered the  
>>>> majority of users. Still, you know someone's going to pipe up  
>>>> about needing RXTX on 10.2 so it would be nice to have a target  
>>>> to make a PPC only build.
>>
>> Brian Schlining
>> Software Engineer
>> http://www.mbari.org
>>
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> Dmitry Markman
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Tue Jun  6 07:01:06 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 6 Jun 2006 15:01:06 +0200
Subject: [Rxtx] Serial port code for OS X, future steps
In-Reply-To: <CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
	<CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
Message-ID: <8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>

I posted the "wrong link". There is a correction here:

    http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00059.html

In fact, the 2.1.7 implementation of RXTX has quite some deficiencies  
on OSX. I have tried to supply some patches that don't interfere to  
much with the existing RXTX code base, but there are limits to what  
can be done with local patches.

There are some very intrusive changes that should be done. Ie proper  
mapping of /dev/tty <-> /dev/cu handling to correct behaviour of  
CommPortOwnershipListener (http://java.sun.com/products/javacomm/ 
reference/api/index.html). I dont think this can be done with  
patches. Hence I think, RXTX should be rewritten from scratch de- 
unifying the native code base (and implementing thread safe code on  
the Java side).


How "should" /dev/tty vs /dev/cu be implemented?

=====
The Unix contract is this: An open /dev/tty.xxx port (incomming)  
should be interrupted/auto-closed when opening /dev/cu.xxx (outgoing)  
[if /dev/tty.xxx is not currently handling a communication].  /dev/ 
cu.xxx and /dev/tty.xxx refer to the same device, so owning  
"exclusively" should block both. This should be respected across all  
applications native or Java.

This contract is realizable on OSX with the existing javax.comm  
interface while also respecting (to the biggest part) the contract  
defined by javax.comm.PortOwnershipListener.

The one point where the suggested implementation "breaks" the  
javax.comm contract, is by the fact that one can loose a /dev/tty  
port without calling close. However, the only option I see is to  
always open serial ports "non-exclusively" which would outrule Java  
as a platform for (dormant) applications waiting for incoming  
connections/faxes/etc. There could be a system property to choose the  
intended behavior.
=====

Here is how it could be done on OSX:

Calling port=ComportIdentifier.open("/dev/cu.xxx") opens and owns the  
port exclusively until port.close() is called.
- Java applications listening with a PortOwnershipListener should get  
a PORT_OWNED event reasonably soon.
- Any further attempt by a Java or native application to open "/dev/ 
cu.xxx" or "/dev/tty.xxx" fails.
- /dev/cu.xxx is for "outgoing" connections, so receiving  
PORT_OWNERSHIP_REQUESTED makes little to no sense. With native  
applications it can not be implemented. For Java applications it  
could be implemented (by a hidden communication channel). I think  
it's not worth bothering. If anyone is willing to give up a port to  
others he should use /dev/tty.xxx instead of /dev/cu.xxx.

Registering a PortOwnershipListener on "/dev/cu.xxx" without opening  
it, uses /dev/tty.xxx (native open()) non-exclusively and polls its  
state. PORT_OWNED and PORT_UNOWNED can be produced.

Calling port=ComportIdentifier.open("/dev/tty.xxx") should open the  
port non-exclusively.
- Adding a SerialPortEventListener and reading from the port could be  
allowed while keeping it non-exclusive.
- When port.getOutputStream() is called, the state should be changed  
to an "exclusive" ownership. This may be configurable via a system  
property.
- To return to the non-exclusive state the port must be closed and  
reopened.
- While non-exclusively opened, opening the corresponding /dev/cu.xxx  
produces a PORT_OWNERSHIP_REQUESTED event. Which should be responded  
by closing the port from within the callback (as described in  
java.comm.PortOwnershipListener). If there is a pending read, it will  
return after the listener finishes (with -1 or "0 bytes read").
- Calling write() on the /dev/tty.xxx after somebody opened /dev/ 
cu.xxx will fail with a descriptive IOException.
- Calling read() on the /dev/tty.xxx after somebody opened /dev/ 
cu.xxx will fail with a descriptive IOException (or potentially  
block, see side notes below).

CommPortIdentifier.getCurrentOwner() can be implemented by an  
external call to lsof.

CommPortIdentifier.isCurrentlyOwned() can be implemented by trying an  
open on the /dev/tty.
- It returns true if the port is currently held "exclusively".
- Whether it should also return true on /dev/tty if /dev/tty is  
already opened non-exclusively might be a system property option. In  
general, having several applications waiting for incoming connections  
on the same port will require an application level "arbitration"  
protocol...

[[side note1: One interesting question is, what happens if the  
process holding /dev/tty non-exclusively ignores  
PORT_OWNERSHIP_REQUESTED. Ie after "loosing" a non-exclusively opened  
"dev/tty.xxx" port to another process. One possible implementation  
is, that the port is "regained" when the other process gives up the  
port. This would mean that in the meanwhile read() returns no data,  
and any changes to the configuration of the port are stored but not  
forwarded. I guess, the safe (and simple) way to do this is to make  
the close() mandatory (ie setting the port into an "awaiting_close"  
state which produces IOExceptions to any other call than close). ]]

[[side note2:  Another interesting question is, what should happen if  
several applications open the same /dev/tty.xxx port "non- 
exclusively" and start to change the settings of the device.]]

Regards,
Joachim



On 06.06.2006, at 10:40, Joachim Buechse wrote:

> Should the code work on 10.2?
> ----------
>
> Absolutely. The code should work on NextStep, in fact on any BSD
> unix. I would go as far as saying, this code should work on any
> POSSIX based unix. All that was added is the call "ioctl(fd,
> TIOCEXCL)" to request excusivity of the port:
>
> http://gemma.apple.com/documentation/DeviceDrivers/Conceptual/
> WorkingWSerial/WWSerial_SerialDevs/chapter_2_section_8.html
>
> It is not yet "the perfect solution". Normally an open /dev/tty
> (listen for incomming connection) should be "preemptable" by opening
> a /dev/cu (outgoing connection) for the same port. This is not yet
> implemented as it needs calls outside of POSSIX on OSX.
>
> On "classic" systems (like NextStep) this worked based on the
> "carried detect line". open() on /dev/tty.xxx would block until the
> carrier detect signal was raised. As the device was not "opened"
> opening /dev/cu.xxx worked without a hitch. When they ported to the
> Mac this broke. On Macs the "carier detect" is usually not wired.
> Furthermore FAX modems did no longer raise the line. So the OSX
> implementor defined a new call, which is documented here:
>
> http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00045.html
>
> Best regards,
> Joachim



From sds at dcs.gla.ac.uk  Tue Jun  6 11:22:45 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Tue, 06 Jun 2006 18:22:45 +0100
Subject: [Rxtx] Correct compile flag for HP iPAQ hx4700 running Familiar
	Linux?
Message-ID: <1149614565.19496.10.camel@addu>

Hi,

I'd like to use RXTX 2.1 on my HP iPAQ hx4700. The iPAQ is running
Familiar Linux 0.8.2 (as I recall), with Blackdown Java 1.3.1.

I can compile and run a test program which uses RXTX on my i686 machine,
and it works fine. But I can't seem to get things working quite right on
my PDA.

I compile the code on the laptop with the following commands:
	./configure --host=arm-gnu-linux && make
... as suggested in a post to this list, albeit some time ago. This
compiles, I transfer the files, set up LD_LIBRARY_PATH and CLASSPATH
variables, and get the following error on the PDA:

sds at ipaq-pxa-2:~# java Test
java.lang.UnsatisfiedLinkError: /usr/local/lib/ext/librxtxSerial.so: /usr/local/lib/ext/librxtxSerial.so: cannot open shared object file: No such file or directory thrown while loading gnu.io.RXTXCommDriver
Exception in thread "main"
java.lang.UnsatisfiedLinkError: /usr/local/lib/ext/librxtxSerial.so: /usr/local/lib/ext/librxtxSerial.so: cannot open shared object file: No such file or directory
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1382)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1290)
        at java.lang.Runtime.loadLibrary0(Runtime.java:749)
        at java.lang.System.loadLibrary(System.java:820)
        at
gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:83)
        at Test.<init>(Test.java:9)
        at Test.main(Test.java:32)
sds at ipaq-pxa-2:~# 

Note that I'm copying the files to /usr/local/lib/ext/ along with the
RXTXcomm.jar file, purely to keep things separate from the rest of the
system while testing. The location of the .so files doesn't seem to have
any bearing on whether "java Test" will succeed or not. The contents of
this directory are:

sds at ipaq-pxa-2:~$ ls /usr/local/lib/ext/
RXTXcomm.jar              librxtxParallel-2.1-7.so  librxtxRS485.so
librxtxSerial-2.1-7.so
librxtxI2C-2.1-7.so       librxtxParallel.so        librxtxRaw-2.1-7.so
librxtxSerial.so
librxtxI2C.so             librxtxRS485-2.1-7.so     librxtxRaw.so
sds at ipaq-pxa-2:~$

Test.java fails on the first real line of code I'm using to test that
things are working, prior to real development, and was carefully pinched
from the web:
Enumeration portIdentifiers = CommPortIdentifier.getPortIdentifiers();


I assume that I've gotten my --host flag wrong way back up there at
the ./configure step. But if that's the case, what should I set it to?
Or am I missing something more obvious?


Cheers,
Stephen Strowes,
University of Glasgow.




From tjarvi at qbang.org  Tue Jun  6 13:39:41 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 6 Jun 2006 13:39:41 -0600 (MDT)
Subject: [Rxtx] Serial port code for OS X, future steps
In-Reply-To: <8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
	<CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
	<8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>
Message-ID: <Pine.LNX.4.61.0606061315070.9856@www>


>>
There are some very intrusive changes that should be done. Ie proper
mapping of /dev/tty <-> /dev/cu handling to correct behaviour of
CommPortOwnershipListener (http://java.sun.com/products/javacomm/
reference/api/index.html). I dont think this can be done with
patches. Hence I think, RXTX should be rewritten from scratch de-
unifying the native code base (and implementing thread safe code on
the Java side).
<<

This appears to be a very small amount of functionality for a total 
rewrite.  The port ownership only needs maybe 3 native calls if it is done 
with native calls at all.

Those features which are not part of the Unix standard(s) can be special 
cased.  I'm not sure /dev/cu is standard.  We can look.  I know linux 
deprecated /dev/cua years ago.

Thread safe Java code is not a platform specific issue.

--
Trent Jarvi
tjarvi at qbang.org


From sds at dcs.gla.ac.uk  Wed Jun  7 12:36:43 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Wed, 07 Jun 2006 19:36:43 +0100
Subject: [Rxtx] Expected RXTX behaviour?
In-Reply-To: <1149703900.30891.19.camel@addu>
References: <1149703900.30891.19.camel@addu>
Message-ID: <1149705403.30891.25.camel@addu>

Apologies, caught the problem. Had to append '\r' to the end of the AT
string. A non obvious but stupid mistake... :-)

Final quick question though: How might I stop the echoing of
outputStream data back into the inputStream? I still see the ATI
commands on the inputStream, along with the output from the device.


Cheers,
S.



On Wed, 2006-06-07 at 19:11 +0100, Stephen Strowes wrote:
> Hi,
> 
> I managed to get RXTX to compile for my iPAQ following my previous post
> to this list. Quick query though:
> 
> I want to be able to issue AT commands to a device, and interpret the
> responses. For this, I assume I do the following, in psuedo-form:
> 
> 	CommPortIdentifier.getPortIdentifiers();
> 	// find the correct device id
> 	serialPort= (SerialPort)portID.open("Test");
> 	// Set parameters and flow control
> 	outputStream= serialPort.getOutputStream();
> 	inputStream=  serialPort.getInputStream();
> 
> ... following this, I spawn a thread to respond to DATA_AVAILABLE events
> on serialPort with inputStream, and occasionally write and flush an
> "ATI" onto the outputStream. Nothing complex, I just want to see it
> work.
> 
> I would have expected inputStream to give the same information back from
> an "ATI" command as minicom provides, but instead inputStream only sees
> the "ATI" I put onto the outputStream.
> 
> Have I missed something?
> 
> 
> Cheers,
> S.
> 



From sds at dcs.gla.ac.uk  Wed Jun  7 12:11:40 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Wed, 07 Jun 2006 19:11:40 +0100
Subject: [Rxtx] Expected RXTX behaviour?
Message-ID: <1149703900.30891.19.camel@addu>

Hi,

I managed to get RXTX to compile for my iPAQ following my previous post
to this list. Quick query though:

I want to be able to issue AT commands to a device, and interpret the
responses. For this, I assume I do the following, in psuedo-form:

	CommPortIdentifier.getPortIdentifiers();
	// find the correct device id
	serialPort= (SerialPort)portID.open("Test");
	// Set parameters and flow control
	outputStream= serialPort.getOutputStream();
	inputStream=  serialPort.getInputStream();

... following this, I spawn a thread to respond to DATA_AVAILABLE events
on serialPort with inputStream, and occasionally write and flush an
"ATI" onto the outputStream. Nothing complex, I just want to see it
work.

I would have expected inputStream to give the same information back from
an "ATI" command as minicom provides, but instead inputStream only sees
the "ATI" I put onto the outputStream.

Have I missed something?


Cheers,
S.




From joachim at buechse.de  Wed Jun  7 09:02:13 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 7 Jun 2006 17:02:13 +0200
Subject: [Rxtx] Update of build process for OSX (XCode project)
Message-ID: <62EC47B1-46BD-4ECA-B9EC-C4061D147CDA@buechse.de>

With the help of Dmitry Markman and Brian Schilling I have updated  
(and largely simplifed) the XCode project file for Mac OS X.

Changes:
- compiles a universal binary library with intel=OSX10.4+, ppc=OSX10.2 
+ support
- compiles the Java sources into a JRE1.1 compatible, compressed jar.

Please test on your configuration, especially if you have computers  
running 10.2/10.3 or intel.

Best regards,
Joachim


From joachim at buechse.de  Wed Jun  7 14:36:37 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 7 Jun 2006 22:36:37 +0200
Subject: [Rxtx] Expected RXTX behaviour?
In-Reply-To: <1149705403.30891.25.camel@addu>
References: <1149703900.30891.19.camel@addu> <1149705403.30891.25.camel@addu>
Message-ID: <D3AD6EAF-27BB-455E-9697-86C1121920C3@buechse.de>

Echoing is a feature of the modem. Try ATE0 which works with most  
"rockwell" compatible modems.

Regards,
Joachim


On 07.06.2006, at 20:36, Stephen Strowes wrote:

> Apologies, caught the problem. Had to append '\r' to the end of the AT
> string. A non obvious but stupid mistake... :-)
>
> Final quick question though: How might I stop the echoing of
> outputStream data back into the inputStream? I still see the ATI
> commands on the inputStream, along with the output from the device.
>
>
> Cheers,
> S.
>
>
>
> On Wed, 2006-06-07 at 19:11 +0100, Stephen Strowes wrote:
>> Hi,
>>
>> I managed to get RXTX to compile for my iPAQ following my previous  
>> post
>> to this list. Quick query though:
>>
>> I want to be able to issue AT commands to a device, and interpret the
>> responses. For this, I assume I do the following, in psuedo-form:
>>
>> 	CommPortIdentifier.getPortIdentifiers();
>> 	// find the correct device id
>> 	serialPort= (SerialPort)portID.open("Test");
>> 	// Set parameters and flow control
>> 	outputStream= serialPort.getOutputStream();
>> 	inputStream=  serialPort.getInputStream();
>>
>> ... following this, I spawn a thread to respond to DATA_AVAILABLE  
>> events
>> on serialPort with inputStream, and occasionally write and flush an
>> "ATI" onto the outputStream. Nothing complex, I just want to see it
>> work.
>>
>> I would have expected inputStream to give the same information  
>> back from
>> an "ATI" command as minicom provides, but instead inputStream only  
>> sees
>> the "ATI" I put onto the outputStream.
>>
>> Have I missed something?
>>
>>
>> Cheers,
>> S.
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From g_petrini at yahoo.it  Thu Jun  8 01:41:58 2006
From: g_petrini at yahoo.it (Giacomo Petrini)
Date: Thu, 8 Jun 2006 09:41:58 +0200 (CEST)
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from FieldTalk
Message-ID: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>

Hi,
I'm evaluating the library for the modbus protocol
from FieldTalk
(http://www.modbusdriver.com/fieldtalk/.
I'm using J2SE 5.0 and RXTX 2.1 on win XP.
The problem is that the modbus lib has a method (the
openProtocol method, but maybe there are others) tha
throws the
javax.comm.UnsupportedCommOperationException.
Now, in RXTX 2.1 the namespace has changed in gnu.io,
so the modbus library doesn't work anymore (it look
for things in javax.comm). I've already sent an email
to fieldtalk to see if they are aware of the problem.
The solution should be to use JavaComm + RXTX 2.0. But
I've read somewhere that JavaComm 2.0 does not work
with Java 5.0 and JavaComm 3.0 does not work with RXTX
2.0 so I don't know what to do.

Any ideas?

Thanks Jack

PS: can you make a CC to my personal email
(g_petrini at yahoo.it) too please?

Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 


From rxtx at tapastda.co.uk  Thu Jun  8 02:27:57 2006
From: rxtx at tapastda.co.uk (rxtx@tapastda.co.uk)
Date: Thu, 08 Jun 2006 09:27:57 +0100
Subject: [Rxtx] Win XP and Infrared based serial port
Message-ID: <4487DF8D.5050807@tapastda.co.uk>

I'm attempting to use RXTX 2.1.7 on Win XP with J2SE 5.0 to communicate with a
GSM mobile using a COM port. A peculiarity that I've seen is that whilst I can
communicate successfully with a mobile which uses an infrared based COM port
using the SUN provided javax.comm (v2.0) I cannot use RXTX because it fails to
read anything from the port (i.e. read timeout always occurs returning zero bytes).

I assumed that this could be the result of flow control problems and thus I've
tried setting either software or hardware based flow control on the port however
this has no affect.

Can you suggest any other port configuration changes which might be required to
make such a port work with RXTX.

Thanks
Stu
-- 
Stuart
Tapastda Limited


From tjarvi at qbang.org  Thu Jun  8 05:17:12 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 8 Jun 2006 05:17:12 -0600 (MDT)
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from
	FieldTalk
In-Reply-To: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
References: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606080504480.9856@www>

On Thu, 8 Jun 2006, Giacomo Petrini wrote:

> Hi,
> I'm evaluating the library for the modbus protocol
> from FieldTalk
> (http://www.modbusdriver.com/fieldtalk/.
> I'm using J2SE 5.0 and RXTX 2.1 on win XP.
> The problem is that the modbus lib has a method (the
> openProtocol method, but maybe there are others) tha
> throws the
> javax.comm.UnsupportedCommOperationException.
> Now, in RXTX 2.1 the namespace has changed in gnu.io,
> so the modbus library doesn't work anymore (it look
> for things in javax.comm). I've already sent an email
> to fieldtalk to see if they are aware of the problem.
> The solution should be to use JavaComm + RXTX 2.0. But
> I've read somewhere that JavaComm 2.0 does not work
> with Java 5.0 and JavaComm 3.0 does not work with RXTX
> 2.0 so I don't know what to do.
>
> Any ideas?
>
> Thanks Jack
>


Hi Jack

There are plans for Sun to rerelease JavaComm 2.0 mentioned in the rxtx 
mail-list archives.  When this happens rxtx will release a current rxtx 
2.0 library that works with it.

There are no dates promised by either side but rxtx will do it as soon as 
possible after Sun's rerelease.  Just to give you a feel for the time 
frame, this started last year and no significant progress has been made. 
There have been friendly talks pointing towards solutions (rerelease 2.0) 
but that does not get your application working today.  rxtx is preparing 
for its second release in gnu.io since then.

--
Trent Jarvi
tjarvi at qbang.org




From jredman at ergotech.com  Thu Jun  8 08:47:23 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 08 Jun 2006 08:47:23 -0600
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from
	FieldTalk
In-Reply-To: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
References: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
Message-ID: <4488387B.6040903@ergotech.com>

You could always try a different library, eg.

http://sourceforge.net/projects/jamod

I've only used the slave side since we have our own implementation of 
Modbus Client (and a host of other PLC protocols).  However the client 
side seems to be pretty well supported and fairly widely used.  Since 
the source is there you could change to gnu.io.

I think I should take more of an interest in this issue.  We generally 
run 1.4.2 on Linux, but also have some J9 and old platforms that we 
support that are basically Personal Java.  5.0 on Linux has some 
horrible MDI bugs, to the point of being unusable.   Sounds as though we 
are going to have code compatibility problems across these platforms.

Jim


Giacomo Petrini wrote:
> Hi,
> I'm evaluating the library for the modbus protocol
> from FieldTalk
> (http://www.modbusdriver.com/fieldtalk/.
> I'm using J2SE 5.0 and RXTX 2.1 on win XP.
> The problem is that the modbus lib has a method (the
> openProtocol method, but maybe there are others) tha
> throws the
> javax.comm.UnsupportedCommOperationException.
> Now, in RXTX 2.1 the namespace has changed in gnu.io,
> so the modbus library doesn't work anymore (it look
> for things in javax.comm). I've already sent an email
> to fieldtalk to see if they are aware of the problem.
> The solution should be to use JavaComm + RXTX 2.0. But
> I've read somewhere that JavaComm 2.0 does not work
> with Java 5.0 and JavaComm 3.0 does not work with RXTX
> 2.0 so I don't know what to do.
> 
> Any ideas?
> 
> Thanks Jack
> 
> PS: can you make a CC to my personal email
> (g_petrini at yahoo.it) too please?
> 
> Chiacchiera con i tuoi amici in tempo reale! 
>  http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  8 18:17:23 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 08 Jun 2006 17:17:23 -0700
Subject: [Rxtx] rxtx access is denied error
Message-ID: <4488BE13.2050706@dupreeinc.com>

Hello,

I have been trying to replace the commapi from sun with rxtx for a 
project that communicates with a serial port that is a USB-Serial 
interface.  To be exact, I am using the FTDI VCP driver with one of 
their modules connected to a windows XP system.

I have the RXTX package working pretty well as long as nothing goes wrong.

If a user disconnects the USB port while my java application is running, 
my application goes into an endless loop with lots of messages in the  
errors stream  like the ones below:

    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(481):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.


I believe when this happens the COM port completely disappears and the 
rxtx driver has a heart attack.  Obviously, the user should not do this, 
but my application needs to ideally, correct the situation or as a worse 
case, terminate with a little dignity.  Currently, I have not figured 
out how to catch this error.

The closest I have come is to trap an exception to my input stream read  
that says "No error in readByte"  This error appears to be outside of 
the endless loop of the errors listed above.

Does anybody have an idea of how to identify and trap this error?  Any 
suggestions on how to gracefully recover from it would be greatly 
appreciated!

Thank you for your time,

Doug Thistlethwaite




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060608/9cfca302/attachment-0022.html

From tjarvi at qbang.org  Thu Jun  8 20:54:17 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 8 Jun 2006 20:54:17 -0600 (MDT)
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <4488BE13.2050706@dupreeinc.com>
References: <4488BE13.2050706@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606082022580.1323@www>

On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I have been trying to replace the commapi from sun with rxtx for a project 
> that communicates with a serial port that is a USB-Serial interface.  To be 
> exact, I am using the FTDI VCP driver with one of their modules connected to 
> a windows XP system.
>
> I have the RXTX package working pretty well as long as nothing goes wrong.
>
> If a user disconnects the USB port while my java application is running, my 
> application goes into an endless loop with lots of messages in the  errors 
> stream  like the ones below:
>
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(481):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>
>
> I believe when this happens the COM port completely disappears and the rxtx 
> driver has a heart attack.  Obviously, the user should not do this, but my 
> application needs to ideally, correct the situation or as a worse case, 
> terminate with a little dignity.  Currently, I have not figured out how to 
> catch this error.
>
> The closest I have come is to trap an exception to my input stream read  that 
> says "No error in readByte"  This error appears to be outside of the endless 
> loop of the errors listed above.
>
> Does anybody have an idea of how to identify and trap this error?  Any 
> suggestions on how to gracefully recover from it would be greatly 
> appreciated!
>

Hi Doug

Sadly I don't have a quick solution for you.

Termios has no knowlage about the JVM so it wont be throwing exceptions 
you can catch.

We can return error and set the error number to something reasonable that 
results in an exception.  The No Error message simply means we did not set 
an error number in termios.c.  Those are the line numbers in the code you 
see.  SerialImp.c realizes it errored but does not know much more yet. 
Everything touching the file descriptor is going to error after the port 
is gone presumably.

We don't currently have a plan in place for vanishing (or appearing) com 
ports.

Another example of what we need to think about is what happens if you 
start your application and then plug in the dongle?  Or what if you unplug 
and then plug it in again?

So in each of these three cases, what would the behavior of the (yet to 
be) correct implementation do?

How will the enumerated ports be handled during these changes?

There can also be hints from the OS that could be taken into 
consideration.

We can probably get some exceptions thrown that make sense and null the 
file descriptor when it happens to prevent io attempts.  That would be a 
crude way to let applications know something strange has happened.

Is anyone else tinkering with this problem?

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  9 01:31:29 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 9 Jun 2006 09:31:29 +0200
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <Pine.LNX.4.61.0606082022580.1323@www>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
Message-ID: <AC6EDDDD-0A64-401F-B16B-E484788CDF4A@buechse.de>

Hello Trent,

I am not tinkering with this on the Source Level - but I think it  
should work pretty much the same way as it currently does in OSX.  
When the port goes away you get an IOException thrown for any read/ 
write. It will no longer be in the list of ports from  
CommPortIdentifier.getPortIdentifiers(). When a port (re-)appears it  
is added to the list. It's up to the application to re-check the list  
from time to time.

On Windows you can't do much better then that, because the ports  
don't have useful names. Which USB "virtual com port" is on which  
COMx depends on the order the devices were added. So reconnecting to  
the same device may mean connecting to another port.

Regarding the exception thrown: it would be nice to use an  
IOException subclass but the Exception message should definetly be  
informative also as most applications may want to keep compatibility  
with javax.comm.

Regards,
Joachim


On 09.06.2006, at 04:54, Trent Jarvi wrote:

> On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:
>
>> Hello,
>>
>> I have been trying to replace the commapi from sun with rxtx for a  
>> project
>> that communicates with a serial port that is a USB-Serial  
>> interface.  To be
>> exact, I am using the FTDI VCP driver with one of their modules  
>> connected to
>> a windows XP system.
>>
>> I have the RXTX package working pretty well as long as nothing  
>> goes wrong.
>>
>> If a user disconnects the USB port while my java application is  
>> running, my
>> application goes into an endless loop with lots of messages in  
>> the  errors
>> stream  like the ones below:
>>
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (481):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>
>>
>> I believe when this happens the COM port completely disappears and  
>> the rxtx
>> driver has a heart attack.  Obviously, the user should not do  
>> this, but my
>> application needs to ideally, correct the situation or as a worse  
>> case,
>> terminate with a little dignity.  Currently, I have not figured  
>> out how to
>> catch this error.
>>
>> The closest I have come is to trap an exception to my input stream  
>> read  that
>> says "No error in readByte"  This error appears to be outside of  
>> the endless
>> loop of the errors listed above.
>>
>> Does anybody have an idea of how to identify and trap this error?   
>> Any
>> suggestions on how to gracefully recover from it would be greatly
>> appreciated!
>>
>
> Hi Doug
>
> Sadly I don't have a quick solution for you.
>
> Termios has no knowlage about the JVM so it wont be throwing  
> exceptions
> you can catch.
>
> We can return error and set the error number to something  
> reasonable that
> results in an exception.  The No Error message simply means we did  
> not set
> an error number in termios.c.  Those are the line numbers in the  
> code you
> see.  SerialImp.c realizes it errored but does not know much more yet.
> Everything touching the file descriptor is going to error after the  
> port
> is gone presumably.
>
> We don't currently have a plan in place for vanishing (or  
> appearing) com
> ports.
>
> Another example of what we need to think about is what happens if you
> start your application and then plug in the dongle?  Or what if you  
> unplug
> and then plug it in again?
>
> So in each of these three cases, what would the behavior of the  
> (yet to
> be) correct implementation do?
>
> How will the enumerated ports be handled during these changes?
>
> There can also be hints from the OS that could be taken into
> consideration.
>
> We can probably get some exceptions thrown that make sense and null  
> the
> file descriptor when it happens to prevent io attempts.  That would  
> be a
> crude way to let applications know something strange has happened.
>
> Is anyone else tinkering with this problem?
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From doug at dupreeinc.com  Fri Jun  9 13:09:58 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 09 Jun 2006 12:09:58 -0700
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <Pine.LNX.4.61.0606082022580.1323@www>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
Message-ID: <4489C786.9050504@dupreeinc.com>


Ideally, it would be nice if it would throw an exception and terminate 
the loop.  I am still trying to figure out how to detect the condition 
and recover form it in some form...  I am getting the "No error in 
readByte" exception in my serialEvent() method after an input stream 
read.  It appears to me that the only graceful recovery is to close the 
port and then reopen it when it becomes available.  I can pass the event 
up to the update method in my main frame, but I still can't close the 
port from within that thread.  Any suggestions on how to pass this event 
to a location where the port can be safely closed?

Re: Slow startup in windows XP
I have been looking into this a little closer and have found out the 
following:
System Windows XP Pro 3GHz dual core with 1GB RAM and NO parallel port.
Starting the SerialDemo included with the commapi using the rxtx instead 
of javax.comm takes 60 seconds.
Starting the SerialDemo using rxrx with the rxtxParallel.dll file 
removed takes about 20 seconds.
Modify initialize in RXRXCommDriver.java to not test the parallel ports 
takes less than 1 second.

It would be nice if the initialize routine could detect the presence of 
rxtxParallel.dll file and just skip the whole process if not present.  
Is there an easy way to check for the presence of this file without 
running the parallel port test?

Doug


 

Trent Jarvi wrote:

>On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:
>...
>  
>
>
>Hi Doug
>
>Sadly I don't have a quick solution for you.
>
>Termios has no knowlage about the JVM so it wont be throwing exceptions 
>you can catch.
>
>We can return error and set the error number to something reasonable that 
>results in an exception.  The No Error message simply means we did not set 
>an error number in termios.c.  Those are the line numbers in the code you 
>see.  SerialImp.c realizes it errored but does not know much more yet. 
>Everything touching the file descriptor is going to error after the port 
>is gone presumably.
>
>We don't currently have a plan in place for vanishing (or appearing) com 
>ports.
>
>Another example of what we need to think about is what happens if you 
>start your application and then plug in the dongle?  Or what if you unplug 
>and then plug it in again?
>
>So in each of these three cases, what would the behavior of the (yet to 
>be) correct implementation do?
>
>How will the enumerated ports be handled during these changes?
>
>There can also be hints from the OS that could be taken into 
>consideration.
>
>We can probably get some exceptions thrown that make sense and null the 
>file descriptor when it happens to prevent io attempts.  That would be a 
>crude way to let applications know something strange has happened.
>
>Is anyone else tinkering with this problem?
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060609/911ed787/attachment-0022.html

From Ugo.Landini at Sun.COM  Fri Jun  2 14:23:47 2006
From: Ugo.Landini at Sun.COM (Ugo Landini)
Date: Fri, 02 Jun 2006 22:23:47 +0200
Subject: [Rxtx] OSX 10.4.7 and usb
Message-ID: <44809E53.2070905@sun.com>

Hi, I have installed the library and the native libraries on OSX 10.4.7. 
Then I have run this simple code:

...
while (portList.hasMoreElements()) {
             portId = (CommPortIdentifier) portList.nextElement();
             System.out.println("-> " + portId.getName() + " Port Type:" 
+ portId.getPortType());
...

and the output is:

Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7

Ports found:
-> /dev/tty.Bluetooth-PDA-Sync Port Type:1
-> /dev/cu.Bluetooth-PDA-Sync Port Type:1
-> /dev/tty.Bluetooth-Modem Port Type:1
-> /dev/cu.Bluetooth-Modem Port Type:1

I can't see any USB ports... with javax.comm on linux I could see the 
/dev/ttyUSB stuff, but that's not the case with OSX. Any idea?

tia

uL


From tod at todbot.com  Sun Jun 11 12:04:37 2006
From: tod at todbot.com (Tod E. Kurt)
Date: Sun, 11 Jun 2006 11:04:37 -0700
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <44809E53.2070905@sun.com>
References: <44809E53.2070905@sun.com>
Message-ID: <E2EB14A1-20A7-4611-8F1A-E3D2ABE41F48@todbot.com>

A dumb question, but: do you have the USB serial adapters plugged  
in?  They only show up in /dev when plugged in.  Also, you can verify  
they exist independent of RXTX by doing something like "ls -l /dev/ 
cu.*".

On Jun 2, 2006, at 1:23 PM, Ugo Landini wrote:

> Hi, I have installed the library and the native libraries on OSX  
> 10.4.7.
> Then I have run this simple code:
>
> ...
> while (portList.hasMoreElements()) {
>              portId = (CommPortIdentifier) portList.nextElement();
>              System.out.println("-> " + portId.getName() + " Port  
> Type:"
> + portId.getPortType());
> ...
>
> and the output is:
>
> Experimental:  JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
>
> Ports found:
> -> /dev/tty.Bluetooth-PDA-Sync Port Type:1
> -> /dev/cu.Bluetooth-PDA-Sync Port Type:1
> -> /dev/tty.Bluetooth-Modem Port Type:1
> -> /dev/cu.Bluetooth-Modem Port Type:1
>
> I can't see any USB ports... with javax.comm on linux I could see the
> /dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>
> tia
>
> uL
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>



From lyon at docjava.com  Sun Jun 11 12:14:50 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Sun, 11 Jun 2006 14:14:50 -0400
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <44809E53.2070905@sun.com>
References: <44809E53.2070905@sun.com>
Message-ID: <p06020444c0b20de7d248@[192.168.1.152]>

>Hi Ugo,

Do you have any USB serial ports (like the keyspan 19-HS) plugged
into the mac?
Thanks!
  - DL


>Hi, I have installed the library and the native libraries on OSX 10.4.7.
>Then I have run this simple code:
>
>...
>while (portList.hasMoreElements()) {
>              portId = (CommPortIdentifier) portList.nextElement();
>              System.out.println("-> " + portId.getName() + " Port Type:"
>+ portId.getPortType());
>...
>
>and the output is:
>
>Experimental:  JNI_OnLoad called.
>Stable Library
>=========================================
>Native lib Version = RXTX-2.1-7
>Java lib Version   = RXTX-2.1-7
>
>Ports found:
>-> /dev/tty.Bluetooth-PDA-Sync Port Type:1
>-> /dev/cu.Bluetooth-PDA-Sync Port Type:1
>-> /dev/tty.Bluetooth-Modem Port Type:1
>-> /dev/cu.Bluetooth-Modem Port Type:1
>
>I can't see any USB ports... with javax.comm on linux I could see the
>/dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>
>tia
>
>uL
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx



From dmarkman at mac.com  Sun Jun 11 14:30:27 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Sun, 11 Jun 2006 16:30:27 -0400
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <p06020444c0b20de7d248@[192.168.1.152]>
References: <44809E53.2070905@sun.com> <p06020444c0b20de7d248@[192.168.1.152]>
Message-ID: <B9C1606B-4339-4564-A175-FE83DFFA7D76@mac.com>

afaik
10.4.7 wasn't released yet
it will soon, no doubts


On Jun 11, 2006, at 2:14 PM, Dr. Douglas Lyon wrote:

>> Hi Ugo,
>
> Do you have any USB serial ports (like the keyspan 19-HS) plugged
> into the mac?
> Thanks!
>   - DL
>
>
>> Hi, I have installed the library and the native libraries on OSX  
>> 10.4.7.
>> Then I have run this simple code:
>>
>> ...
>> while (portList.hasMoreElements()) {
>>              portId = (CommPortIdentifier) portList.nextElement();
>>              System.out.println("-> " + portId.getName() + " Port  
>> Type:"
>> + portId.getPortType());
>> ...
>>
>> and the output is:
>>
>> Experimental:  JNI_OnLoad called.
>> Stable Library
>> =========================================
>> Native lib Version = RXTX-2.1-7
>> Java lib Version   = RXTX-2.1-7
>>
>> Ports found:
>> -> /dev/tty.Bluetooth-PDA-Sync Port Type:1
>> -> /dev/cu.Bluetooth-PDA-Sync Port Type:1
>> -> /dev/tty.Bluetooth-Modem Port Type:1
>> -> /dev/cu.Bluetooth-Modem Port Type:1
>>
>> I can't see any USB ports... with javax.comm on linux I could see the
>> /dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>>
>> tia
>>
>> uL
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman



From tjarvi at qbang.org  Sun Jun 11 18:52:59 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 11 Jun 2006 18:52:59 -0600 (MDT)
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <4489C786.9050504@dupreeinc.com>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
	<4489C786.9050504@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606111845430.7274@www>

On Fri, 9 Jun 2006, Doug Thistlethwaite wrote:

>
> Ideally, it would be nice if it would throw an exception and terminate the 
> loop.  I am still trying to figure out how to detect the condition and 
> recover form it in some form...  I am getting the "No error in readByte" 
> exception in my serialEvent() method after an input stream read.  It appears 
> to me that the only graceful recovery is to close the port and then reopen it 
> when it becomes available.  I can pass the event up to the update method in 
> my main frame, but I still can't close the port from within that thread.  Any 
> suggestions on how to pass this event to a location where the port can be 
> safely closed?
>

I've gone through and cleaned up the termios.c layer.  I need to get to a 
windows machine with a USB dongle and see where the ioctl() is being 
called.  Probably the eventLoop.  But all of the ioctls should probably 
result in an IOException during this condition.

I'll probably finish this up Monday night when I can borrow a USB 
dongle.

There is no point in putting the code into CVS yet.  If you are tinkering 
I can mail the patch.  I think we will want to make a couple fixes in 
SerialImp.c to handle errors before it's ready.

--
Trent Jarvi
tjarvi at qbang.org



From bob_tai2001 at yahoo.com  Mon Jun 12 09:42:14 2006
From: bob_tai2001 at yahoo.com (Bob Tai)
Date: Mon, 12 Jun 2006 08:42:14 -0700 (PDT)
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to RXTX
	again
Message-ID: <20060612154214.58219.qmail@web32804.mail.mud.yahoo.com>


thank you Paul, Joachim, Trent and everyone try to
workout the java comm and Rxtx situation.  At least
now I have something that is solid enough to make my
decision.  

thank you,
     Bob

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From Ralph.Buchfelder at gmx.net  Mon Jun 12 15:30:20 2006
From: Ralph.Buchfelder at gmx.net (Ralph Buchfelder)
Date: Mon, 12 Jun 2006 23:30:20 +0200
Subject: [Rxtx] rxtx binaries or porting to XSCALE Windows Mobile 2003 / 2005
Message-ID: <448DDCEC.7090506@gmx.net>

dear group,

i have been carefully reading your homepage, wiki and archives
but there seems to be no detailled information on porting to Windows 
Mobile/CE.

as far as i understood from the 'porting' section you can do porting to 
winCE. but how? do i only need to obtain the sourcecode (which one?) and 
compile this in Microsoft eMbedded Visual C++ for ARM/Xscale?
Any other ways?


unfortunately i must admit that i do have little linux skills but i have 
made my way through gcc and makefiles. right now i need to implement com 
  communication in a J2ME application and found your website as >the< 
solution.

best regards
Ralph Buchfelder

University of Regensburg
Department of Geography

PS: i dont care about Javacomm compliancy (ie. 2.0 or 2.1) - i just need 
a working serial port API in IBM J9 VM.


From paul.klissner at sun.com  Wed Jun 14 18:12:58 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Wed, 14 Jun 2006 17:12:58 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
Message-ID: <4490A60A.9090305@sun.com>

Hello RxTx community,

I finally think I have a compromise in place that will stand in the gap.

If you go to http://www.sun.com and search for javax.comm, you'll
get taken to a download page, where now users can get a copy of the
comm.jar file out of 2.0.3, along with just a license and a README.

I trust this will suffice until such time as RxTx decided to implement
their own java classes or we can get a JSR going to mitigate some
of the problems (the readme in the comm.jar 2.0.3 zip file
contains my thoughts on that).

Thanks,
Paul



From tjarvi at qbang.org  Wed Jun 14 21:15:35 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 14 Jun 2006 21:15:35 -0600 (MDT)
Subject: [Rxtx] rxtx-2.0-7 (final) src is in CVS
Message-ID: <Pine.LNX.4.61.0606142100500.2742@www>


I wasn't expecting to be working on rxtx 2.0 tonight :)

Thanks go out to Paul Klissner for his work in making the coming release 
of rxtx-2.0-7 possible for users that require package javax.comm on many 
platforms.

Most people know that rxtx 2.0 is for use with Sun's CommAPI 2.0 for 
Solaris or the Generic CommAPI 2.0-3 available for download at Sun.  If 
you need javax.comm packages on many platforms, you are probably 
interested.  If you use rxtx 2.1 in package gnu.io, then you are not going 
to care much.

I've tried to update the rxtx 2.0 src directory in preparation for 
rxtx-2.0-7 (final).  Linux should compile.  Windows will compile if you 
generate your own .def files (I'll generate these tomorrow).  If you have 
some time to do basic testing of the source, I'd appreciate it.  The 
source should be good but you may find classes not found.  This source is 
a backport from rxtx 2.1.

I wanted to get things started so anyone interested on Mac OS X could get 
a head start.

All of this is in CVS.  http://www.rxtx.org/cvs.html

I suspect we will have binaries for testing in a couple days if you are 
unable to compile.   Consider this a smoke test.

--
Trent Jarvi
tjarvi at qbang.org


From legolas.w at gmail.com  Wed Jun 14 22:04:28 2006
From: legolas.w at gmail.com (Legolas Woodland)
Date: Wed, 14 Jun 2006 21:04:28 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <4490A60A.9090305@sun.com>
References: <4490A60A.9090305@sun.com>
Message-ID: <87ee9b170606142104p745fcef0vea622fbc8f528bfc@mail.gmail.com>

is there anything new in this version of javax.comm ?
thanks


On 6/14/06, Paul Klissner <paul.klissner at sun.com> wrote:
>
> Hello RxTx community,
>
> I finally think I have a compromise in place that will stand in the gap.
>
> If you go to http://www.sun.com and search for javax.comm, you'll
> get taken to a download page, where now users can get a copy of the
> comm.jar file out of 2.0.3, along with just a license and a README.
>
> I trust this will suffice until such time as RxTx decided to implement
> their own java classes or we can get a JSR going to mitigate some
> of the problems (the readme in the comm.jar 2.0.3 zip file
> contains my thoughts on that).
>
> Thanks,
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060614/5ff4dfbc/attachment-0022.html

From joachim at buechse.de  Thu Jun 15 07:22:48 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 15 Jun 2006 15:22:48 +0200
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
Message-ID: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>

Good day!

Some of my users report problems using RXTX 2.1.7 on Windows98 to  
communicate with an FTDI FT245BM chip (using their latest VCP  
driver). Either no ports are being shown (ie returned form  
CommPortIdentifier.getPortIdentifiers()) or the transfers fail.

Did anyone run into similar Problems with Win98??

Best regards,
Joachim



From ajmas at sympatico.ca  Thu Jun 15 08:12:28 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Thu, 15 Jun 2006 10:12:28 -0400
Subject: [Rxtx] API change question
Message-ID: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

How closely do you follow the Java Communication API spec? The reason I ask is because I would be interested in augmenting the CommPortIdentifier class to include a getDisplayName() method. By default it would return the same value as getName(), but would provide the possibility of displaying a 'user friendly' name, for platforms where the display name is not the same as the device name. An example of this is on MacOS X, where currently the names seem to be of the form /dev/cu.* and /dev/tty.*, yet what the expects to see is simply the part after the full-stop. Although I could move this logic into the Java code, it would be nice to see it transparent to the Java code.

Andre




From ajmas at sympatico.ca  Thu Jun 15 08:16:22 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Thu, 15 Jun 2006 10:16:22 -0400
Subject: [Rxtx] Package to use
Message-ID: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

While the Java API spec refers to javax.comm, I see that only gnu.io is provide by the rxtx project. Should our projects refer to the gnu.io package or the javax.comm API?

Andre



From joachim at buechse.de  Thu Jun 15 08:45:05 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 15 Jun 2006 16:45:05 +0200
Subject: [Rxtx] API change question
In-Reply-To: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>

Hello Andre,

the /dev/cu and /dev/tty have different semantics on OS X. It is much  
more than a simply naming issue to unify them, see my recent mail to  
the list...

Best regards,
Joachim


On 15.06.2006, at 16:12, Andre-John Mas wrote:

> Hi,
>
> How closely do you follow the Java Communication API spec? The  
> reason I ask is because I would be interested in augmenting the  
> CommPortIdentifier class to include a getDisplayName() method. By  
> default it would return the same value as getName(), but would  
> provide the possibility of displaying a 'user friendly' name, for  
> platforms where the display name is not the same as the device  
> name. An example of this is on MacOS X, where currently the names  
> seem to be of the form /dev/cu.* and /dev/tty.*, yet what the  
> expects to see is simply the part after the full-stop. Although I  
> could move this logic into the Java code, it would be nice to see  
> it transparent to the Java code.
>
> Andre
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From lyon at docjava.com  Thu Jun 15 10:16:29 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Thu, 15 Jun 2006 12:16:29 -0400
Subject: [Rxtx] cu.modem != /dev/ttya on mac.
In-Reply-To: <763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
	<763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>
Message-ID: <p0602046cc0b7378a95b0@[192.168.1.152]>

>Hi All,

I think that Joachim is correct. For the longest time,
I have been trying to figure out how to direct dial using
the cu.modem on the mac under os x.

As a less-than-optimal approach to auto-dialing, I have used
a keyspan USB 19HS adapter, along with an external modem, to
obtain the dialing feature.

Ideally, it would be better to dial with the built-in modem...but that did not
always seem to work, for some reason. Have others had some experience with
using the built in modem for dialing on the mac?

Thanks!
  - Doug


>Hello Andre,
>
>the /dev/cu and /dev/tty have different semantics on OS X. It is much?
>more than a simply naming issue to unify them, see my recent mail to?
>the list...
>
>Best regards,
>Joachim
>



From doug at dupreeinc.com  Thu Jun 15 14:52:50 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 15 Jun 2006 13:52:50 -0700
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
In-Reply-To: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
References: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
Message-ID: <4491C8A2.8090108@dupreeinc.com>

Hi Joachim,

I have been doing a lot with the new FTDI driver with win XP and have 
not had that particular problem.  I did notice that the new driver 
(dated May19th, 2006) is only for XP, Server 2003, and 2000.  Are they 
trying to use the 2.00.00 drivers or the old 1.09.06 version.  I am 
using a FT232R based module, but it uses the same drivers and I assume 
it would have the same problems.  Let me know which driver they are 
using and I can load up a 98 system here and see if  I can duplicate the 
problem.

Doug

Joachim Buechse wrote:

>Good day!
>
>Some of my users report problems using RXTX 2.1.7 on Windows98 to  
>communicate with an FTDI FT245BM chip (using their latest VCP  
>driver). Either no ports are being shown (ie returned form  
>CommPortIdentifier.getPortIdentifiers()) or the transfers fail.
>
>Did anyone run into similar Problems with Win98??
>
>Best regards,
>Joachim
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From matthewhepp at yahoo.com  Thu Jun 15 17:34:47 2006
From: matthewhepp at yahoo.com (Matthew Hepp)
Date: Thu, 15 Jun 2006 16:34:47 -0700 (PDT)
Subject: [Rxtx] Wither the XCode project?
Message-ID: <20060615233447.48064.qmail@web50311.mail.yahoo.com>

Either I don't know how to properly use CVS (entirely possibl), or the XCode
project is not making through the update properly. Doing a "cvs update" against
2.1-7 creates an XCode folder in MACOSX_IDE, and therein a
LibSerialUniversal.xcodeproj, but trying to open it yields a "Unable to Open
Project - Project rxtx-devel/MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj
cannot be opened because it is missing its project.pbxproj file" error. Showing
package contents reveals just the cvs-related files. Perhaps this is why
previous xcode projects have been saved as an sit.hqx - to retain the resource
fork?

Can someone point me in the right direction?

Thanks,

Matt

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Thu Jun 15 19:53:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 19:53:06 -0600 (MDT)
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
In-Reply-To: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
References: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
Message-ID: <Pine.LNX.4.61.0606151944070.23137@www>

On Thu, 15 Jun 2006, Joachim Buechse wrote:

> Good day!
>
> Some of my users report problems using RXTX 2.1.7 on Windows98 to
> communicate with an FTDI FT245BM chip (using their latest VCP
> driver). Either no ports are being shown (ie returned form
> CommPortIdentifier.getPortIdentifiers()) or the transfers fail.
>
> Did anyone run into similar Problems with Win98??
>

Hi Joachim

It has been a long time since I've tested win98.  I know rxtx-2.1-7pre16 
did get testing on win98 with ~jdk 1.3 though.  I wonder if jdks are still 
tested on that platform.

With win98 you usually have older boxes.  They can be short on CPU and 
memory.  Enumeration should work but I could picture runtime performance 
issues on win98.

The enumeration problems could result from other copies of your 
application if various states of decay still holding onto the port.  When 
things go wrong, people also like to open other terminal software to see 
whats going on which can interfere.  You can't open a windows port with 
two apps.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Thu Jun 15 20:08:53 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 20:08:53 -0600 (MDT)
Subject: [Rxtx] API change question
In-Reply-To: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606151954270.23137@www>

On Thu, 15 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> How closely do you follow the Java Communication API spec?

I can explain how this worked in the past.  How we do it in the future is 
open for discussion.

In the past we have tried to follow it as close as possible in gnu.io 
(rxtx 2.1).  We have added extensions but try to discourage their use. 
The extensions are clearly marked as such in the source code and javadocs.

rxtx 2.0 was intended to be a strict implementation of part of the spec. 
We let Sun's interfaces decide what methods can be called. There are 
differences not covered by the spec such as default values.  Thats not 
intentional but rather hard to avoid.

--
Trent Jarvi
tjarvi at qbang.org





From tjarvi at qbang.org  Thu Jun 15 21:09:11 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 21:09:11 -0600 (MDT)
Subject: [Rxtx] Package to use
In-Reply-To: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606152026120.23137@www>

On Thu, 15 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> While the Java API spec refers to javax.comm, I see that only gnu.io is 
> provide by the rxtx project. Should our projects refer to the gnu.io 
> package or the javax.comm API?
>

Hi Andre

Lets see if I can give a fair and balanced answer to that.

If you are starting a new project and want to use RXTX, I would recommend 
using gnu.io.  The community support for gnu.io will not be going away 
anytime soon.  You can switch between gnu.io (2.1) and javax.comm (2.0) 
fairly easily.  They are not intended to be incompatible.  You just change 
package names and libs.

You can also consider the combination of rxtx 2.0 with Sun's commapi 
2.0-3.  This is considered a stop-gap measure by Sun for previous users of 
that combination.  Together rxtx 2.0 and Sun CommAPI 2.0 work in namespace 
javax.comm for programmers.

Finally, you can opt to just use Sun's oferrings in CommAPI 3.0 without 
rxtx.  That would be in namespace javax.comm also.  CommAPI 3.0 may be 
of more interest to you if you are looking at POS with Sun computers. 
Rxtx does not currently support the changes in CommAPI 3.0 or have firm 
plans to do so.  That does not mean we wouldn't implement them.  It just 
means nobody has contributed code yet.

You can't combine rxtx with CommAPI 3.0 for technical reasons that wont 
likely be fixed soon.

It's up to you as far as what you use.  We like to provide the freedom so 
you can choose.  Realistically, we will be supporting gnu.io mainly 
because we have some control over that name space and can support it.

Things may happen in the future that enable rxtx to provide more support 
in the javax namespace but that has not happened yet.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun 16 00:33:06 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 08:33:06 +0200
Subject: [Rxtx] Wither the XCode project?
In-Reply-To: <20060615233447.48064.qmail@web50311.mail.yahoo.com>
References: <20060615233447.48064.qmail@web50311.mail.yahoo.com>
Message-ID: <D30D660F-A49B-464E-AE4C-6B4563893682@buechse.de>

Hello Matthew,

could you please send me the contents of your

   rxtx-devel/CVS
   rxtx-devel/MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj/CVS

directories as a zip to my personal email address. This should  
indicate why the file is not checked out. I can see that it exists on  
the correct branch in the repository, so something must have gone  
wrong during the "cvs update"...

Best regards,
Joachim

On 16.06.2006, at 01:34, Matthew Hepp wrote:

> Either I don't know how to properly use CVS (entirely possibl), or  
> the XCode
> project is not making through the update properly. Doing a "cvs  
> update" against
> 2.1-7 creates an XCode folder in MACOSX_IDE, and therein a
> LibSerialUniversal.xcodeproj, but trying to open it yields a  
> "Unable to Open
> Project - Project rxtx-devel/MACOSX_IDE/XCode/ 
> LibSerialUniversal.xcodeproj
> cannot be opened because it is missing its project.pbxproj file"  
> error. Showing
> package contents reveals just the cvs-related files. Perhaps this  
> is why
> previous xcode projects have been saved as an sit.hqx - to retain  
> the resource
> fork?
>
> Can someone point me in the right direction?



From joachim at buechse.de  Fri Jun 16 10:41:20 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 18:41:20 +0200
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <p06230903c0b88613dca6@[10.0.1.7]>
References: <p06230903c0b88613dca6@[10.0.1.7]>
Message-ID: <03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>

Hello Bob,

until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was  
behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if  
Trent has migrated all recent changes from 2.1 to 2.0.

I have added the XCode project and updated documentation only to the  
gnu.io branch. Once the 2.0 implementation is up to date I will copy  
over the documentation/build files make them work.

Best regards,
Joachim

On 16.06.2006, at 18:07, Bob Jacobsen wrote:

> I'm one of the developers for the JMRI project, which provides  
> model railroad software in Java.  We've been using RXTX to provide  
> serial port access on MacOS X and Linux; we use the old javax.comm  
> 2.0 on Windows, OS/2 and Solaris.  Because of that, we need to stay  
> with RXTX 2.0, not 2.1
>
> We've been using the 2.0-pre17 installer for a long time, but it's  
> not compatible with Intel macs.
>
> Can you point me to where I can find the right files for RXTX 2.0  
> to package with the program?
>
> The current situation is confusing to me.  I've been pointed to  
> recent 2.1 versions (but we need the javax.comm names), to an even  
> older installer, etc.  I've been reading that some versions require  
> an installer, and others don't, but I haven't been able to figure  
> out which (if any) of those are where in CVS.
>
> I'd really appreciate a clear statement of what files to use and  
> what to do with them that I can pass on to our users.
>
> I'm more than happy to put files in the local classpath, have users  
> run an installer, or anything else.  Whatever is easiest for you.
>
> Thanks!  I really appreciate all that you do to keep RXTX working.
>
> Bob
> -- 
> Bob Jacobsen +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG



From joachim at buechse.de  Fri Jun 16 09:59:28 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 17:59:28 +0200
Subject: [Rxtx] Wither the XCode project?
In-Reply-To: <20060616150240.49464.qmail@web50309.mail.yahoo.com>
References: <20060616150240.49464.qmail@web50309.mail.yahoo.com>
Message-ID: <D9935E05-2B83-488D-86DD-42599E229052@buechse.de>

Hello Matthew,

you have checked out the trunk (which is the 2.0.7 javax.comm.xxx  
release). For rxtx-2.1.7 (gnu.io.xxx release) you need to check out  
the branch

      commapi-0-0-1

The easiest way to do this is to download the rxtx src archive,  
unpack it and then do a cvs up inside the decompressed tree.  
Optionally you could do a

      cvs co -r commapi-0-0-1

but this will take much longer!

Best regards,
Joachim

When you do a cvs status it will show the sticky tag.

41:~/jdevelop/rxtx-2.1-7r2 joachim$ cvs status README.OSX
===================================================================
File: README.OSX        Status: Up-to-date

    Working revision:    1.1.2.1
    Repository revision: 1.1.2.1 /usr/local/cvsroot/rxtx-devel/Attic/ 
README.OSX,v
    Sticky Tag:          commapi-0-0-1 (branch: 1.1.2)
    Sticky Date:         (none)
    Sticky Options:      (none)




On 16.06.2006, at 17:02, Matthew Hepp wrote:

> %cvs status README.MACOSX
> ===================================================================
> File: README.MACOSX     Status: Up-to-date
>
>    Working revision:    1.1
>    Repository revision: 1.1     /usr/local/cvsroot/rxtx-devel/ 
> README.MACOSX,v
>    Sticky Tag:          (none)
>    Sticky Date:         (none)
>    Sticky Options:      (none)



From tjarvi at qbang.org  Fri Jun 16 16:31:18 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Fri, 16 Jun 2006 16:31:18 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
Message-ID: <Pine.LNX.4.61.0606161630030.14139@www>

On Fri, 16 Jun 2006, Joachim Buechse wrote:

> Hello Bob,
>
> until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was
> behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if
> Trent has migrated all recent changes from 2.1 to 2.0.
>

The src/ directory and configure.in/configure files should be fine.  I 
have not touched the Mac OS X directories.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sat Jun 17 02:39:55 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sat, 17 Jun 2006 10:39:55 +0200
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <Pine.LNX.4.61.0606161630030.14139@www>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
Message-ID: <350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>

Hello Trent,

apparently the IOEXCL changes have not made it into 2.0. I will add  
them to achieve a minimal diff between 2.0 and 2.1.

One other thing that bugs me for a while...

Shouldn't we replace "if !defined(TIOCSERGETLSR) && !defined(WIN32)"  
by a definition of its own "if defined(DRAINTHREAD)"? I think this  
would make the code clearer for people starting to read it.

Regards,
Joachim


On 17.06.2006, at 00:31, Trent Jarvi wrote:

> On Fri, 16 Jun 2006, Joachim Buechse wrote:
>
>> Hello Bob,
>>
>> until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was
>> behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if
>> Trent has migrated all recent changes from 2.1 to 2.0.
>>
>
> The src/ directory and configure.in/configure files should be fine.  I
> have not touched the Mac OS X directories.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From tropicsu at hotmail.com  Sat Jun 17 09:32:48 2006
From: tropicsu at hotmail.com (Yoke K)
Date: Sat, 17 Jun 2006 15:32:48 +0000
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
Message-ID: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>

Hi,

I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to work with 
MAC OS X.
I am using iTegno 3000 - USB GPRS Modem.

Files in /dev and a symbolic link as follows:

crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 -> tty.usbserial

In my SendMessage.java, I have this line:
CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");

Appreciate any help ?

- Jon


Errors as follows:

>>INFO: SMSLib API for Java / v1.2.2
>>INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>INFO: JRE Version: 1.5.0_06
>>INFO: JRE Impl Version: 1.5.0_06-64
>>INFO: O/S: Mac OS X / ppc / 10.4.6
>>INFO: Using Wavecom (Generic) AT handler.

SendMessage(): Send a message.
  Using SMSLib API for Java v1.2.2

Connecting ..... :
>>INFO: CSerialDriver(): Connecting...
Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
>>INFO: CSerialDriver(): Disconnecting...
gnu.io.NoSuchPortException
        at 
gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:218)
        at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
        at org.smslib.CService.connect(CService.java:197)
        at SendMessage.main(SendMessage.java:38)

_________________________________________________________________
Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/



From tjarvi at qbang.org  Sat Jun 17 10:12:30 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 10:12:30 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
	<350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
Message-ID: <Pine.LNX.4.61.0606171010060.14139@www>

On Sat, 17 Jun 2006, Joachim Buechse wrote:

> Hello Trent,
>
> apparently the IOEXCL changes have not made it into 2.0. I will add
> them to achieve a minimal diff between 2.0 and 2.1.
>

Hi Joachim

As I recall the IOEXCL change was after 2.1-7.  I was just syncing with 
2.1-7.  We can release 2.1-8 and 2.0-8 with the same changes.

> One other thing that bugs me for a while...
>
> Shouldn't we replace "if !defined(TIOCSERGETLSR) && !defined(WIN32)"
> by a definition of its own "if defined(DRAINTHREAD)"? I think this
> would make the code clearer for people starting to read it.
>


Sure.  We can do that for -8.  The TIOCSERGETLSR code should be a special 
case not the expected.  I think only Linux uses it.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Sat Jun 17 10:48:21 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 10:48:21 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <Pine.LNX.4.61.0606171010060.14139@www>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
	<350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
	<Pine.LNX.4.61.0606171010060.14139@www>
Message-ID: <Pine.LNX.4.61.0606171047310.14139@www>

On Sat, 17 Jun 2006, Trent Jarvi wrote:

> On Sat, 17 Jun 2006, Joachim Buechse wrote:
>
>> Hello Trent,
>>
>> apparently the IOEXCL changes have not made it into 2.0. I will add
>> them to achieve a minimal diff between 2.0 and 2.1.
>>
>
> Hi Joachim
>
> As I recall the IOEXCL change was after 2.1-7.  I was just syncing with
> 2.1-7.  We can release 2.1-8 and 2.0-8 with the same changes.
>

We could just move to 2.1-8 and 2.0-8.

--
Trent Jarvi
tjarvi at qbang.org


From brian.t.lamb at gmail.com  Tue Jun 13 13:54:13 2006
From: brian.t.lamb at gmail.com (Brian Lamb)
Date: Tue, 13 Jun 2006 15:54:13 -0400
Subject: [Rxtx] Windows XP Installation
Message-ID: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>

I've not installed Java packages on Windows before and am unsure how to
proceed. All the documentation I've seen provides detailed instructions on
how to install on Linux or Solaris. I was wondering how to install rxtx on
Windows XP.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060613/6f68cd5c/attachment-0022.html

From tjarvi at qbang.org  Sat Jun 17 13:57:03 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 13:57:03 -0600 (MDT)
Subject: [Rxtx] Windows XP Installation
In-Reply-To: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>
References: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0606171356120.14139@www>

On Tue, 13 Jun 2006, Brian Lamb wrote:

> I've not installed Java packages on Windows before and am unsure how to
> proceed. All the documentation I've seen provides detailed instructions on
> how to install on Linux or Solaris. I was wondering how to install rxtx on
> Windows XP.
>

Hi Brian

Which rxtx version are you trying to install?

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sun Jun 18 10:41:44 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sun, 18 Jun 2006 18:41:44 +0200
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
References: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
Message-ID: <8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>

Hello Jon,

 From OSX's standpoint a symbolic link is not a device (as far as I  
know). What stops you from using tty.usbserial? Did you try hard- 
linking?

Regards,
Joachim

On 17.06.2006, at 17:32, Yoke K wrote:
> Hi,
>
> I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to  
> work with
> MAC OS X.
> I am using iTegno 3000 - USB GPRS Modem.
>
> Files in /dev and a symbolic link as follows:
>
> crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
> crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
> lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->  
> tty.usbserial
>
> In my SendMessage.java, I have this line:
> CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
>
> Appreciate any help ?
>
> - Jon
>
>
> Errors as follows:
>
>>> INFO: SMSLib API for Java / v1.2.2
>>> INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>> INFO: JRE Version: 1.5.0_06
>>> INFO: JRE Impl Version: 1.5.0_06-64
>>> INFO: O/S: Mac OS X / ppc / 10.4.6
>>> INFO: Using Wavecom (Generic) AT handler.
>
> SendMessage(): Send a message.
>   Using SMSLib API for Java v1.2.2
>
> Connecting ..... :
>>> INFO: CSerialDriver(): Connecting...
> Experimental:  JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
>>> INFO: CSerialDriver(): Disconnecting...
> gnu.io.NoSuchPortException
>         at
> gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java: 
> 218)
>         at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
>         at org.smslib.CService.connect(CService.java:197)
>         at SendMessage.main(SendMessage.java:38)
>
> _________________________________________________________________
> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Sun Jun 18 10:56:55 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 12:56:55 -0400
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>
References: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
	<8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>
Message-ID: <7B6834E3-F41D-46B6-B979-55466BC73859@sympatico.ca>

Have you been able to get any other software to talk with your
modem? What port is it using? Have tried using the cu.usbserial
instead?

Andre

On 18-Jun-06, at 12:41 , Joachim Buechse wrote:

> Hello Jon,
>
>  From OSX's standpoint a symbolic link is not a device (as far as I
> know). What stops you from using tty.usbserial? Did you try hard-
> linking?
>
> Regards,
> Joachim
>
> On 17.06.2006, at 17:32, Yoke K wrote:
>> Hi,
>>
>> I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to
>> work with
>> MAC OS X.
>> I am using iTegno 3000 - USB GPRS Modem.
>>
>> Files in /dev and a symbolic link as follows:
>>
>> crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
>> crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
>> lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->
>> tty.usbserial
>>
>> In my SendMessage.java, I have this line:
>> CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
>>
>> Appreciate any help ?
>>
>> - Jon
>>
>>
>> Errors as follows:
>>
>>>> INFO: SMSLib API for Java / v1.2.2
>>>> INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>>> INFO: JRE Version: 1.5.0_06
>>>> INFO: JRE Impl Version: 1.5.0_06-64
>>>> INFO: O/S: Mac OS X / ppc / 10.4.6
>>>> INFO: Using Wavecom (Generic) AT handler.
>>
>> SendMessage(): Send a message.
>>   Using SMSLib API for Java v1.2.2
>>
>> Connecting ..... :
>>>> INFO: CSerialDriver(): Connecting...
>> Experimental:  JNI_OnLoad called.
>> Stable Library
>> =========================================
>> Native lib Version = RXTX-2.1-7
>> Java lib Version   = RXTX-2.1-7
>>>> INFO: CSerialDriver(): Disconnecting...
>> gnu.io.NoSuchPortException
>>         at
>> gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:
>> 218)
>>         at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
>>         at org.smslib.CService.connect(CService.java:197)
>>         at SendMessage.main(SendMessage.java:38)
>>
>> _________________________________________________________________
>> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Sun Jun 18 17:33:08 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 19:33:08 -0400
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
Message-ID: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>

Hi,

I am have a program that I wrote in Java to communicate with a  
Bluetooth GPS device. I am
trying to get this working on my Mac, but I keep getting told that:

gnu.io.PortInUseException: Unknown Application

but

portIdentifier.isCurrentlyOwned()

returns false and when I do lsof on the device I am trying to connect  
to, I see no application
using it. As the same time if I go to the command line and use  
minicom I have no issues. The
exception happens with this call:

CommPort commPort = portIdentifier.open(null,0);

Any suggestions?

Andre


From ajmas at sympatico.ca  Sun Jun 18 17:45:11 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 19:45:11 -0400
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
Message-ID: <30245B30-682D-4EAE-8084-8227B719F10D@sympatico.ca>

BTW My code snippet is:

     private InputStream connectToSerial () throws IOException,  
Exception
     {
         InputStream in = null;

         Enumeration portEnum = CommPortIdentifier.getPortIdentifiers();
         while ( portEnum.hasMoreElements() )
         {
             CommPortIdentifier portIdentifier = (CommPortIdentifier)  
portEnum.nextElement();
             System.out.println(portIdentifier.getName() + " - " +  
portIdentifier.getPortType() );
         }

         CommPortIdentifier portIdentifier =  
CommPortIdentifier.getPortIdentifier("/dev/cu.BTGPS-SPPslave-1");
         System.out.println("current owner: " +  
portIdentifier.getCurrentOwner());
         if ( portIdentifier.isCurrentlyOwned() )
         {
             System.out.println("Error: Port is currently in use");
             return null;
         }
         else
         {
             CommPort commPort = portIdentifier.open(this.getClass 
().getName(),2000);

             if ( commPort instanceof SerialPort )
             {
                 SerialPort serialPort = (SerialPort) commPort;
                 serialPort.setSerialPortParams 
(4800,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE 
);
                 in = serialPort.getInputStream();

                 return in;
             }
             else
             {
                 System.out.println("Error: Only serial ports are  
handled.");
             }
         }


         return in;
     }


On 18-Jun-06, at 19:33 , Andr?-John Mas wrote:

> Hi,
>
> I am have a program that I wrote in Java to communicate with a
> Bluetooth GPS device. I am
> trying to get this working on my Mac, but I keep getting told that:
>
> gnu.io.PortInUseException: Unknown Application
>
> but
>
> portIdentifier.isCurrentlyOwned()
>
> returns false and when I do lsof on the device I am trying to connect
> to, I see no application
> using it. As the same time if I go to the command line and use
> minicom I have no issues. The
> exception happens with this call:
>
> CommPort commPort = portIdentifier.open(null,0);
>
> Any suggestions?
>
> Andre
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From joachim at buechse.de  Mon Jun 19 05:54:49 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 13:54:49 +0200
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de>

This is most likely due to a problem with lock files. If you have  
downloaded the binaries of 2.17 rxtx will try to create non-standard  
lock files on OSX. We have since changed the code to use OSX device  
locking - however the binaries have not been updated yet. The 2.18  
release fixing this issue is due shortly.

Regards,
Joachim

On 19.06.2006, at 01:33, Andr?-John Mas wrote:

> Hi,
>
> I am have a program that I wrote in Java to communicate with a
> Bluetooth GPS device. I am
> trying to get this working on my Mac, but I keep getting told that:
>
> gnu.io.PortInUseException: Unknown Application
>
> but
>
> portIdentifier.isCurrentlyOwned()
>
> returns false and when I do lsof on the device I am trying to connect
> to, I see no application
> using it. As the same time if I go to the command line and use
> minicom I have no issues. The
> exception happens with this call:
>
> CommPort commPort = portIdentifier.open(null,0);
>
> Any suggestions?
>
> Andre
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From joachim at buechse.de  Mon Jun 19 06:44:27 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 14:44:27 +0200
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <4490A60A.9090305@sun.com>
References: <4490A60A.9090305@sun.com>
Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>

Hello Paul,

I just downloaded the "generic" javax.comm version now available. A  
first check indicates, that it was compiled with a JDK 1.4 javac  
without setting the target classfile version. In other words in can  
not be loaded by 1.1-1.3 VMs (or PersonalJava).

Do you see any chance to provide a version compiled with classfile  
format 45.3 (ie JVM1.1).

---
52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose  
javax.comm.SerialPort | head -5
Compiled from "SerialPort.java"
public abstract class javax.comm.SerialPort extends javax.comm.CommPort
   SourceFile: "SerialPort.java"
   minor version: 0
   major version: 48
---

Best regards,
Joachim


On 15.06.2006, at 02:12, Paul Klissner wrote:

> Hello RxTx community,
>
> I finally think I have a compromise in place that will stand in the  
> gap.
>
> If you go to http://www.sun.com and search for javax.comm, you'll
> get taken to a download page, where now users can get a copy of the
> comm.jar file out of 2.0.3, along with just a license and a README.
>
> I trust this will suffice until such time as RxTx decided to implement
> their own java classes or we can get a JSR going to mitigate some
> of the problems (the readme in the comm.jar 2.0.3 zip file
> contains my thoughts on that).
>
> Thanks,
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Mon Jun 19 09:11:45 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Mon, 19 Jun 2006 11:11:45 -0400
Subject: [Rxtx] Examples added to Wiki
Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

I have added a couple of examples to the Wiki:

http://rxtx.qbang.org/wiki/index.php/Examples

If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :)

Andre



From paul.klissner at sun.com  Mon Jun 19 10:42:47 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Mon, 19 Jun 2006 09:42:47 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>
References: <4490A60A.9090305@sun.com>
	<03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>
Message-ID: <4496D407.1090609@sun.com>

Joachim Buechse wrote:
> Hello Paul,
> 
> I just downloaded the "generic" javax.comm version now available. A  
> first check indicates, that it was compiled with a JDK 1.4 javac  
> without setting the target classfile version. In other words in can  
> not be loaded by 1.1-1.3 VMs (or PersonalJava).
> 
> Do you see any chance to provide a version compiled with classfile  
> format 45.3 (ie JVM1.1).
> 
> ---
> 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose  
> javax.comm.SerialPort | head -5
> Compiled from "SerialPort.java"
> public abstract class javax.comm.SerialPort extends javax.comm.CommPort
>    SourceFile: "SerialPort.java"
>    minor version: 0
>    major version: 48
> ---

I cannot promise when I can do that. Since we thought we were done
with javax.comm, the build environment got moved around, and right
now it doesn't even compile in it's new home.  I tried and it was
not cooperative at all. I was never impressed with that workspace
(in fact far far from it, it is a mess, which is why I migrated 3.0
to ant and never looked back).  It will take some real determination
for me to rebuild it, and frankly, right now I'm swamped.  If I can
find a bit of time over the next few weeks to do it, and it isn't
too bad an ordeal, I will.

Posting that will give me an excuse to post javax.comm 3.0, Update 2 as
well, while I'm working with the people who put content up on our
download center.  The only reason for a new update to 3.0 is that
I've changed the distribution to provide ispt (Interactive Serial
Port Tool), such that it can be launched as soon as the zip file
is unpacked, via a provided script.  ISPT is a command line
interactive tool for  manipulating one or two serial port,
sending data, managing events, etc... I've found it to be so useful
for doing certain kinds of validation  that I assume others will
find it useful to.  ISPT is already in 3.0u1, but one has to set
up their own classpath and launch it and since few people ever read
the documentation most won't know about it.  I've added the ability
to set stop bits and parity since 3.0u1 too.  But I digress.

Paul


From joachim at buechse.de  Mon Jun 19 11:01:28 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 19:01:28 +0200
Subject: [Rxtx] load mechanism of 2.0x
Message-ID: <CFD1440C-21AA-4D3B-9EA6-270D0FF9D6FC@buechse.de>

Good day,

I am trying to figure out, how the 2.0x distribution interacts with  
Suns implementation of javax.comm.CommPortIdentifier.

1) Apparently one can put javax.comm.properties in {java.home}/lib
2) The javax.comm package also reacts to -Djavax.comm.properties="...."

Looking at the javap output it also seems like CommPortIdentifier  
tries to find it's jar file and load the properties from there??


What I'm really looking for is a solution that allows using  
javax.comm with RXTX without modifying the VM installation. So I  
would prefer not to use 1) but I can't figure out how to use 2).

Any hints are welcome,
Joachim



From bob_tai2001 at yahoo.com  Mon Jun 19 15:00:35 2006
From: bob_tai2001 at yahoo.com (Bob Tai)
Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT)
Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place
	to start?
Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>

Hi, 

I got  rxtx Windows 2000 installed.  I did not use the
"best" way ... I just follow the insturuction and dump
the necessary files into the jre... I know it's "best"
idea, I got lazy didn't want to change my setting to
my Eclipse and classpath.

I was able to modify SimpleWrite.java to print on my
AddMaster serial printer.  I think I am ready to code!
But I need to make sure I can handle exceptions and so
on.  I notice the \samples\NullDriver\  has two files
seems to have some of the require method done, should
I start coding from those file?  I like the idea it
has the "time out" and basic exceptions done.   I am
slowly digging into the samples, but if you think any
of the code from Sun is good to checkout please let me
know.

btw, http://rxtx.qbang.org/wiki/index.php/Examples/
was very helpful, wish there are more examples.

thank you,

    Bob


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Mon Jun 19 15:55:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT)
Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good
 place to start?
In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>
References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606191542260.14139@www>

> I am
> slowly digging into the samples, but if you think any
> of the code from Sun is good to checkout please let me
> know.
>

I think NullDriver.java was an example stub driver for implementing 
something like rxtx.  It has been a while.  Unless they have been updated, 
you will find the examples are very dated.  You can look at how they use 
the port but avoid the GUI and hard coded variables (number of ports for 
instance).

There was no Swing and nobody knew what requirements today's compilers 
would make on code.  The examples worked fine with jdk 1.1 but times have 
changed.

--
Trent Jarvi
tjarvi at qbang.org


From tropicsu at hotmail.com  Mon Jun 19 19:49:08 2006
From: tropicsu at hotmail.com (Yoke K)
Date: Tue, 20 Jun 2006 01:49:08 +0000
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
Message-ID: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>

An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/fa588f00/attachment-0013.html

From ajmas at sympatico.ca  Mon Jun 19 21:14:37 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Mon, 19 Jun 2006 23:14:37 -0400
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>
References: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>
Message-ID: <CA22AB2A-5712-458B-9984-68477C6042AF@sympatico.ca>

Regarding the PortInUseException, I had a similar issue and got
this response from the mailing list:

   http://mailman.qbang.org/pipermail/rxtx/Week-of- 
Mon-20060619/062838.html

Andre
On 19-Jun-06, at 21:49 , Yoke K wrote:

> Hi Andre, Joachim
>
> I have tried using /dev/tty.usbserial and also /dev/cu.usbserial  
> and it also reported error as  "gnu.io.PortInUseException".
>
> The iTegno modem works in windows environment. As I moving around  
> using my ibook and I need to get it work on MAC OS as well.
>
> >> INFO: SMSLib API for Java / v1.2.2
> >> INFO: Using port: /dev/tty.usbserial @ 115200 baud.
> >> INFO: JRE Version: 1.5.0_06
> >> INFO: JRE Impl Version: 1.5.0_06-64
> >> INFO: O/S: Mac OS X / ppc / 10.4.6
> >> INFO: Using Wavecom (Generic) AT handler.
>
> SendMessage(): Send a message.
> Using SMSLib API for Java v1.2.2
>
> Connecting ..... :
> >> INFO: CSerialDriver(): Connecting...
> Experimental: JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version = RXTX-2.1-7
> >> INFO: CSerialDriver(): Disconnecting...
> gnu.io.PortInUseException: Unknown Application
> at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354)
> at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1)
> at org.smslib.CService.connect(CService.java:197)
> at SendMessage.main(SendMessage.java:38)
>
> Thanks.
>
> - Jon
>
>
>
>
> ====================
>
> Hello Jon,
>
> From OSX's standpoint a symbolic link is not a device (as far as I
> know). What stops you from using tty.usbserial? Did you try hard-
> linking?
>
> Regards,
> Joachim
>
>
>
> From:  "Yoke K" <tropicsu at hotmail.com>
> To:  rxtx at qbang.org
> Subject:  RXTX-2.1-7 / MAC OS X / NoSuchPortException
> Date:  Sat, 17 Jun 2006 15:32:48 +0000
> >Hi,
> >
> >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to
> >work with MAC OS X.
> >I am using iTegno 3000 - USB GPRS Modem.
> >
> >Files in /dev and a symbolic link as follows:
> >
> >crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
> >crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
> >lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->
> >tty.usbserial
> >
> >In my SendMessage.java, I have this line:
> >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
> >
> >Appreciate any help ?
> >
> >- Jon
> >
> >
> >Errors as follows:
> >
> >>>INFO: SMSLib API for Java / v1.2.2
> >>>INFO: Using port: /dev/ttyS1 @ 56000 baud.
> >>>INFO: JRE Version: 1.5.0_06
> >>>INFO: JRE Impl Version: 1.5.0_06-64
> >>>INFO: O/S: Mac OS X / ppc / 10.4.6
> >>>INFO: Using Wavecom (Generic) AT handler.
> >
> >SendMessage(): Send a message.
> >  Using SMSLib API for Java v1.2.2
> >
> >Connecting ..... :
> >>>INFO: CSerialDriver(): Connecting...
> >Experimental:  JNI_OnLoad called.
> >Stable Library
> >=========================================
> >Native lib Version = RXTX-2.1-7
> >Java lib Version   = RXTX-2.1-7
> >>>INFO: CSerialDriver(): Disconnecting...
> >gnu.io.NoSuchPortException
> >        at
> >gnu.io.CommPortIdentifier.getPortIdentifier 
> (CommPortIdentifier.java:218)
> >        at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
> >        at org.smslib.CService.connect(CService.java:197)
> >        at SendMessage.main(SendMessage.java:38)
> >
> >_________________________________________________________________
> >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
> >
>
> Find love online with MSN Personals
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Tue Jun 20 02:35:24 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 10:35:24 +0200
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>

Hello everybody,

I have been fighting a bit with the javax.comm version of RXTX the  
last days. I am working on the README .OSX now and try to figure out  
which should be the "suggested" installation.

The facts:
------

- the "generic" comm.jar version of javax.comm which has been made re- 
available tries to load com.sun.comm.SolarisDriver
- this classname can be overridden ONLY by putting a file  
javax.comm.properties in {java.home}/lib
- if it is not overridden and SolarisDriver.class is not found  
CommPortIdentifier will be disfunctional (in particual it is not  
possible to add CommPort's via CommPortIdentifier.add).
- the license distributed with comm.jar does not allow the  
modification/addition of classes in javax.comm (however no mention of  
com.sun...)


What really bothers me is to suggest putting this config file in the  
"global" vm installation. This is particularly ugly on the Mac as  
there are several VM installations and the file may be forgotten.  
Additionally it may create versioning problems. I prefer an  
installation where all files are local to the application (even  
comm.jar).

In my opinion the ideal situation would be:
------

1) The author of a program compiles against javax.comm.
2a) For platforms supported by Sun the user is free to use the 3.0  
comm.jar download from Sun
2b) For platforms not supported by Sun the user adds RXTXComm.jar to  
the classpath of the application (and librxtxSerial.jnilib to the  
application directory). Also he will need the 2.0.3 generic comm.jar  
from Sun.
3) Nobody messes with the global VM installation.

Of course 2a) and 2b) could be handled by the author of the program  
via an appropriate installer. The author could also decide to always  
use RXTX and include the generic javax.comm classes as well as the  
RXTX classes in his application jar. [If he further uses an explicit  
call to System.load() he may even include the jnilib(s) in the jar,  
extract it (based on the platform name) at runtime to a temp file and  
load it from there.]


Suggested solution:
------

We only need to put the following class in the classpath BEFORE Suns  
comm.jar

   package com.sun.comm;
   public class SolarisDriver extends gnu.io.RXTXCommDriver {
   }

This is not "the pure art" (TM). It depends on an implementation  
detail of the generic driver. However, so does the  
javax.comm.properties file - as we have seen when Sun released 3.0.  
It has the following advantages:

- The "generic" javax.comm implementation will happily load this  
class as its primary driver.
- No javax.comm.properties file is required.
- This does not violate the javax.comm license agreement as there is  
no mention of the "com.sun.comm" package in this license agreement at  
all.
- Authors packaging comm.jar with their application can strip out all  
com.sun.comm classes from comm.jar


Please comment!

Joachim



From joachim at buechse.de  Tue Jun 20 02:50:36 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 10:50:36 +0200
Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar
Message-ID: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>

There has been some discussions about the best way to install RXTX  
and where to place files.

I suggest that,

- we include the native libraries for the most common operating  
systems (in a special version of) RXTXcomm.jar
- we add loader code which tries to extract and load the platform  
specific binary at runtime
- on failure the current mechanism remains as a fallback

Wether the current mechanism should have priority (ie loadLibrary  
before load) remains to be discussed.


The advantages of this solution are
  - users of RXTX do not need to worry about java/platform specific  
file placement.
  - authors of applications may fully merge RXTX into their  
application jar (which provides a double-clickable application for  
Windows and OSX, Linux?).

Please comment,
Joachim

PS: Of course the suggested solution is already possible today,  
however relatively few programmers know how to correctly extract a  
binary resource file via the class loader and load it as a native  
library.


From tjarvi at qbang.org  Tue Jun 20 03:58:12 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT)
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
Message-ID: <Pine.LNX.4.61.0606200335190.14139@www>

> 2a) For platforms supported by Sun the user is free to use the 3.0
> comm.jar download from Sun
> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to
> the classpath of the application (and librxtxSerial.jnilib to the
> application directory). Also he will need the 2.0.3 generic comm.jar
> from Sun.

As there are no plans to support CommAPI 3.0 due to the limitations in its 
implementation mentioned before, I would not recommend projects use Sun's 
3.0 comm.jar.  They will lose the freedom to chose their low level 
implementation by being locked into vendor specific modifications.

Projects should chose between platform neutrality in CommAPI 2.0 and 
reduced platform neutrality in commapi 3.0.  Projects should also strongly 
consider the fact that the 2.0 comm.jar targets only a reduced number of 
JVMs.

Projects can go with rxtx 2.1 or other packages but should probably only 
consider using Sun CommAPI with rxtx if they did so in the past.  They 
should take steps to no longer depend upon this option being available.

> Suggested solution:
> ------
>
> We only need to put the following class in the classpath BEFORE Suns
> comm.jar
>
>   package com.sun.comm;
>   public class SolarisDriver extends gnu.io.RXTXCommDriver {
>   }
>
> This is not "the pure art" (TM). It depends on an implementation
> detail of the generic driver. However, so does the
> javax.comm.properties file - as we have seen when Sun released 3.0.
> It has the following advantages:
>
> - The "generic" javax.comm implementation will happily load this
> class as its primary driver.
> - No javax.comm.properties file is required.
> - This does not violate the javax.comm license agreement as there is
> no mention of the "com.sun.comm" package in this license agreement at
> all.
> - Authors packaging comm.jar with their application can strip out all
> com.sun.comm classes from comm.jar
>

I would not encourage people to place packages in the com.sun.comm 
namespace.  Authors using Sun's commapi 2.0 should just realize it is 
greatly limited in practical utility and consider moving to something that 
isn't being rescued from EOL.

The primary focus of this release is projects previously depending upon 
Sun CommAPI + RXTX.  There are no plans at this time to provide future 
support in this arrangement due to technical incompatabilities we have no 
control over in commapi 3.0 and limited utility of Sun's generic comm.jar 
in commapi 2.0 offered.  Projects should be aware of this so they can make 
appropriate plans.

--
Trent Jarvi
tjarvi at qbang.org


From paul.klissner at sun.com  Tue Jun 20 05:24:00 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Tue, 20 Jun 2006 04:24:00 -0700
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
In-Reply-To: <Pine.LNX.4.61.0606200335190.14139@www>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
	<Pine.LNX.4.61.0606200335190.14139@www>
Message-ID: <4497DAD0.10803@sun.com>

Trent Jarvi wrote:
>> 2a) For platforms supported by Sun the user is free to use the 3.0
>> comm.jar download from Sun
>> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to
>> the classpath of the application (and librxtxSerial.jnilib to the
>> application directory). Also he will need the 2.0.3 generic comm.jar
>> from Sun.
> 
> As there are no plans to support CommAPI 3.0 due to the limitations in its 
> implementation mentioned before, I would not recommend projects use Sun's 
> 3.0 comm.jar.  They will lose the freedom to chose their low level 
> implementation by being locked into vendor specific modifications.
> 
> Projects should chose between platform neutrality in CommAPI 2.0 and 
> reduced platform neutrality in commapi 3.0.  Projects should also strongly 
> consider the fact that the 2.0 comm.jar targets only a reduced number of 
> JVMs.

Well, that's a little ambiguous because the API is the same
either way.  We're talking about Sun's implementation vs.
other implementations.
> 
> Projects can go with rxtx 2.1 or other packages but should probably only 
> consider using Sun CommAPI with rxtx if they did so in the past.  They 
> should take steps to no longer depend upon this option being available.

3.0 is platform centric because there is a need to add some
platform awareness to Sun's implementation, and the choices
for how to do that are limited by the constraints of the API,
as mentioned in the javax.comm 2.0.3 comm.jar download's README.

I am really advocating getting a JSR open (http://www.jcp.org)
to push a new comm API that is more pluggable, platform neutral
and addresses some of the deficiencies of the current API. Then
we can achieve the optimal of platform neutrality while
simulataneously allowing the API to flexibly adapt to
heterogeneous environments.

This is not a question of attitude, this is an issue of resources,
time and commitment.  The current owners of javax.comm within
Sun would like nothing better than to see the ideal reached for
the API and a model that will extend well beyond the foreseeable
future and work for the industry overall.



> 
>> Suggested solution:
>> ------
>>
>> We only need to put the following class in the classpath BEFORE Suns
>> comm.jar
>>
>>   package com.sun.comm;
>>   public class SolarisDriver extends gnu.io.RXTXCommDriver {
>>   }
>>
>> This is not "the pure art" (TM). It depends on an implementation
>> detail of the generic driver. However, so does the
>> javax.comm.properties file - as we have seen when Sun released 3.0.
>> It has the following advantages:
>>
>> - The "generic" javax.comm implementation will happily load this
>> class as its primary driver.
>> - No javax.comm.properties file is required.
>> - This does not violate the javax.comm license agreement as there is
>> no mention of the "com.sun.comm" package in this license agreement at
>> all.
>> - Authors packaging comm.jar with their application can strip out all
>> com.sun.comm classes from comm.jar
>>
> 
> I would not encourage people to place packages in the com.sun.comm 
> namespace.  Authors using Sun's commapi 2.0 should just realize it is 
> greatly limited in practical utility and consider moving to something that 
> isn't being rescued from EOL.
> 
> The primary focus of this release is projects previously depending upon 
> Sun CommAPI + RXTX.  There are no plans at this time to provide future 
> support in this arrangement due to technical incompatabilities we have no 
> control over in commapi 3.0 and limited utility of Sun's generic comm.jar 
> in commapi 2.0 offered.  Projects should be aware of this so they can make 
> appropriate plans.

Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86,
or need the powerful portmapping features in javax.com 3.0, or would like to
acquire the Interactive Serial Port Test utility.

-Paul


From paul.klissner at sun.com  Tue Jun 20 05:33:44 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Tue, 20 Jun 2006 04:33:44 -0700
Subject: [Rxtx] Suggested installation RXTX 2.0x...
In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
Message-ID: <4497DD18.70207@sun.com>

Joachim Buechse wrote:
> Hello everybody,
> 
> I have been fighting a bit with the javax.comm version of RXTX the  
> last days. I am working on the README .OSX now and try to figure out  
> which should be the "suggested" installation.
> 
> The facts:
> ------
> 
> - the "generic" comm.jar version of javax.comm which has been made re- 
> available tries to load com.sun.comm.SolarisDriver
> - this classname can be overridden ONLY by putting a file  
> javax.comm.properties in {java.home}/lib
> - if it is not overridden and SolarisDriver.class is not found  
> CommPortIdentifier will be disfunctional (in particual it is not  
> possible to add CommPort's via CommPortIdentifier.add).
> - the license distributed with comm.jar does not allow the  
> modification/addition of classes in javax.comm (however no mention of  
> com.sun...)
> 
> 
> What really bothers me is to suggest putting this config file in the  
> "global" vm installation. This is particularly ugly on the Mac as  
> there are several VM installations and the file may be forgotten.  
> Additionally it may create versioning problems. I prefer an  
> installation where all files are local to the application (even  
> comm.jar).
> 
> In my opinion the ideal situation would be:
> ------
> 
> 1) The author of a program compiles against javax.comm.
> 2a) For platforms supported by Sun the user is free to use the 3.0  
> comm.jar download from Sun
> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to  
> the classpath of the application (and librxtxSerial.jnilib to the  
> application directory). Also he will need the 2.0.3 generic comm.jar  
> from Sun.
> 3) Nobody messes with the global VM installation.
> 
> Of course 2a) and 2b) could be handled by the author of the program  
> via an appropriate installer. The author could also decide to always  
> use RXTX and include the generic javax.comm classes as well as the  
> RXTX classes in his application jar. [If he further uses an explicit  
> call to System.load() he may even include the jnilib(s) in the jar,  
> extract it (based on the platform name) at runtime to a temp file and  
> load it from there.]
> 

This was how the Sun implementation originated (I did not write
that code).  I completely agree, and I fixed the whole conf file
locating mechanism in 3.0 to avoid the problems youmentioned.
However, I was unaware of how RxTx was using Sun's implementation,
so I didn't architect it in such a way as to avoid namespace pollution
in the native space in for the backend provider.  In retrospect,
I should have done that differently just as a design principle,
but at this point I don't have the spare cycles to get that all
re-factored.  Further, I'm loathe to do it, because the whole
thing will still be an under-the-hood hack due to the constraints
of the API itself.

Paul





From brian at mbari.org  Tue Jun 20 10:23:54 2006
From: brian at mbari.org (Brian Schlining)
Date: Tue, 20 Jun 2006 09:23:54 -0700
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>


Hi Joachim,

> There has been some discussions about the best way to install RXTX
> and where to place files.
>
> I suggest that,
>
> - we include the native libraries for the most common operating
> systems (in a special version of) RXTXcomm.jar
> - we add loader code which tries to extract and load the platform
> specific binary at runtime
> - on failure the current mechanism remains as a fallback

I like your suggestion. However, my understanding is that in general  
the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH  
(Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to  
be loaded by the JVM. The alternative is to point to your native lib  
directory using -Djava.library.path=/my/dir/with/native/libs when you  
launch the JVM. So, I'm very interested to know how you're planning  
to work around this.

> PS: Of course the suggested solution is already possible today,
> however relatively few programmers know how to correctly extract a
> binary resource file via the class loader and load it as a native
> library.

So how do you use it to dynamically load a native lib? I've read that  
you can't really modify the java.library.path after the JVM has been  
launched. (http://forum.java.sun.com/thread.jspa? 
threadID=627890&tstart=90)

Thanks

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0022.html

From joachim at buechse.de  Tue Jun 20 09:20:29 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 17:20:29 +0200
Subject: [Rxtx] 2.0x in sync with 2.1x
Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>

I have added most of the changes from the 2.1 branch to the 2.0 branch.

This includes
  - correction of illegal javadoc comments
  - implementation errors in handling of Thread.interrupt in  
RXTXPort.java
  - MacOS X locking without lock files/special user groups
  - XCode project which builds a universal binary library
  - updated documentation for OSX

I have done some minimal testing (only G4).
[Trent: there are still some changes you made for specific baud  
rates. I will not sync this, as I can not test them. From my  
perspective we are ready for 2.08/2.18]

The updated documentation can be found in the file README.OSX. Here  
it is:

------------------------ Required files -----------------------

To use or compile RXTX 2.0.x you need to downlad the "generic"  
version (2.0.3)
of the javax.comm implementation from Sun. The zip you download  
contains an
archive comm.jar which is required:

- To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar

- To run the app you will need comm.jar in the classpath or in  
{java.lib.path}


------------------------ Installation on MacOSX -----------------------

WARNING: Please read this section until the end.

---
Preparation
---

You may want to spare your users the burden of modifying the global VM
installation. OSX has several different VM versions installed by  
default and
regular users will be unable to figure out which version will load your
application.

If you provide the class

package com.sun.comm;
public class SolarisDriver extends gnu.io.RXTXCommDriver {
}

and make sure, that it is present in the classpath before Suns  
"generic" comm.jar
your users can skip the following step:

Create a file named
    javax.comm.properties
in the directory
    /System/Library/Frameworks/JavaVM.framework/Home/lib/
which contains (only) the following line (no leading space):
    Driver=gnu.io.RXTXCommDriver



----
The unsafe way of using RXTX on OS X:
----

RXTX can be installed by putting the files
   libSerial.jnilib
   RXTXcomm.jar
   comm.jar
into the folder
   /Library/Java/Extensions

This is NOT RECOMMENDED as it creates versioning conflicts among  
applications.
However you may be forced to install it this way if an application  
was written
for Windows or Linux, requires RXTX and you are not able to change  
its starter.


----
The safe way of using RXTX on OS X:
----

Make sure that you have no (older) version of RXTX installed in
   /Library/Java/Extensions
   /System/Library/Java/Extensions
   /usr/lib/java

Put
   libSerial.jnilib
in the directory of the application (the JavaVM will find it there). Add
   RXTXComm.jar
   comm.jar
to the application classpath or include the classes in the  
application jar.
(Some applications already include the RXTX classes in their  
application jar,
in which case only the file libSerial.jnilib is required).


----
History
----

Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation  
of lockfiles
required special permissions for the user executing an application  
based on RXTX.
To simplify the setup RXTX came with an installer modifying group  
permissions
and installing RXTX in the global location /Library/Java/Extensions.  
However
this was prune to versioning conflicts and is no longer recommended.

--------------------- Build instructions for OSX XCode  
-------------------

contributed by Joachim Buechse <joachim at buechse.de>
original version by Dmitry Markman <dmarkman at mac.com>

System requirements for building:
MacOSX 10.4
XCode 2.3

   open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj
   choose libSerial.jnilib target
   build

After the build you will find RXTXcomm.jar and libSerial.jnilib files  
in the
directory build/Development.

In case you can't find RXTXcomm.jar build the RXTXcomm target manually.
In case of (serious) problems feel free to contact joachim at buechse.de .



From tjarvi at qbang.org  Tue Jun 20 22:01:45 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT)
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
Message-ID: <Pine.LNX.4.61.0606202127270.14139@www>

> ---
> Preparation
> ---
>
> You may want to spare your users the burden of modifying the global VM
> installation. OSX has several different VM versions installed by
> default and
> regular users will be unable to figure out which version will load your
> application.
>
> If you provide the class
>
> package com.sun.comm;
> public class SolarisDriver extends gnu.io.RXTXCommDriver {
> }
>
> and make sure, that it is present in the classpath before Suns
> "generic" comm.jar
> your users can skip the following step:

Hi Joachim

With regards to the above, I have not seen that we have Sun's OK to 
promote that.  I'm not very comfortable with the distribution 
documentation advocating this without Sun agreeing.

I see your point but I'd rather not actively promote putting classes in 
Sun's namespace without permission if you don't mind.  This isn't about 
what is in a license.

I'll go through the code tomorrow night.  It was a late night at work 
today.  There is also a w32 fix comming for people opening and closing 
multiple ports.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Wed Jun 21 01:56:45 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 21 Jun 2006 09:56:45 +0200
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <Pine.LNX.4.61.0606202127270.14139@www>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
	<Pine.LNX.4.61.0606202127270.14139@www>
Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>

Hello Trent,

I guess we will not get an explicit OK from Sun for such a hack. I  
think Paul has made it pretty clear, that he does not have the  
resources to modify the 2.x or 3.x code for the needs of RXTX. I'm  
not thrilled but OK with the current API. Hence I dont agree with  
Paul's idea to start a new JSR to fix the implementation - but that's  
mainly because I dont have the time to push it. According to their  
Readme Sun sees no business case in having cross platform support for  
javax.comm - that is sad but it's none of my business. However I  
prefer to program versus javax.comm in my projects as this gives an  
advanced user the chance to exchange the provider without access to  
the code.

I interpret Pauls reponse to my original "Request for comment" as a  
quiet acceptance of the hack I propose (he did respond, but not at  
all to the sun.comm namespace suggestion). This is certainly not  
something we should put into RXTXcomm.jar but hinting a work around  
for implementation errors should be allowed. That's why I've choosen  
the wording "You may want to spare" and "If you provide". The company  
I worked for has choosen similar hacks for years to fix bugs in swing  
for JDK1.1 applications. Those hacks were usually included in their  
own swingpatch.jar.

Having said all that - I do not take it as an insult if you remove  
the paragraph from the Readme. I appreciate that you notified me  
before. It would be interesting to hear some more opinions from the  
list members...

Best regards,
Joachim


On 21.06.2006, at 06:01, Trent Jarvi wrote:

>> ---
>> Preparation
>> ---
>>
>> You may want to spare your users the burden of modifying the  
>> global VM
>> installation. OSX has several different VM versions installed by
>> default and
>> regular users will be unable to figure out which version will load  
>> your
>> application.
>>
>> If you provide the class
>>
>> package com.sun.comm;
>> public class SolarisDriver extends gnu.io.RXTXCommDriver {
>> }
>>
>> and make sure, that it is present in the classpath before Suns
>> "generic" comm.jar
>> your users can skip the following step:
>
> Hi Joachim
>
> With regards to the above, I have not seen that we have Sun's OK to
> promote that.  I'm not very comfortable with the distribution
> documentation advocating this without Sun agreeing.
>
> I see your point but I'd rather not actively promote putting  
> classes in
> Sun's namespace without permission if you don't mind.  This isn't  
> about
> what is in a license.
>
> I'll go through the code tomorrow night.  It was a late night at work
> today.  There is also a w32 fix comming for people opening and closing
> multiple ports.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Wed Jun 21 02:03:33 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 21 Jun 2006 10:03:33 +0200
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
	<6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
Message-ID: <BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>

See System.load(String) [it's also mentioned under the URL you posted].

Regards,
Joachim


On 20.06.2006, at 18:23, Brian Schlining wrote:

> So how do you use it to dynamically load a native lib? I've read  
> that you can't really modify the java.library.path after the JVM  
> has been launched. (http://forum.java.sun.com/thread.jspa? 
> threadID=627890&tstart=90)
>
> Thanks
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From baris.ozkan at elikasu.com.tr  Wed Jun 21 07:58:06 2006
From: baris.ozkan at elikasu.com.tr (Baris)
Date: Wed, 21 Jun 2006 16:58:06 +0300
Subject: [Rxtx] RS 232 ..additional parameters
Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>

Hi,
 
Currently i am developing an application that requires to connect to a
remote rs232 device through  a dialup connection.
 
My problem is that the communication needs several more connection
parameters (i extracted that information from the vendor's dll , listed at
the end of the message)
 
I explored rxtx API and src files and could not find methods to set a
majority  of the parameters.
Am i missing any point or does rxtx is limited to soem standard set of
functionality(e.g. commAPI)? How  is it possible ,if i want to put some
extensions(???) to current rxtx implementation?
 
I am not very good at rs232 programming so excuse me if this message  is
boring one.
 
Thanx
 
Baris Ozkan
 
 
A Listing of Parameters:
 
 
typedef struct _DCB {

DWORD DCBlength; /* sizeof(DCB) */

DWORD BaudRate; /* Baudrate at which running */

DWORD fBinary: 1; /* Binary Mode (skip EOF check) */

DWORD fParity: 1; /* Enable parity checking */

DWORD fOutxCtsFlow:1; /* CTS handshaking on output */

DWORD fOutxDsrFlow:1; /* DSR handshaking on output */

DWORD fDtrControl:2; /* DTR Flow control */

DWORD fDsrSensitivity:1; /* DSR Sensitivity */

DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */

DWORD fOutX: 1; /* Enable output X-ON/X-OFF */

DWORD fInX: 1; /* Enable input X-ON/X-OFF */

DWORD fErrorChar: 1; /* Enable Err Replacement */

DWORD fNull: 1; /* Enable Null stripping */

DWORD fRtsControl:2; /* Rts Flow control */

DWORD fAbortOnError:1; /* Abort all reads and writes on Error */

DWORD fDummy2:17; /* Reserved */

WORD wReserved; /* Not currently used */

WORD XonLim; /* Transmit X-ON threshold */

WORD XoffLim; /* Transmit X-OFF threshold */

BYTE ByteSize; /* Number of bits/byte, 4-8 */

BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */

BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */

char XonChar; /* Tx and Rx X-ON character */

char XoffChar; /* Tx and Rx X-OFF character */

char ErrorChar; /* Error replacement char */

char EofChar; /* End of Input character */

char EvtChar; /* Received Event character */

WORD wReserved1; /* Fill for now. */

} DCB, *LPDCB;

typedef struct _COMMTIMEOUTS {

DWORD ReadIntervalTimeout; /* Maximum time between read chars. */

DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */

DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */

DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */

DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */

} COMMTIMEOUTS,*LPCOMMTIMEOUTS;

dcb.fOutX = FALSE;

dcb.fInX = FALSE;

dcb.fOutxCtsFlow = FALSE;

dcb.fBinary = TRUE;

dcb.fRtsControl = RTS_CONTROL_ENABLE;

SetCommState(hComm , &dcb ); 

COMMTIMEOUTS commTimeOut;

GetCommTimeouts(hComm, &commTimeOut );

commTimeOut.WriteTotalTimeoutMultiplier = 1; 

commTimeOut.WriteTotalTimeoutConstant = 18; 

// commTimeOut.ReadIntervalTimeout = 28; 

commTimeOut.ReadIntervalTimeout = 0; 

// commTimeOut.ReadTotalTimeoutMultiplier = 184; 

commTimeOut.ReadTotalTimeoutMultiplier = 300; 

// commTimeOut.ReadTotalTimeoutConstant = 1200;

commTimeOut.ReadTotalTimeoutConstant = 1200;

SetCommTimeouts(hComm, &commTimeOut);

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0022.html

From ajmas at sympatico.ca  Wed Jun 21 08:14:26 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Wed, 21 Jun 2006 10:14:26 -0400
Subject: [Rxtx] When is 2.18 planned for?
Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

Just curious as to know if there is a target date for 2.18?

Andre



From brian at mbari.org  Wed Jun 21 09:36:00 2006
From: brian at mbari.org (Brian Schlining)
Date: Wed, 21 Jun 2006 08:36:00 -0700
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
	<6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
	<BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>
Message-ID: <A21C9BC0-7894-4B08-AC82-44E11AB3D461@mbari.org>

Ha!!

I suppose I should read my own postings. ;-)

Thanks
B

On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote:

> See System.load(String) [it's also mentioned under the URL you  
> posted].
>
> Regards,
> Joachim
>
>
> On 20.06.2006, at 18:23, Brian Schlining wrote:
>
>> So how do you use it to dynamically load a native lib? I've read
>> that you can't really modify the java.library.path after the JVM
>> has been launched. (http://forum.java.sun.com/thread.jspa?
>> threadID=627890&tstart=90)

Brian Schlining
Software Engineer
http://www.mbari.org




From ajmas at sympatico.ca  Wed Jun 21 16:41:28 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Wed, 21 Jun 2006 18:41:28 -0400
Subject: [Rxtx] CVS build question
Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X:

 The JCL extension to RxTx requires comm.jar
 If you intend to use RxTx for commapi support comm.jar
 needs to be located in  /System/Library/Frameworks/JavaVM.framework/
  Versions/1.5/Home/lib/ext/comm.jar

I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me.

On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native).

Andre






From tjarvi at qbang.org  Wed Jun 21 18:00:04 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT)
Subject: [Rxtx] CVS build question
In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606211756310.14139@www>

On Wed, 21 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> Is the CVS repository meant to build for gnu.io or javax.comm? I ask 
> this, because I see the following when calling ./configure from MacOS X:
>
> The JCL extension to RxTx requires comm.jar
> If you intend to use RxTx for commapi support comm.jar
> needs to be located in  /System/Library/Frameworks/JavaVM.framework/
>  Versions/1.5/Home/lib/ext/comm.jar
>
> I am wanting to build for the gnu.io package, since I want to jump ahead 
> and see if the changes, intended for 2.18 for MacOS X, work for me.
>
> On a side note /Library/Java/Extensions should be included as a valid 
> search path for the JAR, since this is where Apple recommends placing 
> third party extensions (both Java and native).
>

rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel"
rxtx 2.0 src is obtained with "cvs checkout rxtx-devel"

rxtx 2.1 is a complete package in namespace gnu.io
rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 18:02:23 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT)
Subject: [Rxtx] When is 2.18 planned for?
In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606211800180.14139@www>

On Wed, 21 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> Just curious as to know if there is a target date for 2.18?
>

Hi Andre

"When it is ready" :)

Probably this weekend.  Maybe sooner.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 18:10:18 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT)
Subject: [Rxtx] RS 232 ..additional parameters
In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>
References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>
Message-ID: <Pine.LNX.4.61.0606211805010.14139@www>

On Wed, 21 Jun 2006, Baris wrote:

> Hi,
>
> Currently i am developing an application that requires to connect to a
> remote rs232 device through  a dialup connection.
>
> My problem is that the communication needs several more connection
> parameters (i extracted that information from the vendor's dll , listed at
> the end of the message)
>
> I explored rxtx API and src files and could not find methods to set a
> majority  of the parameters.
> Am i missing any point or does rxtx is limited to soem standard set of
> functionality(e.g. commAPI)? How  is it possible ,if i want to put some
> extensions(???) to current rxtx implementation?
>
> I am not very good at rs232 programming so excuse me if this message  is
> boring one.
>
> Thanx
>

Hi Baris

> typedef struct _DCB {
> typedef struct _COMMTIMEOUTS {

These are all handled in termios.c.  It is possible to add extensions to 
rxtx 2.1.  It may well be that the defaults are the same for the variables 
not covered by the existing API.  You can dump the DCB and COMMTIMEOUTS 
from inside termios.c to compare.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 20:23:30 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT)
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
	<Pine.LNX.4.61.0606202127270.14139@www>
	<789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>
Message-ID: <Pine.LNX.4.61.0606212012210.14139@www>

> I'm
> not thrilled but OK with the current API. Hence I dont agree with
> Paul's idea to start a new JSR to fix the implementation - but that's
> mainly because I dont have the time to push it. According to their
> Readme Sun sees no business case in having cross platform support for
> javax.comm - that is sad but it's none of my business. However I
> prefer to program versus javax.comm in my projects as this gives an
> advanced user the chance to exchange the provider without access to
> the code.

Hi Joachim

With regards to the JSR, I think that would be Doug's call.  The effort I 
put in would have to be on my own time which would not be a great deal.  I 
could help things go smoothly but thats not the same as pushing something 
through.

--
Trent Jarvi
tjarvi at qbang.org



From vt at freehold.crocodile.org  Wed Jun 21 21:05:22 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Wed, 21 Jun 2006 20:05:22 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
Message-ID: <449A08F2.3020106@freehold.crocodile.org>

Hello all,

I know this question may belong to JSR lists, but since all interested 
parties are here, I thought I just ask this question here, again...

A while ago I run into a problem and wrote a rant, here: 
http://servomaster.sourceforge.net/dev/serial-usb.html
At the time of writing I didn't think of adding another possible 
solution - changing the CommAPI specs to support removable devices. 
Apparently, Serial/USB bridges are here to stay, and this issue has to 
be addressed.

Wonder if anything changed since, and any abstractions for supporting 
removable devices made it into current or future Java CommAPI drafts - 
Paul, any comments?

--vt



From joachim at buechse.de  Thu Jun 22 01:59:54 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 22 Jun 2006 09:59:54 +0200
Subject: [Rxtx] CVS build question
In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de>

Hello Andre,

I am not sure how well the configure/make mechanism will work on OSX.  
I know that a while ago some contributors tried to get configure/make  
working on OSX but from comments I found in the readmes this work was  
only partially successfull. For compilation on OSX we have used the  
ProjectBuilder/XCode projects you can find in MACOSX_IDE.

Regarding the  ./configure comment:
RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config  
file javax.comm.properties. The later MUST reside in {java.home}/lib.  
As the two only work together putting comm.jar into  /Library/Java/ 
Extensions  and hence making it available to all current and future  
VM installations will only add to confusion.

Regards,
Joachim

On 22.06.2006, at 00:41, Andre-John Mas wrote:

> Hi,
>
> Is the CVS repository meant to build for gnu.io or javax.comm? I  
> ask this, because I see the following when calling ./configure from  
> MacOS X:
>
>  The JCL extension to RxTx requires comm.jar
>  If you intend to use RxTx for commapi support comm.jar
>  needs to be located in  /System/Library/Frameworks/JavaVM.framework/
>   Versions/1.5/Home/lib/ext/comm.jar
>
> I am wanting to build for the gnu.io package, since I want to jump  
> ahead and see if the changes, intended for 2.18 for MacOS X, work  
> for me.
>
> On a side note /Library/Java/Extensions should be included as a  
> valid search path for the JAR, since this is where Apple recommends  
> placing third party extensions (both Java and native).
>
> Andre
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Thu Jun 22 02:51:05 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 22 Jun 2006 10:51:05 +0200
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449A08F2.3020106@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>

Hello Vadim,

I think that your rant is to the point. However it is a bit like  
saying that Windows is at the source of email degradation and the  
only solution is to have users switch to safer operating systems.

I don't see how javax.comm or RXTX can address the problems you  
mention. Of course it would be super cool if javax.comm could magicly  
find the "matching" usb-device and query it's configuration via the  
usb protocol - however this magic (mapping /dev/xyz to its underlying  
USB device) is not supported by any kernel APIs I am aware of. It  
could be supported via POSSIX ioctl calls but then you should address  
your rant to the POSSIX group...

So for the time beeing it's either up to the virtual comm port driver  
to provide a usefull name under /dev/ or to the user choosing the  
right port to use. One example of a smart(er) com port driver is the  
KDDI driver for OSX, which will create device names like "/dev/ 
cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- 
encoded into the bridge chip. The same driver for windows also has  
some options allowing it in theory to recreate the same COMx every  
time a device is plugged/unplugged.

For most industrial applications however it will be up to the user to  
choose the right port (without getting a lot of help doing so).

Probing serial ports can go wrong, that's right. However any serial  
device developper would be well adviced to implement a basic set of  
Hayes AT modem commands (be it a modem or not). Especially AT I0.  
Anyone failing to do so risks that the users favourite TCP/PPP/FAX  
application or stack will kill the device in short time.

Best regards,
Joachim


On 22.06.2006, at 05:05, Vadim Tkachenko wrote:

> Hello all,
>
> I know this question may belong to JSR lists, but since all interested
> parties are here, I thought I just ask this question here, again...
>
> A while ago I run into a problem and wrote a rant, here:
> http://servomaster.sourceforge.net/dev/serial-usb.html
> At the time of writing I didn't think of adding another possible
> solution - changing the CommAPI specs to support removable devices.
> Apparently, Serial/USB bridges are here to stay, and this issue has to
> be addressed.
>
> Wonder if anything changed since, and any abstractions for supporting
> removable devices made it into current or future Java CommAPI drafts -
> Paul, any comments?
>
> --vt
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From vt at freehold.crocodile.org  Thu Jun 22 13:16:03 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 12:16:03 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
Message-ID: <20060622191603.GA17487@freehold.crocodile.org>

Hello Joachim,

> I think that your rant is to the point. However it is a bit like  
> saying that Windows is at the source of email degradation and the  
> only solution is to have users switch to safer operating systems.

I guess the problem is that the rant itself is obsolete and has to be
updated according to latest developments. At the time of writing there
weren't that many bridges around, and the trend didn't manifest itself as it
does now.

> I don't see how javax.comm or RXTX can address the problems you  
> mention.

I would agree that javax.comm won't be able to address the problem, at least
in the short run. As for RxTx - well, nobody prevents it from being a
superset of CommAPI specification, right? RxTx being the de-facto standard
for quite a few platforms, I'd daresay the standard may follow.

> Of course it would be super cool if javax.comm could magicly find the
> "matching" usb-device and query it's configuration via the usb protocol -
> however this magic (mapping /dev/xyz to its underlying USB device) is not
> supported by any kernel APIs I am aware of. It could be supported via
> POSSIX ioctl calls but then you should address your rant to the POSSIX
> group...

As a matter of fact, my bigger concern is addressing the fact that a serial
device can now be removable. This hasn't been the case before, and it
clearly is now. Regarding the above, well, I guess if we accept this fact,
we also need to accept the fact that we need at least rudimentary means of
identification of a serial device. For the USB case, it would usually be the
vendor/product ID, plus possible serial number - but it is irrelevant what
exactly the identifying information is, as long as it allows to identify the
device.

A paradigm shift is required, this is what I wanted to say. Serial devices
can be removed and replaced, it's now our turn to learn to deal with it.

> Joachim

--vt


From jredman at ergotech.com  Thu Jun 22 13:41:44 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 13:41:44 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
Message-ID: <449AF278.6000903@ergotech.com>


Vadim Tkachenko wrote:
> A paradigm shift is required, this is what I wanted to say. Serial devices
> can be removed and replaced, it's now our turn to learn to deal with it.

The removal if the serial port hardly significantly different from the 
removal of the device attached to the serial port.   Different, 
slightly, but not a "paradigm shift".

And yes, someone could unplug a USB serial device and plug it into a 
different USB port so that it has a different name/number, but they 
could do that with the device itself, move it from com1 to com2.

Am I missing something?

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 13:57:27 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 12:57:27 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449AF278.6000903@ergotech.com>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
Message-ID: <20060622195727.GA20247@freehold.crocodile.org>

On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote:
> 
> Vadim Tkachenko wrote:
> > A paradigm shift is required, this is what I wanted to say. Serial devices
> > can be removed and replaced, it's now our turn to learn to deal with it.
> 
> The removal if the serial port hardly significantly different from the 
> removal of the device attached to the serial port.   Different, 
> slightly, but not a "paradigm shift".
> 
> And yes, someone could unplug a USB serial device and plug it into a 
> different USB port so that it has a different name/number, but they 
> could do that with the device itself, move it from com1 to com2.
> 
> Am I missing something?

Yes, the fact that they could unplug a device A and plug a device B. With
the introduction of the concept of removability, the notion of the serial
port itself is not as important anymore, but the notion of the unique device
identifier is.

Consider a situation: long running system (enterprise HVAC, tens of nodes,
tens of thousands square feet area, hundreds of thousand dollars worth of
equipment being conditioned, can't shut down), serial/usb device fails, is
replaced by an identical device with a different serial #.

A little bit farfetched, but hopefully highlighting the point I'm trying to
make.

> Jim

--vt


From jredman at ergotech.com  Thu Jun 22 14:37:38 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 14:37:38 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>	<20060622191603.GA17487@freehold.crocodile.org>	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
Message-ID: <449AFF92.8080003@ergotech.com>


Vadim Tkachenko wrote:
>>
>> Am I missing something?
> 
> Yes, the fact that they could unplug a device A and plug a device B. With
> the introduction of the concept of removability, the notion of the serial
> port itself is not as important anymore, but the notion of the unique device
> identifier is.

Serial devices are always removable.  I could unplug _serial_ device A 
and plug in _serial_ device B.  We have systems running with two RS485 
ports, one talks to a Modbus PLC network one to a number of drives on a 
proprietary protocol.  If you plug the wrong DB9 into the wrong port the 
application doesn't work.

If you dangle a USB 485 converter on the end of the DB9 you've just 
moved the problem from RS485 to USB, but the problem/effect is the same.

> 
> Consider a situation: long running system (enterprise HVAC, tens of nodes,
> tens of thousands square feet area, hundreds of thousand dollars worth of
> equipment being conditioned, can't shut down), serial/usb device fails, is
> replaced by an identical device with a different serial #.
> 
> A little bit farfetched, but hopefully highlighting the point I'm trying to
> make.

Nothing's changed.  If I had a 4 port ISA board and plugged it into my 
new shiny '386 machine.  I could have com ports 9-12.  If I took a board 
off the shelf and didn't set the jumpers, I would have com ports 3-6.

The problem's the same.  If you replace with identical product then the 
com ports  will be the same - no software changes required.  If you 
replace one piece of hardware with hardware from a different 
manufacturer, then the naming/numbering may change.  You're physically 
changing the system, so may reasonably expect to have to make a software 
change.  RXTX actually handles this situation quite well with the -D 
command line option.  (My experience has generally been that the port 
number depends more on the USB port used than the hardware - so the 
chances are even with a hardware change the port number/name will be the 
same.)

Slightly Off Topic - there is a reason why industrial users will pay a 
premium for continued availability of hardware.  Yes you can mail-order 
a $10 USB converter and it will work, but there's no guarantee that the 
next time you buy the same part number from the same vendor it will be 
the same.  The industrial vendors will charge you $100+ for the same 
item, but it will be the same every time you buy it for the next 5 to 10 
years.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 14:37:19 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 13:37:19 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
Message-ID: <20060622203719.GA22521@freehold.crocodile.org>

Hello again,

And while I'm at it, why don't just say this: give me one good reason to
write 3+ different ways of handling removable devices, one for USB, one for
FireWire, one for serial...

I understand very well that this goes way beyond the scope of RxTx and
CommAPI and will require cooperation between them and javax.usb and whatever
JSR is responsible for FireWire implementation - but the end result is well
worth it. Abstract out and generalize arrival/departure/monitoring/discovery
API, provide protocol specific extensions for each, live happily ever after.

--vt


On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote:
> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote:
> > 
> > Vadim Tkachenko wrote:
> > > A paradigm shift is required, this is what I wanted to say. Serial devices
> > > can be removed and replaced, it's now our turn to learn to deal with it.
> > 
> > The removal if the serial port hardly significantly different from the 
> > removal of the device attached to the serial port.   Different, 
> > slightly, but not a "paradigm shift".
> > 
> > And yes, someone could unplug a USB serial device and plug it into a 
> > different USB port so that it has a different name/number, but they 
> > could do that with the device itself, move it from com1 to com2.
> > 
> > Am I missing something?
> 
> Yes, the fact that they could unplug a device A and plug a device B. With
> the introduction of the concept of removability, the notion of the serial
> port itself is not as important anymore, but the notion of the unique device
> identifier is.
> 
> Consider a situation: long running system (enterprise HVAC, tens of nodes,
> tens of thousands square feet area, hundreds of thousand dollars worth of
> equipment being conditioned, can't shut down), serial/usb device fails, is
> replaced by an identical device with a different serial #.
> 
> A little bit farfetched, but hopefully highlighting the point I'm trying to
> make.
> 
> > Jim
> 
> --vt
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx


From jredman at ergotech.com  Thu Jun 22 15:13:49 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 15:13:49 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>	<20060622191603.GA17487@freehold.crocodile.org>	<449AF278.6000903@ergotech.com>	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
Message-ID: <449B080D.9080208@ergotech.com>


Vadim Tkachenko wrote:
> Hello again,
> 
> And while I'm at it, why don't just say this: give me one good reason to
> write 3+ different ways of handling removable devices, one for USB, one for
> FireWire, one for serial...

You don't, they're all the same "I have lost communication with my 
serial device".

The only thing you could really do is improve error reporting by knowing 
the exact sub-system.  ("Device X which is/was attached to USB port Y is 
no longer functioning, please check the USB ports, the device, the 
cables and anything else you can think of that may be a cause of 
failure.")  That just requires an intelligent description of the port.

> I understand very well that this goes way beyond the scope of RxTx and
> CommAPI and will require cooperation between them and javax.usb and whatever
> JSR is responsible for FireWire implementation - but the end result is well
> worth it. Abstract out and generalize arrival/departure/monitoring/discovery
> API, provide protocol specific extensions for each, live happily ever after.

There's a huge list of pseudo-serial devices each with a different set 
of requirements, Bluetooth, RFC 2217, a host of proprietary systems, 
etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I 
have no clue how you'd implement them in a general/cross platform sense.

You haven't convinced me (and only me, others may see something that I 
don't, I'm not speaking for them) that this mechanism can be implemented 
in any practical sense.  That is, that the implementation could be wide 
enough to be consider generally available in RXTX regardless of the 
serial port implementation, platform, etc..  However, if you can come up 
with a general design and a reference implementation for one subsystem, 
I'd like to see it and might get on board.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 15:40:55 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 14:40:55 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449B080D.9080208@ergotech.com>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
Message-ID: <20060622214055.GA25497@freehold.crocodile.org>

On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote:
> 
> Vadim Tkachenko wrote:
> > Hello again,
> > 
> > And while I'm at it, why don't just say this: give me one good reason to
> > write 3+ different ways of handling removable devices, one for USB, one for
> > FireWire, one for serial...
> 
> You don't, they're all the same "I have lost communication with my 
> serial device".

"I have lost communication with my ${protocol} device".

> The only thing you could really do is improve error reporting by knowing 
> the exact sub-system.  ("Device X which is/was attached to USB port Y is 
> no longer functioning, please check the USB ports, the device, the 
> cables and anything else you can think of that may be a cause of 
> failure.")

"Device ${id} which is/was attached to ${protocol} port ${port} is no longer
functioning, please check the ${protocol} ports, the device, the
${protocol_media} and anything else you can think of that may be a cause of
failure".

>  That just requires an intelligent description of the port.

Agree absolutely.

> > I understand very well that this goes way beyond the scope of RxTx and
> > CommAPI and will require cooperation between them and javax.usb and whatever
> > JSR is responsible for FireWire implementation - but the end result is well
> > worth it. Abstract out and generalize arrival/departure/monitoring/discovery
> > API, provide protocol specific extensions for each, live happily ever after.
> 
> There's a huge list of pseudo-serial devices each with a different set 
> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, 
> etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I 
> have no clue how you'd implement them in a general/cross platform sense.

That's because some of the protocols were created decades ago when
autoconfiguration wasn't even conceived, much less practical. RS232/RS485
don't have a clue about identity discovery, and even capabilities discovery
beyond obvious 8N1 etc.

I agree that today all these protocols have generally incompatible
strategies for handling the situations I'm trying to address, but there's
nothing that says it's not an oversight. Besides, we're dealing with the
devices at a level of abstraction that allows some simplifications and
generalizations, at least part of the time - unless it's the protocol
specific features we're dealing with.

> You haven't convinced me (and only me, others may see something that I 
> don't, I'm not speaking for them) that this mechanism can be implemented 
> in any practical sense.  That is, that the implementation could be wide 
> enough to be consider generally available in RXTX regardless of the 
> serial port implementation, platform, etc..  However, if you can come up 
> with a general design and a reference implementation for one subsystem, 
> I'd like to see it and might get on board.

Actually, I wasn't even thinking about all this stuff when I wrote the first
message on the subject :) Now that you mention it - well, I'm not sure I can
chew the piece I just tried to bite in reasonable amount of time.

How do you eat an elephant? One bite at a time. If we could agree that a
small step in the specification is acceptable at this time, and express
further intentions, things may start happening.

To put it succinctly:

- Concept of a "port" should be augmented with a concept of a "device". A
device may be attached to a port in an implicit or explicit way.
- Implicitly connected device is exactly what the current scope of the
specification covers. No new functionality is offered.
- Explicitly connected device supports detachable device semantics, just as
other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a
few).
- The input and output streams are not properties of a port now, but
properties of the device attached to the port.
- A mechanism to allow listening for device arrivals and departures must be
made available.

That's it, off the top of my head.

I understand that this goes completely against current javax.comm specs, but
an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be
difficult to implement without disrupting javax.comm compatibility.

One concern is how to deal with the device identity - but there's no general
way of dealing with this at this time, devices may or may not offer identity
discovery.

> Jim

--vt


From joachim at buechse.de  Fri Jun 23 02:12:43 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 23 Jun 2006 10:12:43 +0200
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
Message-ID: <CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>

Hello++ Vadim,

I would like to repeat that your request is best addressed to the  
POSSIX standardization group - or maybe the BSD/Linux maintainers. If  
you convince the BSD or Linux guys to add this kind of functionality  
(they can as most of there VCP drivers are open source), there is a  
certain chance that other vendors will pick it up. I assure you that  
RXTX will happily provide this functionality once it's possible - I'm  
sure there is more than one maintainer that would love to add it.  
Having this concept penetrate the market may take some years though.

SHORT: The solution you would like to see could be added to the API  
but it can not be implemented (at least not on the platforms I know).  
There are currently no hooks in the kernel that allow you to discover  
"the device" or even the "means of connection" based on an existing  
"device file descriptor" ie COM-port or /dev/... entry. The name  
mapping of the device is handled by the virtual com port driver of  
the device. Unless you are suggesting RXTX should reimplement virtual  
com port drivers for all usb/serial bridges out there your request is  
understandable from a users viewpoint but simply not realizable. It's  
like asking that the Socket api should identify the computer behind  
an IP address (ie by its Ethernet address). While this COULD be  
implemented in TCP/IP, it IS not, and hence there is no point adding  
such a function to the Socket API.

The current trend for USB/Bluetooth/Irda/etc connected devices is  
going away from serial port abstraction towards RPC (ie the drivers  
provide a device specific or device class specific driver that  
provides an application level api to the device functions). The line  
level protocol is often not even published.

Best regards,
Joachim

On 22.06.2006, at 23:40, Vadim Tkachenko wrote:

> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote:
>>
>> Vadim Tkachenko wrote:
>>> Hello again,
>>>
>>> And while I'm at it, why don't just say this: give me one good  
>>> reason to
>>> write 3+ different ways of handling removable devices, one for  
>>> USB, one for
>>> FireWire, one for serial...
>>
>> You don't, they're all the same "I have lost communication with my
>> serial device".
>
> "I have lost communication with my ${protocol} device".
>
>> The only thing you could really do is improve error reporting by  
>> knowing
>> the exact sub-system.  ("Device X which is/was attached to USB  
>> port Y is
>> no longer functioning, please check the USB ports, the device, the
>> cables and anything else you can think of that may be a cause of
>> failure.")
>
> "Device ${id} which is/was attached to ${protocol} port ${port} is  
> no longer
> functioning, please check the ${protocol} ports, the device, the
> ${protocol_media} and anything else you can think of that may be a  
> cause of
> failure".
>
>>  That just requires an intelligent description of the port.
>
> Agree absolutely.
>
>>> I understand very well that this goes way beyond the scope of  
>>> RxTx and
>>> CommAPI and will require cooperation between them and javax.usb  
>>> and whatever
>>> JSR is responsible for FireWire implementation - but the end  
>>> result is well
>>> worth it. Abstract out and generalize arrival/departure/ 
>>> monitoring/discovery
>>> API, provide protocol specific extensions for each, live happily  
>>> ever after.
>>
>> There's a huge list of pseudo-serial devices each with a different  
>> set
>> of requirements, Bluetooth, RFC 2217, a host of proprietary systems,
>> etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I
>> have no clue how you'd implement them in a general/cross platform  
>> sense.
>
> That's because some of the protocols were created decades ago when
> autoconfiguration wasn't even conceived, much less practical. RS232/ 
> RS485
> don't have a clue about identity discovery, and even capabilities  
> discovery
> beyond obvious 8N1 etc.
>
> I agree that today all these protocols have generally incompatible
> strategies for handling the situations I'm trying to address, but  
> there's
> nothing that says it's not an oversight. Besides, we're dealing  
> with the
> devices at a level of abstraction that allows some simplifications and
> generalizations, at least part of the time - unless it's the protocol
> specific features we're dealing with.
>
>> You haven't convinced me (and only me, others may see something  
>> that I
>> don't, I'm not speaking for them) that this mechanism can be  
>> implemented
>> in any practical sense.  That is, that the implementation could be  
>> wide
>> enough to be consider generally available in RXTX regardless of the
>> serial port implementation, platform, etc..  However, if you can  
>> come up
>> with a general design and a reference implementation for one  
>> subsystem,
>> I'd like to see it and might get on board.
>
> Actually, I wasn't even thinking about all this stuff when I wrote  
> the first
> message on the subject :) Now that you mention it - well, I'm not  
> sure I can
> chew the piece I just tried to bite in reasonable amount of time.
>
> How do you eat an elephant? One bite at a time. If we could agree  
> that a
> small step in the specification is acceptable at this time, and  
> express
> further intentions, things may start happening.
>
> To put it succinctly:
>
> - Concept of a "port" should be augmented with a concept of a  
> "device". A
> device may be attached to a port in an implicit or explicit way.
> - Implicitly connected device is exactly what the current scope of the
> specification covers. No new functionality is offered.
> - Explicitly connected device supports detachable device semantics,  
> just as
> other protocols do (USB, FireWire, Wireless USB, Bluetooth, to  
> mention a
> few).
> - The input and output streams are not properties of a port now, but
> properties of the device attached to the port.
> - A mechanism to allow listening for device arrivals and departures  
> must be
> made available.
>
> That's it, off the top of my head.
>
> I understand that this goes completely against current javax.comm  
> specs, but
> an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern )  
> won't be
> difficult to implement without disrupting javax.comm compatibility.
>
> One concern is how to deal with the device identity - but there's  
> no general
> way of dealing with this at this time, devices may or may not offer  
> identity
> discovery.
>
>> Jim
>
> --vt
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From vt at freehold.crocodile.org  Fri Jun 23 11:28:29 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Fri, 23 Jun 2006 10:28:29 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
	<CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
Message-ID: <20060623172829.GA5335@freehold.crocodile.org>

Hello Joachim,

> I would like to repeat that your request is best addressed to the POSSIX
> standardization group - or maybe the BSD/Linux maintainers. If you
> convince the BSD or Linux guys to add this kind of functionality (they can
> as most of there VCP drivers are open source), there is a certain chance
> that other vendors will pick it up. I assure you that RXTX will happily
> provide this functionality once it's possible - I'm sure there is more
> than one maintainer that would love to add it.

I realize this thing is bigger than RxTx itself, and I'm afraid it's too
global not to cause people to laugh before they think about it :)

> Having this concept penetrate the market may take some years though.

Well, I'm sure it'll get there, the only question is - when.

> SHORT: The solution you would like to see could be added to the API but it
> can not be implemented (at least not on the platforms I know).

I guess I'm concerned about the abstraction more than I'm concerned about
the implementation at this point.
  
> There are currently no hooks in the kernel that allow you to discover  
> "the device" or even the "means of connection" based on an existing  
> "device file descriptor" ie COM-port or /dev/... entry.

Well, I'm not so sure you need to keep the literal mapping from /dev
namespace to your device namespace. As long as you can consistently offer a
virtual serial device on top of a virtual serial port, it may be irrelevant
whether you can map it into /dev. The mapping is going be schitzofrenic
anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the
representation...

> The name mapping of the device is handled by the virtual com port driver
> of the device. Unless you are suggesting RXTX should reimplement virtual
> com port drivers for all usb/serial bridges out there your request is
> understandable from a users viewpoint but simply not realizable.

It's not so much a request but rather an offer of participation. I run a few
projects actively using serial communications, as well as USB device
drivers, in different degrees of readiness (Servomaster, Haywire, DIY
Zoning) - and it would be a perfect playground.

You mentioned above that this task is about two things: a) abstraction b)
implementation. I could start the abstraction part of it without changing
the current CommAPI, on top of it, as an adapter. Even if the removable
device semantics are not implemented, but offered, this is already a step
forward.

> It's like asking that the Socket api should identify the computer behind
> an IP address (ie by its Ethernet address). While this COULD be
> implemented in TCP/IP, it IS not, and hence there is no point adding such
> a function to the Socket API.

Thank you for bringing up this example - I guess this is just about the same
thing that I'd like to see. Socket transparently provides you with the
input/output streams, at the same time offering protocol level specifics to
you.

> The current trend for USB/Bluetooth/Irda/etc connected devices is going
> away from serial port abstraction towards RPC (ie the drivers provide a
> device specific or device class specific driver that provides an
> application level api to the device functions). The line level protocol is
> often not even published.

I can't say I'm that happy with it. The best (or, rather, worst) example is
suchlike support for the Phidget servo controller - zealous Linux developers
implemented kernel module support for it, completely hijacking a possibility
of using it on a different level (it's somewhat fixed by now, thankfully).

I believe that whenever an abstraction is offered, it must be made optional
and/or pluggable so it can be replaced by something more suited to the task.

The nature of Java applications is such that they'd probably care much more
about Java API offered, than about no matter how rich application level api
that is offered outside of Java. I've dealt with JNI adapters in the past,
and whereas they can be made reasonably stable, the very fact that you are
forced to deal with things that are not on the critical timing/memory path
and could've been done much easier in Java causes endless grief.

> Joachim

--vt


From lyon at docjava.com  Sat Jun 24 04:54:12 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Sat, 24 Jun 2006 06:54:12 -0400
Subject: [Rxtx] jsr
In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
	<CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
	<20060623172829.GA5335@freehold.crocodile.org>
Message-ID: <p060204a3c0c2c9dde4f8@[192.168.1.152]>

Hi All,
I have had some off-list discussion with Trent.
Opening up a JSR with Sun, as per Peters' suggestion
seems like a reasonable idea, to us.

Does anyone having any concerns about the JSR process
that they would like to raise?

Thanks!
  - Doug



From the.grey.lantern at gmail.com  Sat Jun 24 18:15:26 2006
From: the.grey.lantern at gmail.com (Craig Nicoll)
Date: Sun, 25 Jun 2006 01:15:26 +0100
Subject: [Rxtx] Cannot create virtual serial port
Message-ID: <a1221cc50606241715g2d1e2af6r747347dd4c20e997@mail.gmail.com>

Hello,

This is my first post on this mailing list and I hope someone can help me.

I am having great difficult establishing a virtual serial port for the
Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia
7600.

Every time I try to run the SendMessage program that comes with SMSLib, I
get the following exception: gnu.io.NoSuchPortException

The port names I have tried are:
rfcomm0
rfcomm
/dev/rfcomm0
/dev/rfcomm

This is what I have done so far:
Modified /etc/bluetooth/rfcomm.conf to include the address of my phone:

rfcomm0 {
# Automatically bind the device at startup
bind no;

# Bluetooth address of the device
device 00:0e:6d:7a:98:43;

# RFCOMM channel for the connection
channel 1;

# Description of the connection
comment "Example Bluetooth device";
}

I also tried running the following command: rfcomm bind /dev/rfcomm0

I have searched the mailing list archives and found this post where someone
had a very similar problem to me:
http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried
changing the system properties as suggested and it made no difference.

I have also been scouring Google all day to no avail.

I would be incredibly grateful if anyone could give me some tips.

Thank you,

Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060625/cfa6df35/attachment-0013.html

From tjarvi at qbang.org  Sun Jun 25 19:56:08 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT)
Subject: [Rxtx] Pending release
Message-ID: <Pine.LNX.4.61.0606251942460.15744@www>


With frustration, I was unable to get to the pending release this weekend.
The release should be comming this next week once things calm down.
The source is in CVS except for a fix for multiple ports in windows.

I had planned on doing the release this weekend but that was disrupted by 
my transportation failing in a spectacular fashion.

--
Trent Jarvi
tjarvi at qbang.org


From Pawan.Kharbanda at dot.state.co.us  Tue Jun 27 22:28:51 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 27 Jun 2006 22:28:51 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>

 Trent, 
   I have an application running in a cluster in linux environment and I
am using RXTX2.1.7 (final) with JDK1.5. The application opens and closes
serial comm ports every 30 seconds and exchanges datas. I have
experienced some of my Comm Ports are left hanging (I can see the
LCK..cufXX lock files under /var/lock folder). On putting the debugs I
found out that, it is stuck at a native call line 809 in RXTXPort.java
class (Please see the code snippet below). Can you help me explain what
this method does in the native code? Am I getting into some thread
deadlocks? Thanks in advance.

Pawan Kharbanda 


public void removeEventListener()
	{
		if (debug)
			z.reportln( "RXTXPort:removeEventListener()
called");
		waitForTheNativeCodeSilly();
		//if( monThread != null && monThread.isAlive() )
		if( monThreadisInterrupted == true )
		{
			z.reportln( "	RXTXPort:removeEventListener()
already interrupted");
			monThread = null;
			SPEventListener = null;
			return;
		}
		else if( monThread != null && monThread.isAlive() )
		{
			if (debug)
				z.reportln( "
RXTXPort:Interrupt=true");
			monThreadisInterrupted=true;
			/*
			   Notify all threads in this PID that something
is up
			   They will call back to see if its their
thread
			   using isInterrupted().
			*/
			if (debug)
				z.reportln( "	RXTXPort:calling
interruptEventLoop");
// LINE 809			interruptEventLoop( ); It never returns
out of this 
			
			if (debug)
				z.reportln( "	RXTXPort:calling
monThread.join()");
			try {
				monThread.join(1000);
			} catch (Exception ex) {
				/* yikes */
				ex.printStackTrace();
			}
			if (debug)
				z.reportln( "	RXTXPort:waiting on
isAlive()");
			while( monThread.isAlive() )
			{
				if ( debug )
					z.reportln( "	MonThread is
still alive!");
				try {
					monThread.join(1000);
					Thread.sleep( 1000 );
				} catch( Exception e ){} 
				//monThread.stop();
			}
			
		}
		if (debug)
			z.reportln( "	RXTXPort:calling gc()");
		monThread = null;
		SPEventListener = null;
		MonitorThreadLock = false;
		MonitorThreadAlive=false;
		monThreadisInterrupted=true;
		z.reportln( "RXTXPort:removeEventListener() returning");
	} 

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Sunday, June 25, 2006 7:56 PM
To: rxtx at qbang.org
Subject: [Rxtx] Pending release


With frustration, I was unable to get to the pending release this
weekend.
The release should be comming this next week once things calm down.
The source is in CVS except for a fix for multiple ports in windows.

I had planned on doing the release this weekend but that was disrupted
by my transportation failing in a spectacular fashion.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Wed Jun 28 04:17:29 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 28 Jun 2006 04:17:29 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606280406330.9561@www>



Hi Pawan

You may have found a deadlock but I've not seen on recently on linux.

If you can, please update from CVS.  This will have some close fixes. 
I'm running with the same code as is in CVS.  It is not perfect but I've 
not seen anything like you mention.  Be sure to set timeouts and 
thresholds on the port.  It may be that the port is waiting on pending io 
that never happens.  I think the CVS patches deal with this also but it 
looks like your in a better test environment to know for sure.

The exploded vehicle mentioned below is expected to be fixed today.  It 
was just a ninja small radiator hose.  The pressure test afterwards 
created its own set of problems.  Until this is resolved, I'm spending 
most of my free time commuting by bicycle.

On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>   I have an application running in a cluster in linux environment and I
> am using RXTX2.1.7 (final) with JDK1.5. The application opens and closes
> serial comm ports every 30 seconds and exchanges datas. I have
> experienced some of my Comm Ports are left hanging (I can see the
> LCK..cufXX lock files under /var/lock folder). On putting the debugs I
> found out that, it is stuck at a native call line 809 in RXTXPort.java
> class (Please see the code snippet below). Can you help me explain what
> this method does in the native code? Am I getting into some thread
> deadlocks? Thanks in advance.
>
> Pawan Kharbanda
>
>
> public void removeEventListener()
> 	{
> 		if (debug)
> 			z.reportln( "RXTXPort:removeEventListener()
> called");
> 		waitForTheNativeCodeSilly();
> 		//if( monThread != null && monThread.isAlive() )
> 		if( monThreadisInterrupted == true )
> 		{
> 			z.reportln( "	RXTXPort:removeEventListener()
> already interrupted");
> 			monThread = null;
> 			SPEventListener = null;
> 			return;
> 		}
> 		else if( monThread != null && monThread.isAlive() )
> 		{
> 			if (debug)
> 				z.reportln( "
> RXTXPort:Interrupt=true");
> 			monThreadisInterrupted=true;
> 			/*
> 			   Notify all threads in this PID that something
> is up
> 			   They will call back to see if its their
> thread
> 			   using isInterrupted().
> 			*/
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> interruptEventLoop");
> // LINE 809			interruptEventLoop( ); It never returns
> out of this
>
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> monThread.join()");
> 			try {
> 				monThread.join(1000);
> 			} catch (Exception ex) {
> 				/* yikes */
> 				ex.printStackTrace();
> 			}
> 			if (debug)
> 				z.reportln( "	RXTXPort:waiting on
> isAlive()");
> 			while( monThread.isAlive() )
> 			{
> 				if ( debug )
> 					z.reportln( "	MonThread is
> still alive!");
> 				try {
> 					monThread.join(1000);
> 					Thread.sleep( 1000 );
> 				} catch( Exception e ){}
> 				//monThread.stop();
> 			}
>
> 		}
> 		if (debug)
> 			z.reportln( "	RXTXPort:calling gc()");
> 		monThread = null;
> 		SPEventListener = null;
> 		MonitorThreadLock = false;
> 		MonitorThreadAlive=false;
> 		monThreadisInterrupted=true;
> 		z.reportln( "RXTXPort:removeEventListener() returning");
> 	}
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Sunday, June 25, 2006 7:56 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] Pending release
>
>
> With frustration, I was unable to get to the pending release this
> weekend.
> The release should be comming this next week once things calm down.
> The source is in CVS except for a fix for multiple ports in windows.
>
> I had planned on doing the release this weekend but that was disrupted
> by my transportation failing in a spectacular fashion.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From Pawan.Kharbanda at dot.state.co.us  Wed Jun 28 12:11:06 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Wed, 28 Jun 2006 12:11:06 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>

Trent,
    Again thanks for the reply. First of all I have Receive timeouts set
on all communications including Max no of bytes to expect during the
call. I have noticed the problem is during "closing the connection". I
am not sure if the RXTX is 100% thread-safe yet. There seems to be a
glitch in the native calls. I am sure I have the latest code I did the
update on the Version 2.1.7 from CVS, is this where the latest updates
are located, I have noticed another version in CVS "rxtx-devel".

Regards
Pawan Kharbanda

    

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Wednesday, June 28, 2006 4:17 AM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports



Hi Pawan

You may have found a deadlock but I've not seen on recently on linux.

If you can, please update from CVS.  This will have some close fixes. 
I'm running with the same code as is in CVS.  It is not perfect but I've
not seen anything like you mention.  Be sure to set timeouts and
thresholds on the port.  It may be that the port is waiting on pending
io that never happens.  I think the CVS patches deal with this also but
it looks like your in a better test environment to know for sure.

The exploded vehicle mentioned below is expected to be fixed today.  It
was just a ninja small radiator hose.  The pressure test afterwards
created its own set of problems.  Until this is resolved, I'm spending
most of my free time commuting by bicycle.

On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>   I have an application running in a cluster in linux environment and 
> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and 
> closes serial comm ports every 30 seconds and exchanges datas. I have 
> experienced some of my Comm Ports are left hanging (I can see the 
> LCK..cufXX lock files under /var/lock folder). On putting the debugs I

> found out that, it is stuck at a native call line 809 in RXTXPort.java

> class (Please see the code snippet below). Can you help me explain 
> what this method does in the native code? Am I getting into some 
> thread deadlocks? Thanks in advance.
>
> Pawan Kharbanda
>
>
> public void removeEventListener()
> 	{
> 		if (debug)
> 			z.reportln( "RXTXPort:removeEventListener()
called");
> 		waitForTheNativeCodeSilly();
> 		//if( monThread != null && monThread.isAlive() )
> 		if( monThreadisInterrupted == true )
> 		{
> 			z.reportln( "	RXTXPort:removeEventListener()
> already interrupted");
> 			monThread = null;
> 			SPEventListener = null;
> 			return;
> 		}
> 		else if( monThread != null && monThread.isAlive() )
> 		{
> 			if (debug)
> 				z.reportln( "
> RXTXPort:Interrupt=true");
> 			monThreadisInterrupted=true;
> 			/*
> 			   Notify all threads in this PID that something
is up
> 			   They will call back to see if its their
thread
> 			   using isInterrupted().
> 			*/
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> interruptEventLoop");
> // LINE 809			interruptEventLoop( ); It never returns
> out of this
>
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> monThread.join()");
> 			try {
> 				monThread.join(1000);
> 			} catch (Exception ex) {
> 				/* yikes */
> 				ex.printStackTrace();
> 			}
> 			if (debug)
> 				z.reportln( "	RXTXPort:waiting on
> isAlive()");
> 			while( monThread.isAlive() )
> 			{
> 				if ( debug )
> 					z.reportln( "	MonThread is
> still alive!");
> 				try {
> 					monThread.join(1000);
> 					Thread.sleep( 1000 );
> 				} catch( Exception e ){}
> 				//monThread.stop();
> 			}
>
> 		}
> 		if (debug)
> 			z.reportln( "	RXTXPort:calling gc()");
> 		monThread = null;
> 		SPEventListener = null;
> 		MonitorThreadLock = false;
> 		MonitorThreadAlive=false;
> 		monThreadisInterrupted=true;
> 		z.reportln( "RXTXPort:removeEventListener() returning");
> 	}
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf

> Of Trent Jarvi
> Sent: Sunday, June 25, 2006 7:56 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] Pending release
>
>
> With frustration, I was unable to get to the pending release this 
> weekend.
> The release should be comming this next week once things calm down.
> The source is in CVS except for a fix for multiple ports in windows.
>
> I had planned on doing the release this weekend but that was disrupted

> by my transportation failing in a spectacular fashion.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Wed Jun 28 12:26:21 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 28 Jun 2006 12:26:21 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606281222420.9561@www>


Hi Pawan

If you did a cvs update from the 2.1-7 tar ball, you have the current 
version.  All rxtx in CVS is under rxtx-devel.  The 2.1-7 just has -r
commapi-0-0-1.

You may well have found something.  I have seen win32 fail on closing 
ports but not linux that I can think of.  Your use is much different than 
I normally see too.

Could you give us more information on how we would reproduce this and the 
frequency?


On Wed, 28 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>    Again thanks for the reply. First of all I have Receive timeouts set
> on all communications including Max no of bytes to expect during the
> call. I have noticed the problem is during "closing the connection". I
> am not sure if the RXTX is 100% thread-safe yet. There seems to be a
> glitch in the native calls. I am sure I have the latest code I did the
> update on the Version 2.1.7 from CVS, is this where the latest updates
> are located, I have noticed another version in CVS "rxtx-devel".
>
> Regards
> Pawan Kharbanda
>
>
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Wednesday, June 28, 2006 4:17 AM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] Locked Ports
>
>
>
> Hi Pawan
>
> You may have found a deadlock but I've not seen on recently on linux.
>
> If you can, please update from CVS.  This will have some close fixes.
> I'm running with the same code as is in CVS.  It is not perfect but I've
> not seen anything like you mention.  Be sure to set timeouts and
> thresholds on the port.  It may be that the port is waiting on pending
> io that never happens.  I think the CVS patches deal with this also but
> it looks like your in a better test environment to know for sure.
>
> The exploded vehicle mentioned below is expected to be fixed today.  It
> was just a ninja small radiator hose.  The pressure test afterwards
> created its own set of problems.  Until this is resolved, I'm spending
> most of my free time commuting by bicycle.
>
> On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:
>
>> Trent,
>>   I have an application running in a cluster in linux environment and
>> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and
>> closes serial comm ports every 30 seconds and exchanges datas. I have
>> experienced some of my Comm Ports are left hanging (I can see the
>> LCK..cufXX lock files under /var/lock folder). On putting the debugs I
>
>> found out that, it is stuck at a native call line 809 in RXTXPort.java
>
>> class (Please see the code snippet below). Can you help me explain
>> what this method does in the native code? Am I getting into some
>> thread deadlocks? Thanks in advance.
>>
>> Pawan Kharbanda
>>
>>
>> public void removeEventListener()
>> 	{
>> 		if (debug)
>> 			z.reportln( "RXTXPort:removeEventListener()
> called");
>> 		waitForTheNativeCodeSilly();
>> 		//if( monThread != null && monThread.isAlive() )
>> 		if( monThreadisInterrupted == true )
>> 		{
>> 			z.reportln( "	RXTXPort:removeEventListener()
>> already interrupted");
>> 			monThread = null;
>> 			SPEventListener = null;
>> 			return;
>> 		}
>> 		else if( monThread != null && monThread.isAlive() )
>> 		{
>> 			if (debug)
>> 				z.reportln( "
>> RXTXPort:Interrupt=true");
>> 			monThreadisInterrupted=true;
>> 			/*
>> 			   Notify all threads in this PID that something
> is up
>> 			   They will call back to see if its their
> thread
>> 			   using isInterrupted().
>> 			*/
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> interruptEventLoop");
>> // LINE 809			interruptEventLoop( ); It never returns
>> out of this
>>
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> monThread.join()");
>> 			try {
>> 				monThread.join(1000);
>> 			} catch (Exception ex) {
>> 				/* yikes */
>> 				ex.printStackTrace();
>> 			}
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:waiting on
>> isAlive()");
>> 			while( monThread.isAlive() )
>> 			{
>> 				if ( debug )
>> 					z.reportln( "	MonThread is
>> still alive!");
>> 				try {
>> 					monThread.join(1000);
>> 					Thread.sleep( 1000 );
>> 				} catch( Exception e ){}
>> 				//monThread.stop();
>> 			}
>>
>> 		}
>> 		if (debug)
>> 			z.reportln( "	RXTXPort:calling gc()");
>> 		monThread = null;
>> 		SPEventListener = null;
>> 		MonitorThreadLock = false;
>> 		MonitorThreadAlive=false;
>> 		monThreadisInterrupted=true;
>> 		z.reportln( "RXTXPort:removeEventListener() returning");
>> 	}
>>
>> -----Original Message-----
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
>
>> Of Trent Jarvi
>> Sent: Sunday, June 25, 2006 7:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] Pending release
>>
>>
>> With frustration, I was unable to get to the pending release this
>> weekend.
>> The release should be comming this next week once things calm down.
>> The source is in CVS except for a fix for multiple ports in windows.
>>
>> I had planned on doing the release this weekend but that was disrupted
>
>> by my transportation failing in a spectacular fashion.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From Pawan.Kharbanda at dot.state.co.us  Wed Jun 28 15:42:49 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Wed, 28 Jun 2006 15:42:49 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>

Trent,
    I will try to explain how I am setup and will try to write you a
Sample code little later to reproduce this. On our system we have
DigiBoxes installed on the 2 Linux servers. Both of them have RXTX2.1-7
version installed with the JRE(1.5) and both the machines have the same
port mappings in gnu.io.rxtx.properties (Currently in the production
system I have 64 ports). This is how the system works:

1) A thick Map based client initiates a Action on the Device on the
field. One of the Thread Workers(Asynchronous Call) in the Cluster picks
up the request. 
2) Once the worker gets the request it locks the Device and
Communication port in the DB's(These are our persistent locks, because
most of the devices do one to one communication with the serial ports).
After that the worker (or Comm Server) opens up the connection and after
exchanging the information calls the "Close" and returns.
3) Once the connection is closed , the DB lock is removed on the comm
port and is made available to accept future calls. Here is where the
glitch is the Serial Comm Close method never returns due to the
deadlock. 

I have noticed that the deadlocks are very inconsistent, sometime it
happens right away as soon as Application server starts and sometimes I
don't see any deadlocks for days, but it happens for sure. 

Here is how you can test if you have resources/ test environment. Write
a program and try to open/close  different ports(I will say have a
minimum of four) randomly and very frequently(may be 30 seconds), I am
pretty sure you will see the deadlocks and it happens in the native call
to interrptEventLoop in RXTXPort.java in removeEventListener() method
call.

Also I have noticed that the JVM carshes (without any memrory errors or
JVM errors. Its just not there) when native call is made to eventLoop()
in run() method in MonitorThread inner class. I am still investigating
why this is happening, but at this point I can just tell you the
location. You might have a question How I am so sure about the location?
My application is configured with Log4J and I have enabled the debugs on
the RXTXPort.java, so every time my JVM dies I see these logs at the end
of the file.

"2006-06-28 15:27:15,183 INFO  [STDOUT] RXTXPort:RXTXPort(/dev/cub01)
called
2006-06-28 15:27:15,218 INFO  [STDOUT]
RXTXPort:MontitorThread:MonitorThread()
2006-06-28 15:27:15,219 INFO  [STDOUT] RXTXPort:MontitorThread:run()"

I surely do have a luxury of a testing environment(ports, devices etc.)
and can help you fix these problems? Please advise me how we can resolve
these issues.

Thanks 
Pawan Kharbanda
303-478-2991





-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Wednesday, June 28, 2006 12:26 PM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports


Hi Pawan

If you did a cvs update from the 2.1-7 tar ball, you have the current
version.  All rxtx in CVS is under rxtx-devel.  The 2.1-7 just has -r
commapi-0-0-1.

You may well have found something.  I have seen win32 fail on closing
ports but not linux that I can think of.  Your use is much different
than I normally see too.

Could you give us more information on how we would reproduce this and
the frequency?


On Wed, 28 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>    Again thanks for the reply. First of all I have Receive timeouts
set
> on all communications including Max no of bytes to expect during the
> call. I have noticed the problem is during "closing the connection". I
> am not sure if the RXTX is 100% thread-safe yet. There seems to be a
> glitch in the native calls. I am sure I have the latest code I did the
> update on the Version 2.1.7 from CVS, is this where the latest updates
> are located, I have noticed another version in CVS "rxtx-devel".
>
> Regards
> Pawan Kharbanda
>
>
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Wednesday, June 28, 2006 4:17 AM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] Locked Ports
>
>
>
> Hi Pawan
>
> You may have found a deadlock but I've not seen on recently on linux.
>
> If you can, please update from CVS.  This will have some close fixes.
> I'm running with the same code as is in CVS.  It is not perfect but
I've
> not seen anything like you mention.  Be sure to set timeouts and
> thresholds on the port.  It may be that the port is waiting on pending
> io that never happens.  I think the CVS patches deal with this also
but
> it looks like your in a better test environment to know for sure.
>
> The exploded vehicle mentioned below is expected to be fixed today.
It
> was just a ninja small radiator hose.  The pressure test afterwards
> created its own set of problems.  Until this is resolved, I'm spending
> most of my free time commuting by bicycle.
>
> On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:
>
>> Trent,
>>   I have an application running in a cluster in linux environment and
>> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and
>> closes serial comm ports every 30 seconds and exchanges datas. I have
>> experienced some of my Comm Ports are left hanging (I can see the
>> LCK..cufXX lock files under /var/lock folder). On putting the debugs
I
>
>> found out that, it is stuck at a native call line 809 in
RXTXPort.java
>
>> class (Please see the code snippet below). Can you help me explain
>> what this method does in the native code? Am I getting into some
>> thread deadlocks? Thanks in advance.
>>
>> Pawan Kharbanda
>>
>>
>> public void removeEventListener()
>> 	{
>> 		if (debug)
>> 			z.reportln( "RXTXPort:removeEventListener()
> called");
>> 		waitForTheNativeCodeSilly();
>> 		//if( monThread != null && monThread.isAlive() )
>> 		if( monThreadisInterrupted == true )
>> 		{
>> 			z.reportln( "	RXTXPort:removeEventListener()
>> already interrupted");
>> 			monThread = null;
>> 			SPEventListener = null;
>> 			return;
>> 		}
>> 		else if( monThread != null && monThread.isAlive() )
>> 		{
>> 			if (debug)
>> 				z.reportln( "
>> RXTXPort:Interrupt=true");
>> 			monThreadisInterrupted=true;
>> 			/*
>> 			   Notify all threads in this PID that something
> is up
>> 			   They will call back to see if its their
> thread
>> 			   using isInterrupted().
>> 			*/
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> interruptEventLoop");
>> // LINE 809			interruptEventLoop( ); It never returns
>> out of this
>>
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> monThread.join()");
>> 			try {
>> 				monThread.join(1000);
>> 			} catch (Exception ex) {
>> 				/* yikes */
>> 				ex.printStackTrace();
>> 			}
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:waiting on
>> isAlive()");
>> 			while( monThread.isAlive() )
>> 			{
>> 				if ( debug )
>> 					z.reportln( "	MonThread is
>> still alive!");
>> 				try {
>> 					monThread.join(1000);
>> 					Thread.sleep( 1000 );
>> 				} catch( Exception e ){}
>> 				//monThread.stop();
>> 			}
>>
>> 		}
>> 		if (debug)
>> 			z.reportln( "	RXTXPort:calling gc()");
>> 		monThread = null;
>> 		SPEventListener = null;
>> 		MonitorThreadLock = false;
>> 		MonitorThreadAlive=false;
>> 		monThreadisInterrupted=true;
>> 		z.reportln( "RXTXPort:removeEventListener() returning");
>> 	}
>>
>> -----Original Message-----
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On
Behalf
>
>> Of Trent Jarvi
>> Sent: Sunday, June 25, 2006 7:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] Pending release
>>
>>
>> With frustration, I was unable to get to the pending release this
>> weekend.
>> The release should be comming this next week once things calm down.
>> The source is in CVS except for a fix for multiple ports in windows.
>>
>> I had planned on doing the release this weekend but that was
disrupted
>
>> by my transportation failing in a spectacular fashion.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx 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 khattar31 at yahoo.com  Wed Jun 28 22:04:59 2006
From: khattar31 at yahoo.com (rahul khattar)
Date: Wed, 28 Jun 2006 21:04:59 -0700 (PDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
Message-ID: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>

Hi All,

I was looking at the src file on the last release.
I did notice a missing header file while trying to
compile the parallelport.dll. Would somebody be kind
enoughf to share the missing header file:
gnu_io_LPRPort.h

I am using MinGw to compile the same from Parinya
(which is an execellent tool)


Regards,
Rahul Khattar

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Thu Jun 29 03:43:53 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 03:43:53 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>
References: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606290341210.9561@www>

On Wed, 28 Jun 2006, rahul khattar wrote:

> Hi All,
>
> I was looking at the src file on the last release.
> I did notice a missing header file while trying to
> compile the parallelport.dll. Would somebody be kind
> enoughf to share the missing header file:
> gnu_io_LPRPort.h
>
> I am using MinGw to compile the same from Parinya
> (which is an execellent tool)
>

Hi Rahul

The gnu.io_LPRPort.h file is generated with javah.  You can see the 
command in the Makefile I presume.  You do not need rxtxParallel.dll to 
use w32 serial btw.

--
Trent Jarvi
tjarvi at qbang.org


From khattar31 at yahoo.com  Thu Jun 29 04:47:01 2006
From: khattar31 at yahoo.com (rahul khattar)
Date: Thu, 29 Jun 2006 03:47:01 -0700 (PDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606290341210.9561@www>
Message-ID: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>

Hi Trent 
I did notice this file is required in the source file
ParallelImp.c
on line 38

Attached the O/P 

Regards,
Rahul Khattar




--- Trent Jarvi <tjarvi at qbang.org> wrote:

> On Wed, 28 Jun 2006, rahul khattar wrote:
> 
> > Hi All,
> >
> > I was looking at the src file on the last release.
> > I did notice a missing header file while trying to
> > compile the parallelport.dll. Would somebody be
> kind
> > enoughf to share the missing header file:
> > gnu_io_LPRPort.h
> >
> > I am using MinGw to compile the same from Parinya
> > (which is an execellent tool)
> >
> 
> Hi Rahul
> 
> The gnu.io_LPRPort.h file is generated with javah. 
> You can see the 
> command in the Makefile I presume.  You do not need
> rxtxParallel.dll to 
> use w32 serial btw.
> 
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Error.zip
Type: application/x-zip-compressed
Size: 1746 bytes
Desc: 2948039066-Error.zip
Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060629/a5b6f783/Error-0022.bin

From tjarvi at qbang.org  Thu Jun 29 06:16:24 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 06:16:24 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606290614530.9561@www>

On Thu, 29 Jun 2006, rahul khattar wrote:

> Hi Trent
> I did notice this file is required in the source file
> ParallelImp.c
> on line 38
>
> Attached the O/P
>

The command to generate the .h file will be something like:

javah -classpath . -jni gnu.io.LPRPort

The makefile should have this.  There are several approaches to creating 
or using makefiles so I have no idea which one you used if any.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Thu Jun 29 06:20:51 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 06:20:51 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606290616420.9561@www>

> Here is how you can test if you have resources/ test environment. Write
> a program and try to open/close  different ports(I will say have a
> minimum of four) randomly and very frequently(may be 30 seconds), I am
> pretty sure you will see the deadlocks and it happens in the native call
> to interrptEventLoop in RXTXPort.java in removeEventListener() method
> call.

Hi Pawan

I'll try to find a way to reproduce this.  One thing to note is that you 
are using different kernel drivers (digi) to perform this task.  So I 
probably will not be able to reproduce the exact same environment.

In general, multiport kernel drivers have been tested far less than 
typical serial drivers.  This may or may not be an issue.

--
Trent Jarvi
tjarvi at qbang.org



From jhaysonn at gmail.com  Thu Jun 29 12:29:13 2006
From: jhaysonn at gmail.com (jhaysonn pathak)
Date: Thu, 29 Jun 2006 14:29:13 -0400
Subject: [Rxtx] RXTX install
Message-ID: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>

Hi Guys,

I'm doing trying to write a generative piece of Sonic Art using an EEG
plugged into a mac runnning Max/MSP.  I just recently discovered RXTX
drivers in my search for a piece of software that might give me more
output options for my EEG (I'm using the CEO from MindPeak).  I found
Bioera which uses RXTX drivers.  Thing is - I can't figure out how to
install RXTX correctly.

After I build the 'libSerial.jnilib' target inside of
'LibSerial.pbproj' I can't find the libSerial.jnilib file that
accompanies the RXTXcomm.jar nor do I know where to put them.

I also don't understand this part at the bottom of the OS X instructions at all:

"AFTER INSTALLATION VERY IMPORTANT
	check existence of the folder /var/spool/uucp
	if you don't have it create it with command
	sudo mkdir /var/spool/uucp
	permissions should be: drwxrwxr-x
	if they are not do command
	sudo chmod 775 /var/spool/uucp

	YOU should be a member of the uucp group
	you can check it with command
		niutil -readprop / /groups/uucp users
	you should see your name in output of the niutil command
	if you don't do following:
		sudo niutil -appendprop / /groups/uucp users <yourname>
			substitute  <yourname> with your user's name
			for example if your user name is peter:
				sudo niutil -appendprop / /groups/uucp users peter

	NOTES: RXTX.pkg should create uucp folder and insert your name  in
uucp group automatically"



I really appreciate any help that you guys can offer.  I've been
struggling with this for a while now as part of a research grant that
I was awarded.  Thanks again for the help.

Jhaysonn Pathak


From naranjo.manuel at gmail.com  Thu Jun 29 07:19:15 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 10:19:15 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606290614530.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www>
Message-ID: <44A3D353.6010605@gmail.com>

Speaking about Windows Support, I had seen that inside the 
rxtx-2.1-7-bins-r2 package inside Windows directory it says:
"i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will 
not make harm to anyone, and i'm almost sure that someone has noticed it 
before.
Cheers,
Manuel


From joachim at buechse.de  Thu Jun 29 13:25:16 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 29 Jun 2006 21:25:16 +0200
Subject: [Rxtx] RXTX install
In-Reply-To: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>
References: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>
Message-ID: <2A003E42-97E1-4237-8438-646BDE2E3961@buechse.de>

Hello Jhaysonn,

I assume you are trying to use the javax.comm version of RXTX.

Please use "cvs up" to update your download to the latest version of  
the repository. The latest version does not use lock files, so the  
mentioned process is no longer needed. Updating with CVS will also  
provide you with a new README.OSX file that should be simpler to  
understand.

You will find LibSerialUniversal.xcodeproj in MACOSX_IDE/Xcode. Put  
comm.jar (downloaded from Sun) into MACOSX_IDE/Xcode. Compile the  
library. You will find RXTXcomm.jar and librxtxSerial.jnilib in  
MACOSX_IDE/Xcode/build/Default

Best regards,
Joachim
---
Joachim B?chse
Softwarel?sungen und Beratung
Hadlaubsteig 2
CH-8006 Z?rich


On 29.06.2006, at 20:29, jhaysonn pathak wrote:

> Hi Guys,
>
> I'm doing trying to write a generative piece of Sonic Art using an EEG
> plugged into a mac runnning Max/MSP.  I just recently discovered RXTX
> drivers in my search for a piece of software that might give me more
> output options for my EEG (I'm using the CEO from MindPeak).  I found
> Bioera which uses RXTX drivers.  Thing is - I can't figure out how to
> install RXTX correctly.
>
> After I build the 'libSerial.jnilib' target inside of
> 'LibSerial.pbproj' I can't find the libSerial.jnilib file that
> accompanies the RXTXcomm.jar nor do I know where to put them.
>
> I also don't understand this part at the bottom of the OS X  
> instructions at all:
>
> "AFTER INSTALLATION VERY IMPORTANT
> 	check existence of the folder /var/spool/uucp
> 	if you don't have it create it with command
> 	sudo mkdir /var/spool/uucp
> 	permissions should be: drwxrwxr-x
> 	if they are not do command
> 	sudo chmod 775 /var/spool/uucp
>
> 	YOU should be a member of the uucp group
> 	you can check it with command
> 		niutil -readprop / /groups/uucp users
> 	you should see your name in output of the niutil command
> 	if you don't do following:
> 		sudo niutil -appendprop / /groups/uucp users <yourname>
> 			substitute  <yourname> with your user's name
> 			for example if your user name is peter:
> 				sudo niutil -appendprop / /groups/uucp users peter
>
> 	NOTES: RXTX.pkg should create uucp folder and insert your name  in
> uucp group automatically"
>
>
>
> I really appreciate any help that you guys can offer.  I've been
> struggling with this for a while now as part of a research grant that
> I was awarded.  Thanks again for the help.
>
> Jhaysonn Pathak
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From tjarvi at qbang.org  Thu Jun 29 19:30:00 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 19:30:00 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A3D353.6010605@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
Message-ID: <Pine.LNX.4.61.0606291923000.9561@www>

On Thu, 29 Jun 2006, Manuel Naranjo wrote:

> Speaking about Windows Support, I had seen that inside the
> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
> not make harm to anyone, and i'm almost sure that someone has noticed it
> before.

Hi Manuel

         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
     47421  01-30-06 00:23 
rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
     77759  03-01-06 12:01 
rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README


It looks normal to me.  There are no fancy tools used there :)

--
Trent Jarvi
tjarvi at qbang.org

From naranjo.manuel at gmail.com  Thu Jun 29 19:38:16 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 22:38:16 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606291923000.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com> <Pine.LNX.4.61.0606291923000.9561@www>
Message-ID: <44A48088.2040407@gmail.com>

> On Thu, 29 Jun 2006, Manuel Naranjo wrote:
> 
>> Speaking about Windows Support, I had seen that inside the
>> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
>> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
>> not make harm to anyone, and i'm almost sure that someone has noticed it
>> before.
> 
> Hi Manuel
> 
>         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
>         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
>     47421  01-30-06 00:23 
> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
>     77759  03-01-06 12:01 
> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
>       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README
> 
> 
> It looks normal to me.  There are no fancy tools used there :)
> 
Hi Trent:
Is not the i368 representing the name of the Architecture?? If so the 
name should start with i386 it will not break any system, is simply miss
written, I saw that and wanted to report it. It a silly thing.
Ohh I forgoten I must congratulate you for your GREAT libray, I was able 
to make an .exe with JSmooth that launches an application that uses RXTX 
with out the need to install RXTX on users system :). The .exe tells JVM 
where to find the RXTX Library and Binaries. I tried with Sun's Java 
Comm but it was imposible.
Regards,
Manuel


From tjarvi at qbang.org  Thu Jun 29 19:52:45 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 19:52:45 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A48088.2040407@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
	<Pine.LNX.4.61.0606291923000.9561@www> <44A48088.2040407@gmail.com>
Message-ID: <Pine.LNX.4.61.0606291945060.9561@www>

On Thu, 29 Jun 2006, Manuel Naranjo wrote:

>> On Thu, 29 Jun 2006, Manuel Naranjo wrote:
>>
>>> Speaking about Windows Support, I had seen that inside the
>>> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
>>> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
>>> not make harm to anyone, and i'm almost sure that someone has noticed it
>>> before.
>>
>> Hi Manuel
>>
>>         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
>>         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
>>     47421  01-30-06 00:23
>> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
>>     77759  03-01-06 12:01
>> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
>>       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README
>>
>>
>> It looks normal to me.  There are no fancy tools used there :)
>>
> Hi Trent:
> Is not the i368 representing the name of the Architecture?? If so the
> name should start with i386 it will not break any system, is simply miss
> written, I saw that and wanted to report it. It a silly thing.
> Ohh I forgoten I must congratulate you for your GREAT libray, I was able
> to make an .exe with JSmooth that launches an application that uses RXTX
> with out the need to install RXTX on users system :). The .exe tells JVM
> where to find the RXTX Library and Binaries. I tried with Sun's Java
> Comm but it was imposible.

Hi Manuel

The compiler uses only the i386 instruction set for windows.  I doubt 
there will be any measurable advantages with going to later instruction 
sets.  In theory rxtx would run on a 386 but I doubt anyone does that.

So it looks odd but is not a typo.

We could compile to i686 but don't.  The compiler used does not appear to 
be a problem yet so I don't see any point in changing it.  Right now, we 
could not compile 64 bit windows binaries.  gcc/mingw/... do not support 
them that I know of.  People will have to compile those with closed source 
tools on their own until an option is available.

--
Trent Jarvi
tjarvi at qbang.org

From naranjo.manuel at gmail.com  Thu Jun 29 20:00:48 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 23:00:48 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606291945060.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com>	<Pine.LNX.4.61.0606291923000.9561@www>
	<44A48088.2040407@gmail.com> <Pine.LNX.4.61.0606291945060.9561@www>
Message-ID: <44A485D0.7050202@gmail.com>

Trent you did not get my point
The folder says 368 three hundred sixty eight, when
it should say 386 three hundred eighty six. Is simply a miss writting.
Regards,
Manuel


From tjarvi at qbang.org  Thu Jun 29 20:12:15 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 20:12:15 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A485D0.7050202@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
	<Pine.LNX.4.61.0606291923000.9561@www> <44A48088.2040407@gmail.com>
	<Pine.LNX.4.61.0606291945060.9561@www> <44A485D0.7050202@gmail.com>
Message-ID: <Pine.LNX.4.61.0606292008061.9561@www>


On Thu, 29 Jun 2006, Manuel Naranjo wrote:

> Trent you did not get my point
> The folder says 368 three hundred sixty eight, when
> it should say 386 three hundred eighty six. Is simply a miss writting.

hehe..  OK.  My bad.  It's been a long day.

Nevermind :)

--
Trent Jarvi
tjarvi at qbang.org




From naranjo.manuel at gmail.com  Thu Jun 29 20:18:44 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 23:18:44 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606292008061.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com>	<Pine.LNX.4.61.0606291923000.9561@www>
	<44A48088.2040407@gmail.com>	<Pine.LNX.4.61.0606291945060.9561@www>
	<44A485D0.7050202@gmail.com> <Pine.LNX.4.61.0606292008061.9561@www>
Message-ID: <44A48A04.9040401@gmail.com>

Don't worry Trent.
About 64 bits compilation, I would like to colaborate, I have a Pc with 
64 bits, the only problem is that i do not have windows 64 bits 
installed :(.




From Pawan.Kharbanda at dot.state.co.us  Fri Jun 30 08:49:52 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 30 Jun 2006 08:49:52 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E996@hqexchange3.dot.state.co.us>

Trent,  
    Can you explain what the interruptedEventLoop() native method is
doing is there a possibility that method is somehow getting into the
infinite loop(there are 2 while loops without any break statements).
This might be a very basic question how can I debug the native code(or
print the debug statements).  Again thanks for the help. 

Pawan Kharbanda

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Thursday, June 29, 2006 6:21 AM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports

> Here is how you can test if you have resources/ test environment. 
> Write a program and try to open/close  different ports(I will say have

> a minimum of four) randomly and very frequently(may be 30 seconds), I 
> am pretty sure you will see the deadlocks and it happens in the native

> call to interrptEventLoop in RXTXPort.java in removeEventListener() 
> method call.

Hi Pawan

I'll try to find a way to reproduce this.  One thing to note is that you
are using different kernel drivers (digi) to perform this task.  So I
probably will not be able to reproduce the exact same environment.

In general, multiport kernel drivers have been tested far less than
typical serial drivers.  This may or may not be an issue.

--
Trent Jarvi
tjarvi at qbang.org

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From cpine at wrsystems.com  Thu Jun 29 15:17:12 2006
From: cpine at wrsystems.com (Chris Pine)
Date: Thu, 29 Jun 2006 17:17:12 -0400
Subject: [Rxtx]  Controlling Individual Signals DTR and RTS
Message-ID: <MAIL4FJo0S8ACLEBajJ000005cf@mail4.wrsystems.com>

Dear Moussa Ba,
	I hope I am not being too forward, but we are having the exact same
issue with needing to control DTR from RXTX in Linux.  Did you ever have any
luck figuring it out?

Thank you very much for your time,

Chris Pine




From tjarvi at qbang.org  Thu Jun  1 11:13:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 11:13:40 -0600 (MDT)
Subject: [Rxtx] custom baud rate win32
In-Reply-To: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606011107210.30220@www>


Hi Daren

I can't imagine that 1953 is possibly the actual value on the UART.  Maybe 
if your baud base is very high with a custom serial board.  More likely, 
the driver just remembers that what you asked for and did something else.

I'll have more to say on the dcb->BaudRate after I try some things here. 
I have managed to do something like that in the past as a quick hack but 
it was for 14400.  I may have used the CBR_14400.

If we can't access this through the win32 API with protected mode, there 
is another layer of complication.  With real mode, it would be easy.
With protected mode, I assume there would have to be some kernel driver or 
a hook I'm not aware of to access the MCR directly (bang a memory 
addresss).



On Thu, 1 Jun 2006, Daren wrote:

> Trent,
> I have managed to successfully open the port at this speed using Realterm
> (available on sourceforge). From memory this uses DLPortIO.
>
> Using portmon.exe with realterm, even there it says that the port has opened
> at 1953.
>
> I changed termios.c:560 to
> dcb->BaudRate        = 1953 ;
>
> and it still opens the port at 9600.
>
> Daren
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Trent Jarvi
> Sent: Thursday, 1 June 2006 1:44 PM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] custom baud rate win32
>
> On Thu, 1 Jun 2006, Daren wrote:
>
>> Hi all,
>>
>> I downloaded 2.1.7-pre16 and managed to build it and get it going. I made
>> the changes as suggested by Peter Smith in an old post, by adding his code
>> to SerialImpl.c, uncommenting the TIOCGSERIAL and TIOCSSERIAL, and
> defining
>> ASYNC_SPD_CUST which is equal to 0x0030 (according to linus header
> files)..
>>
>>
>> Still not working, it opens the port at 9600 according to portmon.exe .
> Has
>> anyone managed to get this going at a custom rate?
>>
>> Here is the post I'm referring to:
>> http://marc.theaimsgroup.com/?l=rxtx&m=106270038110713&w=2
>>
>>
>> Thanks,
>> Daren
>>
>> ________________________________________
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
>> Daren
>> Sent: Wednesday, 31 May 2006 10:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] (no subject)
>>
>> Hi All,
>> I have been using rxtx for a little while and needed to get it working at
>> 1953, like a past user in the mailing list, who seemed to have got it
>> working by changing some C code.
>>
>> I wanted to build rxtx myself with these changes but don't know where to
>> start. I have windows here and FC4 at home. I downloaded cygwin and
> mingw32,
>> each build works by building a rxtxSerial.dll file that is ~11k smaller
> than
>> the original, and I always get the following error when testing the dll:
>>
>> Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at
>> PC=0x8077655
>> Function=[Unknown.]
>> Library=C:\opt\java\j2sdk1.4.2\jre\bin\client\jvm.dll
>>
>> NOTE: We are unable to locate the function name symbol for the error
>>      just occurred. Please refer to release documentation for possible
>>      reason and solutions.
>>
>>
>> Current Java thread:
>> 	at gnu.io.RXTXPort.open(Native Method)
>> 	- locked <0x1002c800> (a gnu.io.RXTXPort)
>> 	at gnu.io.RXTXPort.<init>(RXTXPort.java:84)
>>
>> Anyone know what im doing wrong?
>>
>>
>>
>>
>
> Hi Daren
>
> You are running into the same rats nest I'm looking at now.
>
> With win32 and specific custom baud rates, I'm not sure how this will go.
> I've got the Linux custom baud rates working very nicely.  I did much like
> the post you linked.  In fact I had forgot about that post.  You probably
> noticed that it becomes a bunch of dirt roads going noplace fast in
> termios.c for w32.
>
> I'm probably only going to get 14400, 28800, 128000 and 256000 working
> with the next release on w32.  I'll look a little further.  If you have an
> example w32 that works at 1953 I'd really like to hear.  Thats an unusual
> baud rate.
>
> Assuming a baud_base of 128000, your divisor will be 65 or 66.
>
> 128000/66=1939 -14
> 128000/65=1969 +13
>
> One thing I've been wondering about with linux is which would be the right
> answer in cases like this.  Right now it would just go with a baud base of
> 65 and ignore the modulus details.
>
> It appears to be a general trend for kernel developers to hide these
> details thinking that they can come up with a general solution.  Then they
> run out of time.  Perahps the solution is to help out but there are
> ultiple OS's rxtx supports making that nontrivial.
>
> If you look at current linux kernels, the 'tricks' above have been marked
> deprecated with no replacement.  Windows has some hard defines and then
> ancient near magic.  I've not looked at Solaris via Open Solaris yet but
> doubt there is a solution at all.
>
> What I'd try since you have the equipment and the monitor software is to
> hardcode the dcb->Baud in termios.c to 1953 (no define) and see what the
> w32 kernel does with it.  I think if you toss a baud rate at the driver it
> will try to come close.  You may try comming closer to a real baudrate
> based upon the 128000 baud base as shown above.
>
> If it works, it is worth looking at the rest of the ping/pong logic then.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
>
>
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From doug at dupreeinc.com  Thu Jun  1 13:22:13 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 12:22:13 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011107210.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
Message-ID: <447F3E65.1020809@dupreeinc.com>

Hello,

I am still trying to get this startup a little faster so I turned on the 
debug of a few of the classes.  The COM ports are scanned really fast 
and the delay occurs during the LPT scan.  The console output looks like 
this:

    ...
      LPT1
      LPT2
      LPT3
     valid port prefixes:
      LPT
    LPT1 LPT
    1 1
    LPT2 LPT
    2 2                                                                 
      * <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
    CommPortIdentifier:addPortName(LPT2)
    CommPortIdentifier:AddIdentifierToList()
    LPT3 LPT
    3 3
    CommPortIdentifier:addPortName(LPT3)
    CommPortIdentifier:AddIdentifierToList()
    CommPortIdentifier:AddIdentifierToList() index.next
    Leaving registerValidPorts()
    Have not implemented native_psmisc_report_owner(PortName)); in
    CommPortIdentifier
    CommPortIdentifier:getPortIdentifier(COM3)
    CommPortIdentifier:open(densConnect, 30000)
    RXTXCommDriver:getCommPort(COM3,1)
    ...

It would seem to me that if I removed the code for port scanning of LPT 
ports I could solve this problem. I would much prefer to use unmodified 
code if at all possible.  Do any of you have alternate suggestions?

Thank you for your time.

Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/cf433ee7/attachment-0023.html

From tjarvi at qbang.org  Thu Jun  1 13:52:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 13:52:06 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F3E65.1020809@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011348380.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I am still trying to get this startup a little faster so I turned on the 
> debug of a few of the classes.  The COM ports are scanned really fast and the 
> delay occurs during the LPT scan.  The console output looks like this:
>
>   ...
>     LPT1
>     LPT2
>     LPT3
>    valid port prefixes:
>     LPT
>   LPT1 LPT
>   1 1
>   LPT2 LPT
>   2 2                                                                      * 
> <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>   CommPortIdentifier:addPortName(LPT2)
>   CommPortIdentifier:AddIdentifierToList()
>   LPT3 LPT
>   3 3
>   CommPortIdentifier:addPortName(LPT3)
>   CommPortIdentifier:AddIdentifierToList()
>   CommPortIdentifier:AddIdentifierToList() index.next
>   Leaving registerValidPorts()
>   Have not implemented native_psmisc_report_owner(PortName)); in
>   CommPortIdentifier
>   CommPortIdentifier:getPortIdentifier(COM3)
>   CommPortIdentifier:open(densConnect, 30000)
>   RXTXCommDriver:getCommPort(COM3,1)
>   ...
>
> It would seem to me that if I removed the code for port scanning of LPT ports 
> I could solve this problem. I would much prefer to use unmodified code if at 
> all possible.  Do any of you have alternate suggestions?
>
> Thank you for your time.
>
> Doug
>


Does commenting out the LPT enumeration actually help?  There can often be 
differences between debug information printed and whats really going on. 
When you combine various environments the debug info can even come out in 
the wrong order.

I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
I do not think this problem is universal.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Thu Jun  1 14:29:44 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:29:44 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4E38.2060004@dupreeinc.com>

I will give it a try.  One thing to note on this PC is it has no LPT 
Parallel ports.

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
>>Hello,
>>
>>I am still trying to get this startup a little faster so I turned on the 
>>debug of a few of the classes.  The COM ports are scanned really fast and the 
>>delay occurs during the LPT scan.  The console output looks like this:
>>
>>  ...
>>    LPT1
>>    LPT2
>>    LPT3
>>   valid port prefixes:
>>    LPT
>>  LPT1 LPT
>>  1 1
>>  LPT2 LPT
>>  2 2                                                                      * 
>><<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>>  CommPortIdentifier:addPortName(LPT2)
>>  CommPortIdentifier:AddIdentifierToList()
>>  LPT3 LPT
>>  3 3
>>  CommPortIdentifier:addPortName(LPT3)
>>  CommPortIdentifier:AddIdentifierToList()
>>  CommPortIdentifier:AddIdentifierToList() index.next
>>  Leaving registerValidPorts()
>>  Have not implemented native_psmisc_report_owner(PortName)); in
>>  CommPortIdentifier
>>  CommPortIdentifier:getPortIdentifier(COM3)
>>  CommPortIdentifier:open(densConnect, 30000)
>>  RXTXCommDriver:getCommPort(COM3,1)
>>  ...
>>
>>It would seem to me that if I removed the code for port scanning of LPT ports 
>>I could solve this problem. I would much prefer to use unmodified code if at 
>>all possible.  Do any of you have alternate suggestions?
>>
>>Thank you for your time.
>>
>>Doug
>>
>>    
>>
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/dd31fed5/attachment-0023.html

From doug at dupreeinc.com  Thu Jun  1 14:36:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:36:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4FC8.9080106@dupreeinc.com>

Trent,

I commented out the section in RegisterScannedPorts() that adds the 
three LPT ports to the CandidateDeviceNames string array.  The 
application started immediately.  This is probably not the way to do 
this, but it was quick ,dirty, and worked.

It would be nice if there was a way to pole the OS to see if there is 
even a port there, though I guess this is what this code is suppose to do...

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
> ...
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From lynn at swcp.com  Thu Jun  1 14:49:34 2006
From: lynn at swcp.com (lynn@swcp.com)
Date: Thu, 1 Jun 2006 20:49:34 -0000
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>,
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <twig.1149194974.97617@swcp.com>

Perhaps we could add an argument to port enumeration where if not specified,
you get the default behavior that looks for everything.  With a new
constructor that has an argument(or more) you could optionally declare it to
not inspect printer ports.

Existing code would work as it always has.  New code could be smarter.

Lynn



Doug Thistlethwaite <doug at dupreeinc.com> said:

> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
> >On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
> >
> >  
> >
> > ...
> >
> >
> >Does commenting out the LPT enumeration actually help?  There can often be 
> >differences between debug information printed and whats really going on. 
> >When you combine various environments the debug info can even come out in 
> >the wrong order.
> >
> >I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
> >I do not think this problem is universal.
> >
> >--
> >Trent Jarvi
> >tjarvi at qbang.org
> >_______________________________________________
> >Rxtx mailing list
> >Rxtx at qbang.org
> >http://mailman.qbang.org/mailman/listinfo/rxtx
> >
> >
> >  
> >
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



-- 





From jredman at ergotech.com  Thu Jun  1 15:20:20 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 01 Jun 2006 15:20:20 -0600
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
Message-ID: <447F5A14.6010803@ergotech.com>

Doug,

If you specifically request ports, eg:

-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

or
 
-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

Depending upon the version  (Windows is COM1:COM2, etc. I assume).

Does it still enumerate the parallel ports?

Jim

Doug Thistlethwaite wrote:
> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
>> On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>
>>  
>>
>> ...
>>
>>
>> Does commenting out the LPT enumeration actually help?  There can often be 
>> differences between debug information printed and whats really going on. 
>> When you combine various environments the debug info can even come out in 
>> the wrong order.
>>
>> I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>> I do not think this problem is universal.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>>
>>  
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  1 16:49:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:49:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6EF4.7080709@dupreeinc.com>

I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
folder.  I created this file and added the following to the file:

gnu.io.rxtx.SerialPorts=COM3

and I get the following error on the console:
CommPortIdentifier:static initialization()
RXTXCommDriver {}
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
RXTXCommDriver:
    Jar version = RXTX-2.1-7
    native lib Version = RXTX-2.1-7
RXTXCommDriver:initialize()
checking for system-known ports of type 1
checking registry for ports of type 1

RXTXCommDriver:addSpecifiedPorts()
Exception in thread "main" java.lang.ExceptionInInitializerError
    at 
densconnect.SerialConnection.openConnection(SerialConnection.java:136)
    at densconnect.DensTalk.<init>(DensTalk.java:165)
    at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
    at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
    at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
    at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
Caused by: java.lang.NullPointerException
    at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
CommPortIdentifier:addPortName(COM3)
CommPortIdentifier:AddIdentifierToList()
CommPortIdentifier:AddIdentifierToList() null
...


It looks like it  read COM3 from the file, but it had the above 
exception that killed it.  The strange this is this error is from 
RXTXCommDriver initialize function (if statement line):

        OS = System.getProperty("os.name");
                System.out.println("OS NAME: " + OS);
        if(OS.toLowerCase().indexOf("linux") == -1)

OS is returning null, thus the error.

If the file is not present, it scans the ports and reads the OS.

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>Doug Thistlethwaite wrote:
>  
>
>>Trent,
>>
>>I commented out the section in RegisterScannedPorts() that adds the 
>>three LPT ports to the CandidateDeviceNames string array.  The 
>>application started immediately.  This is probably not the way to do 
>>this, but it was quick ,dirty, and worked.
>>
>>It would be nice if there was a way to pole the OS to see if there is 
>>even a port there, though I guess this is what this code is suppose to do...
>>
>>Doug
>>
>>Trent Jarvi wrote:
>>
>>    
>>
>>>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>>
>>> 
>>>
>>>...
>>>
>>>
>>>Does commenting out the LPT enumeration actually help?  There can often be 
>>>differences between debug information printed and whats really going on. 
>>>When you combine various environments the debug info can even come out in 
>>>the wrong order.
>>>
>>>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>>>I do not think this problem is universal.
>>>
>>>--
>>>Trent Jarvi
>>>tjarvi at qbang.org
>>>_______________________________________________
>>>Rxtx mailing list
>>>Rxtx at qbang.org
>>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>>
>>>
>>> 
>>>
>>>      
>>>
>>_______________________________________________
>>Rxtx mailing list
>>Rxtx at qbang.org
>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>    
>>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/bf4cca0e/attachment-0023.html

From doug at dupreeinc.com  Thu Jun  1 16:51:26 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:51:26 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6F6E.5060603@dupreeinc.com>

Jim,

I did not try your suggestion as I do not understand where I would put 
these command line parameters (it that is what they are).  It appears 
that using the properties file should do that same thing...

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>
>  
>


From doug at dupreeinc.com  Thu Jun  1 17:56:19 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 16:56:19 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
Message-ID: <447F7EA3.6050400@dupreeinc.com>

I think there is an error in the registerSpecifiedPorts() method.  When 
I have a gnu.io.rxtx.properties file in the ext directory, this function 
kills the System class  IF I call System.getProperty("os.name") before 
the call  to registerSpecifiedPorts(), it returns the os name, after the 
call, it returns null.  I have not played much with properties, except 
for reading them, so I don't really understand the code.

Doug



From doug at dupreeinc.com  Thu Jun  1 18:11:14 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 17:11:14 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F7EA3.6050400@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com>
Message-ID: <447F8222.3060402@dupreeinc.com>

Ok, I just hacked this thing up and got it to read the 
gnu.io.rxtx.properties file.

I commented out the line:
System.setProperties(p); in the method registerSpecifiedPorts() in 
RXTXCommDriver class.  I really don't understand that much about 
properties, but this call kills the System class.

I used the following in the gnu.io.rxtx.properties file:

gnu.io.rxtx.SerialPorts=COM3
gnu.io.rxtx.ParallelPorts=null

This allows the application to open very quickly without any errors.  
Whomever coded this class or somebody who understands properties should 
look at this method and make sure it is doing what they expect.

Doug




Doug Thistlethwaite wrote:

>I think there is an error in the registerSpecifiedPorts() method.  When 
>I have a gnu.io.rxtx.properties file in the ext directory, this function 
>kills the System class  IF I call System.getProperty("os.name") before 
>the call  to registerSpecifiedPorts(), it returns the os name, after the 
>call, it returns null.  I have not played much with properties, except 
>for reading them, so I don't really understand the code.
>
>Doug
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From tjarvi at qbang.org  Thu Jun  1 18:32:50 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 18:32:50 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F6EF4.7080709@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com> <447F6EF4.7080709@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011831510.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
> folder.  I created this file and added the following to the file:
>
> gnu.io.rxtx.SerialPorts=COM3
>
> and I get the following error on the console:
> CommPortIdentifier:static initialization()
> RXTXCommDriver {}
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
> RXTXCommDriver:
>   Jar version = RXTX-2.1-7
>   native lib Version = RXTX-2.1-7
> RXTXCommDriver:initialize()
> checking for system-known ports of type 1
> checking registry for ports of type 1
>
> RXTXCommDriver:addSpecifiedPorts()
> Exception in thread "main" java.lang.ExceptionInInitializerError
>   at densconnect.SerialConnection.openConnection(SerialConnection.java:136)
>   at densconnect.DensTalk.<init>(DensTalk.java:165)
>   at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
>   at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
>   at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
>   at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
> Caused by: java.lang.NullPointerException
>   at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
> CommPortIdentifier:addPortName(COM3)
> CommPortIdentifier:AddIdentifierToList()
> CommPortIdentifier:AddIdentifierToList() null
> ...
>
>

There is a solution for this bug.

http://bugzilla.qbang.org/show_bug.cgi?id=54

We have been horribly slow at getting the next round of patches in but 
they are comming.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  2 00:58:02 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 08:58:02 +0200
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F8222.3060402@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
Message-ID: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>

Hi Doug,

you wrote in an earlier message, that you would prefer an unchanged  
version. What about simply removing the RXTX parallel lib from the  
ext directory. This does not fix the bug, but it should fix your  
problem.

In general I think it is not a good idea to put the RXTX files in a  
system wide location. Putting the libs in the application folder and  
including the .jar in the application classpath (or application jar)  
is all that is required.

Regards,
Joachim

On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:

> Ok, I just hacked this thing up and got it to read the
> gnu.io.rxtx.properties file.
>
> I commented out the line:
> System.setProperties(p); in the method registerSpecifiedPorts() in
> RXTXCommDriver class.  I really don't understand that much about
> properties, but this call kills the System class.
>
> I used the following in the gnu.io.rxtx.properties file:
>
> gnu.io.rxtx.SerialPorts=COM3
> gnu.io.rxtx.ParallelPorts=null
>
> This allows the application to open very quickly without any errors.
> Whomever coded this class or somebody who understands properties  
> should
> look at this method and make sure it is doing what they expect.
>
> Doug
>
>
>
>
> Doug Thistlethwaite wrote:
>
>> I think there is an error in the registerSpecifiedPorts() method.   
>> When
>> I have a gnu.io.rxtx.properties file in the ext directory, this  
>> function
>> kills the System class  IF I call System.getProperty("os.name")  
>> before
>> the call  to registerSpecifiedPorts(), it returns the os name,  
>> after the
>> call, it returns null.  I have not played much with properties,  
>> except
>> for reading them, so I don't really understand the code.
>>
>> 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 antonio.luis at iscte.pt  Fri Jun  2 02:42:28 2006
From: antonio.luis at iscte.pt (=?ISO-8859-1?Q?Ant=F3nio_Lopes?=)
Date: Fri, 02 Jun 2006 09:42:28 +0100
Subject: [Rxtx] Exception when closing serial port
Message-ID: <447FF9F4.7060209@iscte.pt>

Hello everyone,
I've been using RXTX in a Java application in my Pocket PC.
The communication through the (bluetooth) serial port is working perfectly.

However, when I disconnect the app and close the serial port, sometimes I get 
the following error:

"1149237595000: RXTXPort:close detected bad File Descriptor"

The problem is that after this error occurs, the app is no longer able to 
connect to the serial port and I have to soft-reset the device in order to be 
able to connect to it again.

Any ideas on how to solve this issue?

Any help is appreciated.
Thanks,
regards,
-- 
Ant?nio Lopes

@contact: antonio.luis at iscte.pt
@work: ADETTI - ISCTE
@web: http://antonio.lopes.googlepages.com


From paul.klissner at sun.com  Fri Jun  2 02:44:34 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 01:44:34 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to RXTX
	again
Message-ID: <447FFA72.6040807@sun.com>

After looking into javax.comm 3.1 and what it would take to re-engineer it
to be compatible with RXTX platform libraries, I've decided, due my group's
priorities, complexity of the effort vs. benefit, and limited resources, 
to re-post
javax.comm 2.0 binaries on Sun's software download server, unsupported,
with disclaimers, as it was previously.

I don't think there will be any snags doing this from the standpoint of Sun
management or legality.  I will try to have it  posted there in the next 
week
or two, depending on how fast we can get it pushed through the process.

I'd like to think of this as a stop gap measure... ie. a compromise, 
where, at some
point in the not too distant future RXTX implements their own version of the
Java side of the API, as is normally done by javax.extension porters. 
That way
we avoid uncomfortable dependencies in the future.  And that really is 
the Java
development model.

Since RXTX already has the back-end code, porting the java code shouldn't
be a gargantuan effort at all, and RXTX will be in full control of the 
code top
to bottom. I think RXTX can do at least as good a job as the original 
coder.
Prepping 2.0 to be open sourced is more trouble than it is worth. ie. I 
don't
think the current implementation warrants it.

Ultimately, it would be nice to see someone open up a JSR and re-architect
the comm. API to overcome some of it's current design flaws (ie. be more
adaptable to modern platforms, more pluggable, better defined SPI, better
port ownership handling, etc...). A superior architecture would allow for
better collaboration in the future and better interchangeability of 
components
among projects.

Sun's 3.1 version of javax.comm, which is Sun's currently supported version,
has changes pertaining mostly to Sun platform-specific portmapping and has
some minor additional interactions with our back end code, but generally
has little bearing on RXTX. 

Paul



From joachim at buechse.de  Fri Jun  2 04:00:19 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 12:00:19 +0200
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
	RXTX again
In-Reply-To: <447FFA72.6040807@sun.com>
References: <447FFA72.6040807@sun.com>
Message-ID: <1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>

Good day Paul!

A clean architecture with loadable drivers and reusable code would be  
very beneficial for the future, I think everybody agrees. However  
this could be several years into the future. In the meantime, there  
is a real existing problem with IO support on Java. I have the strong  
feeling that most programmers want to code against one specification  
(javax.comm) and be able to replace the underlying implementation via  
a "plugin" on platforms where the SUN implementation is not  
sufficient. RXTX could be just this plugin (reusing very close to 0%  
of the javax.comm implementation but 100% of its API).

I want to propose an API addition and implementation change that will  
take less then 2 hours of manpower to implement and create a solution  
that can bridge the years until javax.comm has been based on a new  
architecture.

Looking at the javax.comm api at http://java.sun.com/products/ 
javacomm/reference/api/index.html I would like to propose the following:

The only entry point to javax.comm is CommPortIdentifier. It has 3  
static methods plus the constructor.

1) define one additional Interface

public interface CommProvider {
    CommPortIdentifier getPortIdentifier(CommPort port);
    CommPortIdentifier getPortIdentifier(String portName);
    Enumeration getPortIdentifiers ();
}

2) add one method to CommPortIdentifier

   public static setCustomCommProvider (CommProvider);

3) change the three static methods of CommPortIdentifier to dispatch  
to the CommProvider if it is set

4) change the constructor of CommPortIdentifier to

   public CommPortIdentifier(...) {
      if (isProviderSet && this.getClass() ==  
javax.comm.CommPortIdentifier) {
          throw new RuntimeException("illegal creation of  
CommPortIndentifier, custom CommProvider is in use");
      }

5) (this is optional, but would be very nice) automatically set a  
custom CommProvider if it is found on the classpath or defined via a  
system property.


The above 1) - 4) can be implemented in less than 1hour. 5) may take  
another hour. I agree that this is not the most elegant design, but  
it would solve a lot of problems with very little effort. It would  
certainly allow RXTX to move forward. If the javax.comm API needs to  
be redesigned completely this addition will not hurt, as people will  
move to the new API anyway and javax.comm 3.0 was so far never  
included in the main distribution.

Best regards,
Joachim

On 02.06.2006, at 10:44, Paul Klissner wrote:

> After looking into javax.comm 3.1 and what it would take to re- 
> engineer it
> to be compatible with RXTX platform libraries, I've decided, due my  
> group's
> priorities, complexity of the effort vs. benefit, and limited  
> resources,
> to re-post
> javax.comm 2.0 binaries on Sun's software download server,  
> unsupported,
> with disclaimers, as it was previously.
>
> I don't think there will be any snags doing this from the  
> standpoint of Sun
> management or legality.  I will try to have it  posted there in the  
> next
> week
> or two, depending on how fast we can get it pushed through the  
> process.
>
> I'd like to think of this as a stop gap measure... ie. a compromise,
> where, at some
> point in the not too distant future RXTX implements their own  
> version of the
> Java side of the API, as is normally done by javax.extension porters.
> That way
> we avoid uncomfortable dependencies in the future.  And that really is
> the Java
> development model.
>
> Since RXTX already has the back-end code, porting the java code  
> shouldn't
> be a gargantuan effort at all, and RXTX will be in full control of the
> code top
> to bottom. I think RXTX can do at least as good a job as the original
> coder.
> Prepping 2.0 to be open sourced is more trouble than it is worth.  
> ie. I
> don't
> think the current implementation warrants it.
>
> Ultimately, it would be nice to see someone open up a JSR and re- 
> architect
> the comm. API to overcome some of it's current design flaws (ie. be  
> more
> adaptable to modern platforms, more pluggable, better defined SPI,  
> better
> port ownership handling, etc...). A superior architecture would  
> allow for
> better collaboration in the future and better interchangeability of
> components
> among projects.
>
> Sun's 3.1 version of javax.comm, which is Sun's currently supported  
> version,
> has changes pertaining mostly to Sun platform-specific portmapping  
> and has
> some minor additional interactions with our back end code, but  
> generally
> has little bearing on RXTX.
>
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Fri Jun  2 09:10:13 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Fri, 2 Jun 2006 09:10:13 -0600 (MDT)
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <447FFA72.6040807@sun.com>
References: <447FFA72.6040807@sun.com>
Message-ID: <Pine.LNX.4.61.0606020906400.15971@www>

On Fri, 2 Jun 2006, Paul Klissner wrote:

> After looking into javax.comm 3.1 and what it would take to re-engineer it
> to be compatible with RXTX platform libraries, I've decided, due my group's
> priorities, complexity of the effort vs. benefit, and limited resources,
> to re-post
> javax.comm 2.0 binaries on Sun's software download server, unsupported,
> with disclaimers, as it was previously.
>

Hi Paul

To address users' immediate needs, we can release rxtx 2.0-7 (final) to 
match the 2.0 binaries from Sun when they are offered for download.

We can discuss potential long term solutions after that.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Fri Jun  2 10:20:09 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 02 Jun 2006 09:20:09 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
	<9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
Message-ID: <44806539.8080902@dupreeinc.com>

Thanks for the suggestion, I will give it a try.

Doug

Joachim Buechse wrote:

>Hi Doug,
>
>you wrote in an earlier message, that you would prefer an unchanged  
>version. What about simply removing the RXTX parallel lib from the  
>ext directory. This does not fix the bug, but it should fix your  
>problem.
>
>In general I think it is not a good idea to put the RXTX files in a  
>system wide location. Putting the libs in the application folder and  
>including the .jar in the application classpath (or application jar)  
>is all that is required.
>
>Regards,
>Joachim
>
>On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:
>
>  
>
>>Ok, I just hacked this thing up and got it to read the
>>gnu.io.rxtx.properties file.
>>
>>I commented out the line:
>>System.setProperties(p); in the method registerSpecifiedPorts() in
>>RXTXCommDriver class.  I really don't understand that much about
>>properties, but this call kills the System class.
>>
>>I used the following in the gnu.io.rxtx.properties file:
>>
>>gnu.io.rxtx.SerialPorts=COM3
>>gnu.io.rxtx.ParallelPorts=null
>>
>>This allows the application to open very quickly without any errors.
>>Whomever coded this class or somebody who understands properties  
>>should
>>look at this method and make sure it is doing what they expect.
>>
>>Doug
>>
>>
>>
>>
>>Doug Thistlethwaite wrote:
>>
>>    
>>
>>>I think there is an error in the registerSpecifiedPorts() method.   
>>>When
>>>I have a gnu.io.rxtx.properties file in the ext directory, this  
>>>function
>>>kills the System class  IF I call System.getProperty("os.name")  
>>>before
>>>the call  to registerSpecifiedPorts(), it returns the os name,  
>>>after the
>>>call, it returns null.  I have not played much with properties,  
>>>except
>>>for reading them, so I don't really understand the code.
>>>
>>>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
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060602/c8892a46/attachment-0023.html

From paul.klissner at sun.com  Fri Jun  2 12:09:26 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 11:09:26 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
Message-ID: <44807ED6.8000903@sun.com>

Joachim Buechse wrote:
> Good day Paul!
>
> A clean architecture with loadable drivers and reusable code would be  
> very beneficial for the future, I think everybody agrees. However  
> this could be several years into the future. In the meantime, there  
> is a real existing problem with IO support on Java. I have the strong  
> feeling that most programmers want to code against one specification  
> (javax.comm) and be able to replace the underlying implementation via  
> a "plugin" on platforms where the SUN implementation is not  
> sufficient. RXTX could be just this plugin (reusing very close to 0%  
> of the javax.comm implementation but 100% of its API).
>
> I want to propose an API addition and implementation change that will  
> take less then 2 hours of manpower to implement and create a solution  
> that can bridge the years until javax.comm has been based on a new  
> architecture.
>
> Looking at the javax.comm api at http://java.sun.com/products/ 
> javacomm/reference/api/index.html I would like to propose the following:
>
> The only entry point to javax.comm is CommPortIdentifier. It has 3  
> static methods plus the constructor.
>
> 1) define one additional Interface
>
> public interface CommProvider {
>     CommPortIdentifier getPortIdentifier(CommPort port);
>     CommPortIdentifier getPortIdentifier(String portName);
>     Enumeration getPortIdentifiers ();
> }
>
> 2) add one method to CommPortIdentifier
>
>    public static setCustomCommProvider (CommProvider);
>
> 3) change the three static methods of CommPortIdentifier to dispatch  
> to the CommProvider if it is set
>
> 4) change the constructor of CommPortIdentifier to
>
>    public CommPortIdentifier(...) {
>       if (isProviderSet && this.getClass() ==  
> javax.comm.CommPortIdentifier) {
>           throw new RuntimeException("illegal creation of  
> CommPortIndentifier, custom CommProvider is in use");
>       }
>
> 5) (this is optional, but would be very nice) automatically set a  
> custom CommProvider if it is found on the classpath or defined via a  
> system property.
>
>
> The above 1) - 4) can be implemented in less than 1hour. 5) may take  
> another hour. I agree that this is not the most elegant design, but  
> it would solve a lot of problems with very little effort. It would  
> certainly allow RXTX to move forward. If the javax.comm API needs to  
> be redesigned completely this addition will not hurt, as people will  
> move to the new API anyway and javax.comm 3.0 was so far never  
> included in the main distribution.
>
> Best regards,
> Joachi
I'm afraid modifying the interface classes isn't my call.  There was 
actually
a TCK written and one of the tests was to ensure that the interface classes
match the spec.  Thus my hands have already been tied since this project
was essentially grandfathered into the JCP.

That's why we need to open a new JSR and find someone who wants
to be the spec lead, and go in with a new reference implementation.
I'm not sure why it would have to take years, since this isn't bleeding edge
technology and there are only so many things that can be done with it,
and we already have practical experience about many functional aspects
that we could cite precedence on.

As it becomes clear that the specification is being accepted completely
or by-and-large by the community, nothing would stop people from
starting adapting to the new API (using the reference implementation or
porting it) and using it in their projects prior to it's final community and
JCP approval, since approval is required only to make it official and
get the "100% pure java" certification for platform ports.

You have one idea already.  Why don't you implement it, solicit some
design feedback from Sun and the RXTX, and create a functional
implementation that addresses the needs of the community, then
we can document it and open a JSR.  That's it.  It should march through
the approval stages reasonably quickly I would imagine, and meantime
RXTX could start using it.

Paul




From doug at dupreeinc.com  Fri Jun  2 12:45:01 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 02 Jun 2006 11:45:01 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
References: <447F7EA3.6050400@dupreeinc.com> <447F8222.3060402@dupreeinc.com>
	<9A41A5D5-7E8D-4A7D-A28F-E6388BD7D9C8@buechse.de>
Message-ID: <4480872D.6000605@dupreeinc.com>

Joachim,

Thank you for the suggestion.  I restored the jar file to the one I 
downloaded, moved the dll files into the project directory, and added 
the jar to the classpath.  The SerialDemo program that was included with 
the Sun commapi started in 12 seconds instead of the 58 seconds when the 
parallel dll is present.  I did get the startup time to about a second 
by modifying the java code and adding the properties file but this is 
probably not a good idea.

Doug

Joachim Buechse wrote:

>Hi Doug,
>
>you wrote in an earlier message, that you would prefer an unchanged  
>version. What about simply removing the RXTX parallel lib from the  
>ext directory. This does not fix the bug, but it should fix your  
>problem.
>
>In general I think it is not a good idea to put the RXTX files in a  
>system wide location. Putting the libs in the application folder and  
>including the .jar in the application classpath (or application jar)  
>is all that is required.
>
>Regards,
>Joachim
>
>On 02.06.2006, at 02:11, Doug Thistlethwaite wrote:
>
>  
>
>>Ok, I just hacked this thing up and got it to read the
>>gnu.io.rxtx.properties file.
>>
>>I commented out the line:
>>System.setProperties(p); in the method registerSpecifiedPorts() in
>>RXTXCommDriver class.  I really don't understand that much about
>>properties, but this call kills the System class.
>>
>>I used the following in the gnu.io.rxtx.properties file:
>>
>>gnu.io.rxtx.SerialPorts=COM3
>>gnu.io.rxtx.ParallelPorts=null
>>
>>This allows the application to open very quickly without any errors.
>>Whomever coded this class or somebody who understands properties  
>>should
>>look at this method and make sure it is doing what they expect.
>>
>>Doug
>>
>>
>>
>>
>>Doug Thistlethwaite wrote:
>>
>>    
>>
>>>I think there is an error in the registerSpecifiedPorts() method.   
>>>When
>>>I have a gnu.io.rxtx.properties file in the ext directory, this  
>>>function
>>>kills the System class  IF I call System.getProperty("os.name")  
>>>before
>>>the call  to registerSpecifiedPorts(), it returns the os name,  
>>>after the
>>>call, it returns null.  I have not played much with properties,  
>>>except
>>>for reading them, so I don't really understand the code.
>>>
>>>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
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060602/3c0e420f/attachment-0023.html

From joachim at buechse.de  Fri Jun  2 13:46:36 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 21:46:36 +0200
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
	RXTX again
In-Reply-To: <44807ED6.8000903@sun.com>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
	<44807ED6.8000903@sun.com>
Message-ID: <6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>

Hello Paul,

of course, the basic change I suggested could be done "hidden".  The  
CommProvider interface could live somewhere in sun.xyz.*
The setCustomCommProvider method would not be in CommPortIdentifier  
but also somewhere in sun.xyz.* This would be an unofficial feature,  
the official interface stays exactly the same. However RXTX (and  
others) could access the hidden interface.

Don't get me wrong, I don't want to harass you into making changes  
you don't like (which probably wouldn't work anyway;-). But I'm a  
long time Java programmer and seeing the state of cross platform  
serial support for Java makes me feel really sad. In fact, when I  
started to look into Java serial port programming some months ago I  
was very surprised that javax.comm never made it into the JDK.

I'm sorry that I did not contribute my feedback to the JSR for  
javax.comm 3.0. However at the time I didn't do serial port  
programming in Java. I agree that a new JSR should be opened - I'm  
not an expert on JSRs or the JCP process, but from looking quickly  
over the progress of some JSRs I would be very surprised if we can  
have a new version in less then a year. In the meanwhile some people  
will start using javax.comm 3.0 (which can not be supported by RXTX),  
some will use javax.comm 2.0 (which means the 2.0.7 release of RXTX  
still needs to be maintained). This may get even worse if eg Apple  
decides to port and include javax.comm 3.0 at which point it may get  
very tricky to write a cross platform Java application.

All of this simply means, that we are loosing a lot of man-power that  
could otherwise be invested in building a clean solution and/or to  
add features that are becoming more and more important (USB events...).

In the automation / machine control universe Java makes a lot of  
sense. Right now many people are migrating to Linux or from  
propietary systems (even DOS) to Windows. Writing the control/ 
configuration applications in Java is the kings way to unify the code  
base.

Best regards,
Joachim


On 02.06.2006, at 20:09, Paul Klissner wrote:

> Joachim Buechse wrote:
>> Good day Paul!
>>
>> A clean architecture with loadable drivers and reusable code would be
>> very beneficial for the future, I think everybody agrees. However
>> this could be several years into the future. In the meantime, there
>> is a real existing problem with IO support on Java. I have the strong
>> feeling that most programmers want to code against one specification
>> (javax.comm) and be able to replace the underlying implementation via
>> a "plugin" on platforms where the SUN implementation is not
>> sufficient. RXTX could be just this plugin (reusing very close to 0%
>> of the javax.comm implementation but 100% of its API).
>>
>> I want to propose an API addition and implementation change that will
>> take less then 2 hours of manpower to implement and create a solution
>> that can bridge the years until javax.comm has been based on a new
>> architecture.
>>
>> Looking at the javax.comm api at http://java.sun.com/products/
>> javacomm/reference/api/index.html I would like to propose the  
>> following:
>>
>> The only entry point to javax.comm is CommPortIdentifier. It has 3
>> static methods plus the constructor.
>>
>> 1) define one additional Interface
>>
>> public interface CommProvider {
>>     CommPortIdentifier getPortIdentifier(CommPort port);
>>     CommPortIdentifier getPortIdentifier(String portName);
>>     Enumeration getPortIdentifiers ();
>> }
>>
>> 2) add one method to CommPortIdentifier
>>
>>    public static setCustomCommProvider (CommProvider);
>>
>> 3) change the three static methods of CommPortIdentifier to dispatch
>> to the CommProvider if it is set
>>
>> 4) change the constructor of CommPortIdentifier to
>>
>>    public CommPortIdentifier(...) {
>>       if (isProviderSet && this.getClass() ==
>> javax.comm.CommPortIdentifier) {
>>           throw new RuntimeException("illegal creation of
>> CommPortIndentifier, custom CommProvider is in use");
>>       }
>>
>> 5) (this is optional, but would be very nice) automatically set a
>> custom CommProvider if it is found on the classpath or defined via a
>> system property.
>>
>>
>> The above 1) - 4) can be implemented in less than 1hour. 5) may take
>> another hour. I agree that this is not the most elegant design, but
>> it would solve a lot of problems with very little effort. It would
>> certainly allow RXTX to move forward. If the javax.comm API needs to
>> be redesigned completely this addition will not hurt, as people will
>> move to the new API anyway and javax.comm 3.0 was so far never
>> included in the main distribution.
>>
>> Best regards,
>> Joachi
> I'm afraid modifying the interface classes isn't my call.  There was
> actually
> a TCK written and one of the tests was to ensure that the interface  
> classes
> match the spec.  Thus my hands have already been tied since this  
> project
> was essentially grandfathered into the JCP.
>
> That's why we need to open a new JSR and find someone who wants
> to be the spec lead, and go in with a new reference implementation.
> I'm not sure why it would have to take years, since this isn't  
> bleeding edge
> technology and there are only so many things that can be done with it,
> and we already have practical experience about many functional aspects
> that we could cite precedence on.
>
> As it becomes clear that the specification is being accepted  
> completely
> or by-and-large by the community, nothing would stop people from
> starting adapting to the new API (using the reference  
> implementation or
> porting it) and using it in their projects prior to it's final  
> community and
> JCP approval, since approval is required only to make it official and
> get the "100% pure java" certification for platform ports.
>
> You have one idea already.  Why don't you implement it, solicit some
> design feedback from Sun and the RXTX, and create a functional
> implementation that addresses the needs of the community, then
> we can document it and open a JSR.  That's it.  It should march  
> through
> the approval stages reasonably quickly I would imagine, and meantime
> RXTX could start using it.
>
> Paul
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From paul.klissner at sun.com  Fri Jun  2 14:38:49 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Fri, 02 Jun 2006 13:38:49 -0700
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to
 RXTX again
In-Reply-To: <6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>
References: <447FFA72.6040807@sun.com>
	<1C8DB1B6-DEB4-49E8-9EA3-B5EEC4E4BEC2@buechse.de>
	<44807ED6.8000903@sun.com>
	<6F42B09E-2586-4A67-B491-5D3673307DDD@buechse.de>
Message-ID: <4480A1D9.5060106@sun.com>

Joachim Buechse wrote:
> Hello Paul,
>
> of course, the basic change I suggested could be done "hidden".  The  
> CommProvider interface could live somewhere in sun.xyz.*
> The setCustomCommProvider method would not be in CommPortIdentifier  
> but also somewhere in sun.xyz.* This would be an unofficial feature,  
> the official interface stays exactly the same. However RXTX (and  
> others) could access the hidden interface.
>
> Don't get me wrong, I don't want to harass you into making changes  
> you don't like (which probably wouldn't work anyway;-). But I'm a  
> long time Java programmer and seeing the state of cross platform  
> serial support for Java makes me feel really sad. In fact, when I  
> started to look into Java serial port programming some months ago I  
> was very surprised that javax.comm never made it into the JDK.
>
> I'm sorry that I did not contribute my feedback to the JSR for  
> javax.comm 3.0. 
There was no JSR for 3.0, because we didn't have the resources to make 
the commitment.
Yet Sun needed to add support for platform-dependent port name mapping, 
which had to
be done 'under the hood', since the API isn't designed to handle that in 
a pluggable way.
But these quick fixes aren't the right approach, they just kick the dog 
down the road,
setting bad precedent, inviting confusion and more intractable problems 
(such as the
one plaguing us now).

My changes could have been layered better, it was a trade off between 
achieving an
ideal architecture, trying to find internal reviewers, and meet the 
needs of big customers
in a timely way.  Thus my namespace changes collided with RXTX's 
dependencies.
I was unaware of Jagane's rogue agreement made with the RXTX community 7 
years ago,
before Jagane left Sun.  I think this was a wag-the-dog situation.

Now it is time to do it right, and I don't think it is going to be as 
much trouble as people
some people fear. If RXTX wants to sponsor the JSR and seed a new spec, 
Sun can join
the Expert Group.  And we'd be largely in agreement, since we're not 
talking about
humongous changes, and looking for mutually beneficial changes. The core 
API is already
largely proved and tested.
> However at the time I didn't do serial port  
> programming in Java. I agree that a new JSR should be opened - I'm  
> not an expert on JSRs or the JCP process, but from looking quickly  
> over the progress of some JSRs I would be very surprised if we can  
> have a new version in less then a year. 
*Approved*  But that doesn't mean the spec couldn't be 99.9% stable 
before that.  Once
the delta rate declines and changes approach nil, people could start 
adapting to the API in
advance of formal approval.   It isn't going to be drawn out like 
javax.usb, which was new
technology, a very complex API, and involved precedent setting corporate 
disputes and
policy issues to resolve.

> In the meanwhile some people  
> will start using javax.comm 3.0 (which can not be supported by RXTX),  
> some will use javax.comm 2.0 (which means the 2.0.7 release of RXTX  
> still needs to be maintained). This may get even worse if eg Apple  
> decides to port and include javax.comm 3.0 at which point it may get  
> very tricky to write a cross platform Java application.
>   
The interfaces haven't changed since 1.0.  If we open a JSR ,we can 
contact Apple and
allow them to be on the E.G., if they want.  That might make the JSR a 
bit more drawn out,
but then we'd arrive ultimately arrive at a best-of-all-worlds API that 
most people would
accept, perhaps forever, and arrive at a respectable set of compromises.

-Paul

> All of this simply means, that we are loosing a lot of man-power that  
> could otherwise be invested in building a clean solution and/or to  
> add features that are becoming more and more important (USB events...).
>
> In the automation / machine control universe Java makes a lot of  
> sense. Right now many people are migrating to Linux or from  
> propietary systems (even DOS) to Windows. Writing the control/ 
> configuration applications in Java is the kings way to unify the code  
> base.
>
> Best regards,
> Joachim
>
>
> On 02.06.2006, at 20:09, Paul Klissner wrote:
>
>   
>> Joachim Buechse wrote:
>>     
>>> Good day Paul!
>>>
>>> A clean architecture with loadable drivers and reusable code would be
>>> very beneficial for the future, I think everybody agrees. However
>>> this could be several years into the future. In the meantime, there
>>> is a real existing problem with IO support on Java. I have the strong
>>> feeling that most programmers want to code against one specification
>>> (javax.comm) and be able to replace the underlying implementation via
>>> a "plugin" on platforms where the SUN implementation is not
>>> sufficient. RXTX could be just this plugin (reusing very close to 0%
>>> of the javax.comm implementation but 100% of its API).
>>>
>>> I want to propose an API addition and implementation change that will
>>> take less then 2 hours of manpower to implement and create a solution
>>> that can bridge the years until javax.comm has been based on a new
>>> architecture.
>>>
>>> Looking at the javax.comm api at http://java.sun.com/products/
>>> javacomm/reference/api/index.html I would like to propose the  
>>> following:
>>>
>>> The only entry point to javax.comm is CommPortIdentifier. It has 3
>>> static methods plus the constructor.
>>>
>>> 1) define one additional Interface
>>>
>>> public interface CommProvider {
>>>     CommPortIdentifier getPortIdentifier(CommPort port);
>>>     CommPortIdentifier getPortIdentifier(String portName);
>>>     Enumeration getPortIdentifiers ();
>>> }
>>>
>>> 2) add one method to CommPortIdentifier
>>>
>>>    public static setCustomCommProvider (CommProvider);
>>>
>>> 3) change the three static methods of CommPortIdentifier to dispatch
>>> to the CommProvider if it is set
>>>
>>> 4) change the constructor of CommPortIdentifier to
>>>
>>>    public CommPortIdentifier(...) {
>>>       if (isProviderSet && this.getClass() ==
>>> javax.comm.CommPortIdentifier) {
>>>           throw new RuntimeException("illegal creation of
>>> CommPortIndentifier, custom CommProvider is in use");
>>>       }
>>>
>>> 5) (this is optional, but would be very nice) automatically set a
>>> custom CommProvider if it is found on the classpath or defined via a
>>> system property.
>>>
>>>
>>> The above 1) - 4) can be implemented in less than 1hour. 5) may take
>>> another hour. I agree that this is not the most elegant design, but
>>> it would solve a lot of problems with very little effort. It would
>>> certainly allow RXTX to move forward. If the javax.comm API needs to
>>> be redesigned completely this addition will not hurt, as people will
>>> move to the new API anyway and javax.comm 3.0 was so far never
>>> included in the main distribution.
>>>
>>> Best regards,
>>> Joachi
>>>       
>> I'm afraid modifying the interface classes isn't my call.  There was
>> actually
>> a TCK written and one of the tests was to ensure that the interface  
>> classes
>> match the spec.  Thus my hands have already been tied since this  
>> project
>> was essentially grandfathered into the JCP.
>>
>> That's why we need to open a new JSR and find someone who wants
>> to be the spec lead, and go in with a new reference implementation.
>> I'm not sure why it would have to take years, since this isn't  
>> bleeding edge
>> technology and there are only so many things that can be done with it,
>> and we already have practical experience about many functional aspects
>> that we could cite precedence on.
>>
>> As it becomes clear that the specification is being accepted  
>> completely
>> or by-and-large by the community, nothing would stop people from
>> starting adapting to the new API (using the reference  
>> implementation or
>> porting it) and using it in their projects prior to it's final  
>> community and
>> JCP approval, since approval is required only to make it official and
>> get the "100% pure java" certification for platform ports.
>>
>> You have one idea already.  Why don't you implement it, solicit some
>> design feedback from Sun and the RXTX, and create a functional
>> implementation that addresses the needs of the community, then
>> we can document it and open a JSR.  That's it.  It should march  
>> through
>> the approval stages reasonably quickly I would imagine, and meantime
>> RXTX could start using it.
>>
>> Paul
>>
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at 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  Sat Jun  3 18:15:24 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 18:15:24 -0600 (MDT)
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
Message-ID: <Pine.LNX.4.61.0606031715100.10890@www>


The attached patch allows baud rates of 14400, 28800, 128000 and 256000.

That was my goal.

[import standard disclaimer]

But I took some time to look a little further.  I got custom baud rates 
working enough that someone (perhaps me) can properly fix them in the 
future.  Proof of concept.

As an undocumented bonus, you can toss random baudrates (say 1953), at the 
API and it will set it to something close to that on windows and linux. 
Solaris should say the baud rate is not supported but I have not tested it 
yet.  Mac OS X behavior is unknown at this point.  Just dont expect 
correct behavior at ~8192-9009 baudrates or baudrates less than 20 on 
windows; these baud rates overlap with defines in win32termios.h.  I 
conveniently closed my eyes there.  Try another value close.  On Linux, a 
baud base and divisor are guestimated and set.  On windows, we wave pixie 
dust over the kernel driver and hope.  Do not expect pixie dust and 
guestimates to be the same on windows and linux.  They may well round to 
different values in yet to be tested ways.  There are only so many 
divisors.  If it isn't working, try a little higher or lower.

In the example of 1953 for instance, there is no divisor for commodity 
hardware that comes to that baudrate.  We just come close on one side or 
the other.  If tools tell you they got 1953 exactly, the tools may be 
questionable and just reading values not directly related to the actual 
hardware settings.

These fixes have been tested on Linux and Windows while using an 
oscilloscope to confirm they change relative to known baudrates at 9600, 
14400*, 19200, 28800* (and 1800, 1953** and 2400).

* = previously unsupported.
** = still not supported but probably works from what I saw.

There could be future discussion in this area.  For now this is working 
for almost all unusual baud rate demands.  Cleaning up the custom baud 
rate should be easier with a working starting point.  Baud bases other 
than 128000 have not been characterized.  Yes.. this overlapps with two of 
the baud rates enabled.

Feedback and ideas are welcome.

--
Trent Jarvi
tjarvi at qbang.org
-------------- next part --------------
Index: SerialImp.c
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v
retrieving revision 1.46.2.187
diff -u -r1.46.2.187 SerialImp.c
--- SerialImp.c	29 Jan 2006 22:19:04 -0000	1.46.2.187
+++ SerialImp.c	3 Jun 2006 23:12:40 -0000
@@ -793,6 +793,19 @@
 		result &= ~TIOCM_DTR;
 		ioctl( fd, TIOCMSET, &result );
 	}
+	/*
+	   B38400 is a special case in Linux for custom baud rates.
+
+	   We just treat this as a custom speed for now.  If you take this ifdef
+	   out and select baud rates 38400 then 28800 then 38400, you will get
+	   a final baud rate of 28800 because you did not update the divisor.
+
+	   See the next ifdef below for the divisor.
+	*/
+#if defined(TIOCGSERIAL)
+	if ( cspeed == B38400 )
+		cspeed = 38400;
+#endif /* TIOCGSERIAL */
 	if(     cfsetispeed( &ttyset, cspeed ) < 0 ||
 		cfsetospeed( &ttyset, cspeed ) < 0 )
 	{
@@ -814,6 +827,7 @@
 		*/
 
 #if defined(TIOCGSERIAL)
+		ioctl( fd, TIOCGSERIAL, &sstruct );
 		sstruct.custom_divisor = ( sstruct.baud_base/cspeed );
 		cspeed = B38400;
 #endif /* TIOCGSERIAL */
@@ -827,7 +841,7 @@
 #if defined(TIOCSSERIAL)
 		/*  It is assumed Win32 does this for us */
 		if (	sstruct.baud_base < 1 ||
-			ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
+		ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
 		{
 			return( 1 );
 		}
Index: termios.c
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v
retrieving revision 1.9.2.56
diff -u -r1.9.2.56 termios.c
--- termios.c	16 Jan 2006 02:50:32 -0000	1.9.2.56
+++ termios.c	3 Jun 2006 23:12:40 -0000
@@ -323,8 +323,8 @@
 		case CBR_3500000:	return( B3500000 );
 		case CBR_4000000:	return( B4000000 );
 		default:
-			set_errno(EINVAL );
-			return -1;
+			/* assume custom baudrate */
+			return( Baud );
 	}
 }
 
@@ -361,12 +361,13 @@
 		case B9600:	ret = CBR_9600;		break;
 		case B14400:	ret = CBR_14400;	break;
 		case B19200:	ret = CBR_19200;	break;
+		case B28800:	ret = CBR_28800;	break;
 		case B38400:	ret = CBR_38400;	break;
 		case B57600:	ret = CBR_57600;	break;
 		case B115200:	ret = CBR_115200;	break;
 		case B128000:	ret = CBR_128000;	break;
-		case B256000: 	ret = CBR_256000;	break;
 		case B230400:	ret = CBR_230400;	break;
+		case B256000: 	ret = CBR_256000;	break;
 		case B460800:	ret = CBR_460800;	break;
 		case B500000:	ret = CBR_500000;	break;
 		case B576000:	ret = CBR_576000;	break;
@@ -381,10 +382,8 @@
 		case B4000000:	ret = CBR_4000000;	break;
 	
 		default:
-			fprintf( stderr, "B_to_CBR: invalid baudrate: %#o\n",
-				Baud );
-			set_errno( EINVAL );
-			return -1;
+			/* assume custom baudrate */
+			return Baud;
 	}
 	LEAVE( "B_to_CBR" );
 	return ret;
@@ -708,12 +707,9 @@
 	ENTER( "init_serial_struct" );
 
 	/*
-	FIXME
-
-	This needs to use inb() to read the actual baud_base
-	and divisor from the UART registers.  Question is how
-	far do we take this?
-
+	use of custom_divisor and baud_base requires access to
+	kernel space.  The kernel does try its best if you just
+	toss a baud rate at it though.
 	*/
 
 	sstruct->custom_divisor = 0;
@@ -1678,16 +1674,17 @@
 {
 	char message[80];
 	ENTER( "cfsetospeed" );
+	/* clear baudrate */
+	s_termios->c_cflag &= ~CBAUD;
 	if ( speed & ~CBAUD )
 	{
 		sprintf( message, "cfsetospeed: not speed: %#o\n", speed );
 		report( message );
-		return 0;
+		/* continue assuming its a custom baudrate */
+		s_termios->c_cflag |= B38400;  /* use 38400 during custom */
+		s_termios->c_cflag |= CBAUDEX; /* use CBAUDEX for custom */
 	}
-	s_termios->c_ispeed = s_termios->c_ospeed = speed;
-	/* clear baudrate */
-	s_termios->c_cflag &= ~CBAUD;
-	if( speed )
+	else if( speed )
 	{
 		s_termios->c_cflag |= speed;
 	}
@@ -1696,6 +1693,7 @@
 		/* PC blows up with speed 0 handled in Java */
 		s_termios->c_cflag |= B9600;
 	}
+	s_termios->c_ispeed = s_termios->c_ospeed = speed;
 	LEAVE( "cfsetospeed" );
 	return 1;
 }
@@ -1767,25 +1765,6 @@
 }
 
 /*----------------------------------------------------------
-serial_struct_to_DCB()
-
-   accept:      
-   perform:     
-   return:      
-   exceptions:  
-   win32api:     None
-   comments:    
-----------------------------------------------------------*/
-int serial_struct_to_DCB( struct serial_struct *sstruct, DCB *dcb )
-{
-	/* 5 Baud rate fix
-	sstruct.baud_base
-	sstruct.custom_divisor = ( sstruct.baud_base/cspeed );
-	*/
-	return(0);
-}
-
-/*----------------------------------------------------------
 termios_to_DCB()
 
    accept:      
@@ -1798,7 +1777,8 @@
 int termios_to_DCB( struct termios *s_termios, DCB *dcb )
 {
 	ENTER( "termios_to_DCB" );
-	s_termios->c_ispeed = s_termios->c_ospeed = s_termios->c_cflag & CBAUD;
+	if ( !(s_termios->c_cflag & CBAUDEX) )
+		s_termios->c_ispeed = s_termios->c_ospeed = s_termios->c_cflag & CBAUD;
 	dcb->BaudRate        = B_to_CBR( s_termios->c_ispeed );
 	dcb->ByteSize = termios_to_bytesize( s_termios->c_cflag );
 
@@ -2863,11 +2843,6 @@
 			GetCommState( index->hComm, dcb );
 
 			index->sstruct = va_arg( ap, struct serial_struct * );
-			if ( serial_struct_to_DCB( index->sstruct, dcb ) < 0 )
-			{
-				va_end( ap );
-				return -1;
-			}
 
 			report( "TIOCSSERIAL\n" );
 			free(dcb);
Index: win32termios.h
===================================================================
RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v
retrieving revision 1.5.2.28
diff -u -r1.5.2.28 win32termios.h
--- win32termios.h	30 Jun 2005 20:23:26 -0000	1.5.2.28
+++ win32termios.h	3 Jun 2006 23:12:40 -0000
@@ -279,7 +279,7 @@
 #define XTABS	01000000 /* Hmm.. Linux/i386 considers this part of TABDLY.. */
 
 /* c_cflag bit meaning */
-# define CBAUD	0010017
+#define  CBAUD  0030017
 #define  B0	0000000		/* hang up */
 #define  B50	0000001
 #define  B75	0000002
@@ -312,13 +312,16 @@
 #define  B3500000 0010016
 #define  B4000000 0010017
 
-/* glue for unsupported linux speeds see also SerialImp.h */
-/* hosed */
-
-#define B14400		1010001
-#define B28800		1010002
-#define B128000		1010003
-#define B256000		1010004
+/*
+	glue for unsupported linux speeds see also SerialImp.h 
+	custom baud rates around 8192-9000 will not work because
+	of these.
+*/
+
+#define B14400		0020001
+#define B28800		0020002
+#define B128000		0020003
+#define B256000		0020004
 
 #define EXTA B19200
 #define EXTB B38400
@@ -356,8 +359,10 @@
 
 /* glue for unsupported windows speeds */
 
-#define CBR_230400	230400
 #define CBR_28800	28800
+#define CBR_128000	128000
+#define CBR_230400	230400
+#define CBR_256000	256000
 #define CBR_460800	460800
 #define CBR_500000	500000
 #define CBR_576000	576000

From impakt01 at optusnet.com.au  Sat Jun  3 18:30:37 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 10:30:37 +1000
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
In-Reply-To: <Pine.LNX.4.61.0606031715100.10890@www>
Message-ID: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>

Hi Trent,
I'd love to try the patch but I can't get the latest build compiling, only
pre16. 

Can you attach the rxtxSerial.dll file with this patch?

Also, I hardcoded 1953 in a couple more places last night on pre16 and it
managed to open the port at the right speed, but stopped receiving anything
after 100-150 bytes, even though more data was getting sent to the port.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 10:15 AM
To: rxtx at qbang.org
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.


The attached patch allows baud rates of 14400, 28800, 128000 and 256000.

That was my goal.

[import standard disclaimer]

But I took some time to look a little further.  I got custom baud rates 
working enough that someone (perhaps me) can properly fix them in the 
future.  Proof of concept.

As an undocumented bonus, you can toss random baudrates (say 1953), at the 
API and it will set it to something close to that on windows and linux. 
Solaris should say the baud rate is not supported but I have not tested it 
yet.  Mac OS X behavior is unknown at this point.  Just dont expect 
correct behavior at ~8192-9009 baudrates or baudrates less than 20 on 
windows; these baud rates overlap with defines in win32termios.h.  I 
conveniently closed my eyes there.  Try another value close.  On Linux, a 
baud base and divisor are guestimated and set.  On windows, we wave pixie 
dust over the kernel driver and hope.  Do not expect pixie dust and 
guestimates to be the same on windows and linux.  They may well round to 
different values in yet to be tested ways.  There are only so many 
divisors.  If it isn't working, try a little higher or lower.

In the example of 1953 for instance, there is no divisor for commodity 
hardware that comes to that baudrate.  We just come close on one side or 
the other.  If tools tell you they got 1953 exactly, the tools may be 
questionable and just reading values not directly related to the actual 
hardware settings.

These fixes have been tested on Linux and Windows while using an 
oscilloscope to confirm they change relative to known baudrates at 9600, 
14400*, 19200, 28800* (and 1800, 1953** and 2400).

* = previously unsupported.
** = still not supported but probably works from what I saw.

There could be future discussion in this area.  For now this is working 
for almost all unusual baud rate demands.  Cleaning up the custom baud 
rate should be easier with a working starting point.  Baud bases other 
than 128000 have not been characterized.  Yes.. this overlapps with two of 
the baud rates enabled.

Feedback and ideas are welcome.

--
Trent Jarvi
tjarvi at qbang.org



From tjarvi at qbang.org  Sat Jun  3 19:05:11 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 19:05:11 -0600 (MDT)
Subject: [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged.
In-Reply-To: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>
References: <200606040030.k540Ul6M013677@mail20.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606031840400.10890@www>

On Sun, 4 Jun 2006, Daren wrote:

> Hi Trent,
> I'd love to try the patch but I can't get the latest build compiling, only
> pre16.
>
> Can you attach the rxtxSerial.dll file with this patch?
>
> Also, I hardcoded 1953 in a couple more places last night on pre16 and it
> managed to open the port at the right speed, but stopped receiving anything
> after 100-150 bytes, even though more data was getting sent to the port.
>


ftp://ftp.qbang.org/pub/rxtx/rxtx-2.1-8-testing

I dont think they will hang.  But I was just testing via loopback/break 
out box/scope.

I'll be putting about 10 patches and another set of binaries in that 
directory shortly.  For now the binaries should just have the baud_rate 
fix.

I'll announce all the patches at once.  but wont be releasing 2.1-8 right 
away.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Sat Jun  3 21:00:01 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 21:00:01 -0600 (MDT)
Subject: [Rxtx] CVS for 2.1 should have everything
Message-ID: <Pine.LNX.4.61.0606032056190.10890@www>


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org


From impakt01 at optusnet.com.au  Sat Jun  3 21:08:14 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 13:08:14 +1000
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <Pine.LNX.4.61.0606032056190.10890@www>
Message-ID: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>

Hi Trent,
I tried the latest dll and it opens the port, receives 100-200 bytes and
then stops receiving anything else..

I'll keep playing with it.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 1:00 PM
To: rxtx at qbang.org
Subject: [Rxtx] CVS for 2.1 should have everything


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From impakt01 at optusnet.com.au  Sat Jun  3 21:22:41 2006
From: impakt01 at optusnet.com.au (Daren)
Date: Sun, 4 Jun 2006 13:22:41 +1000
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
Message-ID: <200606040322.k543MqW1008455@mail12.syd.optusnet.com.au>

Played with it, problem, with a while loop in my code, working great now

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Daren
Sent: Sunday, 4 June 2006 1:08 PM
To: 'RXTX Developers and Users'
Subject: Re: [Rxtx] CVS for 2.1 should have everything

Hi Trent,
I tried the latest dll and it opens the port, receives 100-200 bytes and
then stops receiving anything else..

I'll keep playing with it.

Daren

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Trent Jarvi
Sent: Sunday, 4 June 2006 1:00 PM
To: rxtx at qbang.org
Subject: [Rxtx] CVS for 2.1 should have everything


Developers:

You may want to check to see that your favorite fix is in.  I'll post a 
list and finish credits in the morning.

The patches have been applied one at a time and commited.

If you have something in the queue, please let me know.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Sat Jun  3 21:35:41 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 3 Jun 2006 21:35:41 -0600 (MDT)
Subject: [Rxtx] CVS for 2.1 should have everything
In-Reply-To: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
References: <200606040308.k5438PMA004982@mail30.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606032131140.10890@www>

On Sun, 4 Jun 2006, Daren wrote:

> Hi Trent,
> I tried the latest dll and it opens the port, receives 100-200 bytes and
> then stops receiving anything else..
>
> I'll keep playing with it.
>
> Daren

The difference may be that I'm talking to something at the exact same baud 
rate (loopback).

You may also try setting the baudrate to ~1933 and ~1973 to force the 
guesses one way or the other.  If you are on windows, we are not doing 
anything fancy in the end.  Thats the kernel guessing.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sun Jun  4 04:12:09 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sun, 4 Jun 2006 12:12:09 +0200
Subject: [Rxtx] Update of OSX installer, Readme, etc
Message-ID: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>

Good day,

after the latest changes a lot of OS X specific files should be  
updated. Especially the installer!

- The "MaxOSX" readme file on the root level is outdated (ie  
CodeWarrior information). Maybe we could even rename it to README.OSX  
to be in line with README.IPAQ, README.SCO (Trent do you mind copying/ 
renaming ,v files in the repository?).

- The lock files are no longer used and hence the user group magic  
and lock folder creation should be removed from the installer.

- MACOSX_IDE/ForPackageMaker/Resources/ReadMe.rtf and Welcome.rtf  
need to be updated.

- I suggest to replace the current installation instruction for OS X:  
Installation should occur into the application directory, not in the  
Java-VM directory. This simplifies things a lot, as the Mac Installer  
can be removed completely.

- The xcodeproject's build settings need to be updated to generate  
JAVA 1.1 format class files.


Dimitry: do you have time to tackle this? I could do it, but as this  
is "your baby" I thought you may prefer to do it yourself.

Regards,
Joachim



From dmarkman at mac.com  Sun Jun  4 11:27:53 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Sun, 4 Jun 2006 13:27:53 -0400
Subject: [Rxtx] Update of OSX installer, Readme, etc
In-Reply-To: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
References: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
Message-ID: <26E7A202-962B-4C19-93B6-29426C467249@mac.com>

Joachim,
unfortunately I don't have time right now to do that
so if you can do that, please do

it's not only my baby
it's yours too :-)

thanks


On Jun 4, 2006, at 6:12 AM, Joachim Buechse wrote:

> Good day,
>
> after the latest changes a lot of OS X specific files should be
> updated. Especially the installer!
>
> - The "MaxOSX" readme file on the root level is outdated (ie
> CodeWarrior information). Maybe we could even rename it to README.OSX
> to be in line with README.IPAQ, README.SCO (Trent do you mind copying/
> renaming ,v files in the repository?).
>
> - The lock files are no longer used and hence the user group magic
> and lock folder creation should be removed from the installer.
>
> - MACOSX_IDE/ForPackageMaker/Resources/ReadMe.rtf and Welcome.rtf
> need to be updated.
>
> - I suggest to replace the current installation instruction for OS X:
> Installation should occur into the application directory, not in the
> Java-VM directory. This simplifies things a lot, as the Mac Installer
> can be removed completely.
>
> - The xcodeproject's build settings need to be updated to generate
> JAVA 1.1 format class files.
>
>
> Dimitry: do you have time to tackle this? I could do it, but as this
> is "your baby" I thought you may prefer to do it yourself.
>
> Regards,
> Joachim
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman



From tjarvi at qbang.org  Sun Jun  4 13:54:02 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 4 Jun 2006 13:54:02 -0600 (MDT)
Subject: [Rxtx] Update of OSX installer, Readme, etc
In-Reply-To: <26E7A202-962B-4C19-93B6-29426C467249@mac.com>
References: <C2A059E1-34CF-4EC1-B41C-58FD01C56DB6@buechse.de>
	<26E7A202-962B-4C19-93B6-29426C467249@mac.com>
Message-ID: <Pine.LNX.4.61.0606041353040.22522@www>

On Sun, 4 Jun 2006, Dmitry Markman wrote:

> Joachim,
> unfortunately I don't have time right now to do that
> so if you can do that, please do
>
> it's not only my baby
> it's yours too :-)
>

I've given Joachim cvs access.  He has shown good work in bugzilla.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Mon Jun  5 10:08:32 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 5 Jun 2006 18:08:32 +0200
Subject: [Rxtx] Build process changes for Mac OS X
Message-ID: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>

Good day,

I have cleaned up some outdated Mac OSX specific build files in the  
repository.

There was not a lot left of the readme file "MacOSX" after cleaning  
it up, so I decided to rename it README.OSX to be in harmony with the  
other files in the directory (ie README.IPAQ, README.SCO, ...)

I added an (uncompressed) XCode 2.3 project file/structure  
with .cvsignore files that will ignore the user specific settings.  
This should work "out of the box" for OSX10.4. Users of 10.2/10.3 may  
have to switch the build settings.

[It's kind of tricky to choose "the right" setting. Afaik there is no  
way to compile a universal binary that will work on 10.3 or before.  
So it's either UniversalBinary OR Legacy. Maybe we should have  
different build targets for these different targets?? I would like to  
get some feedback from the Mac developers on this list regarding the  
subject].

Besides other things the OSX installer is no longer required. Since  
the next version (2.1.8) will no longer use lockfiles on OSX, the  
group/permission magic is no longer required and hence there remains  
basicly no work for the installer - other than copying 2 files to the  
VM extension directory. Then again, this is not the best way to  
install RXTX. So I removed the installer completely without modifying  
it, this should simplify a "resurrection" should it ever get necessary.

I had problems with the (compressed, ie sit.hqx) legacy project files  
on the latest installation of OSX (javac 1.5 creating non JDK1.1  
class files and some minor problems). To reduce potential confusion  
for newcomers I decided to remove them. This means that there is no  
longer a simple way to build RXTX for OSX 10.0 and 10.1 (I deeply  
apologize if anyone still relied on this ... well the files are in  
the Attiq).

Best regards,
Joachim


From joachim at buechse.de  Mon Jun  5 10:16:37 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 5 Jun 2006 18:16:37 +0200
Subject: [Rxtx] RXTX and lockfiles on OSX [it is fixed now]
Message-ID: <7D2C4418-9397-4B59-8091-9FDE4ED67836@buechse.de>

Quite a number of people contacted me in the last couple of weeks  
because of problems installing RXTX on OSX. I told you to wait for  
the "official" fix. Well, it has been fixed.

So if you were among the people waiting for the solution, you can now  
download the source rxtx-2.1-7r2.zip from the website. Once unpacked  
dont forget to use "cvs up" to update the files to the latest  
version. You can then open MACOSX_IDE/XCode/ 
LibSerialUniversal.xcodeproj with XCode 2.3 and build the libraries  
that no longer try to create lock files.

Regards,
Joachim


From brian at mbari.org  Mon Jun  5 10:52:43 2006
From: brian at mbari.org (Brian Schlining)
Date: Mon, 5 Jun 2006 09:52:43 -0700
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
Message-ID: <78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>

Hi Joachim,

> [It's kind of tricky to choose "the right" setting. Afaik there is no
> way to compile a universal binary that will work on 10.3 or before.
> So it's either UniversalBinary OR Legacy. Maybe we should have
> different build targets for these different targets?? I would like to
> get some feedback from the Mac developers on this list regarding the
> subject].

I imagine most developers will be compiling on 10.4 (It's the nature  
of the coder...gotta have the latest and greatest) and deploying to  
both 10.3 and 10.4; both of which will run Universal Binaries (see  
http://forums.macrumors.com/showthread.php?t=205348). So it sounds  
like you've covered the majority of users. Still, you know someone's  
going to pipe up about needing RXTX on 10.2 so it would be nice to  
have a target to make a PPC only build.

Just my 2 cents

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/1cac8c39/attachment-0023.html

From dmarkman at mac.com  Mon Jun  5 13:47:50 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Mon, 5 Jun 2006 15:47:50 -0400
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
Message-ID: <686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>

I don't think it will be a problem to run universal binary
on 10.2
however if binary has some calls that aren't implemented in 10.2
then you'll have a problem


On Jun 5, 2006, at 12:52 PM, Brian Schlining wrote:

> Hi Joachim,
>
>> [It's kind of tricky to choose "the right" setting. Afaik there is no
>> way to compile a universal binary that will work on 10.3 or before.
>> So it's either UniversalBinary OR Legacy. Maybe we should have
>> different build targets for these different targets?? I would like to
>> get some feedback from the Mac developers on this list regarding the
>> subject].
>
> I imagine most developers will be compiling on 10.4 (It's the  
> nature of the coder...gotta have the latest and greatest) and  
> deploying to both 10.3 and 10.4; both of which will run Universal  
> Binaries (see http://forums.macrumors.com/showthread.php?t=205348).  
> So it sounds like you've covered the majority of users. Still, you  
> know someone's going to pipe up about needing RXTX on 10.2 so it  
> would be nice to have a target to make a PPC only build.
>
> Just my 2 cents
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/9fafc878/attachment-0023.html

From brian at mbari.org  Mon Jun  5 14:52:41 2006
From: brian at mbari.org (Brian Schlining)
Date: Mon, 5 Jun 2006 13:52:41 -0700
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
Message-ID: <E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>

Hi Dmitry,

> I don't think it will be a problem to run universal binary
> on 10.2
> however if binary has some calls that aren't implemented in 10.2
> then you'll have a problem

You're right...I stand corrected.

Note however, to deploy a universal binary to 10.2 RXTX will need to  
use the 10.2 SDK to build the PPC side. (see http:// 
developer.apple.com/documentation/DeveloperTools/Conceptual/ 
cross_development/UniversalBinaries/chapter_4_section_1.html). I  
haven't been paying close attention to the new locking mechanism used  
by RXTX on the Mac...does 10.2 support it?

Joachim, which SDK will you be using by default for building the Mac  
PPC binaries?

>> Hi Joachim,
>>
>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>> is no
>>> way to compile a universal binary that will work on 10.3 or before.
>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>> different build targets for these different targets?? I would  
>>> like to
>>> get some feedback from the Mac developers on this list regarding the
>>> subject].
>>
>> I imagine most developers will be compiling on 10.4 (It's the  
>> nature of the coder...gotta have the latest and greatest) and  
>> deploying to both 10.3 and 10.4; both of which will run Universal  
>> Binaries (see http://forums.macrumors.com/showthread.php? 
>> t=205348). So it sounds like you've covered the majority of users.  
>> Still, you know someone's going to pipe up about needing RXTX on  
>> 10.2 so it would be nice to have a target to make a PPC only build.

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/153bf50e/attachment-0023.html

From dmarkman at mac.com  Mon Jun  5 19:02:04 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Mon, 5 Jun 2006 21:02:04 -0400
Subject: [Rxtx] Build process changes for Mac OS X
In-Reply-To: <E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
Message-ID: <7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>

if Joachim didn't change xcode project setting

/Developer/SDKs/MacOSX10.4u.sdk is used to build universal binary

so it's quite possible that it won't run properly on 10.2

so we have to change the building process, so ppc part will be built
with
/Developer/SDKs/MacOSX10.2.8.sdk

and finally to use lipo utility to build universal binaries

Joachim, did you use some specific locking API that wasn't implemented

in MacOSX10.2.8.sdk?

thanks


On Jun 5, 2006, at 4:52 PM, Brian Schlining wrote:

> Hi Dmitry,
>
>> I don't think it will be a problem to run universal binary
>> on 10.2
>> however if binary has some calls that aren't implemented in 10.2
>> then you'll have a problem
>
> You're right...I stand corrected.
>
> Note however, to deploy a universal binary to 10.2 RXTX will need  
> to use the 10.2 SDK to build the PPC side. (see http:// 
> developer.apple.com/documentation/DeveloperTools/Conceptual/ 
> cross_development/UniversalBinaries/chapter_4_section_1.html). I  
> haven't been paying close attention to the new locking mechanism  
> used by RXTX on the Mac...does 10.2 support it?
>
> Joachim, which SDK will you be using by default for building the  
> Mac PPC binaries?
>
>>> Hi Joachim,
>>>
>>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>>> is no
>>>> way to compile a universal binary that will work on 10.3 or before.
>>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>>> different build targets for these different targets?? I would  
>>>> like to
>>>> get some feedback from the Mac developers on this list regarding  
>>>> the
>>>> subject].
>>>
>>> I imagine most developers will be compiling on 10.4 (It's the  
>>> nature of the coder...gotta have the latest and greatest) and  
>>> deploying to both 10.3 and 10.4; both of which will run Universal  
>>> Binaries (see http://forums.macrumors.com/showthread.php? 
>>> t=205348). So it sounds like you've covered the majority of  
>>> users. Still, you know someone's going to pipe up about needing  
>>> RXTX on 10.2 so it would be nice to have a target to make a PPC  
>>> only build.
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060605/84790f80/attachment-0023.html

From joachim at buechse.de  Tue Jun  6 02:40:47 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 6 Jun 2006 10:40:47 +0200
Subject: [Rxtx] Building on OS X, Impl Changes
In-Reply-To: <7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
Message-ID: <CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>

Good day!

What's in the XCode project setting?
----------

The xcode project remained pretty much the same as before. I excluded  
the user specific files from CVS and changed some settings. I kept  
all the built targets (you shouldn't change what you don't understand;-)

Currently we the following build targets:
    RXTXComm (java files)
    librxtxParallel.jnilib (usefull on the Mac???)
    libI2C.jnilib (not yet working in RXTX)
    libRS485.jnilib (not yet working in RXTX)
    librxtxSerial.jnilib (1)
    librxtxSerial.jnilib Dynamic (2)
    rxtxSerial (3)
We also have the following build configurations for each target:
    Development
    Default
    Deployment

What was changed in the xcode project from previous versions:
- java.souce=1.3 and java.target=1.1 in RXTXComm settings
- removed copying of build products into installer directory
- removed "(Upgraded)" from build target names

What remains to be changed:
- choosing a "non-debug" Build-configuration as default
- potentially removing "Default"/"Development" Build-configurations
- reducing the number of build targets
- creating 10.2 compatible universal binaries

I suggest, that the build configurations should be reduced to 2  
(Debug/Deployment), possibly even 1 (Debug).
I have not yet found the deeper meaning of the build targets(1)(2) 
(3), it seems to me like they should be reduced into one "doing the  
right thing" or maybe into two "rxtxSerial.jnilib Legacy" (back to  
10.2, universal if possible) and "rxtxSerial.jnilib 10.4 
+" (universal, 10.4+).

Should the code work on 10.2?
----------

Absolutely. The code should work on NextStep, in fact on any BSD  
unix. I would go as far as saying, this code should work on any  
POSSIX based unix. All that was added is the call "ioctl(fd,  
TIOCEXCL)" to request excusivity of the port:

http://gemma.apple.com/documentation/DeviceDrivers/Conceptual/ 
WorkingWSerial/WWSerial_SerialDevs/chapter_2_section_8.html

It is not yet "the perfect solution". Normally an open /dev/tty  
(listen for incomming connection) should be "preemptable" by opening  
a /dev/cu (outgoing connection) for the same port. This is not yet  
implemented as it needs calls outside of POSSIX on OSX.

On "classic" systems (like NextStep) this worked based on the  
"carried detect line". open() on /dev/tty.xxx would block until the  
carrier detect signal was raised. As the device was not "opened"  
opening /dev/cu.xxx worked without a hitch. When they ported to the  
Mac this broke. On Macs the "carier detect" is usually not wired.  
Furthermore FAX modems did no longer raise the line. So the OSX  
implementor defined a new call, which is documented here:

http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00045.html

Best regards,
Joachim




On 06.06.2006, at 03:02, Dmitry Markman wrote:

> if Joachim didn't change xcode project setting
>
> /Developer/SDKs/MacOSX10.4u.sdk is used to build universal binary
>
> so it's quite possible that it won't run properly on 10.2
>
> so we have to change the building process, so ppc part will be built
> with
> /Developer/SDKs/MacOSX10.2.8.sdk
>
> and finally to use lipo utility to build universal binaries
>
> Joachim, did you use some specific locking API that wasn't implemented
>
> in MacOSX10.2.8.sdk?
>
> thanks
>
>
> On Jun 5, 2006, at 4:52 PM, Brian Schlining wrote:
>
>> Hi Dmitry,
>>
>>> I don't think it will be a problem to run universal binary
>>> on 10.2
>>> however if binary has some calls that aren't implemented in 10.2
>>> then you'll have a problem
>>
>> You're right...I stand corrected.
>>
>> Note however, to deploy a universal binary to 10.2 RXTX will need  
>> to use the 10.2 SDK to build the PPC side. (see http:// 
>> developer.apple.com/documentation/DeveloperTools/Conceptual/ 
>> cross_development/UniversalBinaries/chapter_4_section_1.html). I  
>> haven't been paying close attention to the new locking mechanism  
>> used by RXTX on the Mac...does 10.2 support it?
>>
>> Joachim, which SDK will you be using by default for building the  
>> Mac PPC binaries?
>>
>>>> Hi Joachim,
>>>>
>>>>> [It's kind of tricky to choose "the right" setting. Afaik there  
>>>>> is no
>>>>> way to compile a universal binary that will work on 10.3 or  
>>>>> before.
>>>>> So it's either UniversalBinary OR Legacy. Maybe we should have
>>>>> different build targets for these different targets?? I would  
>>>>> like to
>>>>> get some feedback from the Mac developers on this list  
>>>>> regarding the
>>>>> subject].
>>>>
>>>> I imagine most developers will be compiling on 10.4 (It's the  
>>>> nature of the coder...gotta have the latest and greatest) and  
>>>> deploying to both 10.3 and 10.4; both of which will run  
>>>> Universal Binaries (see http://forums.macrumors.com/ 
>>>> showthread.php?t=205348). So it sounds like you've covered the  
>>>> majority of users. Still, you know someone's going to pipe up  
>>>> about needing RXTX on 10.2 so it would be nice to have a target  
>>>> to make a PPC only build.
>>
>> Brian Schlining
>> Software Engineer
>> http://www.mbari.org
>>
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> Dmitry Markman
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Tue Jun  6 07:01:06 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 6 Jun 2006 15:01:06 +0200
Subject: [Rxtx] Serial port code for OS X, future steps
In-Reply-To: <CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
	<CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
Message-ID: <8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>

I posted the "wrong link". There is a correction here:

    http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00059.html

In fact, the 2.1.7 implementation of RXTX has quite some deficiencies  
on OSX. I have tried to supply some patches that don't interfere to  
much with the existing RXTX code base, but there are limits to what  
can be done with local patches.

There are some very intrusive changes that should be done. Ie proper  
mapping of /dev/tty <-> /dev/cu handling to correct behaviour of  
CommPortOwnershipListener (http://java.sun.com/products/javacomm/ 
reference/api/index.html). I dont think this can be done with  
patches. Hence I think, RXTX should be rewritten from scratch de- 
unifying the native code base (and implementing thread safe code on  
the Java side).


How "should" /dev/tty vs /dev/cu be implemented?

=====
The Unix contract is this: An open /dev/tty.xxx port (incomming)  
should be interrupted/auto-closed when opening /dev/cu.xxx (outgoing)  
[if /dev/tty.xxx is not currently handling a communication].  /dev/ 
cu.xxx and /dev/tty.xxx refer to the same device, so owning  
"exclusively" should block both. This should be respected across all  
applications native or Java.

This contract is realizable on OSX with the existing javax.comm  
interface while also respecting (to the biggest part) the contract  
defined by javax.comm.PortOwnershipListener.

The one point where the suggested implementation "breaks" the  
javax.comm contract, is by the fact that one can loose a /dev/tty  
port without calling close. However, the only option I see is to  
always open serial ports "non-exclusively" which would outrule Java  
as a platform for (dormant) applications waiting for incoming  
connections/faxes/etc. There could be a system property to choose the  
intended behavior.
=====

Here is how it could be done on OSX:

Calling port=ComportIdentifier.open("/dev/cu.xxx") opens and owns the  
port exclusively until port.close() is called.
- Java applications listening with a PortOwnershipListener should get  
a PORT_OWNED event reasonably soon.
- Any further attempt by a Java or native application to open "/dev/ 
cu.xxx" or "/dev/tty.xxx" fails.
- /dev/cu.xxx is for "outgoing" connections, so receiving  
PORT_OWNERSHIP_REQUESTED makes little to no sense. With native  
applications it can not be implemented. For Java applications it  
could be implemented (by a hidden communication channel). I think  
it's not worth bothering. If anyone is willing to give up a port to  
others he should use /dev/tty.xxx instead of /dev/cu.xxx.

Registering a PortOwnershipListener on "/dev/cu.xxx" without opening  
it, uses /dev/tty.xxx (native open()) non-exclusively and polls its  
state. PORT_OWNED and PORT_UNOWNED can be produced.

Calling port=ComportIdentifier.open("/dev/tty.xxx") should open the  
port non-exclusively.
- Adding a SerialPortEventListener and reading from the port could be  
allowed while keeping it non-exclusive.
- When port.getOutputStream() is called, the state should be changed  
to an "exclusive" ownership. This may be configurable via a system  
property.
- To return to the non-exclusive state the port must be closed and  
reopened.
- While non-exclusively opened, opening the corresponding /dev/cu.xxx  
produces a PORT_OWNERSHIP_REQUESTED event. Which should be responded  
by closing the port from within the callback (as described in  
java.comm.PortOwnershipListener). If there is a pending read, it will  
return after the listener finishes (with -1 or "0 bytes read").
- Calling write() on the /dev/tty.xxx after somebody opened /dev/ 
cu.xxx will fail with a descriptive IOException.
- Calling read() on the /dev/tty.xxx after somebody opened /dev/ 
cu.xxx will fail with a descriptive IOException (or potentially  
block, see side notes below).

CommPortIdentifier.getCurrentOwner() can be implemented by an  
external call to lsof.

CommPortIdentifier.isCurrentlyOwned() can be implemented by trying an  
open on the /dev/tty.
- It returns true if the port is currently held "exclusively".
- Whether it should also return true on /dev/tty if /dev/tty is  
already opened non-exclusively might be a system property option. In  
general, having several applications waiting for incoming connections  
on the same port will require an application level "arbitration"  
protocol...

[[side note1: One interesting question is, what happens if the  
process holding /dev/tty non-exclusively ignores  
PORT_OWNERSHIP_REQUESTED. Ie after "loosing" a non-exclusively opened  
"dev/tty.xxx" port to another process. One possible implementation  
is, that the port is "regained" when the other process gives up the  
port. This would mean that in the meanwhile read() returns no data,  
and any changes to the configuration of the port are stored but not  
forwarded. I guess, the safe (and simple) way to do this is to make  
the close() mandatory (ie setting the port into an "awaiting_close"  
state which produces IOExceptions to any other call than close). ]]

[[side note2:  Another interesting question is, what should happen if  
several applications open the same /dev/tty.xxx port "non- 
exclusively" and start to change the settings of the device.]]

Regards,
Joachim



On 06.06.2006, at 10:40, Joachim Buechse wrote:

> Should the code work on 10.2?
> ----------
>
> Absolutely. The code should work on NextStep, in fact on any BSD
> unix. I would go as far as saying, this code should work on any
> POSSIX based unix. All that was added is the call "ioctl(fd,
> TIOCEXCL)" to request excusivity of the port:
>
> http://gemma.apple.com/documentation/DeviceDrivers/Conceptual/
> WorkingWSerial/WWSerial_SerialDevs/chapter_2_section_8.html
>
> It is not yet "the perfect solution". Normally an open /dev/tty
> (listen for incomming connection) should be "preemptable" by opening
> a /dev/cu (outgoing connection) for the same port. This is not yet
> implemented as it needs calls outside of POSSIX on OSX.
>
> On "classic" systems (like NextStep) this worked based on the
> "carried detect line". open() on /dev/tty.xxx would block until the
> carrier detect signal was raised. As the device was not "opened"
> opening /dev/cu.xxx worked without a hitch. When they ported to the
> Mac this broke. On Macs the "carier detect" is usually not wired.
> Furthermore FAX modems did no longer raise the line. So the OSX
> implementor defined a new call, which is documented here:
>
> http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00045.html
>
> Best regards,
> Joachim



From sds at dcs.gla.ac.uk  Tue Jun  6 11:22:45 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Tue, 06 Jun 2006 18:22:45 +0100
Subject: [Rxtx] Correct compile flag for HP iPAQ hx4700 running Familiar
	Linux?
Message-ID: <1149614565.19496.10.camel@addu>

Hi,

I'd like to use RXTX 2.1 on my HP iPAQ hx4700. The iPAQ is running
Familiar Linux 0.8.2 (as I recall), with Blackdown Java 1.3.1.

I can compile and run a test program which uses RXTX on my i686 machine,
and it works fine. But I can't seem to get things working quite right on
my PDA.

I compile the code on the laptop with the following commands:
	./configure --host=arm-gnu-linux && make
... as suggested in a post to this list, albeit some time ago. This
compiles, I transfer the files, set up LD_LIBRARY_PATH and CLASSPATH
variables, and get the following error on the PDA:

sds at ipaq-pxa-2:~# java Test
java.lang.UnsatisfiedLinkError: /usr/local/lib/ext/librxtxSerial.so: /usr/local/lib/ext/librxtxSerial.so: cannot open shared object file: No such file or directory thrown while loading gnu.io.RXTXCommDriver
Exception in thread "main"
java.lang.UnsatisfiedLinkError: /usr/local/lib/ext/librxtxSerial.so: /usr/local/lib/ext/librxtxSerial.so: cannot open shared object file: No such file or directory
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1382)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1290)
        at java.lang.Runtime.loadLibrary0(Runtime.java:749)
        at java.lang.System.loadLibrary(System.java:820)
        at
gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:83)
        at Test.<init>(Test.java:9)
        at Test.main(Test.java:32)
sds at ipaq-pxa-2:~# 

Note that I'm copying the files to /usr/local/lib/ext/ along with the
RXTXcomm.jar file, purely to keep things separate from the rest of the
system while testing. The location of the .so files doesn't seem to have
any bearing on whether "java Test" will succeed or not. The contents of
this directory are:

sds at ipaq-pxa-2:~$ ls /usr/local/lib/ext/
RXTXcomm.jar              librxtxParallel-2.1-7.so  librxtxRS485.so
librxtxSerial-2.1-7.so
librxtxI2C-2.1-7.so       librxtxParallel.so        librxtxRaw-2.1-7.so
librxtxSerial.so
librxtxI2C.so             librxtxRS485-2.1-7.so     librxtxRaw.so
sds at ipaq-pxa-2:~$

Test.java fails on the first real line of code I'm using to test that
things are working, prior to real development, and was carefully pinched
from the web:
Enumeration portIdentifiers = CommPortIdentifier.getPortIdentifiers();


I assume that I've gotten my --host flag wrong way back up there at
the ./configure step. But if that's the case, what should I set it to?
Or am I missing something more obvious?


Cheers,
Stephen Strowes,
University of Glasgow.




From tjarvi at qbang.org  Tue Jun  6 13:39:41 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 6 Jun 2006 13:39:41 -0600 (MDT)
Subject: [Rxtx] Serial port code for OS X, future steps
In-Reply-To: <8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>
References: <A87AC6B8-E9AE-4901-94B0-405FAD0A06B8@buechse.de>
	<78B9ECC2-B690-47F9-9AD0-7D7F4D4B6713@mbari.org>
	<686F8B08-BE4A-4784-8925-EA21AB1F238D@mac.com>
	<E2459E14-AF3F-455D-9B77-8E81FE2C7155@mbari.org>
	<7BA19B93-6246-4875-9F85-6DE294A172EF@mac.com>
	<CA622711-B384-4CDD-BCB5-B6B42CBB0D3C@buechse.de>
	<8176D2EE-5459-4CB7-ABB3-A8A5089A9668@buechse.de>
Message-ID: <Pine.LNX.4.61.0606061315070.9856@www>


>>
There are some very intrusive changes that should be done. Ie proper
mapping of /dev/tty <-> /dev/cu handling to correct behaviour of
CommPortOwnershipListener (http://java.sun.com/products/javacomm/
reference/api/index.html). I dont think this can be done with
patches. Hence I think, RXTX should be rewritten from scratch de-
unifying the native code base (and implementing thread safe code on
the Java side).
<<

This appears to be a very small amount of functionality for a total 
rewrite.  The port ownership only needs maybe 3 native calls if it is done 
with native calls at all.

Those features which are not part of the Unix standard(s) can be special 
cased.  I'm not sure /dev/cu is standard.  We can look.  I know linux 
deprecated /dev/cua years ago.

Thread safe Java code is not a platform specific issue.

--
Trent Jarvi
tjarvi at qbang.org


From sds at dcs.gla.ac.uk  Wed Jun  7 12:36:43 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Wed, 07 Jun 2006 19:36:43 +0100
Subject: [Rxtx] Expected RXTX behaviour?
In-Reply-To: <1149703900.30891.19.camel@addu>
References: <1149703900.30891.19.camel@addu>
Message-ID: <1149705403.30891.25.camel@addu>

Apologies, caught the problem. Had to append '\r' to the end of the AT
string. A non obvious but stupid mistake... :-)

Final quick question though: How might I stop the echoing of
outputStream data back into the inputStream? I still see the ATI
commands on the inputStream, along with the output from the device.


Cheers,
S.



On Wed, 2006-06-07 at 19:11 +0100, Stephen Strowes wrote:
> Hi,
> 
> I managed to get RXTX to compile for my iPAQ following my previous post
> to this list. Quick query though:
> 
> I want to be able to issue AT commands to a device, and interpret the
> responses. For this, I assume I do the following, in psuedo-form:
> 
> 	CommPortIdentifier.getPortIdentifiers();
> 	// find the correct device id
> 	serialPort= (SerialPort)portID.open("Test");
> 	// Set parameters and flow control
> 	outputStream= serialPort.getOutputStream();
> 	inputStream=  serialPort.getInputStream();
> 
> ... following this, I spawn a thread to respond to DATA_AVAILABLE events
> on serialPort with inputStream, and occasionally write and flush an
> "ATI" onto the outputStream. Nothing complex, I just want to see it
> work.
> 
> I would have expected inputStream to give the same information back from
> an "ATI" command as minicom provides, but instead inputStream only sees
> the "ATI" I put onto the outputStream.
> 
> Have I missed something?
> 
> 
> Cheers,
> S.
> 



From sds at dcs.gla.ac.uk  Wed Jun  7 12:11:40 2006
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Wed, 07 Jun 2006 19:11:40 +0100
Subject: [Rxtx] Expected RXTX behaviour?
Message-ID: <1149703900.30891.19.camel@addu>

Hi,

I managed to get RXTX to compile for my iPAQ following my previous post
to this list. Quick query though:

I want to be able to issue AT commands to a device, and interpret the
responses. For this, I assume I do the following, in psuedo-form:

	CommPortIdentifier.getPortIdentifiers();
	// find the correct device id
	serialPort= (SerialPort)portID.open("Test");
	// Set parameters and flow control
	outputStream= serialPort.getOutputStream();
	inputStream=  serialPort.getInputStream();

... following this, I spawn a thread to respond to DATA_AVAILABLE events
on serialPort with inputStream, and occasionally write and flush an
"ATI" onto the outputStream. Nothing complex, I just want to see it
work.

I would have expected inputStream to give the same information back from
an "ATI" command as minicom provides, but instead inputStream only sees
the "ATI" I put onto the outputStream.

Have I missed something?


Cheers,
S.




From joachim at buechse.de  Wed Jun  7 09:02:13 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 7 Jun 2006 17:02:13 +0200
Subject: [Rxtx] Update of build process for OSX (XCode project)
Message-ID: <62EC47B1-46BD-4ECA-B9EC-C4061D147CDA@buechse.de>

With the help of Dmitry Markman and Brian Schilling I have updated  
(and largely simplifed) the XCode project file for Mac OS X.

Changes:
- compiles a universal binary library with intel=OSX10.4+, ppc=OSX10.2 
+ support
- compiles the Java sources into a JRE1.1 compatible, compressed jar.

Please test on your configuration, especially if you have computers  
running 10.2/10.3 or intel.

Best regards,
Joachim


From joachim at buechse.de  Wed Jun  7 14:36:37 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 7 Jun 2006 22:36:37 +0200
Subject: [Rxtx] Expected RXTX behaviour?
In-Reply-To: <1149705403.30891.25.camel@addu>
References: <1149703900.30891.19.camel@addu> <1149705403.30891.25.camel@addu>
Message-ID: <D3AD6EAF-27BB-455E-9697-86C1121920C3@buechse.de>

Echoing is a feature of the modem. Try ATE0 which works with most  
"rockwell" compatible modems.

Regards,
Joachim


On 07.06.2006, at 20:36, Stephen Strowes wrote:

> Apologies, caught the problem. Had to append '\r' to the end of the AT
> string. A non obvious but stupid mistake... :-)
>
> Final quick question though: How might I stop the echoing of
> outputStream data back into the inputStream? I still see the ATI
> commands on the inputStream, along with the output from the device.
>
>
> Cheers,
> S.
>
>
>
> On Wed, 2006-06-07 at 19:11 +0100, Stephen Strowes wrote:
>> Hi,
>>
>> I managed to get RXTX to compile for my iPAQ following my previous  
>> post
>> to this list. Quick query though:
>>
>> I want to be able to issue AT commands to a device, and interpret the
>> responses. For this, I assume I do the following, in psuedo-form:
>>
>> 	CommPortIdentifier.getPortIdentifiers();
>> 	// find the correct device id
>> 	serialPort= (SerialPort)portID.open("Test");
>> 	// Set parameters and flow control
>> 	outputStream= serialPort.getOutputStream();
>> 	inputStream=  serialPort.getInputStream();
>>
>> ... following this, I spawn a thread to respond to DATA_AVAILABLE  
>> events
>> on serialPort with inputStream, and occasionally write and flush an
>> "ATI" onto the outputStream. Nothing complex, I just want to see it
>> work.
>>
>> I would have expected inputStream to give the same information  
>> back from
>> an "ATI" command as minicom provides, but instead inputStream only  
>> sees
>> the "ATI" I put onto the outputStream.
>>
>> Have I missed something?
>>
>>
>> Cheers,
>> S.
>>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From g_petrini at yahoo.it  Thu Jun  8 01:41:58 2006
From: g_petrini at yahoo.it (Giacomo Petrini)
Date: Thu, 8 Jun 2006 09:41:58 +0200 (CEST)
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from FieldTalk
Message-ID: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>

Hi,
I'm evaluating the library for the modbus protocol
from FieldTalk
(http://www.modbusdriver.com/fieldtalk/.
I'm using J2SE 5.0 and RXTX 2.1 on win XP.
The problem is that the modbus lib has a method (the
openProtocol method, but maybe there are others) tha
throws the
javax.comm.UnsupportedCommOperationException.
Now, in RXTX 2.1 the namespace has changed in gnu.io,
so the modbus library doesn't work anymore (it look
for things in javax.comm). I've already sent an email
to fieldtalk to see if they are aware of the problem.
The solution should be to use JavaComm + RXTX 2.0. But
I've read somewhere that JavaComm 2.0 does not work
with Java 5.0 and JavaComm 3.0 does not work with RXTX
2.0 so I don't know what to do.

Any ideas?

Thanks Jack

PS: can you make a CC to my personal email
(g_petrini at yahoo.it) too please?

Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 


From rxtx at tapastda.co.uk  Thu Jun  8 02:27:57 2006
From: rxtx at tapastda.co.uk (rxtx@tapastda.co.uk)
Date: Thu, 08 Jun 2006 09:27:57 +0100
Subject: [Rxtx] Win XP and Infrared based serial port
Message-ID: <4487DF8D.5050807@tapastda.co.uk>

I'm attempting to use RXTX 2.1.7 on Win XP with J2SE 5.0 to communicate with a
GSM mobile using a COM port. A peculiarity that I've seen is that whilst I can
communicate successfully with a mobile which uses an infrared based COM port
using the SUN provided javax.comm (v2.0) I cannot use RXTX because it fails to
read anything from the port (i.e. read timeout always occurs returning zero bytes).

I assumed that this could be the result of flow control problems and thus I've
tried setting either software or hardware based flow control on the port however
this has no affect.

Can you suggest any other port configuration changes which might be required to
make such a port work with RXTX.

Thanks
Stu
-- 
Stuart
Tapastda Limited


From tjarvi at qbang.org  Thu Jun  8 05:17:12 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 8 Jun 2006 05:17:12 -0600 (MDT)
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from
	FieldTalk
In-Reply-To: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
References: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606080504480.9856@www>

On Thu, 8 Jun 2006, Giacomo Petrini wrote:

> Hi,
> I'm evaluating the library for the modbus protocol
> from FieldTalk
> (http://www.modbusdriver.com/fieldtalk/.
> I'm using J2SE 5.0 and RXTX 2.1 on win XP.
> The problem is that the modbus lib has a method (the
> openProtocol method, but maybe there are others) tha
> throws the
> javax.comm.UnsupportedCommOperationException.
> Now, in RXTX 2.1 the namespace has changed in gnu.io,
> so the modbus library doesn't work anymore (it look
> for things in javax.comm). I've already sent an email
> to fieldtalk to see if they are aware of the problem.
> The solution should be to use JavaComm + RXTX 2.0. But
> I've read somewhere that JavaComm 2.0 does not work
> with Java 5.0 and JavaComm 3.0 does not work with RXTX
> 2.0 so I don't know what to do.
>
> Any ideas?
>
> Thanks Jack
>


Hi Jack

There are plans for Sun to rerelease JavaComm 2.0 mentioned in the rxtx 
mail-list archives.  When this happens rxtx will release a current rxtx 
2.0 library that works with it.

There are no dates promised by either side but rxtx will do it as soon as 
possible after Sun's rerelease.  Just to give you a feel for the time 
frame, this started last year and no significant progress has been made. 
There have been friendly talks pointing towards solutions (rerelease 2.0) 
but that does not get your application working today.  rxtx is preparing 
for its second release in gnu.io since then.

--
Trent Jarvi
tjarvi at qbang.org




From jredman at ergotech.com  Thu Jun  8 08:47:23 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 08 Jun 2006 08:47:23 -0600
Subject: [Rxtx] problem with rxtx 2.1 and the ModBus library from
	FieldTalk
In-Reply-To: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
References: <20060608074158.23175.qmail@web31913.mail.mud.yahoo.com>
Message-ID: <4488387B.6040903@ergotech.com>

You could always try a different library, eg.

http://sourceforge.net/projects/jamod

I've only used the slave side since we have our own implementation of 
Modbus Client (and a host of other PLC protocols).  However the client 
side seems to be pretty well supported and fairly widely used.  Since 
the source is there you could change to gnu.io.

I think I should take more of an interest in this issue.  We generally 
run 1.4.2 on Linux, but also have some J9 and old platforms that we 
support that are basically Personal Java.  5.0 on Linux has some 
horrible MDI bugs, to the point of being unusable.   Sounds as though we 
are going to have code compatibility problems across these platforms.

Jim


Giacomo Petrini wrote:
> Hi,
> I'm evaluating the library for the modbus protocol
> from FieldTalk
> (http://www.modbusdriver.com/fieldtalk/.
> I'm using J2SE 5.0 and RXTX 2.1 on win XP.
> The problem is that the modbus lib has a method (the
> openProtocol method, but maybe there are others) tha
> throws the
> javax.comm.UnsupportedCommOperationException.
> Now, in RXTX 2.1 the namespace has changed in gnu.io,
> so the modbus library doesn't work anymore (it look
> for things in javax.comm). I've already sent an email
> to fieldtalk to see if they are aware of the problem.
> The solution should be to use JavaComm + RXTX 2.0. But
> I've read somewhere that JavaComm 2.0 does not work
> with Java 5.0 and JavaComm 3.0 does not work with RXTX
> 2.0 so I don't know what to do.
> 
> Any ideas?
> 
> Thanks Jack
> 
> PS: can you make a CC to my personal email
> (g_petrini at yahoo.it) too please?
> 
> Chiacchiera con i tuoi amici in tempo reale! 
>  http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  8 18:17:23 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 08 Jun 2006 17:17:23 -0700
Subject: [Rxtx] rxtx access is denied error
Message-ID: <4488BE13.2050706@dupreeinc.com>

Hello,

I have been trying to replace the commapi from sun with rxtx for a 
project that communicates with a serial port that is a USB-Serial 
interface.  To be exact, I am using the FTDI VCP driver with one of 
their modules connected to a windows XP system.

I have the RXTX package working pretty well as long as nothing goes wrong.

If a user disconnects the USB port while my java application is running, 
my application goes into an endless loop with lots of messages in the  
errors stream  like the ones below:

    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(481):
    Access is denied.
    Error 0x5 at
    /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
    Access is denied.


I believe when this happens the COM port completely disappears and the 
rxtx driver has a heart attack.  Obviously, the user should not do this, 
but my application needs to ideally, correct the situation or as a worse 
case, terminate with a little dignity.  Currently, I have not figured 
out how to catch this error.

The closest I have come is to trap an exception to my input stream read  
that says "No error in readByte"  This error appears to be outside of 
the endless loop of the errors listed above.

Does anybody have an idea of how to identify and trap this error?  Any 
suggestions on how to gracefully recover from it would be greatly 
appreciated!

Thank you for your time,

Doug Thistlethwaite




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060608/9cfca302/attachment-0023.html

From tjarvi at qbang.org  Thu Jun  8 20:54:17 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 8 Jun 2006 20:54:17 -0600 (MDT)
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <4488BE13.2050706@dupreeinc.com>
References: <4488BE13.2050706@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606082022580.1323@www>

On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I have been trying to replace the commapi from sun with rxtx for a project 
> that communicates with a serial port that is a USB-Serial interface.  To be 
> exact, I am using the FTDI VCP driver with one of their modules connected to 
> a windows XP system.
>
> I have the RXTX package working pretty well as long as nothing goes wrong.
>
> If a user disconnects the USB port while my java application is running, my 
> application goes into an endless loop with lots of messages in the  errors 
> stream  like the ones below:
>
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(481):
>   Access is denied.
>   Error 0x5 at
>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c(2694):
>   Access is denied.
>
>
> I believe when this happens the COM port completely disappears and the rxtx 
> driver has a heart attack.  Obviously, the user should not do this, but my 
> application needs to ideally, correct the situation or as a worse case, 
> terminate with a little dignity.  Currently, I have not figured out how to 
> catch this error.
>
> The closest I have come is to trap an exception to my input stream read  that 
> says "No error in readByte"  This error appears to be outside of the endless 
> loop of the errors listed above.
>
> Does anybody have an idea of how to identify and trap this error?  Any 
> suggestions on how to gracefully recover from it would be greatly 
> appreciated!
>

Hi Doug

Sadly I don't have a quick solution for you.

Termios has no knowlage about the JVM so it wont be throwing exceptions 
you can catch.

We can return error and set the error number to something reasonable that 
results in an exception.  The No Error message simply means we did not set 
an error number in termios.c.  Those are the line numbers in the code you 
see.  SerialImp.c realizes it errored but does not know much more yet. 
Everything touching the file descriptor is going to error after the port 
is gone presumably.

We don't currently have a plan in place for vanishing (or appearing) com 
ports.

Another example of what we need to think about is what happens if you 
start your application and then plug in the dongle?  Or what if you unplug 
and then plug it in again?

So in each of these three cases, what would the behavior of the (yet to 
be) correct implementation do?

How will the enumerated ports be handled during these changes?

There can also be hints from the OS that could be taken into 
consideration.

We can probably get some exceptions thrown that make sense and null the 
file descriptor when it happens to prevent io attempts.  That would be a 
crude way to let applications know something strange has happened.

Is anyone else tinkering with this problem?

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  9 01:31:29 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 9 Jun 2006 09:31:29 +0200
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <Pine.LNX.4.61.0606082022580.1323@www>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
Message-ID: <AC6EDDDD-0A64-401F-B16B-E484788CDF4A@buechse.de>

Hello Trent,

I am not tinkering with this on the Source Level - but I think it  
should work pretty much the same way as it currently does in OSX.  
When the port goes away you get an IOException thrown for any read/ 
write. It will no longer be in the list of ports from  
CommPortIdentifier.getPortIdentifiers(). When a port (re-)appears it  
is added to the list. It's up to the application to re-check the list  
from time to time.

On Windows you can't do much better then that, because the ports  
don't have useful names. Which USB "virtual com port" is on which  
COMx depends on the order the devices were added. So reconnecting to  
the same device may mean connecting to another port.

Regarding the exception thrown: it would be nice to use an  
IOException subclass but the Exception message should definetly be  
informative also as most applications may want to keep compatibility  
with javax.comm.

Regards,
Joachim


On 09.06.2006, at 04:54, Trent Jarvi wrote:

> On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:
>
>> Hello,
>>
>> I have been trying to replace the commapi from sun with rxtx for a  
>> project
>> that communicates with a serial port that is a USB-Serial  
>> interface.  To be
>> exact, I am using the FTDI VCP driver with one of their modules  
>> connected to
>> a windows XP system.
>>
>> I have the RXTX package working pretty well as long as nothing  
>> goes wrong.
>>
>> If a user disconnects the USB port while my java application is  
>> running, my
>> application goes into an endless loop with lots of messages in  
>> the  errors
>> stream  like the ones below:
>>
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (481):
>>   Access is denied.
>>   Error 0x5 at
>>   /sandbox/tjarvi/libs/rxtx-2.1-7-144/build-win32/../src/termios.c 
>> (2694):
>>   Access is denied.
>>
>>
>> I believe when this happens the COM port completely disappears and  
>> the rxtx
>> driver has a heart attack.  Obviously, the user should not do  
>> this, but my
>> application needs to ideally, correct the situation or as a worse  
>> case,
>> terminate with a little dignity.  Currently, I have not figured  
>> out how to
>> catch this error.
>>
>> The closest I have come is to trap an exception to my input stream  
>> read  that
>> says "No error in readByte"  This error appears to be outside of  
>> the endless
>> loop of the errors listed above.
>>
>> Does anybody have an idea of how to identify and trap this error?   
>> Any
>> suggestions on how to gracefully recover from it would be greatly
>> appreciated!
>>
>
> Hi Doug
>
> Sadly I don't have a quick solution for you.
>
> Termios has no knowlage about the JVM so it wont be throwing  
> exceptions
> you can catch.
>
> We can return error and set the error number to something  
> reasonable that
> results in an exception.  The No Error message simply means we did  
> not set
> an error number in termios.c.  Those are the line numbers in the  
> code you
> see.  SerialImp.c realizes it errored but does not know much more yet.
> Everything touching the file descriptor is going to error after the  
> port
> is gone presumably.
>
> We don't currently have a plan in place for vanishing (or  
> appearing) com
> ports.
>
> Another example of what we need to think about is what happens if you
> start your application and then plug in the dongle?  Or what if you  
> unplug
> and then plug it in again?
>
> So in each of these three cases, what would the behavior of the  
> (yet to
> be) correct implementation do?
>
> How will the enumerated ports be handled during these changes?
>
> There can also be hints from the OS that could be taken into
> consideration.
>
> We can probably get some exceptions thrown that make sense and null  
> the
> file descriptor when it happens to prevent io attempts.  That would  
> be a
> crude way to let applications know something strange has happened.
>
> Is anyone else tinkering with this problem?
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From doug at dupreeinc.com  Fri Jun  9 13:09:58 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Fri, 09 Jun 2006 12:09:58 -0700
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <Pine.LNX.4.61.0606082022580.1323@www>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
Message-ID: <4489C786.9050504@dupreeinc.com>


Ideally, it would be nice if it would throw an exception and terminate 
the loop.  I am still trying to figure out how to detect the condition 
and recover form it in some form...  I am getting the "No error in 
readByte" exception in my serialEvent() method after an input stream 
read.  It appears to me that the only graceful recovery is to close the 
port and then reopen it when it becomes available.  I can pass the event 
up to the update method in my main frame, but I still can't close the 
port from within that thread.  Any suggestions on how to pass this event 
to a location where the port can be safely closed?

Re: Slow startup in windows XP
I have been looking into this a little closer and have found out the 
following:
System Windows XP Pro 3GHz dual core with 1GB RAM and NO parallel port.
Starting the SerialDemo included with the commapi using the rxtx instead 
of javax.comm takes 60 seconds.
Starting the SerialDemo using rxrx with the rxtxParallel.dll file 
removed takes about 20 seconds.
Modify initialize in RXRXCommDriver.java to not test the parallel ports 
takes less than 1 second.

It would be nice if the initialize routine could detect the presence of 
rxtxParallel.dll file and just skip the whole process if not present.  
Is there an easy way to check for the presence of this file without 
running the parallel port test?

Doug


 

Trent Jarvi wrote:

>On Thu, 8 Jun 2006, Doug Thistlethwaite wrote:
>...
>  
>
>
>Hi Doug
>
>Sadly I don't have a quick solution for you.
>
>Termios has no knowlage about the JVM so it wont be throwing exceptions 
>you can catch.
>
>We can return error and set the error number to something reasonable that 
>results in an exception.  The No Error message simply means we did not set 
>an error number in termios.c.  Those are the line numbers in the code you 
>see.  SerialImp.c realizes it errored but does not know much more yet. 
>Everything touching the file descriptor is going to error after the port 
>is gone presumably.
>
>We don't currently have a plan in place for vanishing (or appearing) com 
>ports.
>
>Another example of what we need to think about is what happens if you 
>start your application and then plug in the dongle?  Or what if you unplug 
>and then plug it in again?
>
>So in each of these three cases, what would the behavior of the (yet to 
>be) correct implementation do?
>
>How will the enumerated ports be handled during these changes?
>
>There can also be hints from the OS that could be taken into 
>consideration.
>
>We can probably get some exceptions thrown that make sense and null the 
>file descriptor when it happens to prevent io attempts.  That would be a 
>crude way to let applications know something strange has happened.
>
>Is anyone else tinkering with this problem?
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060609/911ed787/attachment-0023.html

From Ugo.Landini at Sun.COM  Fri Jun  2 14:23:47 2006
From: Ugo.Landini at Sun.COM (Ugo Landini)
Date: Fri, 02 Jun 2006 22:23:47 +0200
Subject: [Rxtx] OSX 10.4.7 and usb
Message-ID: <44809E53.2070905@sun.com>

Hi, I have installed the library and the native libraries on OSX 10.4.7. 
Then I have run this simple code:

...
while (portList.hasMoreElements()) {
             portId = (CommPortIdentifier) portList.nextElement();
             System.out.println("-> " + portId.getName() + " Port Type:" 
+ portId.getPortType());
...

and the output is:

Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7

Ports found:
-> /dev/tty.Bluetooth-PDA-Sync Port Type:1
-> /dev/cu.Bluetooth-PDA-Sync Port Type:1
-> /dev/tty.Bluetooth-Modem Port Type:1
-> /dev/cu.Bluetooth-Modem Port Type:1

I can't see any USB ports... with javax.comm on linux I could see the 
/dev/ttyUSB stuff, but that's not the case with OSX. Any idea?

tia

uL


From tod at todbot.com  Sun Jun 11 12:04:37 2006
From: tod at todbot.com (Tod E. Kurt)
Date: Sun, 11 Jun 2006 11:04:37 -0700
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <44809E53.2070905@sun.com>
References: <44809E53.2070905@sun.com>
Message-ID: <E2EB14A1-20A7-4611-8F1A-E3D2ABE41F48@todbot.com>

A dumb question, but: do you have the USB serial adapters plugged  
in?  They only show up in /dev when plugged in.  Also, you can verify  
they exist independent of RXTX by doing something like "ls -l /dev/ 
cu.*".

On Jun 2, 2006, at 1:23 PM, Ugo Landini wrote:

> Hi, I have installed the library and the native libraries on OSX  
> 10.4.7.
> Then I have run this simple code:
>
> ...
> while (portList.hasMoreElements()) {
>              portId = (CommPortIdentifier) portList.nextElement();
>              System.out.println("-> " + portId.getName() + " Port  
> Type:"
> + portId.getPortType());
> ...
>
> and the output is:
>
> Experimental:  JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
>
> Ports found:
> -> /dev/tty.Bluetooth-PDA-Sync Port Type:1
> -> /dev/cu.Bluetooth-PDA-Sync Port Type:1
> -> /dev/tty.Bluetooth-Modem Port Type:1
> -> /dev/cu.Bluetooth-Modem Port Type:1
>
> I can't see any USB ports... with javax.comm on linux I could see the
> /dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>
> tia
>
> uL
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>



From lyon at docjava.com  Sun Jun 11 12:14:50 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Sun, 11 Jun 2006 14:14:50 -0400
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <44809E53.2070905@sun.com>
References: <44809E53.2070905@sun.com>
Message-ID: <p06020444c0b20de7d248@[192.168.1.152]>

>Hi Ugo,

Do you have any USB serial ports (like the keyspan 19-HS) plugged
into the mac?
Thanks!
  - DL


>Hi, I have installed the library and the native libraries on OSX 10.4.7.
>Then I have run this simple code:
>
>...
>while (portList.hasMoreElements()) {
>              portId = (CommPortIdentifier) portList.nextElement();
>              System.out.println("-> " + portId.getName() + " Port Type:"
>+ portId.getPortType());
>...
>
>and the output is:
>
>Experimental:  JNI_OnLoad called.
>Stable Library
>=========================================
>Native lib Version = RXTX-2.1-7
>Java lib Version   = RXTX-2.1-7
>
>Ports found:
>-> /dev/tty.Bluetooth-PDA-Sync Port Type:1
>-> /dev/cu.Bluetooth-PDA-Sync Port Type:1
>-> /dev/tty.Bluetooth-Modem Port Type:1
>-> /dev/cu.Bluetooth-Modem Port Type:1
>
>I can't see any USB ports... with javax.comm on linux I could see the
>/dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>
>tia
>
>uL
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx



From dmarkman at mac.com  Sun Jun 11 14:30:27 2006
From: dmarkman at mac.com (Dmitry Markman)
Date: Sun, 11 Jun 2006 16:30:27 -0400
Subject: [Rxtx] OSX 10.4.7 and usb
In-Reply-To: <p06020444c0b20de7d248@[192.168.1.152]>
References: <44809E53.2070905@sun.com> <p06020444c0b20de7d248@[192.168.1.152]>
Message-ID: <B9C1606B-4339-4564-A175-FE83DFFA7D76@mac.com>

afaik
10.4.7 wasn't released yet
it will soon, no doubts


On Jun 11, 2006, at 2:14 PM, Dr. Douglas Lyon wrote:

>> Hi Ugo,
>
> Do you have any USB serial ports (like the keyspan 19-HS) plugged
> into the mac?
> Thanks!
>   - DL
>
>
>> Hi, I have installed the library and the native libraries on OSX  
>> 10.4.7.
>> Then I have run this simple code:
>>
>> ...
>> while (portList.hasMoreElements()) {
>>              portId = (CommPortIdentifier) portList.nextElement();
>>              System.out.println("-> " + portId.getName() + " Port  
>> Type:"
>> + portId.getPortType());
>> ...
>>
>> and the output is:
>>
>> Experimental:  JNI_OnLoad called.
>> Stable Library
>> =========================================
>> Native lib Version = RXTX-2.1-7
>> Java lib Version   = RXTX-2.1-7
>>
>> Ports found:
>> -> /dev/tty.Bluetooth-PDA-Sync Port Type:1
>> -> /dev/cu.Bluetooth-PDA-Sync Port Type:1
>> -> /dev/tty.Bluetooth-Modem Port Type:1
>> -> /dev/cu.Bluetooth-Modem Port Type:1
>>
>> I can't see any USB ports... with javax.comm on linux I could see the
>> /dev/ttyUSB stuff, but that's not the case with OSX. Any idea?
>>
>> tia
>>
>> uL
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

Dmitry Markman



From tjarvi at qbang.org  Sun Jun 11 18:52:59 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 11 Jun 2006 18:52:59 -0600 (MDT)
Subject: [Rxtx] rxtx access is denied error
In-Reply-To: <4489C786.9050504@dupreeinc.com>
References: <4488BE13.2050706@dupreeinc.com>
	<Pine.LNX.4.61.0606082022580.1323@www>
	<4489C786.9050504@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606111845430.7274@www>

On Fri, 9 Jun 2006, Doug Thistlethwaite wrote:

>
> Ideally, it would be nice if it would throw an exception and terminate the 
> loop.  I am still trying to figure out how to detect the condition and 
> recover form it in some form...  I am getting the "No error in readByte" 
> exception in my serialEvent() method after an input stream read.  It appears 
> to me that the only graceful recovery is to close the port and then reopen it 
> when it becomes available.  I can pass the event up to the update method in 
> my main frame, but I still can't close the port from within that thread.  Any 
> suggestions on how to pass this event to a location where the port can be 
> safely closed?
>

I've gone through and cleaned up the termios.c layer.  I need to get to a 
windows machine with a USB dongle and see where the ioctl() is being 
called.  Probably the eventLoop.  But all of the ioctls should probably 
result in an IOException during this condition.

I'll probably finish this up Monday night when I can borrow a USB 
dongle.

There is no point in putting the code into CVS yet.  If you are tinkering 
I can mail the patch.  I think we will want to make a couple fixes in 
SerialImp.c to handle errors before it's ready.

--
Trent Jarvi
tjarvi at qbang.org



From bob_tai2001 at yahoo.com  Mon Jun 12 09:42:14 2006
From: bob_tai2001 at yahoo.com (Bob Tai)
Date: Mon, 12 Jun 2006 08:42:14 -0700 (PDT)
Subject: [Rxtx] Would like to make javax.comm 2.0 binaries available to RXTX
	again
Message-ID: <20060612154214.58219.qmail@web32804.mail.mud.yahoo.com>


thank you Paul, Joachim, Trent and everyone try to
workout the java comm and Rxtx situation.  At least
now I have something that is solid enough to make my
decision.  

thank you,
     Bob

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From Ralph.Buchfelder at gmx.net  Mon Jun 12 15:30:20 2006
From: Ralph.Buchfelder at gmx.net (Ralph Buchfelder)
Date: Mon, 12 Jun 2006 23:30:20 +0200
Subject: [Rxtx] rxtx binaries or porting to XSCALE Windows Mobile 2003 / 2005
Message-ID: <448DDCEC.7090506@gmx.net>

dear group,

i have been carefully reading your homepage, wiki and archives
but there seems to be no detailled information on porting to Windows 
Mobile/CE.

as far as i understood from the 'porting' section you can do porting to 
winCE. but how? do i only need to obtain the sourcecode (which one?) and 
compile this in Microsoft eMbedded Visual C++ for ARM/Xscale?
Any other ways?


unfortunately i must admit that i do have little linux skills but i have 
made my way through gcc and makefiles. right now i need to implement com 
  communication in a J2ME application and found your website as >the< 
solution.

best regards
Ralph Buchfelder

University of Regensburg
Department of Geography

PS: i dont care about Javacomm compliancy (ie. 2.0 or 2.1) - i just need 
a working serial port API in IBM J9 VM.


From paul.klissner at sun.com  Wed Jun 14 18:12:58 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Wed, 14 Jun 2006 17:12:58 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
Message-ID: <4490A60A.9090305@sun.com>

Hello RxTx community,

I finally think I have a compromise in place that will stand in the gap.

If you go to http://www.sun.com and search for javax.comm, you'll
get taken to a download page, where now users can get a copy of the
comm.jar file out of 2.0.3, along with just a license and a README.

I trust this will suffice until such time as RxTx decided to implement
their own java classes or we can get a JSR going to mitigate some
of the problems (the readme in the comm.jar 2.0.3 zip file
contains my thoughts on that).

Thanks,
Paul



From tjarvi at qbang.org  Wed Jun 14 21:15:35 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 14 Jun 2006 21:15:35 -0600 (MDT)
Subject: [Rxtx] rxtx-2.0-7 (final) src is in CVS
Message-ID: <Pine.LNX.4.61.0606142100500.2742@www>


I wasn't expecting to be working on rxtx 2.0 tonight :)

Thanks go out to Paul Klissner for his work in making the coming release 
of rxtx-2.0-7 possible for users that require package javax.comm on many 
platforms.

Most people know that rxtx 2.0 is for use with Sun's CommAPI 2.0 for 
Solaris or the Generic CommAPI 2.0-3 available for download at Sun.  If 
you need javax.comm packages on many platforms, you are probably 
interested.  If you use rxtx 2.1 in package gnu.io, then you are not going 
to care much.

I've tried to update the rxtx 2.0 src directory in preparation for 
rxtx-2.0-7 (final).  Linux should compile.  Windows will compile if you 
generate your own .def files (I'll generate these tomorrow).  If you have 
some time to do basic testing of the source, I'd appreciate it.  The 
source should be good but you may find classes not found.  This source is 
a backport from rxtx 2.1.

I wanted to get things started so anyone interested on Mac OS X could get 
a head start.

All of this is in CVS.  http://www.rxtx.org/cvs.html

I suspect we will have binaries for testing in a couple days if you are 
unable to compile.   Consider this a smoke test.

--
Trent Jarvi
tjarvi at qbang.org


From legolas.w at gmail.com  Wed Jun 14 22:04:28 2006
From: legolas.w at gmail.com (Legolas Woodland)
Date: Wed, 14 Jun 2006 21:04:28 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <4490A60A.9090305@sun.com>
References: <4490A60A.9090305@sun.com>
Message-ID: <87ee9b170606142104p745fcef0vea622fbc8f528bfc@mail.gmail.com>

is there anything new in this version of javax.comm ?
thanks


On 6/14/06, Paul Klissner <paul.klissner at sun.com> wrote:
>
> Hello RxTx community,
>
> I finally think I have a compromise in place that will stand in the gap.
>
> If you go to http://www.sun.com and search for javax.comm, you'll
> get taken to a download page, where now users can get a copy of the
> comm.jar file out of 2.0.3, along with just a license and a README.
>
> I trust this will suffice until such time as RxTx decided to implement
> their own java classes or we can get a JSR going to mitigate some
> of the problems (the readme in the comm.jar 2.0.3 zip file
> contains my thoughts on that).
>
> Thanks,
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060614/5ff4dfbc/attachment-0023.html

From joachim at buechse.de  Thu Jun 15 07:22:48 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 15 Jun 2006 15:22:48 +0200
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
Message-ID: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>

Good day!

Some of my users report problems using RXTX 2.1.7 on Windows98 to  
communicate with an FTDI FT245BM chip (using their latest VCP  
driver). Either no ports are being shown (ie returned form  
CommPortIdentifier.getPortIdentifiers()) or the transfers fail.

Did anyone run into similar Problems with Win98??

Best regards,
Joachim



From ajmas at sympatico.ca  Thu Jun 15 08:12:28 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Thu, 15 Jun 2006 10:12:28 -0400
Subject: [Rxtx] API change question
Message-ID: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

How closely do you follow the Java Communication API spec? The reason I ask is because I would be interested in augmenting the CommPortIdentifier class to include a getDisplayName() method. By default it would return the same value as getName(), but would provide the possibility of displaying a 'user friendly' name, for platforms where the display name is not the same as the device name. An example of this is on MacOS X, where currently the names seem to be of the form /dev/cu.* and /dev/tty.*, yet what the expects to see is simply the part after the full-stop. Although I could move this logic into the Java code, it would be nice to see it transparent to the Java code.

Andre




From ajmas at sympatico.ca  Thu Jun 15 08:16:22 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Thu, 15 Jun 2006 10:16:22 -0400
Subject: [Rxtx] Package to use
Message-ID: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

While the Java API spec refers to javax.comm, I see that only gnu.io is provide by the rxtx project. Should our projects refer to the gnu.io package or the javax.comm API?

Andre



From joachim at buechse.de  Thu Jun 15 08:45:05 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 15 Jun 2006 16:45:05 +0200
Subject: [Rxtx] API change question
In-Reply-To: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>

Hello Andre,

the /dev/cu and /dev/tty have different semantics on OS X. It is much  
more than a simply naming issue to unify them, see my recent mail to  
the list...

Best regards,
Joachim


On 15.06.2006, at 16:12, Andre-John Mas wrote:

> Hi,
>
> How closely do you follow the Java Communication API spec? The  
> reason I ask is because I would be interested in augmenting the  
> CommPortIdentifier class to include a getDisplayName() method. By  
> default it would return the same value as getName(), but would  
> provide the possibility of displaying a 'user friendly' name, for  
> platforms where the display name is not the same as the device  
> name. An example of this is on MacOS X, where currently the names  
> seem to be of the form /dev/cu.* and /dev/tty.*, yet what the  
> expects to see is simply the part after the full-stop. Although I  
> could move this logic into the Java code, it would be nice to see  
> it transparent to the Java code.
>
> Andre
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From lyon at docjava.com  Thu Jun 15 10:16:29 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Thu, 15 Jun 2006 12:16:29 -0400
Subject: [Rxtx] cu.modem != /dev/ttya on mac.
In-Reply-To: <763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
	<763BFEE0-B51A-4B51-B92F-C79F7F2FC2A9@buechse.de>
Message-ID: <p0602046cc0b7378a95b0@[192.168.1.152]>

>Hi All,

I think that Joachim is correct. For the longest time,
I have been trying to figure out how to direct dial using
the cu.modem on the mac under os x.

As a less-than-optimal approach to auto-dialing, I have used
a keyspan USB 19HS adapter, along with an external modem, to
obtain the dialing feature.

Ideally, it would be better to dial with the built-in modem...but that did not
always seem to work, for some reason. Have others had some experience with
using the built in modem for dialing on the mac?

Thanks!
  - Doug


>Hello Andre,
>
>the /dev/cu and /dev/tty have different semantics on OS X. It is much?
>more than a simply naming issue to unify them, see my recent mail to?
>the list...
>
>Best regards,
>Joachim
>



From doug at dupreeinc.com  Thu Jun 15 14:52:50 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 15 Jun 2006 13:52:50 -0700
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
In-Reply-To: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
References: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
Message-ID: <4491C8A2.8090108@dupreeinc.com>

Hi Joachim,

I have been doing a lot with the new FTDI driver with win XP and have 
not had that particular problem.  I did notice that the new driver 
(dated May19th, 2006) is only for XP, Server 2003, and 2000.  Are they 
trying to use the 2.00.00 drivers or the old 1.09.06 version.  I am 
using a FT232R based module, but it uses the same drivers and I assume 
it would have the same problems.  Let me know which driver they are 
using and I can load up a 98 system here and see if  I can duplicate the 
problem.

Doug

Joachim Buechse wrote:

>Good day!
>
>Some of my users report problems using RXTX 2.1.7 on Windows98 to  
>communicate with an FTDI FT245BM chip (using their latest VCP  
>driver). Either no ports are being shown (ie returned form  
>CommPortIdentifier.getPortIdentifiers()) or the transfers fail.
>
>Did anyone run into similar Problems with Win98??
>
>Best regards,
>Joachim
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From matthewhepp at yahoo.com  Thu Jun 15 17:34:47 2006
From: matthewhepp at yahoo.com (Matthew Hepp)
Date: Thu, 15 Jun 2006 16:34:47 -0700 (PDT)
Subject: [Rxtx] Wither the XCode project?
Message-ID: <20060615233447.48064.qmail@web50311.mail.yahoo.com>

Either I don't know how to properly use CVS (entirely possibl), or the XCode
project is not making through the update properly. Doing a "cvs update" against
2.1-7 creates an XCode folder in MACOSX_IDE, and therein a
LibSerialUniversal.xcodeproj, but trying to open it yields a "Unable to Open
Project - Project rxtx-devel/MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj
cannot be opened because it is missing its project.pbxproj file" error. Showing
package contents reveals just the cvs-related files. Perhaps this is why
previous xcode projects have been saved as an sit.hqx - to retain the resource
fork?

Can someone point me in the right direction?

Thanks,

Matt

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Thu Jun 15 19:53:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 19:53:06 -0600 (MDT)
Subject: [Rxtx] Windows 98 no ports found, transmission aborted
In-Reply-To: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
References: <F38C0472-77DC-45D6-BDBC-41487536B724@buechse.de>
Message-ID: <Pine.LNX.4.61.0606151944070.23137@www>

On Thu, 15 Jun 2006, Joachim Buechse wrote:

> Good day!
>
> Some of my users report problems using RXTX 2.1.7 on Windows98 to
> communicate with an FTDI FT245BM chip (using their latest VCP
> driver). Either no ports are being shown (ie returned form
> CommPortIdentifier.getPortIdentifiers()) or the transfers fail.
>
> Did anyone run into similar Problems with Win98??
>

Hi Joachim

It has been a long time since I've tested win98.  I know rxtx-2.1-7pre16 
did get testing on win98 with ~jdk 1.3 though.  I wonder if jdks are still 
tested on that platform.

With win98 you usually have older boxes.  They can be short on CPU and 
memory.  Enumeration should work but I could picture runtime performance 
issues on win98.

The enumeration problems could result from other copies of your 
application if various states of decay still holding onto the port.  When 
things go wrong, people also like to open other terminal software to see 
whats going on which can interfere.  You can't open a windows port with 
two apps.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Thu Jun 15 20:08:53 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 20:08:53 -0600 (MDT)
Subject: [Rxtx] API change question
In-Reply-To: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141228.RXWM16051.tomts20-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606151954270.23137@www>

On Thu, 15 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> How closely do you follow the Java Communication API spec?

I can explain how this worked in the past.  How we do it in the future is 
open for discussion.

In the past we have tried to follow it as close as possible in gnu.io 
(rxtx 2.1).  We have added extensions but try to discourage their use. 
The extensions are clearly marked as such in the source code and javadocs.

rxtx 2.0 was intended to be a strict implementation of part of the spec. 
We let Sun's interfaces decide what methods can be called. There are 
differences not covered by the spec such as default values.  Thats not 
intentional but rather hard to avoid.

--
Trent Jarvi
tjarvi at qbang.org





From tjarvi at qbang.org  Thu Jun 15 21:09:11 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 15 Jun 2006 21:09:11 -0600 (MDT)
Subject: [Rxtx] Package to use
In-Reply-To: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060615141622.XXLZ29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606152026120.23137@www>

On Thu, 15 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> While the Java API spec refers to javax.comm, I see that only gnu.io is 
> provide by the rxtx project. Should our projects refer to the gnu.io 
> package or the javax.comm API?
>

Hi Andre

Lets see if I can give a fair and balanced answer to that.

If you are starting a new project and want to use RXTX, I would recommend 
using gnu.io.  The community support for gnu.io will not be going away 
anytime soon.  You can switch between gnu.io (2.1) and javax.comm (2.0) 
fairly easily.  They are not intended to be incompatible.  You just change 
package names and libs.

You can also consider the combination of rxtx 2.0 with Sun's commapi 
2.0-3.  This is considered a stop-gap measure by Sun for previous users of 
that combination.  Together rxtx 2.0 and Sun CommAPI 2.0 work in namespace 
javax.comm for programmers.

Finally, you can opt to just use Sun's oferrings in CommAPI 3.0 without 
rxtx.  That would be in namespace javax.comm also.  CommAPI 3.0 may be 
of more interest to you if you are looking at POS with Sun computers. 
Rxtx does not currently support the changes in CommAPI 3.0 or have firm 
plans to do so.  That does not mean we wouldn't implement them.  It just 
means nobody has contributed code yet.

You can't combine rxtx with CommAPI 3.0 for technical reasons that wont 
likely be fixed soon.

It's up to you as far as what you use.  We like to provide the freedom so 
you can choose.  Realistically, we will be supporting gnu.io mainly 
because we have some control over that name space and can support it.

Things may happen in the future that enable rxtx to provide more support 
in the javax namespace but that has not happened yet.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun 16 00:33:06 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 08:33:06 +0200
Subject: [Rxtx] Wither the XCode project?
In-Reply-To: <20060615233447.48064.qmail@web50311.mail.yahoo.com>
References: <20060615233447.48064.qmail@web50311.mail.yahoo.com>
Message-ID: <D30D660F-A49B-464E-AE4C-6B4563893682@buechse.de>

Hello Matthew,

could you please send me the contents of your

   rxtx-devel/CVS
   rxtx-devel/MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj/CVS

directories as a zip to my personal email address. This should  
indicate why the file is not checked out. I can see that it exists on  
the correct branch in the repository, so something must have gone  
wrong during the "cvs update"...

Best regards,
Joachim

On 16.06.2006, at 01:34, Matthew Hepp wrote:

> Either I don't know how to properly use CVS (entirely possibl), or  
> the XCode
> project is not making through the update properly. Doing a "cvs  
> update" against
> 2.1-7 creates an XCode folder in MACOSX_IDE, and therein a
> LibSerialUniversal.xcodeproj, but trying to open it yields a  
> "Unable to Open
> Project - Project rxtx-devel/MACOSX_IDE/XCode/ 
> LibSerialUniversal.xcodeproj
> cannot be opened because it is missing its project.pbxproj file"  
> error. Showing
> package contents reveals just the cvs-related files. Perhaps this  
> is why
> previous xcode projects have been saved as an sit.hqx - to retain  
> the resource
> fork?
>
> Can someone point me in the right direction?



From joachim at buechse.de  Fri Jun 16 10:41:20 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 18:41:20 +0200
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <p06230903c0b88613dca6@[10.0.1.7]>
References: <p06230903c0b88613dca6@[10.0.1.7]>
Message-ID: <03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>

Hello Bob,

until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was  
behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if  
Trent has migrated all recent changes from 2.1 to 2.0.

I have added the XCode project and updated documentation only to the  
gnu.io branch. Once the 2.0 implementation is up to date I will copy  
over the documentation/build files make them work.

Best regards,
Joachim

On 16.06.2006, at 18:07, Bob Jacobsen wrote:

> I'm one of the developers for the JMRI project, which provides  
> model railroad software in Java.  We've been using RXTX to provide  
> serial port access on MacOS X and Linux; we use the old javax.comm  
> 2.0 on Windows, OS/2 and Solaris.  Because of that, we need to stay  
> with RXTX 2.0, not 2.1
>
> We've been using the 2.0-pre17 installer for a long time, but it's  
> not compatible with Intel macs.
>
> Can you point me to where I can find the right files for RXTX 2.0  
> to package with the program?
>
> The current situation is confusing to me.  I've been pointed to  
> recent 2.1 versions (but we need the javax.comm names), to an even  
> older installer, etc.  I've been reading that some versions require  
> an installer, and others don't, but I haven't been able to figure  
> out which (if any) of those are where in CVS.
>
> I'd really appreciate a clear statement of what files to use and  
> what to do with them that I can pass on to our users.
>
> I'm more than happy to put files in the local classpath, have users  
> run an installer, or anything else.  Whatever is easiest for you.
>
> Thanks!  I really appreciate all that you do to keep RXTX working.
>
> Bob
> -- 
> Bob Jacobsen +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG



From joachim at buechse.de  Fri Jun 16 09:59:28 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 16 Jun 2006 17:59:28 +0200
Subject: [Rxtx] Wither the XCode project?
In-Reply-To: <20060616150240.49464.qmail@web50309.mail.yahoo.com>
References: <20060616150240.49464.qmail@web50309.mail.yahoo.com>
Message-ID: <D9935E05-2B83-488D-86DD-42599E229052@buechse.de>

Hello Matthew,

you have checked out the trunk (which is the 2.0.7 javax.comm.xxx  
release). For rxtx-2.1.7 (gnu.io.xxx release) you need to check out  
the branch

      commapi-0-0-1

The easiest way to do this is to download the rxtx src archive,  
unpack it and then do a cvs up inside the decompressed tree.  
Optionally you could do a

      cvs co -r commapi-0-0-1

but this will take much longer!

Best regards,
Joachim

When you do a cvs status it will show the sticky tag.

41:~/jdevelop/rxtx-2.1-7r2 joachim$ cvs status README.OSX
===================================================================
File: README.OSX        Status: Up-to-date

    Working revision:    1.1.2.1
    Repository revision: 1.1.2.1 /usr/local/cvsroot/rxtx-devel/Attic/ 
README.OSX,v
    Sticky Tag:          commapi-0-0-1 (branch: 1.1.2)
    Sticky Date:         (none)
    Sticky Options:      (none)




On 16.06.2006, at 17:02, Matthew Hepp wrote:

> %cvs status README.MACOSX
> ===================================================================
> File: README.MACOSX     Status: Up-to-date
>
>    Working revision:    1.1
>    Repository revision: 1.1     /usr/local/cvsroot/rxtx-devel/ 
> README.MACOSX,v
>    Sticky Tag:          (none)
>    Sticky Date:         (none)
>    Sticky Options:      (none)



From tjarvi at qbang.org  Fri Jun 16 16:31:18 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Fri, 16 Jun 2006 16:31:18 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
Message-ID: <Pine.LNX.4.61.0606161630030.14139@www>

On Fri, 16 Jun 2006, Joachim Buechse wrote:

> Hello Bob,
>
> until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was
> behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if
> Trent has migrated all recent changes from 2.1 to 2.0.
>

The src/ directory and configure.in/configure files should be fine.  I 
have not touched the Mac OS X directories.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sat Jun 17 02:39:55 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sat, 17 Jun 2006 10:39:55 +0200
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <Pine.LNX.4.61.0606161630030.14139@www>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
Message-ID: <350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>

Hello Trent,

apparently the IOEXCL changes have not made it into 2.0. I will add  
them to achieve a minimal diff between 2.0 and 2.1.

One other thing that bugs me for a while...

Shouldn't we replace "if !defined(TIOCSERGETLSR) && !defined(WIN32)"  
by a definition of its own "if defined(DRAINTHREAD)"? I think this  
would make the code clearer for people starting to read it.

Regards,
Joachim


On 17.06.2006, at 00:31, Trent Jarvi wrote:

> On Fri, 16 Jun 2006, Joachim Buechse wrote:
>
>> Hello Bob,
>>
>> until a couple of days ago, the rxtx javax.comm (ie 2.0) branch was
>> behind the rxtx gnu.io (ie 2.1) branch. I have not yet checked if
>> Trent has migrated all recent changes from 2.1 to 2.0.
>>
>
> The src/ directory and configure.in/configure files should be fine.  I
> have not touched the Mac OS X directories.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From tropicsu at hotmail.com  Sat Jun 17 09:32:48 2006
From: tropicsu at hotmail.com (Yoke K)
Date: Sat, 17 Jun 2006 15:32:48 +0000
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
Message-ID: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>

Hi,

I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to work with 
MAC OS X.
I am using iTegno 3000 - USB GPRS Modem.

Files in /dev and a symbolic link as follows:

crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 -> tty.usbserial

In my SendMessage.java, I have this line:
CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");

Appreciate any help ?

- Jon


Errors as follows:

>>INFO: SMSLib API for Java / v1.2.2
>>INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>INFO: JRE Version: 1.5.0_06
>>INFO: JRE Impl Version: 1.5.0_06-64
>>INFO: O/S: Mac OS X / ppc / 10.4.6
>>INFO: Using Wavecom (Generic) AT handler.

SendMessage(): Send a message.
  Using SMSLib API for Java v1.2.2

Connecting ..... :
>>INFO: CSerialDriver(): Connecting...
Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
>>INFO: CSerialDriver(): Disconnecting...
gnu.io.NoSuchPortException
        at 
gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:218)
        at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
        at org.smslib.CService.connect(CService.java:197)
        at SendMessage.main(SendMessage.java:38)

_________________________________________________________________
Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/



From tjarvi at qbang.org  Sat Jun 17 10:12:30 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 10:12:30 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
	<350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
Message-ID: <Pine.LNX.4.61.0606171010060.14139@www>

On Sat, 17 Jun 2006, Joachim Buechse wrote:

> Hello Trent,
>
> apparently the IOEXCL changes have not made it into 2.0. I will add
> them to achieve a minimal diff between 2.0 and 2.1.
>

Hi Joachim

As I recall the IOEXCL change was after 2.1-7.  I was just syncing with 
2.1-7.  We can release 2.1-8 and 2.0-8 with the same changes.

> One other thing that bugs me for a while...
>
> Shouldn't we replace "if !defined(TIOCSERGETLSR) && !defined(WIN32)"
> by a definition of its own "if defined(DRAINTHREAD)"? I think this
> would make the code clearer for people starting to read it.
>


Sure.  We can do that for -8.  The TIOCSERGETLSR code should be a special 
case not the expected.  I think only Linux uses it.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Sat Jun 17 10:48:21 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 10:48:21 -0600 (MDT)
Subject: [Rxtx] Looking for RXTX 2.0 for Intel Mac
In-Reply-To: <Pine.LNX.4.61.0606171010060.14139@www>
References: <p06230903c0b88613dca6@[10.0.1.7]>
	<03FD6CEC-F4C6-4028-A2CD-8843247D46EC@buechse.de>
	<Pine.LNX.4.61.0606161630030.14139@www>
	<350DCCF9-8656-4156-918A-17EF83E48D6C@buechse.de>
	<Pine.LNX.4.61.0606171010060.14139@www>
Message-ID: <Pine.LNX.4.61.0606171047310.14139@www>

On Sat, 17 Jun 2006, Trent Jarvi wrote:

> On Sat, 17 Jun 2006, Joachim Buechse wrote:
>
>> Hello Trent,
>>
>> apparently the IOEXCL changes have not made it into 2.0. I will add
>> them to achieve a minimal diff between 2.0 and 2.1.
>>
>
> Hi Joachim
>
> As I recall the IOEXCL change was after 2.1-7.  I was just syncing with
> 2.1-7.  We can release 2.1-8 and 2.0-8 with the same changes.
>

We could just move to 2.1-8 and 2.0-8.

--
Trent Jarvi
tjarvi at qbang.org


From brian.t.lamb at gmail.com  Tue Jun 13 13:54:13 2006
From: brian.t.lamb at gmail.com (Brian Lamb)
Date: Tue, 13 Jun 2006 15:54:13 -0400
Subject: [Rxtx] Windows XP Installation
Message-ID: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>

I've not installed Java packages on Windows before and am unsure how to
proceed. All the documentation I've seen provides detailed instructions on
how to install on Linux or Solaris. I was wondering how to install rxtx on
Windows XP.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060613/6f68cd5c/attachment-0023.html

From tjarvi at qbang.org  Sat Jun 17 13:57:03 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sat, 17 Jun 2006 13:57:03 -0600 (MDT)
Subject: [Rxtx] Windows XP Installation
In-Reply-To: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>
References: <39674dd0606131254q607e47cdr178a148cdb4dee58@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0606171356120.14139@www>

On Tue, 13 Jun 2006, Brian Lamb wrote:

> I've not installed Java packages on Windows before and am unsure how to
> proceed. All the documentation I've seen provides detailed instructions on
> how to install on Linux or Solaris. I was wondering how to install rxtx on
> Windows XP.
>

Hi Brian

Which rxtx version are you trying to install?

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Sun Jun 18 10:41:44 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Sun, 18 Jun 2006 18:41:44 +0200
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
References: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
Message-ID: <8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>

Hello Jon,

 From OSX's standpoint a symbolic link is not a device (as far as I  
know). What stops you from using tty.usbserial? Did you try hard- 
linking?

Regards,
Joachim

On 17.06.2006, at 17:32, Yoke K wrote:
> Hi,
>
> I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to  
> work with
> MAC OS X.
> I am using iTegno 3000 - USB GPRS Modem.
>
> Files in /dev and a symbolic link as follows:
>
> crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
> crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
> lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->  
> tty.usbserial
>
> In my SendMessage.java, I have this line:
> CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
>
> Appreciate any help ?
>
> - Jon
>
>
> Errors as follows:
>
>>> INFO: SMSLib API for Java / v1.2.2
>>> INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>> INFO: JRE Version: 1.5.0_06
>>> INFO: JRE Impl Version: 1.5.0_06-64
>>> INFO: O/S: Mac OS X / ppc / 10.4.6
>>> INFO: Using Wavecom (Generic) AT handler.
>
> SendMessage(): Send a message.
>   Using SMSLib API for Java v1.2.2
>
> Connecting ..... :
>>> INFO: CSerialDriver(): Connecting...
> Experimental:  JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
>>> INFO: CSerialDriver(): Disconnecting...
> gnu.io.NoSuchPortException
>         at
> gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java: 
> 218)
>         at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
>         at org.smslib.CService.connect(CService.java:197)
>         at SendMessage.main(SendMessage.java:38)
>
> _________________________________________________________________
> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Sun Jun 18 10:56:55 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 12:56:55 -0400
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>
References: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
	<8F48A471-CFB4-49F1-838C-668CA1DD00AE@buechse.de>
Message-ID: <7B6834E3-F41D-46B6-B979-55466BC73859@sympatico.ca>

Have you been able to get any other software to talk with your
modem? What port is it using? Have tried using the cu.usbserial
instead?

Andre

On 18-Jun-06, at 12:41 , Joachim Buechse wrote:

> Hello Jon,
>
>  From OSX's standpoint a symbolic link is not a device (as far as I
> know). What stops you from using tty.usbserial? Did you try hard-
> linking?
>
> Regards,
> Joachim
>
> On 17.06.2006, at 17:32, Yoke K wrote:
>> Hi,
>>
>> I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to
>> work with
>> MAC OS X.
>> I am using iTegno 3000 - USB GPRS Modem.
>>
>> Files in /dev and a symbolic link as follows:
>>
>> crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
>> crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
>> lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->
>> tty.usbserial
>>
>> In my SendMessage.java, I have this line:
>> CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
>>
>> Appreciate any help ?
>>
>> - Jon
>>
>>
>> Errors as follows:
>>
>>>> INFO: SMSLib API for Java / v1.2.2
>>>> INFO: Using port: /dev/ttyS1 @ 56000 baud.
>>>> INFO: JRE Version: 1.5.0_06
>>>> INFO: JRE Impl Version: 1.5.0_06-64
>>>> INFO: O/S: Mac OS X / ppc / 10.4.6
>>>> INFO: Using Wavecom (Generic) AT handler.
>>
>> SendMessage(): Send a message.
>>   Using SMSLib API for Java v1.2.2
>>
>> Connecting ..... :
>>>> INFO: CSerialDriver(): Connecting...
>> Experimental:  JNI_OnLoad called.
>> Stable Library
>> =========================================
>> Native lib Version = RXTX-2.1-7
>> Java lib Version   = RXTX-2.1-7
>>>> INFO: CSerialDriver(): Disconnecting...
>> gnu.io.NoSuchPortException
>>         at
>> gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:
>> 218)
>>         at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
>>         at org.smslib.CService.connect(CService.java:197)
>>         at SendMessage.main(SendMessage.java:38)
>>
>> _________________________________________________________________
>> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Sun Jun 18 17:33:08 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 19:33:08 -0400
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
Message-ID: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>

Hi,

I am have a program that I wrote in Java to communicate with a  
Bluetooth GPS device. I am
trying to get this working on my Mac, but I keep getting told that:

gnu.io.PortInUseException: Unknown Application

but

portIdentifier.isCurrentlyOwned()

returns false and when I do lsof on the device I am trying to connect  
to, I see no application
using it. As the same time if I go to the command line and use  
minicom I have no issues. The
exception happens with this call:

CommPort commPort = portIdentifier.open(null,0);

Any suggestions?

Andre


From ajmas at sympatico.ca  Sun Jun 18 17:45:11 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Sun, 18 Jun 2006 19:45:11 -0400
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
Message-ID: <30245B30-682D-4EAE-8084-8227B719F10D@sympatico.ca>

BTW My code snippet is:

     private InputStream connectToSerial () throws IOException,  
Exception
     {
         InputStream in = null;

         Enumeration portEnum = CommPortIdentifier.getPortIdentifiers();
         while ( portEnum.hasMoreElements() )
         {
             CommPortIdentifier portIdentifier = (CommPortIdentifier)  
portEnum.nextElement();
             System.out.println(portIdentifier.getName() + " - " +  
portIdentifier.getPortType() );
         }

         CommPortIdentifier portIdentifier =  
CommPortIdentifier.getPortIdentifier("/dev/cu.BTGPS-SPPslave-1");
         System.out.println("current owner: " +  
portIdentifier.getCurrentOwner());
         if ( portIdentifier.isCurrentlyOwned() )
         {
             System.out.println("Error: Port is currently in use");
             return null;
         }
         else
         {
             CommPort commPort = portIdentifier.open(this.getClass 
().getName(),2000);

             if ( commPort instanceof SerialPort )
             {
                 SerialPort serialPort = (SerialPort) commPort;
                 serialPort.setSerialPortParams 
(4800,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE 
);
                 in = serialPort.getInputStream();

                 return in;
             }
             else
             {
                 System.out.println("Error: Only serial ports are  
handled.");
             }
         }


         return in;
     }


On 18-Jun-06, at 19:33 , Andr?-John Mas wrote:

> Hi,
>
> I am have a program that I wrote in Java to communicate with a
> Bluetooth GPS device. I am
> trying to get this working on my Mac, but I keep getting told that:
>
> gnu.io.PortInUseException: Unknown Application
>
> but
>
> portIdentifier.isCurrentlyOwned()
>
> returns false and when I do lsof on the device I am trying to connect
> to, I see no application
> using it. As the same time if I go to the command line and use
> minicom I have no issues. The
> exception happens with this call:
>
> CommPort commPort = portIdentifier.open(null,0);
>
> Any suggestions?
>
> Andre
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From joachim at buechse.de  Mon Jun 19 05:54:49 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 13:54:49 +0200
Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ???
In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca>
Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de>

This is most likely due to a problem with lock files. If you have  
downloaded the binaries of 2.17 rxtx will try to create non-standard  
lock files on OSX. We have since changed the code to use OSX device  
locking - however the binaries have not been updated yet. The 2.18  
release fixing this issue is due shortly.

Regards,
Joachim

On 19.06.2006, at 01:33, Andr?-John Mas wrote:

> Hi,
>
> I am have a program that I wrote in Java to communicate with a
> Bluetooth GPS device. I am
> trying to get this working on my Mac, but I keep getting told that:
>
> gnu.io.PortInUseException: Unknown Application
>
> but
>
> portIdentifier.isCurrentlyOwned()
>
> returns false and when I do lsof on the device I am trying to connect
> to, I see no application
> using it. As the same time if I go to the command line and use
> minicom I have no issues. The
> exception happens with this call:
>
> CommPort commPort = portIdentifier.open(null,0);
>
> Any suggestions?
>
> Andre
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From joachim at buechse.de  Mon Jun 19 06:44:27 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 14:44:27 +0200
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <4490A60A.9090305@sun.com>
References: <4490A60A.9090305@sun.com>
Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>

Hello Paul,

I just downloaded the "generic" javax.comm version now available. A  
first check indicates, that it was compiled with a JDK 1.4 javac  
without setting the target classfile version. In other words in can  
not be loaded by 1.1-1.3 VMs (or PersonalJava).

Do you see any chance to provide a version compiled with classfile  
format 45.3 (ie JVM1.1).

---
52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose  
javax.comm.SerialPort | head -5
Compiled from "SerialPort.java"
public abstract class javax.comm.SerialPort extends javax.comm.CommPort
   SourceFile: "SerialPort.java"
   minor version: 0
   major version: 48
---

Best regards,
Joachim


On 15.06.2006, at 02:12, Paul Klissner wrote:

> Hello RxTx community,
>
> I finally think I have a compromise in place that will stand in the  
> gap.
>
> If you go to http://www.sun.com and search for javax.comm, you'll
> get taken to a download page, where now users can get a copy of the
> comm.jar file out of 2.0.3, along with just a license and a README.
>
> I trust this will suffice until such time as RxTx decided to implement
> their own java classes or we can get a JSR going to mitigate some
> of the problems (the readme in the comm.jar 2.0.3 zip file
> contains my thoughts on that).
>
> Thanks,
> Paul
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From ajmas at sympatico.ca  Mon Jun 19 09:11:45 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Mon, 19 Jun 2006 11:11:45 -0400
Subject: [Rxtx] Examples added to Wiki
Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

I have added a couple of examples to the Wiki:

http://rxtx.qbang.org/wiki/index.php/Examples

If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :)

Andre



From paul.klissner at sun.com  Mon Jun 19 10:42:47 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Mon, 19 Jun 2006 09:42:47 -0700
Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun
In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>
References: <4490A60A.9090305@sun.com>
	<03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de>
Message-ID: <4496D407.1090609@sun.com>

Joachim Buechse wrote:
> Hello Paul,
> 
> I just downloaded the "generic" javax.comm version now available. A  
> first check indicates, that it was compiled with a JDK 1.4 javac  
> without setting the target classfile version. In other words in can  
> not be loaded by 1.1-1.3 VMs (or PersonalJava).
> 
> Do you see any chance to provide a version compiled with classfile  
> format 45.3 (ie JVM1.1).
> 
> ---
> 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose  
> javax.comm.SerialPort | head -5
> Compiled from "SerialPort.java"
> public abstract class javax.comm.SerialPort extends javax.comm.CommPort
>    SourceFile: "SerialPort.java"
>    minor version: 0
>    major version: 48
> ---

I cannot promise when I can do that. Since we thought we were done
with javax.comm, the build environment got moved around, and right
now it doesn't even compile in it's new home.  I tried and it was
not cooperative at all. I was never impressed with that workspace
(in fact far far from it, it is a mess, which is why I migrated 3.0
to ant and never looked back).  It will take some real determination
for me to rebuild it, and frankly, right now I'm swamped.  If I can
find a bit of time over the next few weeks to do it, and it isn't
too bad an ordeal, I will.

Posting that will give me an excuse to post javax.comm 3.0, Update 2 as
well, while I'm working with the people who put content up on our
download center.  The only reason for a new update to 3.0 is that
I've changed the distribution to provide ispt (Interactive Serial
Port Tool), such that it can be launched as soon as the zip file
is unpacked, via a provided script.  ISPT is a command line
interactive tool for  manipulating one or two serial port,
sending data, managing events, etc... I've found it to be so useful
for doing certain kinds of validation  that I assume others will
find it useful to.  ISPT is already in 3.0u1, but one has to set
up their own classpath and launch it and since few people ever read
the documentation most won't know about it.  I've added the ability
to set stop bits and parity since 3.0u1 too.  But I digress.

Paul


From joachim at buechse.de  Mon Jun 19 11:01:28 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Mon, 19 Jun 2006 19:01:28 +0200
Subject: [Rxtx] load mechanism of 2.0x
Message-ID: <CFD1440C-21AA-4D3B-9EA6-270D0FF9D6FC@buechse.de>

Good day,

I am trying to figure out, how the 2.0x distribution interacts with  
Suns implementation of javax.comm.CommPortIdentifier.

1) Apparently one can put javax.comm.properties in {java.home}/lib
2) The javax.comm package also reacts to -Djavax.comm.properties="...."

Looking at the javap output it also seems like CommPortIdentifier  
tries to find it's jar file and load the properties from there??


What I'm really looking for is a solution that allows using  
javax.comm with RXTX without modifying the VM installation. So I  
would prefer not to use 1) but I can't figure out how to use 2).

Any hints are welcome,
Joachim



From bob_tai2001 at yahoo.com  Mon Jun 19 15:00:35 2006
From: bob_tai2001 at yahoo.com (Bob Tai)
Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT)
Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place
	to start?
Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>

Hi, 

I got  rxtx Windows 2000 installed.  I did not use the
"best" way ... I just follow the insturuction and dump
the necessary files into the jre... I know it's "best"
idea, I got lazy didn't want to change my setting to
my Eclipse and classpath.

I was able to modify SimpleWrite.java to print on my
AddMaster serial printer.  I think I am ready to code!
But I need to make sure I can handle exceptions and so
on.  I notice the \samples\NullDriver\  has two files
seems to have some of the require method done, should
I start coding from those file?  I like the idea it
has the "time out" and basic exceptions done.   I am
slowly digging into the samples, but if you think any
of the code from Sun is good to checkout please let me
know.

btw, http://rxtx.qbang.org/wiki/index.php/Examples/
was very helpful, wish there are more examples.

thank you,

    Bob


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Mon Jun 19 15:55:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT)
Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good
 place to start?
In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>
References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606191542260.14139@www>

> I am
> slowly digging into the samples, but if you think any
> of the code from Sun is good to checkout please let me
> know.
>

I think NullDriver.java was an example stub driver for implementing 
something like rxtx.  It has been a while.  Unless they have been updated, 
you will find the examples are very dated.  You can look at how they use 
the port but avoid the GUI and hard coded variables (number of ports for 
instance).

There was no Swing and nobody knew what requirements today's compilers 
would make on code.  The examples worked fine with jdk 1.1 but times have 
changed.

--
Trent Jarvi
tjarvi at qbang.org


From tropicsu at hotmail.com  Mon Jun 19 19:49:08 2006
From: tropicsu at hotmail.com (Yoke K)
Date: Tue, 20 Jun 2006 01:49:08 +0000
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F203B2C69ABFF994B3934FBDA800@phx.gbl>
Message-ID: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>

An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/fa588f00/attachment-0014.html

From ajmas at sympatico.ca  Mon Jun 19 21:14:37 2006
From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=)
Date: Mon, 19 Jun 2006 23:14:37 -0400
Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException
In-Reply-To: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>
References: <BAY22-F1177C20F3ECAC389A3F882DA870@phx.gbl>
Message-ID: <CA22AB2A-5712-458B-9984-68477C6042AF@sympatico.ca>

Regarding the PortInUseException, I had a similar issue and got
this response from the mailing list:

   http://mailman.qbang.org/pipermail/rxtx/Week-of- 
Mon-20060619/062838.html

Andre
On 19-Jun-06, at 21:49 , Yoke K wrote:

> Hi Andre, Joachim
>
> I have tried using /dev/tty.usbserial and also /dev/cu.usbserial  
> and it also reported error as  "gnu.io.PortInUseException".
>
> The iTegno modem works in windows environment. As I moving around  
> using my ibook and I need to get it work on MAC OS as well.
>
> >> INFO: SMSLib API for Java / v1.2.2
> >> INFO: Using port: /dev/tty.usbserial @ 115200 baud.
> >> INFO: JRE Version: 1.5.0_06
> >> INFO: JRE Impl Version: 1.5.0_06-64
> >> INFO: O/S: Mac OS X / ppc / 10.4.6
> >> INFO: Using Wavecom (Generic) AT handler.
>
> SendMessage(): Send a message.
> Using SMSLib API for Java v1.2.2
>
> Connecting ..... :
> >> INFO: CSerialDriver(): Connecting...
> Experimental: JNI_OnLoad called.
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version = RXTX-2.1-7
> >> INFO: CSerialDriver(): Disconnecting...
> gnu.io.PortInUseException: Unknown Application
> at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354)
> at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1)
> at org.smslib.CService.connect(CService.java:197)
> at SendMessage.main(SendMessage.java:38)
>
> Thanks.
>
> - Jon
>
>
>
>
> ====================
>
> Hello Jon,
>
> From OSX's standpoint a symbolic link is not a device (as far as I
> know). What stops you from using tty.usbserial? Did you try hard-
> linking?
>
> Regards,
> Joachim
>
>
>
> From:  "Yoke K" <tropicsu at hotmail.com>
> To:  rxtx at qbang.org
> Subject:  RXTX-2.1-7 / MAC OS X / NoSuchPortException
> Date:  Sat, 17 Jun 2006 15:32:48 +0000
> >Hi,
> >
> >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to
> >work with MAC OS X.
> >I am using iTegno 3000 - USB GPRS Modem.
> >
> >Files in /dev and a symbolic link as follows:
> >
> >crw-rw-rw-    1 root  wheel       9,   9 Jun 17 22:58 cu.usbserial
> >crw-rw-rw-    1 root  wheel       9,   8 Jun 17 22:58 tty.usbserial
> >lrwxr-xr-x    1 root  wheel            0 Jun 17 22:37 ttyS1 ->
> >tty.usbserial
> >
> >In my SendMessage.java, I have this line:
> >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", "");
> >
> >Appreciate any help ?
> >
> >- Jon
> >
> >
> >Errors as follows:
> >
> >>>INFO: SMSLib API for Java / v1.2.2
> >>>INFO: Using port: /dev/ttyS1 @ 56000 baud.
> >>>INFO: JRE Version: 1.5.0_06
> >>>INFO: JRE Impl Version: 1.5.0_06-64
> >>>INFO: O/S: Mac OS X / ppc / 10.4.6
> >>>INFO: Using Wavecom (Generic) AT handler.
> >
> >SendMessage(): Send a message.
> >  Using SMSLib API for Java v1.2.2
> >
> >Connecting ..... :
> >>>INFO: CSerialDriver(): Connecting...
> >Experimental:  JNI_OnLoad called.
> >Stable Library
> >=========================================
> >Native lib Version = RXTX-2.1-7
> >Java lib Version   = RXTX-2.1-7
> >>>INFO: CSerialDriver(): Disconnecting...
> >gnu.io.NoSuchPortException
> >        at
> >gnu.io.CommPortIdentifier.getPortIdentifier 
> (CommPortIdentifier.java:218)
> >        at org.smslib.CSerialDriver.open(CSerialDriver.java:70)
> >        at org.smslib.CService.connect(CService.java:197)
> >        at SendMessage.main(SendMessage.java:38)
> >
> >_________________________________________________________________
> >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
> >
>
> Find love online with MSN Personals
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Tue Jun 20 02:35:24 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 10:35:24 +0200
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>

Hello everybody,

I have been fighting a bit with the javax.comm version of RXTX the  
last days. I am working on the README .OSX now and try to figure out  
which should be the "suggested" installation.

The facts:
------

- the "generic" comm.jar version of javax.comm which has been made re- 
available tries to load com.sun.comm.SolarisDriver
- this classname can be overridden ONLY by putting a file  
javax.comm.properties in {java.home}/lib
- if it is not overridden and SolarisDriver.class is not found  
CommPortIdentifier will be disfunctional (in particual it is not  
possible to add CommPort's via CommPortIdentifier.add).
- the license distributed with comm.jar does not allow the  
modification/addition of classes in javax.comm (however no mention of  
com.sun...)


What really bothers me is to suggest putting this config file in the  
"global" vm installation. This is particularly ugly on the Mac as  
there are several VM installations and the file may be forgotten.  
Additionally it may create versioning problems. I prefer an  
installation where all files are local to the application (even  
comm.jar).

In my opinion the ideal situation would be:
------

1) The author of a program compiles against javax.comm.
2a) For platforms supported by Sun the user is free to use the 3.0  
comm.jar download from Sun
2b) For platforms not supported by Sun the user adds RXTXComm.jar to  
the classpath of the application (and librxtxSerial.jnilib to the  
application directory). Also he will need the 2.0.3 generic comm.jar  
from Sun.
3) Nobody messes with the global VM installation.

Of course 2a) and 2b) could be handled by the author of the program  
via an appropriate installer. The author could also decide to always  
use RXTX and include the generic javax.comm classes as well as the  
RXTX classes in his application jar. [If he further uses an explicit  
call to System.load() he may even include the jnilib(s) in the jar,  
extract it (based on the platform name) at runtime to a temp file and  
load it from there.]


Suggested solution:
------

We only need to put the following class in the classpath BEFORE Suns  
comm.jar

   package com.sun.comm;
   public class SolarisDriver extends gnu.io.RXTXCommDriver {
   }

This is not "the pure art" (TM). It depends on an implementation  
detail of the generic driver. However, so does the  
javax.comm.properties file - as we have seen when Sun released 3.0.  
It has the following advantages:

- The "generic" javax.comm implementation will happily load this  
class as its primary driver.
- No javax.comm.properties file is required.
- This does not violate the javax.comm license agreement as there is  
no mention of the "com.sun.comm" package in this license agreement at  
all.
- Authors packaging comm.jar with their application can strip out all  
com.sun.comm classes from comm.jar


Please comment!

Joachim



From joachim at buechse.de  Tue Jun 20 02:50:36 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 10:50:36 +0200
Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar
Message-ID: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>

There has been some discussions about the best way to install RXTX  
and where to place files.

I suggest that,

- we include the native libraries for the most common operating  
systems (in a special version of) RXTXcomm.jar
- we add loader code which tries to extract and load the platform  
specific binary at runtime
- on failure the current mechanism remains as a fallback

Wether the current mechanism should have priority (ie loadLibrary  
before load) remains to be discussed.


The advantages of this solution are
  - users of RXTX do not need to worry about java/platform specific  
file placement.
  - authors of applications may fully merge RXTX into their  
application jar (which provides a double-clickable application for  
Windows and OSX, Linux?).

Please comment,
Joachim

PS: Of course the suggested solution is already possible today,  
however relatively few programmers know how to correctly extract a  
binary resource file via the class loader and load it as a native  
library.


From tjarvi at qbang.org  Tue Jun 20 03:58:12 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT)
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
Message-ID: <Pine.LNX.4.61.0606200335190.14139@www>

> 2a) For platforms supported by Sun the user is free to use the 3.0
> comm.jar download from Sun
> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to
> the classpath of the application (and librxtxSerial.jnilib to the
> application directory). Also he will need the 2.0.3 generic comm.jar
> from Sun.

As there are no plans to support CommAPI 3.0 due to the limitations in its 
implementation mentioned before, I would not recommend projects use Sun's 
3.0 comm.jar.  They will lose the freedom to chose their low level 
implementation by being locked into vendor specific modifications.

Projects should chose between platform neutrality in CommAPI 2.0 and 
reduced platform neutrality in commapi 3.0.  Projects should also strongly 
consider the fact that the 2.0 comm.jar targets only a reduced number of 
JVMs.

Projects can go with rxtx 2.1 or other packages but should probably only 
consider using Sun CommAPI with rxtx if they did so in the past.  They 
should take steps to no longer depend upon this option being available.

> Suggested solution:
> ------
>
> We only need to put the following class in the classpath BEFORE Suns
> comm.jar
>
>   package com.sun.comm;
>   public class SolarisDriver extends gnu.io.RXTXCommDriver {
>   }
>
> This is not "the pure art" (TM). It depends on an implementation
> detail of the generic driver. However, so does the
> javax.comm.properties file - as we have seen when Sun released 3.0.
> It has the following advantages:
>
> - The "generic" javax.comm implementation will happily load this
> class as its primary driver.
> - No javax.comm.properties file is required.
> - This does not violate the javax.comm license agreement as there is
> no mention of the "com.sun.comm" package in this license agreement at
> all.
> - Authors packaging comm.jar with their application can strip out all
> com.sun.comm classes from comm.jar
>

I would not encourage people to place packages in the com.sun.comm 
namespace.  Authors using Sun's commapi 2.0 should just realize it is 
greatly limited in practical utility and consider moving to something that 
isn't being rescued from EOL.

The primary focus of this release is projects previously depending upon 
Sun CommAPI + RXTX.  There are no plans at this time to provide future 
support in this arrangement due to technical incompatabilities we have no 
control over in commapi 3.0 and limited utility of Sun's generic comm.jar 
in commapi 2.0 offered.  Projects should be aware of this so they can make 
appropriate plans.

--
Trent Jarvi
tjarvi at qbang.org


From paul.klissner at sun.com  Tue Jun 20 05:24:00 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Tue, 20 Jun 2006 04:24:00 -0700
Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x
In-Reply-To: <Pine.LNX.4.61.0606200335190.14139@www>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
	<Pine.LNX.4.61.0606200335190.14139@www>
Message-ID: <4497DAD0.10803@sun.com>

Trent Jarvi wrote:
>> 2a) For platforms supported by Sun the user is free to use the 3.0
>> comm.jar download from Sun
>> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to
>> the classpath of the application (and librxtxSerial.jnilib to the
>> application directory). Also he will need the 2.0.3 generic comm.jar
>> from Sun.
> 
> As there are no plans to support CommAPI 3.0 due to the limitations in its 
> implementation mentioned before, I would not recommend projects use Sun's 
> 3.0 comm.jar.  They will lose the freedom to chose their low level 
> implementation by being locked into vendor specific modifications.
> 
> Projects should chose between platform neutrality in CommAPI 2.0 and 
> reduced platform neutrality in commapi 3.0.  Projects should also strongly 
> consider the fact that the 2.0 comm.jar targets only a reduced number of 
> JVMs.

Well, that's a little ambiguous because the API is the same
either way.  We're talking about Sun's implementation vs.
other implementations.
> 
> Projects can go with rxtx 2.1 or other packages but should probably only 
> consider using Sun CommAPI with rxtx if they did so in the past.  They 
> should take steps to no longer depend upon this option being available.

3.0 is platform centric because there is a need to add some
platform awareness to Sun's implementation, and the choices
for how to do that are limited by the constraints of the API,
as mentioned in the javax.comm 2.0.3 comm.jar download's README.

I am really advocating getting a JSR open (http://www.jcp.org)
to push a new comm API that is more pluggable, platform neutral
and addresses some of the deficiencies of the current API. Then
we can achieve the optimal of platform neutrality while
simulataneously allowing the API to flexibly adapt to
heterogeneous environments.

This is not a question of attitude, this is an issue of resources,
time and commitment.  The current owners of javax.comm within
Sun would like nothing better than to see the ideal reached for
the API and a model that will extend well beyond the foreseeable
future and work for the industry overall.



> 
>> Suggested solution:
>> ------
>>
>> We only need to put the following class in the classpath BEFORE Suns
>> comm.jar
>>
>>   package com.sun.comm;
>>   public class SolarisDriver extends gnu.io.RXTXCommDriver {
>>   }
>>
>> This is not "the pure art" (TM). It depends on an implementation
>> detail of the generic driver. However, so does the
>> javax.comm.properties file - as we have seen when Sun released 3.0.
>> It has the following advantages:
>>
>> - The "generic" javax.comm implementation will happily load this
>> class as its primary driver.
>> - No javax.comm.properties file is required.
>> - This does not violate the javax.comm license agreement as there is
>> no mention of the "com.sun.comm" package in this license agreement at
>> all.
>> - Authors packaging comm.jar with their application can strip out all
>> com.sun.comm classes from comm.jar
>>
> 
> I would not encourage people to place packages in the com.sun.comm 
> namespace.  Authors using Sun's commapi 2.0 should just realize it is 
> greatly limited in practical utility and consider moving to something that 
> isn't being rescued from EOL.
> 
> The primary focus of this release is projects previously depending upon 
> Sun CommAPI + RXTX.  There are no plans at this time to provide future 
> support in this arrangement due to technical incompatabilities we have no 
> control over in commapi 3.0 and limited utility of Sun's generic comm.jar 
> in commapi 2.0 offered.  Projects should be aware of this so they can make 
> appropriate plans.

Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86,
or need the powerful portmapping features in javax.com 3.0, or would like to
acquire the Interactive Serial Port Test utility.

-Paul


From paul.klissner at sun.com  Tue Jun 20 05:33:44 2006
From: paul.klissner at sun.com (Paul Klissner)
Date: Tue, 20 Jun 2006 04:33:44 -0700
Subject: [Rxtx] Suggested installation RXTX 2.0x...
In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de>
Message-ID: <4497DD18.70207@sun.com>

Joachim Buechse wrote:
> Hello everybody,
> 
> I have been fighting a bit with the javax.comm version of RXTX the  
> last days. I am working on the README .OSX now and try to figure out  
> which should be the "suggested" installation.
> 
> The facts:
> ------
> 
> - the "generic" comm.jar version of javax.comm which has been made re- 
> available tries to load com.sun.comm.SolarisDriver
> - this classname can be overridden ONLY by putting a file  
> javax.comm.properties in {java.home}/lib
> - if it is not overridden and SolarisDriver.class is not found  
> CommPortIdentifier will be disfunctional (in particual it is not  
> possible to add CommPort's via CommPortIdentifier.add).
> - the license distributed with comm.jar does not allow the  
> modification/addition of classes in javax.comm (however no mention of  
> com.sun...)
> 
> 
> What really bothers me is to suggest putting this config file in the  
> "global" vm installation. This is particularly ugly on the Mac as  
> there are several VM installations and the file may be forgotten.  
> Additionally it may create versioning problems. I prefer an  
> installation where all files are local to the application (even  
> comm.jar).
> 
> In my opinion the ideal situation would be:
> ------
> 
> 1) The author of a program compiles against javax.comm.
> 2a) For platforms supported by Sun the user is free to use the 3.0  
> comm.jar download from Sun
> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to  
> the classpath of the application (and librxtxSerial.jnilib to the  
> application directory). Also he will need the 2.0.3 generic comm.jar  
> from Sun.
> 3) Nobody messes with the global VM installation.
> 
> Of course 2a) and 2b) could be handled by the author of the program  
> via an appropriate installer. The author could also decide to always  
> use RXTX and include the generic javax.comm classes as well as the  
> RXTX classes in his application jar. [If he further uses an explicit  
> call to System.load() he may even include the jnilib(s) in the jar,  
> extract it (based on the platform name) at runtime to a temp file and  
> load it from there.]
> 

This was how the Sun implementation originated (I did not write
that code).  I completely agree, and I fixed the whole conf file
locating mechanism in 3.0 to avoid the problems youmentioned.
However, I was unaware of how RxTx was using Sun's implementation,
so I didn't architect it in such a way as to avoid namespace pollution
in the native space in for the backend provider.  In retrospect,
I should have done that differently just as a design principle,
but at this point I don't have the spare cycles to get that all
re-factored.  Further, I'm loathe to do it, because the whole
thing will still be an under-the-hood hack due to the constraints
of the API itself.

Paul





From brian at mbari.org  Tue Jun 20 10:23:54 2006
From: brian at mbari.org (Brian Schlining)
Date: Tue, 20 Jun 2006 09:23:54 -0700
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>


Hi Joachim,

> There has been some discussions about the best way to install RXTX
> and where to place files.
>
> I suggest that,
>
> - we include the native libraries for the most common operating
> systems (in a special version of) RXTXcomm.jar
> - we add loader code which tries to extract and load the platform
> specific binary at runtime
> - on failure the current mechanism remains as a fallback

I like your suggestion. However, my understanding is that in general  
the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH  
(Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to  
be loaded by the JVM. The alternative is to point to your native lib  
directory using -Djava.library.path=/my/dir/with/native/libs when you  
launch the JVM. So, I'm very interested to know how you're planning  
to work around this.

> PS: Of course the suggested solution is already possible today,
> however relatively few programmers know how to correctly extract a
> binary resource file via the class loader and load it as a native
> library.

So how do you use it to dynamically load a native lib? I've read that  
you can't really modify the java.library.path after the JVM has been  
launched. (http://forum.java.sun.com/thread.jspa? 
threadID=627890&tstart=90)

Thanks

Brian Schlining
Software Engineer
http://www.mbari.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0023.html

From joachim at buechse.de  Tue Jun 20 09:20:29 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Tue, 20 Jun 2006 17:20:29 +0200
Subject: [Rxtx] 2.0x in sync with 2.1x
Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>

I have added most of the changes from the 2.1 branch to the 2.0 branch.

This includes
  - correction of illegal javadoc comments
  - implementation errors in handling of Thread.interrupt in  
RXTXPort.java
  - MacOS X locking without lock files/special user groups
  - XCode project which builds a universal binary library
  - updated documentation for OSX

I have done some minimal testing (only G4).
[Trent: there are still some changes you made for specific baud  
rates. I will not sync this, as I can not test them. From my  
perspective we are ready for 2.08/2.18]

The updated documentation can be found in the file README.OSX. Here  
it is:

------------------------ Required files -----------------------

To use or compile RXTX 2.0.x you need to downlad the "generic"  
version (2.0.3)
of the javax.comm implementation from Sun. The zip you download  
contains an
archive comm.jar which is required:

- To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar

- To run the app you will need comm.jar in the classpath or in  
{java.lib.path}


------------------------ Installation on MacOSX -----------------------

WARNING: Please read this section until the end.

---
Preparation
---

You may want to spare your users the burden of modifying the global VM
installation. OSX has several different VM versions installed by  
default and
regular users will be unable to figure out which version will load your
application.

If you provide the class

package com.sun.comm;
public class SolarisDriver extends gnu.io.RXTXCommDriver {
}

and make sure, that it is present in the classpath before Suns  
"generic" comm.jar
your users can skip the following step:

Create a file named
    javax.comm.properties
in the directory
    /System/Library/Frameworks/JavaVM.framework/Home/lib/
which contains (only) the following line (no leading space):
    Driver=gnu.io.RXTXCommDriver



----
The unsafe way of using RXTX on OS X:
----

RXTX can be installed by putting the files
   libSerial.jnilib
   RXTXcomm.jar
   comm.jar
into the folder
   /Library/Java/Extensions

This is NOT RECOMMENDED as it creates versioning conflicts among  
applications.
However you may be forced to install it this way if an application  
was written
for Windows or Linux, requires RXTX and you are not able to change  
its starter.


----
The safe way of using RXTX on OS X:
----

Make sure that you have no (older) version of RXTX installed in
   /Library/Java/Extensions
   /System/Library/Java/Extensions
   /usr/lib/java

Put
   libSerial.jnilib
in the directory of the application (the JavaVM will find it there). Add
   RXTXComm.jar
   comm.jar
to the application classpath or include the classes in the  
application jar.
(Some applications already include the RXTX classes in their  
application jar,
in which case only the file libSerial.jnilib is required).


----
History
----

Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation  
of lockfiles
required special permissions for the user executing an application  
based on RXTX.
To simplify the setup RXTX came with an installer modifying group  
permissions
and installing RXTX in the global location /Library/Java/Extensions.  
However
this was prune to versioning conflicts and is no longer recommended.

--------------------- Build instructions for OSX XCode  
-------------------

contributed by Joachim Buechse <joachim at buechse.de>
original version by Dmitry Markman <dmarkman at mac.com>

System requirements for building:
MacOSX 10.4
XCode 2.3

   open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj
   choose libSerial.jnilib target
   build

After the build you will find RXTXcomm.jar and libSerial.jnilib files  
in the
directory build/Development.

In case you can't find RXTXcomm.jar build the RXTXcomm target manually.
In case of (serious) problems feel free to contact joachim at buechse.de .



From tjarvi at qbang.org  Tue Jun 20 22:01:45 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT)
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
Message-ID: <Pine.LNX.4.61.0606202127270.14139@www>

> ---
> Preparation
> ---
>
> You may want to spare your users the burden of modifying the global VM
> installation. OSX has several different VM versions installed by
> default and
> regular users will be unable to figure out which version will load your
> application.
>
> If you provide the class
>
> package com.sun.comm;
> public class SolarisDriver extends gnu.io.RXTXCommDriver {
> }
>
> and make sure, that it is present in the classpath before Suns
> "generic" comm.jar
> your users can skip the following step:

Hi Joachim

With regards to the above, I have not seen that we have Sun's OK to 
promote that.  I'm not very comfortable with the distribution 
documentation advocating this without Sun agreeing.

I see your point but I'd rather not actively promote putting classes in 
Sun's namespace without permission if you don't mind.  This isn't about 
what is in a license.

I'll go through the code tomorrow night.  It was a late night at work 
today.  There is also a w32 fix comming for people opening and closing 
multiple ports.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Wed Jun 21 01:56:45 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 21 Jun 2006 09:56:45 +0200
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <Pine.LNX.4.61.0606202127270.14139@www>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
	<Pine.LNX.4.61.0606202127270.14139@www>
Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>

Hello Trent,

I guess we will not get an explicit OK from Sun for such a hack. I  
think Paul has made it pretty clear, that he does not have the  
resources to modify the 2.x or 3.x code for the needs of RXTX. I'm  
not thrilled but OK with the current API. Hence I dont agree with  
Paul's idea to start a new JSR to fix the implementation - but that's  
mainly because I dont have the time to push it. According to their  
Readme Sun sees no business case in having cross platform support for  
javax.comm - that is sad but it's none of my business. However I  
prefer to program versus javax.comm in my projects as this gives an  
advanced user the chance to exchange the provider without access to  
the code.

I interpret Pauls reponse to my original "Request for comment" as a  
quiet acceptance of the hack I propose (he did respond, but not at  
all to the sun.comm namespace suggestion). This is certainly not  
something we should put into RXTXcomm.jar but hinting a work around  
for implementation errors should be allowed. That's why I've choosen  
the wording "You may want to spare" and "If you provide". The company  
I worked for has choosen similar hacks for years to fix bugs in swing  
for JDK1.1 applications. Those hacks were usually included in their  
own swingpatch.jar.

Having said all that - I do not take it as an insult if you remove  
the paragraph from the Readme. I appreciate that you notified me  
before. It would be interesting to hear some more opinions from the  
list members...

Best regards,
Joachim


On 21.06.2006, at 06:01, Trent Jarvi wrote:

>> ---
>> Preparation
>> ---
>>
>> You may want to spare your users the burden of modifying the  
>> global VM
>> installation. OSX has several different VM versions installed by
>> default and
>> regular users will be unable to figure out which version will load  
>> your
>> application.
>>
>> If you provide the class
>>
>> package com.sun.comm;
>> public class SolarisDriver extends gnu.io.RXTXCommDriver {
>> }
>>
>> and make sure, that it is present in the classpath before Suns
>> "generic" comm.jar
>> your users can skip the following step:
>
> Hi Joachim
>
> With regards to the above, I have not seen that we have Sun's OK to
> promote that.  I'm not very comfortable with the distribution
> documentation advocating this without Sun agreeing.
>
> I see your point but I'd rather not actively promote putting  
> classes in
> Sun's namespace without permission if you don't mind.  This isn't  
> about
> what is in a license.
>
> I'll go through the code tomorrow night.  It was a late night at work
> today.  There is also a w32 fix comming for people opening and closing
> multiple ports.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Wed Jun 21 02:03:33 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Wed, 21 Jun 2006 10:03:33 +0200
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
	<6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
Message-ID: <BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>

See System.load(String) [it's also mentioned under the URL you posted].

Regards,
Joachim


On 20.06.2006, at 18:23, Brian Schlining wrote:

> So how do you use it to dynamically load a native lib? I've read  
> that you can't really modify the java.library.path after the JVM  
> has been launched. (http://forum.java.sun.com/thread.jspa? 
> threadID=627890&tstart=90)
>
> Thanks
>
> Brian Schlining
> Software Engineer
> http://www.mbari.org
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From baris.ozkan at elikasu.com.tr  Wed Jun 21 07:58:06 2006
From: baris.ozkan at elikasu.com.tr (Baris)
Date: Wed, 21 Jun 2006 16:58:06 +0300
Subject: [Rxtx] RS 232 ..additional parameters
Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>

Hi,
 
Currently i am developing an application that requires to connect to a
remote rs232 device through  a dialup connection.
 
My problem is that the communication needs several more connection
parameters (i extracted that information from the vendor's dll , listed at
the end of the message)
 
I explored rxtx API and src files and could not find methods to set a
majority  of the parameters.
Am i missing any point or does rxtx is limited to soem standard set of
functionality(e.g. commAPI)? How  is it possible ,if i want to put some
extensions(???) to current rxtx implementation?
 
I am not very good at rs232 programming so excuse me if this message  is
boring one.
 
Thanx
 
Baris Ozkan
 
 
A Listing of Parameters:
 
 
typedef struct _DCB {

DWORD DCBlength; /* sizeof(DCB) */

DWORD BaudRate; /* Baudrate at which running */

DWORD fBinary: 1; /* Binary Mode (skip EOF check) */

DWORD fParity: 1; /* Enable parity checking */

DWORD fOutxCtsFlow:1; /* CTS handshaking on output */

DWORD fOutxDsrFlow:1; /* DSR handshaking on output */

DWORD fDtrControl:2; /* DTR Flow control */

DWORD fDsrSensitivity:1; /* DSR Sensitivity */

DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */

DWORD fOutX: 1; /* Enable output X-ON/X-OFF */

DWORD fInX: 1; /* Enable input X-ON/X-OFF */

DWORD fErrorChar: 1; /* Enable Err Replacement */

DWORD fNull: 1; /* Enable Null stripping */

DWORD fRtsControl:2; /* Rts Flow control */

DWORD fAbortOnError:1; /* Abort all reads and writes on Error */

DWORD fDummy2:17; /* Reserved */

WORD wReserved; /* Not currently used */

WORD XonLim; /* Transmit X-ON threshold */

WORD XoffLim; /* Transmit X-OFF threshold */

BYTE ByteSize; /* Number of bits/byte, 4-8 */

BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */

BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */

char XonChar; /* Tx and Rx X-ON character */

char XoffChar; /* Tx and Rx X-OFF character */

char ErrorChar; /* Error replacement char */

char EofChar; /* End of Input character */

char EvtChar; /* Received Event character */

WORD wReserved1; /* Fill for now. */

} DCB, *LPDCB;

typedef struct _COMMTIMEOUTS {

DWORD ReadIntervalTimeout; /* Maximum time between read chars. */

DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */

DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */

DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */

DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */

} COMMTIMEOUTS,*LPCOMMTIMEOUTS;

dcb.fOutX = FALSE;

dcb.fInX = FALSE;

dcb.fOutxCtsFlow = FALSE;

dcb.fBinary = TRUE;

dcb.fRtsControl = RTS_CONTROL_ENABLE;

SetCommState(hComm , &dcb ); 

COMMTIMEOUTS commTimeOut;

GetCommTimeouts(hComm, &commTimeOut );

commTimeOut.WriteTotalTimeoutMultiplier = 1; 

commTimeOut.WriteTotalTimeoutConstant = 18; 

// commTimeOut.ReadIntervalTimeout = 28; 

commTimeOut.ReadIntervalTimeout = 0; 

// commTimeOut.ReadTotalTimeoutMultiplier = 184; 

commTimeOut.ReadTotalTimeoutMultiplier = 300; 

// commTimeOut.ReadTotalTimeoutConstant = 1200;

commTimeOut.ReadTotalTimeoutConstant = 1200;

SetCommTimeouts(hComm, &commTimeOut);

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0023.html

From ajmas at sympatico.ca  Wed Jun 21 08:14:26 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Wed, 21 Jun 2006 10:14:26 -0400
Subject: [Rxtx] When is 2.18 planned for?
Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

Just curious as to know if there is a target date for 2.18?

Andre



From brian at mbari.org  Wed Jun 21 09:36:00 2006
From: brian at mbari.org (Brian Schlining)
Date: Wed, 21 Jun 2006 08:36:00 -0700
Subject: [Rxtx] Request for comment: Inclusion of native libs in
	RXTXcomm.jar
In-Reply-To: <BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>
References: <F56D9AE7-8E12-4F88-A44E-690A4B9AFE8E@buechse.de>
	<6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org>
	<BAE2721A-E716-4986-84C6-A79ACCC45292@buechse.de>
Message-ID: <A21C9BC0-7894-4B08-AC82-44E11AB3D461@mbari.org>

Ha!!

I suppose I should read my own postings. ;-)

Thanks
B

On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote:

> See System.load(String) [it's also mentioned under the URL you  
> posted].
>
> Regards,
> Joachim
>
>
> On 20.06.2006, at 18:23, Brian Schlining wrote:
>
>> So how do you use it to dynamically load a native lib? I've read
>> that you can't really modify the java.library.path after the JVM
>> has been launched. (http://forum.java.sun.com/thread.jspa?
>> threadID=627890&tstart=90)

Brian Schlining
Software Engineer
http://www.mbari.org




From ajmas at sympatico.ca  Wed Jun 21 16:41:28 2006
From: ajmas at sympatico.ca (Andre-John Mas)
Date: Wed, 21 Jun 2006 18:41:28 -0400
Subject: [Rxtx] CVS build question
Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>

Hi,

Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X:

 The JCL extension to RxTx requires comm.jar
 If you intend to use RxTx for commapi support comm.jar
 needs to be located in  /System/Library/Frameworks/JavaVM.framework/
  Versions/1.5/Home/lib/ext/comm.jar

I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me.

On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native).

Andre






From tjarvi at qbang.org  Wed Jun 21 18:00:04 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT)
Subject: [Rxtx] CVS build question
In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606211756310.14139@www>

On Wed, 21 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> Is the CVS repository meant to build for gnu.io or javax.comm? I ask 
> this, because I see the following when calling ./configure from MacOS X:
>
> The JCL extension to RxTx requires comm.jar
> If you intend to use RxTx for commapi support comm.jar
> needs to be located in  /System/Library/Frameworks/JavaVM.framework/
>  Versions/1.5/Home/lib/ext/comm.jar
>
> I am wanting to build for the gnu.io package, since I want to jump ahead 
> and see if the changes, intended for 2.18 for MacOS X, work for me.
>
> On a side note /Library/Java/Extensions should be included as a valid 
> search path for the JAR, since this is where Apple recommends placing 
> third party extensions (both Java and native).
>

rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel"
rxtx 2.0 src is obtained with "cvs checkout rxtx-devel"

rxtx 2.1 is a complete package in namespace gnu.io
rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 18:02:23 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT)
Subject: [Rxtx] When is 2.18 planned for?
In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <Pine.LNX.4.61.0606211800180.14139@www>

On Wed, 21 Jun 2006, Andre-John Mas wrote:

> Hi,
>
> Just curious as to know if there is a target date for 2.18?
>

Hi Andre

"When it is ready" :)

Probably this weekend.  Maybe sooner.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 18:10:18 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT)
Subject: [Rxtx] RS 232 ..additional parameters
In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>
References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades>
Message-ID: <Pine.LNX.4.61.0606211805010.14139@www>

On Wed, 21 Jun 2006, Baris wrote:

> Hi,
>
> Currently i am developing an application that requires to connect to a
> remote rs232 device through  a dialup connection.
>
> My problem is that the communication needs several more connection
> parameters (i extracted that information from the vendor's dll , listed at
> the end of the message)
>
> I explored rxtx API and src files and could not find methods to set a
> majority  of the parameters.
> Am i missing any point or does rxtx is limited to soem standard set of
> functionality(e.g. commAPI)? How  is it possible ,if i want to put some
> extensions(???) to current rxtx implementation?
>
> I am not very good at rs232 programming so excuse me if this message  is
> boring one.
>
> Thanx
>

Hi Baris

> typedef struct _DCB {
> typedef struct _COMMTIMEOUTS {

These are all handled in termios.c.  It is possible to add extensions to 
rxtx 2.1.  It may well be that the defaults are the same for the variables 
not covered by the existing API.  You can dump the DCB and COMMTIMEOUTS 
from inside termios.c to compare.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Wed Jun 21 20:23:30 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT)
Subject: [Rxtx] 2.0x in sync with 2.1x
In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>
References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de>
	<Pine.LNX.4.61.0606202127270.14139@www>
	<789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de>
Message-ID: <Pine.LNX.4.61.0606212012210.14139@www>

> I'm
> not thrilled but OK with the current API. Hence I dont agree with
> Paul's idea to start a new JSR to fix the implementation - but that's
> mainly because I dont have the time to push it. According to their
> Readme Sun sees no business case in having cross platform support for
> javax.comm - that is sad but it's none of my business. However I
> prefer to program versus javax.comm in my projects as this gives an
> advanced user the chance to exchange the provider without access to
> the code.

Hi Joachim

With regards to the JSR, I think that would be Doug's call.  The effort I 
put in would have to be on my own time which would not be a great deal.  I 
could help things go smoothly but thats not the same as pushing something 
through.

--
Trent Jarvi
tjarvi at qbang.org



From vt at freehold.crocodile.org  Wed Jun 21 21:05:22 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Wed, 21 Jun 2006 20:05:22 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
Message-ID: <449A08F2.3020106@freehold.crocodile.org>

Hello all,

I know this question may belong to JSR lists, but since all interested 
parties are here, I thought I just ask this question here, again...

A while ago I run into a problem and wrote a rant, here: 
http://servomaster.sourceforge.net/dev/serial-usb.html
At the time of writing I didn't think of adding another possible 
solution - changing the CommAPI specs to support removable devices. 
Apparently, Serial/USB bridges are here to stay, and this issue has to 
be addressed.

Wonder if anything changed since, and any abstractions for supporting 
removable devices made it into current or future Java CommAPI drafts - 
Paul, any comments?

--vt



From joachim at buechse.de  Thu Jun 22 01:59:54 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 22 Jun 2006 09:59:54 +0200
Subject: [Rxtx] CVS build question
In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca>
Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de>

Hello Andre,

I am not sure how well the configure/make mechanism will work on OSX.  
I know that a while ago some contributors tried to get configure/make  
working on OSX but from comments I found in the readmes this work was  
only partially successfull. For compilation on OSX we have used the  
ProjectBuilder/XCode projects you can find in MACOSX_IDE.

Regarding the  ./configure comment:
RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config  
file javax.comm.properties. The later MUST reside in {java.home}/lib.  
As the two only work together putting comm.jar into  /Library/Java/ 
Extensions  and hence making it available to all current and future  
VM installations will only add to confusion.

Regards,
Joachim

On 22.06.2006, at 00:41, Andre-John Mas wrote:

> Hi,
>
> Is the CVS repository meant to build for gnu.io or javax.comm? I  
> ask this, because I see the following when calling ./configure from  
> MacOS X:
>
>  The JCL extension to RxTx requires comm.jar
>  If you intend to use RxTx for commapi support comm.jar
>  needs to be located in  /System/Library/Frameworks/JavaVM.framework/
>   Versions/1.5/Home/lib/ext/comm.jar
>
> I am wanting to build for the gnu.io package, since I want to jump  
> ahead and see if the changes, intended for 2.18 for MacOS X, work  
> for me.
>
> On a side note /Library/Java/Extensions should be included as a  
> valid search path for the JAR, since this is where Apple recommends  
> placing third party extensions (both Java and native).
>
> Andre
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From joachim at buechse.de  Thu Jun 22 02:51:05 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 22 Jun 2006 10:51:05 +0200
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449A08F2.3020106@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>

Hello Vadim,

I think that your rant is to the point. However it is a bit like  
saying that Windows is at the source of email degradation and the  
only solution is to have users switch to safer operating systems.

I don't see how javax.comm or RXTX can address the problems you  
mention. Of course it would be super cool if javax.comm could magicly  
find the "matching" usb-device and query it's configuration via the  
usb protocol - however this magic (mapping /dev/xyz to its underlying  
USB device) is not supported by any kernel APIs I am aware of. It  
could be supported via POSSIX ioctl calls but then you should address  
your rant to the POSSIX group...

So for the time beeing it's either up to the virtual comm port driver  
to provide a usefull name under /dev/ or to the user choosing the  
right port to use. One example of a smart(er) com port driver is the  
KDDI driver for OSX, which will create device names like "/dev/ 
cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- 
encoded into the bridge chip. The same driver for windows also has  
some options allowing it in theory to recreate the same COMx every  
time a device is plugged/unplugged.

For most industrial applications however it will be up to the user to  
choose the right port (without getting a lot of help doing so).

Probing serial ports can go wrong, that's right. However any serial  
device developper would be well adviced to implement a basic set of  
Hayes AT modem commands (be it a modem or not). Especially AT I0.  
Anyone failing to do so risks that the users favourite TCP/PPP/FAX  
application or stack will kill the device in short time.

Best regards,
Joachim


On 22.06.2006, at 05:05, Vadim Tkachenko wrote:

> Hello all,
>
> I know this question may belong to JSR lists, but since all interested
> parties are here, I thought I just ask this question here, again...
>
> A while ago I run into a problem and wrote a rant, here:
> http://servomaster.sourceforge.net/dev/serial-usb.html
> At the time of writing I didn't think of adding another possible
> solution - changing the CommAPI specs to support removable devices.
> Apparently, Serial/USB bridges are here to stay, and this issue has to
> be addressed.
>
> Wonder if anything changed since, and any abstractions for supporting
> removable devices made it into current or future Java CommAPI drafts -
> Paul, any comments?
>
> --vt
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From vt at freehold.crocodile.org  Thu Jun 22 13:16:03 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 12:16:03 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
Message-ID: <20060622191603.GA17487@freehold.crocodile.org>

Hello Joachim,

> I think that your rant is to the point. However it is a bit like  
> saying that Windows is at the source of email degradation and the  
> only solution is to have users switch to safer operating systems.

I guess the problem is that the rant itself is obsolete and has to be
updated according to latest developments. At the time of writing there
weren't that many bridges around, and the trend didn't manifest itself as it
does now.

> I don't see how javax.comm or RXTX can address the problems you  
> mention.

I would agree that javax.comm won't be able to address the problem, at least
in the short run. As for RxTx - well, nobody prevents it from being a
superset of CommAPI specification, right? RxTx being the de-facto standard
for quite a few platforms, I'd daresay the standard may follow.

> Of course it would be super cool if javax.comm could magicly find the
> "matching" usb-device and query it's configuration via the usb protocol -
> however this magic (mapping /dev/xyz to its underlying USB device) is not
> supported by any kernel APIs I am aware of. It could be supported via
> POSSIX ioctl calls but then you should address your rant to the POSSIX
> group...

As a matter of fact, my bigger concern is addressing the fact that a serial
device can now be removable. This hasn't been the case before, and it
clearly is now. Regarding the above, well, I guess if we accept this fact,
we also need to accept the fact that we need at least rudimentary means of
identification of a serial device. For the USB case, it would usually be the
vendor/product ID, plus possible serial number - but it is irrelevant what
exactly the identifying information is, as long as it allows to identify the
device.

A paradigm shift is required, this is what I wanted to say. Serial devices
can be removed and replaced, it's now our turn to learn to deal with it.

> Joachim

--vt


From jredman at ergotech.com  Thu Jun 22 13:41:44 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 13:41:44 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
Message-ID: <449AF278.6000903@ergotech.com>


Vadim Tkachenko wrote:
> A paradigm shift is required, this is what I wanted to say. Serial devices
> can be removed and replaced, it's now our turn to learn to deal with it.

The removal if the serial port hardly significantly different from the 
removal of the device attached to the serial port.   Different, 
slightly, but not a "paradigm shift".

And yes, someone could unplug a USB serial device and plug it into a 
different USB port so that it has a different name/number, but they 
could do that with the device itself, move it from com1 to com2.

Am I missing something?

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 13:57:27 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 12:57:27 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449AF278.6000903@ergotech.com>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
Message-ID: <20060622195727.GA20247@freehold.crocodile.org>

On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote:
> 
> Vadim Tkachenko wrote:
> > A paradigm shift is required, this is what I wanted to say. Serial devices
> > can be removed and replaced, it's now our turn to learn to deal with it.
> 
> The removal if the serial port hardly significantly different from the 
> removal of the device attached to the serial port.   Different, 
> slightly, but not a "paradigm shift".
> 
> And yes, someone could unplug a USB serial device and plug it into a 
> different USB port so that it has a different name/number, but they 
> could do that with the device itself, move it from com1 to com2.
> 
> Am I missing something?

Yes, the fact that they could unplug a device A and plug a device B. With
the introduction of the concept of removability, the notion of the serial
port itself is not as important anymore, but the notion of the unique device
identifier is.

Consider a situation: long running system (enterprise HVAC, tens of nodes,
tens of thousands square feet area, hundreds of thousand dollars worth of
equipment being conditioned, can't shut down), serial/usb device fails, is
replaced by an identical device with a different serial #.

A little bit farfetched, but hopefully highlighting the point I'm trying to
make.

> Jim

--vt


From jredman at ergotech.com  Thu Jun 22 14:37:38 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 14:37:38 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>	<20060622191603.GA17487@freehold.crocodile.org>	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
Message-ID: <449AFF92.8080003@ergotech.com>


Vadim Tkachenko wrote:
>>
>> Am I missing something?
> 
> Yes, the fact that they could unplug a device A and plug a device B. With
> the introduction of the concept of removability, the notion of the serial
> port itself is not as important anymore, but the notion of the unique device
> identifier is.

Serial devices are always removable.  I could unplug _serial_ device A 
and plug in _serial_ device B.  We have systems running with two RS485 
ports, one talks to a Modbus PLC network one to a number of drives on a 
proprietary protocol.  If you plug the wrong DB9 into the wrong port the 
application doesn't work.

If you dangle a USB 485 converter on the end of the DB9 you've just 
moved the problem from RS485 to USB, but the problem/effect is the same.

> 
> Consider a situation: long running system (enterprise HVAC, tens of nodes,
> tens of thousands square feet area, hundreds of thousand dollars worth of
> equipment being conditioned, can't shut down), serial/usb device fails, is
> replaced by an identical device with a different serial #.
> 
> A little bit farfetched, but hopefully highlighting the point I'm trying to
> make.

Nothing's changed.  If I had a 4 port ISA board and plugged it into my 
new shiny '386 machine.  I could have com ports 9-12.  If I took a board 
off the shelf and didn't set the jumpers, I would have com ports 3-6.

The problem's the same.  If you replace with identical product then the 
com ports  will be the same - no software changes required.  If you 
replace one piece of hardware with hardware from a different 
manufacturer, then the naming/numbering may change.  You're physically 
changing the system, so may reasonably expect to have to make a software 
change.  RXTX actually handles this situation quite well with the -D 
command line option.  (My experience has generally been that the port 
number depends more on the USB port used than the hardware - so the 
chances are even with a hardware change the port number/name will be the 
same.)

Slightly Off Topic - there is a reason why industrial users will pay a 
premium for continued availability of hardware.  Yes you can mail-order 
a $10 USB converter and it will work, but there's no guarantee that the 
next time you buy the same part number from the same vendor it will be 
the same.  The industrial vendors will charge you $100+ for the same 
item, but it will be the same every time you buy it for the next 5 to 10 
years.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 14:37:19 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 13:37:19 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
Message-ID: <20060622203719.GA22521@freehold.crocodile.org>

Hello again,

And while I'm at it, why don't just say this: give me one good reason to
write 3+ different ways of handling removable devices, one for USB, one for
FireWire, one for serial...

I understand very well that this goes way beyond the scope of RxTx and
CommAPI and will require cooperation between them and javax.usb and whatever
JSR is responsible for FireWire implementation - but the end result is well
worth it. Abstract out and generalize arrival/departure/monitoring/discovery
API, provide protocol specific extensions for each, live happily ever after.

--vt


On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote:
> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote:
> > 
> > Vadim Tkachenko wrote:
> > > A paradigm shift is required, this is what I wanted to say. Serial devices
> > > can be removed and replaced, it's now our turn to learn to deal with it.
> > 
> > The removal if the serial port hardly significantly different from the 
> > removal of the device attached to the serial port.   Different, 
> > slightly, but not a "paradigm shift".
> > 
> > And yes, someone could unplug a USB serial device and plug it into a 
> > different USB port so that it has a different name/number, but they 
> > could do that with the device itself, move it from com1 to com2.
> > 
> > Am I missing something?
> 
> Yes, the fact that they could unplug a device A and plug a device B. With
> the introduction of the concept of removability, the notion of the serial
> port itself is not as important anymore, but the notion of the unique device
> identifier is.
> 
> Consider a situation: long running system (enterprise HVAC, tens of nodes,
> tens of thousands square feet area, hundreds of thousand dollars worth of
> equipment being conditioned, can't shut down), serial/usb device fails, is
> replaced by an identical device with a different serial #.
> 
> A little bit farfetched, but hopefully highlighting the point I'm trying to
> make.
> 
> > Jim
> 
> --vt
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx


From jredman at ergotech.com  Thu Jun 22 15:13:49 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 22 Jun 2006 15:13:49 -0600
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>	<20060622191603.GA17487@freehold.crocodile.org>	<449AF278.6000903@ergotech.com>	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
Message-ID: <449B080D.9080208@ergotech.com>


Vadim Tkachenko wrote:
> Hello again,
> 
> And while I'm at it, why don't just say this: give me one good reason to
> write 3+ different ways of handling removable devices, one for USB, one for
> FireWire, one for serial...

You don't, they're all the same "I have lost communication with my 
serial device".

The only thing you could really do is improve error reporting by knowing 
the exact sub-system.  ("Device X which is/was attached to USB port Y is 
no longer functioning, please check the USB ports, the device, the 
cables and anything else you can think of that may be a cause of 
failure.")  That just requires an intelligent description of the port.

> I understand very well that this goes way beyond the scope of RxTx and
> CommAPI and will require cooperation between them and javax.usb and whatever
> JSR is responsible for FireWire implementation - but the end result is well
> worth it. Abstract out and generalize arrival/departure/monitoring/discovery
> API, provide protocol specific extensions for each, live happily ever after.

There's a huge list of pseudo-serial devices each with a different set 
of requirements, Bluetooth, RFC 2217, a host of proprietary systems, 
etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I 
have no clue how you'd implement them in a general/cross platform sense.

You haven't convinced me (and only me, others may see something that I 
don't, I'm not speaking for them) that this mechanism can be implemented 
in any practical sense.  That is, that the implementation could be wide 
enough to be consider generally available in RXTX regardless of the 
serial port implementation, platform, etc..  However, if you can come up 
with a general design and a reference implementation for one subsystem, 
I'd like to see it and might get on board.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From vt at freehold.crocodile.org  Thu Jun 22 15:40:55 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Thu, 22 Jun 2006 14:40:55 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <449B080D.9080208@ergotech.com>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
Message-ID: <20060622214055.GA25497@freehold.crocodile.org>

On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote:
> 
> Vadim Tkachenko wrote:
> > Hello again,
> > 
> > And while I'm at it, why don't just say this: give me one good reason to
> > write 3+ different ways of handling removable devices, one for USB, one for
> > FireWire, one for serial...
> 
> You don't, they're all the same "I have lost communication with my 
> serial device".

"I have lost communication with my ${protocol} device".

> The only thing you could really do is improve error reporting by knowing 
> the exact sub-system.  ("Device X which is/was attached to USB port Y is 
> no longer functioning, please check the USB ports, the device, the 
> cables and anything else you can think of that may be a cause of 
> failure.")

"Device ${id} which is/was attached to ${protocol} port ${port} is no longer
functioning, please check the ${protocol} ports, the device, the
${protocol_media} and anything else you can think of that may be a cause of
failure".

>  That just requires an intelligent description of the port.

Agree absolutely.

> > I understand very well that this goes way beyond the scope of RxTx and
> > CommAPI and will require cooperation between them and javax.usb and whatever
> > JSR is responsible for FireWire implementation - but the end result is well
> > worth it. Abstract out and generalize arrival/departure/monitoring/discovery
> > API, provide protocol specific extensions for each, live happily ever after.
> 
> There's a huge list of pseudo-serial devices each with a different set 
> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, 
> etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I 
> have no clue how you'd implement them in a general/cross platform sense.

That's because some of the protocols were created decades ago when
autoconfiguration wasn't even conceived, much less practical. RS232/RS485
don't have a clue about identity discovery, and even capabilities discovery
beyond obvious 8N1 etc.

I agree that today all these protocols have generally incompatible
strategies for handling the situations I'm trying to address, but there's
nothing that says it's not an oversight. Besides, we're dealing with the
devices at a level of abstraction that allows some simplifications and
generalizations, at least part of the time - unless it's the protocol
specific features we're dealing with.

> You haven't convinced me (and only me, others may see something that I 
> don't, I'm not speaking for them) that this mechanism can be implemented 
> in any practical sense.  That is, that the implementation could be wide 
> enough to be consider generally available in RXTX regardless of the 
> serial port implementation, platform, etc..  However, if you can come up 
> with a general design and a reference implementation for one subsystem, 
> I'd like to see it and might get on board.

Actually, I wasn't even thinking about all this stuff when I wrote the first
message on the subject :) Now that you mention it - well, I'm not sure I can
chew the piece I just tried to bite in reasonable amount of time.

How do you eat an elephant? One bite at a time. If we could agree that a
small step in the specification is acceptable at this time, and express
further intentions, things may start happening.

To put it succinctly:

- Concept of a "port" should be augmented with a concept of a "device". A
device may be attached to a port in an implicit or explicit way.
- Implicitly connected device is exactly what the current scope of the
specification covers. No new functionality is offered.
- Explicitly connected device supports detachable device semantics, just as
other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a
few).
- The input and output streams are not properties of a port now, but
properties of the device attached to the port.
- A mechanism to allow listening for device arrivals and departures must be
made available.

That's it, off the top of my head.

I understand that this goes completely against current javax.comm specs, but
an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be
difficult to implement without disrupting javax.comm compatibility.

One concern is how to deal with the device identity - but there's no general
way of dealing with this at this time, devices may or may not offer identity
discovery.

> Jim

--vt


From joachim at buechse.de  Fri Jun 23 02:12:43 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 23 Jun 2006 10:12:43 +0200
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
Message-ID: <CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>

Hello++ Vadim,

I would like to repeat that your request is best addressed to the  
POSSIX standardization group - or maybe the BSD/Linux maintainers. If  
you convince the BSD or Linux guys to add this kind of functionality  
(they can as most of there VCP drivers are open source), there is a  
certain chance that other vendors will pick it up. I assure you that  
RXTX will happily provide this functionality once it's possible - I'm  
sure there is more than one maintainer that would love to add it.  
Having this concept penetrate the market may take some years though.

SHORT: The solution you would like to see could be added to the API  
but it can not be implemented (at least not on the platforms I know).  
There are currently no hooks in the kernel that allow you to discover  
"the device" or even the "means of connection" based on an existing  
"device file descriptor" ie COM-port or /dev/... entry. The name  
mapping of the device is handled by the virtual com port driver of  
the device. Unless you are suggesting RXTX should reimplement virtual  
com port drivers for all usb/serial bridges out there your request is  
understandable from a users viewpoint but simply not realizable. It's  
like asking that the Socket api should identify the computer behind  
an IP address (ie by its Ethernet address). While this COULD be  
implemented in TCP/IP, it IS not, and hence there is no point adding  
such a function to the Socket API.

The current trend for USB/Bluetooth/Irda/etc connected devices is  
going away from serial port abstraction towards RPC (ie the drivers  
provide a device specific or device class specific driver that  
provides an application level api to the device functions). The line  
level protocol is often not even published.

Best regards,
Joachim

On 22.06.2006, at 23:40, Vadim Tkachenko wrote:

> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote:
>>
>> Vadim Tkachenko wrote:
>>> Hello again,
>>>
>>> And while I'm at it, why don't just say this: give me one good  
>>> reason to
>>> write 3+ different ways of handling removable devices, one for  
>>> USB, one for
>>> FireWire, one for serial...
>>
>> You don't, they're all the same "I have lost communication with my
>> serial device".
>
> "I have lost communication with my ${protocol} device".
>
>> The only thing you could really do is improve error reporting by  
>> knowing
>> the exact sub-system.  ("Device X which is/was attached to USB  
>> port Y is
>> no longer functioning, please check the USB ports, the device, the
>> cables and anything else you can think of that may be a cause of
>> failure.")
>
> "Device ${id} which is/was attached to ${protocol} port ${port} is  
> no longer
> functioning, please check the ${protocol} ports, the device, the
> ${protocol_media} and anything else you can think of that may be a  
> cause of
> failure".
>
>>  That just requires an intelligent description of the port.
>
> Agree absolutely.
>
>>> I understand very well that this goes way beyond the scope of  
>>> RxTx and
>>> CommAPI and will require cooperation between them and javax.usb  
>>> and whatever
>>> JSR is responsible for FireWire implementation - but the end  
>>> result is well
>>> worth it. Abstract out and generalize arrival/departure/ 
>>> monitoring/discovery
>>> API, provide protocol specific extensions for each, live happily  
>>> ever after.
>>
>> There's a huge list of pseudo-serial devices each with a different  
>> set
>> of requirements, Bluetooth, RFC 2217, a host of proprietary systems,
>> etc. etc..  Discovery under Bluetooth, or 802.11 would be cool, but I
>> have no clue how you'd implement them in a general/cross platform  
>> sense.
>
> That's because some of the protocols were created decades ago when
> autoconfiguration wasn't even conceived, much less practical. RS232/ 
> RS485
> don't have a clue about identity discovery, and even capabilities  
> discovery
> beyond obvious 8N1 etc.
>
> I agree that today all these protocols have generally incompatible
> strategies for handling the situations I'm trying to address, but  
> there's
> nothing that says it's not an oversight. Besides, we're dealing  
> with the
> devices at a level of abstraction that allows some simplifications and
> generalizations, at least part of the time - unless it's the protocol
> specific features we're dealing with.
>
>> You haven't convinced me (and only me, others may see something  
>> that I
>> don't, I'm not speaking for them) that this mechanism can be  
>> implemented
>> in any practical sense.  That is, that the implementation could be  
>> wide
>> enough to be consider generally available in RXTX regardless of the
>> serial port implementation, platform, etc..  However, if you can  
>> come up
>> with a general design and a reference implementation for one  
>> subsystem,
>> I'd like to see it and might get on board.
>
> Actually, I wasn't even thinking about all this stuff when I wrote  
> the first
> message on the subject :) Now that you mention it - well, I'm not  
> sure I can
> chew the piece I just tried to bite in reasonable amount of time.
>
> How do you eat an elephant? One bite at a time. If we could agree  
> that a
> small step in the specification is acceptable at this time, and  
> express
> further intentions, things may start happening.
>
> To put it succinctly:
>
> - Concept of a "port" should be augmented with a concept of a  
> "device". A
> device may be attached to a port in an implicit or explicit way.
> - Implicitly connected device is exactly what the current scope of the
> specification covers. No new functionality is offered.
> - Explicitly connected device supports detachable device semantics,  
> just as
> other protocols do (USB, FireWire, Wireless USB, Bluetooth, to  
> mention a
> few).
> - The input and output streams are not properties of a port now, but
> properties of the device attached to the port.
> - A mechanism to allow listening for device arrivals and departures  
> must be
> made available.
>
> That's it, off the top of my head.
>
> I understand that this goes completely against current javax.comm  
> specs, but
> an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern )  
> won't be
> difficult to implement without disrupting javax.comm compatibility.
>
> One concern is how to deal with the device identity - but there's  
> no general
> way of dealing with this at this time, devices may or may not offer  
> identity
> discovery.
>
>> Jim
>
> --vt
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx



From vt at freehold.crocodile.org  Fri Jun 23 11:28:29 2006
From: vt at freehold.crocodile.org (Vadim Tkachenko)
Date: Fri, 23 Jun 2006 10:28:29 -0700
Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI?
In-Reply-To: <CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
	<CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
Message-ID: <20060623172829.GA5335@freehold.crocodile.org>

Hello Joachim,

> I would like to repeat that your request is best addressed to the POSSIX
> standardization group - or maybe the BSD/Linux maintainers. If you
> convince the BSD or Linux guys to add this kind of functionality (they can
> as most of there VCP drivers are open source), there is a certain chance
> that other vendors will pick it up. I assure you that RXTX will happily
> provide this functionality once it's possible - I'm sure there is more
> than one maintainer that would love to add it.

I realize this thing is bigger than RxTx itself, and I'm afraid it's too
global not to cause people to laugh before they think about it :)

> Having this concept penetrate the market may take some years though.

Well, I'm sure it'll get there, the only question is - when.

> SHORT: The solution you would like to see could be added to the API but it
> can not be implemented (at least not on the platforms I know).

I guess I'm concerned about the abstraction more than I'm concerned about
the implementation at this point.
  
> There are currently no hooks in the kernel that allow you to discover  
> "the device" or even the "means of connection" based on an existing  
> "device file descriptor" ie COM-port or /dev/... entry.

Well, I'm not so sure you need to keep the literal mapping from /dev
namespace to your device namespace. As long as you can consistently offer a
virtual serial device on top of a virtual serial port, it may be irrelevant
whether you can map it into /dev. The mapping is going be schitzofrenic
anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the
representation...

> The name mapping of the device is handled by the virtual com port driver
> of the device. Unless you are suggesting RXTX should reimplement virtual
> com port drivers for all usb/serial bridges out there your request is
> understandable from a users viewpoint but simply not realizable.

It's not so much a request but rather an offer of participation. I run a few
projects actively using serial communications, as well as USB device
drivers, in different degrees of readiness (Servomaster, Haywire, DIY
Zoning) - and it would be a perfect playground.

You mentioned above that this task is about two things: a) abstraction b)
implementation. I could start the abstraction part of it without changing
the current CommAPI, on top of it, as an adapter. Even if the removable
device semantics are not implemented, but offered, this is already a step
forward.

> It's like asking that the Socket api should identify the computer behind
> an IP address (ie by its Ethernet address). While this COULD be
> implemented in TCP/IP, it IS not, and hence there is no point adding such
> a function to the Socket API.

Thank you for bringing up this example - I guess this is just about the same
thing that I'd like to see. Socket transparently provides you with the
input/output streams, at the same time offering protocol level specifics to
you.

> The current trend for USB/Bluetooth/Irda/etc connected devices is going
> away from serial port abstraction towards RPC (ie the drivers provide a
> device specific or device class specific driver that provides an
> application level api to the device functions). The line level protocol is
> often not even published.

I can't say I'm that happy with it. The best (or, rather, worst) example is
suchlike support for the Phidget servo controller - zealous Linux developers
implemented kernel module support for it, completely hijacking a possibility
of using it on a different level (it's somewhat fixed by now, thankfully).

I believe that whenever an abstraction is offered, it must be made optional
and/or pluggable so it can be replaced by something more suited to the task.

The nature of Java applications is such that they'd probably care much more
about Java API offered, than about no matter how rich application level api
that is offered outside of Java. I've dealt with JNI adapters in the past,
and whereas they can be made reasonably stable, the very fact that you are
forced to deal with things that are not on the critical timing/memory path
and could've been done much easier in Java causes endless grief.

> Joachim

--vt


From lyon at docjava.com  Sat Jun 24 04:54:12 2006
From: lyon at docjava.com (Dr. Douglas Lyon)
Date: Sat, 24 Jun 2006 06:54:12 -0400
Subject: [Rxtx] jsr
In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org>
References: <449A08F2.3020106@freehold.crocodile.org>
	<2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de>
	<20060622191603.GA17487@freehold.crocodile.org>
	<449AF278.6000903@ergotech.com>
	<20060622195727.GA20247@freehold.crocodile.org>
	<20060622203719.GA22521@freehold.crocodile.org>
	<449B080D.9080208@ergotech.com>
	<20060622214055.GA25497@freehold.crocodile.org>
	<CD86B7B6-5BB3-4FB1-89B4-D14CD009D6A6@buechse.de>
	<20060623172829.GA5335@freehold.crocodile.org>
Message-ID: <p060204a3c0c2c9dde4f8@[192.168.1.152]>

Hi All,
I have had some off-list discussion with Trent.
Opening up a JSR with Sun, as per Peters' suggestion
seems like a reasonable idea, to us.

Does anyone having any concerns about the JSR process
that they would like to raise?

Thanks!
  - Doug



From the.grey.lantern at gmail.com  Sat Jun 24 18:15:26 2006
From: the.grey.lantern at gmail.com (Craig Nicoll)
Date: Sun, 25 Jun 2006 01:15:26 +0100
Subject: [Rxtx] Cannot create virtual serial port
Message-ID: <a1221cc50606241715g2d1e2af6r747347dd4c20e997@mail.gmail.com>

Hello,

This is my first post on this mailing list and I hope someone can help me.

I am having great difficult establishing a virtual serial port for the
Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia
7600.

Every time I try to run the SendMessage program that comes with SMSLib, I
get the following exception: gnu.io.NoSuchPortException

The port names I have tried are:
rfcomm0
rfcomm
/dev/rfcomm0
/dev/rfcomm

This is what I have done so far:
Modified /etc/bluetooth/rfcomm.conf to include the address of my phone:

rfcomm0 {
# Automatically bind the device at startup
bind no;

# Bluetooth address of the device
device 00:0e:6d:7a:98:43;

# RFCOMM channel for the connection
channel 1;

# Description of the connection
comment "Example Bluetooth device";
}

I also tried running the following command: rfcomm bind /dev/rfcomm0

I have searched the mailing list archives and found this post where someone
had a very similar problem to me:
http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried
changing the system properties as suggested and it made no difference.

I have also been scouring Google all day to no avail.

I would be incredibly grateful if anyone could give me some tips.

Thank you,

Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060625/cfa6df35/attachment-0014.html

From tjarvi at qbang.org  Sun Jun 25 19:56:08 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT)
Subject: [Rxtx] Pending release
Message-ID: <Pine.LNX.4.61.0606251942460.15744@www>


With frustration, I was unable to get to the pending release this weekend.
The release should be comming this next week once things calm down.
The source is in CVS except for a fix for multiple ports in windows.

I had planned on doing the release this weekend but that was disrupted by 
my transportation failing in a spectacular fashion.

--
Trent Jarvi
tjarvi at qbang.org


From Pawan.Kharbanda at dot.state.co.us  Tue Jun 27 22:28:51 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Tue, 27 Jun 2006 22:28:51 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>

 Trent, 
   I have an application running in a cluster in linux environment and I
am using RXTX2.1.7 (final) with JDK1.5. The application opens and closes
serial comm ports every 30 seconds and exchanges datas. I have
experienced some of my Comm Ports are left hanging (I can see the
LCK..cufXX lock files under /var/lock folder). On putting the debugs I
found out that, it is stuck at a native call line 809 in RXTXPort.java
class (Please see the code snippet below). Can you help me explain what
this method does in the native code? Am I getting into some thread
deadlocks? Thanks in advance.

Pawan Kharbanda 


public void removeEventListener()
	{
		if (debug)
			z.reportln( "RXTXPort:removeEventListener()
called");
		waitForTheNativeCodeSilly();
		//if( monThread != null && monThread.isAlive() )
		if( monThreadisInterrupted == true )
		{
			z.reportln( "	RXTXPort:removeEventListener()
already interrupted");
			monThread = null;
			SPEventListener = null;
			return;
		}
		else if( monThread != null && monThread.isAlive() )
		{
			if (debug)
				z.reportln( "
RXTXPort:Interrupt=true");
			monThreadisInterrupted=true;
			/*
			   Notify all threads in this PID that something
is up
			   They will call back to see if its their
thread
			   using isInterrupted().
			*/
			if (debug)
				z.reportln( "	RXTXPort:calling
interruptEventLoop");
// LINE 809			interruptEventLoop( ); It never returns
out of this 
			
			if (debug)
				z.reportln( "	RXTXPort:calling
monThread.join()");
			try {
				monThread.join(1000);
			} catch (Exception ex) {
				/* yikes */
				ex.printStackTrace();
			}
			if (debug)
				z.reportln( "	RXTXPort:waiting on
isAlive()");
			while( monThread.isAlive() )
			{
				if ( debug )
					z.reportln( "	MonThread is
still alive!");
				try {
					monThread.join(1000);
					Thread.sleep( 1000 );
				} catch( Exception e ){} 
				//monThread.stop();
			}
			
		}
		if (debug)
			z.reportln( "	RXTXPort:calling gc()");
		monThread = null;
		SPEventListener = null;
		MonitorThreadLock = false;
		MonitorThreadAlive=false;
		monThreadisInterrupted=true;
		z.reportln( "RXTXPort:removeEventListener() returning");
	} 

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Sunday, June 25, 2006 7:56 PM
To: rxtx at qbang.org
Subject: [Rxtx] Pending release


With frustration, I was unable to get to the pending release this
weekend.
The release should be comming this next week once things calm down.
The source is in CVS except for a fix for multiple ports in windows.

I had planned on doing the release this weekend but that was disrupted
by my transportation failing in a spectacular fashion.

--
Trent Jarvi
tjarvi at qbang.org
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Wed Jun 28 04:17:29 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 28 Jun 2006 04:17:29 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E7C6@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606280406330.9561@www>



Hi Pawan

You may have found a deadlock but I've not seen on recently on linux.

If you can, please update from CVS.  This will have some close fixes. 
I'm running with the same code as is in CVS.  It is not perfect but I've 
not seen anything like you mention.  Be sure to set timeouts and 
thresholds on the port.  It may be that the port is waiting on pending io 
that never happens.  I think the CVS patches deal with this also but it 
looks like your in a better test environment to know for sure.

The exploded vehicle mentioned below is expected to be fixed today.  It 
was just a ninja small radiator hose.  The pressure test afterwards 
created its own set of problems.  Until this is resolved, I'm spending 
most of my free time commuting by bicycle.

On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>   I have an application running in a cluster in linux environment and I
> am using RXTX2.1.7 (final) with JDK1.5. The application opens and closes
> serial comm ports every 30 seconds and exchanges datas. I have
> experienced some of my Comm Ports are left hanging (I can see the
> LCK..cufXX lock files under /var/lock folder). On putting the debugs I
> found out that, it is stuck at a native call line 809 in RXTXPort.java
> class (Please see the code snippet below). Can you help me explain what
> this method does in the native code? Am I getting into some thread
> deadlocks? Thanks in advance.
>
> Pawan Kharbanda
>
>
> public void removeEventListener()
> 	{
> 		if (debug)
> 			z.reportln( "RXTXPort:removeEventListener()
> called");
> 		waitForTheNativeCodeSilly();
> 		//if( monThread != null && monThread.isAlive() )
> 		if( monThreadisInterrupted == true )
> 		{
> 			z.reportln( "	RXTXPort:removeEventListener()
> already interrupted");
> 			monThread = null;
> 			SPEventListener = null;
> 			return;
> 		}
> 		else if( monThread != null && monThread.isAlive() )
> 		{
> 			if (debug)
> 				z.reportln( "
> RXTXPort:Interrupt=true");
> 			monThreadisInterrupted=true;
> 			/*
> 			   Notify all threads in this PID that something
> is up
> 			   They will call back to see if its their
> thread
> 			   using isInterrupted().
> 			*/
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> interruptEventLoop");
> // LINE 809			interruptEventLoop( ); It never returns
> out of this
>
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> monThread.join()");
> 			try {
> 				monThread.join(1000);
> 			} catch (Exception ex) {
> 				/* yikes */
> 				ex.printStackTrace();
> 			}
> 			if (debug)
> 				z.reportln( "	RXTXPort:waiting on
> isAlive()");
> 			while( monThread.isAlive() )
> 			{
> 				if ( debug )
> 					z.reportln( "	MonThread is
> still alive!");
> 				try {
> 					monThread.join(1000);
> 					Thread.sleep( 1000 );
> 				} catch( Exception e ){}
> 				//monThread.stop();
> 			}
>
> 		}
> 		if (debug)
> 			z.reportln( "	RXTXPort:calling gc()");
> 		monThread = null;
> 		SPEventListener = null;
> 		MonitorThreadLock = false;
> 		MonitorThreadAlive=false;
> 		monThreadisInterrupted=true;
> 		z.reportln( "RXTXPort:removeEventListener() returning");
> 	}
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Sunday, June 25, 2006 7:56 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] Pending release
>
>
> With frustration, I was unable to get to the pending release this
> weekend.
> The release should be comming this next week once things calm down.
> The source is in CVS except for a fix for multiple ports in windows.
>
> I had planned on doing the release this weekend but that was disrupted
> by my transportation failing in a spectacular fashion.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From Pawan.Kharbanda at dot.state.co.us  Wed Jun 28 12:11:06 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Wed, 28 Jun 2006 12:11:06 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>

Trent,
    Again thanks for the reply. First of all I have Receive timeouts set
on all communications including Max no of bytes to expect during the
call. I have noticed the problem is during "closing the connection". I
am not sure if the RXTX is 100% thread-safe yet. There seems to be a
glitch in the native calls. I am sure I have the latest code I did the
update on the Version 2.1.7 from CVS, is this where the latest updates
are located, I have noticed another version in CVS "rxtx-devel".

Regards
Pawan Kharbanda

    

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Wednesday, June 28, 2006 4:17 AM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports



Hi Pawan

You may have found a deadlock but I've not seen on recently on linux.

If you can, please update from CVS.  This will have some close fixes. 
I'm running with the same code as is in CVS.  It is not perfect but I've
not seen anything like you mention.  Be sure to set timeouts and
thresholds on the port.  It may be that the port is waiting on pending
io that never happens.  I think the CVS patches deal with this also but
it looks like your in a better test environment to know for sure.

The exploded vehicle mentioned below is expected to be fixed today.  It
was just a ninja small radiator hose.  The pressure test afterwards
created its own set of problems.  Until this is resolved, I'm spending
most of my free time commuting by bicycle.

On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>   I have an application running in a cluster in linux environment and 
> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and 
> closes serial comm ports every 30 seconds and exchanges datas. I have 
> experienced some of my Comm Ports are left hanging (I can see the 
> LCK..cufXX lock files under /var/lock folder). On putting the debugs I

> found out that, it is stuck at a native call line 809 in RXTXPort.java

> class (Please see the code snippet below). Can you help me explain 
> what this method does in the native code? Am I getting into some 
> thread deadlocks? Thanks in advance.
>
> Pawan Kharbanda
>
>
> public void removeEventListener()
> 	{
> 		if (debug)
> 			z.reportln( "RXTXPort:removeEventListener()
called");
> 		waitForTheNativeCodeSilly();
> 		//if( monThread != null && monThread.isAlive() )
> 		if( monThreadisInterrupted == true )
> 		{
> 			z.reportln( "	RXTXPort:removeEventListener()
> already interrupted");
> 			monThread = null;
> 			SPEventListener = null;
> 			return;
> 		}
> 		else if( monThread != null && monThread.isAlive() )
> 		{
> 			if (debug)
> 				z.reportln( "
> RXTXPort:Interrupt=true");
> 			monThreadisInterrupted=true;
> 			/*
> 			   Notify all threads in this PID that something
is up
> 			   They will call back to see if its their
thread
> 			   using isInterrupted().
> 			*/
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> interruptEventLoop");
> // LINE 809			interruptEventLoop( ); It never returns
> out of this
>
> 			if (debug)
> 				z.reportln( "	RXTXPort:calling
> monThread.join()");
> 			try {
> 				monThread.join(1000);
> 			} catch (Exception ex) {
> 				/* yikes */
> 				ex.printStackTrace();
> 			}
> 			if (debug)
> 				z.reportln( "	RXTXPort:waiting on
> isAlive()");
> 			while( monThread.isAlive() )
> 			{
> 				if ( debug )
> 					z.reportln( "	MonThread is
> still alive!");
> 				try {
> 					monThread.join(1000);
> 					Thread.sleep( 1000 );
> 				} catch( Exception e ){}
> 				//monThread.stop();
> 			}
>
> 		}
> 		if (debug)
> 			z.reportln( "	RXTXPort:calling gc()");
> 		monThread = null;
> 		SPEventListener = null;
> 		MonitorThreadLock = false;
> 		MonitorThreadAlive=false;
> 		monThreadisInterrupted=true;
> 		z.reportln( "RXTXPort:removeEventListener() returning");
> 	}
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf

> Of Trent Jarvi
> Sent: Sunday, June 25, 2006 7:56 PM
> To: rxtx at qbang.org
> Subject: [Rxtx] Pending release
>
>
> With frustration, I was unable to get to the pending release this 
> weekend.
> The release should be comming this next week once things calm down.
> The source is in CVS except for a fix for multiple ports in windows.
>
> I had planned on doing the release this weekend but that was disrupted

> by my transportation failing in a spectacular fashion.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From tjarvi at qbang.org  Wed Jun 28 12:26:21 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Wed, 28 Jun 2006 12:26:21 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E82A@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606281222420.9561@www>


Hi Pawan

If you did a cvs update from the 2.1-7 tar ball, you have the current 
version.  All rxtx in CVS is under rxtx-devel.  The 2.1-7 just has -r
commapi-0-0-1.

You may well have found something.  I have seen win32 fail on closing 
ports but not linux that I can think of.  Your use is much different than 
I normally see too.

Could you give us more information on how we would reproduce this and the 
frequency?


On Wed, 28 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>    Again thanks for the reply. First of all I have Receive timeouts set
> on all communications including Max no of bytes to expect during the
> call. I have noticed the problem is during "closing the connection". I
> am not sure if the RXTX is 100% thread-safe yet. There seems to be a
> glitch in the native calls. I am sure I have the latest code I did the
> update on the Version 2.1.7 from CVS, is this where the latest updates
> are located, I have noticed another version in CVS "rxtx-devel".
>
> Regards
> Pawan Kharbanda
>
>
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Wednesday, June 28, 2006 4:17 AM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] Locked Ports
>
>
>
> Hi Pawan
>
> You may have found a deadlock but I've not seen on recently on linux.
>
> If you can, please update from CVS.  This will have some close fixes.
> I'm running with the same code as is in CVS.  It is not perfect but I've
> not seen anything like you mention.  Be sure to set timeouts and
> thresholds on the port.  It may be that the port is waiting on pending
> io that never happens.  I think the CVS patches deal with this also but
> it looks like your in a better test environment to know for sure.
>
> The exploded vehicle mentioned below is expected to be fixed today.  It
> was just a ninja small radiator hose.  The pressure test afterwards
> created its own set of problems.  Until this is resolved, I'm spending
> most of my free time commuting by bicycle.
>
> On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:
>
>> Trent,
>>   I have an application running in a cluster in linux environment and
>> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and
>> closes serial comm ports every 30 seconds and exchanges datas. I have
>> experienced some of my Comm Ports are left hanging (I can see the
>> LCK..cufXX lock files under /var/lock folder). On putting the debugs I
>
>> found out that, it is stuck at a native call line 809 in RXTXPort.java
>
>> class (Please see the code snippet below). Can you help me explain
>> what this method does in the native code? Am I getting into some
>> thread deadlocks? Thanks in advance.
>>
>> Pawan Kharbanda
>>
>>
>> public void removeEventListener()
>> 	{
>> 		if (debug)
>> 			z.reportln( "RXTXPort:removeEventListener()
> called");
>> 		waitForTheNativeCodeSilly();
>> 		//if( monThread != null && monThread.isAlive() )
>> 		if( monThreadisInterrupted == true )
>> 		{
>> 			z.reportln( "	RXTXPort:removeEventListener()
>> already interrupted");
>> 			monThread = null;
>> 			SPEventListener = null;
>> 			return;
>> 		}
>> 		else if( monThread != null && monThread.isAlive() )
>> 		{
>> 			if (debug)
>> 				z.reportln( "
>> RXTXPort:Interrupt=true");
>> 			monThreadisInterrupted=true;
>> 			/*
>> 			   Notify all threads in this PID that something
> is up
>> 			   They will call back to see if its their
> thread
>> 			   using isInterrupted().
>> 			*/
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> interruptEventLoop");
>> // LINE 809			interruptEventLoop( ); It never returns
>> out of this
>>
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> monThread.join()");
>> 			try {
>> 				monThread.join(1000);
>> 			} catch (Exception ex) {
>> 				/* yikes */
>> 				ex.printStackTrace();
>> 			}
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:waiting on
>> isAlive()");
>> 			while( monThread.isAlive() )
>> 			{
>> 				if ( debug )
>> 					z.reportln( "	MonThread is
>> still alive!");
>> 				try {
>> 					monThread.join(1000);
>> 					Thread.sleep( 1000 );
>> 				} catch( Exception e ){}
>> 				//monThread.stop();
>> 			}
>>
>> 		}
>> 		if (debug)
>> 			z.reportln( "	RXTXPort:calling gc()");
>> 		monThread = null;
>> 		SPEventListener = null;
>> 		MonitorThreadLock = false;
>> 		MonitorThreadAlive=false;
>> 		monThreadisInterrupted=true;
>> 		z.reportln( "RXTXPort:removeEventListener() returning");
>> 	}
>>
>> -----Original Message-----
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
>
>> Of Trent Jarvi
>> Sent: Sunday, June 25, 2006 7:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] Pending release
>>
>>
>> With frustration, I was unable to get to the pending release this
>> weekend.
>> The release should be comming this next week once things calm down.
>> The source is in CVS except for a fix for multiple ports in windows.
>>
>> I had planned on doing the release this weekend but that was disrupted
>
>> by my transportation failing in a spectacular fashion.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From Pawan.Kharbanda at dot.state.co.us  Wed Jun 28 15:42:49 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Wed, 28 Jun 2006 15:42:49 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>

Trent,
    I will try to explain how I am setup and will try to write you a
Sample code little later to reproduce this. On our system we have
DigiBoxes installed on the 2 Linux servers. Both of them have RXTX2.1-7
version installed with the JRE(1.5) and both the machines have the same
port mappings in gnu.io.rxtx.properties (Currently in the production
system I have 64 ports). This is how the system works:

1) A thick Map based client initiates a Action on the Device on the
field. One of the Thread Workers(Asynchronous Call) in the Cluster picks
up the request. 
2) Once the worker gets the request it locks the Device and
Communication port in the DB's(These are our persistent locks, because
most of the devices do one to one communication with the serial ports).
After that the worker (or Comm Server) opens up the connection and after
exchanging the information calls the "Close" and returns.
3) Once the connection is closed , the DB lock is removed on the comm
port and is made available to accept future calls. Here is where the
glitch is the Serial Comm Close method never returns due to the
deadlock. 

I have noticed that the deadlocks are very inconsistent, sometime it
happens right away as soon as Application server starts and sometimes I
don't see any deadlocks for days, but it happens for sure. 

Here is how you can test if you have resources/ test environment. Write
a program and try to open/close  different ports(I will say have a
minimum of four) randomly and very frequently(may be 30 seconds), I am
pretty sure you will see the deadlocks and it happens in the native call
to interrptEventLoop in RXTXPort.java in removeEventListener() method
call.

Also I have noticed that the JVM carshes (without any memrory errors or
JVM errors. Its just not there) when native call is made to eventLoop()
in run() method in MonitorThread inner class. I am still investigating
why this is happening, but at this point I can just tell you the
location. You might have a question How I am so sure about the location?
My application is configured with Log4J and I have enabled the debugs on
the RXTXPort.java, so every time my JVM dies I see these logs at the end
of the file.

"2006-06-28 15:27:15,183 INFO  [STDOUT] RXTXPort:RXTXPort(/dev/cub01)
called
2006-06-28 15:27:15,218 INFO  [STDOUT]
RXTXPort:MontitorThread:MonitorThread()
2006-06-28 15:27:15,219 INFO  [STDOUT] RXTXPort:MontitorThread:run()"

I surely do have a luxury of a testing environment(ports, devices etc.)
and can help you fix these problems? Please advise me how we can resolve
these issues.

Thanks 
Pawan Kharbanda
303-478-2991





-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Wednesday, June 28, 2006 12:26 PM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports


Hi Pawan

If you did a cvs update from the 2.1-7 tar ball, you have the current
version.  All rxtx in CVS is under rxtx-devel.  The 2.1-7 just has -r
commapi-0-0-1.

You may well have found something.  I have seen win32 fail on closing
ports but not linux that I can think of.  Your use is much different
than I normally see too.

Could you give us more information on how we would reproduce this and
the frequency?


On Wed, 28 Jun 2006, Kharbanda, Pawan wrote:

> Trent,
>    Again thanks for the reply. First of all I have Receive timeouts
set
> on all communications including Max no of bytes to expect during the
> call. I have noticed the problem is during "closing the connection". I
> am not sure if the RXTX is 100% thread-safe yet. There seems to be a
> glitch in the native calls. I am sure I have the latest code I did the
> update on the Version 2.1.7 from CVS, is this where the latest updates
> are located, I have noticed another version in CVS "rxtx-devel".
>
> Regards
> Pawan Kharbanda
>
>
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
> Of Trent Jarvi
> Sent: Wednesday, June 28, 2006 4:17 AM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] Locked Ports
>
>
>
> Hi Pawan
>
> You may have found a deadlock but I've not seen on recently on linux.
>
> If you can, please update from CVS.  This will have some close fixes.
> I'm running with the same code as is in CVS.  It is not perfect but
I've
> not seen anything like you mention.  Be sure to set timeouts and
> thresholds on the port.  It may be that the port is waiting on pending
> io that never happens.  I think the CVS patches deal with this also
but
> it looks like your in a better test environment to know for sure.
>
> The exploded vehicle mentioned below is expected to be fixed today.
It
> was just a ninja small radiator hose.  The pressure test afterwards
> created its own set of problems.  Until this is resolved, I'm spending
> most of my free time commuting by bicycle.
>
> On Tue, 27 Jun 2006, Kharbanda, Pawan wrote:
>
>> Trent,
>>   I have an application running in a cluster in linux environment and
>> I am using RXTX2.1.7 (final) with JDK1.5. The application opens and
>> closes serial comm ports every 30 seconds and exchanges datas. I have
>> experienced some of my Comm Ports are left hanging (I can see the
>> LCK..cufXX lock files under /var/lock folder). On putting the debugs
I
>
>> found out that, it is stuck at a native call line 809 in
RXTXPort.java
>
>> class (Please see the code snippet below). Can you help me explain
>> what this method does in the native code? Am I getting into some
>> thread deadlocks? Thanks in advance.
>>
>> Pawan Kharbanda
>>
>>
>> public void removeEventListener()
>> 	{
>> 		if (debug)
>> 			z.reportln( "RXTXPort:removeEventListener()
> called");
>> 		waitForTheNativeCodeSilly();
>> 		//if( monThread != null && monThread.isAlive() )
>> 		if( monThreadisInterrupted == true )
>> 		{
>> 			z.reportln( "	RXTXPort:removeEventListener()
>> already interrupted");
>> 			monThread = null;
>> 			SPEventListener = null;
>> 			return;
>> 		}
>> 		else if( monThread != null && monThread.isAlive() )
>> 		{
>> 			if (debug)
>> 				z.reportln( "
>> RXTXPort:Interrupt=true");
>> 			monThreadisInterrupted=true;
>> 			/*
>> 			   Notify all threads in this PID that something
> is up
>> 			   They will call back to see if its their
> thread
>> 			   using isInterrupted().
>> 			*/
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> interruptEventLoop");
>> // LINE 809			interruptEventLoop( ); It never returns
>> out of this
>>
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:calling
>> monThread.join()");
>> 			try {
>> 				monThread.join(1000);
>> 			} catch (Exception ex) {
>> 				/* yikes */
>> 				ex.printStackTrace();
>> 			}
>> 			if (debug)
>> 				z.reportln( "	RXTXPort:waiting on
>> isAlive()");
>> 			while( monThread.isAlive() )
>> 			{
>> 				if ( debug )
>> 					z.reportln( "	MonThread is
>> still alive!");
>> 				try {
>> 					monThread.join(1000);
>> 					Thread.sleep( 1000 );
>> 				} catch( Exception e ){}
>> 				//monThread.stop();
>> 			}
>>
>> 		}
>> 		if (debug)
>> 			z.reportln( "	RXTXPort:calling gc()");
>> 		monThread = null;
>> 		SPEventListener = null;
>> 		MonitorThreadLock = false;
>> 		MonitorThreadAlive=false;
>> 		monThreadisInterrupted=true;
>> 		z.reportln( "RXTXPort:removeEventListener() returning");
>> 	}
>>
>> -----Original Message-----
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On
Behalf
>
>> Of Trent Jarvi
>> Sent: Sunday, June 25, 2006 7:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] Pending release
>>
>>
>> With frustration, I was unable to get to the pending release this
>> weekend.
>> The release should be comming this next week once things calm down.
>> The source is in CVS except for a fix for multiple ports in windows.
>>
>> I had planned on doing the release this weekend but that was
disrupted
>
>> by my transportation failing in a spectacular fashion.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx 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 khattar31 at yahoo.com  Wed Jun 28 22:04:59 2006
From: khattar31 at yahoo.com (rahul khattar)
Date: Wed, 28 Jun 2006 21:04:59 -0700 (PDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
Message-ID: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>

Hi All,

I was looking at the src file on the last release.
I did notice a missing header file while trying to
compile the parallelport.dll. Would somebody be kind
enoughf to share the missing header file:
gnu_io_LPRPort.h

I am using MinGw to compile the same from Parinya
(which is an execellent tool)


Regards,
Rahul Khattar

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From tjarvi at qbang.org  Thu Jun 29 03:43:53 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 03:43:53 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>
References: <20060629040459.33983.qmail@web36707.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606290341210.9561@www>

On Wed, 28 Jun 2006, rahul khattar wrote:

> Hi All,
>
> I was looking at the src file on the last release.
> I did notice a missing header file while trying to
> compile the parallelport.dll. Would somebody be kind
> enoughf to share the missing header file:
> gnu_io_LPRPort.h
>
> I am using MinGw to compile the same from Parinya
> (which is an execellent tool)
>

Hi Rahul

The gnu.io_LPRPort.h file is generated with javah.  You can see the 
command in the Makefile I presume.  You do not need rxtxParallel.dll to 
use w32 serial btw.

--
Trent Jarvi
tjarvi at qbang.org


From khattar31 at yahoo.com  Thu Jun 29 04:47:01 2006
From: khattar31 at yahoo.com (rahul khattar)
Date: Thu, 29 Jun 2006 03:47:01 -0700 (PDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606290341210.9561@www>
Message-ID: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>

Hi Trent 
I did notice this file is required in the source file
ParallelImp.c
on line 38

Attached the O/P 

Regards,
Rahul Khattar




--- Trent Jarvi <tjarvi at qbang.org> wrote:

> On Wed, 28 Jun 2006, rahul khattar wrote:
> 
> > Hi All,
> >
> > I was looking at the src file on the last release.
> > I did notice a missing header file while trying to
> > compile the parallelport.dll. Would somebody be
> kind
> > enoughf to share the missing header file:
> > gnu_io_LPRPort.h
> >
> > I am using MinGw to compile the same from Parinya
> > (which is an execellent tool)
> >
> 
> Hi Rahul
> 
> The gnu.io_LPRPort.h file is generated with javah. 
> You can see the 
> command in the Makefile I presume.  You do not need
> rxtxParallel.dll to 
> use w32 serial btw.
> 
> --
> Trent Jarvi
> tjarvi at qbang.org
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Error.zip
Type: application/x-zip-compressed
Size: 1746 bytes
Desc: 2948039066-Error.zip
Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060629/a5b6f783/Error-0023.bin

From tjarvi at qbang.org  Thu Jun 29 06:16:24 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 06:16:24 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0606290614530.9561@www>

On Thu, 29 Jun 2006, rahul khattar wrote:

> Hi Trent
> I did notice this file is required in the source file
> ParallelImp.c
> on line 38
>
> Attached the O/P
>

The command to generate the .h file will be something like:

javah -classpath . -jni gnu.io.LPRPort

The makefile should have this.  There are several approaches to creating 
or using makefiles so I have no idea which one you used if any.

--
Trent Jarvi
tjarvi at qbang.org


From tjarvi at qbang.org  Thu Jun 29 06:20:51 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 06:20:51 -0600 (MDT)
Subject: [Rxtx] Locked Ports
In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
References: <939A619A756047469C41EE9BA51890FB03F3E86D@hqexchange3.dot.state.co.us>
Message-ID: <Pine.LNX.4.61.0606290616420.9561@www>

> Here is how you can test if you have resources/ test environment. Write
> a program and try to open/close  different ports(I will say have a
> minimum of four) randomly and very frequently(may be 30 seconds), I am
> pretty sure you will see the deadlocks and it happens in the native call
> to interrptEventLoop in RXTXPort.java in removeEventListener() method
> call.

Hi Pawan

I'll try to find a way to reproduce this.  One thing to note is that you 
are using different kernel drivers (digi) to perform this task.  So I 
probably will not be able to reproduce the exact same environment.

In general, multiport kernel drivers have been tested far less than 
typical serial drivers.  This may or may not be an issue.

--
Trent Jarvi
tjarvi at qbang.org



From jhaysonn at gmail.com  Thu Jun 29 12:29:13 2006
From: jhaysonn at gmail.com (jhaysonn pathak)
Date: Thu, 29 Jun 2006 14:29:13 -0400
Subject: [Rxtx] RXTX install
Message-ID: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>

Hi Guys,

I'm doing trying to write a generative piece of Sonic Art using an EEG
plugged into a mac runnning Max/MSP.  I just recently discovered RXTX
drivers in my search for a piece of software that might give me more
output options for my EEG (I'm using the CEO from MindPeak).  I found
Bioera which uses RXTX drivers.  Thing is - I can't figure out how to
install RXTX correctly.

After I build the 'libSerial.jnilib' target inside of
'LibSerial.pbproj' I can't find the libSerial.jnilib file that
accompanies the RXTXcomm.jar nor do I know where to put them.

I also don't understand this part at the bottom of the OS X instructions at all:

"AFTER INSTALLATION VERY IMPORTANT
	check existence of the folder /var/spool/uucp
	if you don't have it create it with command
	sudo mkdir /var/spool/uucp
	permissions should be: drwxrwxr-x
	if they are not do command
	sudo chmod 775 /var/spool/uucp

	YOU should be a member of the uucp group
	you can check it with command
		niutil -readprop / /groups/uucp users
	you should see your name in output of the niutil command
	if you don't do following:
		sudo niutil -appendprop / /groups/uucp users <yourname>
			substitute  <yourname> with your user's name
			for example if your user name is peter:
				sudo niutil -appendprop / /groups/uucp users peter

	NOTES: RXTX.pkg should create uucp folder and insert your name  in
uucp group automatically"



I really appreciate any help that you guys can offer.  I've been
struggling with this for a while now as part of a research grant that
I was awarded.  Thanks again for the help.

Jhaysonn Pathak


From naranjo.manuel at gmail.com  Thu Jun 29 07:19:15 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 10:19:15 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606290614530.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www>
Message-ID: <44A3D353.6010605@gmail.com>

Speaking about Windows Support, I had seen that inside the 
rxtx-2.1-7-bins-r2 package inside Windows directory it says:
"i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will 
not make harm to anyone, and i'm almost sure that someone has noticed it 
before.
Cheers,
Manuel


From joachim at buechse.de  Thu Jun 29 13:25:16 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Thu, 29 Jun 2006 21:25:16 +0200
Subject: [Rxtx] RXTX install
In-Reply-To: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>
References: <fda60b830606291129q72fb0f35q8a79a64aa68cf505@mail.gmail.com>
Message-ID: <2A003E42-97E1-4237-8438-646BDE2E3961@buechse.de>

Hello Jhaysonn,

I assume you are trying to use the javax.comm version of RXTX.

Please use "cvs up" to update your download to the latest version of  
the repository. The latest version does not use lock files, so the  
mentioned process is no longer needed. Updating with CVS will also  
provide you with a new README.OSX file that should be simpler to  
understand.

You will find LibSerialUniversal.xcodeproj in MACOSX_IDE/Xcode. Put  
comm.jar (downloaded from Sun) into MACOSX_IDE/Xcode. Compile the  
library. You will find RXTXcomm.jar and librxtxSerial.jnilib in  
MACOSX_IDE/Xcode/build/Default

Best regards,
Joachim
---
Joachim B?chse
Softwarel?sungen und Beratung
Hadlaubsteig 2
CH-8006 Z?rich


On 29.06.2006, at 20:29, jhaysonn pathak wrote:

> Hi Guys,
>
> I'm doing trying to write a generative piece of Sonic Art using an EEG
> plugged into a mac runnning Max/MSP.  I just recently discovered RXTX
> drivers in my search for a piece of software that might give me more
> output options for my EEG (I'm using the CEO from MindPeak).  I found
> Bioera which uses RXTX drivers.  Thing is - I can't figure out how to
> install RXTX correctly.
>
> After I build the 'libSerial.jnilib' target inside of
> 'LibSerial.pbproj' I can't find the libSerial.jnilib file that
> accompanies the RXTXcomm.jar nor do I know where to put them.
>
> I also don't understand this part at the bottom of the OS X  
> instructions at all:
>
> "AFTER INSTALLATION VERY IMPORTANT
> 	check existence of the folder /var/spool/uucp
> 	if you don't have it create it with command
> 	sudo mkdir /var/spool/uucp
> 	permissions should be: drwxrwxr-x
> 	if they are not do command
> 	sudo chmod 775 /var/spool/uucp
>
> 	YOU should be a member of the uucp group
> 	you can check it with command
> 		niutil -readprop / /groups/uucp users
> 	you should see your name in output of the niutil command
> 	if you don't do following:
> 		sudo niutil -appendprop / /groups/uucp users <yourname>
> 			substitute  <yourname> with your user's name
> 			for example if your user name is peter:
> 				sudo niutil -appendprop / /groups/uucp users peter
>
> 	NOTES: RXTX.pkg should create uucp folder and insert your name  in
> uucp group automatically"
>
>
>
> I really appreciate any help that you guys can offer.  I've been
> struggling with this for a while now as part of a research grant that
> I was awarded.  Thanks again for the help.
>
> Jhaysonn Pathak
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx




From tjarvi at qbang.org  Thu Jun 29 19:30:00 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 19:30:00 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A3D353.6010605@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
Message-ID: <Pine.LNX.4.61.0606291923000.9561@www>

On Thu, 29 Jun 2006, Manuel Naranjo wrote:

> Speaking about Windows Support, I had seen that inside the
> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
> not make harm to anyone, and i'm almost sure that someone has noticed it
> before.

Hi Manuel

         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
     47421  01-30-06 00:23 
rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
     77759  03-01-06 12:01 
rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README


It looks normal to me.  There are no fancy tools used there :)

--
Trent Jarvi
tjarvi at qbang.org

From naranjo.manuel at gmail.com  Thu Jun 29 19:38:16 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 22:38:16 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606291923000.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com> <Pine.LNX.4.61.0606291923000.9561@www>
Message-ID: <44A48088.2040407@gmail.com>

> On Thu, 29 Jun 2006, Manuel Naranjo wrote:
> 
>> Speaking about Windows Support, I had seen that inside the
>> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
>> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
>> not make harm to anyone, and i'm almost sure that someone has noticed it
>> before.
> 
> Hi Manuel
> 
>         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
>         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
>     47421  01-30-06 00:23 
> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
>     77759  03-01-06 12:01 
> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
>       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README
> 
> 
> It looks normal to me.  There are no fancy tools used there :)
> 
Hi Trent:
Is not the i368 representing the name of the Architecture?? If so the 
name should start with i386 it will not break any system, is simply miss
written, I saw that and wanted to report it. It a silly thing.
Ohh I forgoten I must congratulate you for your GREAT libray, I was able 
to make an .exe with JSmooth that launches an application that uses RXTX 
with out the need to install RXTX on users system :). The .exe tells JVM 
where to find the RXTX Library and Binaries. I tried with Sun's Java 
Comm but it was imposible.
Regards,
Manuel


From tjarvi at qbang.org  Thu Jun 29 19:52:45 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 19:52:45 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A48088.2040407@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
	<Pine.LNX.4.61.0606291923000.9561@www> <44A48088.2040407@gmail.com>
Message-ID: <Pine.LNX.4.61.0606291945060.9561@www>

On Thu, 29 Jun 2006, Manuel Naranjo wrote:

>> On Thu, 29 Jun 2006, Manuel Naranjo wrote:
>>
>>> Speaking about Windows Support, I had seen that inside the
>>> rxtx-2.1-7-bins-r2 package inside Windows directory it says:
>>> "i368-mingw32?" instead of "i386-mingw32" :) it's a little bug that will
>>> not make harm to anyone, and i'm almost sure that someone has noticed it
>>> before.
>>
>> Hi Manuel
>>
>>         0  02-04-06 17:36   rxtx-2.1-7-bins-r2/Windows/
>>         0  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/
>>     47421  01-30-06 00:23
>> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxParallel.dll
>>     77759  03-01-06 12:01
>> rxtx-2.1-7-bins-r2/Windows/i368-mingw32/rxtxSerial.dll
>>       102  03-01-06 12:01   rxtx-2.1-7-bins-r2/Windows/i368-mingw32/README
>>
>>
>> It looks normal to me.  There are no fancy tools used there :)
>>
> Hi Trent:
> Is not the i368 representing the name of the Architecture?? If so the
> name should start with i386 it will not break any system, is simply miss
> written, I saw that and wanted to report it. It a silly thing.
> Ohh I forgoten I must congratulate you for your GREAT libray, I was able
> to make an .exe with JSmooth that launches an application that uses RXTX
> with out the need to install RXTX on users system :). The .exe tells JVM
> where to find the RXTX Library and Binaries. I tried with Sun's Java
> Comm but it was imposible.

Hi Manuel

The compiler uses only the i386 instruction set for windows.  I doubt 
there will be any measurable advantages with going to later instruction 
sets.  In theory rxtx would run on a 386 but I doubt anyone does that.

So it looks odd but is not a typo.

We could compile to i686 but don't.  The compiler used does not appear to 
be a problem yet so I don't see any point in changing it.  Right now, we 
could not compile 64 bit windows binaries.  gcc/mingw/... do not support 
them that I know of.  People will have to compile those with closed source 
tools on their own until an option is available.

--
Trent Jarvi
tjarvi at qbang.org

From naranjo.manuel at gmail.com  Thu Jun 29 20:00:48 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 23:00:48 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606291945060.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com>	<Pine.LNX.4.61.0606291923000.9561@www>
	<44A48088.2040407@gmail.com> <Pine.LNX.4.61.0606291945060.9561@www>
Message-ID: <44A485D0.7050202@gmail.com>

Trent you did not get my point
The folder says 368 three hundred sixty eight, when
it should say 386 three hundred eighty six. Is simply a miss writting.
Regards,
Manuel


From tjarvi at qbang.org  Thu Jun 29 20:12:15 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 29 Jun 2006 20:12:15 -0600 (MDT)
Subject: [Rxtx] Windows Support
In-Reply-To: <44A485D0.7050202@gmail.com>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>
	<Pine.LNX.4.61.0606290614530.9561@www> <44A3D353.6010605@gmail.com>
	<Pine.LNX.4.61.0606291923000.9561@www> <44A48088.2040407@gmail.com>
	<Pine.LNX.4.61.0606291945060.9561@www> <44A485D0.7050202@gmail.com>
Message-ID: <Pine.LNX.4.61.0606292008061.9561@www>


On Thu, 29 Jun 2006, Manuel Naranjo wrote:

> Trent you did not get my point
> The folder says 368 three hundred sixty eight, when
> it should say 386 three hundred eighty six. Is simply a miss writting.

hehe..  OK.  My bad.  It's been a long day.

Nevermind :)

--
Trent Jarvi
tjarvi at qbang.org




From naranjo.manuel at gmail.com  Thu Jun 29 20:18:44 2006
From: naranjo.manuel at gmail.com (Manuel Naranjo)
Date: Thu, 29 Jun 2006 23:18:44 -0300
Subject: [Rxtx] Windows Support
In-Reply-To: <Pine.LNX.4.61.0606292008061.9561@www>
References: <20060629104701.26054.qmail@web36714.mail.mud.yahoo.com>	<Pine.LNX.4.61.0606290614530.9561@www>
	<44A3D353.6010605@gmail.com>	<Pine.LNX.4.61.0606291923000.9561@www>
	<44A48088.2040407@gmail.com>	<Pine.LNX.4.61.0606291945060.9561@www>
	<44A485D0.7050202@gmail.com> <Pine.LNX.4.61.0606292008061.9561@www>
Message-ID: <44A48A04.9040401@gmail.com>

Don't worry Trent.
About 64 bits compilation, I would like to colaborate, I have a Pc with 
64 bits, the only problem is that i do not have windows 64 bits 
installed :(.




From Pawan.Kharbanda at dot.state.co.us  Fri Jun 30 08:49:52 2006
From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan)
Date: Fri, 30 Jun 2006 08:49:52 -0600
Subject: [Rxtx] Locked Ports
Message-ID: <939A619A756047469C41EE9BA51890FB03F3E996@hqexchange3.dot.state.co.us>

Trent,  
    Can you explain what the interruptedEventLoop() native method is
doing is there a possibility that method is somehow getting into the
infinite loop(there are 2 while loops without any break statements).
This might be a very basic question how can I debug the native code(or
print the debug statements).  Again thanks for the help. 

Pawan Kharbanda

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf
Of Trent Jarvi
Sent: Thursday, June 29, 2006 6:21 AM
To: RXTX Developers and Users
Subject: Re: [Rxtx] Locked Ports

> Here is how you can test if you have resources/ test environment. 
> Write a program and try to open/close  different ports(I will say have

> a minimum of four) randomly and very frequently(may be 30 seconds), I 
> am pretty sure you will see the deadlocks and it happens in the native

> call to interrptEventLoop in RXTXPort.java in removeEventListener() 
> method call.

Hi Pawan

I'll try to find a way to reproduce this.  One thing to note is that you
are using different kernel drivers (digi) to perform this task.  So I
probably will not be able to reproduce the exact same environment.

In general, multiport kernel drivers have been tested far less than
typical serial drivers.  This may or may not be an issue.

--
Trent Jarvi
tjarvi at qbang.org

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx



From cpine at wrsystems.com  Thu Jun 29 15:17:12 2006
From: cpine at wrsystems.com (Chris Pine)
Date: Thu, 29 Jun 2006 17:17:12 -0400
Subject: [Rxtx]  Controlling Individual Signals DTR and RTS
Message-ID: <MAIL4FJo0S8ACLEBajJ000005cf@mail4.wrsystems.com>

Dear Moussa Ba,
	I hope I am not being too forward, but we are having the exact same
issue with needing to control DTR from RXTX in Linux.  Did you ever have any
luck figuring it out?

Thank you very much for your time,

Chris Pine




From tjarvi at qbang.org  Thu Jun  1 11:13:40 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 11:13:40 -0600 (MDT)
Subject: [Rxtx] custom baud rate win32
In-Reply-To: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
Message-ID: <Pine.LNX.4.61.0606011107210.30220@www>


Hi Daren

I can't imagine that 1953 is possibly the actual value on the UART.  Maybe 
if your baud base is very high with a custom serial board.  More likely, 
the driver just remembers that what you asked for and did something else.

I'll have more to say on the dcb->BaudRate after I try some things here. 
I have managed to do something like that in the past as a quick hack but 
it was for 14400.  I may have used the CBR_14400.

If we can't access this through the win32 API with protected mode, there 
is another layer of complication.  With real mode, it would be easy.
With protected mode, I assume there would have to be some kernel driver or 
a hook I'm not aware of to access the MCR directly (bang a memory 
addresss).



On Thu, 1 Jun 2006, Daren wrote:

> Trent,
> I have managed to successfully open the port at this speed using Realterm
> (available on sourceforge). From memory this uses DLPortIO.
>
> Using portmon.exe with realterm, even there it says that the port has opened
> at 1953.
>
> I changed termios.c:560 to
> dcb->BaudRate        = 1953 ;
>
> and it still opens the port at 9600.
>
> Daren
>
> -----Original Message-----
> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
> Trent Jarvi
> Sent: Thursday, 1 June 2006 1:44 PM
> To: RXTX Developers and Users
> Subject: Re: [Rxtx] custom baud rate win32
>
> On Thu, 1 Jun 2006, Daren wrote:
>
>> Hi all,
>>
>> I downloaded 2.1.7-pre16 and managed to build it and get it going. I made
>> the changes as suggested by Peter Smith in an old post, by adding his code
>> to SerialImpl.c, uncommenting the TIOCGSERIAL and TIOCSSERIAL, and
> defining
>> ASYNC_SPD_CUST which is equal to 0x0030 (according to linus header
> files)..
>>
>>
>> Still not working, it opens the port at 9600 according to portmon.exe .
> Has
>> anyone managed to get this going at a custom rate?
>>
>> Here is the post I'm referring to:
>> http://marc.theaimsgroup.com/?l=rxtx&m=106270038110713&w=2
>>
>>
>> Thanks,
>> Daren
>>
>> ________________________________________
>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
>> Daren
>> Sent: Wednesday, 31 May 2006 10:56 PM
>> To: rxtx at qbang.org
>> Subject: [Rxtx] (no subject)
>>
>> Hi All,
>> I have been using rxtx for a little while and needed to get it working at
>> 1953, like a past user in the mailing list, who seemed to have got it
>> working by changing some C code.
>>
>> I wanted to build rxtx myself with these changes but don't know where to
>> start. I have windows here and FC4 at home. I downloaded cygwin and
> mingw32,
>> each build works by building a rxtxSerial.dll file that is ~11k smaller
> than
>> the original, and I always get the following error when testing the dll:
>>
>> Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at
>> PC=0x8077655
>> Function=[Unknown.]
>> Library=C:\opt\java\j2sdk1.4.2\jre\bin\client\jvm.dll
>>
>> NOTE: We are unable to locate the function name symbol for the error
>>      just occurred. Please refer to release documentation for possible
>>      reason and solutions.
>>
>>
>> Current Java thread:
>> 	at gnu.io.RXTXPort.open(Native Method)
>> 	- locked <0x1002c800> (a gnu.io.RXTXPort)
>> 	at gnu.io.RXTXPort.<init>(RXTXPort.java:84)
>>
>> Anyone know what im doing wrong?
>>
>>
>>
>>
>
> Hi Daren
>
> You are running into the same rats nest I'm looking at now.
>
> With win32 and specific custom baud rates, I'm not sure how this will go.
> I've got the Linux custom baud rates working very nicely.  I did much like
> the post you linked.  In fact I had forgot about that post.  You probably
> noticed that it becomes a bunch of dirt roads going noplace fast in
> termios.c for w32.
>
> I'm probably only going to get 14400, 28800, 128000 and 256000 working
> with the next release on w32.  I'll look a little further.  If you have an
> example w32 that works at 1953 I'd really like to hear.  Thats an unusual
> baud rate.
>
> Assuming a baud_base of 128000, your divisor will be 65 or 66.
>
> 128000/66=1939 -14
> 128000/65=1969 +13
>
> One thing I've been wondering about with linux is which would be the right
> answer in cases like this.  Right now it would just go with a baud base of
> 65 and ignore the modulus details.
>
> It appears to be a general trend for kernel developers to hide these
> details thinking that they can come up with a general solution.  Then they
> run out of time.  Perahps the solution is to help out but there are
> ultiple OS's rxtx supports making that nontrivial.
>
> If you look at current linux kernels, the 'tricks' above have been marked
> deprecated with no replacement.  Windows has some hard defines and then
> ancient near magic.  I've not looked at Solaris via Open Solaris yet but
> doubt there is a solution at all.
>
> What I'd try since you have the equipment and the monitor software is to
> hardcode the dcb->Baud in termios.c to 1953 (no define) and see what the
> w32 kernel does with it.  I think if you toss a baud rate at the driver it
> will try to come close.  You may try comming closer to a real baudrate
> based upon the 128000 baud base as shown above.
>
> If it works, it is worth looking at the rest of the ping/pong logic then.
>
> --
> Trent Jarvi
> tjarvi at qbang.org
>
>
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>


From doug at dupreeinc.com  Thu Jun  1 13:22:13 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 12:22:13 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011107210.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
Message-ID: <447F3E65.1020809@dupreeinc.com>

Hello,

I am still trying to get this startup a little faster so I turned on the 
debug of a few of the classes.  The COM ports are scanned really fast 
and the delay occurs during the LPT scan.  The console output looks like 
this:

    ...
      LPT1
      LPT2
      LPT3
     valid port prefixes:
      LPT
    LPT1 LPT
    1 1
    LPT2 LPT
    2 2                                                                 
      * <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
    CommPortIdentifier:addPortName(LPT2)
    CommPortIdentifier:AddIdentifierToList()
    LPT3 LPT
    3 3
    CommPortIdentifier:addPortName(LPT3)
    CommPortIdentifier:AddIdentifierToList()
    CommPortIdentifier:AddIdentifierToList() index.next
    Leaving registerValidPorts()
    Have not implemented native_psmisc_report_owner(PortName)); in
    CommPortIdentifier
    CommPortIdentifier:getPortIdentifier(COM3)
    CommPortIdentifier:open(densConnect, 30000)
    RXTXCommDriver:getCommPort(COM3,1)
    ...

It would seem to me that if I removed the code for port scanning of LPT 
ports I could solve this problem. I would much prefer to use unmodified 
code if at all possible.  Do any of you have alternate suggestions?

Thank you for your time.

Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/cf433ee7/attachment-0024.html

From tjarvi at qbang.org  Thu Jun  1 13:52:06 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 13:52:06 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F3E65.1020809@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011348380.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> Hello,
>
> I am still trying to get this startup a little faster so I turned on the 
> debug of a few of the classes.  The COM ports are scanned really fast and the 
> delay occurs during the LPT scan.  The console output looks like this:
>
>   ...
>     LPT1
>     LPT2
>     LPT3
>    valid port prefixes:
>     LPT
>   LPT1 LPT
>   1 1
>   LPT2 LPT
>   2 2                                                                      * 
> <<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>   CommPortIdentifier:addPortName(LPT2)
>   CommPortIdentifier:AddIdentifierToList()
>   LPT3 LPT
>   3 3
>   CommPortIdentifier:addPortName(LPT3)
>   CommPortIdentifier:AddIdentifierToList()
>   CommPortIdentifier:AddIdentifierToList() index.next
>   Leaving registerValidPorts()
>   Have not implemented native_psmisc_report_owner(PortName)); in
>   CommPortIdentifier
>   CommPortIdentifier:getPortIdentifier(COM3)
>   CommPortIdentifier:open(densConnect, 30000)
>   RXTXCommDriver:getCommPort(COM3,1)
>   ...
>
> It would seem to me that if I removed the code for port scanning of LPT ports 
> I could solve this problem. I would much prefer to use unmodified code if at 
> all possible.  Do any of you have alternate suggestions?
>
> Thank you for your time.
>
> Doug
>


Does commenting out the LPT enumeration actually help?  There can often be 
differences between debug information printed and whats really going on. 
When you combine various environments the debug info can even come out in 
the wrong order.

I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
I do not think this problem is universal.

--
Trent Jarvi
tjarvi at qbang.org


From doug at dupreeinc.com  Thu Jun  1 14:29:44 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:29:44 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4E38.2060004@dupreeinc.com>

I will give it a try.  One thing to note on this PC is it has no LPT 
Parallel ports.

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
>>Hello,
>>
>>I am still trying to get this startup a little faster so I turned on the 
>>debug of a few of the classes.  The COM ports are scanned really fast and the 
>>delay occurs during the LPT scan.  The console output looks like this:
>>
>>  ...
>>    LPT1
>>    LPT2
>>    LPT3
>>   valid port prefixes:
>>    LPT
>>  LPT1 LPT
>>  1 1
>>  LPT2 LPT
>>  2 2                                                                      * 
>><<<<<<<<<<<<<<<============  Delay is after this line is printed.*
>>  CommPortIdentifier:addPortName(LPT2)
>>  CommPortIdentifier:AddIdentifierToList()
>>  LPT3 LPT
>>  3 3
>>  CommPortIdentifier:addPortName(LPT3)
>>  CommPortIdentifier:AddIdentifierToList()
>>  CommPortIdentifier:AddIdentifierToList() index.next
>>  Leaving registerValidPorts()
>>  Have not implemented native_psmisc_report_owner(PortName)); in
>>  CommPortIdentifier
>>  CommPortIdentifier:getPortIdentifier(COM3)
>>  CommPortIdentifier:open(densConnect, 30000)
>>  RXTXCommDriver:getCommPort(COM3,1)
>>  ...
>>
>>It would seem to me that if I removed the code for port scanning of LPT ports 
>>I could solve this problem. I would much prefer to use unmodified code if at 
>>all possible.  Do any of you have alternate suggestions?
>>
>>Thank you for your time.
>>
>>Doug
>>
>>    
>>
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/dd31fed5/attachment-0024.html

From doug at dupreeinc.com  Thu Jun  1 14:36:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 13:36:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <Pine.LNX.4.61.0606011348380.30220@www>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <447F4FC8.9080106@dupreeinc.com>

Trent,

I commented out the section in RegisterScannedPorts() that adds the 
three LPT ports to the CandidateDeviceNames string array.  The 
application started immediately.  This is probably not the way to do 
this, but it was quick ,dirty, and worked.

It would be nice if there was a way to pole the OS to see if there is 
even a port there, though I guess this is what this code is suppose to do...

Doug

Trent Jarvi wrote:

>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>
>  
>
> ...
>
>
>Does commenting out the LPT enumeration actually help?  There can often be 
>differences between debug information printed and whats really going on. 
>When you combine various environments the debug info can even come out in 
>the wrong order.
>
>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>I do not think this problem is universal.
>
>--
>Trent Jarvi
>tjarvi at qbang.org
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From lynn at swcp.com  Thu Jun  1 14:49:34 2006
From: lynn at swcp.com (lynn@swcp.com)
Date: Thu, 1 Jun 2006 20:49:34 -0000
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>,
	<Pine.LNX.4.61.0606011348380.30220@www>
Message-ID: <twig.1149194974.97617@swcp.com>

Perhaps we could add an argument to port enumeration where if not specified,
you get the default behavior that looks for everything.  With a new
constructor that has an argument(or more) you could optionally declare it to
not inspect printer ports.

Existing code would work as it always has.  New code could be smarter.

Lynn



Doug Thistlethwaite <doug at dupreeinc.com> said:

> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
> >On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
> >
> >  
> >
> > ...
> >
> >
> >Does commenting out the LPT enumeration actually help?  There can often be 
> >differences between debug information printed and whats really going on. 
> >When you combine various environments the debug info can even come out in 
> >the wrong order.
> >
> >I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
> >I do not think this problem is universal.
> >
> >--
> >Trent Jarvi
> >tjarvi at qbang.org
> >_______________________________________________
> >Rxtx mailing list
> >Rxtx at qbang.org
> >http://mailman.qbang.org/mailman/listinfo/rxtx
> >
> >
> >  
> >
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
> 



-- 





From jredman at ergotech.com  Thu Jun  1 15:20:20 2006
From: jredman at ergotech.com (Jim Redman)
Date: Thu, 01 Jun 2006 15:20:20 -0600
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F4FC8.9080106@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
Message-ID: <447F5A14.6010803@ergotech.com>

Doug,

If you specifically request ports, eg:

-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

or
 
-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3

Depending upon the version  (Windows is COM1:COM2, etc. I assume).

Does it still enumerate the parallel ports?

Jim

Doug Thistlethwaite wrote:
> Trent,
> 
> I commented out the section in RegisterScannedPorts() that adds the 
> three LPT ports to the CandidateDeviceNames string array.  The 
> application started immediately.  This is probably not the way to do 
> this, but it was quick ,dirty, and worked.
> 
> It would be nice if there was a way to pole the OS to see if there is 
> even a port there, though I guess this is what this code is suppose to do...
> 
> Doug
> 
> Trent Jarvi wrote:
> 
>> On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>
>>  
>>
>> ...
>>
>>
>> Does commenting out the LPT enumeration actually help?  There can often be 
>> differences between debug information printed and whats really going on. 
>> When you combine various environments the debug info can even come out in 
>> the wrong order.
>>
>> I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>> I do not think this problem is universal.
>>
>> --
>> Trent Jarvi
>> tjarvi at qbang.org
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>
>>
>>  
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


From doug at dupreeinc.com  Thu Jun  1 16:49:24 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:49:24 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6EF4.7080709@dupreeinc.com>

I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
folder.  I created this file and added the following to the file:

gnu.io.rxtx.SerialPorts=COM3

and I get the following error on the console:
CommPortIdentifier:static initialization()
RXTXCommDriver {}
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
RXTXCommDriver:
    Jar version = RXTX-2.1-7
    native lib Version = RXTX-2.1-7
RXTXCommDriver:initialize()
checking for system-known ports of type 1
checking registry for ports of type 1

RXTXCommDriver:addSpecifiedPorts()
Exception in thread "main" java.lang.ExceptionInInitializerError
    at 
densconnect.SerialConnection.openConnection(SerialConnection.java:136)
    at densconnect.DensTalk.<init>(DensTalk.java:165)
    at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
    at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
    at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
    at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
Caused by: java.lang.NullPointerException
    at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
CommPortIdentifier:addPortName(COM3)
CommPortIdentifier:AddIdentifierToList()
CommPortIdentifier:AddIdentifierToList() null
...


It looks like it  read COM3 from the file, but it had the above 
exception that killed it.  The strange this is this error is from 
RXTXCommDriver initialize function (if statement line):

        OS = System.getProperty("os.name");
                System.out.println("OS NAME: " + OS);
        if(OS.toLowerCase().indexOf("linux") == -1)

OS is returning null, thus the error.

If the file is not present, it scans the ports and reads the OS.

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>Doug Thistlethwaite wrote:
>  
>
>>Trent,
>>
>>I commented out the section in RegisterScannedPorts() that adds the 
>>three LPT ports to the CandidateDeviceNames string array.  The 
>>application started immediately.  This is probably not the way to do 
>>this, but it was quick ,dirty, and worked.
>>
>>It would be nice if there was a way to pole the OS to see if there is 
>>even a port there, though I guess this is what this code is suppose to do...
>>
>>Doug
>>
>>Trent Jarvi wrote:
>>
>>    
>>
>>>On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:
>>>
>>> 
>>>
>>>...
>>>
>>>
>>>Does commenting out the LPT enumeration actually help?  There can often be 
>>>differences between debug information printed and whats really going on. 
>>>When you combine various environments the debug info can even come out in 
>>>the wrong order.
>>>
>>>I thought this may be IrDA/Bluetooth ports causing the delay as the reset. 
>>>I do not think this problem is universal.
>>>
>>>--
>>>Trent Jarvi
>>>tjarvi at qbang.org
>>>_______________________________________________
>>>Rxtx mailing list
>>>Rxtx at qbang.org
>>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>>
>>>
>>> 
>>>
>>>      
>>>
>>_______________________________________________
>>Rxtx mailing list
>>Rxtx at qbang.org
>>http://mailman.qbang.org/mailman/listinfo/rxtx
>>    
>>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060601/bf4cca0e/attachment-0024.html

From doug at dupreeinc.com  Thu Jun  1 16:51:26 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 15:51:26 -0700
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F5A14.6010803@ergotech.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>	<Pine.LNX.4.61.0606011107210.30220@www>	<447F3E65.1020809@dupreeinc.com>	<Pine.LNX.4.61.0606011348380.30220@www>	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com>
Message-ID: <447F6F6E.5060603@dupreeinc.com>

Jim,

I did not try your suggestion as I do not understand where I would put 
these command line parameters (it that is what they are).  It appears 
that using the properties file should do that same thing...

Doug

Jim Redman wrote:

>Doug,
>
>If you specifically request ports, eg:
>
>-Dgnu.io.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>or
> 
>-Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyS1:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3
>
>Depending upon the version  (Windows is COM1:COM2, etc. I assume).
>
>Does it still enumerate the parallel ports?
>
>Jim
>
>
>  
>


From doug at dupreeinc.com  Thu Jun  1 17:56:19 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 16:56:19 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
Message-ID: <447F7EA3.6050400@dupreeinc.com>

I think there is an error in the registerSpecifiedPorts() method.  When 
I have a gnu.io.rxtx.properties file in the ext directory, this function 
kills the System class  IF I call System.getProperty("os.name") before 
the call  to registerSpecifiedPorts(), it returns the os name, after the 
call, it returns null.  I have not played much with properties, except 
for reading them, so I don't really understand the code.

Doug



From doug at dupreeinc.com  Thu Jun  1 18:11:14 2006
From: doug at dupreeinc.com (Doug Thistlethwaite)
Date: Thu, 01 Jun 2006 17:11:14 -0700
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F7EA3.6050400@dupreeinc.com>
References: <447F7EA3.6050400@dupreeinc.com>
Message-ID: <447F8222.3060402@dupreeinc.com>

Ok, I just hacked this thing up and got it to read the 
gnu.io.rxtx.properties file.

I commented out the line:
System.setProperties(p); in the method registerSpecifiedPorts() in 
RXTXCommDriver class.  I really don't understand that much about 
properties, but this call kills the System class.

I used the following in the gnu.io.rxtx.properties file:

gnu.io.rxtx.SerialPorts=COM3
gnu.io.rxtx.ParallelPorts=null

This allows the application to open very quickly without any errors.  
Whomever coded this class or somebody who understands properties should 
look at this method and make sure it is doing what they expect.

Doug




Doug Thistlethwaite wrote:

>I think there is an error in the registerSpecifiedPorts() method.  When 
>I have a gnu.io.rxtx.properties file in the ext directory, this function 
>kills the System class  IF I call System.getProperty("os.name") before 
>the call  to registerSpecifiedPorts(), it returns the os name, after the 
>call, it returns null.  I have not played much with properties, except 
>for reading them, so I don't really understand the code.
>
>Doug
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
>  
>


From tjarvi at qbang.org  Thu Jun  1 18:32:50 2006
From: tjarvi at qbang.org (Trent Jarvi)
Date: Thu, 1 Jun 2006 18:32:50 -0600 (MDT)
Subject: [Rxtx] windows XP slow start
In-Reply-To: <447F6EF4.7080709@dupreeinc.com>
References: <200606010406.k51464X2010447@mail03.syd.optusnet.com.au>
	<Pine.LNX.4.61.0606011107210.30220@www>
	<447F3E65.1020809@dupreeinc.com>
	<Pine.LNX.4.61.0606011348380.30220@www>
	<447F4FC8.9080106@dupreeinc.com>
	<447F5A14.6010803@ergotech.com> <447F6EF4.7080709@dupreeinc.com>
Message-ID: <Pine.LNX.4.61.0606011831510.30220@www>

On Thu, 1 Jun 2006, Doug Thistlethwaite wrote:

> I noticed that I did not have a gnu.io.rxtx.prioerties file in the ext 
> folder.  I created this file and added the following to the file:
>
> gnu.io.rxtx.SerialPorts=COM3
>
> and I get the following error on the console:
> CommPortIdentifier:static initialization()
> RXTXCommDriver {}
> Stable Library
> =========================================
> Native lib Version = RXTX-2.1-7
> Java lib Version   = RXTX-2.1-7
> RXTXCommDriver:
>   Jar version = RXTX-2.1-7
>   native lib Version = RXTX-2.1-7
> RXTXCommDriver:initialize()
> checking for system-known ports of type 1
> checking registry for ports of type 1
>
> RXTXCommDriver:addSpecifiedPorts()
> Exception in thread "main" java.lang.ExceptionInInitializerError
>   at densconnect.SerialConnection.openConnection(SerialConnection.java:136)
>   at densconnect.DensTalk.<init>(DensTalk.java:165)
>   at densconnect.TestDensTalkFrame.jbInit(TestDensTalkFrame.java:92)
>   at densconnect.TestDensTalkFrame.<init>(TestDensTalkFrame.java:71)
>   at densconnect.TestDensTalkApp.<init>(TestDensTalkApp.java:20)
>   at densconnect.TestDensTalkApp.main(TestDensTalkApp.java:49)
> Caused by: java.lang.NullPointerException
>   at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:78)
> CommPortIdentifier:addPortName(COM3)
> CommPortIdentifier:AddIdentifierToList()
> CommPortIdentifier:AddIdentifierToList() null
> ...
>
>

There is a solution for this bug.

http://bugzilla.qbang.org/show_bug.cgi?id=54

We have been horribly slow at getting the next round of patches in but 
they are comming.

--
Trent Jarvi
tjarvi at qbang.org


From joachim at buechse.de  Fri Jun  2 00:58:02 2006
From: joachim at buechse.de (Joachim Buechse)
Date: Fri, 2 Jun 2006 08:58:02 +0200
Subject: [Rxtx] Problem in registerSpecifiedPorts
In-Reply-To: <447F8222.3060402@dupreeinc.com>
References: <447F7EA3.60504