Closed melyux closed 2 years ago
Please test the following library version and see if it resolves your issue:
https://drive.google.com/file/d/17nqSfZDaLu7EJQhe25NXLTepWKG8dFfz/view?usp=sharing
This is expected behavior. Each OS (and each individual device driver) will have a maximum buffer size for transmitting bytes to the device. This is actually the main reason that the writeBytes()
function returns an indication of how many bytes were actually written...so that the user application can call the function again if needed. In this case, your application will need to keep track of what was written and send the remaining data if all bytes were not written.
I can't speak to how RXTX implements this functionality, but I based on your testing results, I assume they retry to send the remaining bytes inside of the library itself as opposed to leaving this task to the application level. In that case, the total number of bytes written may be as expected but the timing/timeouts may be violated, so we have opted to just return the number of bytes written from the OS verbatim.
As such, this will be closed as "will not fix" since it directly mimics the behavior of the same native call on this OS.
I am opening a new issue however about getDeviceWriteBufferSize()
not returning the correct buffer size of the underlying device driver: #380
The exact same code truncates the sent data sent with
writeBytes()
to 1024 bytes on Mac but sends the whole thing on Windows.getDeviceWriteBufferSize()
returns 4096, but doesn't seem to make a difference.e.g.
writeBytes(buffer, 1028)
returns 1024 and port sniffing reveals that it indeed only sends 1024 bytes, on Intel Macs. On Windows, the same Java code returns 1028 and indeed sends all 1028 bytes.Tried the RXTX library for Mac, and it sends >1024 bytes no problem. Seems to be a problem with jSerialComm.