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

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

本地錯(cuò)誤報(bào)告

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

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

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

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

本地錯(cuò)誤和超時(shí)處理

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

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

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

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

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

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

中央錯(cuò)誤處理

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

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

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

增加一個(gè)全局錯(cuò)誤計(jì)數(shù)器，errctr。這表明自系統(tǒng)啟動(dòng)以來(lái)發(fā)生了多少錯(cuò)誤。

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

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

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

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

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

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

決定使用什么

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

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

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

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

審核編輯：郭婷