### Re: Big and littleendian fields in one mspec

Bit: 15|14|13|12|11|10|9 |8 |7 |6 |5 |4 |3 |2 > > > |1 |0 > > > > > > Meaning:A |B |C |D |E | F |G|H |I | J | K |L | M|N |O |P > > > >

### Re: Big and littleendian fields in one mspec

> > > > > > > > Assuming you have a bit field of 16 bits BE uint. If the spec > now says: > > > > > > > > > > > > > > > >

### Re: Big and littleendian fields in one mspec

> So you have to declare the bit fields in the order: > > > > I | J | K |L | M|N |O |P |A |B |C |D > > |E | F |G|H > > > > >

### Re: Big and littleendian fields in one mspec

: > > > > 7 |6 |5 |4 |3 |2 |1 |0 | 15|14|13|12|11|10|9 |8 > > > > So you have to declare the bit fields in the order: > > > > I | J | K |L | M|N |O |P |A |B |C |D &

### Re: Big and littleendian fields in one mspec

F |G|H |I | J | K |L | M|N > |O |P > > > > > > > > Then the order they are sent is: > > > > 7 |6 |5 |4 |3 |2 |1 |0 | 15|14|13|12|11|10|9 |8 > > > > So you have to declare the bit fields in the order: > > > >

### Re: Big and littleendian fields in one mspec

> > So you have to declare the bit fields in the order: > >I | J | K |L | M|N |O |P |A |B |C |D > |E | F |G|H > > > > So I don’t quite understand what you’re trying to flip here. >

### Re: Big and littleendian fields in one mspec

I  | J | K |L | M|N |O |P  |A  |B  |C  |D >  |E  | F  |G|H > >   > > So I don’t quite understand what you’re trying to flip here. > >   > > Chris > >   > > *Von: *Łukasz Dywicki > *Datum: *Dienstag, 14. April 2020 um 13:26 > *An: *Christofe

### Re: Big and littleendian fields in one mspec

:26 An: Christofer Dutz Betreff: Re: Big and littleendian fields in one mspec I've added the endianness switch to the types in my experiments. These are not needed for enums as these are read as int and then mapped to constants. I referred to these as an example - enum does have a length

### Re: Big and littleendian fields in one mspec

Hi Lukasz, but we don't have a: [enum uint 16 little endian 'CommandId'] But only a: [enum uint 16 'CommandId'] And in your case I think perhaps the constants are not correct. So having a 16 bit uint will result in a 4 digit hex string: So if you are having problems in mapping them to your

### Re: Big and littleendian fields in one mspec

Hi Julian, I am currently not aware of a protocol that mixes the endianness. I have heard that there are some modbus implementations that send the payload with different endianness for some implementations, but we shouldn't handle that on mspec level. Because then we would have super-complex

### Re: Big and littleendian fields in one mspec

Hi, as far as I see it there are technically two ways to achieve the change between BE / LE. One ist he one suggested by Lukasz, i.e. always specifying byte order for each read / write item in mspec. The other one ist o leave it out of mspec and only define it in the ByteReader / Writer

### Re: Big and littleendian fields in one mspec

Hey Christian, The problem I face is quite simple. State type in mspec i declared as a bunch of bits. Type length is fixed, however not available anywhere in mspec or code generator to re-arrange bytes upfront. All we have exposed at reader/write level is read/write bit. To be fair LE/BE support

### Re: Big and littleendian fields in one mspec

Hi Lukasz, I am not sure I am understanding the problems you are facing. We already have LE and BE protocols. For example EIP is LE and the rest is generally BE. It seems that ADS/AMS is also LE. mspec doesn't even know about endianness. Up till now the endianness doesn't have an effect on

### Re: Big and littleendian fields in one mspec

Hey Niclas, I realized how old the old things are when I started preparing automation training for mere mortals and got into history of frames and even cabling. Mr. Modbus and EIA-485 is definitely older than I. ;-) Getting back to the point - yes. I been thinking how to address the byte order in

### Re: Big and littleendian fields in one mspec

For us who were around and shaping the protocols in the 1980s, and people before us (and before standards like RS-232), a lot of the "specifications" came out of "observation of implementation we managed to get to work", rather than "implement this spec". A lot was due to extreme memory

### Re: Big and littleendian fields in one mspec

Hi Lukasz, I think it really gets tricky when using BE and having some byte-odd-sizes ... I remember in the Firmata protocol there were some bitmasks and then 10 bit uint as BE ... not it really got tricky as the specs were written from a point of view: You read 16 bits BE and then the first6

### Re: Big and littleendian fields in one mspec

I've made some progress with topic by modyfing mspec and allowing 'little endian' flag on fields. This moved me further to next issue - which is whole type encoded little endian. In ADS driver such type is State, which has 2 bytes and uses 8 bits for various flags. There are two cases which