大多數 RTOS 提供對服務調用和其他類型錯誤的監控和報告。盡管人們普遍認為良好的錯誤處理有助于調試并提高可靠性，但很少有時間這樣做。問題是我們已經面臨實現主要項目目標的挑戰，處理錯誤是一種不受歡迎的麻煩。這是不幸的，因為良好的錯誤檢測和處理可以減少調試時間并有助于處理交付系統中的問題。

所需要的是將錯誤和超時管理合并到嵌入式系統中的簡單方法。有兩種錯誤報告，本地和中央。由于并非所有 RTOS 都提供后者，讓我們從前者開始。

本地錯誤報告

本地報錯基本上有兩種方法。第一個直接返回狀態信息并將所需結果放入作為參數提供的地址中。例如：

在這種情況下，任務控制塊 （TCB） 已被靜態定義。OSTaskCreate（） 使用它的地址填寫 TCB 字段并返回 status = OK。如果發生錯誤，例如無效的 TCB 地址，則 status 是錯誤類型。這種方法的缺點是需要一個額外的參數來告訴將結果放在哪里以及需要靜態定義 TCB。

第二種方法直接返回結果，并將狀態放入當前任務的 TCB 中的一個字段中。例如：

在這種情況下，TCB 是從池中動態分配的，如果成功，則 RTOS 返回其句柄。（句柄是taskA，它是一個指向taskA 的TCB 的指針。）如果不是，它返回NULL。在這種情況下，發生了錯誤或超時，并且狀態已存儲在 smx_ct-》err 中，其中 smx_ct 是當前任務，即嘗試創建 taskA 的任務。這些方法是等價的，但我更喜歡第二種，因為它更直接。

本地錯誤和超時處理

這是一種處理本地錯誤和超時的方法，而不會使主代碼復雜化：

在此示例中，while （1） 循環執行主要處理。它在 port_in 交換處等待消息。如果在 TMO 周期內收到一條消息，它會被處理，然后釋放，控制返回到消息接收。如果由于錯誤或超時未收到消息，則控制轉到 else 語句。如果發生超時 （SMXE_TMO），則會對其進行處理并控制返回消息接收，除非超時次數過多。否則，控制會跳出 while （1） 循環并轉到 switch 語句。在這里，存在所有 smx_MsgReceive（） 錯誤類型的情況，以及超時過多的情況。

錯誤處理后，taskA_Main（） 返回到調度程序，調度程序將其停止。這確保了 taskA 在問題得到解決之前不會造成進一步的損害。一旦問題得到解決，taskA 可以重新啟動，它會回到它的主處理循環。在調試時，停止任務有助于診斷問題并決定如何在已發布的系統中修復它。

taskA 也可以在不停止的情況下重新啟動，如無效 MCB 情況所示。在這種情況下，消息被丟棄，taskA 返回其主處理循環。重啟taskA是錯誤處理的程度。此外，任務重啟后沒有中斷，因為它之后不會執行任何語句。

此示例說明如何區分超時和錯誤以及如何區分錯誤類型。請注意，可能需要通知然后重試的超時處理保留在主 while 循環中，而錯誤處理在循環之外執行。這使得主循環更容易理解，因為它沒有雜亂的錯誤處理代碼。

通過將錯誤處理代碼與主處理代碼分開，更容易將時間和精力集中在后者上。在調試期間，switch 語句可能僅用于放置斷點的位置。稍后，它可能會用案例充實，如圖所示，或者用中央錯誤處理代替。

中央錯誤處理

中央錯誤處理減少了對本地錯誤處理的需求，如果由 RTOS 提供，則應使用它。每當 RTOS 服務或 RTOS 本身檢測到錯誤時，都會調用 RTOS 錯誤管理器 EM（）。理想情況下，EM（） 在系統堆棧中運行，因此處理錯誤不會導致任務堆棧溢出。這可能是一團糟，因為它是出乎意料的，而且 EM（） 不太可能是可重入的。EM（） 應該執行以下部分或全部操作：

將錯誤號加載到全局變量 errno 中。這是系統遇到的最后一個錯誤。

將錯誤號加載到當前任務的 tcb.err 字段中。如果在每個 RTOS 服務啟動時清除此字段，它將反映此任務使用的最后一個服務中發生的情況。如前所示，這對于本地錯誤管理是必要的。

增加一個全局錯誤計數器，errctr。這表明自系統啟動以來發生了多少錯誤。

為錯誤類型增加一個特定的計數器，errctrs［e］。這有助于確定交付的系統中出現了哪些問題。

將錯誤信息保存在錯誤緩沖區 EB 中，例如發生時間、errno 和發生錯誤的線程。

將錯誤信息保存在事件緩沖區 EVB 中，以便在使用內核感知插件時可以相對于其他事件顯示錯誤。

調用用戶掛鉤函數 EMHook（） 以添加特定于錯誤和線程的處理。

如果當前任務損壞，則停止當前任務，如果錯誤不可恢復，則調用 EMExitHook（） 重新啟動系統。

EM（） 僅在發生錯誤時才會增加系統開銷。因此，可以將大量錯誤處理放入 EM（） 中，而對正常系統操作的影響可以忽略不計。此外，相對于總代碼大小，代碼大小的增加很小。

決定使用什么

本地錯誤管理往往會增加主代碼的復雜性，使其變得更大、更慢。然而，錯誤通常可以在調用點得到最有效的處理，在某些情況下，這樣做是必不可少的。例如，在網絡軟件中，輸入數據包的空閑塊用完可能在重負載條件下是正常的。因此，在本地處理它是必要的。如前所述，這可以在不使主代碼嚴重復雜化的情況下完成。

但是，一旦調試完成，大多數錯誤將不再發生。超時可能是唯一需要處理的頻繁事件，并且可以相當簡單地處理它們。因此，在許多系統中，依賴中央錯誤管理可能是最佳選擇，因為它不會增加太多開銷，也不會使主代碼復雜化。然而，它允許查看錯誤發生的位置及其頻率。

使用 EMHook（） 提供了一個中間地帶，可以為特定的錯誤和線程收集額外的信息。然后可以啟動錯誤或線程特定的恢復。

在典型系統中，許多路徑流經 RTOS，因此它處于檢測和處理錯誤的良好位置。一般來說，函數的返回值，尤其是 RTOS 服務，不應該在沒有檢查的情況下使用。不這樣做可能會導致嚴重的故障，并可能為惡意軟件提供入口點。完成主要代碼后，可以將注意力轉向適合已發布系統的錯誤處理的數量和類型。可能會選擇上述方法的某種組合。

審核編輯：郭婷