nyholku / purejavacomm

Pure Java implementation of JavaComm SerialPort
http://www.sparetimelabs.com/purejavacomm/index.html
BSD 3-Clause "New" or "Revised" License
367 stars 146 forks source link

Likely a compatible issue with OS X El Capitan and Ubuntu 14.04 Desktop #78

Closed AnakinFoxe closed 8 years ago

AnakinFoxe commented 8 years ago

Hi, I'm not very familiar with PureJavaComm (PJC) and not 100% sure it is a PJC issue, but according to my experiment it is very likely to be one. So I will describe as detail as possible for you guys to check if it is an existing issue.

The problem I encountered was with IOIO-OTG board (https://github.com/ytai/ioio/wiki). Basically a IOIO program contains IOIO libs which utilize JNA and PJC to connect the board. My "HelloWorld" program works perfectly on Windows 8.1 and Arch Linux, but won't be able to establish connection with the board on OS X El Capitan and Ubuntu 14.04, even though the operating system could recognize the board.

Various JDK versions have been tested; JNA version from 4.00 to 4.21 and PJC version from 0.22 to the latest 0.29 have been tested; all have the same result.

Let me know if you need more information or further tests. Thank you!

nyholku commented 8 years ago

So what happens?

If you do ls /dev from terminal, do you see your ioio device there?

How do you open the port?

What exceptions do you get?

Have you tried turning on the logging?

https://github.com/nyholku/purejavacomm/wiki/Trouble-shooting

AnakinFoxe commented 8 years ago

Yes, the IOIO device will show as /dev/tty.usbmodemxxxx on OS X.

I just tried turning on logging:

log: 271448,instantiating jtermios.macosx.JTermiosImpl log: 271450,> open('/dev/tty.usbmodem1421',00020006) log: 271458,< open('/dev/tty.usbmodem1421',00020006) => 23 log: 271459,> tcgetattr(23,jtermios.Termios@a1323da0) log: 271463,< tcgetattr(23,jtermios.Termios@ea4810a3) => 0 log: 271463,> close(23) log: 271465,< close(23) => 0 log: 271468,> open('/dev/tty.usbmodem1421',00020006) log: 271471,< open('/dev/tty.usbmodem1421',00020006) => 23 log: 271472,> fcntl(23, 3, 0) log: 271472,< fcntl(23, 3, 0) => 6 log: 271472,> fcntl(23, 4, 2) log: 271474,< fcntl(23, 4, 2) => 0 log: 271475,> tcgetattr(23,jtermios.Termios@a1323da0) log: 271476,< tcgetattr(23,jtermios.Termios@ea4810a3) => 0 log: 271476,> cfmakeraw(23,jtermios.Termios@ea4810a3) log: 271477,< cfmakeraw(23,jtermios.Termios@ea562824) log: 271477,> tcsetattr(23,0,jtermios.Termios@625c3705) log: 271479,< tcsetattr(23,0,jtermios.Termios@625c3705) => 0 log: 271479,> setspeed(23,jtermios.Termios@625c3705,9600) log: 271482,< setspeed(23,jtermios.Termios@625c3705,9600) => 0 log: 271482,> tcsetattr(23,0,jtermios.Termios@625c3705) log: 271484,< tcsetattr(23,0,jtermios.Termios@625c3705) => 0 log: 271484,> tcsetattr(23,0,jtermios.Termios@d87f3705) log: 271486,< tcsetattr(23,0,jtermios.Termios@d87f3705) => 0 log: 271486,> ioctl(23,1074033770,[00000000]) log: 271487,< ioctl(23,1074033770,[00000006]) => 0 log: 271487,> pipe([2,0,0]) log: 271489,< pipe([2,24,25]) => 0 log: 271490,> fcntl(24, 3, 0) log: 271490,< fcntl(24, 3, 0) => 0 log: 271490,> fcntl(24, 4, 4) log: 271490,< fcntl(24, 4, 4) => 0 log: 271492,> ioctl(23,1074033770,[00000006]) log: 271492,< ioctl(23,1074033770,[00000006]) => 0 log: 271492,> ioctl(23,-2147191699,[00000006]) log: 271493,< ioctl(23,-2147191699,[00000006]) => 0 log: 271598,> tcsetattr(23,0,jtermios.Termios@b21ed329) log: 271600,< tcsetattr(23,0,jtermios.Termios@b21ed329) => 0 log: 271601,> select(25,[2324],[],[],jtermios.TimeVal@27fa135a) log: 272107,< select(25,[],[],[],jtermios.TimeVal@27fa135a) => 0

And it will endlessly looping the last two lines: log: 271601,> select(25,[2324],[],[],jtermios.TimeVal@27fa135a) log: 272107,< select(25,[],[],[],jtermios.TimeVal@27fa135a) => 0

nyholku commented 8 years ago

So basically everything is working, it is just that the operating system select() call does not report any data coming in.

Maybe the device is not sending anything. I don't know the protocol so hard to guess, perhaps you first need to send something to the device. Maybe the sending part is not working. If the protocol is known (likely described somewhere) you might try to test the device with terminal emulator (unix screen for example) to see if the device communicates out of PJC context (if the protocol is binary, the this is not likely to succeed unless you write some C code).

Since PJC is working for many people on Mac (including myself) and (El Capitan) I suggest this may have something to do with the way the the IOIO initialises PJC (or does not initialise). Maybe the defaults have changed in El Capitan.

I suggest the next step is to try this on some pre-El Capitan OS X version to see if the problem can be isolated to El Capitan.

I don't have El Capitan and have no plans to install it for months so I cannot test this.

I do have some early revision IOIO board but have never used it before and don't have it with me here on the road, so at best I could test this sometime in January.

You might try to talk to the IOIO man Ytai Ben-Tsvi himself, I've previously corresponded with him and he seemed cordial and responsive.

Or maybe there is some 'community' around IOIO who could test this for you.

nyholku commented 8 years ago

Actually, which version of PJC you are using? And what was your logging level?

In your log you have:

log: 271486,> ioctl(23,1074033770,[00000000]) log: 271487,< ioctl(23,1074033770,[00000006]) => 0

in the latest version (which you should be using) the logging for ioctl() is broken so above would most likely NOT BE OUTPUT but an exception should occur (which would then cause PJC not to work if the logging is enabled). I've fixed this bug (but forgot to include it in the latest release).

So if your are NOT using the latest version, try that first (with logging NOT enabled). If you want to try the logging with the latest version, ensure that in `JTermios.java' line 445 you have:

    static public int ioctl(int fd, int cmd, int... data) {
        log = log && log(5, "> ioctl(%d,%d,[%s])\n", fd, cmd, Arrays.toString(data));
        int ret = m_Termios.ioctl(fd, cmd, data);
        log = log && log(3, "< ioctl(%d,%d,[%s]) => %d\n", fd, cmd, Arrays.toString(data), ret);
        return ret;
    }
AnakinFoxe commented 8 years ago

Hi Kustaa, with this latest fix, here is new logging:

log: 125058,instantiating jtermios.macosx.JTermiosImpl log: 125061,> open('/dev/tty.usbmodem1421',00020006) log: 125064,< open('/dev/tty.usbmodem1421',00020006) => 59 log: 125065,> tcgetattr(59,jtermios.Termios@a1323da0) log: 125087,< tcgetattr(59,jtermios.Termios@ea4810a3) => 0 log: 125089,> close(59) log: 125093,< close(59) => 0 log: 125120,> open('/dev/tty.usbmodem1421',00020006) log: 125124,< open('/dev/tty.usbmodem1421',00020006) => 62 log: 125124,> fcntl(62, 3, 0) log: 125125,< fcntl(62, 3, 0) => 6 log: 125125,> fcntl(62, 4, 2) log: 125125,< fcntl(62, 4, 2) => 0 log: 125125,> tcgetattr(62,jtermios.Termios@a1323da0) log: 125129,< tcgetattr(62,jtermios.Termios@ea4810a3) => 0 log: 125129,> cfmakeraw(62,jtermios.Termios@ea4810a3) log: 125130,< cfmakeraw(62,jtermios.Termios@ea562824) log: 125130,> tcsetattr(62,0,jtermios.Termios@625c3705) log: 125132,< tcsetattr(62,0,jtermios.Termios@625c3705) => 0 log: 125133,> setspeed(62,jtermios.Termios@625c3705,9600) log: 125136,< setspeed(62,jtermios.Termios@625c3705,9600) => 0 log: 125136,> tcsetattr(62,0,jtermios.Termios@625c3705) log: 125138,< tcsetattr(62,0,jtermios.Termios@625c3705) => 0 log: 125138,> tcsetattr(62,0,jtermios.Termios@d87f3705) log: 125140,< tcsetattr(62,0,jtermios.Termios@d87f3705) => 0 log: 132757,> ioctl(62,1074033770,[[0]]) log: 150278,< ioctl(62,1074033770,[[6]]) => 0 log: 156332,> pipe([2,0,0]) log: 156333,< pipe([2,63,64]) => 0 log: 156334,> fcntl(63, 3, 0) log: 156334,< fcntl(63, 3, 0) => 0 log: 156334,> fcntl(63, 4, 4) log: 156335,< fcntl(63, 4, 4) => 0 log: 161626,> ioctl(62,1074033770,[[6]]) log: 161626,< ioctl(62,1074033770,[[6]]) => 0 log: 161626,> ioctl(62,-2147191699,[[6]]) log: 161627,< ioctl(62,-2147191699,[[6]]) => 0 [V/IOIOImpl] Waiting for handshake log: 168259,> tcsetattr(62,0,jtermios.Termios@b21ed329) log: 168263,< tcsetattr(62,0,jtermios.Termios@b21ed329) => 0 log: 168264,> select(64,[6263],[],[],jtermios.TimeVal@5103c628) log: 168772,< select(64,[],[],[],jtermios.TimeVal@5103c628) => 0

The last two lines will repeat...

AnakinFoxe commented 8 years ago

Sorry I was lazy, the first log I posted was generated by simply using the program ioiodude which depends on PJC ver0.22. Now I have imported all the latest IOIOLib source code and PJC 0.29 source code (from github) with the "hello word" code. The log I just posted should represent the latest result.

ytai commented 8 years ago

Hey guys! I dug into the issue and found the root cause. The IOIO starts a session as soon as the DTR signal is asserted. For some reason, in El Capitan, one needs to set DTR to false first, then to true, in order to achieve this. I will push a fix to the IOIO tools and libraries soon, including upgrading to PJC 0.0.29. Thanks!

ytai commented 8 years ago

BTW, the Ubuntu issue might have to do with the modem manager interfering. The IOIO wiki page about using IOIO with a PC explains how to overcome that. I would like to merge the udev rules into the standard file, if it works for you, I would appreciate a patch.

nyholku commented 8 years ago

@ytai you wrote "I would like to merge the udev rules into the standard file, if it works for you, I would appreciate a patch" ... I don't get the implications for PJC project ... do you need something done?

I've fixed to small logging issues so if you can wait a day or two I will push those and release PJC 0.0.30 ... or maybe this should finally be upgraded to 1.0.0, after all it has been years and seems to work for many.

ytai commented 8 years ago

Sorry, my comment about the udev rule doesn't belong here. Congrats on v1.x. Right on time! The latest IOIO libraries and tools already use that :) Feel free to close this issue. We seem to be good!