希望本是無所謂有，無所謂無的，這正如腳下的路，其實地上本沒有路，走的人多了，也便成了路....原創不易，文章會持續更新，感謝您的關注

1.問題由來

MCU給上位機發送的一幀數據中，總是多一個字節，調試很久后發現gcc編譯器會把結構體所占空間按四字節對齊。

2.復現

(1)聲明結構體和枚舉類型

typedef enum{ EN_INDIVIDUAL = 0x01,/*個人*/ EN_MANUFACTURER ,/*制造商*/????EN_ENGINEER???,/*工程師*/}enUserLevel_t; typedef enum{ EN_BOOTLOADER = 0x01,/*bootloader*/ EN_CONTROLLER_APP ,/*控制器app*/ EN_PHONE_APP ,/*手機app*/????EN_PC????????,/*電腦上位機*/}enDeviceType_t; typedef struct { enDeviceType_t ubDeviceType; enUserLevel_t ubUserLevel; uint8_t ubMainCmd; uint16_t usSubCmd; uint8_t ubDescribeInfo; uint32_t ulParameterLength; uint8_t* pParameterBuffer;????uint32_t?????ulCrcCheckCode;}tagFrame_t,?*pFrame_t;

(2)程序

__attribute__((optimize( 0 ) ))int main(void){??/*因為p定義了沒使用，加上__attribute__((optimize(?0?)?))*/??/*可以讓gcc不要優化這個函數*/?? tagFrame_t frame; pFrame_t p = &frame; uint8_t arrTxBuffer[1024] = {0x00}; unit32_t length = sizeof(tagFrame_t); frame.ubDeviceType = 1; frame.ubUserLevel = 2; frame.ubMainCmd = 3; frame.usSubCmd = 0x1234; frame.ubDescribeInfo = 5; frame.ulParameterLength = 0xabcd; frame.pParameterBuffer= (uint8_t*)0x1234; for (int8_t i = 0; i < length; i++) { arrTxBuffer[i] = ((uint8_t*)frame)[i]; } sendFrameData(arrTxBuffer, length);}

(3)看內存

從內存可以看出，因為tagFrame_t 結構體的前三個字節加起來一共3個字節，不足4字節，所以gcc編譯器會自動補一個字節，籌齊4字節為一組。

Frame_t的第四個字節是從0x20008FD8開始的，而不是從0x20008FD7開始的，0x20008FD7地址處的0就是gcc編譯器補的。也就能解釋為什么通過sendFrameData函數把arrTxBuffer數組中的內容一個一個字節發送到上位機時，數據老是對不上。

3.解決方法

修改結構體的聲明，人為配成4字節對齊：

typedef struct { enDeviceType_t ubDeviceType; enUserLevel_t ubUserLevel; uint8_t ubDescribeInfo; uint8_t ubMainCmd; uint32_t usSubCmd; uint32_t ulParameterLength; uint8_t* pParameterBuffer; uint32_t ulCrcCheckCode;}tagFrame_t,?*pFrame_t;

4.結論

編譯器為gcc時，有以下結論：
(1)C語言的枚舉占1個字節。
(2)gcc編譯程序時，會自動把結構體按4字節方式對齊。
(3)默認情況下，arm處理器是小端模式。0x1234這個數據，0x12是高8位，在高地址0x20008FD9中；0x34是低8位，在低地址0x20008FD8中。

專注于 嵌入式 和 qt知識分享

歡迎掃碼關注
“嵌入式工程師成長之路”

? 作者原創視頻

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的c# 结构体 4字节对齐_【专题4：平时遇到的问题】 之 【3.由结构体字节对齐引发的通信故障】...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。