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

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

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

中斷延遲基礎知識

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

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

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

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

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

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

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

零添加中斷延遲 RTOS

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

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

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

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

硬件和軟件支持

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

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

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

審核編輯 黃昊宇