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 bits mean XYZ instead of describing how the bits actually travel over the wire.
Chris Am 11.04.20, 01:21 schrieb "Łukasz Dywicki" <l...@code-house.org>: 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 require different approach - reading and writing. So for reading we need to swap N bytes based on type length. For writing we need to alocate buffer for N bytes and swap them before writing. I am stuck now with freemaker templates and bit-io. Cheers, Łukasz On 10.04.2020 17:57, Łukasz Dywicki wrote: > I am doing some tests of ADS serialization. > > I've run into some troubles with payload which is generated with new > driver. I'm not sure if that's my fault or generated code. > > I did a verification of what Wireshark shows and how ads structures are > parsed. There is a gap I think. For example ams port number 1000 > (0x1027) is read as 4135. > > Obviously I used wrong structures while implementing protocol logic in > first place, but now I am uncertain of how fields are encoded. How we > mark field as little endian when rest of payload is big endian? Do we > have `uint_le`? > > As far I remember route creation logic I was tracking last week used > combination of LE and BE. > > Best regards, > Łukasz >