位域无法正常工作

我正在看II. XC32允许比特字段大于32位宽吗？

不确定，但没有抱怨。

对此我也不确定。不幸的是，这里的编译器手册有点薄：我不知道这里到底发生了什么。所以我所能做的就是提供一些想法和非常疯狂的猜测（我不知道它是否有用，或者它是否令人困惑）。我之所以这样问，是因为如果您有嵌套结构，那么事情就会变得更加复杂，因为这比已经出现的问题更深入到编译器特定的行为中。然后，您是否尝试检查sizeof(MESSAGE_LORA_V001)是否为36字节？例如，您可以将其放入易失性变量并检查它。或者你可以做一些野生的LED闪烁（如果你有一个），如果它是错误的。然后，也许它也可能是一个问题的手表窗口。你是不是试着把MM的值读回正常的UIT32？T，看看这个结果？也许你可以试着用-Wpadded编译，看看是否有警告。我猜你想要一个布局，它有0填充位，像这样：8a a 1 a a 7 bb8 bb2 bb2 bb 6 cc---8dd8 dd8 dd8 dd8 dd8 dd8 dd8 dd8 ee8 ee---8ff5 ff 3 gg6 gg 2 hh7 hh 1 ii--------------------------------------8ii8ii8ii8ii8iii8j8j8jj8jjj7j7----------------------------------------------------------------------------------------------jj 1 kk--------8kk8 kk1 kk 7 ll------2ll 6 mm8 mm8 mm8 mm8 mm8 mm--------------------1mm 7 nn8 nn2 nn 7垃圾桶------考虑到一些字段正在跨越它们自己的存储单元的边界，这也许是个问题。例如GG使用的是16位类型，但不适合FF的16位块。也许使用32位类型会有所不同。对于其他的.gg(uint16_t)也是如此，它将穿过16位..ii(uint64_t)，它将穿过128位borderkk(uint32_t)，它将穿过64位..ll(uint16_t)，它将穿过32位..mm(uint32_t)，后者将穿过一个32位..mm(uint32_t)。256位边框。可能是，因此编译器总是将这些数据移动到下一个完全包含它们的存储块中。另一个荒谬的理论是，它可能与缓存页面大小有关，对于您来说可能是256，而缓存页面大小是mm。但是请注意，我不知道是否有我上面描述的东西是真实的，我不知道它是否会引起你的问题。

首先，你张贴的内容不一致。也就是说，假设您有一个名为lora_message的MESAGE_LORA_V001变量，那么就不存在lora_message.V001，更不用说lora_message.V001.jj。我没有花时间尝试复制您使用调试器的经验（我不太喜欢调试调试器或变量的IDE显示）。我没有尝试任何额外的包装或填充。我刚刚使用了你所展示的TyBuffF: ---论坛不让我发布代码片段。参见附件——输出：在2017年8月29日11:01:37PDT上用XC32版本14401编译：lora_message.jj=1080000001=0x405F7E012:lora_message.mm=1080000001=05F7E013:lora_message.jj=1126240237=0x43210FED4:lora_message.mm=1412567294=0x543210FE4，这里没有显示，但我也打印了siZeof（MasaGeLoaLaVv1），得到了36，如预期的（与XC32版本1.43和1.42相同的结果），戴夫。