Closed rgacraig closed 4 years ago
Great point! The problem with this is that you can set com port parameters before opening the port which won't result in an error. The only robust solution I can think of is to have setting parameters throw a Java exception if something occurs when opening OR specifying, indicating exactly what the error was. What do you think?
I've implemented a change whereby all set*()
functions now return a boolean value indicating whether the setting was successfully applied. If the port is already open, this boolean value will accurately indicate success or failure. If the port was unopened, it will always result in true, but the call to openPort()
will now return false if the settings are incorrect. Do you have a concrete way to test these changes that you know should fail?
If so, please go ahead and test the following library version: https://www.dropbox.com/s/qiotswg6os3bv61/jSerialComm-2.6.1.jar?dl=0
Thanks!
I would say that you shouldn't be able to set the com port parameters on an unopened port, but there may be reasons why you want that to happen. The rxtxSerial code throws an exception for error conditions during parameter setting, so that's also a valid way to do it. I'm just as happy with the boolean result. The most common error I've seen is setting a baud rate that's unsupported, so trying to set a baud rate of 1 Mbaud (supported by many RS-422/485 chips) on most RS-232 interfaces should cause an error. I've also seen a case where doing the SetupComm in Windows with too large an Rx buffer failed. I'll try out this new version and let you know what I see. Thanks very much for taking this on and making it freely available! I've been looking for a ummm... less painful... code base than rxtx for quite some time and this looks like a much cleaner implementation.
Yeah, unfortunately I definitely can't remove the option of setting com port parameters on an unopened port due primarily to some devices that misbehave or become unstable if some lines are not set properly prior to/in conjunction with opening the port. And due to the way this whole library is written, there's no way to actually detect a configuration error without attempting to open the port and/or configure an already opened port. RxTx must have implemented their configuration methods quite differently than I did, which isn't surprising since, as you pointed out, I was opting for a cleaner/simpler implementation at the expense of some nitty-gritty configurability.
In any case, I do see the value in being able to detect a configuration error, so I will add the changes I made to the test library above into the main code and also update the documentation so that it is clear that the return values are only meaningful if the port is already opened. Thanks again for raising the issue...it was a great suggestion.
Closing...this was implemented in the most recent release v2.6.1 and updated in the documentation.
For Windows, I was wondering how to detect if setting a particular configuration has failed? The setComParameters doesn't return a boolean so there's no way of telling if there was a problem with one of the parameters (for example, too high a baud rate). The return result for the SetupComm function should also be checked in the configPort (for windows). I've actually seen a virtual com port which will fail if the receive buffer is too large.
Also, any plans for providing some sort of event for data error conditions (framing error, buffer overrun, break Rx)?