Missing Characters on USB port

[danishmhmd]

I am facing issue that sometimes number of characters are not properly received. Using serialPort.readString(serialPort.getInputBufferBytesCount(), 150) Method.(Maven Version 2.8.0) I tried using multiple values of timeout but still either two different messages are received in correctly. For ex:
Expected Data:
[011131FF8300000F0000000000420001000000e9]
[001131FF8300000F000000000042000200000097]

Actual Received Data:
[011131FF8300000F0000
000000420001000000e9]
[001131FF8300000F000000000042000200000097]

Or

[011131FF8300000F0000000000420001000000e9]
[001131FF8300000F000000000
042000200000097]

[tresf]

I'm not familiar with what could cause this, but I wanted to reply to acknowledge the bug report so you know that the project is still active.

[tresf]

@danishmhmd I've looked over this bug report and I believe the library is working to the best of it's ability. I will elaborate:

Missing Characters on USB port [...] I am facing issue that sometimes number of characters are not properly received.

If I'm reading your problem description properly, the expected and actual results do not appear to be missing characters, but rather appear in two separate chunks. Can you please confirm? I am basing this observation off of the fact that your expected and actual results are identical.

The way that readString works is it calls readBytes, which is basically just one of two native calls depending if you're on Windows or on *nix:

jssc/src/main/cpp/windows/jssc.cpp

Line 274 in 4fcddd8

JNIEXPORT jbyteArray JNICALL Java_jssc_SerialNativeInterface_readBytes

jssc/src/main/cpp/_nix_based/jssc.cpp

Line 656 in 4fcddd8

JNIEXPORT jbyteArray JNICALL Java_jssc_SerialNativeInterface_readBytes

In the case of Windows, I believe it attempts to strictly send bytes back that are the size requested, but I'm not sure if this is 100% reliable. @hiddenalpha may be able to shed more light on this.

In the case of *nix, I believe it will send back only what could be read.

The reason I'm skeptical that this is an actual bug is because since I started using JSSC, I've always had to use byte delimiters (or length) in my application to detect when a stream was finished (I've never relied blindly on the result of readBytes) so I suspect this is a problem that all implementers have to work around.

Two years later I'm sure that you (@danishmhmd) have either chose a different library or coded these workarounds yourself, so I'm curious as to your thoughts, but at initial glance, I do not believe this to be a bug with the library, at least not one that we can easily and reasonably solve.

A response is required or this bug report will be closed.