search

NeuronRobotics / nrjavaserial

A Java Serial Port system. This is a fork of the RXTX project that uses in jar loading of the native code.
Other
344 stars 142 forks source link

Usefulness assessment of the nativeStaticSet/nativeStaticGet methods #204

Open MrDOS opened 3 years ago

MrDOS commented 3 years ago

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.

madhephaestus commented 3 years ago

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.

MrDOS commented 3 years ago

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.