Why are message fields reordered?

[Tim]

In the mavgen.py code it reads the message fields from the XML, and
then reorders them according to the base data type size. For example:

<field type="char[16]" name="param_id">Onboard
parameter id</field>
<field type="float" name="param_value">Onboard
parameter value</field>
<field type="uint8_t" name="param_type">Onboard
parameter type: see MAV_VAR enum</field>
<field type="uint16_t" name="param_count">Total number
of onboard parameters</field>
<field type="uint16_t" name="param_index">Index of this
onboard parameter</field>

becomes

float param_value; ///< Onboard parameter value
uint16_t param_count; ///< Total number of onboard parameters
uint16_t param_index; ///< Index of this onboard parameter
char param_id[16]; ///< Onboard parameter id
uint8_t param_type; ///< Onboard parameter type: see MAV_VAR enum

My question is: why is this? It doesn't seem to add anything except
complexity. In fact I consider it slightly dangerous, since the
mapping from the XML field order to the actual field order is now
pretty complicated and arbitrary.

Something to consider for version 4 of the protocol.

[Andrew Tridgell]

Hi Tim,

> In the mavgen.py code it reads the message fields from the XML, and
> then reorders them according to the base data type size.

right

> My question is: why is this? It doesn't seem to add anything except
> complexity.

it ensures that all data types are natually aligned, which allows the
generated code to be maximally efficient and compact on all CPU types
(many CPUs cannot access values that are not aligned on a byte offset
that is a multiple of the size of the element).

The end result is much more compact code for some microcontrollers. It
is often faster too. It also prevents compilers adding pad bytes in
unexpected places. Not all compilers support directives to disable type
alignment.

> In fact I consider it slightly dangerous, since the
> mapping from the XML field order to the actual field order is now
> pretty complicated and arbitrary.

it is not arbitrary, it is a stable sort on the field size. The code
generator handles all the complexity of ensuring the correct decoding is
used.

Cheers, Tridge

[Tim Hutt]

On 25 January 2012 04:09, Andrew Tridgell <tri...@samba.org> wrote:
> it ensures that all data types are natually aligned,

Ah ok, this makes sense too!

One final question, why are there two different enums for data types?
(e.g. both MAVLINK_TYPE_FLOAT = 9, and MAV_VAR_FLOAT = 0). Also, for
the SET_PARAM message, we have:

uint8_t param_type; ///< Onboard parameter type: see MAV_VAR enum

but QGroundControl appears to use the MAVLINK_TYPE values:

qgroundcontrol/src/uas/UAS.cc: p.param_type = MAVLINK_TYPE_FLOAT;

Cheers,

Tim

[Bryant]

My question here would be why isn't this left as an exercise to the
user with a warning during MAVLink generation if how they arranged the
variables isn't optimal? It seems odd to remove this flexibility as it
may be beneficial to have a specific ordering in some cases.