JNA Speicherbelegung der Datentypen

[Der_AltMann]

Ich habe das Problem, dass die Speicherbelegung nicht stimmt. Das schließe ich daraus, dass die Bits zwischen den Attributen verschoben sind.

das ist der native code:

typedef struct s_xl_channel_config {
          char                name [32];
          unsigned char       hwType;                               
          unsigned char       hwIndex;                             
          unsigned char       hwChannel;                           
          unsigned short      transceiverType;                     
          unsigned short      transceiverState;                   
          unsigned short      configError;                         
          unsigned char       channelIndex;                       
          long                channelMask;                         
          unsigned int        channelCapabilities;                 
          unsigned int        channelBusCapabilities;                       
          unsigned char       isOnBus;                             
          unsigned int        connectedBusType;                   
          XLbusParams         busParams;
          unsigned int        _doNotUse;                                                                         
          unsigned int        driverVersion;           
          unsigned int        interfaceVersion;                   
          unsigned int        raw_data[10];                   
          unsigned int        serialNumber;
          unsigned int        articleNumber;
          char                transceiverName [32]; 
          unsigned int        specialCabFlags;                     
          unsigned int        dominantTimeout;                     
          unsigned char       dominantRecessiveDelay;             
          unsigned char       recessiveDominantDelay;             
          unsigned char       connectionInfo;                     
          unsigned char       currentlyAvailableTimestamps;         
          unsigned short      minimalSupplyVoltage;                 
          unsigned short      maximalSupplyVoltage;                 
          unsigned int        maximalBaudrate;                     
          unsigned char       fpgaCoreCapabilities;               
          unsigned char       specialDeviceStatus;                 
          unsigned short      channelBusActiveCapabilities;       
          unsigned short      breakOffset;                         
          unsigned short      delimiterOffset;                     
          unsigned int        reserved[3];
        } XL_CHANNEL_CONFIG;

mein Java Code dazu sieht so aus:

@FieldOrder ({"name", "hwType", "hwIndex", "hwChannel", "transceiverType", "transceiverState", "configError", "channelIndex", "channelMask", "channelCapabilities", "channelBusCapabilities", "isOnBus", "connectedBusType", "busParams",    "_doNotUse", "driverVersion", "interfaceVersion", "raw_data", "serialNumber", "articleNumber", "transceiverName", "specialCabFlags", "dominantTimeout", "dominantRecessiveDelay", "recessiveDominantDelay", "connectionInfo", "currentlyAvailableTimestamps", "minimalSupplyVoltage", "maximalSupplyVoltage", "maximalBaudrate", "fpgaCoreCapabilities", "specialDeviceStatus", "channelBusActiveCapabilities", "breakOffset", "delimiterOffset", "reserved"})
public class XLchannelConfig extends Structure{

    public byte[] name = new byte[32];
    public byte hwType;
    public byte hwIndex;
    public byte hwChannel;
    public short transceiverType;
    public short transceiverState;
    public short configError;
    public byte channelIndex;
    public long channelMask;
    public int channelCapabilities;
    public int channelBusCapabilities;
    public byte isOnBus;
    public int connectedBusType;
    public XLbusParams busParams= new XLbusParams();
    public int _doNotUse;
    public int driverVersion;
    public int interfaceVersion;
    public int[] raw_data = new int[(10)];
    public int serialNumber;
    public int articleNumber;
    public byte[] transceiverName = new byte[32];
    public int specialCabFlags;
    public int dominantTimeout;
    public byte dominantRecessiveDelay;
    public byte recessiveDominantDelay;
    public byte connectionInfo;
    public byte currentlyAvailableTimestamps;
    public short minimalSupplyVoltage;
    public short maximalSupplyVoltage;
    public int maximalBaudrate;
    public byte fpgaCoreCapabilities;
    public byte specialDeviceStatus;
    public short channelBusActiveCapabilities;
    public short breakOffset;
    public short delimiterOffset;
    public int[] reserved = new int[3];
    
    public XLchannelConfig() {
        super();
        
    }

Die Klasse XLchannelConfig ist in einem Array, dass ich mit .toArray initialisiert habe.
Wenn ich die Attribute ausgebe, sehe ich, dass die Werte verschoben sind. Es sieht so aus als wären die Bits von dem einen Attribut in das nächste verschoben. Ich vermute, dass es an einem falschen Datentyp liegt, komme aber nicht darauf an welchem es liegt

 

[mrBrown]

Wenn ich die Attribute ausgebe, sehe ich, dass die Werte verschoben sind.

Ab welchem Wert sind sie denn verschoben?

 

[mihe7]

Das einzige, was mir hier auffällt: unter https://java-native-access.github.io/jna/4.2.1/overview-summary.html#marshalling wird angegeben, dass ein C long in Java mit einem NativeLong abzubilden wäre.

 

[Der_AltMann]

Es scheint ab dem Wert channelMask nicht mehr zu funktionieren. Ich habe NativeLong ausprobiert, der es auch etwas besser gemacht hat aber leider nicht komplett gelöst hat. channelMask ist genau genommen kein long, sondern ein unsigned __int64 Datentyp. Mich wundert, dass es mit NativeLong weniger verschiebt als mit long, da unsigned __int64 ja 64 bit hat und long in Java auch. NativeLong hingegen hat nur 32 bit.
Es sieht so aus als wäre die Verschiebung ein Byte groß, was ich daraus schließe, dass bei der Ausgabe von transceiverName die letzte Stelle kein lesbarer char mehr ist(bei Verwendung von NativeLong).

 

[mrBrown]

NativeLong hingegen hat nur 32 bit.

JNA-NativeLong hat 32 oder 64 Bit, je nach System – also genau wie long unter C/C++

 

[mihe7]

Es sieht so aus als wäre die Verschiebung ein Byte groß, was ich daraus schließe, dass bei der Ausgabe von transceiverName die letzte Stelle kein lesbarer char mehr ist(bei Verwendung von NativeLong).

Was heißt "es sieht so aus"?!? Gibt es noch eine Verschiebung und wenn ja, wo und um wie viele Bytes?

 

[Der_AltMann]

JNA-NativeLong hat 32 oder 64 Bit, je nach System – also genau wie long unter C/C++

Ja das stimmt. In meinem Fall verhält sich NativeLong genau gleich wie wenn ich int nehme. Deshalb nehme ich mal an, dass es 32 Bit benutzt. __int64 hat aber 64 Bit. Deshalb hab ich mich gewundert warum die Verschiebung weniger stark ist mit dem 32 Bit wert

 

[Der_AltMann]

Was heißt "es sieht so aus"?!? Gibt es noch eine Verschiebung und wenn ja, wo und um wie viele Bytes?

bei channelIndex ist die Verschiebung schon da, ich kann nicht genau sagen, ob sie bei transceiverType und transceiverState schon da ist, da ich diese Werte nicht kenne. Die Verschiebung hat ein byte

 

[mihe7]

Was liefert denn toString()?

 

[Der_AltMann]

Was liefert denn toString()?

XLchannelConfig [name=Virtual Channel 1               , hwType=1, hwIndex=0, hwChannel=0, transceiverType=0, transceiverState=0, channelIndex=1, channelMask=0, channelCapabilities=458752, channelBusCapabilities=106496, isOnBus=1, connectedBusType=16777216, driverVersion=67830784, interfaceVersion=0, raw_data=[0, 0, 0, 65536, 0, 0, 0, 0, 0, 0], serialNumber=0, articleNumber=536870912, transceiverName=Virtual CAN                    %, specialCabFlags=0, dominantTimeout=0, reserved=[0, 0, 1442840576], busParams=XLbusParams [busType=536870912]]



XLchannelConfig [name=irtual Channel 2               %, hwType=0, hwIndex=1, hwChannel=22, transceiverType=0, transceiverState=0, channelIndex=0, channelMask=0, channelCapabilities=1792, channelBusCapabilities=16777632, isOnBus=0, connectedBusType=65536, driverVersion=264964, interfaceVersion=0, raw_data=[0, 0, 0, 256, 0, 0, 0, 0, 0, 0], serialNumber=0, articleNumber=1444937728, transceiverName=irtual CAN                   % , specialCabFlags=0, dominantTimeout=0, reserved=[0, 0, 0], busParams=XLbusParams [busType=-1591738368]]

Das % steht für ein Zeichen, dass nicht richtig dargestellt wird.

 

[mrBrown]

Ja das stimmt. In meinem Fall verhält sich NativeLong genau gleich wie wenn ich int nehme. Deshalb nehme ich mal an, dass es 32 Bit benutzt. __int64 hat aber 64 Bit. Deshalb hab ich mich gewundert warum die Verschiebung weniger stark ist mit dem 32 Bit wert

Warum steht denn im struct long, wenn es eigentlich __int64 ist?

 

[Der_AltMann]

Warum steht denn im struct long, wenn es eigentlich __int64 ist?

ja das war ein bisschen dumm von mir 😆

 

[mihe7]

Warum steht denn im struct long, wenn es eigentlich __int64 ist?

So eng muss man das ja nicht sehen

 

[Der_AltMann]

ich hab das Problem gelöst. Man musste im Konstruktor super(Structure.ALIGN_NONE); machen und den Datentyp von NativeLong zu long ändern. Jetzt funktioniert es perfekt.
Trotzdem danke für eure Hilfe