ISerialComEventListener and CTS change #43
Comments
|
I did a wrong evaluation of the event data. Sorry for the noise. |
|
Hello Rishi, When using it throws this exception: However it does not throw an exception if Then I changed |
|
Isn't it when flow control is enabled the operating system itself takes
care of toggling RTC/CTS lines. This question is just for brainstorming.
…On Tue, Dec 1, 2020 at 7:46 PM Andreas Kuhtz ***@***.***> wrote:
Hello Rishi,
I reopen this issue after testing with Test15 under Windows 10 64-bit.
It does not work as expected.
When using FLOWCONTROL.RTS_CTS and calling
scm.setRTS(handle1, false);
it throws this exception:
com.serialpundit.core.SerialComException: The parameter is incorrect.
at com.serialpundit.serial.internal.SerialComPortJNIBridge.setRTS(Native Method)
at com.serialpundit.serial.SerialComManager.setRTS(SerialComManager.java:1505)
However it does not throw an exception if FLOWCONTROL.NONE is used.
Then I changed Test15to get the line status after toggle DTR and RTS
(after sleep 1000). The output shows that a change of DTR from true to
false triggers the EventLooper thread, but a change from false to true
does not trigger the EventLooper thread.
14:59:54.997 [INFO] org.bidib.jbidibc.scm.Test15 [main] - [Initial] Fetched current line status, CTS: 1, DSR: 0, DCD: 0
14:59:54.997 [INFO] org.bidib.jbidibc.scm.EventListener [SerialPundit EventLooper for handle 1612 and port COM10] - eventCTS : 1
14:59:55.003 [INFO] org.bidib.jbidibc.scm.EventListener [SerialPundit EventLooper for handle 1612 and port COM10] - eventDSR : 0
14:59:57.005 [INFO] org.bidib.jbidibc.scm.Test15 [main] - [RTS: false] Fetched current line status, CTS: 0, DSR: 0, DCD: 0
14:59:58.005 [INFO] org.bidib.jbidibc.scm.Test15 [main] - [DTR: false] Fetched current line status, CTS: 0, DSR: 0, DCD: 0
14:59:58.005 [INFO] org.bidib.jbidibc.scm.Test15 [main] - Loop: 20
14:59:58.006 [INFO] org.bidib.jbidibc.scm.EventListener [SerialPundit EventLooper for handle 1612 and port COM10] - eventCTS : 0
14:59:58.006 [INFO] org.bidib.jbidibc.scm.EventListener [SerialPundit EventLooper for handle 1612 and port COM10] - eventDSR : 0
14:59:59.007 [INFO] org.bidib.jbidibc.scm.Test15 [main] - [RTS: true] Fetched current line status, CTS: 1, DSR: 0, DCD: 0
15:00:00.008 [INFO] org.bidib.jbidibc.scm.Test15 [main] - [DTR: true] Fetched current line status, CTS: 1, DSR: 0, DCD: 0
15:00:01.008 [INFO] org.bidib.jbidibc.scm.Test15 [main] - [RTS: false] Fetched current line status, CTS: 0, DSR: 0, DCD: 0
15:00:02.008 [INFO] org.bidib.jbidibc.scm.Test15 [main] - [DTR: false] Fetched current line status, CTS: 0, DSR: 0, DCD: 0
15:00:02.008 [INFO] org.bidib.jbidibc.scm.Test15 [main] - Loop: 19
15:00:02.008 [INFO] org.bidib.jbidibc.scm.EventListener [SerialPundit EventLooper for handle 1612 and port COM10] - eventCTS : 0
15:00:02.008 [INFO] org.bidib.jbidibc.scm.EventListener [SerialPundit EventLooper for handle 1612 and port COM10] - eventDSR : 0
15:00:03.009 [INFO] org.bidib.jbidibc.scm.Test15 [main] - [RTS: true] Fetched current line status, CTS: 1, DSR: 0, DCD: 0
15:00:04.009 [INFO] org.bidib.jbidibc.scm.Test15 [main] - [DTR: true] Fetched current line status, CTS: 1, DSR: 0, DCD: 0
15:00:05.010 [INFO] org.bidib.jbidibc.scm.Test15 [main] - [RTS: false] Fetched current line status, CTS: 0, DSR: 0, DCD: 0
15:00:06.010 [INFO] org.bidib.jbidibc.scm.Test15 [main] - [DTR: false] Fetched current line status, CTS: 0, DSR: 0, DCD: 0
15:00:06.010 [INFO] org.bidib.jbidibc.scm.Test15 [main] - Loop: 18
15:00:06.010 [INFO] org.bidib.jbidibc.scm.EventListener [SerialPundit EventLooper for handle 1612 and port COM10] - eventCTS : 0
15:00:06.010 [INFO] org.bidib.jbidibc.scm.EventListener [SerialPundit EventLooper for handle 1612 and port COM10] - eventDSR : 0
15:00:07.010 [INFO] org.bidib.jbidibc.scm.Test15 [main] - [RTS: true] Fetched current line status, CTS: 1, DSR: 0, DCD: 0
15:00:08.011 [INFO] org.bidib.jbidibc.scm.Test15 [main] - [DTR: true] Fetched current line status, CTS: 1, DSR: 0, DCD: 0
15:00:09.011 [INFO] org.bidib.jbidibc.scm.Test15 [main] - [RTS: false] Fetched current line status, CTS: 0, DSR: 0, DCD: 0
15:00:10.012 [INFO] org.bidib.jbidibc.scm.Test15 [main] - [DTR: false] Fetched current line status, CTS: 0, DSR: 0, DCD: 0
15:00:10.012 [INFO] org.bidib.jbidibc.scm.Test15 [main] - Loop: 17
15:00:10.012 [INFO] org.bidib.jbidibc.scm.EventListener [SerialPundit EventLooper for handle 1612 and port COM10] - eventCTS : 0
15:00:10.013 [INFO] org.bidib.jbidibc.scm.EventListener [SerialPundit EventLooper for handle 1612 and port COM10] - eventDSR : 0
15:00:11.012 [INFO] org.bidib.jbidibc.scm.Test15 [main] - [RTS: true] Fetched current line status, CTS: 1, DSR: 0, DCD: 0
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#43 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACJVFLE7KVMC2RF3B5XDORTSST3CDANCNFSM4UGXZC5A>
.
|
|
Ok, now I understand: The I changed to |
|
I checked the native code. We don't maintain/depend on line state.
The SP library native code simply registers with the operating system for
serial port event.
Whenever there is any event received form OS, SP native code will route it
to Java layers all the way to Java app.
Out of curiosity, why do we think that both 0->1 and 1->0 should be seen
as an event. By default line will be at say logic 0, then to signal event
it will go to 1 and then come backs to 0. So only 0->1 should be tread as
event. Am I missing something in my understanding?
…On Thu, Dec 3, 2020 at 2:35 PM Andreas Kuhtz ***@***.***> wrote:
Ok, now I understand: The FLOWCONTROL.RTS_CTS sets the fRtsControl to
RTS_CONTROL_HANDSHAKE while FLOWCONTROL.NONE allows to use setRTS(...)
manually.
I changed to FLOWCONTROL.NONE but the change of the status of the CTS
line is still only signalled as event if CTS value changed from 0 to 1.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#43 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACJVFLBYT6IROLWUR3YEKWLSS5IFHANCNFSM4UGXZC5A>
.
|
|
From my understanding every change of the line status should result in an event. There are some devices that change the line status to signal the application that no more data must be sent because e.g. the input buffer is full. After some time when the device has processed the input buffer is changes the line status to signal that more data can be sent. I tested with hterm (http://www.der-hammer.info/pages/terminal.html) and a FTDI board (YP-05) where I connected the Then I tested with RXTX (https://github.com/NeuronRobotics/nrjavaserial) and it signals the change of line status, too, if I plug off the jumper cable from the RTS pin and put it back again. I still have to test it with a simple C++ application. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello Rishi,
The ISerialComEventListener is only called once if linestatus CTS changes from 1 to 0 but not if line status changes from 0 to 1.
I'm testing on Windows 10 64-bit and I use FLOWCONTROL.RTS_CTS.
The text was updated successfully, but these errors were encountered: