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.


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
    I am stuck now with freemaker templates and bit-io.
    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

Reply via email to