大多數(shù) RTOS 提供對(duì)服務(wù)調(diào)用和其他類型錯(cuò)誤的監(jiān)控和報(bào)告。盡管人們普遍認(rèn)為良好的錯(cuò)誤處理有助于調(diào)試并提高可靠性,但很少有時(shí)間這樣做。問題是我們已經(jīng)面臨實(shí)現(xiàn)主要項(xiàng)目目標(biāo)的挑戰(zhàn),處理錯(cuò)誤是一種不受歡迎的麻煩。這是不幸的,因?yàn)榱己玫腻e(cuò)誤檢測(cè)和處理可以減少調(diào)試時(shí)間并有助于處理交付系統(tǒng)中的問題。
所需要的是將錯(cuò)誤和超時(shí)管理合并到嵌入式系統(tǒng)中的簡單方法。有兩種錯(cuò)誤報(bào)告,本地和中央。由于并非所有 RTOS 都提供后者,讓我們從前者開始。
本地錯(cuò)誤報(bào)告
本地報(bào)錯(cuò)基本上有兩種方法。第一個(gè)直接返回狀態(tài)信息并將所需結(jié)果放入作為參數(shù)提供的地址中。例如:
在這種情況下,任務(wù)控制塊 (TCB) 已被靜態(tài)定義。OSTaskCreate() 使用它的地址填寫 TCB 字段并返回 status = OK。如果發(fā)生錯(cuò)誤,例如無效的 TCB 地址,則 status 是錯(cuò)誤類型。這種方法的缺點(diǎn)是需要一個(gè)額外的參數(shù)來告訴將結(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 語句。如果發(fā)生超時(shí) (SMXE_TMO),則會(huì)對(duì)其進(jìn)行處理并控制返回消息接收,除非超時(shí)次數(shù)過多。否則,控制會(huì)跳出 while (1) 循環(huán)并轉(zhuǎn)到 switch 語句。在這里,存在所有 smx_MsgReceive() 錯(cuò)誤類型的情況,以及超時(shí)過多的情況。
錯(cuò)誤處理后,taskA_Main() 返回到調(diào)度程序,調(diào)度程序?qū)⑵渫V?。這確保了 taskA 在問題得到解決之前不會(huì)造成進(jìn)一步的損害。一旦問題得到解決,taskA 可以重新啟動(dòng),它會(huì)回到它的主處理循環(huán)。在調(diào)試時(shí),停止任務(wù)有助于診斷問題并決定如何在已發(fā)布的系統(tǒng)中修復(fù)它。
taskA 也可以在不停止的情況下重新啟動(dòng),如無效 MCB 情況所示。在這種情況下,消息被丟棄,taskA 返回其主處理循環(huán)。重啟taskA是錯(cuò)誤處理的程度。此外,任務(wù)重啟后沒有中斷,因?yàn)樗蟛粫?huì)執(zhí)行任何語句。
此示例說明如何區(qū)分超時(shí)和錯(cuò)誤以及如何區(qū)分錯(cuò)誤類型。請(qǐng)注意,可能需要通知然后重試的超時(shí)處理保留在主 while 循環(huán)中,而錯(cuò)誤處理在循環(huán)之外執(zhí)行。這使得主循環(huán)更容易理解,因?yàn)樗鼪]有雜亂的錯(cuò)誤處理代碼。
通過將錯(cuò)誤處理代碼與主處理代碼分開,更容易將時(shí)間和精力集中在后者上。在調(diào)試期間,switch 語句可能僅用于放置斷點(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)以來發(fā)生了多少錯(cuò)誤。
為錯(cuò)誤類型增加一個(gè)特定的計(jì)數(shù)器,errctrs[e]。這有助于確定交付的系統(tǒng)中出現(xià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)開銷。因此,可以將大量錯(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)簡單地處理它們。因此,在許多系統(tǒng)中,依賴中央錯(cuò)誤管理可能是最佳選擇,因?yàn)樗粫?huì)增加太多開銷,也不會(huì)使主代碼復(fù)雜化。然而,它允許查看錯(cuò)誤發(fā)生的位置及其頻率。
使用 EMHook() 提供了一個(gè)中間地帶,可以為特定的錯(cuò)誤和線程收集額外的信息。然后可以啟動(dòng)錯(cuò)誤或線程特定的恢復(fù)。
在典型系統(tǒng)中,許多路徑流經(jīng) RTOS,因此它處于檢測(cè)和處理錯(cuò)誤的良好位置。一般來說,函數(shù)的返回值,尤其是 RTOS 服務(wù),不應(yīng)該在沒有檢查的情況下使用。不這樣做可能會(huì)導(dǎo)致嚴(yán)重的故障,并可能為惡意軟件提供入口點(diǎn)。完成主要代碼后,可以將注意力轉(zhuǎn)向適合已發(fā)布系統(tǒng)的錯(cuò)誤處理的數(shù)量和類型??赡軙?huì)選擇上述方法的某種組合。
審核編輯:郭婷
-
嵌入式
+關(guān)注
關(guān)注
5054文章
18917瀏覽量
300957 -
計(jì)數(shù)器
+關(guān)注
關(guān)注
32文章
2248瀏覽量
94187 -
RTOS
+關(guān)注
關(guān)注
21文章
808瀏覽量
119302
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論