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
>
