General Linux and Windows Library Usage

[Allen Myers]

Bob, Your suggestion of looking closer at the blocking configuration was
spot on and helped me to resolve my problem. Thank you.

I wish jSerialComm would have propagated up the errno appropriately.
Instead it swallows it and just returns a generic -1 and then throws a
generic "port was closed" message in the Java library without any
furthering information:
https://github.com/Fazecast/jSerialComm/blob/master/src/main/c/Linux/SerialPort_Linux.c#L460-L470

I'm not sure why Windows didn't cause me a problem in non-blocking mode,
but Linux apparently needs to be told it is okay to block with my
implementation.

I'm still wanting to use Device I/O after all this, so I may see if I can
migrate to at least a virtual Linux machine to do remote debugging on for
my test environment.

Again, thank you so much!

On Tue, Mar 6, 2018 at 1:47 PM, Bob Vandette <bob.vandette at oracle.com>
wrote:

>
> On Mar 6, 2018, at 3:22 PM, Allen Myers <allen at aemyers.com> wrote:
>
> Bob, ​Thank you for your input​!
>
> I'm actually attempting to use jSerialComm right now. However I seem to
> have some problems with how it manages threads. jSerialComm starts a
> separate thread to manage a listener for the native libraries it uses. But
> it doesn't seem to handle thread interruptions properly.
>
> https://github.com/Fazecast/jSerialComm/blob/master/src/
> main/java/com/fazecast/jSerialComm/SerialPort.java#L1048
>
> It also seems to have random Thread.sleep calls periodically in it's code
> base that I'm not sure underline a solid understanding of how to
> communicate with native libraries properly.
>
> Perhaps I'm still doing something wrong in my code, but I don't seem to be
> able to close a jSerialComm connection and then reopen it right after
> without it closing itself again shortly after for no apparent reason. Maybe
> I just need to accept I shouldn't close it. :)
>
>
> As I stated, I have no experience with this library.  Have you tried to
> use their
> examples?  It looks like their default mode of operation is non blocking
> mode.  This is why they require sleeps.  It looks like you can open a
> serial
> port in blocking mode to avoid this issue.
>
> SerialPort comPort = SerialPort.getCommPorts()[0];
> comPort.openPort();
> comPort.setComPortTimeouts(SerialPort.TIMEOUT_READ_BLOCKING, 1000, 0);
>
>
> Or maybe I should change my development/test environment into a Linux
> platform and use Device I/O. :) This Device I/O library looks very well
> designed. I really want to use it, but I'm so entrenched in a Windows test
> environment right now, it's hard to give all that up for one library…
>
>
> Only you can decide if this is worth it.
>
> Bob.
>
>
> On Tue, Mar 6, 2018 at 12:15 PM, Bob Vandette <bob.vandette at oracle.com>
> wrote:
>
> The Device I/O library only supports Linux.  It should work on any Linux
> platform and not be restricted to embedded specific platforms as long as
> you configure it properly.
>
> I used the javax.comm package on Windows years ago but
> this support was EOL’d by Sun many years ago.
>
> I did a quick search and came up with this package that claims to do
> what you are looking for.  I have no experience with this technology and
> this is not an endorsement of jSerialComm by Oracle.  Use at your own risk.
>
> http://fazecast.github.io/jSerialComm/
>
> Bob.
>
>
> On Mar 6, 2018, at 1:18 PM, Allen Myers <allen at aemyers.com> wrote:
>
> I've been trying to find a reliable serial library to act as an interface
> to a USB connection to a UART on an Arduino. This Device I/O library looks
> brilliant. I'm just not sure if I can use it on a full Linux server (Dell
> server). Is this only designed to be run on embedded type platforms? Could
> it interface with a /dev/tty device on a standard Linux server?
>
> My production environment is Linux, but my test environment is Windows. If
> possible, how would I go about getting natives built for Windows?
>
>
>
>
>