Fazecast / jSerialComm

Platform-independent serial port access for Java
GNU Lesser General Public License v3.0
1.35k stars 287 forks source link

Read timeouts doesn't work on Armbian #189

Closed X0rrify closed 5 years ago

X0rrify commented 5 years ago

Non blocking read timeout doesn't work on Armbian Linux. Tested on Armbian 5.60, 5.69, 5.75. Tested exactly as shown in the usage example.

setComPortTimeouts(SerialPort.TIMEOUT_NONBLOCKING, 0, 0); setComPortTimeouts(SerialPort.TIMEOUT_NONBLOCKING, 10, 0); setComPortTimeouts(SerialPort.TIMEOUT_NONBLOCKING, 3000, 0);

hedgecrw commented 5 years ago

1) What is your expected behavior using non-blocking mode, and 2) what is your code doing that goes against that behavior? There's no such thing as a non-blocking read timeout. There are either read timeouts or there is non-blocking mode, and by definition, they are mutually exclusive, so I need more information to help with this issue.

X0rrify commented 5 years ago

Hi and thanks! I just expect a nice way to continue the flow and i was confused.

At the moment I'm implementing and using my own timer this way:

        startResponseTimer();
        System.out.println("Response timer started");

        while ((sensorSerialPort.bytesAvailable() == 0) && !isTimeout) {
            Thread.sleep(UART_TRANSFER_DELAY);
        }

        timer.cancel();
        System.out.println("Response timer stopped");

After that i check if the available bytes are > 0 and if so the execution continues. UART_TRANSFER_DELAY is 30ms.

Yesterday reading a fixed length buffer worked that way: byte[] inputBuffer = new byte[REGULAR_PACKET_LENGTH]; fingerprintSensorSerialPort.readBytes(inputBuffer, REGULAR_PACKET_LENGTH);

Today I'm trying to read 2 packets one after another, the length of the first one is 24 and the second one is 508. Unfortunately all data comes on the first shot. I decided to read and concatenate all in a 2 loops and then analyze and cut the data. Any ideas are welcome.

Thank you!

On Thu, 21 Feb 2019 at 17:34, Will Hedgecock notifications@github.com wrote:

  1. What is your expected behavior using non-blocking mode, and 2) what is your code doing that goes against that behavior? There's no such thing as a non-blocking read timeout. There are either read timeouts or there is non-blocking mode, and by definition, they are mutually exclusive, so I need more information to help with this issue.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Fazecast/jSerialComm/issues/189#issuecomment-466044626, or mute the thread https://github.com/notifications/unsubscribe-auth/AF2FbeQNhEGQ0ndx3AsIMsPDnqKGCBL0ks5vPrxtgaJpZM4bFRtP .

-- Ted

hedgecrw commented 5 years ago

If you know that you are going to receive 2 packets in a row of length 24 followed by 508, then I would use blocking mode (TIMEOUT_MODE_READ_BLOCKING), and simply read the full packet lengths one after another:

setComPortTimeouts(SerialPort.TIMEOUT_READ_BLOCKING, 0, 0); byte[] packet1 = new byte[24], packet2 = new byte[508]; fingerprintSensorSerialPort.readBytes(packet1, packet1.length); fingerprintSensorSerialPort.readBytes(packet2, packet2.length);

Closing due to not a bug. Please post usage questions on a general coding forum such as StackOverflow, StackExchange, etc.