如何處理RTOS錯誤和超時

大多數(shù) RTOS 提供對服務(wù)調(diào)用和其他類型錯誤的監(jiān)控和報告。盡管人們普遍認(rèn)為良好的錯誤處理有助于調(diào)試并提高可靠性，但很少有時間這樣做。問題是我們已經(jīng)面臨實(shí)現(xiàn)主要項(xiàng)目目標(biāo)的挑戰(zhàn)，處理錯誤是一種不受歡迎的麻煩。這是不幸的，因?yàn)榱己玫腻e誤檢測和處理可以減少調(diào)試時間并有助于處理交付系統(tǒng)中的問題。

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

本地錯誤報告

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

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

第二種方法直接返回結(jié)果，并將狀態(tài)放入當(dāng)前任務(wù)的 TCB 中的一個字段中。例如：

在這種情況下，TCB 是從池中動態(tài)分配的，如果成功，則 RTOS 返回其句柄。（句柄是taskA，它是一個指向taskA 的TCB 的指針。）如果不是，它返回NULL。在這種情況下，發(fā)生了錯誤或超時，并且狀態(tài)已存儲在 smx_ct-》err 中，其中 smx_ct 是當(dāng)前任務(wù)，即嘗試創(chuàng)建 taskA 的任務(wù)。這些方法是等價的，但我更喜歡第二種，因?yàn)樗苯印?/p>

本地錯誤和超時處理

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

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

錯誤處理后，taskA_Main（） 返回到調(diào)度程序，調(diào)度程序?qū)⑵渫Ｖ埂＿@確保了 taskA 在問題得到解決之前不會造成進(jìn)一步的損害。一旦問題得到解決，taskA 可以重新啟動，它會回到它的主處理循環(huán)。在調(diào)試時，停止任務(wù)有助于診斷問題并決定如何在已發(fā)布的系統(tǒng)中修復(fù)它。

taskA 也可以在不停止的情況下重新啟動，如無效 MCB 情況所示。在這種情況下，消息被丟棄，taskA 返回其主處理循環(huán)。重啟taskA是錯誤處理的程度。此外，任務(wù)重啟后沒有中斷，因?yàn)樗蟛粫?zhí)行任何語句。

此示例說明如何區(qū)分超時和錯誤以及如何區(qū)分錯誤類型。請注意，可能需要通知然后重試的超時處理保留在主 while 循環(huán)中，而錯誤處理在循環(huán)之外執(zhí)行。這使得主循環(huán)更容易理解，因?yàn)樗鼪]有雜亂的錯誤處理代碼。

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

中央錯誤處理

中央錯誤處理減少了對本地錯誤處理的需求，如果由 RTOS 提供，則應(yīng)使用它。每當(dāng) RTOS 服務(wù)或 RTOS 本身檢測到錯誤時，都會調(diào)用 RTOS 錯誤管理器 EM（）。理想情況下，EM（） 在系統(tǒng)堆棧中運(yùn)行，因此處理錯誤不會導(dǎo)致任務(wù)堆棧溢出。這可能是一團(tuán)糟，因?yàn)樗浅龊跻饬系模?EM（） 不太可能是可重入的。EM（） 應(yīng)該執(zhí)行以下部分或全部操作：

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

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

增加一個全局錯誤計數(shù)器，errctr。這表明自系統(tǒng)啟動以來發(fā)生了多少錯誤。

為錯誤類型增加一個特定的計數(shù)器，errctrs［e］。這有助于確定交付的系統(tǒng)中出現(xiàn)了哪些問題。

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

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

調(diào)用用戶掛鉤函數(shù) EMHook（） 以添加特定于錯誤和線程的處理。

如果當(dāng)前任務(wù)損壞，則停止當(dāng)前任務(wù)，如果錯誤不可恢復(fù)，則調(diào)用 EMExitHook（） 重新啟動系統(tǒng)。

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

決定使用什么

本地錯誤管理往往會增加主代碼的復(fù)雜性，使其變得更大、更慢。然而，錯誤通?？梢栽谡{(diào)用點(diǎn)得到最有效的處理，在某些情況下，這樣做是必不可少的。例如，在網(wǎng)絡(luò)軟件中，輸入數(shù)據(jù)包的空閑塊用完可能在重負(fù)載條件下是正常的。因此，在本地處理它是必要的。如前所述，這可以在不使主代碼嚴(yán)重復(fù)雜化的情況下完成。

但是，一旦調(diào)試完成，大多數(shù)錯誤將不再發(fā)生。超時可能是唯一需要處理的頻繁事件，并且可以相當(dāng)簡單地處理它們。因此，在許多系統(tǒng)中，依賴中央錯誤管理可能是最佳選擇，因?yàn)樗粫黾犹嚅_銷，也不會使主代碼復(fù)雜化。然而，它允許查看錯誤發(fā)生的位置及其頻率。

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

在典型系統(tǒng)中，許多路徑流經(jīng) RTOS，因此它處于檢測和處理錯誤的良好位置。一般來說，函數(shù)的返回值，尤其是 RTOS 服務(wù)，不應(yīng)該在沒有檢查的情況下使用。不這樣做可能會導(dǎo)致嚴(yán)重的故障，并可能為惡意軟件提供入口點(diǎn)。完成主要代碼后，可以將注意力轉(zhuǎn)向適合已發(fā)布系統(tǒng)的錯誤處理的數(shù)量和類型?？赡軙x擇上述方法的某種組合。

審核編輯：郭婷