You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As with the instanced flow control get/set methods (#203), there's a ton of repetition throughout the RXTXPort.nativeStaticSet*() and RXTXPort.nativeStaticGet*() methods. The very existence of these methods is a little stickier than the instance methods, though. When Linux opens a serial port, the drivers automatically assert the DTR/RTS lines. At some point in history, someone must've wanted a finer degree of control over when those lines went high. Maybe the connected equipment started doing something when these lines went up and a developer wanted a finer degree of control over it, or maybe they were trying to synchronize several ports, I don't know. Anyway, all of those methods check if a descriptor for the port has already been opened, and if one hasn't, they open it, then immediately twiddle the relevant bit. I guess the idea was that if the control line goes high for only a very short period of time then immediately goes low again, the connected device might not catch it.
I think there's useful deduplication which can be done here, in the same vein as #203. Calling a shared function to open the port is not going to have a discernible amount of overhead (and could be inlined if it did – which it doesn't). Same for having another shared function for setting/getting the relevant control bit. Could probably use the same control bit setters/getters as in #203, even.
Beyond that, I'd also like to see how much overhead there is from the JVM, really. I'd like to get a slowish machine (Raspberry Pi, old PIII, whatever) and an oscilloscope and compare how long the DTR/RTS lines stay up for when the port is controlled entirely through C versus opening the port from Java then calling setDTR(false)/setRTS(false). I suspect the difference is minimal.
The text was updated successfully, but these errors were encountered:
control of the DTR/RTS lines is how Arduino kicks the fw into bootloader mode. It may be worth trying to preserve the behavior since that can make arduino devices reset if it is accessed wrong.
Ah, good to have a concrete test case. Definitely don't want to break the behaviour; just wonder if it can be implemented a little more easily. And I'd like to documentation and proof one way or the other.
As with the instanced flow control get/set methods (#203), there's a ton of repetition throughout the
RXTXPort.nativeStaticSet*()
andRXTXPort.nativeStaticGet*()
methods. The very existence of these methods is a little stickier than the instance methods, though. When Linux opens a serial port, the drivers automatically assert the DTR/RTS lines. At some point in history, someone must've wanted a finer degree of control over when those lines went high. Maybe the connected equipment started doing something when these lines went up and a developer wanted a finer degree of control over it, or maybe they were trying to synchronize several ports, I don't know. Anyway, all of those methods check if a descriptor for the port has already been opened, and if one hasn't, they open it, then immediately twiddle the relevant bit. I guess the idea was that if the control line goes high for only a very short period of time then immediately goes low again, the connected device might not catch it.I think there's useful deduplication which can be done here, in the same vein as #203. Calling a shared function to open the port is not going to have a discernible amount of overhead (and could be inlined if it did – which it doesn't). Same for having another shared function for setting/getting the relevant control bit. Could probably use the same control bit setters/getters as in #203, even.
Beyond that, I'd also like to see how much overhead there is from the JVM, really. I'd like to get a slowish machine (Raspberry Pi, old PIII, whatever) and an oscilloscope and compare how long the DTR/RTS lines stay up for when the port is controlled entirely through C versus opening the port from Java then calling
setDTR(false)
/setRTS(false)
. I suspect the difference is minimal.The text was updated successfully, but these errors were encountered: