Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Usefulness assessment of the nativeStaticSet/nativeStaticGet methods #204

Open
MrDOS opened this issue Jan 21, 2021 · 2 comments
Open

Usefulness assessment of the nativeStaticSet/nativeStaticGet methods #204

MrDOS opened this issue Jan 21, 2021 · 2 comments

Comments

@MrDOS
Copy link
Contributor

MrDOS commented Jan 21, 2021

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
Copy link
Member

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
Copy link
Contributor Author

MrDOS commented Jan 22, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants