電子發燒友App
?設備的可靠性涉及多個方面：穩定的硬件、優秀的軟件架構、嚴格的測試以及市場和時間的檢驗等等。
這里著重談一下作者自己對嵌入式軟件可靠性設計的一些理解，通過一定的技巧和方法提高軟件可靠性。
1、判錯
工欲善其事必先利其器。判錯的最終目的是用來暴露設計中的Bug并加以改正，所以將錯誤信息提供給編程者是必要的。
有時候需要將故障信息儲存于非易失性存儲器中，便于查看。這里以使用串口打印錯誤信息到PC顯示屏為例，來說明一般需要顯示什么信息。
編寫或移植一個類似C標準庫中的printf函數，可以格式化打印字符、字符串、十進制整數、十六進制整數。這里稱為UARTprintf（）。
?
unsigned?int?WriteData(unsigned?int?addr) { ?if((addr>=?BASE_ADDR)&&(addr<=END_ADDR))? ????{ ????????…/*地址合法,進行處理*/ ?}? ????else? ????{?/*地址錯誤，打印錯誤信息*/ ??UARTprintf?("文件%s的第?%d?行寫數據時發生地址錯誤,錯誤地址為:0x%x ",__FILE__,__LINE__,addr); ??…/*錯誤處理代碼*/ ?}
?
假設UARTprintf()函數位于main.c模塊的第256行，并且WriteData()函數在讀數據時傳遞了錯誤地址0x00000011，則會執行UARTprintf()函數，打印如下所示的信息：
文件main.c的第256行寫數據時發生地址錯誤，錯誤地址為：0x00000011。類似這樣的信息會有助于程序員定位分析錯誤產生的根源，更快的消除Bug。
2、判斷實參是否合法
程序員可能無意識的傳遞了錯誤參數；外界的強干擾可能將傳遞的參數修改掉，或者使用隨機參數意外的調用函數，因此在執行函數主體前，需要先確定實參是否合法。
?
int?exam_fun(?unsigned?char?*str?)?
{?
????if(?str?!=?NULL?)
????{?//??檢查“假設指針不為空”這個條件?
????????...?//正常處理代碼
????}?
????else?
????{
????????UARTprintf(…);?//?打印錯誤信息
????????…//處理錯誤代碼
????}
}
?
3、仔細檢查函數的返回值
對函數返回的錯誤碼，要進行全面仔細處理，必要時做錯誤記錄。
?
char?*DoSomething(…)
{
????char?*?p;
????p=malloc(1024);
????if(p==NULL)?
????{?/*對函數返回值作出判斷*/
????????UARTprintf(…);?/*打印錯誤信息*/
????????return?NULL;
????}
????retuen?p;
}
?
4、防止指針越界
如果動態計算一個地址時，要保證被計算的地址是合理的并指向某個有意義的地方。特別對于指向一個結構或數組的內部的指針，當指針增加或者改變后仍然指向同一個結構或數組。
5、防止數組越界
數組越界的問題前文已經講述的很多了，由于C不會對數組進行有效的檢測，因此必須在應用中顯式的檢測數組越界問題。下面的例子可用于中斷接收通訊數據。
?
#define?REC_BUF_LEN?100
unsigned?char?RecBuf[REC_BUF_LEN];
…?//其它代碼
void?Uart_IRQHandler(void)
{
????static?int?RecCount=0;???//接收數據長度計數器
????…???????//其它代碼
????if(RecCount?
?
在使用一些庫函數時，同樣需要對邊界進行檢查：
?
#define?REC_BUF_LEN?100
unsigned?char?RecBuf[REC_BUF_LEN];
?
if(len
?
6、數學算數運算
檢測除數是否為零
檢測運算溢出情況
有符號整數除法，僅檢測除數為零就夠了嗎?
兩個整數相除，除了要檢測除數是否為零外，還要檢測除法是否溢出。對于一個signed long類型變量，它能表示的數值范圍為：-2147483648 ~ +2147483647，如果讓-2147483648 / -1，那么結果應該是+ 2147483648，但是這個結果已經超出了signed long所能表示的范圍了。
?
#include?
signed?long?sl1,sl2,result;
/*初始化sl1和sl2*/
if((sl2==0)||((sl1==LONG_MIN)?&&?(sl2==-1)))
{
????//處理錯誤
}?
else?
{
????result?=?sl1?/?sl2;
}
?
加法溢出檢測：
a）無符號加法
?
#include?
unsigned?int?a,b,result;
/*初始化a，b*/
if(UINT_MAX-a
?
b）有符號加法
?
#include?
signed?int?a,b,result;
/*初始化a，b?*/
if((a>0?&&?INT_MAX-ab))
{
?//處理溢出
}?
else?
{
?result=a+b;
}
?
乘法溢出檢測：
a）無符號乘法
?
#include?
unsigned?int?a,b,result;
/*初始化a，b*/
if((a!=0)?&&?(UINT_MAX/a
?
b）有符號乘法
?
#include?
signed?int?a,b,tmp,result;
/*初始化a，b*/
tmp=a?*?b;
if(a!=0?&&?tmp/a!=b)
{
//
}?
else?
{
?result=tmp;
}
?
7、運行時錯誤檢查
運行時錯誤檢查是C 程序員需要加以特別的注意的，這是因為C語言在提供任何運行時檢測方面能力較弱。對于要求可靠性較高的軟件來說，動態檢測是必需的。
因此C 程序員需要謹慎考慮的問題是，在任何可能出現運行時錯誤的地方增加代碼的動態檢測。大多數的動態檢測與應用緊密相關，在程序設計過程中要根據系統需求設置動態代碼檢測。
8、編譯器語義檢查
為了更簡單的設計編譯器，目前幾乎所有編譯器的語義檢查都比較弱小，加之為了獲得更快的執行效率，C語言被設計的足夠靈活且幾乎不進行任何運行時檢查，比如數組越界、指針是否合法、運算結果是否溢出等等。
C語言足夠靈活，對于一個數組a[30]，它允許使用像a[-1]這樣的形式來快速獲取數組首元素所在地址前面的數據；允許將一個常數強制轉換為函數指針，使用代碼( * ((void( * )())0))()來調用位于0地址的函數。
C語言給了程序員足夠的自由，但也由程序員承擔濫用自由帶來的責任。下面的兩個例子都是死循環，如果在不常用分支中出現類似代碼，將會造成看似莫名其妙的死機或者重啟。
?
a.?unsigned?char?i；??????????????????
???for(i=0;i<256;i++)??{…?}??????????????
b.?unsigned?chari;
???for(i=10;i>=0;i--)?{?…?}
?
對于無符號char類型，表示的范圍為0~255，所以無符號char類型變量i永遠小于256（第一個for循環無限執行），永遠大于等于0（第二個for循環無線執行）。
需要說明的是，賦值代碼i=256是被C語言允許的，即使這個初值已經超出了變量i可以表示的范圍。C語言會千方百計的為程序員創造出錯的機會，可見一斑。
假如你在if語句后誤加了一個分號改變了程序邏輯，編譯器也會很配合的幫忙掩蓋，甚至連警告都不提示。代碼如下：
?
if(a>b);??????????//這里誤加了一個分號
a=b;???????????????//這句代碼一直被執行
?
不但如此，編譯器還會忽略掉多余的空格符和換行符，就像下面的代碼也不會給出足夠提示：
?
if(n<3)
return????//這里少加了一個分號
logrec.data=x[0];
logrec.time=x[1];
logrec.code=x[2];
?
這段代碼的本意是n<3時程序直接返回，由于程序員的失誤，return少了一個結束分號。編譯器將它翻譯成返回表達式logrec.data=x[0]的結果，return后面即使是一個表達式也是C語言允許的。這樣當n>=3時，表達式logrec.data=x[0];就不會被執行，給程序埋下了隱患。
可以毫不客氣的說，弱小的編譯器語義檢查在很大程度上縱容了不可靠代碼可以肆無忌憚的存在。
上文曾提到數組常常是引起程序不穩定的重要因素，程序員往往不經意間就會寫數組越界。一位同事的代碼在硬件上運行，一段時間后就會發現LCD顯示屏上的一個數字不正常的被改變。
經過一段時間的調試，問題被定位到下面的一段代碼中：
?
int?SensorData[30];
for(i=30;i>0;i--)
{
????SensorData[i]=…;
????…
}
?
這里聲明了擁有30個元素的數組，不幸的是for循環代碼中誤用了本不存在的數組元素SensorData[30]，但C語言卻默許這么使用，并欣然的按照代碼改變了數組元素SensorData[30]所在位置的值， SensorData[30]所在的位置原本是一個LCD顯示變量，這正是顯示屏上的那個值不正常被改變的原因。真慶幸這么輕而易舉的發現了這個Bug。
9、關鍵數據多區備份，取數據采用“表決法”
RAM中的數據在受到干擾情況下有可能被改變，對于系統關鍵數據必須進行保護。關鍵數據包括全局變量、靜態變量以及需要保護的數據區域。
數據備份與原數據不應該處于相鄰位置，因此不應由編譯器默認分配備份數據位置，而應該由程序員指定區域存儲。
可以將RAM分為3個區域，第一個區域保存原碼，第二個區域保存反碼，第三個區域保存異或碼，區域之間預留一定量的“空白”RAM作為隔離?？梢允褂镁幾g器的“分散加載”機制將變量分別存儲在這些區域。需要進行讀取時，同時讀出3份數據并進行表決，取至少有兩個相同的那個值。
假如設備的RAM從0x1000_0000開始，我需要在RAM的0x1000_0000~0x10007FFF內存儲原碼，在0x1000_9000~0x10009FFF內存儲反碼，在0x1000_B000~0x1000BFFF內存儲0xAA的異或碼，編譯器的分散加載可以設置為：
?
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)
}
}
?
如果一個關鍵變量需要多處備份，可以按照下面方式定義變量，將三個變量分別指定到三個不連續的RAM區中，并在定義時按照原碼、反碼、0xAA的異或碼進行初始化。
?
uint32?plc_pc=0;?//原碼
__attribute__((section("MY_BK1")))?uint32?plc_pc_not=~0x0;?//反碼
__attribute__((section("MY_BK2")))?uint32?plc_pc_xor=0x0^0xAAAAAAAA;?//異或碼
?
當需要寫這個變量時，這三個位置都要更新；讀取變量時，讀取三個值做判斷，取至少有兩個相同的那個值。
為什么選取異或碼而不是補碼？這是因為MDK的整數是按照補碼存儲的，正數的補碼與原碼相同，在這種情況下，原碼和補碼是一致的，不但起不到冗余作用，反而對可靠性有害。比如存儲的一個非零整數區因為干擾，RAM都被清零，由于原碼和補碼一致，按照3取2的“表決法”，會將干擾值0當做正確的數據。
10、非易失性存儲器的數據存儲
非易失性存儲器包括但不限于Flash、EEPROM、鐵電。僅僅將寫入非易失性存儲器中的數據再讀出校驗是不夠的。強干擾情況下可能導致非易失性存儲器內的數據錯誤，在寫非易失性存儲器的期間系統掉電將導致數據丟失，因干擾導致程序跑飛到寫非易失性存儲器函數中，將導致數據存儲紊亂。
一種可靠的辦法是將非易失性存儲器分成多個區，每個數據都將按照不同的形式寫入到這些分區中，需要進行讀取時，同時讀出多份數據并進行表決，取相同數目較多的那個值。
對于因干擾導致程序跑飛到寫非易失性存儲器函數，還應該配合軟件鎖以及嚴格的入口檢驗，單單依靠寫數據到多個區是不夠的也是不明智的，應該在源頭進行阻截。
11、軟件鎖
軟件鎖可以實現但不局限于環環相扣。對于初始化序列或者有一定先后順序的函數調用，為了保證調用順序或者確保每個函數都被調用，我們可以使用環環相扣，實質上這也是一種軟件鎖。此外對于一些安全關鍵代碼語句（是語句，而不是函數），可以給它們設置軟件鎖，只有持有特定鑰匙的，才可以訪問這些關鍵代碼。
比如，向Flash寫一個數據，我們會判斷數據是否合法、寫入的地址是否合法，計算要寫入的扇區。之后調用寫Flash子程序，在這個子程序中，判斷扇區地址是否合法、數據長度是否合法，之后就要將數據寫入Flash。由于寫Flash語句是安全關鍵代碼，所以程序給這些語句上鎖：必須具有正確的鑰匙才可以寫Flash。這樣即使是程序跑飛到寫Flash子程序，也能大大降低誤寫的風險。
?
/***************************************************************
*?名稱：RamToFlash()
*?功能：復制RAM的數據到FLASH，命令代碼51。
*?入口參數：dst 目標地址，即FLASH起始地址。以512字節為分界
* src 源地址，即RAM地址。地址必須字對齊
*?no?復制字節個數，為512/1024/4096/8192
*?ProgStart?軟件鎖標志
*?出口參數：IAP返回值(paramout緩沖區) CMD_SUCCESS,SRC_ADDR_ERROR,DST_ADDR_ERROR,
SRC_ADDR_NOT_MAPPED,DST_ADDR_NOT_MAPPED,COUNT_ERROR,BUSY,未選擇扇區
****************************************************************/
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;?//?設置命令字
????paramin[1]?=?dst;?//?設置參數
????paramin[2]?=?src;
????paramin[3]?=?no;
????paramin[4]?=?Fcclk/1000;
????if(ProgStart==0xA5)?//只有軟件鎖標志正確時，才執行關鍵代碼
????{
????????iap_entry(paramin,?paramout);?//?調用IAP服務程序
????????ProgStart=0;
????}
????else
????{
?????paramout[0]=PROG_UNSTART;
????}
}
?
該程序段是編程lpc1778內部Flash，其中調用IAP程序的函數iap_entry(paramin, paramout)是關鍵安全代碼，所以在執行該代碼前，先判斷一個特定設置的安全鎖標志ProgStart，只有這個標志符合設定值，才會執行編程Flash操作。如果因為意外程序跑飛到該函數，由于ProgStart標志不正確，是不會對Flash進行編程的。
12、通信數據的檢錯
通訊線上的數據誤碼相對嚴重，通訊線越長，所處的環境越惡劣，誤碼會越嚴重。拋開硬件和環境的作用，我們的軟件應能識別錯誤的通訊數據。對此有一些應用措施：
制定協議時，限制每幀的字節數；
每幀字節數越多，發生誤碼的可能性就越大，無效的數據也會越多。對此以太網規定每幀數據不大于1500字節，高可靠性的CAN收發器規定每幀數據不得多于8字節，對于RS485，基于RS485鏈路應用最廣泛的Modbus協議一幀數據規定不超過256字節。因此，建議制定內部通訊協議時，使用RS485時規定每幀數據不超過256字節；
使用多種校驗
編寫程序時應使能奇偶校驗，每幀超過16字節的應用，建議至少編寫CRC16校驗程序。
增加額外判斷
增加緩沖區溢出判斷。這是因為數據接收多是在中斷中完成，編譯器檢測不出緩沖區是否溢出，需要手動檢查，在上文介紹數據溢出一節中已經詳細說明。
增加超時判斷。當一幀數據接收 到一半，長時間接收不到剩余數據，則認為這幀數據無效，重新開始接收?？蛇x，跟不同的協議有關，但緩沖區溢出判斷必須實現。這是因為對于需要幀頭判斷的協議，上位機可能發送完幀頭后突然斷電，重啟后上位機是從新的幀開始發送的，但是下位機已經接收到了上次未發送完的幀頭，所以上位機的這次幀頭會被下位機當成正常數據接收。
這有可能造成數據長度字段為一個很大的值，填滿該長度的緩沖區需要相當多的數據（比如一幀可能1000字節），影響響應時間；另一方面，如果程序沒有緩沖區溢出判斷，那么緩沖區很可能溢出，后果是災難性的。
重傳機制
如果檢測到通訊數據發生了錯誤，則要有重傳機制重新發送出錯的幀。
13、開關量輸入的檢測、確認
開關量容易受到尖脈沖干擾，如果不進行濾除，可能會造成誤動作。一般情況下，需要對開關量輸入信號進行多次采樣，并進行邏輯判斷直到確認信號無誤為止。多次采樣之間需要有一定時間間隔，具體跟開關量的最大切換頻率有關，一般不小于1ms。
14、開關量輸出
開關信號簡單的一次輸出是不安全的，干擾信號可能會翻轉開關量輸出的狀態。采取重復刷新輸出可以有效防止電平的翻轉。
15、初始化信息的保存與恢復
微處理器的寄存器值也可能會因外界干擾而改變，外設初始化值需要在寄存器中長期保存，最容易被破壞。由于Flash中的數據相對不易被破壞，可以將初始化信息預先寫入Flash，待程序空閑時比較與初始化相關的寄存器值是否被更改，如果發現非法更改則使用Flash中的值進行恢復。
16、while循環
有時候程序員會使用while(!flag);語句來等待標志flag改變，比如串口發送時用來等待一字節數據發送完成。這樣的代碼時存在風險的，如果因為某些原因標志位一直不改變則會造成系統死機。良好冗余的程序是設置一個超時定時器，超過一定時間后，強制程序退出while循環。
2003年8月11日發生的W32.Blaster.Worm蠕蟲事件導致全球經濟損失高達5億美元，這個漏洞是利用了Windows分布式組件對象模型的遠程過程調用接口中的一個邏輯缺陷：在調用GetMachineName()函數時，循環只設置了一個不充分的結束條件。
原代碼簡化如下所示：
?
HRESULT?GetMachineName?(?WCHAR?*pwszPath,
WCHARwszMachineName[MAX_COMPUTTERNAME_LENGTH_FQDN+1])
{
????WCHAR?*pwszServerName?=?wszMachineName;
????WCHAR?*pwszTemp?=?pwszPath?+?2;
????while?(?*pwszTemp?!=?L’\’?)???????????????/*?這句代碼循環結束條件不充分?*/
????????*pwszServerName++=?*pwszTemp++;
????/*…?*/
}
?
微軟發布的安全補丁MS03-026解決了這個問題，為GetMachineName()函數設置了充分終止條件。一個解決代碼簡化如下所示（并非微軟補丁代碼）：
?
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
?
17、系統自檢
對CPU、RAM、Flash、外部掉電保存存儲器以及其他線路自檢。
18、其它一些編程建議：
深入理解嵌入式C語言以及編譯器
細致、謹慎的編程
使用好的風格和合理的設計
不要倉促編寫代碼，寫每一行的代碼時都要三思而后行：可能會出現什么樣的錯誤？是否考慮了所有的邏輯分支？
打開編譯器所有警告開關
使用靜態分析工具分析代碼
安全的讀寫數據（檢查所有數組邊界…）
檢查指針的合法性
檢查函數入口參數合法性
檢查所有返回值
在聲明變量位置初始化所有變量
合理的使用括號
謹慎的進行強制轉換
使用好的診斷信息日志和工具
?
審核編輯：湯梓紅
工商網監
評論