Re: Big and littleendian fields in one mspec

2020-05-06 Thread Julian Feinauer
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

2020-05-05 Thread Łukasz Dywicki
> > > > > > > > Assuming you have a bit field of 16 bits BE uint. If the spec > now says: > > > > > > > > > > > > > > > >

Re: Big and littleendian fields in one mspec

2020-05-01 Thread Christofer Dutz
> 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

2020-04-30 Thread Christofer Dutz
: > > > > 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

2020-04-30 Thread Łukasz Dywicki
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

2020-04-14 Thread Christofer Dutz
> > 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

2020-04-14 Thread Łukasz Dywicki
  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

2020-04-14 Thread Christofer Dutz
: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

2020-04-14 Thread Christofer Dutz
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

2020-04-14 Thread Christofer Dutz
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

2020-04-14 Thread Julian Feinauer
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

2020-04-14 Thread Łukasz Dywicki
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

2020-04-14 Thread Christofer Dutz
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

2020-04-13 Thread Łukasz Dywicki
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

2020-04-12 Thread Niclas Hedhman
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

2020-04-12 Thread Christofer Dutz
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

2020-04-10 Thread Łukasz Dywicki
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