微秒很重要：減少工業(yè)控制系統(tǒng)中的中斷延遲

性能是大多數(shù)嵌入式系統(tǒng)開發(fā)人員永遠(yuǎn)不會偏離的話題。但是，相對而言，我們中的許多人都過得很輕松。我們開發(fā)了軟實時系統(tǒng)，在該系統(tǒng)中，響應(yīng)事件的額外幾微秒甚至幾毫秒的延遲不會引起關(guān)注。

不過，還有很多其他開發(fā)商不喜歡這種奢侈。工業(yè)控制項目是硬實時要求非常普遍的應(yīng)用領(lǐng)域。對于該領(lǐng)域的開發(fā)人員，尤其是那些工作涉及電機(jī)控制的開發(fā)人員，我們中的一些人認(rèn)為理所當(dāng)然的微秒可能至關(guān)重要。

為了滿足緊迫的響應(yīng)時間，工業(yè)控制工程師可能有必要做出在其他情況下看起來很荒謬的妥協(xié)。一些做出此類設(shè)計決策的工程師傾向于避免使用實時操作系統(tǒng) (RTOS)。雖然在許多圈子中，RTOS 被視為編寫多任務(wù)應(yīng)用程序代碼的高效軟件平臺，但開發(fā)人員放棄 RTOS 的情況并不少見，因為它感知到的開銷，特別是它對中斷延遲的影響。

中斷延遲基礎(chǔ)知識

為什么 RTOS 盡管有“實時”標(biāo)簽，卻在某些嵌入式系統(tǒng)開發(fā)人員中獲得了這種負(fù)面聲譽(yù)？要回答這個問題，我們首先應(yīng)該簡要回顧一下中斷延遲的概念。

盡管中斷可以描述為立即響應(yīng)硬件事件的一種方式，但從事件到執(zhí)行該事件的代碼的轉(zhuǎn)換肯定不是瞬時的。給定系統(tǒng)中的每個中斷服務(wù)程序 (ISR) 都會經(jīng)歷一定程度的延遲或延遲。如圖1 所示，這種延遲可以分為硬件和軟件組件。

圖 1：硬件和軟件都會影響中斷延遲。

硬件中斷延遲通常反映了操作所需的時間，例如在 CPU 中完成當(dāng)前正在執(zhí)行的指令、定位中斷處理程序的地址以及保存所有寄存器——這些操作在大多數(shù)情況下不屬于開發(fā)人員的范圍?？刂?。當(dāng)然，它還受到 CPU 架構(gòu)的影響。另一方面，軟件延遲取決于系統(tǒng)的中斷禁用時間和系統(tǒng) ISR 序言的大小——在中斷處理程序啟動之前手動保存寄存器和執(zhí)行其他內(nèi)務(wù)操作的代碼。至少在應(yīng)用程序代碼中，開發(fā)人員通常能夠限制這些數(shù)量，從而將系統(tǒng)的中斷延遲降低到可接受的低水平。

如果使用 RTOS，等式會發(fā)生一些變化。RTOS 通常會有自己的 ISR 格式——包括序言和尾聲——而且，也許更重要的是，它會包含許多禁用中斷的關(guān)鍵代碼部分。臨界區(qū)代表了任何系統(tǒng)的額外中斷延遲源，否則該系統(tǒng)將具有零中斷禁用時間。

當(dāng)然，為了促進(jìn)他們的軟件的采用，RTOS 開發(fā)人員試圖使關(guān)鍵部分盡可能簡短，并盡量減少這些代碼段落的數(shù)量。然而，這可能是一項具有挑戰(zhàn)性的工作，因為任何有可能在 ISR 中訪問的 RTOS 變量或數(shù)據(jù)結(jié)構(gòu)（可能是通過 API 調(diào)用）都必須使用關(guān)鍵部分進(jìn)行保護(hù)，以避免出現(xiàn)競爭條件。即使在高效、編寫良好的 RTOS 中，最長的關(guān)鍵部分也可能超出硬實時控制系統(tǒng)的允許范圍。 ?

中斷延遲問題使此類系統(tǒng)的開發(fā)人員處于困境，因為 RTOS 可以帶來許多好處。盡管它可能會產(chǎn)生任何開銷，但 RTOS 最終是一種有效利用 CPU 的工具。利用 RTOS 的開發(fā)人員擁有一個可以相對輕松地維護(hù)和擴(kuò)展的便攜式多任務(wù)軟件平臺。?

零添加中斷延遲 RTOS

幸運(yùn)的是，有一種方法可以消除 RTOS 造成的中斷延遲，而且結(jié)果非常簡單，前提是 RTOS 運(yùn)行在配備有足夠可配置的中斷硬件的處理器上。該方法背后的想法是，如果只有部分系統(tǒng)中斷處理程序有可能（再次通過 API 調(diào)用）訪問 RTOS 變量，則無需在 RTOS 臨界區(qū)禁用所有系統(tǒng)中斷。采用這種方法的 RTOS 不使用全局中斷禁用和啟用，而是在關(guān)鍵部分的開始和結(jié)束處簡單地更新中斷優(yōu)先級或級別寄存器，假設(shè)底層處理器確實提供了這樣的寄存器。說明這種方法的偽代碼如下所示。

#define CRITICAL_ENTER() set_int_prio(5)

#define CRITICAL_EXIT() set_int_prio(0)

無效 RTOS_function (無效)

{

CRITICAL_ENTER(); /* 增加優(yōu)先級 */

訪問 RTOS 變量；

CRITICAL_EXIT(); /* 將優(yōu)先級返回低級 */

}

為了使優(yōu)先級調(diào)整按預(yù)期工作，使用在關(guān)鍵部分采用這種技術(shù)的 RTOS 的應(yīng)用程序開發(fā)人員必須根據(jù)圖 2 所示的方案確定其中斷處理程序的優(yōu)先級。此方案中的最高優(yōu)先級對應(yīng)于不進(jìn)行 RTOS 調(diào)用且不依賴任何 RTOS 服務(wù)的處理程序。這些處理程序（有時稱為“非內(nèi)核感知”ISR）的優(yōu)先級超過了與關(guān)鍵部分相關(guān)的級別，因此它們絕不應(yīng)該被 RTOS 延遲。

圖 2：最高優(yōu)先級的中斷永遠(yuǎn)不會被 RTOS 禁用。?

在“非內(nèi)核感知”處理程序之后是能夠利用 RTOS 服務(wù)的“內(nèi)核感知”ISR。用于實現(xiàn)此優(yōu)先級方案的中斷控制器預(yù)計會阻止“內(nèi)核感知”ISR 在關(guān)鍵部分期間執(zhí)行。因此，這些處理程序的中斷延遲將超過“非內(nèi)核感知”例程的延遲。權(quán)衡是較低優(yōu)先級的處理程序可以調(diào)用 RTOS API，例如，向位于優(yōu)先級層次結(jié)構(gòu)底部的任務(wù)之一發(fā)出信號。?

硬件和軟件支持

對于所有中斷硬件或所有微控制器/處理器，都不可能以建立關(guān)鍵部分為目標(biāo)來操縱優(yōu)先級。然而，優(yōu)先中斷控制器已成為現(xiàn)代 32 位 MCU 的標(biāo)準(zhǔn)，目前為工業(yè)控制項目選擇的許多硬件平臺都配備了此類控制器的高度可配置實現(xiàn)。這意味著曾經(jīng)避免使用 RTOS 的硬實時系統(tǒng)開發(fā)人員現(xiàn)在可以選擇為他們的項目帶來高效的多任務(wù)處理能力。例如，大多數(shù)或所有基于 ARM Cortex-M 的微控制器和 Renesas RX 系列設(shè)備都可以很好地使用這種中斷方案。所需資源只不過是一個優(yōu)先級中斷控制器，它可以在軟件中調(diào)整優(yōu)先級。?

在決定利用哪些特定 RTOS 來實現(xiàn)這些功能時，開發(fā)人員必須謹(jǐn)慎行事?？梢韵胂?，納秒、微秒和毫秒范圍內(nèi)的延遲都可能被 RTOS 提供商解釋為“低”，但對運(yùn)行速度有要求的潛在 RTOS 用戶可能會持不同的看法。

兩個 RTOS 示例是 Micrium 的 μC/OS-II 和 μC/OS-III。兩者在工業(yè)控制系統(tǒng)中的使用歷史悠久，并支持本文中描述的臨界區(qū)格式。對于希望將 RTOS 強(qiáng)大的多任務(wù)處理能力來應(yīng)對工業(yè)設(shè)計中硬實時系統(tǒng)的挑戰(zhàn)的開發(fā)人員來說，它們是兩個可行的選擇。

審核編輯 黃昊宇