1、簡介

市面上介紹C語言以及編程方法的書數目繁多，但對如何編寫優質嵌入式C程序卻鮮有介紹，特別是對應用于單片機、ARM7、Cortex-M3這類微控制器上的優質C程序編寫方法幾乎是個空白。本文面向的，正是使用單片機、ARM7、Cortex-M3這類微控制器的底層編程人員。

編寫優質嵌入式C程序絕非易事，它跟設計者的思維和經驗積累關系密切。嵌入式C程序員不僅需要熟知硬件的特性、硬件的缺陷等，更要深入一門語言編程，不浮于表面。為了更方便的操作硬件，還需要對編譯器進行深入的了解。

本文將從語言特性、編譯器、防御性編程、測試和編程思想這幾個方面來討論如何編寫優質嵌入式C程序。與很多雜志、書籍不同，本文提供大量真實實例、代碼段和參考書目，不僅介紹應該做什么，還重點介紹如何做、以及為什么這樣做。編寫優質嵌入式C程序涉及面十分廣，需要程序員長時間的經驗積累，本文希望能縮短這一過程。

2、C語言特性

語言是編程的基石，C語言詭異且有種種陷阱和缺陷，需要程序員多年歷練才能達到較為完善的地步。雖然有眾多書籍、雜志、專題討論過C語言的陷阱和缺陷，但這并不影響本節再次討論它。總是有大批的初學者，前仆后繼的倒在這些陷阱和缺陷上，民用設備、工業設備甚至是航天設備都不例外。本節將結合具體例子再次審視它們，希望引起足夠重視。深入理解C語言特性，是編寫優質嵌入式C程序的基礎。

2.1處處都是陷阱

2.1.1 無心之過

1)“=”和”==”

將比較運算符”==”誤寫成賦值運算符”=”，可能是絕大多數人都遇到過的。

代碼的本意是比較變量x是否等于常量5，但是誤將”==”寫成了”=”，if語句恒為真。如果在邏輯判斷表達式中出現賦值運算符，現在的大多數編譯器會給出警告信息。比如keil MDK會給出警告提示：“warning: #187-D: use of "=" where"==" may have been intended”，但并非所有程序員都會注意到這類警告，因此有經驗的程序員使用下面的代碼來避免此類錯誤：

將常量放在變量x的左邊，即使程序員誤將’==’寫成了’=’，編譯器會產生一個任誰也不能無視的語法錯誤信息：不可給常量賦值！

2)復合賦值運算符

復合賦值運算符（+=、*=等等）雖然可以使表達式更加簡潔并有可能產生更高效的機器代碼，但某些復合賦值運算符也會給程序帶來隱含Bug，比如”+=”容易誤寫成”=+”，代碼如下：

1.tmp=+1;

代碼本意是想表達tmp=tmp+1，但是將復合賦值運算符”+=”誤寫成”=+”：將正整數常量1賦值給變量tmp。編譯器會欣然接受這類代碼，連警告都不會產生。

如果你能在調試階段就發現這個Bug，真應該慶祝一下，否則這很可能會成為一個重大隱含Bug，且不易被察覺。

復合賦值運算符”-=”也有類似問題存在。

3)其它容易誤寫

使用了中文標點

頭文件聲明語句最后忘記結束分號

邏輯與&&和位與&、邏輯或||和位或|、邏輯非！和位取反~

字母l和數字1、字母O和數字0

這些誤寫其實容易被編譯器檢測出，只需要關注編譯器對此的提示信息，就能很快解決。

很多的軟件Bug源自于輸入錯誤。在Google上搜索的時候，有些結果列表項中帶有一條警告，表明Google認為它帶有惡意代碼。如果你在2009年1月31日一大早使用Google搜索的話，你就會看到，在那天早晨55分鐘的時間內，Google的搜索結果標明每個站點對你的PC都是有害的。這涉及到整個Internet上的所有站點，包括Google自己的所有站點和服務。Google的惡意軟件檢測功能通過在一個已知攻擊者的列表上查找站點，從而識別出危險站點。在1月31日早晨，對這個列表的更新意外地包含了一條斜杠(“/”)。所有的URL都包含一條斜杠，并且，反惡意軟件功能把這條斜杠理解為所有的URL都是可疑的，因此，它愉快地對搜索結果中的每個站點都添加一條警告。很少見到如此簡單的一個輸入錯誤帶來的結果如此奇怪且影響如此廣泛，但程序就是這樣，容不得一絲疏忽。

2.1.2 數組下標

數組常常也是引起程序不穩定的重要因素，C語言數組的迷惑性與數組下標從0開始密不可分，你可以定義int test[30]，但是你絕不可以使用數組元素test [30]，除非你自己明確知道在做什么。

2.1.3 容易被忽略的break關鍵字

1)不能漏加的break

switch…case語句可以很方便的實現多分支結構，但要注意在合適的位置添加break關鍵字。程序員往往容易漏加break從而引起順序執行多個case語句，這也許是C的一個缺陷之處。

對于switch…case語句，從概率論上說，絕大多數程序一次只需執行一個匹配的case語句，而每一個這樣的case語句后都必須跟一個break。去復雜化大概率事件，這多少有些不合常情。

2)不能亂加的break

break關鍵字用于跳出最近的那層循環語句或者switch語句，但程序員往往不夠重視這一點。

1990年1月15日，AT&T電話網絡位于紐約的一臺交換機宕機并且重啟，引起它鄰近交換機癱瘓，由此及彼，一個連著一個，很快，114臺交換機每六秒宕機重啟一次，六萬人九小時內不能打長途電話。當時的解決方式：工程師重裝了以前的軟件版本。。。事后的事故調查發現，這是break關鍵字誤用造成的。《C專家編程》提供了一個簡化版的問題源碼：

那個程序員希望從if語句跳出，但他卻忘記了break關鍵字實際上跳出最近的那層循環語句或者switch語句。現在它跳出了switch語句，執行了use_modes_pointer()函數。但必要的初始化工作并未完成，為將來程序的失敗埋下了伏筆。

2.1.4 意想不到的八進制

將一個整形常量賦值給變量，代碼如下所示：

1.inta=34,b=034;

變量a和b相等嗎？

答案是不相等的。我們知道，16進制常量以’0x’為前綴，10進制常量不需要前綴，那么8進制呢？它與10進制和16進制表示方法都不相通，它以數字’0’為前綴，這多少有點奇葩：三種進制的表示方法完全不相通。如果8進制也像16進制那樣以數字和字母表示前綴的話，或許更有利于減少軟件Bug，畢竟你使用8進制的次數可能都不會有誤使用的次數多！下面展示一個誤用8進制的例子，最后一個數組元素賦值錯誤：

1.a[0]=106;/*十進制數106*/

2.a[1]=112;/*十進制數112*/

3.a[2]=052;/*實際為十進制數42，本意為十進制52*/

2.1.5指針加減運算

指針的加減運算是特殊的。下面的代碼運行在32位ARM架構上，執行之后，a和p的值分別是多少？

1.inta=1;

2.int*p=(int*)0x00001000;

3.a=a+1;

4.p=p+1;

對于a的值很容判斷出結果為2，但是p的結果卻是0x00001004。指針p加1后，p的值增加了4，這是為什么呢？原因是指針做加減運算時是以指針的數據類型為單位。p+1實際上是按照公式p+1*sizeof(int)來計算的。不理解這一點，在使用指針直接操作數據時極易犯錯。

某項目使用下面代碼對連續RAM初始化零操作，但運行發現有些RAM并沒有被真正清零。

通過分析我們發現，由于pRAMaddr是一個無符號int型指針變量，所以pRAMaddr+=4代碼其實使pRAMaddr偏移了4*sizeof(int)=16個字節，所以每執行一次for循環，會使變量pRAMaddr偏移16個字節空間，但只有4字節空間被初始化為零。其它的12字節數據的內容，在大多數架構處理器中都會是隨機數。

2.1.6關鍵字sizeof

不知道有多少人最初認為sizeof是一個函數。其實它是一個關鍵字，其作用是返回一個對象或者類型所占的內存字節數，對絕大多數編譯器而言，返回值為無符號整形數據。需要注意的是，使用sizeof獲取數組長度時，不要對指針應用sizeof操作符，比如下面的例子：

我們知道，對于一個數組array[20]，我們使用代碼sizeof(array)/sizeof(array[0])可以獲得數組的元素（這里為20），但數組名和指針往往是容易混淆的，有且只有一種情況下數組名是可以當做指針的，那就是數組名作為函數形參時，數組名被認為是指針，同時，它不能再兼任數組名。注意只有這種情況下，數組名才可以當做指針，但不幸的是這種情況下容易引發風險。在ClearRAM函數內，作為形參的array[]不再是數組名了，而成了指針。sizeof(array)相當于求指針變量占用的字節數，在32位系統下，該值為4，sizeof(array)/sizeof(array[0])的運算結果也為4。所以在main函數中調用ClearRAM(Fle)，也只能清除數組Fle中的前四個元素了。

2.1.7增量運算符’++’和減量運算符’—‘

增量運算符”++”和減量運算符”--“既可以做前綴也可以做后綴。前綴和后綴的區別在于值的增加或減少這一動作發生的時間是不同的。作為前綴是先自加或自減然后做別的運算，作為后綴時，是先做運算，之后再自加或自減。許多程序員對此認識不夠，就容易埋下隱患。下面的例子可以很好的解釋前綴和后綴的區別。

1.inta=8,b=2,y;

2.y=a+++--b;

代碼執行后，y的值是多少？

這個例子并非是挖空心思設計出來專門讓你絞盡腦汁的C難題（如果你覺得自己對C細節掌握很有信心，做一些C難題檢驗一下是個不錯的選擇。那么，《The C Puzzle Book》這本書一定不要錯過），你甚至可以將這個難懂的語句作為不友好代碼的例子。但是它也可以讓你更好的理解C語言。根據運算符優先級以及編譯器識別字符的貪心法原則，第二句代碼可以寫成更明確的形式：

1.y=(a++)+(--b);

當賦值給變量y時，a的值為8，b的值為1,所以變量y的值為9；賦值完成后，變量a自加，a的值變為9，千萬不要以為y的值為10。這條賦值語句相當于下面的兩條語句：

1.y=a+(--b);

2.a=a+1;

2.1.8邏輯與’&&’和邏輯或’||’的陷阱

為了提高系統效率，邏輯與和邏輯或操作的規定如下：如果對第一個操作數求值后就可以推斷出最終結果，第二個操作數就不會進行求值！比如下面代碼：

1.if((i>=0)&&(i++<=max))????

2.{

3.//其它代碼

4.}

在這個代碼中，只有當i>=0時，i++才會被執行。這樣，i是否自增是不夠明確的，這可能會埋下隱患。邏輯或與之類似。

2.1.9結構體的填充

結構體可能產生填充，因為對大多數處理器而言，訪問按字或者半字對齊的數據速度更快，當定義結構體時，編譯器為了性能優化，可能會將它們按照半字或字對齊，這樣會帶來填充問題。比如以下兩個個結構體：

第一個結構體：

1.struct{

2.charc；

3.shorts；

4.intx；

5.}str_test1;

第二個結構體：

1.struct{

2.charc；

3.intx；

4.shorts；

5.}str_test2;

這兩個結構體元素都是相同的變量，只是元素換了下位置，那么這兩個結構體變量占用的內存大小相同嗎？

其實這兩個結構體變量占用的內存是不同的，對于Keil MDK編譯器，默認情況下第一個結構體變量占用8個字節，第二個結構體占用12個字節，差別很大。第一個結構體變量在內存中的存儲格式如圖2-1所示：

圖2-1：結構體變量1內存分布

第二個結構體變量在內存中的存儲格式如圖2-2所示。對比兩個圖可以看出MDK編譯器是是怎么將數據對齊的，這其中的填充內容是之前內存中的數據，是隨機的，所以不能再結構之間逐字節比較；另外，合理的排布結構體內的元素位置，可以最大限度減少填充，節省RAM。

圖2-2 ：結構體變量2內存分布

2.2不可輕視的優先級

C語言有32個關鍵字，卻有34個運算符。要記住所有運算符的優先級是困難的。稍不注意，你的代碼邏輯和實際執行就會有很大出入。

比如下面將BCD碼轉換為十六進制數的代碼：

1.result=(uTimeValue>>4)*10+uTimeValue&0x0F;

這里uTimeValue存放的BCD碼，想要轉換成16進制數據，實際運行發現，如果uTimeValue的值為0x23，按照我設定的邏輯，result的值應該是0x17，但運算結果卻是0x07。經過種種排查后，才發現’+’的優先級是大于’&’的，相當于(uTimeValue>>4)*10+uTimeValue與0x0F位與，結果自然與邏輯不符。符合邏輯的代碼應該是：

1.result=(uTimeValue>>4)*10+(uTimeValue&0x0F);

不合理的#define會加重優先級問題，讓問題變得更加隱蔽。

運算符'=='的優先級是大于'&'的，代碼IO0PIN&(1<<11)?==(1<<11))等效為IO0PIN&0x00000001：判斷端口P0.0是否為高電平，這與原意相差甚遠。因此，使用宏定義的時候，最好將被定義的內容用括號括起來。

按照常規方式使用時，可能引起誤會的運算符還有很多，如表2-1所示。C語言的運算符當然不會只止步于數目繁多！

有一個簡便方法可以避免優先級問題：不清楚的優先級就加上”()”，但這樣至少有會帶來兩個問題：

過多的括號影響代碼的可讀性，包括自己和以后的維護人員

別人的代碼不一定用括號來解決優先級問題，但你總要讀別人的代碼

無論如何，在嵌入式編程方面，該掌握的基礎知識，偷巧不得。建議花一些時間，將優先級順序以及容易出錯的優先級運算符理清幾遍。

2.3隱式轉換

C語言的設計理念一直被人吐槽，因為它認為C程序員完全清楚自己在做什么，其中一個證據就是隱式轉換。C語言規定，不同類型的數據（比如char和int型數據）需要轉換成同一類型后，才可進行計算。如果你混合使用類型，比如用char類型數據和int類型數據做減法，C使用一個規則集合來自動（隱式的）完成類型轉換。這可能很方便，但也很危險。

這就要求我們理解這個轉換規則并且能應用到程序中去！

1)當出現在表達式里時，有符號和無符號的char和short類型都將自動被轉換為int類型，在需要的情況下，將自動被轉換為unsigned int（在short和int具有相同大小時）。這稱為類型提升。

提升在算數運算中通常不會有什么大的壞處，但如果位運算符 ~ 和 << 應用在基本類型為unsigned char或unsigned short 的操作數，結果應該立即強制轉換為unsigned char或者unsigned short類型（取決于操作時使用的類型）。

1.uint8_tport=0x5aU;

2.uint8_tresult_8;

3.result_8=(~port)>>4;

假如我們不了解表達式里的類型提升，認為在運算過程中變量port一直是unsigned char類型的。我們來看一下運算過程：~port結果為0xa5，0xa5>>4結果為0x0a，這是我們期望的值。但實際上，result_8的結果卻是0xfa！在ARM結構下，int類型為32位。變量port在運算前被提升為int類型：~port結果為0xffffffa5，0xa5>>4結果為0x0ffffffa，賦值給變量result_8，發生類型截斷（這也是隱式的！），result_8=0xfa。經過這么詭異的隱式轉換，結果跟我們期望的值，已經大相徑庭！正確的表達式語句應該為：

1.result_8=(unsignedchar)(~port)>>4;/*強制轉換*/

2)在包含兩種數據類型的任何運算里，兩個值都會被轉換成兩種類型里較高的級別。類型級別從高到低的順序是long double、double、float、unsigned long long、long long、unsigned long、long、unsigned int、int。

這種類型提升通常都是件好事，但往往有很多程序員不能真正理解這句話，比如下面的例子（int類型表示16位）。

u32x和u32y的結果都是4464（70000%65536）！不要認為表達式中有一個高類別uint32_t類型變量，編譯器都會幫你把所有其他低類別都提升到uint32_t類型。正確的書寫方式：

1.u32x=(uint32_t)u16a+(uint32_t)u16b;或者：

2.u32x=(uint32_t)u16a+u16b;

后一種寫法在本表達式中是正確的，但是在其它表達式中不一定正確，比如：

1.uint16_tu16a,u16b,u16c;

2.uint32_tu32x;

3.u32x=u16a+u16b+(uint32_t)u16c;/*錯誤寫法，u16a+u16b仍可能溢出*/

3) 在賦值語句里，計算的最后結果被轉換成將要被賦予值的那個變量的類型。這一過程可能導致類型提升也可能導致類型降級。降級可能會導致問題。比如將運算結果為321的值賦值給8位char類型變量。程序必須對運算時的數據溢出做合理的處理。很多其他語言，像Pascal（C語言設計者之一曾撰文狠狠批評過Pascal語言），都不允許混合使用類型，但C語言不會限制你的自由，即便這經常引起Bug。

4) 當作為函數的參數被傳遞時，char和short會被轉換為int，float會被轉換為double。

當不得已混合使用類型時，一個比較好的習慣是使用類型強制轉換。強制類型轉換可以避免編譯器隱式轉換帶來的錯誤，同時也向以后的維護人員傳遞一些有用信息。這有個前提：你要對強制類型轉換有足夠的了解！下面總結一些規則：

并非所有強制類型轉換都是由風險的，把一個整數值轉換為一種具有相同符號的更寬類型時，是絕對安全的。

精度高的類型強制轉換為精度低的類型時，通過丟棄適當數量的最高有效位來獲取結果，也就是說會發生數據截斷，并且可能改變數據的符號位。

精度低的類型強制轉換為精度高的類型時，如果兩種類型具有相同的符號，那么沒什么問題；需要注意的是負的有符號精度低類型強制轉換為無符號精度高類型時，會不直觀的執行符號擴展，例如：

3、編譯器

如果你和一個優秀的程序員共事，你會發現他對他使用的工具非常熟悉，就像一個畫家了解他的畫具一樣。----比爾.蓋茨

3.1不能簡單的認為是個工具

嵌入式程序開發跟硬件密切相關，需要使用C語言來讀寫底層寄存器、存取數據、控制硬件等，C語言和硬件之間由編譯器來聯系，一些C標準不支持的硬件特性操作，由編譯器提供。

匯編可以很輕易的讀寫指定RAM地址、可以將代碼段放入指定的Flash地址、可以精確的設置變量在RAM中分布等等，所有這些操作，在深入了解編譯器后，也可以使用C語言實現。

C語言標準并非完美，有著數目繁多的未定義行為，這些未定義行為完全由編譯器自主決定，了解你所用的編譯器對這些未定義行為的處理，是必要的。

嵌入式編譯器對調試做了優化，會提供一些工具，可以分析代碼性能，查看外設組件等，了解編譯器的這些特性有助于提高在線調試的效率。

此外，堆棧操作、代碼優化、數據類型的范圍等等，都是要深入了解編譯器的理由。

如果之前你認為編譯器只是個工具，能夠編譯就好。那么，是時候改變這種思想了。

3.2不能依賴編譯器的語義檢查

編譯器的語義檢查很弱小，甚至還會“掩蓋”錯誤。現代的編譯器設計是件浩瀚的工程，為了讓編譯器設計簡單一些，目前幾乎所有編譯器的語義檢查都比較弱小。為了獲得更快的執行效率，C語言被設計的足夠靈活且幾乎不進行任何運行時檢查，比如數組越界、指針是否合法、運算結果是否溢出等等。這就造成了很多編譯正確但執行奇怪的程序。

C語言足夠靈活，對于一個數組test[30]，它允許使用像test[-1]這樣的形式來快速獲取數組首元素所在地址前面的數據；允許將一個常數強制轉換為函數指針，使用代碼(*((void(*)())0))()來調用位于0地址的函數。C語言給了程序員足夠的自由，但也由程序員承擔濫用自由帶來的責任。

3.2.1莫名的死機

下面的兩個例子都是死循環，如果在不常用分支中出現類似代碼，將會造成看似莫名其妙的死機或者重啟。

1.unsignedchari；//例程1

2.for(i=0;i<256;i++)??????

3.{

4.//其它代碼

5.}

1.unsignedchari;//例程2

2.for(i=10;i>=0;i--)

3.{

4.//其它代碼

5.}

對于無符號char類型，表示的范圍為0~255，所以無符號char類型變量i永遠小于256（第一個for循環無限執行），永遠大于等于0（第二個for循環無線執行）。需要說明的是，賦值代碼i=256是被C語言允許的，即使這個初值已經超出了變量i可以表示的范圍。C語言會千方百計的為程序員創造出錯的機會，可見一斑。

3.2.2不起眼的改變

假如你在if語句后誤加了一個分號，可能會完全改變了程序邏輯。編譯器也會很配合的幫忙掩蓋，甚至連警告都不提示。代碼如下：

1.if(a>b);//這里誤加了一個分號

2.a=b;//這句代碼一直被執行

不但如此，編譯器還會忽略掉多余的空格符和換行符，就像下面的代碼也不會給出足夠提示：

1.if(n<3)????

2.return//這里少加了一個分號

3.logrec.data=x[0];

4.logrec.time=x[1];

5.logrec.code=x[2];

這段代碼的本意是n<3時程序直接返回，由于程序員的失誤，return少了一個結束分號。編譯器將它翻譯成返回表達式logrec.data=x[0]的結果，return后面即使是一個表達式也是C語言允許的。這樣當n>=3時，表達式logrec.data=x[0];就不會被執行，給程序埋下了隱患。

3.2.3 難查的數組越界

上文曾提到數組常常是引起程序不穩定的重要因素，程序員往往不經意間就會寫數組越界。

一位同事的代碼在硬件上運行，一段時間后就會發現LCD顯示屏上的一個數字不正常的被改變。經過一段時間的調試，問題被定位到下面的一段代碼中：

1.intSensorData[30];

2.//其他代碼

3.for(i=30;i>0;i--)

4.{

5.SensorData[i]=…;

6.//其他代碼

7.}

這里聲明了擁有30個元素的數組，不幸的是for循環代碼中誤用了本不存在的數組元素SensorData[30]，但C語言卻默許這么使用，并欣然的按照代碼改變了數組元素SensorData[30]所在位置的值， SensorData[30]所在的位置原本是一個LCD顯示變量，這正是顯示屏上的那個值不正常被改變的原因。真慶幸這么輕而易舉的發現了這個Bug。

其實很多編譯器會對上述代碼產生一個警告：賦值超出數組界限。但并非所有程序員都對編譯器警告保持足夠敏感，況且，編譯器也并不能檢查出數組越界的所有情況。比如下面的例子：

你在模塊A中定義數組：

1.intSensorData[30];

在模塊B中引用該數組，但由于你引用代碼并不規范，這里沒有顯示聲明數組大小，但編譯器也允許這么做：

1.externintSensorData[];

這次，編譯器不會給出警告信息，因為編譯器壓根就不知道數組的元素個數。所以，當一個數組聲明為具有外部鏈接，它的大小應該顯式聲明。

再舉一個編譯器檢查不出數組越界的例子。函數func()的形參是一個數組形式，函數代碼簡化如下所示：

1.char*func(charSensorData[30])

2.{

3.unsignedinti；

4.for(i=30;i>0;i--)

5.{

6.SensorData[i]=…;

7.//其他代碼

8.}

9.}

這個給SensorData[30]賦初值的語句，編譯器也是不給任何警告的。實際上，編譯器是將數組名Sensor隱含的轉化為指向數組第一個元素的指針，函數體是使用指針的形式來訪問數組的，它當然也不會知道數組元素的個數了。造成這種局面的原因之一是C編譯器的作者們認為指針代替數組可以提高程序效率，而且，可以簡化編譯器的復雜度。

指針和數組是容易給程序造成混亂的，我們有必要仔細的區分它們的不同。其實換一個角度想想，它們也是容易區分的：可以將數組名等同于指針的情況有且只有一處，就是上面例子提到的數組作為函數形參時。其它時候，數組名是數組名，指針是指針。

下面的例子編譯器同樣檢查不出數組越界。

我們常常用數組來緩存通訊中的一幀數據。在通訊中斷中將接收的數據保存到數組中，直到一幀數據完全接收后再進行處理。即使定義的數組長度足夠長，接收數據的過程中也可能發生數組越界，特別是干擾嚴重時。這是由于外界的干擾破壞了數據幀的某些位，對一幀的數據長度判斷錯誤，接收的數據超出數組范圍，多余的數據改寫與數組相鄰的變量，造成系統崩潰。由于中斷事件的異步性，這類數組越界編譯器無法檢查到。

如果局部數組越界，可能引發ARM架構硬件異常。

同事的一個設備用于接收無線傳感器的數據，一次軟件升級后，發現接收設備工作一段時間后會死機。調試表明ARM7處理器發生了硬件異常，異常處理代碼是一段死循環（死機的直接原因）。接收設備有一個硬件模塊用于接收無線傳感器的整包數據并存在自己的緩沖區中，當硬件模塊接收數據完成后，使用外部中斷通知設備取數據，外部中斷服務程序精簡后如下所示：

1.__irqExintHandler(void)

2.{

3.unsignedcharDataBuf[50];

4.GetData(DataBug);//從硬件緩沖區取一幀數據

5.//其他代碼

6.}

由于存在多個無線傳感器近乎同時發送數據的可能加之GetData()函數保護力度不夠，數組DataBuf在取數據過程中發生越界。由于數組DataBuf為局部變量，被分配在堆棧中，同在此堆棧中的還有中斷發生時的運行環境以及中斷返回地址。溢出的數據將這些數據破壞掉，中斷返回時PC指針可能變成一個不合法值，硬件異常由此產生。

如果我們精心設計溢出部分的數據，化數據為指令，就可以利用數組越界來修改PC指針的值，使之指向我們希望執行的代碼。

1988年，第一個網絡蠕蟲在一天之內感染了2000到6000臺計算機，這個蠕蟲程序利用的正是一個標準輸入庫函數的數組越界Bug。起因是一個標準輸入輸出庫函數gets()，原來設計為從數據流中獲取一段文本，遺憾的是，gets()函數沒有規定輸入文本的長度。gets()函數內部定義了一個500字節的數組，攻擊者發送了大于500字節的數據，利用溢出的數據修改了堆棧中的PC指針，從而獲取了系統權限。目前，雖然有更好的庫函數來代替gets函數，但gets函數仍然存在著。

3.2.4神奇的volatile

做嵌入式設備開發，如果不對volatile修飾符具有足夠了解，實在是說不過去。volatile是C語言32個關鍵字中的一個，屬于類型限定符，常用的const關鍵字也屬于類型限定符。

volatile限定符用來告訴編譯器，該對象的值無任何持久性，不要對它進行任何優化；它迫使編譯器每次需要該對象數據內容時都必須讀該對象，而不是只讀一次數據并將它放在寄存器中以便后續訪問之用（這樣的優化可以提高系統速度）。

這個特性在嵌入式應用中很有用，比如你的IO口的數據不知道什么時候就會改變，這就要求編譯器每次都必須真正的讀取該IO端口。這里使用了詞語“真正的讀”，是因為由于編譯器的優化，你的邏輯反應到代碼上是對的，但是代碼經過編譯器翻譯后，有可能與你的邏輯不符。你的代碼邏輯可能是每次都會讀取IO端口數據，但實際上編譯器將代碼翻譯成匯編時，可能只是讀一次IO端口數據并保存到寄存器中，接下來的多次讀IO口都是使用寄存器中的值來進行處理。因為讀寫寄存器是最快的，這樣可以優化程序效率。與之類似的，中斷里的變量、多線程中的共享變量等都存在這樣的問題。

不使用volatile，可能造成運行邏輯錯誤，但是不必要的使用volatile會造成代碼效率低下（編譯器不優化volatile限定的變量），因此清楚的知道何處該使用volatile限定符，是一個嵌入式程序員的必修內容。

一個程序模塊通常由兩個文件組成，源文件和頭文件。如果你在源文件定義變量：

1.unsignedinttest;

并在頭文件中聲明該變量：

1.externunsignedlongtest;

編譯器會提示一個語法錯誤：變量’ test’聲明類型不一致。但如果你在源文件定義變量：

1.volatileunsignedinttest;

在頭文件中這樣聲明變量：

1.externunsignedinttest;/*缺少volatile限定符*/

編譯器卻不會給出錯誤信息（有些編譯器僅給出一條警告）。當你在另外一個模塊（該模塊包含聲明變量test的頭文件）使用變量test時，它已經不再具有volatile限定，這樣很可能造成一些重大錯誤。比如下面的例子，注意該例子是為了說明volatile限定符而專門構造出的，因為現實中的volatile使用Bug大都隱含，并且難以理解。

在模塊A的源文件中，定義變量：

1.volatileunsignedintTimerCount=0;

該變量用來在一個定時器中斷服務程序中進行軟件計時：

1.TimerCount++;

在模塊A的頭文件中，聲明變量：

1.externunsignedintTimerCount;//這里漏掉了類型限定符volatile

在模塊B中，要使用TimerCount變量進行精確的軟件延時：

1.#include“…A.h”//首先包含模塊A的頭文件

2.//其他代碼

3.TimerCount=0;

4.while(TimerCount<=TIMER_VALUE);???//延時一段時間(感謝網友chhfish指出這里的邏輯錯誤)????

5.//其他代碼

實際上，這是一個死循環。由于模塊A頭文件中聲明變量TimerCount時漏掉了volatile限定符，在模塊B中，變量TimerCount是被當作unsigned int類型變量。由于寄存器速度遠快于RAM，編譯器在使用非volatile限定變量時是先將變量從RAM中拷貝到寄存器中，如果同一個代碼塊再次用到該變量，就不再從RAM中拷貝數據而是直接使用之前寄存器備份值。代碼while(TimerCount<=TIMER_VALUE)中，變量TimerCount僅第一次執行時被使用，之后都是使用的寄存器備份值，而這個寄存器值一直為0，所以程序無限循環。圖3-1的流程圖說明了程序使用限定符volatile和不使用volatile的執行過程。

為了更容易的理解編譯器如何處理volatile限定符，這里給出未使用volatile限定符和使用volatile限定符程序的反匯編代碼：

沒有使用關鍵字volatile，在keil MDK V4.54下編譯，默認優化級別，如下所示（注意最后兩行）：

可以看到，如果沒有使用volatile關鍵字，程序一直比較R0內數據與0xC8是否相等，但R0中的數據是0，所以程序會一直在這里循環比較（死循環）；再看使用了volatile關鍵字的反匯編代碼，程序會先從變量中讀出數據放到R1寄存器中，然后再讓R1內數據與0xC8相比較，這才是我們C代碼的正確邏輯！

3.2.5局部變量

ARM架構下的編譯器會頻繁的使用堆棧，堆棧用于存儲函數的返回值、AAPCS規定的必須保護的寄存器以及局部變量，包括局部數組、結構體、聯合體和C++的類。默認情況下，堆棧的位置、初始值都是由編譯器設置，因此需要對編譯器的堆棧有一定了解。從堆棧中分配的局部變量的初值是不確定的，因此需要運行時顯式初始化該變量。一旦離開局部變量的作用域，這個變量立即被釋放，其它代碼也就可以使用它，因此堆棧中的一個內存位置可能對應整個程序的多個變量。

局部變量必須顯式初始化，除非你確定知道你要做什么。下面的代碼得到的溫度值跟預期會有很大差別，因為在使用局部變量sum時，并不能保證它的初值為0。編譯器會在第一次運行時清零堆棧區域，這加重了此類Bug的隱蔽性。

由于一旦程序離開局部變量的作用域即被釋放，所以下面代碼返回指向局部變量的指針是沒有實際意義的，該指針指向的區域可能會被其它程序使用，其值會被改變。

3.2.6使用外部工具

由于編譯器的語義檢查比較弱，我們可以使用第三方代碼分析工具，使用這些工具來發現潛在的問題，這里介紹其中比較著名的是PC-Lint。

PC-Lint由Gimpel Software公司開發，可以檢查C代碼的語法和語義并給出潛在的BUG報告。PC-Lint可以顯著降低調試時間。

目前公司ARM7和Cortex-M3內核多是使用Keil MDK編譯器來開發程序，通過簡單配置，PC-Lint可以被集成到MDK上，以便更方便的檢查代碼。MDK已經提供了PC-Lint的配置模板，所以整個配置過程十分簡單，Keil MDK開發套件并不包含PC-Lint程序，在此之前，需要預先安裝可用的PC-Lint程序，配置過程如下：

1)點擊菜單Tools---Set-up PC-Lint…

PC-Lint Include Folders：該列表路徑下的文件才會被PC-Lint檢查，此外，這些路徑下的文件內使用#include包含的文件也會被檢查；

Lint Executable：指定PC-Lint程序的路徑

Configuration File：指定配置文件的路徑，該配置文件由MDK編譯器提供。

2)菜單Tools---Lint 文件路徑.c/.h

檢查當前文件。

3)菜單Tools---Lint All C-Source Files

檢查所有C源文件。

PC-Lint的輸出信息顯示在MDK編譯器的Build Output窗口中，雙擊其中的一條信息可以跳轉到源文件所在位置。

編譯器語義檢查的弱小在很大程度上助長了不可靠代碼的廣泛存在。隨著時代的進步，現在越來越多的編譯器開發商意識到了語義檢查的重要性，編譯器的語義檢查也越來越強大，比如公司使用的Keil MDK編譯器，雖然它的編輯器依然不盡人意，但在其 V4.47及以上版本中增加了動態語法檢查并加強了語義檢查，可以友好的提示更多警告信息。建議經常關注編譯器官方網站并將編譯器升級到V4.47或以上版本，升級的另一個好處是這些版本的編輯器增加了標識符自動補全功能，可以大大節省編碼的時間。

3.3你覺得有意義的代碼未必正確

C語言標準特別的規定某些行為是未定義的，編寫未定義行為的代碼，其輸出結果由編譯器決定！ C標準委員會定義未定義行為的原因如下：

簡化標準，并給予實現一定的靈活性，比如不捕捉那些難以診斷的程序錯誤；

編譯器開發商可以通過未定義行為對語言進行擴展

C語言的未定義行為，使得C極度高效靈活并且給編譯器實現帶來了方便，但這并不利于優質嵌入式C程序的編寫。因為許多 C 語言中看起來有意義的東西都是未定義的，并且這也容易使你的代碼埋下隱患，并且不利于跨編譯器移植。Java程序會極力避免未定義行為，并用一系列手段進行運行時檢查，使用Java可以相對容易的寫出安全代碼，但體積龐大效率低下。作為嵌入式程序員，我們需要了解這些未定義行為，利用C語言的靈活性，寫出比Java更安全、效率更高的代碼來。

3.3.1常見的未定義行為

1)自增自減在表達式中連續出現并作用于同一變量或者自增自減在表達式中出現一次，但作用的變量多次出現

自增（++）和自減（--）這一動作發生在表達式的哪個時刻是由編譯器決定的，比如：

1.r=1*a[i++]+2*a[i++]+3*a[i++];

不同的編譯器可能有著不同的匯編代碼，可能是先執行i++再進行乘法和加法運行，也可能是先進行加法和乘法運算，再執行i++，因為這句代碼在一個表達式中出現了連續的自增并作用于同一變量。更加隱蔽的是自增自減在表達式中出現一次，但作用的變量多次出現，比如：

1.a[i]=i++;/*未定義行為*/

先執行i++再賦值，還是先賦值再執行i++是由編譯器決定的，而兩種不同的執行順序的結果差別是巨大的。

2)函數實參被求值的順序

函數如果有多個實參，這些實參的求值順序是由編譯器決定的，比如：

1.printf("%d%d\n",++n,power(2,n));/*未定義行為*/

是先執行++n還是先執行power(2,n)是由編譯器決定的。

3)有符號整數溢出

有符號整數溢出是未定義的行為，編譯器決定有符號整數溢出按照哪種方式取值。比如下面代碼：

1.intvalue1,value2,sum

2.

3.//其它操作

4.sum=value1+value;/*sum可能發生溢出*/

4)有符號數右移、移位的數量是負值或者大于操作數的位數

5)除數為零

6)malloc()、calloc()或realloc()分配零字節內存

3.3.2如何避免C語言未定義行為

代碼中引入未定義行為會為代碼埋下隱患，防止代碼中出現未定義行為是困難的，我們總能不經意間就會在代碼中引入未定義行為。但是還是有一些方法可以降低這種事件，總結如下：

了解C語言未定義行為

標準C99附錄J.2“未定義行為”列舉了C99中的顯式未定義行為，通過查看該文檔，了解那些行為是未定義的，并在編碼中時刻保持警惕；

尋求工具幫助

編譯器警告信息以及PC-Lint等靜態檢查工具能夠發現很多未定義行為并警告，要時刻關注這些工具反饋的信息；

總結并使用一些編碼標準

1）避免構造復雜的自增或者自減表達式，實際上，應該避免構造所有復雜表達式；

比如a[i]=i++;語句可以改為a[i]=i; i++;這兩句代碼。

2）只對無符號操作數使用位操作；

必要的運行時檢查

檢查是否溢出、除數是否為零，申請的內存數量是否為零等等，比如上面的有符號整數溢出例子，可以按照如下方式編寫，以消除未定義特性：

上面的代碼是通用的，不依賴于任何CPU架構，但是代碼效率很低。如果是有符號數使用補碼的CPU架構（目前常見CPU絕大多數都是使用補碼），還可以用下面的代碼來做溢出檢查：

使用的原理解釋一下，因為在加法運算中，操作數value1和value2只有符號相同時，才可能發生溢出，所以我們先將這兩個數轉換為無符號類型，兩個數的和保存在變量usum中。如果發生溢出，則value1、value2和usum的最高位（符號位）一定不同，表達式(usum ^ value1) & (usum ^ value2) 的最高位一定為1，這個表達式位與（&）上INT_MIN是為了將最高位之外的其它位設置為0。

了解你所用的編譯器對未定義行為的處理策略

很多引入了未定義行為的程序也能運行良好，這要歸功于編譯器處理未定義行為的策略。不是你的代碼寫的正確，而是恰好編譯器處理策略跟你需要的邏輯相同。了解編譯器的未定義行為處理策略，可以讓你更清楚的認識到那些引入了未定義行為程序能夠運行良好是多么幸運的事，不然多換幾個編譯器試試！

以Keil MDK為例，列舉常用的處理策略如下：

1）有符號量的右移是算術移位，即移位時要保證符號位不改變。

2）對于int類的值：超過31位的左移結果為零；無符號值或正的有符號值超過31位的右移結果為零。負的有符號值移位結果為-1。

3）整型數除以零返回零

3.4 了解你的編譯器

在嵌入式開發過程中，我們需要經常和編譯器打交道，只有深入了解編譯器，才能用好它，編寫更高效代碼，更靈活的操作硬件，實現一些高級功能。下面以公司最常用的Keil MDK為例，來描述一下編譯器的細節。

3.4.1編譯器的一些小知識

1)默認情況下，char類型的數據項是無符號的，所以它的取值范圍是0～255；

2)在所有的內部和外部標識符中，大寫和小寫字符不同；

3)通常局部變量保存在寄存器中，但當局部變量太多放到棧里的時候，它們總是字對齊的。

4)壓縮類型的自然對齊方式為1。使用關鍵字__packed來壓縮特定結構，將所有有效類型的對齊邊界設置為1；

5)整數以二進制補碼形式表示；浮點量按IEEE格式存儲；

6)整數除法的余數的符號于被除數相同，由ISO C90標準得出；

7)如果整型值被截斷為短的有符號整型，則通過放棄適當數目的最高有效位來得到結果。如果原始數是太大的正或負數，對于新的類型，無法保證結果的符號將于原始數相同。

8)整型數超界不引發異常；像unsigned char test; test=1000;這類是不會報錯的；

9)在嚴格C中，枚舉值必須被表示為整型。例如，必須在?2147483648 到+2147483647的范圍內。但MDK自動使用對象包含enum范圍的最小整型來實現（比如char類型），除非使用編譯器命令??enum_is_int 來強制將enum的基礎類型設為至少和整型一樣寬。超出范圍的枚舉值默認僅產生警告：#66:enumeration value is out of "int" range；

10)對于結構體填充，根據定義結構的方式，keil MDK編譯器用以下方式的一種來填充結構：

I> 定義為static或者extern的結構用零填充；

II> 棧或堆上的結構，例如，用malloc()或者auto定義的結構，使用先前存儲在那些存儲器位置的任何內容進行填充。不能使用memcmp()來比較以這種方式定義的填充結構！

11)編譯器不對聲明為volatile類型的數據進行優化；

12)__nop()：延時一個指令周期，編譯器絕不會優化它。如果硬件支持NOP指令，則該句被替換為NOP指令，如果硬件不支持NOP指令，編譯器將它替換為一個等效于NOP的指令，具體指令由編譯器自己決定；

13)__align(n)：指示編譯器在n 字節邊界上對齊變量。對于局部變量，n的值為1、2、4、8；

14)__attribute__((at(address)))：可以使用此變量屬性指定變量的絕對地址；

15)__inline：提示編譯器在合理的情況下內聯編譯C或C++ 函數；

3.4.2初始化的全局變量和靜態變量的初始值被放到了哪里？

我們程序中的一些全局變量和靜態變量在定義時進行了初始化，經過編譯器編譯后，這些初始值被存放在了代碼的哪里？我們舉個例子說明：

1.unsignedintg_unRunFlag=0xA5；

2.staticunsignedints_unCountFlag=0x5A；

我曾做過一個項目，項目中的一個設備需要在線編程，也就是通過協議，將上位機發給設備的數據通過在應用編程（IAP）技術寫入到設備的內部Flash中。我將內部Flash做了劃分，一小部分運行程序，大部分用來存儲上位機發來的數據。隨著程序量的增加，在一次更新程序后發現，在線編程之后，設備運行正常，但是重啟設備后，運行出現了故障！經過一系列排查，發現故障的原因是一個全局變量的初值被改變了。這是件很不可思議的事情，你在定義這個變量的時候指定了初始值，當你在第一次使用這個變量時卻發現這個初值已經被改掉了！這中間沒有對這個變量做任何賦值操作，其它變量也沒有任何溢出，并且多次在線調試表明，進入main函數的時候，該變量的初值已經被改為一個恒定值。

要想知道為什么全局變量的初值被改變，就要了解這些初值編譯后被放到了二進制文件的哪里。在此之前，需要先了解一點鏈接原理。

ARM映象文件各組成部分在存儲系統中的地址有兩種：一種是映象文件位于存儲器時（通俗的說就是存儲在Flash中的二進制代碼）的地址，稱為加載地址；一種是映象文件運行時（通俗的說就是給板子上電，開始運行Flash中的程序了）的地址，稱為運行時地址。賦初值的全局變量和靜態變量在程序還沒運行的時候，初值是被放在Flash中的，這個時候他們的地址稱為加載地址，當程序運行后，這些初值會從Flash中拷貝到RAM中，這時候就是運行時地址了。

原來，對于在程序中賦初值的全局變量和靜態變量，程序編譯后，MDK將這些初值放到Flash中，位于緊靠在可執行代碼的后面。在程序進入main函數前，會運行一段庫代碼，將這部分數據拷貝至相應RAM位置。由于我的設備程序量不斷增加，超過了為設備程序預留的Flash空間，在線編程時，將一部分存儲全局變量和靜態變量初值的Flash給重新編程了。在重啟設備前，初值已經被拷貝到RAM中，所以這個時候程序運行是正常的，但重新上電后，這部分初值實際上是在線編程的數據，自然與初值不同了。

3.4.3在C代碼中使用的變量，編譯器將他們分配到RAM的哪里？

我們會在代碼中使用各種變量，比如全局變量、靜態變量、局部變量，并且這些變量時由編譯器統一管理的，有時候我們需要知道變量用掉了多少RAM，以及這些變量在RAM中的具體位置。這是一個經常會遇到的事情，舉一個例子，程序中的一個變量在運行時總是不正常的被改變，那么有理由懷疑它臨近的變量或數組溢出了，溢出的數據更改了這個變量值。要排查掉這個可能性，就必須知道該變量被分配到RAM的哪里、這個位置附近是什么變量，以便針對性的做跟蹤。

其實MDK編譯器的輸出文件中有一個“工程名.map”文件，里面記錄了代碼、變量、堆棧的存儲位置，通過這個文件，可以查看使用的變量被分配到RAM的哪個位置。要生成這個文件，需要在Options for Targer窗口，Listing標簽欄下，勾選Linker Listing前的復選框，如圖3-1所示。

圖3-1 設置編譯器生產MAP文件

3.4.4默認情況下，棧被分配到RAM的哪個地方？

MDK中，我們只需要在配置文件中定義堆棧大小，編譯器會自動在RAM的空閑區域選擇一塊合適的地方來分配給我們定義的堆棧，這個地方位于RAM的那個地方呢？

通過查看MAP文件，原來MDK將堆棧放到程序使用到的RAM空間的后面，比如你的RAM空間從0x4000 0000開始，你的程序用掉了0x200字節RAM，那么堆棧空間就從0x4000 0200處開始。

使用了多少堆棧，是否溢出?

2.4.5 有多少RAM會被初始化？

在進入main()函數之前，MDK會把未初始化的RAM給清零的，我們的RAM可能很大，只使用了其中一小部分，MDK會不會把所有RAM都初始化呢？

答案是否定的，MDK只是把你的程序用到的RAM以及堆棧RAM給初始化，其它RAM的內容是不管的。如果你要使用絕對地址訪問MDK未初始化的RAM，那就要小心翼翼的了，因為這些RAM上電時的內容很可能是隨機的，每次上電都不同。

3.4.6 MDK編譯器如何設置非零初始化變量？

對于控制類產品，當系統復位后（非上電復位），可能要求保持住復位前RAM中的數據，用來快速恢復現場，或者不至于因瞬間復位而重啟現場設備。而keil mdk在默認情況下，任何形式的復位都會將RAM區的非初始化變量數據清零。

MDK編譯程序生成的可執行文件中，每個輸出段都最多有三個屬性：RO屬性、RW屬性和ZI屬性。對于一個全局變量或靜態變量，用const修飾符修飾的變量最可能放在RO屬性區，初始化的變量會放在RW屬性區，那么剩下的變量就要放到ZI屬性區了。默認情況下，ZI屬性區的數據在每次復位后，程序執行main函數內的代碼之前，由編譯器“自作主張”的初始化為零。所以我們要在C代碼中設置一些變量在復位后不被零初始化，那一定不能任由編譯器“胡作非為”，我們要用一些規則，約束一下編譯器。

分散加載文件對于連接器來說至關重要，在分散加載文件中，使用UNINIT來修飾一個執行節，可以避免編譯器對該區節的ZI數據進行零初始化。這是要解決非零初始化變量的關鍵。因此我們可以定義一個UNINIT修飾的數據節，然后將希望非零初始化的變量放入這個區域中。于是，就有了第一種方法：

1)修改分散加載文件，增加一個名為MYRAM的執行節，該執行節起始地址為0x1000A000，長度為0x2000字節（8KB），由UNINIT修飾：

變量屬性修飾符__attribute__((at(adde)))用來將變量強制定位到adde所在地址處。由于地址0x1000A000開始的8KB區域ZI變量不會被零初始化，所以位于這一區域的數組plc_eu_backup也就不會被零初始化了。

這種方法的缺點是顯而易見的：要程序員手動分配變量的地址。如果非零初始化數據比較多，這將是件難以想象的大工程（以后的維護、增加、修改代碼等等）。所以要找到一種辦法，讓編譯器去自動分配這一區域的變量。

2)分散加載文件同方法1，如果還是定義一個數組，可以用下面方法：

unsignedcharplc_eu_backup[32]__attribute__((section("NO_INIT"),zero_init));

變量屬性修飾符__attribute__((section(“name”),zero_init))用于將變量強制定義到name屬性數據節中，zero_init表示將未初始化的變量放到ZI數據節中。因為“NO_INIT”這顯性命名的自定義節，具有UNINIT屬性。

3)將一個模塊內的非初始化變量都非零初始化

假如該模塊名字為test.c，修改分散加載文件如下所示：

在該模塊定義時變量時使用如下方法：

這里，變量屬性修飾符__attribute__((zero_init))用于將未初始化的變量放到ZI數據節中變量，其實MDK默認情況下，未初始化的變量就是放在ZI數據區的。

4.防御性編程

嵌入式產品的可靠性自然與硬件密不可分，但在硬件確定、并且沒有第三方測試的前提下，使用防御性編程思想寫出的代碼，往往具有更高的穩定性。

防御性編程首先需要認清C語言的種種缺陷和陷阱，C語言對于運行時的檢查十分弱小，需要程序員謹慎的考慮代碼，在必要的時候增加判斷；防御性編程的另一個核心思想是假設代碼運行在并不可靠的硬件上，外接干擾有可能會打亂程序執行順序、更改RAM存儲數據等等。

4.1具有形參的函數，需判斷傳遞來的實參是否合法。

程序員可能無意識的傳遞了錯誤參數；外界的強干擾可能將傳遞的參數修改掉，或者使用隨機參數意外的調用函數，因此在執行函數主體前，需要先確定實參是否合法。

4.2仔細檢查函數的返回值

對函數返回的錯誤碼，要進行全面仔細處理，必要時做錯誤記錄。

4.3 防止指針越界

如果動態計算一個地址時，要保證被計算的地址是合理的并指向某個有意義的地方。特別對于指向一個結構或數組的內部的指針，當指針增加或者改變后仍然指向同一個結構或數組。

4.4 防止數組越界

數組越界的問題前文已經講述的很多了，由于C不會對數組進行有效的檢測，因此必須在應用中顯式的檢測數組越界問題。下面的例子可用于中斷接收通訊數據。

在使用一些庫函數時，同樣需要對邊界進行檢查，比如下面的memset(RecBuf,0,len)函數把RecBuf指指向的內存區的前len個字節用0填充，如果不注意len的長度，就會將數組RecBuf之外的內存區清零：

4.5 數學算數運算

4.5.1除法運算，只檢測除數為零就可靠嗎？

除法運算前，檢查除數是否為零幾乎已經成為共識，但是僅檢查除數是否為零就夠了嗎？

考慮兩個整數相除，對于一個signed long類型變量，它能表示的數值范圍為：-2147483648 ~+2147483647，如果讓-2147483648/ -1，那么結果應該是+2147483648，但是這個結果已經超出了signedlong所能表示的范圍了。所以，在這種情況下，除了要檢測除數是否為零外，還要檢測除法是否溢出。

4.5.2檢測運算溢出

整數的加減乘運算都有可能發生溢出，在討論未定義行為時，給出過一個有符號整形加法溢出判斷代碼，這里再給出一個無符號整形加法溢出判斷代碼段：

嵌入式硬件一般沒有浮點處理器，浮點數運算在嵌入式也比較少見并且溢出判斷嚴重依賴C庫支持，這里不討論。

4.5.3檢測移位

在討論未定義行為時，提到有符號數右移、移位的數量是負值或者大于操作數的位數都是未定義行為，也提到不對有符號數進行位操作，但要檢測移位的數量是否大于操作數的位數。下面給出一個無符號整數左移檢測代碼段：

4.6如果有硬件看門狗，則使用它

在其它一切措施都失效的情況下，看門狗可能是最后的防線。它的原理特別簡單，但卻能大大提高設備的可靠性。如果設備有硬件看門狗，一定要為它編寫驅動程序。

要盡可能早的開啟看門狗

這是因為從上電復位結束到開啟看門狗的這段時間內，設備有可能被干擾而跳過看門狗初始化程序，導致看門狗失效。盡可能早的開啟看門狗，可以降低這種概率；

不要在中斷中喂狗，除非有其他聯動措施

在中斷程序喂狗，由于干擾的存在，程序可能一直處于中斷之中，這樣會導致看門狗失效。如果在主程序中設置標志位，中斷程序喂狗時與這個標志位聯合判斷，也是允許的；

喂狗間隔跟產品需求有關，并非特定的時間

產品的特性決定了喂狗間隔。對于不涉及安全性、實時性的設備，喂狗間隔比較寬松，但間隔時間不宜過長，否則被用戶感知到，是影響用戶體驗的。對于設計安全性、有實時控制類的設備，原則是盡可能快的復位，否則會造成事故。

4.7關鍵數據儲存多個備份，取數據采用“表決法”

RAM中的數據在受到干擾情況下有可能被改變，對于系統關鍵數據應該進行保護。關鍵數據包括全局變量、靜態變量以及需要保護的數據區域。備份數據與原數據不應該處于相鄰位置，因此不應由編譯器默認分配備份數據位置，而應該由程序員指定區域存儲。可以將RAM分為3個區域，第一個區域保存原碼，第二個區域保存反碼，第三個區域保存異或碼，區域之間預留一定量的“空白”RAM作為隔離。可以使用編譯器的“分散加載”機制將變量分別存儲在這些區域。需要進行讀取時，同時讀出3份數據并進行表決，取至少有兩個相同的那個值。

假如設備的RAM從0x1000_0000開始，我需要在RAM的0x1000_0000~0x10007FFF內存儲原碼，在0x1000_9000~0x10009FFF內存儲反碼，在0x1000_B000~0x1000BFFF內存儲0xAA的異或碼，編譯器的分散加載可以設置為：

如果一個關鍵變量需要多處備份，可以按照下面方式定義變量，將三個變量分別指定到三個不連續的RAM區中，并在定義時按照原碼、反碼、0xAA的異或碼進行初始化。

當需要寫這個變量時，這三個位置都要更新；讀取變量時，讀取三個值做判斷，取至少有兩個相同的那個值。

為什么選取異或碼而不是補碼？這是因為MDK的整數是按照補碼存儲的，正數的補碼與原碼相同，在這種情況下，原碼和補碼是一致的，不但起不到冗余作用，反而對可靠性有害。比如存儲的一個非零整數區因為干擾，RAM都被清零，由于原碼和補碼一致，按照3取2的“表決法”，會將干擾值0當做正確的數據。

4.8對非易失性存儲器進行備份存儲

非易失性存儲器包括但不限于Flash、EEPROM、鐵電。僅僅將寫入非易失性存儲器中的數據再讀出校驗是不夠的。強干擾情況下可能導致非易失性存儲器內的數據錯誤，在寫非易失性存儲器的期間系統掉電將導致數據丟失，因干擾導致程序跑飛到寫非易失性存儲器函數中，將導致數據存儲紊亂。一種可靠的辦法是將非易失性存儲器分成多個區，每個數據都將按照不同的形式寫入到這些分區中，需要進行讀取時，同時讀出多份數據并進行表決，取相同數目較多的那個值。

4.9軟件鎖

對于初始化序列或者有一定先后順序的函數調用，為了保證調用順序或者確保每個函數都被調用，我們可以使用環環相扣，實質上這也是一種軟件鎖。此外對于一些安全關鍵代碼語句（是語句，而不是函數），可以給它們設置軟件鎖，只有持有特定鑰匙的，才可以訪問這些關鍵代碼。也可以通俗的理解為，關鍵安全代碼不能按照單一條件執行，要額外的多設置一個標志。

比如，向Flash寫一個數據，我們會判斷數據是否合法、寫入的地址是否合法，計算要寫入的扇區。之后調用寫Flash子程序，在這個子程序中，判斷扇區地址是否合法、數據長度是否合法，之后就要將數據寫入Flash。由于寫Flash語句是安全關鍵代碼，所以程序給這些語句上鎖：必須具有正確的鑰匙才可以寫Flash。這樣即使是程序跑飛到寫Flash子程序，也能大大降低誤寫的風險。

該程序段是編程lpc1778內部Flash，其中調用IAP程序的函數iap_entry(paramin,paramout)是關鍵安全代碼，所以在執行該代碼前，先判斷一個特定設置的安全鎖標志ProgStart，只有這個標志符合設定值，才會執行編程Flash操作。如果因為意外程序跑飛到該函數，由于ProgStart標志不正確，是不會對Flash進行編程的。

4.10通信

通訊線上的數據誤碼相對嚴重，通訊線越長，所處的環境越惡劣，誤碼會越嚴重。拋開硬件和環境的作用，我們的軟件應能識別錯誤的通訊數據。對此有一些應用措施：

制定協議時，限制每幀的字節數；

每幀字節數越多，發生誤碼的可能性就越大，無效的數據也會越多。對此以太網規定每幀數據不大于1500字節，高可靠性的CAN收發器規定每幀數據不得多于8字節，對于RS485，基于RS485鏈路應用最廣泛的Modbus協議一幀數據規定不超過256字節。因此，建議制定內部通訊協議時，使用RS485時規定每幀數據不超過256字節；

使用多種校驗

編寫程序時應使能奇偶校驗，每幀超過16字節的應用，建議至少編寫CRC16校驗程序；

增加額外判斷

1)增加緩沖區溢出判斷。這是因為數據接收多是在中斷中完成，編譯器檢測不出緩沖區是否溢出，需要手動檢查，在上文介紹數據溢出一節中已經詳細說明。

2)增加超時判斷。當一幀數據接收到一半，長時間接收不到剩余數據，則認為這幀數據無效，重新開始接收。可選，跟不同的協議有關，但緩沖區溢出判斷必須實現。這是因為對于需要幀頭判斷的協議，上位機可能發送完幀頭后突然斷電，重啟后上位機是從新的幀開始發送的，但是下位機已經接收到了上次未發送完的幀頭，所以上位機的這次幀頭會被下位機當成正常數據接收。這有可能造成數據長度字段為一個很大的值，填滿該長度的緩沖區需要相當多的數據（比如一幀可能1000字節），影響響應時間；另一方面，如果程序沒有緩沖區溢出判斷，那么緩沖區很可能溢出，后果是災難性的。

重傳機制

如果檢測到通訊數據發生了錯誤，則要有重傳機制重新發送出錯的幀。

4.11開關量輸入的檢測、確認

開關量容易受到尖脈沖干擾，如果不進行濾除，可能會造成誤動作。一般情況下，需要對開關量輸入信號進行多次采樣，并進行邏輯判斷直到確認信號無誤為止。

4.12開關量輸出

開關信號簡單的一次輸出是不安全的，干擾信號可能會翻轉開關量輸出的狀態。采取重復刷新輸出可以有效防止電平的翻轉。

4.13初始化信息的保存和恢復

微處理器的寄存器值也可能會因外界干擾而改變，外設初始化值需要在寄存器中長期保存，最容易被破壞。由于Flash中的數據相對不易被破壞，可以將初始化信息預先寫入Flash，待程序空閑時比較與初始化相關的寄存器值是否被更改，如果發現非法更改則使用Flash中的值進行恢復。

公司目前使用的4.3寸LCD顯示屏抗干擾能力一般。如果顯示屏與控制器之間的排線距離過長或者對使用該顯示屏的設備打靜電或者脈沖群，顯示屏有可能會花屏或者白屏。對此，我們可以將初始化顯示屏的數據保存在Flash中，程序運行后，每隔一段時間從顯示屏的寄存器讀出當前值和Flash存儲的值相比較，如果發現兩者不同，則重新初始化顯示屏。下面給出校驗源碼，僅供參考。

定義數據結構：

定義const修飾的結構體變量，存儲LCD部分寄存器的初始值，這個初始值跟具體的應用初始化有關，不一定是表中的數據，通常情況下，這個結構體變量被存儲到Flash中。

實現函數如下所示，函數會遍歷結構體變量中的每一個命令，以及每一個命令下的初始值，如果有一個不正確，則跳出循環，執行重新初始化和恢復措施。這個函數中的MY_DEBUGF宏是我自己的調試函數，使用串口打印調試信息，在接下來的第五部分將詳細敘述。通過這個函數，我可以長時間監控顯示屏的哪些命令、哪些位容易被干擾。程序里使用了一個被妖魔化的關鍵字：goto。大多數C語言書籍對goto關鍵字談之色變，但你應該有自己的判斷。在函數內部跳出多重循環，除了goto關鍵字，又有哪種方法能如此簡潔高效！

4.14陷阱

對于8051內核單片機，由于沒有相應的硬件支持，可以用純軟件設置軟件陷阱，用來攔截一些程序跑飛。對于ARM7或者Cortex-M系列單片機，硬件已經內建了多種異常，軟件需要根據硬件異常來編寫陷阱程序，用來快速定位甚至恢復錯誤。

4.15阻塞處理

有時候程序員會使用while(!flag);語句阻塞在此等待標志flag改變，比如串口發送時用來等待一字節數據發送完成。這樣的代碼時存在風險的，如果因為某些原因標志位一直不改變則會造成系統死機。

一個良好冗余的程序是設置一個超時定時器，超過一定時間后，強制程序退出while循環。

2003年8月11日發生的W32.Blaster.Worm蠕蟲事件導致全球經濟損失高達5億美元，這個漏洞是利用了Windows分布式組件對象模型的遠程過程調用接口中的一個邏輯缺陷：在調用GetMachineName()函數時，循環只設置了一個不充分的結束條件。

原代碼簡化如下所示：

微軟發布的安全補丁MS03-026解決了這個問題，為GetMachineName()函數設置了充分終止條件。一個解決代碼簡化如下所示（并非微軟補丁代碼）：

5.測試，再測試

思維再縝密的程序員也不可能編寫完全無缺陷的程序，測試的目的正是盡可能多的發現這些缺陷并改正。這里說的測試，是指程序員的自測試。前期的自測試能夠更早的發現錯誤，相應的修復成本也會很低，如果你不徹底測試自己的代碼，恐怕你開發的就不只是代碼，可能還會聲名狼藉。

優質嵌入式C程序跟優質的基礎元素關系密切，可以將函數作為基礎元素，我們的測試正是從最基本的函數開始。判斷哪些函數需要測試需要一定的經驗積累，雖然代碼行數跟邏輯復雜度并不成正比，但如果你不能判斷某個函數是否要測試，一個簡單粗暴的方法是：當函數有效代碼超過20行，就測試它。

程序員對自己的代碼以及邏輯關系十分清楚，測試時，按照每一個邏輯分支全面測試。很多錯誤發生在我們認為不會出錯的地方，所以即便某個邏輯分支很簡單，也建議測試一遍。第一個原因是我們自己看自己的代碼總是不容易發現錯誤，而測試能暴露這些錯誤；另一方面，語法正確、邏輯正確的代碼，經過編譯器編譯后，生成的匯編代碼很可能與你的邏輯相差甚遠。比如我們前文提及的使用volatile以及不使用volatile關鍵字編譯后生成的匯編代碼，再比如我們用低優化級別編譯和使用高優化級別編譯后生成的匯編代碼，都可能相差很大，實際運行測試，可以暴漏這些隱含錯誤。最后，雖然可能性極小，編譯器本身也可能有BUG，特別是構造復雜表達式的情況下（應極力避免復雜表達式）。

5.1使用硬件調試器測試

使用硬件調試器（比如J-link）測試是最通用的手段。可以單步運行、設置斷點，可以很方便的查看當前寄存器、變量的值。在尋找缺陷方面，使用硬件調試器測試是最簡單卻又最有效的手段。

硬件調試器已經在公司普遍使用，這方面的測試不做介紹，想必大家都已經很熟悉了。

5.2有些缺陷很難纏

就像沒有一種方法能完美解決所有問題，在實際項目中，硬件調試器也有難以觸及的地方。可以舉幾個例子說明：

使用了比較大的協議棧，需要跟進到協議棧內部調試的缺陷

比如公司使用lwIP協議棧，如果跟蹤數據的處理過程，需要從接收數據開始一直到應用層處理數據，之間會經過驅動層、IP層、TCP層和應用層，會經過十幾個文件幾十個函數，使用硬件調試器跟蹤費時費力；

具有隨機性的缺陷

有一些缺陷，可能是不定時出現的，有可能是幾分鐘出現，也有可能是幾個小時甚至幾天才出現，像這樣的缺陷很難用硬件調試器捕捉到；

需要外界一系列有時間限制的輸入條件觸發，但這一過程中有缺陷

比如我們用組合鍵來完成某個功能，規定按下按鍵1不小于3秒后松開，然后在6秒內分別按下按鍵2、按鍵3、按鍵4這三個按鍵來執行我們的特定程序，要測試類似這種過程，硬件調試器很難做到；

除了測試缺陷需要，有時候我們在做穩定性測試時，需要知道軟件每時每刻運行到那些分支、執行了哪些操作、我們關心的變量當前值是什么等等，這些都表明，我們還需要一種和硬件調試器互補的測試手段。

這個測試手段就是在程序中增加額外調試語句，當程序運行時，通過這些調試語句將運行信息輸出到可以方便查看的設備上，可以是PC機、LCD顯示屏、存儲卡等等。

以串口輸出到PC機為例，下面提供完整的測試思路。在此之前，我們先對這種測試手段提一些要求：

必須簡單易用

我們在初學C語言的時候，都接觸過printf函數，這個函數可以方便的輸出信息，并可以將各種變量格式化為指定格式的字符串，我們應當提供類似的函數；

調試語句必須方便的從代碼中移除

在編碼階段，我們可能會往程序中加入大量的調試語句，但是程序發布時，需要將這些調試語句從代碼中移除，這將是件恐怖的過程。我們必須提供一種策略，可以方便的移除這些調試語句。

5.2.1簡單易用的調試函數

1)使用庫函數printf。以MDK為例，方法如下：

I>初始化串口

II>重構fputc函數，printf函數會調用fputc函數執行底層串口的數據發送。

III>在Options for Targer窗口，Targer標簽欄下，勾選Use MicroLIB前的復選框以便避免使用半主機功能。（注：標準C庫printf函數默認開啟半主機功能，如果非要使用標準C庫，請自行查閱資料）

2)構建自己的調試函數

使用庫函數比較方便，但也少了一些靈活性，不利于隨心所欲的定制輸出格式。自己編寫類似printf函數則會更靈活一些，而且不依賴任何編譯器。下面給出一個完整的類printf函數實現，該函數支持有限的格式參數，使用方法與庫函數一致。同庫函數類似，該也需要提供一個底層串口發送函數（原型為：int32_t UARTwrite(const uint8_t *pcBuf, uint32_t ulLen)），用來發送指定數目的字符，并返回最終發送的字符個數。

5.2.2對調試函數進一步封裝

上文說到，我們增加的調試語句應能很方便的從最終發行版中去掉，因此我們不能直接調用printf或者自定義的UARTprintf函數，需要將這些調試函數做一層封裝，以便隨時從代碼中去除這些調試語句。參考方法如下：

在我們編碼測試期間，定義宏MY_DEBUG，并使用宏MY_DEBUGF（注意比前面那個宏多了一個‘F’）輸出調試信息。經過預處理后，宏MY_DEBUGF(message)會被UARTprintf message代替，從而實現了調試信息的輸出；當正式發布時，只需要將宏MY_DEBUG注釋掉，經過預處理后，所有MY_DEBUGF(message)語句都會被空格代替，而從將調試信息從代碼中去除掉。

6.編程思想

6.1編程風格

《計算機程序結構與說明》一書在開篇寫到：程序寫出來是給人看的，附帶能在機器上運行。

6.1.1 整潔的樣式

使用什么樣的編碼樣式一直都頗具爭議性的，比如縮進和大括號的位置。因為編碼的樣式也會影響程序的可讀性，面對一個亂放括號、對齊都不一致的源碼，我們很難提起閱讀它的興趣。我們總要看別人的程序，如果彼此編碼樣式相近，讀起源碼來會覺得比較舒適。但是編碼風格的問題是主觀的，永遠不可能在編碼風格上達成統一意見。因此只要你的編碼樣式整潔、結構清晰就足夠了。除此之外，對編碼樣式再沒有其它要求。

提出匈牙利命名法的程序員、前微軟首席架構師Charles Simonyi說：我覺得代碼清單帶給人的愉快同整潔的家差不多。你一眼就能分辨出家里是雜亂無章還是整潔如新。這也許意義不大。因為光是房子整潔說明不了什么，它仍可能藏污納垢！但是第一印象很重要，它至少反映了程序的某些方面。我敢打賭，我在3米開外就能看出程序拙劣與否。我也許沒法保證它很不錯，但如果從3米外看起來就很糟，我敢保證這程序寫得不用心。如果寫得不用心，那它在邏輯上也許就不會優美。

6.1.2清晰的命名

變量、函數、宏等等都需要命名，清晰的命名是優秀代碼的特點之一。命名的要點之一是名稱應能清晰的描述這個對象，以至于一個初級程序員也能不費力的讀懂你的代碼邏輯。我們寫的代碼主要給誰看是需要思考的：給自己、給編譯器還是給別人看？我覺得代碼最主要的是給別人看，其次是給自己看。如果沒有一個清晰的命名，別人在維護你的程序時很難在整個全貌上看清代碼，因為要記住十多個以上的糟糕命名的變量是件非常困難的事；而且一段時間之后你回過頭來看自己的代碼，很有可能不記得那些糟糕命名的變量是什么意思。

為對象起一個清晰的名字并不是簡單的事情。首先能認識到名稱的重要性需要有一個過程，這也許跟譚式C程序教材被大學廣泛使用有關：滿書的a、b、c、x、y、z變量名是很難在關鍵的初學階段給人傳達優秀編程思想的；其次如何恰當的為對象命名也很有挑戰性，要準確、無歧義、不羅嗦，要對英文有一定水平，所有這些都要滿足時，就會變得很困難；此外，命名還需要考慮整體一致性，在同一個項目中要有統一的風格，堅持這種風格也并不容易。

關于如何命名，Charles Simonyi說：面對一個具備某些屬性的結構，不要隨隨便便地取個名字，然后讓所有人去琢磨名字和屬性之間有什么關聯，你應該把屬性本身，用作結構的名字。

6.1.3恰當的注釋

注釋向來也是爭議之一，不加注釋和過多的注釋我都是反對的。不加注釋的代碼顯然是很糟糕的，但過多的注釋也會妨礙程序的可讀性，由于注釋可能存在的歧義，有可能會誤解程序真實意圖，此外，過多的注釋會增加程序員不必要的時間。如果你的編碼樣式整潔、命名又很清晰，那么，你的代碼可讀性不會差到哪去，而注釋的本意就是為了便于理解程序。

這里建議使用良好的編碼樣式和清晰的命名來減少注釋，對模塊、函數、變量、數據結構、算法和關鍵代碼做注釋，應重視注釋的質量而不是數量。如果你需要一大段注釋才能說清楚程序做什么，那么你應該注意了：是否是因為程序變量命名不夠清晰，或者代碼邏輯過于混亂，這個時候你應該考慮的可能就不是注釋，而是如何精簡這個程序了。

6.2數據結構

數據結構是程序設計的基礎。在設計程序之前，應該先考慮好所需要的數據結構。

前微軟首席架構師Charles Simonyi：編程的第一步是想象。就是要在腦海中對來龍去脈有極為清晰的把握。在這個初始階段，我會使用紙和鉛筆。我只是信手涂鴉，并不寫代碼。我也許會畫些方框或箭頭，但基本上只是涂鴉，因為真正的想法在我腦海里。我喜歡想象那些有待維護的結構，那些結構代表著我想編碼的真實世界。一旦這個結構考慮得相當嚴謹和明確，我便開始寫代碼。我會坐到終端前，或者換在以前的話，就會拿張白紙，開始寫代碼。這相當容易。我只要把頭腦中的想法變換成代碼寫下來，我知道結果應該是什么樣的。大部分代碼會水到渠成，不過我維護的那些數據結構才是關鍵。我會先想好數據結構，并在整個編碼過程中將它們牢記于心。

開發過以太網和操作系統SDS 940的Butler Lampson：（程序員）最重要的素質是能夠把問題的解決方案組織成容易操控的結構。

開發CP/M操作系統的Gary.A：如果不能確認數據結構是正確的，我是決不會開始編碼的。我會先畫數據結構，然后花很長時間思考數據結構。在確定數據結構之后我就開始寫一些小段的代碼，并不斷地改善和監測。在編碼過程中進行測試可以確保所做的修改是局部的，并且如果有什么問題的話，能夠馬上發現。

微軟創始人比爾·蓋茨：編寫程序最重要的部分是設計數據結構。接下來重要的部分是分解各種代碼塊。

編寫世界上第一個電子表格軟件的Dan Bricklin：在我看來，寫程序最重要的部分是設計數據結構，此外，你還必須知道人機界面會是什么樣的。

我們舉個例子來說明。在介紹防御性編程的時候，提到公司使用的LCD顯示屏抗干擾能力一般，為了提高LCD的穩定性，需要定期讀出LCD內部的關鍵寄存器值，然后跟存在Flash中的初始值相比較。需要讀出的LCD寄存器有十多個，從每個寄存器讀出的值也不盡相同，從1個到8個字節都有可能。如果不考慮數據結構，編寫出的程序將會很冗長。

我們分析這個過程，發現能提取出很多相同的元素，比如每次讀LCD寄存器都需要該寄存器的命令號，都會經過讀寄存器、判斷值是否相同、處理異常情況這一過程。所以我們可以提取一些相同的元素，組織成數據結構，用統一的方法去處理這些數據，將數據與處理過程分開來。

我們可以先提取相同的元素，將之組織成數據結構：

這里lcd_command表示的是LCD寄存器命令號；lcd_get_value是一個數組，表示寄存器要初始化的值，這是因為對于一個LCD寄存器，可能要初始化多個字節，這是硬件特性決定的；lcd_value_num是指一個寄存器要多少個字節的初值，這是因為每一個寄存器的初值數目是不同的，我們用同一個方法處理數據時，是需要這個信息的。

就本例而言，我們將要處理的數據都是事先固定的，所以定義好數據結構后，我們可以將這些數據組織成表格：

至此，我們就可以用一個處理過程來完成數十個LCD寄存器的讀取、判斷和異常處理了：

通過合理的數據結構，我們可以將數據和處理過程分開，LCD冗余判斷過程可以用很簡潔的代碼來實現。更重要的是，將數據和處理過程分開更有利于代碼的維護。比如，通過實驗發現，我們還需要增加一個LCD寄存器的值進行判斷，這時候只需要將新增加的寄存器信息按照數據結構格式，放到LCD寄存器設置值列表中的任意位置即可，不用增加任何處理代碼即可實現！這僅僅是數據結構的優勢之一，使用數據結構還能簡化編程，使復雜過程變的簡單，這個只有實際編程后才會有更深的理解。

7.總結

本文介紹了編寫優質嵌入式C程序涉及的多個方面。每年都有億萬計的C程序運行在單片機、ARM7、Cortex-M3這些微處理器上，但在這些處理器上如何編寫優質高效的C程序，幾乎沒有書籍做專門介紹。本文試圖在這方面做一些努力。編寫優質嵌入式C程序需要大量的專業知識，本文雖盡力描述編寫嵌入式C程序所需要的各種技能，但本文卻無力將每一個方面都面面俱到的描述出來，所以本文最后會列舉一些閱讀書目，這些書大多都是真正大師的經驗之談。站在巨人的肩膀上，可以看的更遠。