我应该使用位字段来映射传入的串行数据吗？

我们有通过串行（蓝牙）传入的数据，它映射到特定的结构。该结构的某些部分是子字节大小，因此“显而易见”的解决方案是将传入数据映射到位字段。我无法确定的是机器或编译器的位字节顺序是否会影响它（这很难测试），以及我是否应该完全放弃位字段。

例如，我们有一条1.5字节的数据，所以我们使用结构体：

{
    uint8_t data1; // lsb
    uint8_t data2:4; // msb
    uint8_t reserved:4;
} Data;

保留位始终为 1

例如，如果传入的数据是 0xD2,0xF4，则值为 0x04D2，即 1234。

我们使用的结构始终适用于我们测试过的系统，但我们需要它尽可能可移植。

我的问题是：

• Will data1无论字节序如何，始终按预期表示正确的值（我假设是，并且硬件/软件接口应始终正确处理单个整个字节 - 如果发送 0xD2，则应接收 0xD2）？

• Could data2 and reserved是错误的方式，与data2代表高4位而不是低4位？

If yes:

• 位字节顺序（通常）是否取决于字节字节顺序，或者它们可以完全不同吗？

• 位字节顺序是由硬件还是编译器决定的？看起来 Intel 上的所有 Linux 系统都是一样的——对于 ARM 来说也是如此吗？ （如果我们可以说我们可以支持所有 Intel 和 ARM linux 版本，那应该没问题）

• 是否有一种简单的方法可以在编译器中确定它的方式，并在需要时保留位字段条目？

虽然位字段是映射传入数据的最简洁的代码方式，但我想我只是想知道放弃它们并使用类似的东西是否更安全：

struct {
    uint8_t data1; // lsb (0xFF)
    uint8_t data2; // msb (0x0F) & reserved (0xF0)
} Data;

Data d;

int value = (d.data2 & 0x0F) << 16 + d.data1

我们之所以不这样做，首先是因为许多数据字段小于 1 个字节，而不是超过 1 个字节 - 这意味着通常对于位字段，我们不必进行任何屏蔽，并且移动，因此后处理更简单。

我应该使用位字段来映射传入的串行数据吗？

不会。位域有很多实现指定的行为，这使得使用它们成为一场噩梦。

无论字节序如何，data1 是否始终按预期表示正确的值。

是的，但那是因为uint8_t是最小的可能寻址单元：字节。对于较大的数据类型，您需要注意字节顺序。

难道data2和reserved是错误的方式，data2代表高4位而不是低4位？

是的。它们也可以位于不同的字节上。另外，编译器不必支持uint8_t对于位域，即使它会支持该类型。

位字节顺序（通常）是否取决于字节字节顺序，或者它们可以完全不同吗？

最低有效位总是在最低有效字节中，但在 C 中无法确定where该位将在字节中。

位移运算符提供了足够好的顺序的可靠抽象：对于数据类型uint8_t the (1u << 0)总是最不重要的并且(1u << 7)对于所有编译器和所有体系结构来说，最重要的位。

另一方面，位字段的定义非常糟糕，以至于您无法通过定义字段的顺序来确定位的顺序。

位字节顺序是由硬件还是编译器决定的？

编译器决定数据类型如何映射到实际位，但硬件对其影响很大。对于位字段，同一硬件的两个不同编译器可以按不同的顺序放置字段。

是否有一种简单的方法可以在编译器中确定它的方式，并在需要时保留位字段条目？

并不真地。如果可能的话，这取决于您的编译器如何执行此操作。

虽然位字段是映射传入数据的最简洁的代码方式，但我想我只是想知道放弃它们并使用类似的东西是否更安全：

绝对放弃位字段，但我也建议为此目的完全放弃结构，因为：

• 您需要使用编译器扩展或手动工作来处理字节顺序。

• 您需要使用编译器扩展来禁用填充，以避免由于对齐限制而出现间隙。这会影响某些系统上的成员访问性能。

• 您不能有可变宽度或可选字段。

• 如果您不知道这些问题，很容易出现严格的别名违规。如果为数据帧定义字节数组并将其转换为指向结构的指针，然后取消引用它，那么在很多情况下都会遇到问题。

相反，我建议手动执行此操作。定义字节数组，然后在必要时使用位移位和掩码将每个字段分开，手动将每个字段写入其中。您可以为基本数据类型编写简单的可重用转换函数。