Library not working on MAC OS (10.7) about hid4java HOT 8 CLOSED

Glad to help where I can. If you build the project locally (mvn clean install) and then add it to your project the native OS X library (.dylib) should get picked up automatically. OS X doesn't need any special configuration to get hid4java to work - it should be a case of attaching the device and seeing it appear. Perhaps start with the example code, modified for you use case, and run in debug mode.

Also, which version of OS X are you using? hid4java has been tested down to Snow Leopard.

from hid4java.

Hello,

thanks for your reply. Actually I was able yesterday to move a small step forward (damn my poor knowledge of Mac OS :) ), but still there is something wrong. So, the problem I had before was that I was trying to execute a .jar I created under Windows, so I think it was created with the .dll library.
I installed Netbeans on the MAC (by the way, it is running OS x 10.10, Yosemite), I compiled your library with my GUI (which is essentially doing the same as your example, just with different VID and PID), and this time I was able to open the device (I tried a toString() on the device, and I got the correct information).

The problem comes now when I try to read some information from the device.

But first I think I should remark another small thing; I had to make a small change on Windows as well. Assume my message is the following
Assume I am doing the same as in your sendInitialise() example: I am sending a specific message to the device using the write() method, and then I should be able to call device.read() and read the relative information.

byte[message] = new byte[64];

message[0] = 0x45; //0x45 is the code for my device to send some settings info which I can read
message[1] = 0x00; //0x00 is needed for my device

When I call device.write(message) as before, windows is raising an "Incorrect Parameter" error, which I was able to fix by sending an 0x00 in first position (think I read the fix somewhere, maybe in an older post here)

message[0] = 0x00
message[1] = 0x45
message[2] = 0x00

By doing this, on windows everything is working fine, even a very long data transfer (reading about 200Kb of data).

On MAC, as I said, I am now able to detect the unit, but when I send a message (I tried both with the initial 0x00, and without), the interface freezes and the only thing which is printed out is

[65] , i.e. the number of transmitted bytes.

Today I will continue with some tests; if you can give me some direction that would be really useful.

Once again, thank you very much.

Lorenzo

from hid4java.

Glad you were able to identify the initial cause of the problem. It's hard for me to diagnose these problems from a distance so the more information you can give me the better (which you're doing).

Interesting that you were getting the infamous "the parameter is incorrect" message on Windows. There is compensation code in place to cover this for report ID 0x00 (I've updated the latest README in the develop branch to explain its operation) so you should be able to use the same data buffer contents across platforms. If that's not working then it'll need attention.

One possibility is your device may be expecting a different packet length.

I find it best to start with a simple console app (as in the example) and then when it's all working to build out a UI. It helps to keep me focused on the problem, and provides a low level debugging environment for the inevitable glitches that occur later.

For some comprehensive examples of my writing commercial code that references hid4java have a look at MultiBit Hardware.

from hid4java.

Well,

apparently there must have been some problem with the specific device I was testing, or maybe I missed something during the previous installation.....

To be 100% sure of not missing anything, I downloaded a clean version of your library on the MAC, I compiled it, I replaced the VID and PID in your running example, I took a brand new device, and this time I was able to get back a reply :)

So for the moment I must say that the library is working perfectly, the only minor change I had to do is to insert an 0x00 to the packet I send on Windows. I read your explanation also in the comments inside the write() method of the library, but apparently the problem is still happening, at least in my case.
When I will have some time I will try to dig deeper on it, and if I find something I will let you know.

Thanks for your support, I will write back to you if something is wrong (or if everything works fine, as well ;) ).

from hid4java.

No worries - I'm glad you've got it working.

I'll be very interested to learn if the 0x00 in data is really necessary on Windows if the report ID is set to 0x00. I've seen situations where adding it caused problems so do report back. It could be that I need to refresh the native libraries with the latest release from signal11/hidapi.

from hid4java.

Hi,

in the previous tests I did I was already using report ID = 0, but in order to be sure that the problem still exists, I did a very trivial test.

The device I am using will reply with some info (software revision, unit ID and so on) when the following basic message is transmitted

byte [] message = new byte [64];

message[0] = SEND_INFO;
message[1.....63] = 0x00;

myDevice.write(message, 64, (byte) 0x00)

If I transmit the message as showed before, I got the "Incorrect Parameter" error, which is blocking my program.

If I modify the message before simply by writing

message[0] = 0x00;
message[1] = SEND_INFO;
.......

The command is working perfectly. The same happens for all the other commands I am sending to my unit.

If you are interested, I found the hint to fix the problem here https://code.google.com/p/javahidapi/issues/detail?id=53

(I read in the comment "not working even when setting 0x0....so I tried it and it worked for me :) )

Hope this can help and in any case feel free to ask if I can help you further to correct the problem :)

from hid4java.

There was a bug (#20 fixed in 0.4.0) which lead to an incorrectly formed packet which might have been adding to this situation.

Are you still seeing this in 0.4.0 releases?

from hid4java.

Closing, pending further info.

from hid4java.