I’m currently reading your specification (v1.0-beta) and I can’t understand one example from section 4.2.3 Examples (page 63). The example shows Heartbeat from node-ID 42, nominal priority level, uptime starting from 0 and then incrementing by one every transfer, vendor-specific status code 3471 (decimal base).
First, how is it possible to specify a vendor-specific status code that is larger than uint8? Second, maybe I don’t exactly understand serialization process of composite types. According to the description of
Heartbeat data type field attributes
mode have size of 1 byte, so after serialization
Health data type) must be followed by padding fields? Similar situation with
mode field (from
Mode data type).
In the example according to spec
02 00 00 00 - is a value of
uptime in little endian format.
E0 B1 01 - is
1110 0000 1011 0001 0000 0001. It means first 5 zeros in least significant byte are values of
000). Then we have bit sequence of value 3471 without any preceding padding fields. But why is it so? The specification says that the alignment of composite types is one byte.
You found an error — the example you referenced is, indeed, incorrect. It was supposed to be updated after we introduced certain changes since v1.0-alpha.
For clarity, this is how it is actually deserialized:
>>> import uavcan.node >>> import pyuavcan >>> pyuavcan.dsdl.deserialize(uavcan.node.Heartbeat_1_0, [b'\x03\x00\x00\x00\xE0\xB1\x01\xE3']) uavcan.node.Heartbeat.1.0(uptime=3, health=uavcan.node.Health.1.0(value=0), mode=uavcan.node.Mode.1.0(value=1), vendor_specific_status_code=1) >>> pyuavcan.dsdl.serialize(uavcan.node.Heartbeat_1_0(uptime=3, health=uavcan.node.Health_1_0(value=0), mode=uavcan.node.Mode_1_0(value=1), vendor_specific_status_code=1)) <generator object serialize at 0x7efcc5c4d580> >>> b"".join(_) b'\x03\x00\x00\x00\x00\x01\x01'
Would you volunteer to send a patch correcting these issues in the document?
Thank you for explanation! Now everything has fallen into place.
I think that I can correct this issue.