一.背景介紹

在工業(yè)控制領(lǐng)域 實時(Real Time) 是一個核心要求。

• 實時系統(tǒng)的定義：實時系統(tǒng)是指計算的正確性不僅依賴于邏輯的正確性而且依賴于產(chǎn)生結(jié)果的時間，如果系統(tǒng)的時間限制不能得到滿足，系統(tǒng)將會產(chǎn)生故障。在工業(yè)領(lǐng)域這種故障可能造成災(zāi)難性的結(jié)果。
• 實時操作系統(tǒng)：該操作系統(tǒng)有能力提供一個指定范圍內(nèi)的服務(wù)響應(yīng)時間。

一個 OS kernel 給程序員提供了一系列的服務(wù)，例如： multitasking、 interrupt management、 inter-task communication and signaling、 resource management、 time management、 memory partition management 等等。OS 的主要工作就是資源封裝和調(diào)度，它提供對CPU、Memory、Storage、Network等資源的封裝和調(diào)度。

對于 實時(Real Time) 這個課題來說，我們重點關(guān)注其中的 CPU 資源調(diào)度。

1.1 OS 實時難題

• CPU 調(diào)度模型

在CPU資源調(diào)度方面，OS 主要提供一個多任務(wù)(multitasking)的運行環(huán)境，以方便應(yīng)用的開發(fā)。在開發(fā)某個應(yīng)用時首先把工作拆解成多個任務(wù)(Task/Thread)，每個任務(wù)都可以簡化成一個簡單的無限循環(huán)：

void MyTask (void)  
{  
    while (1) {  
        Wait for an event to occur;  
        Perform task operation;  
    }  
}

對一個任務(wù)來說它好像獨占CPU，但實際上是多個任務(wù)共享一個 CPU 的，由 OS Kernel 根據(jù)任務(wù)的狀態(tài)和優(yōu)先級來動態(tài)調(diào)度運行的：

可以看到OS對CPU調(diào)度提供了封裝，站在OS之上可以很方便的開發(fā)、移植應(yīng)用，應(yīng)用只需要關(guān)注自己的 Task 循環(huán)，其他復(fù)雜操作對OS都是透明。但是另一方面，OS 的這些封裝不可避免帶來了開銷，通常來說一個 CPU 上了 OS 以后會比裸機(jī)系統(tǒng)更慢，在頻率較低的 MCU 系統(tǒng)上這些開銷的占比會更為明顯。

• Event Driven

另一個重要的概念：任何一個系統(tǒng)都是事件驅(qū)動(Event Driven)的，準(zhǔn)確來說是中斷驅(qū)動的。

如上面代碼所示，任務(wù)(Task)都是等待event，然后處理事務(wù)。任何一個任務(wù)得以運行，都是因為它收到了一個 Event，這個 Event 可能是一個中斷、也可能是超時到期、還有可能是其他任務(wù)發(fā)出的IPC信號，繼續(xù)追查發(fā)出IPC信號的任務(wù)最后的源頭 Event 肯定是一個外部設(shè)備硬件中斷 或者 是內(nèi)部的 Timer中斷。中斷引起了 Event 傳遞，形成了逐個運行多個任務(wù)的鏈條(Chain)。一個系統(tǒng)內(nèi)部會存在很多條這種鏈條。

• Real Time

對實時(Real Time)系統(tǒng)來說，不僅僅要求OS能提供多任務(wù)環(huán)境，更要求任務(wù)能在極短的時間之內(nèi)響應(yīng)外部的中斷事件。這個要求也充滿了挑戰(zhàn)，即要享受 OS 帶來的好處，又要把 OS 帶來的開銷將到最小。

OS 實時模型的時序如上圖所示，實時優(yōu)化就是圍繞這張圖來展開的。其中的時間點和可能的優(yōu)化方式如下：

1.2 Linux 實時補(bǔ)丁

大名鼎鼎的 Linux RT-Preempt Patch 試圖從以下方面改善 Linux 的實時性：

實時補(bǔ)丁大大改善了 Linux 的實時性能，但還是軟實時的水平。

1.3 Xenomai + Linux 雙內(nèi)核

優(yōu)先處理實時任務(wù)，linux也被視為其中一個線程，本身也有調(diào)度器，但須等到?jīng)]有實時任務(wù)時（空閑狀態(tài)），才會執(zhí)行l(wèi)inux thread。

Xenomai + Linux 雙內(nèi)核可以達(dá)到 RTOS 的實時水平，也有把這種稱為硬實時。

但是 RTOS 的實時還是存在不確定性，因為OS API等臨界區(qū)的關(guān)中斷時間還是存在不確定性，和系統(tǒng)的負(fù)載相關(guān)聯(lián)。這也是 HW-RTOS 的優(yōu)化點。

1.4 HW-RTOS

HW-RTOS (hardware real-time operating system，硬件實時操作系統(tǒng))是一種基于硬件實現(xiàn)的實時操作系統(tǒng)，是瑞薩電子的專有技術(shù)。HW-RTOS支持大約30個api，都是通過硬件實現(xiàn)的。與傳統(tǒng)的軟件RTOS相比，硬件實現(xiàn)提供了極高水平的實時性能。

可以把HW-RTOS看作是CPU的硬件浮點單元(FPU)，加速內(nèi)核常用操作的專用硬件。然而，HW-RTOS并不執(zhí)行基于軟件的內(nèi)核中通常可用的所有操作。這類似于浮點處理器，它只提供基本的浮點運算，如加、減、乘、除、從浮點數(shù)到整型和從整型到浮點數(shù)的運算，省略了更復(fù)雜的運算，如超越運算、對數(shù)運算和其他運算。在使用HW-RTOS作為骨干時，更復(fù)雜的內(nèi)核操作通常可以在軟件中實現(xiàn)。

HW-RTOS 主要利用了以下手段：

• HW-RTOS 通過并行處理的方式，把 OS 調(diào)度類的負(fù)載從 CPU 上 Offload。
• 當(dāng)上述的調(diào)度負(fù)載由軟件來完成時，受當(dāng)前資源多少的影響執(zhí)行時間會變得不確定(例如：往一個排序鏈表中插入一個成員，消耗時間是不確定的)。但是 HW-RTOS 內(nèi)部的硬件處理也是并行的，它不受當(dāng)前資源多少的影響，所以它處理負(fù)載的時間可以做到接近恒定。

HW-RTOS實現(xiàn)了以下目標(biāo)：

Fast API execution with little fluctuation
Low interrupt latency with low jitter
Very short interrupt disable period

從支持的設(shè)備來說，瑞薩的 RZ 系列 和 R-IN32M3 系列支持了 HW-RTOS 功能：

從支持的 OS 來說，目前 uITRON 和 μC/OS?III 推出了支持 HW-RTOS 的版本，但是目前找不到具體的實例代碼。μC/OS?III HW-RTOS 號稱做到和原版 μC/OS?III 的接口和體驗一致：

接下來的章節(jié)，我們來詳細(xì)的分析 HW-RTOS 實現(xiàn)的相關(guān)優(yōu)化點。

1.5 More

需要特別注意的是，就算實現(xiàn)了 HW-RTOS 但是還是有影響實時的硬件因素存在：Cache Miss、TLB Miss、分支預(yù)測失敗、長跳轉(zhuǎn)與短跳轉(zhuǎn)、DVFS 等等。

航空航天等行業(yè)會使用專業(yè)的WCET(Worst-caseExecutionTime最壞執(zhí)行時間)工具，對系統(tǒng)的實時性做一個全面分析。

二.優(yōu)化點1：API

2.1 原理介紹

傳統(tǒng)軟件 OS API 會給系統(tǒng)來帶開銷，影響系統(tǒng)的性能和實時性，主要體現(xiàn)在兩方面：

(1)、OS API 開銷對實時性能的影響比大多數(shù)軟件工程師認(rèn)為的要大得多，并且發(fā)現(xiàn)很難保證最壞情況下的值。核心點就是 API 的函數(shù)復(fù)雜度是 O(n) 而不是 O(1)。

(2)、OS API 在執(zhí)行期間為了保證一致性大部分情況下是關(guān)中斷的，如果最壞情況下它的執(zhí)行時間是難以預(yù)估的，那么它帶來的最壞關(guān)中斷時間也是不可預(yù)估的。

2.1.1 Software API Execution time

圖3-1顯示了日本最常用的RTOS——ITRON的API執(zhí)行時間。包含“/D”的API是通過分派執(zhí)行的API進(jìn)程。圖3-1的測量是在靜態(tài)條件下進(jìn)行的。

但是由于RTOS的執(zhí)行時間取決于當(dāng)前的內(nèi)部狀態(tài)，因此它們是動態(tài)波動的：

(1)、以Set Flag API執(zhí)行時間為例。如圖3-2所示。圖中顯示了所有Set Flag API的執(zhí)行時間。但是，等待同一事件的任務(wù)越多，執(zhí)行時間就越長。換句話說，執(zhí)行時間會根據(jù)RTOS的內(nèi)部狀態(tài)而波動：

(2)、Wait隊列的基本原理。如圖3-3所示，RTOS的Wait隊列運行在基于優(yōu)先級的FCFS (First Come, First Served)算法上。具體來說，每個對象為每個任務(wù)優(yōu)先級級別都有一個隊列(在本例中，優(yōu)先級0被指定為最高優(yōu)先級，優(yōu)先級n被指定為最低優(yōu)先級)。例如，要實現(xiàn)信號量，每個信號量標(biāo)識符必須有n個隊列。每個希望獲取信號量的任務(wù)必須在隊列中等待。當(dāng)一個任務(wù)釋放它的信號量時，優(yōu)先級最高的隊列頭的任務(wù)被選中，該信號量被該任務(wù)獲取：

(3)、Set Flag API 的關(guān)鍵流程如下。對于標(biāo)志控制，系統(tǒng)必須在設(shè)置后比較等待標(biāo)志模式和事件表中的標(biāo)志模式，以確定釋放等待的條件是否滿足。換句話說，RTOS必須從圖3-3中隊列的頭部開始依次檢查每個任務(wù)，并比較標(biāo)志模式。結(jié)果，Set Flag系統(tǒng)調(diào)用的處理時間與等待相同標(biāo)志的任務(wù)數(shù)量成比例顯著增加，如圖3-2所示。

因此，API執(zhí)行時發(fā)生的RTOS開銷會動態(tài)變化，以響應(yīng)RTOS執(zhí)行時的內(nèi)部狀態(tài)。通常，大多數(shù)設(shè)計人員希望系統(tǒng)調(diào)用執(zhí)行在幾百個時鐘周期內(nèi)得到結(jié)果。然而，現(xiàn)在很多人都沒有意識到，某些條件的重疊可能會花費更多的時間。因此，當(dāng)上面討論的這些條件堆積起來時，開銷會突然增加，這意味著某些過程不能在指定的時間限制內(nèi)完成，從而導(dǎo)致實時系統(tǒng)的整體故障。

2.1.2 Software Influence of Queue Handling

如圖3-3中Wait隊列的邏輯結(jié)構(gòu)所示，RTOS的每個對象都需要優(yōu)先級隊列。通常，軟件中實現(xiàn)的隊列使用列表結(jié)構(gòu)。在RTOS中，TCB通過一個列表體系結(jié)構(gòu)相互連接，以實現(xiàn)一個等待隊列(TCB: Task Control Block)，圖3-3中的隊列實現(xiàn)如圖3-4所示。當(dāng)一個任務(wù)從Wait隊列中取出時，優(yōu)先級最高的隊列頭的任務(wù)將首先取出。因此，軟件必須檢查任務(wù)是否被添加到從最高優(yōu)先級開始的隊列中，以找到任務(wù)正在等待的最高優(yōu)先級隊列。作為結(jié)果，所需的處理時間會因隊列條件的不同而有很大差異。

另一個問題出現(xiàn)了。在RTOS中存在大量的隊列。例如，如果有64個信號量標(biāo)識符、64個事件標(biāo)識符和16個優(yōu)先級級別，那么總數(shù)量將是64×2×16 = 2048個隊列。因此，即使對象的數(shù)量相對較低，也需要大量的資源。圖3-5顯示了一個可能的改進(jìn)。每個隊列的尾部連接到下一個優(yōu)先級下降的隊列(即下一個較低的隊列)頭部的TCB。這個結(jié)構(gòu)允許很容易地從Wait隊列中刪除任務(wù)，只需選擇指針?biāo)甘镜娜蝿?wù)。它還大大減少了指針的數(shù)量。然而，如果仔細(xì)考慮，這種改進(jìn)思想會導(dǎo)致在將任務(wù)添加到隊列時進(jìn)行大量處理。例如，當(dāng)將優(yōu)先級為7的任務(wù)添加到隊列中時，搜索從隊列頭部開始，然后當(dāng)搜索到達(dá)優(yōu)先級為7的任務(wù)時，它將新任務(wù)添加到最后一個7級任務(wù)的末尾。

不管怎樣，很明顯，隊列處理需要大量的處理時間，而時間將根據(jù)隊列的條件而變化。此外，隊列處理是一個非常重要的過程，因此在每個過程期間都禁用中斷。

下面我們將探討隊列處理需要多少時間，并評估這對實時性能有多大影響。測試模型如圖3-6 所示：

測試結(jié)果如下圖所示：

伴隨隊列處理的API執(zhí)行時間會根據(jù)RTOS中隊列的狀態(tài)急劇波動。此外，由此導(dǎo)致的中斷禁用周期幾乎與api執(zhí)行時間一樣長，因此中斷禁用周期也可以根據(jù)RTOS隊列內(nèi)部狀態(tài)動態(tài)波動。

因此，當(dāng)大量任務(wù)被添加到隊列中時，隊列處理可能會產(chǎn)生意想不到的開銷和意想不到的長中斷禁用周期，從而可能導(dǎo)致實時系統(tǒng)中出現(xiàn)意想不到的錯誤。很有可能，應(yīng)用程序和軟件設(shè)計人員通常不會考慮RTOS中連接到隊列的任務(wù)數(shù)量，但提前了解這些任務(wù)可能導(dǎo)致的問題真的很重要。

2.1.3 HW-RTOS API Execution time

HW-RTOS中調(diào)用api的方法如圖4-1所示。如圖所示，應(yīng)用程序調(diào)用的API通過庫軟件作為硬件信號傳遞給HW-RTOS，返回值也通過庫軟件接收。庫軟件還根據(jù)HW-RTOS的指令執(zhí)行調(diào)度過程。在圖4-2中，我們可以看到HW-RTOS和傳統(tǒng)軟件RTOS(現(xiàn)在稱為SW RTOS)執(zhí)行時間測量的比較。

HW-RTOS中的API執(zhí)行時間非常快，大多數(shù)系統(tǒng)調(diào)用可以在10個周期內(nèi)執(zhí)行。然而，庫軟件的開銷確實會增加執(zhí)行時間，如圖4-2所示。在HW-RTOS中，相同的API的執(zhí)行時間不會因為內(nèi)部狀態(tài)而改變，就像在SW RTOS中顯示的設(shè)置標(biāo)志一樣。另一個巨大的優(yōu)點是系統(tǒng)調(diào)用的最壞情況值可以在數(shù)據(jù)表中指定。

2.1.4 HW-RTOS Influence of Queue Handling

HW-RTOS使用瑞薩特有的“虛擬隊列”技術(shù)實現(xiàn)硬件隊列。Virtual Queue可以將任務(wù)添加到隊列中，從隊列中刪除任務(wù)，也可以從隊列中間刪除任務(wù)，每個操作周期為2個周期。因此，無論隊列的狀態(tài)是什么，處理都可以在指定的時間內(nèi)完成。

和軟件方式在同樣測試模型下的對比：

2.2 具體實現(xiàn)

HW-RTOS 通過硬件大概實現(xiàn)了 30 個 API 函數(shù)，具體包括以下幾個方面：

Semaphore
Event flag
Mail box
Lock CPU and disable dispatch
Sleep / wakeup
Release waiting
Rotate ready queue
Change priority

如下圖所示，HW-RTOS作為系統(tǒng)總線上的一個外圍模塊來實現(xiàn)。

HW-RTOS為API調(diào)用實現(xiàn)了3個專門的寄存器:

API register,  
Argument register,  
Result register

瑞薩已經(jīng)為處理這些寄存器準(zhǔn)備了一個操作系統(tǒng)庫。用戶可以使用操作系統(tǒng)庫輕松調(diào)用API調(diào)用，就像傳統(tǒng)的軟件RTOS一樣。當(dāng)調(diào)用set_flg API調(diào)用時，OS庫將參數(shù)寫入?yún)?shù)寄存器，并將API的類型寫入API寄存器。當(dāng)HW-RTOS接收到這些信息時，它執(zhí)行API并將返回值寫入結(jié)果寄存器。OS庫將返回值報告給調(diào)用方應(yīng)用程序。執(zhí)行API時可能需要進(jìn)行任務(wù)切換。在這種情況下，HW-RTOS表示需要進(jìn)行任務(wù)切換，并將下一個應(yīng)該執(zhí)行的任務(wù)的ID寫入結(jié)果寄存器，以將該信息傳遞到OS庫。OS庫根據(jù)此信息執(zhí)行上下文切換。

2.3 性能測試

上圖顯示了API執(zhí)行時間。傳統(tǒng)軟件RTOS的執(zhí)行時間用深紫色表示，HW-RTOS用淺紫色表示。HW-RTOS不僅比軟件RTOS的執(zhí)行時間短，而且波動也不大。

三.優(yōu)化點2：Tick offloading

3.1 原理介紹

3.1.1 Software Tick

傳統(tǒng)OS需要處理一些定時任務(wù)。包括定時器、sleep()、xxx_timeout()、時間片調(diào)度等。為了這個目的，測量時間的軟件處理被周期性地激活。這就是所謂的Tick進(jìn)程。如圖所示，為了激活tick進(jìn)程，需要周期性中斷。

如上圖圖所示，雖然tick是一個不可或缺的功能，但它有以下三個缺點：

(1)、應(yīng)用程序會周期性的停止，CPU的使用效率會降低。

(2)、由于節(jié)拍正在執(zhí)行一個非常關(guān)鍵的進(jìn)程，因此在進(jìn)程執(zhí)行期間禁用所有中斷。因此，這對中斷響應(yīng)時間有負(fù)面影響。

(3)、由于滴答過程需要通過軟件來實現(xiàn)，所以滴答間隔不可能非常短。換句話說，高度精確的時間管理是不可能的。

并且 Tick 的處理時長不是固定的。Tick進(jìn)程檢查處于等待狀態(tài)的任務(wù)是否超時，因此當(dāng)大量任務(wù)同時超時時，處理需求會增加。

3.1.2 HW-RTOS Tick

HW-RTOS完全在硬件上實現(xiàn)tick過程。這個功能被稱為 tick offloading。tick過程在HW-RTOS內(nèi)部執(zhí)行。因此，不需要周期中斷滴答，也不需要CPU執(zhí)行滴答過程。如圖所示，CPU在任何時候都可以自由運行應(yīng)用軟件。只有在通過超時執(zhí)行上下文切換時才會停止。此外，由于滴答過程在非常高的速度執(zhí)行，滴答間隔可以縮短。基于上述原因，與傳統(tǒng)軟件相比，tick offloading可以提供以下優(yōu)點。

No drop in CPU efficiency caused by tick process
No interrupt disable period caused by tick process
Large improvement in tick precision

四.優(yōu)化點3：Hardware ISR(HW ISR)

4.1 原理介紹

4.1.1 Software ISR

傳統(tǒng)OS中當(dāng)一個中斷發(fā)生時，一個中斷服務(wù)程序(ISR)被激活。通常，在ISR執(zhí)行時，中斷是禁用的。在下圖的上半部分，ISR1和ISR2根據(jù)中斷類型交替激活。如果ISR1的處理時間延長，另一個中斷將被錯過或延遲，如圖下方所示。對于實時系統(tǒng)來說，錯過或延遲中斷是不受歡迎的。

4.1.2 Software ISR handed over to Task

一般采用以下方法來避免此類問題。如下圖所示，ISR1的處理移交給任務(wù)1,ISR2的處理移交給任務(wù)2。由于任務(wù)沒有禁用中斷，其他中斷不會受到影響。移交處理的方法如下。任務(wù)1等待一個標(biāo)志。當(dāng)?shù)谝粋€中斷(中斷1)發(fā)生時，ISR1執(zhí)行API來釋放任務(wù)1的等待狀態(tài)。這種方法最大限度地減少中斷處理對其他中斷的影響。例如，Linux 下的中斷線程化。

讓我們更詳細(xì)地看看這種方式下發(fā)生中斷時ISR是如何執(zhí)行API的。下圖顯示了這一點。讓我們假設(shè)在Task_A運行時發(fā)生了一個中斷：

1.The RTOS switches CPU registers and activates the ISR.
2.The ISR checks the interrupt source and invokes the API that corresponds to the interrupt.
3.The RTOS executes this API.
4.When the API finishes, the ISR also ends.
5.As a result, the ready queue is changed. If Task_B, to which ISR processing has been handed over, has a higher priority than Task_A, a dispatch is executed and Task_B will run.

上述過程相當(dāng)復(fù)雜，通常需要500 - 1500個循環(huán)。

4.1.3 HW-RTOS ISR handed over to Task

上述過程如果使用HW-RTOS，圖中顯示的所有RTOS處理(除了dispatch處理)都是在硬件上實現(xiàn)的，因此處理速度非常快。HW-RTOS進(jìn)一步加速了這一過程。也就是說，它加速了ISR進(jìn)程。ISR簡單地調(diào)用與中斷源對應(yīng)的API。通過將這部分實現(xiàn)到硬件中，可以加速它。這種實現(xiàn)稱為硬件ISR (HW ISR)。HW ISR的時序圖如下圖所示。

1.An interrupt occurs and HW-RTOS commences operation. HW-RTOS activates the HW ISR.
2.The HW ISR invokes the API that corresponds to the interrupt.
3.HW-RTOS executes the invoked API.
4.As a result, the ready queue is changed. If Task_B, to which ISR processing has been handed over, has a higher priority than Task_A, a dispatch is executed and Task_B will run.

注意，在HW- rtos和HW ISR正在處理時，CPU是空閑的，可以繼續(xù)處理Task_A。CPU只在任務(wù)切換期間停止。

下圖顯示了在API執(zhí)行結(jié)束時Task_B處于就緒狀態(tài)的一個例子，但是當(dāng)Task_B被交給ISR處理時，Task_B的優(yōu)先級比Task_A的優(yōu)先級低或相等。在本例中，由于Task_A具有更高的優(yōu)先級，因此不需要切換任務(wù)，因此Task_A繼續(xù)處理。即使中斷發(fā)生，它也不會引起CPU開銷：

通過使用HW ISR，您可以獲得以下好處:

1.Greatly reduce CPU overhead during interrupts
2.Greatly shorten interrupt disable period
3.Greatly reduce the number of context switches

對于希望快速執(zhí)行的進(jìn)程，可以簡單地提高HW ISR激活的任務(wù)的優(yōu)先級。當(dāng)然，HW-RTOS也同時支持傳統(tǒng)的ISR。

4.1.4 Non-OS managed Interrupt & Direct Interrupt Service

有操作系統(tǒng)管理的中斷，也有操作系統(tǒng)外部管理的中斷。RTOS、ISR和任務(wù)之間的優(yōu)先級關(guān)系如圖3所示。從圖中可以看到，任務(wù)的優(yōu)先級最低，然后是ISR，然后是RTOS。

由非os管理中斷激活的處理程序稱為非os管理中斷處理程序。正如您在圖3中看到的，非os管理的中斷處理程序的優(yōu)先級甚至高于RTOS進(jìn)程。因此，即使RTOS處于進(jìn)程的中間，該進(jìn)程也可以被中斷并立即激活處理程序。由于軟件在此激活中絕對沒有角色，因此直到處理程序被激活之前的延遲是由CPU定義的中斷延遲。這種非os管理的中斷處理程序通常用于不能允許大量RTOS開銷的應(yīng)用程序，如高速伺服電機(jī)控制。

ISR和非os管理的中斷處理程序之間的另一個區(qū)別是，在處理程序過程中是否可以調(diào)用API。由于ISR是在RTOS管理下運行的，因此可以調(diào)用API。然而，由于非OS管理的中斷處理程序可以在OS執(zhí)行關(guān)鍵進(jìn)程時被激活，自然不可能使用任何其他RTOS函數(shù)。因此，如圖2所示，不可能使用API將處理程序流程的一部分移交給任務(wù)。不能在中斷處理程序期間調(diào)用API是一個巨大的缺點。通常，如果您追蹤任何軟件進(jìn)程的源頭，就會發(fā)現(xiàn)一個中斷。換句話說，當(dāng)一個中斷發(fā)生時，一個特定的進(jìn)程被激活，然后這個進(jìn)程再激活另一個進(jìn)程，所以系統(tǒng)就像一條鏈。因此，當(dāng)您不能從處理程序調(diào)用API時，特別是同步或通信API，這是一個致命的問題。

怎么樣能讓非os管理中斷能喚醒對應(yīng) Task ？這樣既能快速響應(yīng)，又能擁有在 Task 中調(diào)用系統(tǒng) API 的能力。這就是 Direct Interrupt Service 機(jī)制的目的。

可以同時把發(fā)送給中斷 CPU 中斷控制器 和 HW-RTOS:

當(dāng)一個中斷信號產(chǎn)生時，非os管理的中斷處理程序激活，同時HW-RTOS內(nèi)部調(diào)用相應(yīng)的API。該API與非os管理的中斷處理程序并行執(zhí)行，在本例中，Task B從等待狀態(tài)被釋放。任務(wù)B在非os管理的中斷處理程序結(jié)束的同時被激活：

4.2 具體實現(xiàn)

HW-RTOS最多支持32個hw-isr的架構(gòu)，如圖7所示：

HW-ISR都需要在HW-RTOS中設(shè)置三個寄存器：

4.3 性能測試

上圖顯示了中斷延遲。從中斷的發(fā)生到ISR的激活，再到下一個任務(wù)的激活，時間是測量的。在軟件RTOS中，中斷延遲高，抖動大;而在HW-RTOS中，中斷延遲低，抖動小。當(dāng)使用HW ISR時，您可以看到性能上的巨大改進(jìn)。

4.4 相關(guān)應(yīng)用

4.4.1 Multiple interrupts using HW ISR

使用HW ISR，很容易實現(xiàn)多個中斷。通常，多個中斷是通過給每個中斷信號分配一個優(yōu)先級來實現(xiàn)的。在HW ISR中，根據(jù)激活的任務(wù)的優(yōu)先級實現(xiàn)多個中斷。下圖中，值越低優(yōu)先級越高。在下面的例子中，任務(wù)A具有最高的優(yōu)先級。三個中斷線被設(shè)置為使用HW ISR來執(zhí)行API，分別釋放信號量6、信號量3和信號量4。當(dāng)多個中斷發(fā)生時，根據(jù)等待的任務(wù)的優(yōu)先級進(jìn)行處理。

4.4.2 Cyclic activation task

HW-RTOS沒有循環(huán)處理函數(shù)。然而，使用硬件ISR可以實現(xiàn)等效功能。此外，使用HW ISR的循環(huán)激活任務(wù)的啟動時間比在傳統(tǒng)軟件RTOS上運行的循環(huán)處理程序短。這個過程很簡單:定義HW ISR的輸入為帶有嵌入式R-IN引擎的設(shè)備的內(nèi)置定時器的輸出。在下面的例子中，任務(wù)A是一個循環(huán)激活任務(wù)。由于在100 MHz的操作下，最壞情況下的啟動時間為3.5微秒，因此可以實現(xiàn)具有極高實時性能的循環(huán)處理。

通過構(gòu)建一個包含應(yīng)用程序示例1中所示的多個中斷處理的系統(tǒng)，您可以運行多個循環(huán)激活任務(wù)。下圖顯示了兩個循環(huán)激活任務(wù)。任務(wù)B是一個周期激活任務(wù)，周期是任務(wù)a的5倍。實際上，可以定義三個或更多個循環(huán)激活任務(wù)。每個任務(wù)的周期不必互相同步。也可以從外部引腳觸發(fā)循環(huán)激活。

4.4.3 Using cyclic activation task for network synchronization

配備R-IN引擎的瑞薩設(shè)備在硬件上具有IEEE1588支持功能。通過安裝IEEE1588協(xié)議軟件，可以在通過網(wǎng)絡(luò)連接的站點之間進(jìn)行時間同步。通過向計時器輸入同步信號并使用應(yīng)用程序示例2中所示的方法，您可以在通過網(wǎng)絡(luò)連接的HW-RTOSs上同步激活循環(huán)任務(wù)。循環(huán)任務(wù)的啟動波動非常小，在最壞的情況下，在IEEE 1588的波動上增加了3.5微秒的延遲。時間同步也可以使用EtherCAT來實現(xiàn)。

五.優(yōu)化點4：Task Management

5.1 原理介紹

HW-RTOS 的任務(wù)管理分為兩部分：

• 一部分是任務(wù)的調(diào)度器用來選取哪個任務(wù)進(jìn)行調(diào)度。
• 另一部分是任務(wù)的上下文切換。

5.1.1 HW-RTOS Scheduler

HW-RTOS支持多達(dá)64個任務(wù)分配給16個不同的優(yōu)先級級別。優(yōu)先級#0是最高優(yōu)先級，而#15是最低優(yōu)先級。但是，優(yōu)先級#15是為空閑任務(wù)保留的，在這個優(yōu)先級級別上，它必須是唯一的。HW-RTOS文檔還建議保留優(yōu)先級#0以備將來使用。雖然64個任務(wù)聽起來像是一種限制，但是具有這么多任務(wù)的應(yīng)用程序?qū)嶋H上可能相當(dāng)復(fù)雜。

如圖4所示，HW-RTOS執(zhí)行與其對應(yīng)的軟件(選擇要運行的下一個任務(wù))完全相同的功能，只是它使用硬連線邏輯的速度更快。

任務(wù)必須先被創(chuàng)建，然后才能被HW-RTOS管理，任務(wù)是通過在HW-RTOS的TCBs或任務(wù)控制塊中寫入特殊值來創(chuàng)建的(參見圖2)。必須為每個任務(wù)分配一個優(yōu)先級，以及任務(wù)堆棧的存儲區(qū)域(RAM)。

HW-RTOS，像大多數(shù)實時內(nèi)核一樣，包含一個搶占式調(diào)度器。事件導(dǎo)致調(diào)度程序暫停任務(wù)的執(zhí)行，以支持由這些事件準(zhǔn)備運行的更高優(yōu)先級的任務(wù)。事件可以通過其他任務(wù)產(chǎn)生，也可以通過中斷設(shè)備產(chǎn)生。如果一個任務(wù)向高優(yōu)先級的任務(wù)發(fā)送信號或消息，HW-RTOS調(diào)度器會自動向高優(yōu)先級的任務(wù)發(fā)起上下文切換，然后高優(yōu)先級的任務(wù)將處理該事件。類似地，如果一個中斷設(shè)備向一個任務(wù)發(fā)送信號或消息，如果該信號或消息指向更高優(yōu)先級的任務(wù)，則當(dāng)前正在運行的任務(wù)將被掛起。在這種情況下，HW-RTOS向這個優(yōu)先級更高的任務(wù)發(fā)起上下文切換。

5.1.1 HW-RTOS Context Switch

上下文切換分為兩個部分：

• 第一個是為HW-RTOS保留的特殊中斷處理程序，并被分配到vector #76。
• 第二部分是實際的上下文切換(保存和恢復(fù)CPU寄存器)，由Cortex-M3的PendSV處理程序執(zhí)行。

5.2 具體實現(xiàn)

六.典型案例

6.1 Network and RTOS

當(dāng)TCP/IP協(xié)議在嵌入式系統(tǒng)的CPU中實現(xiàn)時，與個人計算機(jī)的CPU不同，實現(xiàn)高吞吐量是非常困難的。下圖的上半部分顯示了使用商用TCP/IP協(xié)議棧的傳輸和接收的概要。只有11%的CPU處理時間花在復(fù)雜的協(xié)議處理上。其余的時間用于內(nèi)存復(fù)制、重新排列報頭、執(zhí)行TCP校驗和和RTOS處理。在這些進(jìn)程中，內(nèi)存復(fù)制、報頭重排和TCP校驗和很容易在硬件中實現(xiàn)。下圖的中間部分顯示了此實現(xiàn)的概要文件。然而，RTOS處理仍然有很高的開銷。由于TCP/IP等協(xié)議處理具有多個任務(wù)，因此每次發(fā)送或接收數(shù)據(jù)包時都需要進(jìn)行任務(wù)切換。還需要多個API調(diào)用。這就是為什么RTOS的配置文件有很高的開銷。HW-RTOS解決了這個問題。使用HW-RTOS可以大大降低CPU的負(fù)載，如圖下方所示。也就是說，您可以使用嵌入式系統(tǒng)中使用的低端cpu來實現(xiàn)高網(wǎng)絡(luò)性能。此外，如果不需要那么高的網(wǎng)絡(luò)吞吐量，可以使用較低的系統(tǒng)時鐘率來大大降低功耗。

下圖為R-IN32M3的框圖。R-IN引擎由HW-RTOS、Cortex?-M3核心和以太網(wǎng)加速器組成。以太網(wǎng)加速器是加速上述內(nèi)存復(fù)制、報頭重排、TCP校驗和進(jìn)程的硬件。通過使用R-IN引擎，可以加速TCP/IP和其他網(wǎng)絡(luò)協(xié)議的處理。R-IN發(fā)動機(jī)包含在R-IN32系列和RZ/N1系列的所有設(shè)備中，以及一些RZ/T1設(shè)備中。

下圖顯示了在R-IN32M3中實現(xiàn)的UDP/IP的吞吐量。工作時鐘為100 MHz，以太網(wǎng)幀長度為1500字節(jié)：

• 頂部的欄顯示了UDP校驗和的吞吐量，在軟件RTOS實現(xiàn)與HW-RTOS關(guān)閉軟件執(zhí)行。
• 中間的欄顯示了硬件實現(xiàn)的校驗和的吞吐量，
• 底部的欄顯示了HW-RTOS打開時的吞吐量。

如你所見，帶有HW-RTOS的R-IN引擎對于加速網(wǎng)絡(luò)協(xié)議處理非常有效。

七.下一代HW-RTOS

下一代HW-RTOS技術(shù)仍在計劃中。下一代將繼承這一代的所有優(yōu)勢。我們還增加了對緊密耦合、循環(huán)處理程序和多核RTOS特性的支持。有了這些，我們計劃為RTOS提供更高的功能和性能。

• Tightly coupled HW-RTOS

我們將從緊密耦合(tightly coupled)的HW-RTOS開始。當(dāng)前一代的HW-RTOS就是我們所說的“松散耦合”(loosely coupled)。在硬件方面，松耦合版本和緊耦合版本的最大區(qū)別是在松耦合版本中，CPU、HW-RTOS和CPU寄存器的保存內(nèi)存都通過系統(tǒng)總線連接。但是，緊耦合版本使用專用接口將這三個模塊連接起來。這種體系結(jié)構(gòu)允許改進(jìn)系統(tǒng)調(diào)用性能，包括調(diào)度，以及使中斷響應(yīng)性能，我們可以達(dá)到傳統(tǒng)軟件RTOS的十倍以上的性能。當(dāng)然，幾乎沒有波動。這允許構(gòu)建具有更高實時性能水平的系統(tǒng)。

• Cyclic handler

下一代HW-RTOS中的第二個新功能是循環(huán)處理器。HW-RTOS中循環(huán)處理程序的第一個獨特特性是通過在硬件中實現(xiàn)循環(huán)處理程序來實現(xiàn)極快的啟動。因此，我們將能夠縮短處理程序的間隔。循環(huán)處理程序間隔將取決于處理程序進(jìn)程，但應(yīng)該可以使用微秒級的間隔。這將允許其用于循環(huán)控制，甚至高精度的電機(jī)控制。我們下一代HW-RTOS循環(huán)處理器的第二個獨特特性是，可以將啟動時間設(shè)置為絕對時間。這將允許通過網(wǎng)絡(luò)連接的站點之間精確同步。

• Multi-core support

下一代HW-RTOS的第三個新功能是多核支持。單核HW-RTOS的所有功能和優(yōu)點延續(xù)到多核HW-RTOS。因此，作為一個實時操作系統(tǒng)，它提供了高水平的實時性能。此外，cpu間的處理，即cpu間的同步和cpu間的通信非常快，執(zhí)行時間的波動大大減少。這些特性的好處是很容易在多核系統(tǒng)上實現(xiàn)實時應(yīng)用程序系統(tǒng)。更具體地說，它提供:

Improved system processing performance
A high level of real-time performance
Definable worst case execution time
Low power consumption through a low operational clock

利用多核HW-RTOS技術(shù)，通過高速、高精度的同步，解決了傳統(tǒng)軟件RTOS中cpu間的同步和通信問題。由于使用多核HW-RTOS可以實現(xiàn)cpu間的同步速度小于1微秒，因此可以實現(xiàn)cpu間的精確定時控制。即使任務(wù)是由不同的cpu執(zhí)行的，它們也是在一個公共的RTOS上定義的。因此，軟件開發(fā)人員不必?fù)?dān)心任務(wù)在哪個CPU上運行——軟件可以像任務(wù)在同一個CPU上運行一樣編寫。因此，使用多核HW-RTOS不僅可以提供高精度的控制，而且由于系統(tǒng)時鐘率低，還可以保持低功耗。