所有重要的軟件都有錯誤。我不想稱它們為“錯誤”，因為這會使它們與需要為自己的錯誤負責的開發人員分離。顯然，設計良好的軟件可能會更少，而現代嵌入式軟件開發工具的應用可以將它們保持在最低限度。當然，具體的錯誤無法預測（否則它們可以被根除），但是可以識別某些類型的軟件問題，并且有可能在問題變成災難之前發現問題。

我會將此類軟件問題分為兩大類：

數據損壞

代碼循環

由于大量嵌入式代碼是用 C 編寫的，這意味著開發人員很可能會使用指針。小心使用，指針是該語言的一個強大功能，但它們也是最常見的程序員錯誤來源之一。指針使用的問題很難靜態識別，并且引入的錯誤可能會在代碼執行時以微妙的方式表現出來。有些事情，比如取消引用空指針很容易檢測到，因為它們通常會導致陷阱。只需要實現一個陷阱處理程序。其他的更難，因為指針最終可能指向任何地方——通常它會指向一個有效的地址，但不幸的是，它可能不是正確的地址。自測試代碼對此幾乎無能為力。然而，有兩種特殊但非常常見的，

不應發生堆棧溢出，因為應仔細確定堆棧分配，并在調試階段驗證其使用情況。但是，很可能會忽略不尋常的情況或使用不易測試的構造（如遞歸函數）。一個簡單的解決方案是在堆棧空間的任一端包含一個額外的詞——“保護詞”。這些預加載了特定值，由自檢任務（可能在后臺運行）監控。如果值更改，則違反了堆棧限制。應謹慎選擇該值。奇數是最好的，因為它不代表大多數處理器的有效地址。也許是 0x55555555。只要該值“不太可能”——例如不是 0x00000001 或 0xffffffff——就有 40 億比 1 的機會發生誤報。

在某些語言中，存在用于在數組邊界之外尋址的內置檢測，但這會引入運行時開銷，這可能是不受歡迎的。因此，這不是在 C 中實現的。此外，可以使用指針而不是運算符來訪問數組元素，因此可能會規避任何檢查。最好的方法是通過在數組末尾定位一個保護字并以與堆棧溢出檢查相同的方式進行監視來檢查緩沖區溢出類型的錯誤。

在這兩種情況下，當保護字被破壞時，這表明即將發生故障。堆棧或數組可能只是一個字就溢出或不足，因此還沒有造成真正的損害。定位錯誤訪問的原因比調試可能發生的隨機崩潰要容易得多。

代碼永遠不應陷入無限循環，但邏輯錯誤或未發生預期的外部事件可能會導致代碼掛起。當代碼在等待某事發生時，理想情況下應該有一個超時機制，這樣代碼就不會無限期地掛起。

在任何類型的多線程環境中——無論是 RTOS 還是帶有 ISR 的主線代碼——都可以實現“看門狗”機制。每個連續運行的任務（可能只是主線代碼）都需要每隔一段時間與看門狗任務（可能是計時器 ISR）“簽入”。如果發生超時，則需要采取措施。

那么，當檢測到堆棧溢出、數組綁定違例或掛起任務時該怎么辦呢？這取決于應用程序。可能只需要停止和重新啟動單個任務，但可能需要更激烈的操作：停止系統、發出某種警報或簡單地重置系統。選擇取決于許多因素，但從廣義上講，目標是為了比崩潰的系統更好的東西。

訂閱

審核編輯：郭婷