[purejavacomm] Re: Detect usb cable unplugged?
- From: Kustaa Nyholm <Kustaa.Nyholm@xxxxxxxxxxxx>
- To: "purejavacomm@xxxxxxxxxxxxx" <purejavacomm@xxxxxxxxxxxxx>
- Date: Thu, 21 Nov 2013 16:45:46 +0200
I was about to suggest the timeout which always makes sense in serial
communication anyway.
PJC does not really know that the port was plugged, it only knows that
something went wrong
and as a safety measure it closes the port internally as it is very unlikely
that the port will
function without re-opening and because of my experience with RXTX that
accessing
plugged out port may crash the JVM. That of course may just be RXTX.
So yes PJC knows that the port is closed but atm there is now way (without
reflection)
or modification to query that the port is closed. This is because the original
JavaComm
spec that RXTX and PJC try to adhere to does not expose that functionality. It
would
of course be trivial to add that. However read/write should fail with
IllegalStateException
if the port is closed so you could catch that.
br Kusti
From: ant elder <ant.elder@xxxxxxxxx<mailto:ant.elder@xxxxxxxxx>>
Reply-To: "purejavacomm@xxxxxxxxxxxxx<mailto:purejavacomm@xxxxxxxxxxxxx>"
<purejavacomm@xxxxxxxxxxxxx<mailto:purejavacomm@xxxxxxxxxxxxx>>
Date: Thu, 21 Nov 2013 15:03:36 +0200
To: "purejavacomm@xxxxxxxxxxxxx<mailto:purejavacomm@xxxxxxxxxxxxx>"
<purejavacomm@xxxxxxxxxxxxx<mailto:purejavacomm@xxxxxxxxxxxxx>>
Subject: [purejavacomm] Re: Detect usb cable unplugged?
Playing around a bit more i see that if i do enableReceiveTimeout(3000) on the
PJC SerialPort and then run and pull out the usb cable then after 3 seconds the
read gets an IOException with the message "Underlying input stream returned
zero bytes". That in itself is not really enough to tell the cable has been
pulled, but a subsequent write to the SerialPort then fails with an IOExcpetion
with no message from
purejavacomm.PureJavaSerialPort$1.write(PureJavaSerialPort.java:651).
So PJC knows and has closed the underlying port. But i can't see any way for my
code to query PJC to see that the port is now closed. Is there some API call
somewhere I could use to see that?
...ant
On Thu, Nov 21, 2013 at 10:54 AM, ant elder
<ant.elder@xxxxxxxxx<mailto:ant.elder@xxxxxxxxx>> wrote:
Sorry, just to be clear, thats actually doing a write followed by a read.
...ant
On Thu, Nov 21, 2013 at 10:53 AM, ant elder
<ant.elder@xxxxxxxxx<mailto:ant.elder@xxxxxxxxx>> wrote:
I've not tried it on Linux yet, but on Windows 7 if i pull out the cable and do
a read with PJC logging switched on, the read hangs and this is what logging is
output:
[err] log: 024372,class purejavacomm.PureJavaSerialPort$1 line 647, thread id
41, Default Executor-thread-6, >
write(0,[8192,0x31,0x2C,0x31,0x32,0x2C,0x31,0x0A,0x35...],7)
[err] log: 024373,class jtermios.windows.JTermiosImpl line 495, thread id 41,
Default Executor-thread-6, > WaitForMultipleObjects(2, [2,native@0x7b0
(jtermios.windows.WinAPI$HANDLE@7b0),native@0x7a8
(jtermios.windows.WinAPI$HANDLE@7a8)], false, -1)
[err] log: 024374,class jtermios.windows.JTermiosImpl line 495, thread id 41,
Default Executor-thread-6, < WaitForMultipleObjects(2, [2,native@0x7b0
(jtermios.windows.WinAPI$HANDLE@7b0),native@0x7a8
(jtermios.windows.WinAPI$HANDLE@7a8)], false, -1) => 0
[err] log: 024375,class jtermios.windows.JTermiosImpl line 501, thread id 41,
Default Executor-thread-6, > GetOverlappedResult(native@0x79c
(jtermios.windows.WinAPI$HANDLE@79c), auto-allocated@0x2485010 (32 bytes), [0],
false)
[err] log: 024376,class jtermios.windows.JTermiosImpl line 501, thread id 41,
Default Executor-thread-6, < GetOverlappedResult(native@0x79c
(jtermios.windows.WinAPI$HANDLE@79c), auto-allocated@0x2485010 (32 bytes), [7],
false) => true
[err] log: 024376,class jtermios.windows.JTermiosImpl line 519, thread id 41,
Default Executor-thread-6, > ResetEvent(native@0x7b0
(jtermios.windows.WinAPI$HANDLE@7b0))
[err] log: 024377,class jtermios.windows.JTermiosImpl line 519, thread id 41,
Default Executor-thread-6, < ResetEvent(native@0x7b0
(jtermios.windows.WinAPI$HANDLE@7b0)) => true
[err] log: 024377,class jtermios.windows.JTermiosImpl line 525, thread id 41,
Default Executor-thread-6, > WriteFile(native@0x79c
(jtermios.windows.WinAPI$HANDLE@79c), [7,0x31,0x2C,0x31,0x32,0x2C...], 7, [7],
auto-allocated@0x2485010 (32 bytes))
[err] log: 024378,class jtermios.windows.JTermiosImpl line 525, thread id 41,
Default Executor-thread-6, < WriteFile(native@0x79c
(jtermios.windows.WinAPI$HANDLE@79c), [7,0x31,0x2C,0x31,0x32,0x2C...], 7, [0],
auto-allocated@0x2485010 (32 bytes)) => false
[err] log: 024379,class jtermios.windows.JTermiosImpl line 528, thread id 41,
Default Executor-thread-6, > GetLastError()
[err] log: 024379,class jtermios.windows.JTermiosImpl line 528, thread id 41,
Default Executor-thread-6, < GetLastError() => 997
[err] log: 024380,class purejavacomm.PureJavaSerialPort$1 line 647, thread id
41, Default Executor-thread-6, <
write(0,[8192,0x31,0x2C,0x31,0x32,0x2C,0x31,0x0A,0x35...],7) => 7
[err] log: 024380,class purejavacomm.PureJavaSerialPort$1 line 673, thread id
41, Default Executor-thread-6, > tcdrain(0)
[err] log: 024381,class jtermios.windows.JTermiosImpl line 314, thread id 41,
Default Executor-thread-6, > FlushFileBuffers(native@0x79c
(jtermios.windows.WinAPI$HANDLE@79c))
[err] log: 024382,class jtermios.windows.JTermiosImpl line 314, thread id 41,
Default Executor-thread-6, < FlushFileBuffers(native@0x79c
(jtermios.windows.WinAPI$HANDLE@79c)) => true
[err] log: 024382,class purejavacomm.PureJavaSerialPort$1 line 673, thread id
41, Default Executor-thread-6, < tcdrain(0) => 0
[err] log: 024458,class purejavacomm.PureJavaSerialPort$2 line 891, thread id
41, Default Executor-thread-6, > select(1,[0],[],[],jtermios.TimeVal@43737616)
[err] log: 024459,class jtermios.windows.JTermiosImpl line 788, thread id 41,
Default Executor-thread-6, > ClearCommError(native@0x79c
(jtermios.windows.WinAPI$HANDLE@79c), [0], [fFlags 0000 cbInQue 0 cbInQue 0])
[err] log: 024460,class jtermios.windows.JTermiosImpl line 788, thread id 41,
Default Executor-thread-6, < ClearCommError(native@0x79c
(jtermios.windows.WinAPI$HANDLE@79c), [0], [fFlags 0000 cbInQue 0 cbInQue 0])
=> true
[err] log: 024461,class jtermios.windows.JTermiosImpl line 830, thread id 41,
Default Executor-thread-6, > SetCommMask(native@0x79c
(jtermios.windows.WinAPI$HANDLE@79c), 0x00000000)
[err] log: 024461,class jtermios.windows.JTermiosImpl line 830, thread id 41,
Default Executor-thread-6, < SetCommMask(native@0x79c
(jtermios.windows.WinAPI$HANDLE@79c), 0x00000000) => true
[err] log: 024462,class jtermios.windows.JTermiosImpl line 832, thread id 41,
Default Executor-thread-6, > GetOverlappedResult(native@0x79c
(jtermios.windows.WinAPI$HANDLE@79c), auto-allocated@0x2485040 (32 bytes), [4],
false)
[err] log: 024463,class jtermios.windows.JTermiosImpl line 832, thread id 41,
Default Executor-thread-6, < GetOverlappedResult(native@0x79c
(jtermios.windows.WinAPI$HANDLE@79c), auto-allocated@0x2485040 (32 bytes), [4],
false) => true
[err] log: 024463,class jtermios.windows.JTermiosImpl line 836, thread id 41,
Default Executor-thread-6, > ResetEvent(native@0x7b4
(jtermios.windows.WinAPI$HANDLE@7b4))
[err] log: 024464,class jtermios.windows.JTermiosImpl line 836, thread id 41,
Default Executor-thread-6, < ResetEvent(native@0x7b4
(jtermios.windows.WinAPI$HANDLE@7b4)) => true
[err] log: 024464,class jtermios.windows.JTermiosImpl line 845, thread id 41,
Default Executor-thread-6, > SetCommMask(native@0x79c
(jtermios.windows.WinAPI$HANDLE@79c), 0x00000001)
[err] log: 024465,class jtermios.windows.JTermiosImpl line 845, thread id 41,
Default Executor-thread-6, < SetCommMask(native@0x79c
(jtermios.windows.WinAPI$HANDLE@79c), 0x00000001) => true
[err] log: 024466,class jtermios.windows.JTermiosImpl line 848, thread id 41,
Default Executor-thread-6, > WaitCommEvent(native@0x79c
(jtermios.windows.WinAPI$HANDLE@79c), [0], auto-allocated@0x2485040 (32 bytes))
[err] log: 024466,class jtermios.windows.JTermiosImpl line 848, thread id 41,
Default Executor-thread-6, < WaitCommEvent(native@0x79c
(jtermios.windows.WinAPI$HANDLE@79c), [0], auto-allocated@0x2485040 (32 bytes))
=> false
[err] log: 024467,class jtermios.windows.JTermiosImpl line 856, thread id 41,
Default Executor-thread-6, > GetLastError()
[err] log: 024467,class jtermios.windows.JTermiosImpl line 856, thread id 41,
Default Executor-thread-6, < GetLastError() => 997
[err] log: 024468,class jtermios.windows.JTermiosImpl line 879, thread id 41,
Default Executor-thread-6, > WaitForMultipleObjects(2, [2,native@0x7b4
(jtermios.windows.WinAPI$HANDLE@7b4),native@0x7a0
(jtermios.windows.WinAPI$HANDLE@7a0)], false, 2147483647)
On Thu, Nov 21, 2013 at 10:48 AM, Kustaa Nyholm
<Kustaa.Nyholm@xxxxxxxxxxxx<mailto:Kustaa.Nyholm@xxxxxxxxxxxx>> wrote:
As far as the platform allows/enables PJC read throws an exception if a device
is unplugged.
Which platform you are using?
For Linux and Mac OS X, the inputstream.read() is very thin layer over the
POSIX read()
and if the OS does not return from a read when the device becomes dysfunctional
there
is little that can be done. IIRC in that respect OS X did not behave as it
should.
br Kusti
From: ant elder <ant.elder@xxxxxxxxx<mailto:ant.elder@xxxxxxxxx>>
Reply-To: "purejavacomm@xxxxxxxxxxxxx<mailto:purejavacomm@xxxxxxxxxxxxx>"
<purejavacomm@xxxxxxxxxxxxx<mailto:purejavacomm@xxxxxxxxxxxxx>>
Date: Thu, 21 Nov 2013 12:32:06 +0200
To: "purejavacomm@xxxxxxxxxxxxx<mailto:purejavacomm@xxxxxxxxxxxxx>"
<purejavacomm@xxxxxxxxxxxxx<mailto:purejavacomm@xxxxxxxxxxxxx>>
Subject: [purejavacomm] Detect usb cable unplugged?
Is there any way to have an application notified by PureJavaComm when a usb
serial port is unplugged?
Presently unplugging the cable without first closing the PureJavaComm
SerialPort can cause a hang if a read is done on the still open port. It would
be nice if the application could be notified when the cable is unplugged and so
close the SerialPort, or at least if a read on a SerialPort thats been
unplugged would throw an exception.
...ant
________________________________
This e-mail may contain confidential or privileged information. If you are not
the intended recipient (or have received this e-mail in error) please notify
the sender immediately and destroy this e-mail. Any unauthorized copying,
disclosure or distribution of the material in this e-mail is strictly
forbidden. We will not be liable for direct, indirect, special or consequential
damages arising from alteration of the contents of this message by a third
party or as a result of any virus being passed on or as of transmission of this
e-mail in general.
Other related posts:
