所有重要的軟件都有錯(cuò)誤。我不想稱它們?yōu)椤板e(cuò)誤”，因?yàn)檫@會(huì)使它們與需要為自己的錯(cuò)誤負(fù)責(zé)的開發(fā)人員分離。顯然，設(shè)計(jì)良好的軟件可能會(huì)更少，而現(xiàn)代嵌入式軟件開發(fā)工具的應(yīng)用可以將它們保持在最低限度。當(dāng)然，具體的錯(cuò)誤無法預(yù)測(cè)（否則它們可以被根除），但是可以識(shí)別某些類型的軟件問題，并且有可能在問題變成災(zāi)難之前發(fā)現(xiàn)問題。

我會(huì)將此類軟件問題分為兩大類：

數(shù)據(jù)損壞

代碼循環(huán)

由于大量嵌入式代碼是用 C 編寫的，這意味著開發(fā)人員很可能會(huì)使用指針。小心使用，指針是該語言的一個(gè)強(qiáng)大功能，但它們也是最常見的程序員錯(cuò)誤來源之一。指針使用的問題很難靜態(tài)識(shí)別，并且引入的錯(cuò)誤可能會(huì)在代碼執(zhí)行時(shí)以微妙的方式表現(xiàn)出來。有些事情，比如取消引用空指針很容易檢測(cè)到，因?yàn)樗鼈兺ǔ?huì)導(dǎo)致陷阱。只需要實(shí)現(xiàn)一個(gè)陷阱處理程序。其他的更難，因?yàn)橹羔樧罱K可能指向任何地方——通常它會(huì)指向一個(gè)有效的地址，但不幸的是，它可能不是正確的地址。自測(cè)試代碼對(duì)此幾乎無能為力。然而，有兩種特殊但非常常見的，

不應(yīng)發(fā)生堆棧溢出，因?yàn)閼?yīng)仔細(xì)確定堆棧分配，并在調(diào)試階段驗(yàn)證其使用情況。但是，很可能會(huì)忽略不尋常的情況或使用不易測(cè)試的構(gòu)造（如遞歸函數(shù)）。一個(gè)簡(jiǎn)單的解決方案是在堆棧空間的任一端包含一個(gè)額外的詞——“保護(hù)詞”。這些預(yù)加載了特定值，由自檢任務(wù)（可能在后臺(tái)運(yùn)行）監(jiān)控。如果值更改，則違反了堆棧限制。應(yīng)謹(jǐn)慎選擇該值。奇數(shù)是最好的，因?yàn)樗淮泶蠖鄶?shù)處理器的有效地址。也許是 0x55555555。只要該值“不太可能”——例如不是 0x00000001 或 0xffffffff——就有 40 億比 1 的機(jī)會(huì)發(fā)生誤報(bào)。

在某些語言中，存在用于在數(shù)組邊界之外尋址的內(nèi)置檢測(cè)，但這會(huì)引入運(yùn)行時(shí)開銷，這可能是不受歡迎的。因此，這不是在 C 中實(shí)現(xiàn)的。此外，可以使用指針而不是運(yùn)算符來訪問數(shù)組元素，因此可能會(huì)規(guī)避任何檢查。最好的方法是通過在數(shù)組末尾定位一個(gè)保護(hù)字并以與堆棧溢出檢查相同的方式進(jìn)行監(jiān)視來檢查緩沖區(qū)溢出類型的錯(cuò)誤。

在這兩種情況下，當(dāng)保護(hù)字被破壞時(shí)，這表明即將發(fā)生故障。堆?；驍?shù)組可能只是一個(gè)字就溢出或不足，因此還沒有造成真正的損害。定位錯(cuò)誤訪問的原因比調(diào)試可能發(fā)生的隨機(jī)崩潰要容易得多。

代碼永遠(yuǎn)不應(yīng)陷入無限循環(huán)，但邏輯錯(cuò)誤或未發(fā)生預(yù)期的外部事件可能會(huì)導(dǎo)致代碼掛起。當(dāng)代碼在等待某事發(fā)生時(shí)，理想情況下應(yīng)該有一個(gè)超時(shí)機(jī)制，這樣代碼就不會(huì)無限期地掛起。

在任何類型的多線程環(huán)境中——無論是 RTOS 還是帶有 ISR 的主線代碼——都可以實(shí)現(xiàn)“看門狗”機(jī)制。每個(gè)連續(xù)運(yùn)行的任務(wù)（可能只是主線代碼）都需要每隔一段時(shí)間與看門狗任務(wù)（可能是計(jì)時(shí)器 ISR）“簽入”。如果發(fā)生超時(shí)，則需要采取措施。

那么，當(dāng)檢測(cè)到堆棧溢出、數(shù)組綁定違例或掛起任務(wù)時(shí)該怎么辦呢？這取決于應(yīng)用程序?？赡苤恍枰Ｖ购椭匦聠?dòng)單個(gè)任務(wù)，但可能需要更激烈的操作：停止系統(tǒng)、發(fā)出某種警報(bào)或簡(jiǎn)單地重置系統(tǒng)。選擇取決于許多因素，但從廣義上講，目標(biāo)是為了比崩潰的系統(tǒng)更好的東西。

訂閱

審核編輯：郭婷