嵌入式系統的C語言開發中，經常遇到這樣那樣的問題。有些問題可能很快就能找到原因，但是有些問題必須有一定的經驗積累才能快速找到原因。
yjbys小編整理了本人所瞭解的和經常遇到的嵌入式開發中的C語言典型問題，不足之處歡迎各位專家指摘賜教。
一、由編譯優化引起的問題
例1、編譯後的彙編語言處理邏輯跟C語言處理邏輯不一致
由於編譯器的原因，在設置了編譯優化的情況下，編譯後有些代碼的邏輯會發生變化。這種情況下會發生很奇怪的問題，一些函數的處理結果跟預想的不一致，而檢查代碼又看不出什麼問題。
這種問題的解決辦法一般是在充分分析軟件處理邏輯，確認處理上沒問題後，把編譯後的列表文件(*)和C語言處理邏輯逐行對照。把不一致的地方找出來，並尋找修正對策。
例2、編譯後的一些處理被優化了
這種問題經常發生在硬件寄存器的操作上。對於硬件而言，每一次讀寫操作可能都有特定的含義：某些硬件寄存器要求讀一下才能做後續其他處理;而某些寄存器要連續寫幾次。比如下面的情形：
#define TSTREG (unsigned char *) 0x00C00032 /*TEST REGISTER */
unsigned char *pTSTR;
pTSTR = TSTREG;
*pTSTR = 0x01; //這個操作很容易被編譯器優化掉。
*pTSTR = 0x02;
……
作爲對策之一，可以在定義變量時加上volatile關鍵字。比如：
volatile unsigned char *pTSTR;
volatile關鍵詞影響編譯器編譯的結果，用volatile聲明的變量表示該變量隨時可能發生變化，與該變量有關的運算，不要進行編譯優化，以免出錯。使用volatile變量的幾個場景：
1)中斷服務程序中修改的供其它程序檢測的變量需要加volatile。
2)多任務環境下各任務間共享的標誌應該加volatile。
3)存儲器映射的硬件寄存器通常也要加voliate，因爲每次對它的讀寫都可能有不同意義。
二、由字節對齊引起的問題
一個結構體變量定義完之後，其在內存中的存儲並不一定等於其所包含元素的寬度之和。因爲這裏涉及到字節對齊的問題。
結構體中元素的對齊基本上遵循兩個基本原則：
原則一：結構體中元素是按照定義順序一個一個放到內存中去的，但並不是緊密排列的。從結構體存儲的首地址開始，每一個元素放置到內存中時，它都會認爲內存是以它自己的大小來劃分的，因此元素放置的位置一定會在自己寬度的整數倍上開始(以結構體變量首地址爲0計算)。
原則二：在經過第一原則分析後，檢查計算出的存儲單元是否爲所有元素中最寬的元素的長度的整數倍。若是，則結束;若不是，則補齊爲它的整數倍。
每個特定平臺上的編譯器都有自己的默認“對齊係數”(也叫對齊模數或邊界調整數)。通常，可以通過預編譯命令#pragma pack(n)，n=1,2,4,8,16來改變這一系數，其中的n就是你要指定的“對齊係數”。
#pragma pack(n) //編譯器將按照n字節對齊
#pragma pack() //編譯器將取消自定義字節對齊方式
在#pragma pack(n)和#pragma pack()之間的代碼按n字節對齊。但是成員對齊有一個重要的條件，即每個成員按照自己的對齊方式對齊; 也就是說雖然指定了按n字節對齊，但並不是所有的成員都以n字節對齊。對齊的規則是：每個成員按其類型的對齊參數(通常是這個類型的大小)和指定對齊參數(這裏是n字節)中較小的一個對齊，即min(n,sizeof(item))，並且結構的長度必須爲所用過的所有對齊參數的整數倍，不夠就補空字節。
以瑞薩SH7145F CPU和XASS-V編譯器爲例，根據XASS-V幫助文件，對於SH7145F，其結構體成員的默認對齊係數如下：
char：1
short：2
int：4
long：4
float：4
long long：4
double：4
指針：4
結構體/聯合體：4
數組：根據類型而定
在編譯的時候可以通過設置 /bond = n, n=4(一般情況)，來指定邊界調整係數。因此，實際採用/bond=n中的n和上述默認對齊係數中的較小者。
由於跟特定編譯器有關，所以下面的例子僅限XASS-V編譯器，目標CPU是瑞薩SH7145F。
例1、假設 /bond=4，進行如下定義：
typedef unsigned char UCHAR;
/* 結構體定義*/
typedef struct{
union{
UCHAR SO_bit7;
UCHAR DMY0_bit56;
UCHAR LNO_bit04;
} DL; /* 預想BYTE0 */
UCHAR ORDN;
union{
UCHAR RW_bit7;
UCHAR DTNO_bit06;
}RD; /* 預想BYTE1 */
UCHAR ADRH; /* 預想BYTE2 */
UCHAR ADRL; /* 預想BYTE3 */
UCHAR DATA; /* 預想BYTE4 */
}stTEST;
/* 變量定義*/
UCHAR TEST[6];
stTEST *pTEM=( stTEST *) TEST;
這樣執行後，pTEM->ADRH並不是對應TEST [3]，導致了數據處理錯誤。
原因分析：
由邊界調整數決定，union只能在4的倍數的地址上存放;且UNION類型要佔用4*X Byte，故後面有3Byte的Dummy。即UNION{xxx}DL佔用了4Byte。
依次類推，整個結構體元素的內存分佈如下：
UNION{xxx}DL; /* Byte0~Byte3: 後3Byte Dummy*/
UCHAR ORDN; /* Byte4~Byte7: 後3Byte Dummy*/
UNION{xxx}RD; /* Byte8~Byte11: 後3Byte Dummy*/
UCHAR ADRH; /* Byte12*/
UCHAR ADRL; /* Byte13*/
UCHAR DATA; /* Byte14~Byte15: 後1Byte Dummy*/
Byte5~Byte7的Dummy是因爲UNION成員必須在4的倍數的地址上存放。
Byte15的Dummy是整個結構體大小必須是4的倍數。
所以sizeof(stTEST)=16， pTEM->ADRH對應爲Byte12，不是預想的TEST[3]。
三、由變量類型不匹配引起的問題
例1、循環變量溢出
UCHAR i = 0x00;
/* 版本1：100個循環 */
for(i=0;i<100;i++) { /* 處理：略*/}
/* 版本2：1000個循環 */
for(i=0;i<1000;i++) { /* 處理：略*/}
一開始需求是100個循環，而後面需求變更爲1000個循環，但忘記修改循環變量類型。以爲UCHAR的有效範圍是0~255，顯然不滿足版本2的要求。這種情況會發生在循環變量定義的位置距離循環體比較遠的時候，在無意識中忽略了。
四、由數組下標越界引起的問題
常見的是指定的數組下標超過了數組最大有效下標。很多情況下不會導致程序奔潰，但是取出的數據顯然是不正確的。
五、由字節序引起的問題
字節序主要體現大於1Byte的數據的存儲方式上。對於CPU而言，有MSB FIRST和LSB FIRST兩種存儲方式。MSB指Most Significant Bit，即最高有效位;LSB指Lest Significant Bit，即最低有效位。簡單地說，MSB FIRST就是高位優先存儲，即高位存儲在低地址上，低位存儲在高地址上，簡稱“高低低高”。LSB FIRST則相反，即低位優先存儲，高位存儲在高地址上，低位存儲在低地址上，簡稱“高高低低”。大部分嵌入式系統的CPU是MSB FIRST的，少部分是LSB FIRST的。常見的LSB FIRST的CPU是INTEL的。
類似的，在網絡通信方面有兩種字節序：“Big-Endian”和“Small-Endian”。 指的都是對於多字節的數據類型(比如4字節的.32位整數)，其多個字節的順序問題，是最高字節在前(Big-Endian)還是最低字節在前(Small-Endian)。 比如對於123456789這個整數，其16進製爲0x075BCD15，那麼按照Big-Endian的方式，它在網絡上傳輸(或者在內存裏存儲)的4個字節依次是：07 5B CD 15，而Small-Endian的順序正相反，是：15 CD 5B 07。處於通信的雙方必須按相同的字節序進行收發數據處理，才能得出正常的結果。
例1、應用程序A以075BCD15的字節序(Big-Endian)發送數據123456789給應用程序B，但應用程序B卻以15CD5B07的字節序(Small-Endian)處理，則雙方沒法正常通信。
六、由UNION元素賦值引起的問題
一個UNION元素的值由最後那次設定決定的。有些時候，無意中對一個UNION元素連續賦值，就會發生意料之外的問題。
例1、以前面的結構體類型stTEST 爲例，做如下設置。
stTEST tTst;
_bit7=0x80; /* SO使用bit7 */
. LNO_bit04=0x01; /* LNO使用bit0~bit4 */
這樣設置後，最終SO=0，而不是預先希望的SO=1。
七、由運算符優先級引起的問題
運算符優先級處理不好也會引入一些潛在的問題。
例1、邏輯運算符與條件運算符
int a=0x02;
if((a&0x03)!=0x00) /*表達式1*/
if(a&0x03!=0x00) /*表達式2*/
表達式1：先執行0x02&0x03=>0x02，再執行0x02 !=0x00，故結果爲TRUE。
表達式2：先執行0x03 !=0x00=>TRUE(結果是0x01)，再執行0x02&0x01，結果爲0x00即FALSE。
顯然，表達式1纔是正確的寫法。如果把用表達式2的形式就會引入一些潛在的問題。
例2、指針取值運算，邏輯運算符與條件運算符
if((*pSTSRG&0x01)==0x00) /*表達式1*/
if(((*pSTSRG)&0x01)==0x00) /*表達式2*/
if(*pSTSRG&0x01==0x00) /*表達式3*/
顯然，表達式1和表達式2是正確寫法，而且最保險的寫法是表達式2。而表達式3是錯誤寫法。
從上面的例子可以看出，由於運算符優先級不太方便記憶，也沒必要去記憶，最規避這類問題的最好辦法就是給表達式強制加上括號。
八、由中斷優先級引起的問題
在多線程應用程序開發中，經常會用信號量等方式來保證共享資源的訪問。但是在有多箇中斷的應用程序中，經常會無意識地略掉中斷優先級，導致引入一些潛在的問題。
例1、中斷IRQ1每1ms發生1次，中斷IRQ4每4ms發生1次，且IRQ4的優先級高於IRQ1。在IRQ1和IRQ4的處理過程都會設置全局變量tData。該如何安排IRQ1和IRQ4的處理邏輯?
因爲低優先級的中斷IRQ1未處理完成時，如果發生高優先級的中斷IRQ4，則IRQ1的處理會把相關上下文壓棧，暫時掛起，等IRQ4處理完成後才繼續處理IRQ1。由於IRQ4也會修改全局變量tData，如果沒有任何保護措施，則IRQ1的處理可能會不完全正確。作爲對策之一就是在IRQ1的處理中加入中斷屏蔽。
/* IRQ1的中斷處理函數 */
IRQ1_Handler()
{
xxx; /* 屏蔽所有中斷 */
yyy; /* 相關處理 */
zzz; /* 解除中斷屏蔽 */
}
當然，上述處理的前提是IRQ4是可屏蔽中斷。
九、由彙編語言轉C語言引起的問題
由於CPU的更換，原先用匯編語言開發的系統轉換爲用C語言開發的情形也是存在的。這種情況也經常會引入一些問題。
例1、CPU字節序不同而引起的問題
關於字節序參考前面的內容。當用到一個大於1Byte的變量的時候，必須瞭解新舊CPU的字節序，正確操作大於1Byte的變量，才能保證不會因爲高低位倒置而引入問題。
例2、CPU頻率不同而引起的問題
在彙編語言開發的系統中，經常會用一些循環來實現微秒級的延時。特別在串口通信中，硬件寄存器對時間非常敏感，如果在轉換成C語言時沒有考慮到這點，沒有及時調整循環次數，就會因爲CPU頻率變高而導致延時不足。
