[Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED]
M.Dec-GM
mariusz.dec at gmail.com
Thu Sep 30 06:58:06 MDT 2010
Hi,
in miliseconds, I have 10 like in the example.
Regards
Mariusz
----- Original Message -----
From: "Philipp Leusmann" <philipp.leusmann at rwth-aachen.de>
To: <rxtx at qbang.org>
Sent: Thursday, September 30, 2010 2:26 PM
Subject: Re: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED]
> Hi Mariusz,
>
> please see inline comments.
>
> Am 29.09.2010 um 12:19 schrieb Mariusz Dec:
>
>> Hi Philipp,
>> Yes, you are "almost" right - synchronised closing this is ONLY the
>> part of the trick , the second thing in Mac & Linux is Receive
>> timeout.
>> This is described in example as the "critical confiiguration stuff".
>
>
> Cool, this really seems to help.
> Though, which unit is the timeout in? milliseconds? seconds?
>
>
>>
>> I have tried to do this trick "inside" RXTX, but without successes, so
>> I have decided to prepare a kind of the workaround without patches
>> (CVS).
>> I think that anyway this is enough good way - in my opinion a bit of
>> work should stay for the application's programmer :) - utility
>> packages aren't applications :).
>
> But I still consider locking up when running multi-threaded a library issue and it would be great, if it could be fixed without jumping through hoops in the application code.
>
>
>>
>> As I have mentioned in example, this code works with "pure"
>> RXTX2.2pre2 from November 2009.
>> If you would like to check my code in such environment, please let me
>> know, I will prepare this RXTX sources on my FTP for you.
>>
>
> I tried using the CVS code from some weeks ago.
>
>> Another friends who have had succeses with this code, always have
>> started from my pure example. Have you checked it?
>
> Yes, I checked your example but simply forgot to add the timeout.
> I added the stuff to my own pre-existing code.
>
> To sum my results up, it seems it must be performed in each thread like this (in pseudo-code):
>
> CommPort.enableReceiveTimeout(100);
>
> synchronized (GLOBAL_MUTEX) {
> CommPortIdentifier.open(...);
> }
>
> //perform IO
>
> //wait until all threads finished IO operations
>
> synchronized (GLOBAL_MUTEX) {
> CommPort.close();
> }
>
>
> Did I forget anything important?
>
> Regards,
> Philipp
>
>
>>
>> Regards
>> Mariusz
>>
>>
>>
>>
>>
>> 2010/9/29, Philipp Leusmann <philipp.leusmann at rwth-aachen.de>:
>>> Hi,
>>>
>>> sorry, I do not really get the status of this discussion.
>>> I saw Mariusz did publish the sources for the client, but cannot find any of
>>> the mentioned patches to RXTX. Have they been merged into the CVS?
>>>
>>> I am experiencing locking when trying to close the serial connection, and I
>>> guess this is what it's all about. Isn't it?
>>>
>>> By looking at the client code posted by Mariusz it seems that synchronizing
>>> access when closing one thread to avoid any IO-Operations by other threads
>>> shall do the trick. Did I get this right?
>>> The last time I checked, this did not help at all (using CVS code from some
>>> weeks ago).
>>>
>>> It would be really cool, if this problem can be fixed.
>>>
>>> Regards,
>>> Philipp
>>>
>>>
>>>
>>> Am 14.09.2010 um 09:36 schrieb M.Dec-GM:
>>>
>>>> Thank you John :)
>>>> I have just prepared Java workaround example app with documentation
>>>> inside, and in few minutes it will available here as well.
>>>> I think that your solution is good, but in my example I am showing
>>>> aditionally a very fast method of the transferring data from serial to
>>>> application.
>>>> It was suggestion of Michael Erskine and I did it.
>>>> So I will publish it as well :)
>>>>
>>>> Regards
>>>> Mariusz
>>>>
>>>>
>>>> ----- Original Message -----
>>>> From: "John Coffey" <johnco3 at gmail.com>
>>>> To: <rxtx at qbang.org>
>>>> Sent: Tuesday, September 14, 2010 8:24 AM
>>>> Subject: Re: [Rxtx] RXTX and Macintosh, Information Please
>>>> [SEC=UNCLASSIFIED]
>>>>
>>>>
>>>> Mariusz,
>>>>
>>>> here is a patch that I've been testing this evening so far without
>>>> problems (I tested Windows XP 32 bit earlier and here I just finished
>>>> testing a recompiled set of DLLs on x64 (compiled as x64), My code is
>>>> against the head of the current build and includes the disconnect
>>>> patch and a single patch that I needed for an 8200 byte input buffer
>>>> that I needed for my app. My patch is basically a combination of the
>>>> patch below brought up to date with the head of the 2.2pre2 tree in
>>>> CVS and a separate as per the link below you will need to include
>>>> Ilkkya's separate files are included via the link below.
>>>> My patch was generated by cvs diff -up . > latestgreatest.patch so the
>>>> patch can be applied
>>>>
>>>> src/gnu/io/PortAlreadyClosedException.java
>>>> src/gnu/io/SerialReconnectDemo.java
>>>>
>>>> It is in 'cvs diff -up' format. It can be applied with 'patch -p0 <
>>>> latestgreatest.patch' in rxtx-devel directory
>>>>
>>>> I added one thing that I needed for myself (for SetupComm to have an
>>>> 8k buffer for an avionics protocol, without it my app hung and
>>>> unfortunately the APIs to set the input and output buffer size for the
>>>> communications port are no-ops (see my commented out app code below)!
>>>> If you could see your way to putting that function in I would be
>>>> really grateful
>>>> http://mailman.qbang.org/pipermail/rxtx/2009-September/5724682.html
>>>>
>>>> /** internal thread control logic */
>>>> private void doCommControl(final Command aCommand) throws IOException {
>>>> try {
>>>> switch (aCommand) {
>>>> case StartComms:
>>>> mSerialPort = (SerialPort) mPortId.open("SerialMonitor", 2000);
>>>> // @TODO: Try to add support for buffer size
>>>> // This currently does not work as the port size
>>>> // parameter is ignored
>>>> // mSerialPort.setInputBufferSize(8200);
>>>> // int inputBufferSize = mSerialPort.getInputBufferSize();
>>>> // mSerialPort.setOutputBufferSize(8200);
>>>> // int outputBufferSize = mSerialPort.getOutputBufferSize();
>>>> // pre fetch from the receive buffer
>>>> //mSerialPort.enableReceiveThreshold(4096);
>>>> if (mFlowControl == FlowControl.FlowCtsRts) {
>>>> mSerialPort.setFlowControlMode(
>>>> SerialPort.FLOWCONTROL_RTSCTS_IN |
>>>> SerialPort.FLOWCONTROL_RTSCTS_OUT);
>>>> } else {
>>>> mSerialPort.setFlowControlMode(
>>>> SerialPort.FLOWCONTROL_NONE);
>>>> }
>>>> mInputStream = mSerialPort.getInputStream();
>>>> mOutputStream = mSerialPort.getOutputStream();
>>>> mSerialPort.addEventListener(this);
>>>>
>>>>
>>>> On Tue, Sep 14, 2010 at 1:04 AM, M.Dec-GM <mariusz.dec at gmail.com> wrote:
>>>>> Hi John, Hi Brian, Hi All
>>>>>
>>>>> I have send a parts of application with this code - (it isn't RXTX patch)
>>>>> to
>>>>> coulple of peples.
>>>>> But now there is more questions...
>>>>> We have a new day now - 7:00 am. I will busy until 10 am.
>>>>> After that I will prepare clear example and I will publish it here.
>>>>> Regards
>>>>> Mariusz
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>> From: Brian Schlining
>>>>> To: rxtx at qbang.org
>>>>> Sent: Tuesday, September 14, 2010 2:08 AM
>>>>> Subject: Re: [Rxtx] RXTX and Macintosh, Information Please
>>>>> [SEC=UNCLASSIFIED]
>>>>>
>>>>>
>>>>>> I recall the elegant fix you put together to
>>>>>> handle Close/reopen/disconnect USB patch? As I recall the only downside
>>>>>> from general adoption by the rxtx community was that the signature of
>>>>>> some
>>>>>> methods had an extra exception which was not quite compatible with
>>>>>> javax.comm or something to that effect. I can certainly live with that
>>>>>> :)
>>>>>> given the benefits of your fixes.
>>>>>
>>>>> I haven't looked at the code in question, but if the only downside is a
>>>>> change to the method signature I would recommend the following, if you
>>>>> want
>>>>> wider adoption:
>>>>> 1) If it's a new checked exception that's being thrown (i.e a subclass of
>>>>> Exception), change the exception to an unchecked (i.e. a subclass of
>>>>> RuntimeException).
>>>>> 2) Document in the javadoc that the method can throw your special
>>>>> Exception.
>>>>> 3) Return the method signature to match what RXTX had. The method can
>>>>> still
>>>>> throw your exception but it doesn't force users to catch it like a
>>>>> checked
>>>>> Exception does.
>>>>> Just my 2 cents
>>>>> --
>>>>> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
>>>>> Brian Schlining
>>>>> bschlining at gmail.com
>>>>>
>>>>> ________________________________
>>>>>
>>>>> _______________________________________________
>>>>> Rxtx mailing list
>>>>> Rxtx at qbang.org
>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>>>>
>>>>> _______________________________________________
>>>>> Rxtx mailing list
>>>>> Rxtx at qbang.org
>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Rxtx mailing list
>>>> Rxtx at qbang.org
>>>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>>
>>> _______________________________________________
>>> Rxtx mailing list
>>> Rxtx at qbang.org
>>> http://mailman.qbang.org/mailman/listinfo/rxtx
>>>
>> _______________________________________________
>> Rxtx mailing list
>> Rxtx at qbang.org
>> http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
More information about the Rxtx
mailing list