Should I use bit-fields for mapping incoming serial data?

后端 未结 1 1431
隐瞒了意图╮
隐瞒了意图╮ 2020-12-21 14:23

We have data coming in over serial (Bluetooth), which maps to a particular structure. Some parts of the structure are sub-byte size, so the \"obvious\" solution is to map th

相关标签:
1条回答
  • 2020-12-21 15:16

    Should I use bit-fields for mapping incoming serial data?

    No. Bit-fields have a lot of implementation specified behaviour that makes using them a nightmare.

    Will data1 always represent the correct value as expected regardless of endianness.

    Yes, but that is because uint8_t is smallest possible addressable unit: a byte. For larger data types you need to take care of the byte endianness.

    Could data2 and reserved be the wrong way around, with data2 representing the upper 4 bits instead of the lower 4 bits?

    Yes. They could also be on different bytes. Also, compiler doesn't have to support uint8_t for bitfields, even if it would support the type otherwise.

    Is the bit endianness (generally) dependent on the byte endianness, or can they differ entirely?

    The least signifact bit will always be in the least significant byte, but it's impossible to determine in C where in the byte the bit will be.

    Bit shifting operators give reliable abstraction of the order that is good enough: For data type uint8_t the (1u << 0) is always the least significant and (1u << 7) the most significant bit, for all compilers and for all architectures.

    Bit-fields on the other hand are so poorly defined that you cannot determine the order of bits by the order of your defined fields.

    Is the bit-endianness determined by the hardware or the compiler?

    Compiler dictates how datatypes map to actual bits, but hardware heavily influences it. For bit-fields, two different compilers for the same hardware can put fields in different order.

    Is there a simple way to determine in the compiler which way around it is, and reserve the bit-fields entries if needed?

    Not really. It depends on your compiler how to do it, if it's possible at all.

    Although bit-fields are the neatest way, code-wise, to map the incoming data, I suppose I am just wondering if it's a lot safer to just abandon them, and use something like:

    Definitely abandon bit-fields, but I would also recommend abandoning structures altogether for this purpose, because:

    • You need to use compiler extensions or manual work to handle byte order.

    • You need to use compiler extensions to disable padding to avoid gaps due to alignment restrictions. This affects member access performance on some systems.

    • You cannot have variable width or optional fields.

    • It's very easy to have strict aliasing violations if you are unaware of those issues. If you define byte array for the data frame and cast that to pointer to structure and then dereference that, you have problems in many cases.

    Instead I recommend doing it manually. Define byte array and then write each field into it manually by breaking them apart using bit shifting and masking when necessary. You can write a simple reusable conversion functions for the basic data types.

    0 讨论(0)
提交回复
热议问题