[prev in list] [next in list] [prev in thread] [next in thread]
List: rxtx
Subject: Re: [Rxtx] Some RXTX questions
From: Ytai Ben-Tsvi <ytaibt () gmail ! com>
Date: 2012-06-22 3:31:14
Message-ID: CANfwwrCM-Qs_wQYDNVzg09VwW95zDDa3VuKjN73uKU1BovShTg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Thanks!
I'm pretty surprised that with a project like Arduino as a client, nobody
made the effort of making sure this plays nicely with USB. But then again,
if they haven't bothered, perhaps I can live with it too...
Looking forward to your release. I'll definitely give it a go.
Ytai
On Sun, Jun 17, 2012 at 9:24 PM, Trent Jarvi <tjarvi@qbang.org> wrote:
>
> The releases are about two nights work away which should happen in the
> next week or two. It may be pushing it to assume everything will be right
> for your release in four weeks if you notice issues.
>
> USB serial being plugged in is a different beast. The action results in a
> USB hotplug event. Without listening for these events through the USB api,
> it is difficult to become aware of a device being plugged in.
>
> Currently, as you noticed, rxtx scans for ports. It also caches the
> results for future queries. This can be problematic for people wanting USB
> hotplug behavior. You may want to look at the scanning solution you
> mentioned sooner rather than later if the expectation is to work with
> hotplugged USB serial devices.
>
> Without some effort, it will not be possible to poll for new devices.
>
>
> On Sun, 17 Jun 2012, Ytai Ben-Tsvi wrote:
>
> Thanks for the answers. More inline.
>>
>> On Sun, Jun 17, 2012 at 6:07 PM, Trent Jarvi <tjarvi@qbang.org> wrote:
>>
>>
>> On Sun, 17 Jun 2012, Ytai Ben-Tsvi wrote:
>>
>> Hi folks!I've seen some of these questions asked in the past,
>> but couldn't find any definite answers.
>> I'm looking into using rxtx in a cross-platform app used to
>> communicate with a USB CDC device.
>>
>> I've managed to get the basics working (using the 2.1.7
>> binaries + cloudhopper's binaries), but am still encountering
>> some annoyances. Perhaps someone
>> can shed some light on the best practices.
>> 1. Closing the port while a thread is blocking on reading. From reading
>> the code it seems to be (deliberately?) impossible. I've worked
>> around this by
>> adding a timeout on the reads and checking for a close flag every
>> time. Ugly but works. I'm wondering what is the reasoning behind the
>> existing
>>
>>
>> If you enabled timeouts, the close should happen without checking flags.
>>
>>
>> I meant that I need to set a flag meaning "I'm closing", so that when my
>> read() returns a -1 I can know whether that's a timeout or a close. In the
>> former case, I'd like to go right back into read, thus simulating a true
>> blocking read.
>>
>>
>>
>> logic (which basically requires the remote end to
>> collaborate in
>>
>> order to be able to close the port).
>> 2. Graceful handling of USB disconnect while the port is in use.
>> I'd expect a IOException thrown, but instead it's crashing the VM.
>> Recommendations?
>>
>>
>> This may be fixed in CVS. I'm working on new bins.
>>
>>
>> Oh, great. So there's a new binary release coming? Any idea when
>> approximately? Would be great if I can include this in my release, which is
>> about a
>> month away.
>>
>>
>> 3. USB enumeration on Windows takes ages. I understand that
>> trying each and every COM is possibly the only reliable way to go.
>> But strangely, it is
>> done even when creating a PortIdentifier by name. I
>>
> sympathize with the urge to punish Windows users for using Windows, but
>
>> is this really
>> necessary? Can't the enumeration be done only when the user
>> is requesting an enumeration? As a workaround, I'm currently
>> passing
>> the gnu.io.SerialPorts property.
>>
>>
>> I've only seen enumeration take a long time when some Bluetooth/Serial
>> stacks are enabled. They spend time looking for possible connections
>> presumably.
>>
>>
>> Could be. I indeed have Bluetooth enabled, so this may be the case.
>>
>>
>> If you want to submit a patch that enumerates when requested, we can
>> add it. This would probably help when people want to 'rescan.' USB
>> serial ports became popular after rxtx was implemented so there may
>> still need to be some changes made for them. Initially, they didnt
>> support serial ports well enough to bother with.
>>
>>
>> I might. This would sort of throw me out of focus on my own product, but
>> I might do that if I feel that without it my product would provide a lesser
>> user experience. Maybe I'll add it at a later stage.
>>
>>
>> 4. What is the recommended way to wait until a port becomes
>> available (i.e. USB UART is attached)? Just catch an exception,
>> delay, retry later?
>> Thanks a lot for this helpful library!
>> Ytai
>>
>>
>> RXTX basically expects serial ports to be soldiered onto the motherboard
>> or attached very well with duct tape :). One could explore enabling OS
>> specific USB connect/disconnect events.
>>
>>
>> I'm not sure whether explicit handling of the USB case would be required.
>> I'm assuming that even when treating these things as abstract serial ports,
>> the OS will somehow gracefully signal the client on disconnection /
>> connection (in the latter case, the client might have to constantly poll).
>>
>>
>> --
>> Trent Jarvi
>> tjarvi@qbang.org
>> ______________________________**_________________
>> Rxtx mailing list
>> Rxtx@qbang.org
>> http://mailman.qbang.org/**mailman/listinfo/rxtx<http://mailman.qbang.org/mailman/listinfo/rxtx>
>>
>>
>>
>>
> _______________________________________________
> Rxtx mailing list
> Rxtx@qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
>
[Attachment #5 (text/html)]
<div dir="ltr">Thanks!<div>I'm pretty surprised that with a project like Arduino \
as a client, nobody made the effort of making sure this plays nicely with USB. But \
then again, if they haven't bothered, perhaps I can live with it too...</div>
<div>Looking forward to your release. I'll definitely give it a \
go.</div><div><br></div><div>Ytai<br><br><div class="gmail_quote">On Sun, Jun 17, \
2012 at 9:24 PM, Trent Jarvi <span dir="ltr"><<a href="mailto:tjarvi@qbang.org" \
target="_blank">tjarvi@qbang.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><br> The releases are about two nights work away which should \
happen in the next week or two. It may be pushing it to assume everything will be \
right for your release in four weeks if you notice issues.<br> <br>
USB serial being plugged in is a different beast. The action results in a USB \
hotplug event. Without listening for these events through the USB api, it is \
difficult to become aware of a device being plugged in.<br> <br>
Currently, as you noticed, rxtx scans for ports. It also caches the results for \
future queries. This can be problematic for people wanting USB hotplug behavior. \
You may want to look at the scanning solution you mentioned sooner rather than later \
if the expectation is to work with hotplugged USB serial devices.<br>
<br>
Without some effort, it will not be possible to poll for new devices.<div \
class="HOEnZb"><div class="h5"><br> <br>
On Sun, 17 Jun 2012, Ytai Ben-Tsvi wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> Thanks for the answers. More inline.<br>
<br>
On Sun, Jun 17, 2012 at 6:07 PM, Trent Jarvi <<a href="mailto:tjarvi@qbang.org" \
target="_blank">tjarvi@qbang.org</a>> wrote:<br> <br>
<br>
On Sun, 17 Jun 2012, Ytai Ben-Tsvi wrote:<br>
<br>
Hi folks!I've seen some of these questions asked in the past, but \
couldn't find any definite answers.<br>
I'm looking into using rxtx in a cross-platform app used to \
communicate with a USB CDC device.<br> <br>
I've managed to get the basics working (using the 2.1.7 binaries + \
cloudhopper's binaries), but am still encountering<br> some annoyances. Perhaps \
someone<br> can shed some light on the best practices.<br>
1. Closing the port while a thread is blocking on reading. From reading the code it \
seems to be (deliberately?) impossible. I've worked<br> around this by<br>
adding a timeout on the reads and checking for a close flag every time. Ugly but \
works. I'm wondering what is the reasoning behind the<br> existing<br>
<br>
<br>
If you enabled timeouts, the close should happen without checking flags.<br>
<br>
<br>
I meant that I need to set a flag meaning "I'm closing", so that when \
my read() returns a -1 I can know whether that's a timeout or a close. In the<br> \
former case, I'd like to go right back into read, thus simulating a true blocking \
read.<br> <br>
<br>
<br>
logic (which basically requires the remote end to collaborate in<br>
<br>
order to be able to close the port).<br>
2. Graceful handling of USB disconnect while the port is in use. I'd \
expect a IOException thrown, but instead it's crashing the VM.<br> \
Recommendations?<br> <br>
<br>
This may be fixed in CVS. I'm working on new bins.<br>
<br>
<br>
Oh, great. So there's a new binary release coming? Any idea when approximately? \
Would be great if I can include this in my release, which is about a<br> month \
away.<br> <br>
<br>
3. USB enumeration on Windows takes ages. I understand that trying each \
and every COM is possibly the only reliable way to go.<br> But strangely, it is<br>
done even when creating a PortIdentifier by name. I <br>
</blockquote>
sympathize with the urge to punish Windows users for using Windows, but<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> is this really<br>
necessary? Can't the enumeration be done only when the user is \
requesting an enumeration? As a workaround, I'm currently<br> passing<br>
the gnu.io.SerialPorts property.<br>
<br>
<br>
I've only seen enumeration take a long time when some Bluetooth/Serial stacks are \
enabled. They spend time looking for possible connections<br> presumably.<br>
<br>
<br>
Could be. I indeed have Bluetooth enabled, so this may be the case.<br>
<br>
<br>
If you want to submit a patch that enumerates when requested, we can add it. \
This would probably help when people want to 'rescan.' \
USB<br>
serial ports became popular after rxtx was implemented so there may still need \
to be some changes made for them. Initially, they didnt<br> support serial ports \
well enough to bother with.<br> <br>
<br>
I might. This would sort of throw me out of focus on my own product, but I might do \
that if I feel that without it my product would provide a lesser<br> user experience. \
Maybe I'll add it at a later stage.<br> <br>
<br>
4. What is the recommended way to wait until a port becomes available \
(i.e. USB UART is attached)? Just catch an exception,<br> delay, retry later?<br>
Thanks a lot for this helpful library!<br>
Ytai<br>
<br>
<br>
RXTX basically expects serial ports to be soldiered onto the motherboard or attached \
very well with duct tape :). One could explore enabling OS<br> specific USB \
connect/disconnect events.<br> <br>
<br>
I'm not sure whether explicit handling of the USB case would be required. I'm \
assuming that even when treating these things as abstract serial ports,<br> the OS \
will somehow gracefully signal the client on disconnection / connection (in the \
latter case, the client might have to constantly poll).<br> <br>
<br>
--<br>
Trent Jarvi<br>
<a href="mailto:tjarvi@qbang.org" target="_blank">tjarvi@qbang.org</a><br>
______________________________<u></u>_________________<br>
Rxtx mailing list<br>
<a href="mailto:Rxtx@qbang.org" target="_blank">Rxtx@qbang.org</a><br>
<a href="http://mailman.qbang.org/mailman/listinfo/rxtx" \
target="_blank">http://mailman.qbang.org/<u></u>mailman/listinfo/rxtx</a><br> <br>
<br>
<br>
</blockquote>
</div></div><br>_______________________________________________<br>
Rxtx mailing list<br>
<a href="mailto:Rxtx@qbang.org">Rxtx@qbang.org</a><br>
<a href="http://mailman.qbang.org/mailman/listinfo/rxtx" \
target="_blank">http://mailman.qbang.org/mailman/listinfo/rxtx</a><br> \
<br></blockquote></div><br></div></div>
_______________________________________________
Rxtx mailing list
Rxtx@qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic