摘要：

本文首先分析了C語言的陷阱和缺陷，對容易犯錯(cuò)的地方進(jìn)行歸納整理；分析了編譯器語義檢查的不足之處并給出防范措施，以Keil MDK編譯器為例，介紹了該編譯器的特性、對未定義行為的處理以及一些高級應(yīng)用；

在此基礎(chǔ)上，介紹了防御性編程的概念，提出了編程過程中就應(yīng)該防范于未然的多種措施；提出了測試對編寫優(yōu)質(zhì)嵌入式程序的重要作用以及常用測試方法；最后，本文試圖以更高的層次看待編程，討論一些通用的編程思想。

1. 簡介

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

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

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

2. C語言特性

語言是編程的基石，C語言詭異且有種種陷阱和缺陷，需要程序員多年歷練才能達(dá)到較為完善的地步。雖然有眾多書籍、雜志、專題討論過C語言的陷阱和缺陷，但這并不影響本節(jié)再次討論它?？偸怯写笈某鯇W(xué)者，前仆后繼的倒在這些陷阱和缺陷上，民用設(shè)備、工業(yè)設(shè)備甚至是航天設(shè)備都不例外。本節(jié)將結(jié)合具體例子再次審視它們，希望引起足夠重視。深入理解C語言特性，是編寫優(yōu)質(zhì)嵌入式C程序的基礎(chǔ)。

2.1處處都是陷阱

2.1.1 無心之過

1)“=”和”==”

將比較運(yùn)算符”==”誤寫成賦值運(yùn)算符”=”，可能是絕大多數(shù)人都遇到過的，比如下面代碼：

	if(x=5)   
	{   
	    //其它代碼   
	}

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

	if(5==x)   
	{   
	    //其它代碼   
	}

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

2)復(fù)合賦值運(yùn)算符

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

tmp=+1;

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

如果你能在調(diào)試階段就發(fā)現(xiàn)這個(gè)Bug，真應(yīng)該慶祝一下，否則這很可能會(huì)成為一個(gè)重大隱含Bug，且不易被察覺。

復(fù)合賦值運(yùn)算符”-=”也有類似問題存在。

3)其它容易誤寫

• 使用了中文標(biāo)點(diǎn)
• 頭文件聲明語句最后忘記結(jié)束分號
• 邏輯與&&和位與&、邏輯或||和位或|、邏輯非！和位取反~
• 字母l和數(shù)字1、字母O和數(shù)字0

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

很多的軟件Bug源自于輸入錯(cuò)誤。在Google上搜索的時(shí)候，有些結(jié)果列表項(xiàng)中帶有一條警告，表明Google認(rèn)為它帶有惡意代碼。如果你在2009年1月31日一大早使用Google搜索的話，你就會(huì)看到，在那天早晨55分鐘的時(shí)間內(nèi)，

Google的搜索結(jié)果標(biāo)明每個(gè)站點(diǎn)對你的PC都是有害的。這涉及到整個(gè)Internet上的所有站點(diǎn)，包括Google自己的所有站點(diǎn)和服務(wù)。Google的惡意軟件檢測功能通過在一個(gè)已知攻擊者的列表上查找站點(diǎn)，從而識別出危險(xiǎn)站點(diǎn)。在1月31日早晨，對這個(gè)列表的更新意外地包含了一條斜杠(“/”)。

所有的URL都包含一條斜杠，并且，反惡意軟件功能把這條斜杠理解為所有的URL都是可疑的，因此，它愉快地對搜索結(jié)果中的每個(gè)站點(diǎn)都添加一條警告。很少見到如此簡單的一個(gè)輸入錯(cuò)誤帶來的結(jié)果如此奇怪且影響如此廣泛，但程序就是這樣，容不得一絲疏忽。

2.1.2 數(shù)組下標(biāo)

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

2.1.3 容易被忽略的break關(guān)鍵字

1)不能漏加的break

switch…case語句可以很方便的實(shí)現(xiàn)多分支結(jié)構(gòu)，但要注意在合適的位置添加break關(guān)鍵字。程序員往往容易漏加break從而引起順序執(zhí)行多個(gè)case語句，這也許是C的一個(gè)缺陷之處。

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

2)不能亂加的break

break關(guān)鍵字用于跳出最近的那層循環(huán)語句或者switch語句，但程序員往往不夠重視這一點(diǎn)。

1990年1月15日，AT&T電話網(wǎng)絡(luò)位于紐約的一臺交換機(jī)宕機(jī)并且重啟，引起它鄰近交換機(jī)癱瘓，由此及彼，一個(gè)連著一個(gè)，很快，114型交換機(jī)每六秒宕機(jī)重啟一次，六萬人九小時(shí)內(nèi)不能打長途電話。當(dāng)時(shí)的解決方式：工程師重裝了以前的軟件版本。。。事后的事故調(diào)查發(fā)現(xiàn)，這是break關(guān)鍵字誤用造成的?！禖專家編程》提供了一個(gè)簡化版的問題源碼：

	network code()  
	{  
	    switch(line) 
	     {  
	        case  THING1:
			   {  
	            doit1(); 
	         } break;  
	        case  THING2:
			   {  
	            if(x==STUFF) 
	             {  
	                do_first_stuff();  
	                if(y==OTHER_STUFF)  
	                    break;  
	                do_later_stuff();  
	            }  /*代碼的意圖是跳轉(zhuǎn)到這里… …*/  
	            initialize_modes_pointer(); 
			   } break;  
	        default :  
	            processing();  
	    } /*… …但事實(shí)上跳到了這里。*/  
	    use_modes_pointer(); /*致使modes_pointer未初始化*/  
	}  

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

2.1.4 意想不到的八進(jìn)制

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

	int a=34, b=034; 

變量a和b相等嗎？

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

    a[0]=106;       /*十進(jìn)制數(shù)106*/  
    a[1]=112;         /*十進(jìn)制數(shù)112*/   
    a[2]=052;       /*實(shí)際為十進(jìn)制數(shù)42，本意為十進(jìn)制52*/ 

2.1.5 指針加減運(yùn)算

指針的加減運(yùn)算是特殊的。下面的代碼運(yùn)行在32位ARM架構(gòu)上，執(zhí)行之后，a和p的值分別是多少？

	int a=1;  
	int *p=(int *)0x00001000;  
	a=a+1;  
	p=p+1; 

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

某項(xiàng)目使用下面代碼對連續(xù)RAM初始化零操作，但運(yùn)行發(fā)現(xiàn)有些RAM并沒有被真正清零。

	unsigned int *pRAMaddr;         //定義地址指針變量  
	for(pRAMaddr=StartAddr;pRAMaddr<EndAddr;pRAMaddr+=4)  
	{  
	     *pRAMaddr=0x00000000;   //指定RAM地址清零  
	} 

通過分析我們發(fā)現(xiàn)，由于pRAMaddr是一個(gè)無符號int型指針變量，所以pRAMaddr+=4代碼其實(shí)使pRAMaddr偏移了4*sizeof(int)=16個(gè)字節(jié)，所以每執(zhí)行一次for循環(huán)，會(huì)使變量pRAMaddr偏移16個(gè)字節(jié)空間，但只有4字節(jié)空間被初始化為零。其它的12字節(jié)數(shù)據(jù)的內(nèi)容，在大多數(shù)架構(gòu)處理器中都會(huì)是隨機(jī)數(shù)。

2.1.6 關(guān)鍵字sizeof

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

	void ClearRAM(char array[])  
	    int i ;  
	    for(i=0;i<sizeof(array)/sizeof(array[0]);i++)     //這里用法錯(cuò)誤，array實(shí)際上是指針  
	    {  
	        array[i]=0x00;  
	    }  
	}  
	int main(void)  
	{  
	    char Fle[20];  
	    ClearRAM(Fle);          //只能清除數(shù)組Fle中的前四個(gè)元素  
	}  

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

2.1.7 增量運(yùn)算符’++’和減量運(yùn)算符’—‘

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

	int a=8,b=2,y;  
	y=a+++--b;  

代碼執(zhí)行后，y的值是多少？

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

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

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

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

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

為了提高系統(tǒng)效率，邏輯與和邏輯或操作的規(guī)定如下：如果對第一個(gè)操作數(shù)求值后就可以推斷出最終結(jié)果，第二個(gè)操作數(shù)就不會(huì)進(jìn)行求值！比如下面代碼：

	if((i>=0)&&(i++ <=max))  
	{  
	       //其它代碼  
	}  

在這個(gè)代碼中，只有當(dāng)i>=0時(shí)，i++才會(huì)被執(zhí)行。這樣，i是否自增是不夠明確的，這可能會(huì)埋下隱患。邏輯或與之類似。

2.1.9 結(jié)構(gòu)體的填充

結(jié)構(gòu)體可能產(chǎn)生填充，因?yàn)閷Υ蠖鄶?shù)處理器而言，訪問按字或者半字對齊的數(shù)據(jù)速度更快，當(dāng)定義結(jié)構(gòu)體時(shí)，編譯器為了性能優(yōu)化，可能會(huì)將它們按照半字或字對齊，這樣會(huì)帶來填充問題。比如以下兩個(gè)個(gè)結(jié)構(gòu)體：

第一個(gè)結(jié)構(gòu)體：

	struct {  
	    char  c；  
	    short s；  
	    int   x；  
	}str_test1; 

第二個(gè)結(jié)構(gòu)體：

	struct {  
	    char  c；  
	    int   x；  
	    short s；      
	}str_test2;

這兩個(gè)結(jié)構(gòu)體元素都是相同的變量，只是元素?fù)Q了下位置，那么這兩個(gè)結(jié)構(gòu)體變量占用的內(nèi)存大小相同嗎？

其實(shí)這兩個(gè)結(jié)構(gòu)體變量占用的內(nèi)存是不同的，對于Keil MDK編譯器，默認(rèn)情況下第一個(gè)結(jié)構(gòu)體變量占用8個(gè)字節(jié)，第二個(gè)結(jié)構(gòu)體占用12個(gè)字節(jié)，差別很大。第一個(gè)結(jié)構(gòu)體變量在內(nèi)存中的存儲(chǔ)格式如圖2-1所示：

圖2-1：結(jié)構(gòu)體變量1內(nèi)存分布

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

圖2-2 ：結(jié)構(gòu)體變量2內(nèi)存分布

2.2 不可輕視的優(yōu)先級

C語言有32個(gè)關(guān)鍵字，卻有34個(gè)運(yùn)算符。要記住所有運(yùn)算符的優(yōu)先級是困難的。稍不注意，你的代碼邏輯和實(shí)際執(zhí)行就會(huì)有很大出入。

比如下面將BCD碼轉(zhuǎn)換為十六進(jìn)制數(shù)的代碼：

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

這里uTimeValue存放的BCD碼，想要轉(zhuǎn)換成16進(jìn)制數(shù)據(jù)，實(shí)際運(yùn)行發(fā)現(xiàn)，如果uTimeValue的值為0x23，按照我設(shè)定的邏輯，result的值應(yīng)該是0x17，但運(yùn)算結(jié)果卻是0x07。經(jīng)過種種排查后，才發(fā)現(xiàn)’+’的優(yōu)先級是大于’&’的，相當(dāng)于(uTimeValue>>4)*10+uTimeValue與0x0F位與，結(jié)果自然與邏輯不符。符合邏輯的代碼應(yīng)該是：

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

不合理的#define會(huì)加重優(yōu)先級問題，讓問題變得更加隱蔽。

	#define READSDA IO0PIN&(1<<11)  //讀IO口p0.11的端口狀態(tài)  
	          
	if(READSDA==(1<<11))          //判斷端口p0.11是否為高電平   
	{    
	    //其它代碼  
	}  

編譯器在編譯后將宏帶入,原代碼語句變?yōu)?

	if(IO0PIN&(1<<11) ==(1<<11))  
	{  
	    //其它代碼   
	} 

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

按照常規(guī)方式使用時(shí)，可能引起誤會(huì)的運(yùn)算符還有很多，如表2-1所示。C語言的運(yùn)算符當(dāng)然不會(huì)只止步于數(shù)目繁多！

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

• 過多的括號影響代碼的可讀性，包括自己和以后的維護(hù)人員
• 別人的代碼不一定用括號來解決優(yōu)先級問題，但你總要讀別人的代碼

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

2.3 隱式轉(zhuǎn)換

C語言的設(shè)計(jì)理念一直被人吐槽，因?yàn)樗J(rèn)為C程序員完全清楚自己在做什么，其中一個(gè)證據(jù)就是隱式轉(zhuǎn)換。C語言規(guī)定，不同類型的數(shù)據(jù)（比如char和int型數(shù)據(jù)）需要轉(zhuǎn)換成同一類型后，才可進(jìn)行計(jì)算。如果你混合使用類型，比如用char類型數(shù)據(jù)和int類型數(shù)據(jù)做減法，C使用一個(gè)規(guī)則集合來自動(dòng)（隱式的）完成類型轉(zhuǎn)換。這可能很方便，但也很危險(xiǎn)。

這就要求我們理解這個(gè)轉(zhuǎn)換規(guī)則并且能應(yīng)用到程序中去！

1)當(dāng)出現(xiàn)在表達(dá)式里時(shí)，有符號和無符號的char和short類型都將自動(dòng)被轉(zhuǎn)換為int類型，在需要的情況下，將自動(dòng)被轉(zhuǎn)換為unsigned int（在short和int具有相同大小時(shí)）。這稱為類型提升。

提升在算數(shù)運(yùn)算中通常不會(huì)有什么大的壞處，但如果位運(yùn)算符 ~ 和 << 應(yīng)用在基本類型為unsigned char或unsigned short 的操作數(shù)，結(jié)果應(yīng)該立即強(qiáng)制轉(zhuǎn)換為unsigned char或者unsigned short類型（取決于操作時(shí)使用的類型）。

	uint8_t  port =0x5aU;  
	uint8_t  result_8;  
	result_8= (~port) >> 4; 

假如我們不了解表達(dá)式里的類型提升，認(rèn)為在運(yùn)算過程中變量port一直是unsigned char類型的。我們來看一下運(yùn)算過程：~port結(jié)果為0xa5，0xa5>>4結(jié)果為0x0a，這是我們期望的值。但實(shí)際上，result_8的結(jié)果卻是0xfa！在ARM結(jié)構(gòu)下，int類型為32位。變量port在運(yùn)算前被提升為int類型：~port結(jié)果為0xffffffa5，0xa5>>4結(jié)果為0x0ffffffa，賦值給變量result_8，發(fā)生類型截?cái)啵ㄟ@也是隱式的！），result_8=0xfa。經(jīng)過這么詭異的隱式轉(zhuǎn)換，結(jié)果跟我們期望的值，已經(jīng)大相徑庭！正確的表達(dá)式語句應(yīng)該為：

result_8=(unsigned char) (~port) >> 4;             /*強(qiáng)制轉(zhuǎn)換*/

2)在包含兩種數(shù)據(jù)類型的任何運(yùn)算里，兩個(gè)值都會(huì)被轉(zhuǎn)換成兩種類型里較高的級別。類型級別從高到低的順序是long double、double、float、unsigned long long、long long、unsigned long、long、unsigned int、int。

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

	uint16_t  u16a = 40000;            	/* 16位無符號變量*/  
	uint16_t  u16b= 30000;          	/*16位無符號變量*/  
	uint32_t  u32x;                  	/*32位無符號變量 */  
	uint32_t  u32y;  
	u32x = u16a +u16b;                	/* u32x = 70000還是4464 ? */  
	u32y =(uint32_t)(u16a + u16b);   	/* u32y = 70000 還是4464 ? */

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

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

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

	uint16_t u16a,u16b,u16c;  
	uint32_t  u32x;  
	u32x= u16a + u16b + (uint32_t)u16c;/*錯(cuò)誤寫法，u16a+ u16b仍可能溢出*/ 

3)在賦值語句里，計(jì)算的最后結(jié)果被轉(zhuǎn)換成將要被賦予值的那個(gè)變量的類型。這一過程可能導(dǎo)致類型提升也可能導(dǎo)致類型降級。降級可能會(huì)導(dǎo)致問題。比如將運(yùn)算結(jié)果為321的值賦值給8位char類型變量。程序必須對運(yùn)算時(shí)的數(shù)據(jù)溢出做合理的處理。

很多其他語言，像Pascal（C語言設(shè)計(jì)者之一曾撰文狠狠批評過Pascal語言），都不允許混合使用類型，但C語言不會(huì)限制你的自由，即便這經(jīng)常引起B(yǎng)ug。

4)當(dāng)作為函數(shù)的參數(shù)被傳遞時(shí)，char和short會(huì)被轉(zhuǎn)換為int，float會(huì)被轉(zhuǎn)換為double。

當(dāng)不得已混合使用類型時(shí)，一個(gè)比較好的習(xí)慣是使用類型強(qiáng)制轉(zhuǎn)換。強(qiáng)制類型轉(zhuǎn)換可以避免編譯器隱式轉(zhuǎn)換帶來的錯(cuò)誤，同時(shí)也向以后的維護(hù)人員傳遞一些有用信息。這有個(gè)前提：你要對強(qiáng)制類型轉(zhuǎn)換有足夠的了解！下面總結(jié)一些規(guī)則：

• 并非所有強(qiáng)制類型轉(zhuǎn)換都是由風(fēng)險(xiǎn)的，把一個(gè)整數(shù)值轉(zhuǎn)換為一種具有相同符號的更寬類型時(shí)，是絕對安全的。
• 精度高的類型強(qiáng)制轉(zhuǎn)換為精度低的類型時(shí)，通過丟棄適當(dāng)數(shù)量的最高有效位來獲取結(jié)果，也就是說會(huì)發(fā)生數(shù)據(jù)截?cái)啵⑶铱赡芨淖償?shù)據(jù)的符號位。
• 精度低的類型強(qiáng)制轉(zhuǎn)換為精度高的類型時(shí)，如果兩種類型具有相同的符號，那么沒什么問題；需要注意的是負(fù)的有符號精度低類型強(qiáng)制轉(zhuǎn)換為無符號精度高類型時(shí)，會(huì)不直觀的執(zhí)行符號擴(kuò)展，例如：

	unsigned int bob;  
	signed char fred = -1;  
	   
	bob=(unsigned int )fred;              /*發(fā)生符號擴(kuò)展，此時(shí)bob為0xFFFFFFFF*/ 

3. 編譯器

如果你和一個(gè)優(yōu)秀的程序員共事，你會(huì)發(fā)現(xiàn)他對他使用的工具非常熟悉，就像一個(gè)畫家了解他的畫具一樣。----比爾.蓋茨

3.1 不能簡單的認(rèn)為是個(gè)工具

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

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

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

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

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

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

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

編譯器的語義檢查很弱小，甚至還會(huì)“掩蓋”錯(cuò)誤?，F(xiàn)代的編譯器設(shè)計(jì)是件浩瀚的工程，為了讓編譯器設(shè)計(jì)簡單一些，目前幾乎所有編譯器的語義檢查都比較弱小。為了獲得更快的執(zhí)行效率，C語言被設(shè)計(jì)的足夠靈活且?guī)缀醪贿M(jìn)行任何運(yùn)行時(shí)檢查，比如數(shù)組越界、指針是否合法、運(yùn)算結(jié)果是否溢出等等。這就造成了很多編譯正確但執(zhí)行奇怪的程序。

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

3.2.1莫名的死機(jī)

下面的兩個(gè)例子都是死循環(huán)，如果在不常用分支中出現(xiàn)類似代碼，將會(huì)造成看似莫名其妙的死機(jī)或者重啟。

	unsigned char i；    //例程1 
	for(i=0;i<256;i++)    
	{   
	    //其它代碼  
	} 
	unsigned char i;     //例程2 
	for(i=10;i>=0;i--)   
	{   
	    //其它代碼  
	}

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

3.2.2不起眼的改變

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

	if(a>b);          	//這里誤加了一個(gè)分號  
	a=b;             	//這句代碼一直被執(zhí)行 

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

	if(n<3)  
	return    		//這里少加了一個(gè)分號  
	logrec.data=x[0];  
	logrec.time=x[1];  
	logrec.code=x[2];  

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

3.2.3 難查的數(shù)組越界

上文曾提到數(shù)組常常是引起程序不穩(wěn)定的重要因素，程序員往往不經(jīng)意間就會(huì)寫數(shù)組越界。

一位同事的代碼在硬件上運(yùn)行，一段時(shí)間后就會(huì)發(fā)現(xiàn)LCD顯示屏上的一個(gè)數(shù)字不正常的被改變。經(jīng)過一段時(shí)間的調(diào)試，問題被定位到下面的一段代碼中：

	int SensorData[30];  
	//其他代碼 
	for(i=30;i>0;i--)  
	{  
	     SensorData[i]=…;  
	     //其他代碼   
	}

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

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

你在模塊A中定義數(shù)組：

int SensorData[30];

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

extern int SensorData[]; 

這次，編譯器不會(huì)給出警告信息，因?yàn)榫幾g器壓根就不知道數(shù)組的元素個(gè)數(shù)。所以，當(dāng)一個(gè)數(shù)組聲明為具有外部鏈接，它的大小應(yīng)該顯式聲明。

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

	char * func(char SensorData[30])  
	{  
	     unsignedint i；  
	     for(i=30;i>0;i--)  
	     {  
	          SensorData[i]=…;  
	          //其他代碼
	     }  
	}  

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

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

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

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

如果局部數(shù)組越界，可能引發(fā)ARM架構(gòu)硬件異常。

同事的一個(gè)設(shè)備用于接收無線傳感器的數(shù)據(jù)，一次軟件升級后，發(fā)現(xiàn)接收設(shè)備工作一段時(shí)間后會(huì)死機(jī)。調(diào)試表明ARM7處理器發(fā)生了硬件異常，異常處理代碼是一段死循環(huán)（死機(jī)的直接原因）。接收設(shè)備有一個(gè)硬件模塊用于接收無線傳感器的整包數(shù)據(jù)并存在自己的緩沖區(qū)中，當(dāng)硬件模塊接收數(shù)據(jù)完成后，使用外部中斷通知設(shè)備取數(shù)據(jù)，外部中斷服務(wù)程序精簡后如下所示：

	__irq ExintHandler(void)  
	{  
	     unsignedchar DataBuf[50];  
	     GetData(DataBug);        //從硬件緩沖區(qū)取一幀數(shù)據(jù)  
	     //其他代碼 
	}

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

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

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

3.2.4神奇的volatile

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

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

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

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

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

unsigned int test; 

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

extern unsigned long test;

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

volatile unsigned int test;

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

extern unsigned int test; /*缺少volatile限定符*/

編譯器卻不會(huì)給出錯(cuò)誤信息（有些編譯器僅給出一條警告）。當(dāng)你在另外一個(gè)模塊（該模塊包含聲明變量test的頭文件）使用變量test時(shí)，它已經(jīng)不再具有volatile限定，這樣很可能造成一些重大錯(cuò)誤。比如下面的例子，注意該例子是為了說明volatile限定符而專門構(gòu)造出的，因?yàn)楝F(xiàn)實(shí)中的volatile使用Bug大都隱含，并且難以理解。

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

volatile unsigned int TimerCount=0;

該變量用來在一個(gè)定時(shí)器中斷服務(wù)程序中進(jìn)行軟件計(jì)時(shí)：

TimerCount++; 

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

extern unsigned int TimerCount; //這里漏掉了類型限定符volatile 

在模塊B中，要使用TimerCount變量進(jìn)行精確的軟件延時(shí)：

	#include “…A.h”                     //首先包含模塊A的頭文件  
	//其他代碼  
	TimerCount=0;  
	while(TimerCount<=TIMER_VALUE);   //延時(shí)一段時(shí)間(感謝網(wǎng)友chhfish指出這里的邏輯錯(cuò)誤)  
	//其他代碼  

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

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

沒有使用關(guān)鍵字volatile，在keil MDK V4.54下編譯，默認(rèn)優(yōu)化級別，如下所示（注意最后兩行）：

    unIdleCount=0;   
	   123:        
	0x00002E10  E59F11D4  LDR       R1,[PC,#0x01D4]  
	0x00002E14  E3A05000  MOV       R5,#key1(0x00000000)  
	0x00002E18  E1A00005  MOV       R0,R5  
	0x00002E1C  E5815000  STR       R5,[R1]  
	   124:     while(unIdleCount!=200);   //延時(shí)2S鐘   
	   125:        
     0x00002E20  E35000C8  CMP       R0,#0x000000C8  
	0x00002E24  1AFFFFFD  BNE       0x00002E20</span>

使用關(guān)鍵字volatile，在keil MDK V4.54下編譯，默認(rèn)優(yōu)化級別，如下所示（注意最后三行）：

     unIdleCount=0;   
	   123:        
	0x00002E10  E59F01D4  LDR       R0,[PC,#0x01D4]  
	0x00002E14  E3A05000  MOV       R5,#key1(0x00000000)  
	0x00002E18  E5805000  STR       R5,[R0]  
	   124:     while(unIdleCount!=200);   //延時(shí)2S鐘   
	   125:        
	0x00002E1C  E5901000  LDR       R1,[R0]  
	0x00002E20  E35100C8  CMP       R1,#0x000000C8  
	0x00002E24  1AFFFFFC  BNE       0x00002E1C 

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

3.2.5局部變量

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

局部變量必須顯式初始化，除非你確定知道你要做什么。下面的代碼得到的溫度值跟預(yù)期會(huì)有很大差別，因?yàn)樵谑褂镁植孔兞縮um時(shí)，并不能保證它的初值為0。編譯器會(huì)在第一次運(yùn)行時(shí)清零堆棧區(qū)域，這加重了此類Bug的隱蔽性。

	unsigned intGetTempValue(void)  
	{  
	    unsigned int sum;                     //定義局部變量，保存總值  
	    for(i=0;i<10;i++)  
	    {  
	        sum+=CollectTemp();               //函數(shù)CollectTemp可以得到當(dāng)前的溫度值  
	    }  
	    return (sum/10);  
	} 

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

	char * GetData(void)  
	{  
	     char buffer[100];                 //局部數(shù)組  
	     …  
	     return buffer;  
	} 

3.2.6使用外部工具

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

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

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

1)點(diǎn)擊菜單Tools---Set-up PC-Lint…

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

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

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

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

檢查當(dāng)前文件。

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

檢查所有C源文件。

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

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

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

C語言標(biāo)準(zhǔn)特別的規(guī)定某些行為是未定義的，編寫未定義行為的代碼，其輸出結(jié)果由編譯器決定！ C標(biāo)準(zhǔn)委員會(huì)定義未定義行為的原因如下：

• 簡化標(biāo)準(zhǔn)，并給予實(shí)現(xiàn)一定的靈活性，比如不捕捉那些難以診斷的程序錯(cuò)誤；
• 編譯器開發(fā)商可以通過未定義行為對語言進(jìn)行擴(kuò)展

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

3.3.1常見的未定義行為

1)自增自減在表達(dá)式中連續(xù)出現(xiàn)并作用于同一變量或者自增自減在表達(dá)式中出現(xiàn)一次，但作用的變量多次出現(xiàn)

自增（++）和自減（--）這一動(dòng)作發(fā)生在表達(dá)式的哪個(gè)時(shí)刻是由編譯器決定的，比如：

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

不同的編譯器可能有著不同的匯編代碼，可能是先執(zhí)行i++再進(jìn)行乘法和加法運(yùn)行，也可能是先進(jìn)行加法和乘法運(yùn)算，再執(zhí)行i++，因?yàn)檫@句代碼在一個(gè)表達(dá)式中出現(xiàn)了連續(xù)的自增并作用于同一變量。更加隱蔽的是自增自減在表達(dá)式中出現(xiàn)一次，但作用的變量多次出現(xiàn)，比如：

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

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

2)函數(shù)實(shí)參被求值的順序

函數(shù)如果有多個(gè)實(shí)參，這些實(shí)參的求值順序是由編譯器決定的，比如：

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

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

3)有符號整數(shù)溢出

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

	int value1,value2,sum  
	  
	//其它操作  
	sum=value1+value;    /*sum可能發(fā)生溢出*/

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

5)除數(shù)為零

6)malloc()、calloc()或realloc()分配零字節(jié)內(nèi)存

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

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

了解C語言未定義行為

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

尋求工具幫助

編譯器警告信息以及PC-Lint等靜態(tài)檢查工具能夠發(fā)現(xiàn)很多未定義行為并警告，要時(shí)刻關(guān)注這些工具反饋的信息；

總結(jié)并使用一些編碼標(biāo)準(zhǔn)

1）避免構(gòu)造復(fù)雜的自增或者自減表達(dá)式，實(shí)際上，應(yīng)該避免構(gòu)造所有復(fù)雜表達(dá)式；

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

2）只對無符號操作數(shù)使用位操作；

必要的運(yùn)行時(shí)檢查

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

int value1,value2,sum;  
//其它代碼  
if((value1>0 && value2>0 && value1>(INT_MAX-value2))||  
   (value1<0 && value2<0 && value1<(INT_MIN-value2)))  
{  
    //處理錯(cuò)誤  
}  
else  
{  
    sum=value1+value2;  
}

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

int value1, value2, sum;
unsigned int usum = (unsigned int)value1 + value2;
 
if((usum ^ value1) & (usum ^ value2) & INT_MIN)
{
	/*處理溢出情況*/
}
else
{
	sum = value1 + value2;
}

使用的原理解釋一下，因?yàn)樵诩臃ㄟ\(yùn)算中，操作數(shù)value1和value2只有符號相同時(shí)，才可能發(fā)生溢出，所以我們先將這兩個(gè)數(shù)轉(zhuǎn)換為無符號類型，兩個(gè)數(shù)的和保存在變量usum中。如果發(fā)生溢出，則value1、value2和usum的最高位（符號位）一定不同，表達(dá)式(usum ^ value1) & (usum ^ value2) 的最高位一定為1，這個(gè)表達(dá)式位與（&）上INT_MIN是為了將最高位之外的其它位設(shè)置為0。

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

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

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

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

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

3）整型數(shù)除以零返回零

3.4 了解你的編譯器

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

3.4.1編譯器的一些小知識

1)默認(rèn)情況下，char類型的數(shù)據(jù)項(xiàng)是無符號的，所以它的取值范圍是0～255；

2)在所有的內(nèi)部和外部標(biāo)識符中，大寫和小寫字符不同；

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

4)壓縮類型的自然對齊方式為1。使用關(guān)鍵字__packed來壓縮特定結(jié)構(gòu)，將所有有效類型的對齊邊界設(shè)置為1；

5)整數(shù)以二進(jìn)制補(bǔ)碼形式表示；浮點(diǎn)量按IEEE格式存儲(chǔ)；

6)整數(shù)除法的余數(shù)的符號于被除數(shù)相同，由ISO C90標(biāo)準(zhǔn)得出；

7)如果整型值被截?cái)酁槎痰挠蟹栒?，則通過放棄適當(dāng)數(shù)目的最高有效位來得到結(jié)果。如果原始數(shù)是太大的正或負(fù)數(shù)，對于新的類型，無法保證結(jié)果的符號將于原始數(shù)相同。

8)整型數(shù)超界不引發(fā)異常；像unsigned char test; test=1000;這類是不會(huì)報(bào)錯(cuò)的；

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

10)對于結(jié)構(gòu)體填充，根據(jù)定義結(jié)構(gòu)的方式，keil MDK編譯器用以下方式的一種來填充結(jié)構(gòu)：

I> 定義為static或者extern的結(jié)構(gòu)用零填充；

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

11)編譯器不對聲明為volatile類型的數(shù)據(jù)進(jìn)行優(yōu)化；

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

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

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

15)__inline：提示編譯器在合理的情況下內(nèi)聯(lián)編譯C或C++ 函數(shù)；

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

我們程序中的一些全局變量和靜態(tài)變量在定義時(shí)進(jìn)行了初始化，經(jīng)過編譯器編譯后，這些初始值被存放在了代碼的哪里？我們舉個(gè)例子說明：

	unsigned int g_unRunFlag=0xA5；  
	static unsigned int s_unCountFlag=0x5A； 

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

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

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

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

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

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

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

圖3-1 設(shè)置編譯器生產(chǎn)MAP文件

3.4.4默認(rèn)情況下，棧被分配到RAM的哪個(gè)地方？

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

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

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

3.4.5有多少RAM會(huì)被初始化？

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

答案是否定的，MDK只是把你的程序用到的RAM以及堆棧RAM給初始化，其它RAM的內(nèi)容是不管的。如果你要使用絕對地址訪問MDK未初始化的RAM，那就要小心翼翼的了，因?yàn)檫@些RAM上電時(shí)的內(nèi)容很可能是隨機(jī)的，每次上電都不同。

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

對于控制類產(chǎn)品，當(dāng)系統(tǒng)復(fù)位后（非上電復(fù)位），可能要求保持住復(fù)位前RAM中的數(shù)據(jù)，用來快速恢復(fù)現(xiàn)場，或者不至于因瞬間復(fù)位而重啟現(xiàn)場設(shè)備。而keil mdk在默認(rèn)情況下，任何形式的復(fù)位都會(huì)將RAM區(qū)的非初始化變量數(shù)據(jù)清零。

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

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

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

 LR_IROM1 0x00000000 0x00080000  {    ; load region size_region
 ER_IROM1 0x00000000 0x00080000  {  ; load address = execution address
  *.o (RESET, +First)
  *(InRoot$$Sections)
  .ANY (+RO)
 }
 RW_IRAM1 0x10000000 0x0000A000  {  ; RW data
  .ANY (+RW +ZI)
 }
  MYRAM 0x1000A000 UNINIT 0x00002000  {
   .ANY (NO_INIT)
  }
}

那么，如果在程序中有一個(gè)數(shù)組，你不想讓它復(fù)位后零初始化，就可以這樣來定義變量：

unsigned char plc_eu_backup[32] __attribute__((at(0x1000A000)));

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

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

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

unsigned char plc_eu_backup[32] __attribute__((section("NO_INIT"),zero_init));

變量屬性修飾符__attribute__((section(“name”),zero_init))用于將變量強(qiáng)制定義到name屬性數(shù)據(jù)節(jié)中，zero_init表示將未初始化的變量放到ZI數(shù)據(jù)節(jié)中。因?yàn)?ldquo;NO_INIT”這顯性命名的自定義節(jié)，具有UNINIT屬性。

3)將一個(gè)模塊內(nèi)的非初始化變量都非零初始化

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

   LR_IROM1 0x00000000 0x00080000  {    ; load region size_region
   ER_IROM1 0x00000000 0x00080000  {  ; load address = execution address
    *.o (RESET, +First)
    *(InRoot$$Sections)
    .ANY (+RO)
   }
   RW_IRAM1 0x10000000 0x0000A000  {  ; RW data
    .ANY (+RW +ZI)
   }
    RW_IRAM2 0x1000A000 UNINIT 0x00002000  {
     test.o (+ZI)
    }
  }

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

這里，變量屬性修飾符__attribute__((zero_init))用于將未初始化的變量放到ZI數(shù)據(jù)節(jié)中變量，其實(shí)MDK默認(rèn)情況下，未初始化的變量就是放在ZI數(shù)據(jù)區(qū)的。

4. 防御性編程

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

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

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

程序員可能無意識的傳遞了錯(cuò)誤參數(shù)；外界的強(qiáng)干擾可能將傳遞的參數(shù)修改掉，或者使用隨機(jī)參數(shù)意外的調(diào)用函數(shù)，因此在執(zhí)行函數(shù)主體前，需要先確定實(shí)參是否合法。

    int exam_fun( unsigned char *str )   
    {   
          if( str != NULL )     //  檢查“假設(shè)指針不為空”這個(gè)條件 
    	     {   
               //正常處理代碼               
          } 
          else 
          {  
              //處理錯(cuò)誤代碼  
         }  
    }  

4.2 仔細(xì)檢查函數(shù)的返回值

對函數(shù)返回的錯(cuò)誤碼，要進(jìn)行全面仔細(xì)處理，必要時(shí)做錯(cuò)誤記錄。

 	char *DoSomething(…)  
 	{  
 	    char * p;  
 	     p=malloc(1024);  
 	     if(p==NULL)          /*對函數(shù)返回值作出判斷*/
 	     {         
 	        UARTprintf(…);   /*打印錯(cuò)誤信息*/  
 	         return NULL;  
 	     }  
 	     retuen p;  
 	}  

4.3 防止指針越界

如果動(dòng)態(tài)計(jì)算一個(gè)地址時(shí)，要保證被計(jì)算的地址是合理的并指向某個(gè)有意義的地方。特別對于指向一個(gè)結(jié)構(gòu)或數(shù)組的內(nèi)部的指針，當(dāng)指針增加或者改變后仍然指向同一個(gè)結(jié)構(gòu)或數(shù)組。

4.4 防止數(shù)組越界

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

	#define REC_BUF_LEN 100  
	unsigned char RecBuf[REC_BUF_LEN];  
	//其它代碼  
	void Uart_IRQHandler(void)  
	{  
	    static RecCount=0;          //接收數(shù)據(jù)長度計(jì)數(shù)器  
	    //其它代碼  
	    if(RecCount< REC_BUF_LEN)   //判斷數(shù)組是否越界
	    {  
	         RecBuf[RecCount]=…;     //從硬件取數(shù)據(jù)  
	         RecCount++;  
	         //其它代碼  
	    } 
	    else 
	    {  
	        //錯(cuò)誤處理代碼   
	    }  
	     //其它代碼 
	}  

在使用一些庫函數(shù)時(shí)，同樣需要對邊界進(jìn)行檢查，比如下面的memset(RecBuf,0,len)函數(shù)把RecBuf指指向的內(nèi)存區(qū)的前l(fā)en個(gè)字節(jié)用0填充，如果不注意len的長度，就會(huì)將數(shù)組RecBuf之外的內(nèi)存區(qū)清零：

	#define REC_BUF_LEN 100  
	unsigned char RecBuf[REC_BUF_LEN];  
	  
	if(len< REC_BUF_LEN)
	{  
	    memset(RecBuf,0,len);       //將數(shù)組RecBuf清零  
	} 
	else 
	{  
	    //處理錯(cuò)誤  
	}  

4.5 數(shù)學(xué)算數(shù)運(yùn)算

4.5.1除法運(yùn)算，只檢測除數(shù)為零就可靠嗎？

除法運(yùn)算前，檢查除數(shù)是否為零幾乎已經(jīng)成為共識，但是僅檢查除數(shù)是否為零就夠了嗎？

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

	#include <limits.h>    
	signed long sl1,sl2,result;    
	/*初始化sl1和sl2*/    
	if((sl2==0)||(sl1==LONG_MIN && sl2==-1))  
	{    
	    //處理錯(cuò)誤    
	}   
	else   
	{    
	    result = sl1 / sl2;    
	}

4.5.2檢測運(yùn)算溢出

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

	#include <limits.h>    
	unsigned int a,b,result;    
	/*初始化a，b*/    
	if(UINT_MAX-a<b)  
	{    
	    //處理溢出    
	}   
	else   
	{    
	    result=a+b;    
	}

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

4.5.3檢測移位

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

	unsigned int ui1;  
	unsigned int ui2;  
	unsigned int uresult;  
	  
	/*初始化ui1,ui2*/  
	if(ui2>=sizeof(unsigned int)*CHAR_BIT)  
	{  
	    //處理錯(cuò)誤  
	}  
	else  
	{  
	    uresult=ui1<<ui2;  
	}  

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

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

要盡可能早的開啟看門狗

這是因?yàn)閺纳想姀?fù)位結(jié)束到開啟看門狗的這段時(shí)間內(nèi)，設(shè)備有可能被干擾而跳過看門狗初始化程序，導(dǎo)致看門狗失效。盡可能早的開啟看門狗，可以降低這種概率；

不要在中斷中喂狗，除非有其他聯(lián)動(dòng)措施

在中斷程序喂狗，由于干擾的存在，程序可能一直處于中斷之中，這樣會(huì)導(dǎo)致看門狗失效。如果在主程序中設(shè)置標(biāo)志位，中斷程序喂狗時(shí)與這個(gè)標(biāo)志位聯(lián)合判斷，也是允許的；

喂狗間隔跟產(chǎn)品需求有關(guān)，并非特定的時(shí)間

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

克萊門汀號在進(jìn)行第二階段的任務(wù)時(shí)，原本預(yù)訂要從月球飛行到太空深處的Geographos小行星進(jìn)行探勘，然而這艘太空探測器在飛向小行星時(shí)卻由于一個(gè)軟件缺陷而使其中斷運(yùn)作20分鐘，不但未能到達(dá)小行星，也因?yàn)榭刂茋娮烊紵?1分鐘使電力供應(yīng)降低，無法再透過遠(yuǎn)端控制探測器，最終結(jié)束這項(xiàng)任務(wù)，但也導(dǎo)致了資源與資金的浪費(fèi)。

“克萊門汀太空任務(wù)失敗這件事讓我感到十分震驚，它其實(shí)可以透過硬件中一款簡單的看門狗計(jì)時(shí)器避免掉這項(xiàng)意外，但由于當(dāng)時(shí)的開發(fā)時(shí)間相當(dāng)緊縮，程序設(shè)計(jì)人員沒時(shí)間編寫程序來啟動(dòng)它，”Ganssle說。

遺憾的是，1998年發(fā)射的近地號太空船(NEAR)也遇到了相同的問題。由于編程人員并未采納建議，因此，當(dāng)推進(jìn)器減速器系統(tǒng)故障時(shí)，29公斤的儲(chǔ)備燃料也隨之報(bào)銷──這同樣是一個(gè)本來可經(jīng)由看門狗定時(shí)器編程而避免的問題，同時(shí)也證明要從其他程序設(shè)計(jì)人員的錯(cuò)誤中學(xué)習(xí)并不容易。

4.7關(guān)鍵數(shù)據(jù)儲(chǔ)存多個(gè)備份，取數(shù)據(jù)采用“表決法”

RAM中的數(shù)據(jù)在受到干擾情況下有可能被改變，對于系統(tǒng)關(guān)鍵數(shù)據(jù)應(yīng)該進(jìn)行保護(hù)。關(guān)鍵數(shù)據(jù)包括全局變量、靜態(tài)變量以及需要保護(hù)的數(shù)據(jù)區(qū)域。備份數(shù)據(jù)與原數(shù)據(jù)不應(yīng)該處于相鄰位置，因此不應(yīng)由編譯器默認(rèn)分配備份數(shù)據(jù)位置，而應(yīng)該由程序員指定區(qū)域存儲(chǔ)?？梢詫AM分為3個(gè)區(qū)域，第一個(gè)區(qū)域保存原碼，第二個(gè)區(qū)域保存反碼，第三個(gè)區(qū)域保存異或碼，區(qū)域之間預(yù)留一定量的“空白”RAM作為隔離?？梢允褂镁幾g器的“分散加載”機(jī)制將變量分別存儲(chǔ)在這些區(qū)域。需要進(jìn)行讀取時(shí)，同時(shí)讀出3份數(shù)據(jù)并進(jìn)行表決，取至少有兩個(gè)相同的那個(gè)值。

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

	LR_IROM1 0x00000000 0x00080000  {    ; load region size_region  
	  ER_IROM1 0x00000000 0x00080000  {  ; load address = execution address  
	   *.o (RESET, +First)  
	   *(InRoot$$Sections)  
	   .ANY (+RO)  
	  }  
	  RW_IRAM1 0x10000000 0x00008000  {  ;保存原碼  
	   .ANY (+RW +ZI )  
	  }  
	  RW_IRAM3 0x10009000 0x00001000{    ;保存反碼  
	   .ANY (MY_BK1)  
	  }  
	  RW_IRAM2 0x1000B000 0x00001000  {  ;保存異或碼  
	   .ANY (MY_BK2)  
	  }  
	} 

如果一個(gè)關(guān)鍵變量需要多處備份，可以按照下面方式定義變量，將三個(gè)變量分別指定到三個(gè)不連續(xù)的RAM區(qū)中，并在定義時(shí)按照原碼、反碼、0xAA的異或碼進(jìn)行初始化。

	uint32  plc_pc=0;                                                       //原碼  
	__attribute__((section("MY_BK1"))) uint32 plc_pc_not=~0x0;              //反碼  
	__attribute__((section("MY_BK2"))) uint32 plc_pc_xor=0x0^0xAAAAAAAA;    //異或碼

當(dāng)需要寫這個(gè)變量時(shí)，這三個(gè)位置都要更新；讀取變量時(shí)，讀取三個(gè)值做判斷，取至少有兩個(gè)相同的那個(gè)值。

為什么選取異或碼而不是補(bǔ)碼？這是因?yàn)镸DK的整數(shù)是按照補(bǔ)碼存儲(chǔ)的，正數(shù)的補(bǔ)碼與原碼相同，在這種情況下，原碼和補(bǔ)碼是一致的，不但起不到冗余作用，反而對可靠性有害。比如存儲(chǔ)的一個(gè)非零整數(shù)區(qū)因?yàn)楦蓴_，RAM都被清零，由于原碼和補(bǔ)碼一致，按照3取2的“表決法”，會(huì)將干擾值0當(dāng)做正確的數(shù)據(jù)。

4.8對非易失性存儲(chǔ)器進(jìn)行備份存儲(chǔ)

非易失性存儲(chǔ)器包括但不限于Flash、EEPROM、鐵電。僅僅將寫入非易失性存儲(chǔ)器中的數(shù)據(jù)再讀出校驗(yàn)是不夠的。強(qiáng)干擾情況下可能導(dǎo)致非易失性存儲(chǔ)器內(nèi)的數(shù)據(jù)錯(cuò)誤，在寫非易失性存儲(chǔ)器的期間系統(tǒng)掉電將導(dǎo)致數(shù)據(jù)丟失，因干擾導(dǎo)致程序跑飛到寫非易失性存儲(chǔ)器函數(shù)中，將導(dǎo)致數(shù)據(jù)存儲(chǔ)紊亂。一種可靠的辦法是將非易失性存儲(chǔ)器分成多個(gè)區(qū)，每個(gè)數(shù)據(jù)都將按照不同的形式寫入到這些分區(qū)中，需要進(jìn)行讀取時(shí)，同時(shí)讀出多份數(shù)據(jù)并進(jìn)行表決，取相同數(shù)目較多的那個(gè)值。

4.9軟件鎖

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

比如，向Flash寫一個(gè)數(shù)據(jù)，我們會(huì)判斷數(shù)據(jù)是否合法、寫入的地址是否合法，計(jì)算要寫入的扇區(qū)。之后調(diào)用寫Flash子程序，在這個(gè)子程序中，判斷扇區(qū)地址是否合法、數(shù)據(jù)長度是否合法，之后就要將數(shù)據(jù)寫入Flash。由于寫Flash語句是安全關(guān)鍵代碼，所以程序給這些語句上鎖：必須具有正確的鑰匙才可以寫Flash。這樣即使是程序跑飛到寫Flash子程序，也能大大降低誤寫的風(fēng)險(xiǎn)。

	/**************************************************************************** 
	* 名稱：RamToFlash() 
	* 功能：復(fù)制RAM的數(shù)據(jù)到FLASH，命令代碼51。 
	* 入口參數(shù)： dst        目標(biāo)地址，即FLASH起始地址。以512字節(jié)為分界 
	*           src        源地址，即RAM地址。地址必須字對齊 
	*           no         復(fù)制字節(jié)個(gè)數(shù)，為512/1024/4096/8192 
	*           ProgStart  軟件鎖標(biāo)志    
	* 出口參數(shù)：IAP返回值(paramout緩沖區(qū)) CMD_SUCCESS,SRC_ADDR_ERROR,DST_ADDR_ERROR, 
	SRC_ADDR_NOT_MAPPED,DST_ADDR_NOT_MAPPED,COUNT_ERROR,BUSY,未選擇扇區(qū) 
	****************************************************************************/  
	void  RamToFlash(uint32 dst, uint32 src, uint32 no,uint8 ProgStart)  
	{     
	    PLC_ASSERT("Sector number",(dst>=0x00040000)&&(dst<=0x0007FFFF));  
	    PLC_ASSERT("Copy bytes number is 512",(no==512));  
	    PLC_ASSERT("ProgStart==0xA5",(ProgStart==0xA5));  
	    paramin[0] = IAP_RAMTOFLASH;             // 設(shè)置命令字  
	    paramin[1] = dst;                        // 設(shè)置參數(shù)  
	    paramin[2] = src;  
	    paramin[3] = no;  
	    paramin[4] = Fcclk/1000;                      
	    if(ProgStart==0xA5)                     //只有軟件鎖標(biāo)志正確時(shí),才執(zhí)行關(guān)鍵代碼  
	    {  
	        iap_entry(paramin, paramout);       // 調(diào)用IAP服務(wù)程序                 
	        ProgStart=0;   
	    }  
	    else  
	    {  
	        paramout[0]=PROG_UNSTART;     
	    }  
	}

該程序段是編程lpc1778內(nèi)部Flash，其中調(diào)用IAP程序的函數(shù)iap_entry(paramin,paramout)是關(guān)鍵安全代碼，所以在執(zhí)行該代碼前，先判斷一個(gè)特定設(shè)置的安全鎖標(biāo)志ProgStart，只有這個(gè)標(biāo)志符合設(shè)定值，才會(huì)執(zhí)行編程Flash操作。如果因?yàn)橐馔獬绦蚺茱w到該函數(shù)，由于ProgStart標(biāo)志不正確，是不會(huì)對Flash進(jìn)行編程的。

4.10通信

通訊線上的數(shù)據(jù)誤碼相對嚴(yán)重，通訊線越長，所處的環(huán)境越惡劣，誤碼會(huì)越嚴(yán)重。拋開硬件和環(huán)境的作用，我們的軟件應(yīng)能識別錯(cuò)誤的通訊數(shù)據(jù)。對此有一些應(yīng)用措施：

制定協(xié)議時(shí)，限制每幀的字節(jié)數(shù)；

每幀字節(jié)數(shù)越多，發(fā)生誤碼的可能性就越大，無效的數(shù)據(jù)也會(huì)越多。對此以太網(wǎng)規(guī)定每幀數(shù)據(jù)不大于1500字節(jié)，高可靠性的CAN收發(fā)器規(guī)定每幀數(shù)據(jù)不得多于8字節(jié)，對于RS485，基于RS485鏈路應(yīng)用最廣泛的Modbus協(xié)議一幀數(shù)據(jù)規(guī)定不超過256字節(jié)。因此，建議制定內(nèi)部通訊協(xié)議時(shí)，使用RS485時(shí)規(guī)定每幀數(shù)據(jù)不超過256字節(jié)；

使用多種校驗(yàn)

編寫程序時(shí)應(yīng)使能奇偶校驗(yàn)，每幀超過16字節(jié)的應(yīng)用，建議至少編寫CRC16校驗(yàn)程序；

增加額外判斷

1)增加緩沖區(qū)溢出判斷。這是因?yàn)閿?shù)據(jù)接收多是在中斷中完成，編譯器檢測不出緩沖區(qū)是否溢出，需要手動(dòng)檢查，在上文介紹數(shù)據(jù)溢出一節(jié)中已經(jīng)詳細(xì)說明。

2)增加超時(shí)判斷。當(dāng)一幀數(shù)據(jù)接收到一半，長時(shí)間接收不到剩余數(shù)據(jù)，則認(rèn)為這幀數(shù)據(jù)無效，重新開始接收。可選，跟不同的協(xié)議有關(guān)，但緩沖區(qū)溢出判斷必須實(shí)現(xiàn)。這是因?yàn)閷τ谛枰獛^判斷的協(xié)議，上位機(jī)可能發(fā)送完幀頭后突然斷電，重啟后上位機(jī)是從新的幀開始發(fā)送的，但是下位機(jī)已經(jīng)接收到了上次未發(fā)送完的幀頭，所以上位機(jī)的這次幀頭會(huì)被下位機(jī)當(dāng)成正常數(shù)據(jù)接收。這有可能造成數(shù)據(jù)長度字段為一個(gè)很大的值，填滿該長度的緩沖區(qū)需要相當(dāng)多的數(shù)據(jù)（比如一幀可能1000字節(jié)），影響響應(yīng)時(shí)間；另一方面，如果程序沒有緩沖區(qū)溢出判斷，那么緩沖區(qū)很可能溢出，后果是災(zāi)難性的。

重傳機(jī)制

如果檢測到通訊數(shù)據(jù)發(fā)生了錯(cuò)誤，則要有重傳機(jī)制重新發(fā)送出錯(cuò)的幀。

4.11開關(guān)量輸入的檢測、確認(rèn)

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

4.12開關(guān)量輸出

開關(guān)信號簡單的一次輸出是不安全的，干擾信號可能會(huì)翻轉(zhuǎn)開關(guān)量輸出的狀態(tài)。采取重復(fù)刷新輸出可以有效防止電平的翻轉(zhuǎn)。

4.13初始化信息的保存和恢復(fù)

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

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

定義數(shù)據(jù)結(jié)構(gòu)：

    typedef struct {  
        uint8_t  lcd_command;           //LCD寄存器  
        uint8_t  lcd_get_value[8];      //初始化時(shí)寫入寄存器的值  
        uint8_t  lcd_value_num;         //初始化時(shí)寫入寄存器值的數(shù)目  
    }lcd_redu_list_struct; 

定義const修飾的結(jié)構(gòu)體變量，存儲(chǔ)LCD部分寄存器的初始值，這個(gè)初始值跟具體的應(yīng)用初始化有關(guān)，不一定是表中的數(shù)據(jù)，通常情況下，這個(gè)結(jié)構(gòu)體變量被存儲(chǔ)到Flash中。

	/*LCD部分寄存器設(shè)置值列表*/  
	lcd_redu_list_struct const lcd_redu_list_str[]=  
	{  
	  {SSD1963_Get_Address_Mode,{0x20}                                   ,1}, /*1*/ 
	  {SSD1963_Get_Pll_Mn      ,{0x3b,0x02,0x04}                         ,3}, /*2*/ 
	  {SSD1963_Get_Pll_Status  ,{0x04}                                   ,1}, /*3*/ 
	  {SSD1963_Get_Lcd_Mode    ,{0x24,0x20,0x01,0xdf,0x01,0x0f,0x00}     ,7}, /*4*/ 
	  {SSD1963_Get_Hori_Period ,{0x02,0x0c,0x00,0x2a,0x07,0x00,0x00,0x00},8}, /*5*/ 
	  {SSD1963_Get_Vert_Period ,{0x01,0x1d,0x00,0x0b,0x09,0x00,0x00}     ,7}, /*6*/ 
	  {SSD1963_Get_Power_Mode  ,{0x1c}                                   ,1}, /*7*/ 
	  {SSD1963_Get_Display_Mode,{0x03}                                   ,1}, /*8*/ 
	  {SSD1963_Get_Gpio_Conf   ,{0x0F,0x01}                              ,2}, /*9*/ 
	  {SSD1963_Get_Lshift_Freq ,{0x00,0xb8}                              ,2}, /*10*/
	}; 

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

	/** 
	* lcd 顯示冗余 
	* 每隔一段時(shí)間調(diào)用該程序一次 
	*/  
	void lcd_redu(void)  
	{  
	    uint8_t  tmp[8];  
	    uint32_t i,j;  
	    uint32_t lcd_init_flag;  
	    lcd_init_flag =0;  
	    for(i=0;i<sizeof(lcd_redu_list_str)/sizeof(lcd_redu_list_str[0]);i++)  
	    {  
	        LCD_SendCommand(lcd_redu_list_str[i].lcd_command);  
	        uyDelay(10);  
	        for(j=0;j<lcd_redu_list_str[i].lcd_value_num;j++)  
	        {  
	            tmp[j]=LCD_ReadData();  
	            if(tmp[j]!=lcd_redu_list_str[i].lcd_get_value[j])  
	            {  
	                lcd_init_flag=0x55;  
	                MY_DEBUGF(MENU_DEBUG,("讀lcd寄存器值與預(yù)期不符,命令為:0x%x,第%d個(gè)參數(shù),
	            該參數(shù)正確值為:0x%x,實(shí)際讀出值為:0x%x\n",lcd_redu_list_str[i].lcd_command,j+1,
	            lcd_redu_list_str[i].lcd_get_value[j],tmp[j]));  
	                goto handle_lcd_init;  
	            }  
	        }  
	    }  
	    handle_lcd_init:  
	    if(lcd_init_flag==0x55)  
	    {  
	        //重新初始化LCD  
	        //一些必要的恢復(fù)措施  
	    }     
	}  

4.14陷阱

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

4.15阻塞處理

有時(shí)候程序員會(huì)使用while(!flag);語句阻塞在此等待標(biāo)志flag改變，比如串口發(fā)送時(shí)用來等待一字節(jié)數(shù)據(jù)發(fā)送完成。這樣的代碼時(shí)存在風(fēng)險(xiǎn)的，如果因?yàn)槟承┰驑?biāo)志位一直不改變則會(huì)造成系統(tǒng)死機(jī)。

一個(gè)良好冗余的程序是設(shè)置一個(gè)超時(shí)定時(shí)器，超過一定時(shí)間后，強(qiáng)制程序退出while循環(huán)。

2003年8月11日發(fā)生的W32.Blaster.Worm蠕蟲事件導(dǎo)致全球經(jīng)濟(jì)損失高達(dá)5億美元，這個(gè)漏洞是利用了Windows分布式組件對象模型的遠(yuǎn)程過程調(diào)用接口中的一個(gè)邏輯缺陷：在調(diào)用GetMachineName()函數(shù)時(shí)，循環(huán)只設(shè)置了一個(gè)不充分的結(jié)束條件。

原代碼簡化如下所示：

	HRESULT GetMachineName ( WCHAR *pwszPath,  
	WCHARwszMachineName[MAX_COMPUTTERNAME_LENGTH_FQDN+1])  
	{  
	       WCHAR *pwszServerName = wszMachineName;  
	       WCHAR *pwszTemp = pwszPath + 2;  
	       while ( *pwszTemp != L'\\' )           /* 這句代碼循環(huán)結(jié)束條件不充分 */  
	             *pwszServerName++= *pwszTemp++;  
	       /*… */  
	}  

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

	HRESULT GetMachineName( WCHAR *pwszPath,  
	WCHARwszMachineName[MAX_COMPUTTERNAME_LENGTH_FQDN+1])  
	{  
	       WCHAR *pwszServerName = wszMachineName;  
	       WCHAR *pwszTemp = pwszPath + 2;  
	       WCHAR *end_addr = pwszServerName +MAX_COMPUTTERNAME_LENGTH_FQDN；  
	       while (（*pwszTemp != L'\\' ) && (*pwszTemp != L'\0')  
	&& (pwszServerName<end_addr))  /*充分終止條件*/  
	             *pwszServerName++= *pwszTemp++;  
	       /*… */  
	} 

5.測試，再測試

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

優(yōu)質(zhì)嵌入式C程序跟優(yōu)質(zhì)的基礎(chǔ)元素關(guān)系密切，可以將函數(shù)作為基礎(chǔ)元素，我們的測試正是從最基本的函數(shù)開始。判斷哪些函數(shù)需要測試需要一定的經(jīng)驗(yàn)積累，雖然代碼行數(shù)跟邏輯復(fù)雜度并不成正比，但如果你不能判斷某個(gè)函數(shù)是否要測試，一個(gè)簡單粗暴的方法是：當(dāng)函數(shù)有效代碼超過20行，就測試它。

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

5.1使用硬件調(diào)試器測試

使用硬件調(diào)試器（比如J-link）測試是最通用的手段?？梢詥尾竭\(yùn)行、設(shè)置斷點(diǎn)，可以很方便的查看當(dāng)前寄存器、變量的值。在尋找缺陷方面，使用硬件調(diào)試器測試是最簡單卻又最有效的手段。

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

5.2有些缺陷很難纏

就像沒有一種方法能完美解決所有問題，在實(shí)際項(xiàng)目中，硬件調(diào)試器也有難以觸及的地方?？梢耘e幾個(gè)例子說明：

使用了比較大的協(xié)議棧，需要跟進(jìn)到協(xié)議棧內(nèi)部調(diào)試的缺陷

比如公司使用lwIP協(xié)議棧，如果跟蹤數(shù)據(jù)的處理過程，需要從接收數(shù)據(jù)開始一直到應(yīng)用層處理數(shù)據(jù)，之間會(huì)經(jīng)過驅(qū)動(dòng)層、IP層、TCP層和應(yīng)用層，會(huì)經(jīng)過十幾個(gè)文件幾十個(gè)函數(shù)，使用硬件調(diào)試器跟蹤費(fèi)時(shí)費(fèi)力；

具有隨機(jī)性的缺陷

有一些缺陷，可能是不定時(shí)出現(xiàn)的，有可能是幾分鐘出現(xiàn)，也有可能是幾個(gè)小時(shí)甚至幾天才出現(xiàn)，像這樣的缺陷很難用硬件調(diào)試器捕捉到；

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

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

除了測試缺陷需要，有時(shí)候我們在做穩(wěn)定性測試時(shí)，需要知道軟件每時(shí)每刻運(yùn)行到那些分支、執(zhí)行了哪些操作、我們關(guān)心的變量當(dāng)前值是什么等等，這些都表明，我們還需要一種和硬件調(diào)試器互補(bǔ)的測試手段。

這個(gè)測試手段就是在程序中增加額外調(diào)試語句，當(dāng)程序運(yùn)行時(shí)，通過這些調(diào)試語句將運(yùn)行信息輸出到可以方便查看的設(shè)備上，可以是PC機(jī)、LCD顯示屏、存儲(chǔ)卡等等。

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

必須簡單易用

我們在初學(xué)C語言的時(shí)候，都接觸過printf函數(shù)，這個(gè)函數(shù)可以方便的輸出信息，并可以將各種變量格式化為指定格式的字符串，我們應(yīng)當(dāng)提供類似的函數(shù)；

調(diào)試語句必須方便的從代碼中移除

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

5.2.1簡單易用的調(diào)試函數(shù)

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

I>初始化串口

II>重構(gòu)fputc函數(shù)，printf函數(shù)會(huì)調(diào)用fputc函數(shù)執(zhí)行底層串口的數(shù)據(jù)發(fā)送。

	/** 
	  * @brief  將C庫中的printf函數(shù)重定向到指定的串口. 
	  * @param  ch:要發(fā)送的字符 
	  * @param  f :文件指針 
	  */  
	int fputc(int ch, FILE *f)  
	{  
	    /*這里是一個(gè)跟硬件相關(guān)函數(shù),將一個(gè)字符寫到UART */  
	    //舉例:USART_SendData(UART_COM1, (uint8_t) ch);  
	    return ch;  
	} 

III>在Options for Targer窗口，Targer標(biāo)簽欄下，勾選Use MicroLIB前的復(fù)選框以便避免使用半主機(jī)功能。（注：標(biāo)準(zhǔn)C庫printf函數(shù)默認(rèn)開啟半主機(jī)功能，如果非要使用標(biāo)準(zhǔn)C庫，請自行查閱資料）

2)構(gòu)建自己的調(diào)試函數(shù)

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

  #include <stdarg.h>               /*支持函數(shù)接收不定量參數(shù)*/  
  const char * const g_pcHex = "0123456789abcdef";  
  /** 
  * 簡介:   一個(gè)簡單的printf函數(shù),支持\%c, \%d, \%p, \%s, \%u,\%x, and \%X. 
  */  
  void UARTprintf(const uint8_t *pcString, ...)  
  {  
      uint32_t ulIdx;  
      uint32_t ulValue;       //保存從不定量參數(shù)堆棧中取出的數(shù)值型變量  
      uint32_t ulPos, ulCount;  
      uint32_t ulBase;        //保存進(jìn)制基數(shù),如十進(jìn)制則為10,十六進(jìn)制數(shù)則為16  
      uint32_t ulNeg;         //為1表示從變量為負(fù)數(shù)  
      uint8_t *pcStr;         //保存從不定量參數(shù)堆棧中取出的字符型變量  
      uint8_t pcBuf[32];      //保存數(shù)值型變量字符化后的字符  
      uint8_t cFill;          //'%08x'->不足8個(gè)字符用'0'填充,cFill='0';    
                              //'%8x '->不足8個(gè)字符用空格填充,cFill=' '  
      va_list vaArgP;  
      va_start(vaArgP, pcString);  
      while(*pcString)  
      {  
          // 首先搜尋非%核字符串結(jié)束字符  
          for(ulIdx = 0; (pcString[ulIdx] != '%') && (pcString[ulIdx] != '\0'); ulIdx++)  
          { }  
          UARTwrite(pcString, ulIdx);  
    
          pcString += ulIdx;  
          if(*pcString == '%')  
          {  
              pcString++;  
    
              ulCount = 0;  
              cFill = ' ';  
  again:  
              switch(*pcString++)  
              {  
                  case '0': case '1': case '2': case '3': case '4':  
                  case '5': case '6': case '7': case '8': case '9':  
                  {  
                      // 如果第一個(gè)數(shù)字為0, 則使用0做填充,則用空格填充)  
                      if((pcString[-1] == '0') && (ulCount == 0))  
                      {  
                          cFill = '0';  
                      }  
                      ulCount *= 10;  
                      ulCount += pcString[-1] - '0';  
                      goto again;  
                  }  
                  case 'c':          
                  {  
                      ulValue = va_arg(vaArgP, unsigned long);  
                      UARTwrite((unsigned char *)&ulValue, 1);  
                      break;  
                  }  
                  case 'd':     
                  {  
                      ulValue = va_arg(vaArgP, unsigned long);  
                      ulPos = 0;  
                        
                      if((long)ulValue < 0)  
                      {  
                          ulValue = -(long)ulValue;  
                          ulNeg = 1;  
                      }  
                      else  
                      {  
                          ulNeg = 0;  
                      }  
                      ulBase = 10;          
                      goto convert;  
                  }  
                  case 's':  
                  {  
                      pcStr = va_arg(vaArgP, unsigned char *);  
    
                      for(ulIdx = 0; pcStr[ulIdx] != '\0'; ulIdx++)  
                      {  
                      }  
                      UARTwrite(pcStr, ulIdx);  
    
                      if(ulCount > ulIdx)  
                      {  
                          ulCount -= ulIdx;  
                          while(ulCount--)  
                          {  
                              UARTwrite(" ", 1);  
                          }  
                      }  
                      break;  
                  }  
                  case 'u':  
                  {  
                      ulValue = va_arg(vaArgP, unsigned long);  
                      ulPos = 0;  
                      ulBase = 10;  
                      ulNeg = 0;  
                      goto convert;  
  	                }  
  	                case 'x': case 'X': case 'p':  
  	                {  
  	                    ulValue = va_arg(vaArgP, unsigned long);  
  	                    ulPos = 0;  
  	                    ulBase = 16;  
  	                    ulNeg = 0;  
  	         convert:   //將數(shù)值轉(zhuǎn)換成字符  
  	                    for(ulIdx = 1; (((ulIdx * ulBase) <= ulValue) &&(((ulIdx * ulBase) / ulBase) == ulIdx)); ulIdx *= ulBase, ulCount--)       
  	                    { }  
  	                    if(ulNeg)  
  	                    {  
  	                        ulCount--;                        
  	                    }  
  	                    if(ulNeg && (cFill == '0'))  
  	                    {  
  	                        pcBuf[ulPos++] = '-';  
  	                        ulNeg = 0;  
  	                    }  
  	                    if((ulCount > 1) && (ulCount < 16))  
  	                    {  
  	                        for(ulCount--; ulCount; ulCount--)  
  	                        {  
  	                            pcBuf[ulPos++] = cFill;  
  	                        }  
  	                    }  
  	  
  	                    if(ulNeg)  
  	                    {  
  	                        pcBuf[ulPos++] = '-';  
  	                    }  
  	  
  	                    for(; ulIdx; ulIdx /= ulBase)  
  	                    {  
  	                        pcBuf[ulPos++] = g_pcHex[(ulValue / ulIdx) % ulBase]; 
  	                    }  
  	                    UARTwrite(pcBuf, ulPos);  
  	                    break;  
  	                }  
  	                case '%':  
  	                {  
  	                    UARTwrite(pcString - 1, 1);                    
  	                    break;  
  	                }  
  	                default:  
  	                {                      
  	                    UARTwrite("ERROR", 5);                    
  	                    break;  
  	                }  
  	            }  
  	        }  
  	    }  
  	    //可變參數(shù)處理結(jié)束  
  	    va_end(vaArgP);  
  	} 

5.2.2對調(diào)試函數(shù)進(jìn)一步封裝

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

	#ifdef MY_DEBUG  
	#define MY_DEBUGF(message) do { \  
	                                  {UARTprintf message;} \  
	                               } while(0)  
	#else    
	#define MY_DEBUGF(message)    
	#endif /* PLC_DEBUG */

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

6.編程思想

6.1編程風(fēng)格

《計(jì)算機(jī)程序的構(gòu)造和解釋》一書在開篇寫到：程序?qū)懗鰜硎墙o人看的，附帶能在機(jī)器上運(yùn)行。

6.1.1整潔的樣式

使用什么樣的編碼樣式一直都頗具爭議性的，比如縮進(jìn)和大括號的位置。因?yàn)榫幋a的樣式也會(huì)影響程序的可讀性，面對一個(gè)亂放括號、對齊都不一致的源碼，我們很難提起閱讀它的興趣。我們總要看別人的程序，如果彼此編碼樣式相近，讀起源碼來會(huì)覺得比較舒適。但是編碼風(fēng)格的問題是主觀的，永遠(yuǎn)不可能在編碼風(fēng)格上達(dá)成統(tǒng)一意見。因此只要你的編碼樣式整潔、結(jié)構(gòu)清晰就足夠了。除此之外，對編碼樣式再?zèng)]有其它要求。

提出匈牙利命名法的程序員、前微軟首席架構(gòu)師Charles Simonyi說：我覺得代碼清單帶給人的愉快同整潔的家差不多。你一眼就能分辨出家里是雜亂無章還是整潔如新。這也許意義不大。因?yàn)楣馐欠孔诱麧嵳f明不了什么，它仍可能藏污納垢！但是第一印象很重要，它至少反映了程序的某些方面。我敢打賭，我在3米開外就能看出程序拙劣與否。我也許沒法保證它很不錯(cuò)，但如果從3米外看起來就很糟，我敢保證這程序?qū)懙貌挥眯摹Ｈ绻麑懙貌挥眯?，那它在邏輯上也許就不會(huì)優(yōu)美。

6.1.2清晰的命名

變量、函數(shù)、宏等等都需要命名，清晰的命名是優(yōu)秀代碼的特點(diǎn)之一。命名的要點(diǎn)之一是名稱應(yīng)能清晰的描述這個(gè)對象，以至于一個(gè)初級程序員也能不費(fèi)力的讀懂你的代碼邏輯。我們寫的代碼主要給誰看是需要思考的：給自己、給編譯器還是給別人看？我覺得代碼最主要的是給別人看，其次是給自己看。如果沒有一個(gè)清晰的命名，別人在維護(hù)你的程序時(shí)很難在整個(gè)全貌上看清代碼，因?yàn)橐涀∈鄠€(gè)以上的糟糕命名的變量是件非常困難的事；而且一段時(shí)間之后你回過頭來看自己的代碼，很有可能不記得那些糟糕命名的變量是什么意思。

為對象起一個(gè)清晰的名字并不是簡單的事情。首先能認(rèn)識到名稱的重要性需要有一個(gè)過程，這也許跟譚式C程序教材被大學(xué)廣泛使用有關(guān)：滿書的a、b、c、x、y、z變量名是很難在關(guān)鍵的初學(xué)階段給人傳達(dá)優(yōu)秀編程思想的；其次如何恰當(dāng)?shù)臑閷ο竺埠苡刑魬?zhàn)性，要準(zhǔn)確、無歧義、不羅嗦，要對英文有一定水平，所有這些都要滿足時(shí)，就會(huì)變得很困難；此外，命名還需要考慮整體一致性，在同一個(gè)項(xiàng)目中要有統(tǒng)一的風(fēng)格，堅(jiān)持這種風(fēng)格也并不容易。

關(guān)于如何命名，Charles Simonyi說：面對一個(gè)具備某些屬性的結(jié)構(gòu)，不要隨隨便便地取個(gè)名字，然后讓所有人去琢磨名字和屬性之間有什么關(guān)聯(lián)，你應(yīng)該把屬性本身，用作結(jié)構(gòu)的名字。

6.1.3恰當(dāng)?shù)淖⑨?/h4>

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

這里建議使用良好的編碼樣式和清晰的命名來減少注釋，對模塊、函數(shù)、變量、數(shù)據(jù)結(jié)構(gòu)、算法和關(guān)鍵代碼做注釋，應(yīng)重視注釋的質(zhì)量而不是數(shù)量。如果你需要一大段注釋才能說清楚程序做什么，那么你應(yīng)該注意了：是否是因?yàn)槌绦蜃兞棵粔蚯逦蛘叽a邏輯過于混亂，這個(gè)時(shí)候你應(yīng)該考慮的可能就不是注釋，而是如何精簡這個(gè)程序了。

6.2數(shù)據(jù)結(jié)構(gòu)

數(shù)據(jù)結(jié)構(gòu)是程序設(shè)計(jì)的基礎(chǔ)。在設(shè)計(jì)程序之前，應(yīng)該先考慮好所需要的數(shù)據(jù)結(jié)構(gòu)。

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

開發(fā)過以太網(wǎng)和操作系統(tǒng)SDS 940的Butler Lampson：（程序員）最重要的素質(zhì)是能夠把問題的解決方案組織成容易操控的結(jié)構(gòu)。

開發(fā)CP/M操作系統(tǒng)的Gary.A：如果不能確認(rèn)數(shù)據(jù)結(jié)構(gòu)是正確的，我是決不會(huì)開始編碼的。我會(huì)先畫數(shù)據(jù)結(jié)構(gòu)，然后花很長時(shí)間思考數(shù)據(jù)結(jié)構(gòu)。在確定數(shù)據(jù)結(jié)構(gòu)之后我就開始寫一些小段的代碼，并不斷地改善和監(jiān)測。在編碼過程中進(jìn)行測試可以確保所做的修改是局部的，并且如果有什么問題的話，能夠馬上發(fā)現(xiàn)。

微軟創(chuàng)始人比爾·蓋茨：編寫程序最重要的部分是設(shè)計(jì)數(shù)據(jù)結(jié)構(gòu)。接下來重要的部分是分解各種代碼塊。

編寫世界上第一個(gè)電子表格軟件的Dan Bricklin：在我看來，寫程序最重要的部分是設(shè)計(jì)數(shù)據(jù)結(jié)構(gòu)，此外，你還必須知道人機(jī)界面會(huì)是什么樣的。

我們舉個(gè)例子來說明。在介紹防御性編程的時(shí)候，提到公司使用的LCD顯示屏抗干擾能力一般，為了提高LCD的穩(wěn)定性，需要定期讀出LCD內(nèi)部的關(guān)鍵寄存器值，然后跟存在Flash中的初始值相比較。需要讀出的LCD寄存器有十多個(gè)，從每個(gè)寄存器讀出的值也不盡相同，從1個(gè)到8個(gè)字節(jié)都有可能。如果不考慮數(shù)據(jù)結(jié)構(gòu)，編寫出的程序?qū)?huì)很冗長。

	void lcd_redu(void)  
	{  
	    讀第一個(gè)寄存器值;  
	    if(第一個(gè)寄存器值==Flash存儲(chǔ)值)  
	    {  
	        讀第二個(gè)寄存器值;  
	        if(第二個(gè)寄存器值==Flash存儲(chǔ)值)  
	        {  
	            ...  
	            讀第十個(gè)寄存器值;  
	            if(第十個(gè)寄存器值==Flash存儲(chǔ)值)  
	            {  
	                返回;  
	            }  
	            else  
	            {  
	                重新初始化LCD;  
	            }  
	        }  
	        else  
	        {  
	            重新初始化LCD;  
	        }  
	    }  
	    else  
	    {  
	        重新初始化LCD;  
	    }  
	}  

我們分析這個(gè)過程，發(fā)現(xiàn)能提取出很多相同的元素，比如每次讀LCD寄存器都需要該寄存器的命令號，都會(huì)經(jīng)過讀寄存器、判斷值是否相同、處理異常情況這一過程。所以我們可以提取一些相同的元素，組織成數(shù)據(jù)結(jié)構(gòu)，用統(tǒng)一的方法去處理這些數(shù)據(jù)，將數(shù)據(jù)與處理過程分開來。

我們可以先提取相同的元素，將之組織成數(shù)據(jù)結(jié)構(gòu)：

	typedef struct {  
	    uint8_t  lcd_command;           //LCD寄存器  
	    uint8_t  lcd_get_value[8];      //初始化時(shí)寫入寄存器的值  
	    uint8_t  lcd_value_num;         //初始化時(shí)寫入寄存器值的數(shù)目  
	}lcd_redu_list_struct;  

這里lcd_command表示的是LCD寄存器命令號；lcd_get_value是一個(gè)數(shù)組，表示寄存器要初始化的值，這是因?yàn)閷τ谝粋€(gè)LCD寄存器，可能要初始化多個(gè)字節(jié)，這是硬件特性決定的；lcd_value_num是指一個(gè)寄存器要多少個(gè)字節(jié)的初值，這是因?yàn)槊恳粋€(gè)寄存器的初值數(shù)目是不同的，我們用同一個(gè)方法處理數(shù)據(jù)時(shí)，是需要這個(gè)信息的。

就本例而言，我們將要處理的數(shù)據(jù)都是事先固定的，所以定義好數(shù)據(jù)結(jié)構(gòu)后，我們可以將這些數(shù)據(jù)組織成表格：

  /*LCD部分寄存器設(shè)置值列表*/  
  lcd_redu_list_struct const lcd_redu_list_str[]=  
  {  
    {SSD1963_Get_Address_Mode,{0x20}                                   ,1}, /*1*/ 
    {SSD1963_Get_Pll_Mn      ,{0x3b,0x02,0x04}                         ,3}, /*2*/ 
    {SSD1963_Get_Pll_Status  ,{0x04}                                   ,1}, /*3*  
    {SSD1963_Get_Lcd_Mode    ,{0x24,0x20,0x01,0xdf,0x01,0x0f,0x00}     ,7}, /*4*/ 
    {SSD1963_Get_Hori_Period ,{0x02,0x0c,0x00,0x2a,0x07,0x00,0x00,0x00},8}, /*5*/ 
    {SSD1963_Get_Vert_Period ,{0x01,0x1d,0x00,0x0b,0x09,0x00,0x00}     ,7}, /*6*/ 
    {SSD1963_Get_Power_Mode  ,{0x1c}                                   ,1}, /*7*/ 
    {SSD1963_Get_Display_Mode,{0x03}                                   ,1}, /*8*/ 
    {SSD1963_Get_Gpio_Conf   ,{0x0F,0x01}                              ,2}, /*9*/ 
    {SSD1963_Get_Lshift_Freq ,{0x00,0xb8}                              ,2}, /*10* 
  };  

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

	/** 
	* lcd 顯示冗余 
	* 每隔一段時(shí)間調(diào)用該程序一次 
	*/  
	void lcd_redu(void)  
	{  
	    uint8_t  tmp[8];  
	    uint32_t i,j;  
	    uint32_t lcd_init_flag;  
	    lcd_init_flag =0;  
	    for(i=0;i<sizeof(lcd_redu_list_str)/sizeof(lcd_redu_list_str[0]);i++)  
	    {  
	        LCD_SendCommand(lcd_redu_list_str[i].lcd_command);  
	        uyDelay(10);  
	        for(j=0;j<lcd_redu_list_str[i].lcd_value_num;j++)  
	        {  
	            tmp[j]=LCD_ReadData();  
	            if(tmp[j]!=lcd_redu_list_str[i].lcd_get_value[j])  
	            {  
	                lcd_init_flag=0x55;  
	                //一些調(diào)試語句，打印出錯(cuò)的具體信息
	                goto handle_lcd_init;  
	            }  
	        }  
	    }  
	    handle_lcd_init:  
	    if(lcd_init_flag==0x55)  
	    {  
	        //重新初始化LCD  
	        //一些必要的恢復(fù)措施  
	    }     
	}  

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

7.總結(jié)和閱讀書目

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

7.1關(guān)于語言特性

• Stephen Prata 著 云巔工作室 譯 《C Primer Plus（第五版）中文版》
• Andrew Koenig 著 高巍 譯 《C陷阱與缺陷》
• Peter Van Der Linden 著 徐波 譯 《C專家編程》
• 陳正沖 編著 《C語言深度解剖》

7.2關(guān)于編譯器

• 杜春雷 編著 《ARM體系結(jié)構(gòu)與編程》
• Keil MDK 編譯器幫助手冊

7.3關(guān)于防御性編程

• MISRA-C-:2004 Guidelines for the use of the C language in criticalsystems
• Robert C.Seacord 著 徐波 譯 《C安全編碼標(biāo)準(zhǔn)》

7.4關(guān)于編程思想

• Pete Goodliffe 著 韓江、陳玉 譯 《編程匠藝---編寫卓越的代碼》
• Susan Lammers 著 李琳驍、吳詠煒、張菁《編程大師訪談錄

以上就是嵌入式C程序優(yōu)質(zhì)編寫教程的詳細(xì)內(nèi)容，更多關(guān)于嵌入式C程序編寫的資料請關(guān)注腳本之家其它相關(guān)文章！