1、前言 設備的可靠性涉及多個方面：穩(wěn)定的硬件、優(yōu)秀的軟件架構、嚴格的測試以及市場和時間的檢驗等等。這里著重談一下作者自己對嵌入式軟件可靠性設計的一些理解，通過一定的技巧和方法提高軟件可靠性。這里所說的嵌入式設備，是指使用單片機、ARM7、Cortex-M0，M3之類為核心的測控或工控系統(tǒng)。 嵌入式軟件可靠性設計應該從防錯、判錯和容錯三方面進行考慮。 此外，還需理解自己所使用的編譯器特性。 2、防錯 良好的軟件架構、清晰的代碼結構、掌握硬件、深入理解C語言是防錯的要點，這里只談一下C語言。 “人的思維和經(jīng)驗積累對軟件可靠性有很大影響"。C語言詭異且有種種陷阱和缺陷，需要程序員多年歷練才能達到較為完善的地步。“軟件的質(zhì)量是由程序員的質(zhì)量以及他們相互之間的協(xié)作決定的”。因此，作者認為防錯的重點是要考慮人的因素。 “深入一門語言編程，不要浮于表面”。軟件的可靠性，與你理解的語言深度密切相關，嵌入式C更是如此。除了語言，作者認為嵌入式開發(fā)還必須深入理解編譯器。 本節(jié)將對C語言的陷阱和缺陷做初步探討。 2.1 處處皆陷阱 最初開始編程時，除了英文標點被誤寫成中文標點外，可能被大家普遍遇到的是將比較運算符==誤寫成賦值運算符=，代碼如下所示： if(x=5) { … } 這里本意是比較變量x是否等于常量5，但是誤將’==’寫成了’=’，if語句恒為真。如果在邏輯判斷表達式中出現(xiàn)賦值運算符，現(xiàn)在的大多數(shù)編譯器會給出警告信息。并非所有程序員都會注意到這類警告，因此有經(jīng)驗的程序員使用下面的代碼來避免此類錯誤： if(5==x) { … } 將常量放在變量x的左邊，即使程序員誤將’==’寫成了’=’，編譯器會產(chǎn)生一個任誰也不能無視的語法錯誤信息：不可給常量賦值！ +=與=+、-=與=-也是容易寫混的。復合賦值運算符（+=、*=等等）雖然可以使表達式更加簡潔并有可能產(chǎn)生更高效的機器代碼，但某些復合賦值運算符也會給程序帶來隱含Bug，如下所示代碼： tmp=+1; 該代碼本意是想表達tmp=tmp+1，但是將復合賦值運算符+=誤寫成=+：將正整數(shù)常量1賦值給變量tmp。編譯器會欣然接受這類代碼，連警告都不會產(chǎn)生。 如果你能在調(diào)試階段就發(fā)現(xiàn)這個Bug，你真應該慶祝一下，否則這很可能會成為一個重大隱含Bug，且不易被察覺。 -=與=-也是同樣道理。與之類似的還有邏輯與&&和位與&、邏輯或||和位或|、邏輯非！和位取反~。此外字母l和數(shù)字1、字母O和數(shù)字0也易混淆，這種情況可借助編譯器來糾正。 很多的軟件BUG自于輸入錯誤。在Google上搜索的時候，有些結果列表項中帶有一條警告，表明Google認為它帶有惡意代碼。如果你在2009年1月31日一大早使用Google搜索的話，你就會看到，在那天早晨55分鐘的時間內(nèi)，Google的搜索結果標明每個站點對你的PC都是有害的。這涉及到整個Internet上的所有站點，包括Google自己的所有站點和服務。Google的惡意軟件檢測功能通過在一個已知攻擊者的列表上查找站點，從而識別出危險站點。在1月31日早晨，對這個列表的更新意外地包含了一條斜杠(“/”)。所有的URL都包含一條斜杠，并且，反惡意軟件功能把這條斜杠理解為所有的URL都是可疑的，因此，它愉快地對搜索結果中的每個站點都添加一條警告。很少見到如此簡單的一個輸入錯誤帶來的結果如此奇怪且影響如此廣泛，但程序就是這樣，容不得一絲疏忽。 數(shù)組常常也是引起程序不穩(wěn)定的重要因素，C語言數(shù)組的迷惑性與數(shù)組下標從0開始密不可分，你可以定義int a[30]，但是你絕不可以使用數(shù)組元素a[30]，除非你自己明確知道在做什么。 switch…case語句可以很方便的實現(xiàn)多分支結構，但要注意在合適的位置添加break關鍵字。程序員往往容易漏加break從而引起順序執(zhí)行多個case語句，這也許是C的一個缺陷之處。對于switch…case語句，從概率論上說，絕大多數(shù)程序一次只需執(zhí)行一個匹配的case語句，而每一個這樣的case語句后都必須跟一個break。去復雜化大概率事件，這多少有些不合常情。 break關鍵字用于跳出最近的那層循環(huán)語句或者switch語句，但程序員往往不夠重視這一點。 1990年1月15日，AT&T電話網(wǎng)絡位于紐約的一臺交換機當機并且重啟，引起它鄰近交換機癱瘓，由此及彼，一個連著一個，很快，114臺交換機每六秒當機重啟一次，六萬人九小時內(nèi)不能打長途電話。當時的解決方式：工程師重裝了以前的軟件版本。事后的事故調(diào)查發(fā)現(xiàn)，這是break關鍵字誤用造成的。《C專家編程》提供了一個簡化版的問題源碼： network code() { switch(line) { case THING1: doit1(); break; case THING2: if(x==STUFF) { do_first_stuff(); if(y==OTHER_STUFF) break; do_later_stuff(); } /*代碼的意圖是跳轉到這里… …*/ initialize_modes_pointer(); break; default: processing(); }/*… …但事實上跳到了這里。*/ use_modes_pointer();/*致使modes_pointer未初始化*/ } 那個程序員希望從if語句跳出，但他卻忘記了break關鍵字實際上跳出最近的那層循環(huán)語句或者switch語句。現(xiàn)在它跳出了switch語句，執(zhí)行了use_modes_pointer()函數(shù)。但必要的初始化工作并未完成，為將來程序的失敗埋下了伏筆。 將一個整形常量賦值給變量，代碼如下所示： int a=34, b=034; 變量a和b相等嗎？答案是不相等的。我們知道，16進制常量以’0x’為前綴，10進制常量不需要前綴，那么8進制呢？它與10進制和16進制表示方法都不相通，它以數(shù)字’0’為前綴，這多少有點奇葩：三種進制的表示方法完全不相通。如果8進制也像16進制那樣以數(shù)字和字母表示前綴的話，或許更有利于減少軟件Bug，畢竟你使用8進制的次數(shù)可能都不會有誤使用的次數(shù)多！下面展示一個誤用8進制的例子，最后一個數(shù)組元素賦值錯誤： a[0]=106; /*十進制數(shù)106*/ a[1]=112; /*十進制數(shù)112*/ a[2]=052; /*實際為十進制數(shù)42，本意為十進制52*/ 指針的加減運算是特殊的。下面的代碼運行在32位ARM架構上，執(zhí)行之后，a和p的值分別是多少？ int a=1; int *p=(int*)0x00001000; a=a+1; p=p+1; 對于a的值很容判斷出結果為2，但是p的結果卻是0x00001004。指針p加1后，p的值增加了4，這是為什么呢？原因是指針做加減運算時是以指針的數(shù)據(jù)類型為單位。p+1實際上是p+1*sizeof(int)。不理解這一點，在使用指針直接操作數(shù)據(jù)時極易犯錯。比如下面對連續(xù)RAM初始化零操作代碼: unsigned int *pRAMaddr; //定義地址指針變量 for(pRAMaddr=StartAddr;pRAMaddr{ *pRAMaddr=0x00000000; //指定RAM地址清零 }