Question 1: How to distinguish whether dsdl two variables are converted into C format is one byte or two bytes, for example: dsdl has two variables uint7 node_id and bool first_part_of_unique_id, then in fact these two variables use one byte (such as 0xFA) means it, or does it mean 0x7D, 0x00. What rules does this follow? If I am not familiar with this, where should I start?
Question 2: How should I compile .uavcan to generate .h files on a linux system? I have seen instructions for compiling dsdl, but I have some problems. Now I need to compile the dsdl in https://github.com/UAVCAN/public_regulated_data_types/tree/legacy-v0/uavcan/equipment/power to generate .h, the purpose is still as mentioned in question 1, how to judge the two or Do multiple variables belong to one byte in total, or do they correspond to two or more variables? I am a new learner of dsdl. According to my understanding at the beginning, dsdl is a variable corresponding to a variable in the C language. At present, I see that the two variables of dsdl are compiled through a shift operation to generate a variable of c, (for example, as mentioned in question 1), but I don’t know if this is the case. If it is possible, I think it is intuitive to compile the .uavcan file Into a .h file. So I ask the compilation method, for the https://github.com/UAVCAN/public_regulated_data_types/tree/legacy-v0/uavcan/equipment/power file
Byte order: least significant byte (LSB) first, also known as little-endian.
Bit order: bits are filled from the most significant to the least significant, i.e., the most significant bit has index 0.
The resulting bit sequence must be aligned to 1 byte; pad bits must be set to zero.
For the purpose of example, the following data will be encoded according to the defined order:
0xbeda of bit length 12
-1 of bit length 3
-5 of bit length 4
-1 of bit length 2
0x88 of bit length 4
The resulting byte sequence is shown on the following diagram:
#
uint7 node_id
#
# If transfer is anonymous, this field indicates first-stage request.
# If transfer is non-anonymous, this field should be assigned zero and ignored.
#
bool first_part_of_unique_id
#
# If transfer is anonymous, this array must not contain more than MAX_LENGTH_OF_UNIQUE_ID_IN_REQUEST items.
# Note that array is tail-optimized, i.e. it will not be prepended with length field.
#
uint8[<=16] unique_id
1.485 1E000101 29 BA FA 44 C0 8B 63 82
1.485 1E000101 5E 05 F4 BC 10 96 DF 22
1.485 1E000101 11 A8 BA 54 47 42
Combining these two examples, where FA is uint7 node_id and bool first_part_of_unique_id to get the shift operation, let me think of a word “bit-aligned” similar to 1-byte alignment? To be honest, I read https://legacy.uavcan.org/Specification/3._Data_structure_description_language/ and still have doubts. Maybe it’s because I’m stupid. I don’t know if only the bool variable and uint7 need to be shifted (bit-aligned?) to synthesize a byte (such as 0xFA), or there are still other situations that require such a shifting operation to synthesize. I don’t know if I have expressed my meaning clearly, I hope I can get some answers to this
In UAVCAN v0, there is no implicit alignment at all (except at the end). You just squeeze all your bits together into a long string, and that’s it. The picture you attached is actually supposed to illustrate just that: having the four fields uint12, int3, int4, int2, and uint4, we end up with the 25 bits of the serialized representation. The extra 7 bits at the end are only needed to pad the resulting string to byte.
