JNA Passing Structure By Reference Help

Question

Hi all, I'm trying to use JNA to talk over a USB device plugged into the computer. Using Java and a .dll that was provided to me. I am having trouble with the Write function:

C code:

typedef struct {
    unsigned int id;
    unsigned int timestamp;
    unsigned char flags;
    unsigned char len;
    unsigned char data[16];
} CANMsg;

CAN_STATUS canplus_Write(
        CANHANDLE handle, //long
     CANMsg *msg
    );

Java Equivalent:

public class CANMsg extends Structure{
    public int id = 0;
    public int timestamp = 0;
    public byte flags = 0;
    public byte len = 8;
    public byte data[] = new byte[16];
}

int canplus_Write(NativeLong handle, CANMsg msg);

I have confirmed that I can open and close the device. The close requires the NativeLong handle, so i am assuming that the CANMsg msg is the issue here. I have also confirmed that the device works when tested with C only code.

I have read the the JNA documentation thoroughly... I think. Any pointers. Thanks all.

Answer 1

I don't know much about JNA but inter-language data transfer usually fails when pointers get transfered as a simple address.

If it's the data it points to that you want to send accross, there's presumably a packaging method call in there somewhere. If you didn't write it yourself, maybe it is generated by this JNA framework... Could be useful to add it to your question.

Mapping C char to Java byte is also a bit weird to me but I can see where that could come from. What operating system are you running this code on?

Answer 2

Is len the size of the structure? If yes; then the value you have given is wrong. Do this:

CANMsg msg = new CANMsg();
msg.len = msg.size();

Answer 3

Hi,

I too am having a problem with the canplus_write interface. So far everything is pointing towards a bug in the provided driver - I don't think the new USBCANPlus module has gone through a proper testing phase yet. From your code I can see that you are using an older version of the driver to begin with, as the data field should consist of 8 bytes (that's the maximum number of data bytes in a CAN message). What I have found through my own investigations is that the driver fails to properly convert the data into ASCII characters i.e. if you want to send 01 02 03, it will transmit the ASCII characters '1' '2' '3' to the module instead of '0' '1' '0' '2' '0' '3' - you can use USB monitoring software to verify this. I am in contact with the FTDI technical support at the moment and am hoping they will release an updated version of the driver soon.

Hope this solves your problem too, I would recommend getting in touch with them as well.

Answer 4

I don't know anything about the dll you are using but the CANMsg.len is more than likely referring to how many bytes are actually in the byte[] data. So you would either need to keep track of how much you write to the byte[16] data array or calculate the len based on the terminating null char (assuming String ASCII is the data). I don't think the CANMsg.size() exists or is implemented like Rusty above suggests.