Fazecast / jSerialComm

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

Exceed Buffer Size #367

Closed abodin closed 2 years ago

abodin commented 3 years ago

I try to open a serial port connection with a Quectel Modem according to read modem logs which consist of several HDLC frames.

SerialPort port = SerialPort.getCommPort("port_diag1");
port.setComPortTimeouts(SerialPort.TIMEOUT_READ_SEMI_BLOCKING, 0, 0);

if (!port.openPort()) 
    return null;

port.addDataListener(new SerialPortDataListener() {
  @Override
  public int getListeningEvents() {
      return SerialPort.LISTENING_EVENT_DATA_RECEIVED;
  }

  @Override
  public void serialEvent(SerialPortEvent event) {
      if (event.getEventType() != SerialPort.LISTENING_EVENT_DATA_RECEIVED)
          return;

      readFromDiagPort(event);
  }
});

private void readFromDiagPort(SerialPortEvent event) {
    try {
        byte[] newData = event.getReceivedData();
        System.out.println(event.getSerialPort().bytesAvailable());
        System.out.println(newData.length);

    } catch (Exception e) {
        e.printStackTrace();
    }
}

But when the received data size exceed 4096 (or sometimes below than 4096), event.getReceivedData() truncates my data and does not deliver all bytes. I find this problem by checking CRC of the received packet.

Point: I use JSerialComm version 2.7.0. Point: When this problem occurred, event.getSerialPort().bytesAvailable() is not equal to zero. But when all thing is Ok, this parameter equal to zero.

hedgecrw commented 3 years ago

So there are two issues here:

1) The received data appears to be capped at 4096 bytes, even if more data is available on the serial port. This is actually not a bug and is expected. The serial port driver installed on your OS (nothing to do with jSerialComm) only buffers a certain amount of data before passing it up to be handled by a serial port read from an application or library like jSerialComm. Based on your testing, it seems that that buffer size if 4096 bytes. So nothing is being truncated, you are just receiving data in separate reads which is normal. It is up to your application code to check if you have received a full "packet", whatever that means for your particular application. 2) What could actually be a bug here is if you are not receiving an additional serialEvent() callback with the remainder of your data after the first callback is triggered. Example, if you are expecting to receive 5000 bytes of data and the serial driver is capped at 4096 bytes, I would expect serialEvent() to be called once with 4096 bytes (or less) of data, and then immediately again with the remaining 994 bytes (or more) of data. If this is not occurring, there is a problem.

Would you be able to test the second question above using the following library version:

https://drive.google.com/file/d/17nqSfZDaLu7EJQhe25NXLTepWKG8dFfz/view?usp=sharing

Thanks so much!

hedgecrw commented 2 years ago

Any update on this issue? Please test using the newly released version 2.8.0. It should ensure that item 2 above is handled correctly.

hedgecrw commented 2 years ago

Closing due to inactivity and should have been fixed with 2.8.X series of updates.