problems with little-edian dword in RAW codec [message #1801864] |
Mon, 28 January 2019 16:02 |
|
I'm currently trying to express a 32bit little-endian bitfield using the TITAN RAW codec and I simply cannot get it to work. I must have tried all permutations of FIELDORDER, BITORDER and BYTEORDER without success.
The full module source is available at http://git.osmocom.org/titan.TestPorts.USB/tree/src/CCID_Types.ttcn
Maybe somebody can provide a quick help?
The data in question is simply a 32bit DWORD in little-endian byte order. It contains reserved bits in the upper 30 bits, and two defined bits as the two LSB.
module CCID_Types {
type bitstring BIT30 length(30) with { variant "FIELDLENGTH(30)" };
type record CCID_Protocols {
BIT30 RFU,
boolean protocol_t1,
boolean protocol_t0
};
} with { encode "RAW"; variant "FIELDORDER(msb)" }
I always get something like
dwProtocools := {
RFU := '000000000000000000000000000011'B,
protocol_t1 := false,
protocol_t0 := false
},
This seems to suggest that the bit-order is correct, but somehow the field-order isn't - despite the entire module having set FIELDORDER(msb) in the definition above.
If I decode the entire 32bit value not as CCID_Protocols but using the u32le_t definition below, it works. But of course I don't get the individual bits decoded as booleans, as intended.
type integer u32le_t (0..4294967295) with { variant "unsigned 32 bit" variant "BYTEORDER(first)" };
I'm trying similar constructs with a variety of data types, and it seems to always work when the bitfield is < 8 bits (e.g. 5 MSB RFU, then 3 bits as individual bools) but it seems to consistently fail whenever the record is encoded over more than one byte.
Thanks in advance for your help.
|
|
|
|
Re: problems with little-edian dword in RAW codec [message #1801892 is a reply to message #1801867] |
Tue, 29 January 2019 09:57 |
|
Thanks for your quick response and for presenting a work-around for the problem.
I intentionally did not want to re-order the fields in the record to keep the order of fields the same way as people would "normally" write it if they were writing (or looking at) a "C struct" definition. This way it's also much easier for a human being to compare the definition in TTCN-3 and the definition in C when writing related code.
I was under the impression that the various *ORDER attributes of the RAW codec would provide me with that flexibility, but it appears I was mistaken. Thanks for clarifying it.
|
|
|
|
Powered by
FUDForum. Page generated in 0.03225 seconds