一.背景介紹

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

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

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

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

1.1 OS 實時難題

• CPU 調度模型

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

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

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

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

• Event Driven

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

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

• Real Time

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

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

1.2 Linux 實時補丁

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

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

1.3 Xenomai + Linux 雙內核

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

Xenomai + Linux 雙內核可以達到 RTOS 的實時水平，也有把這種稱為硬實時。

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

1.4 HW-RTOS

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

可以把HW-RTOS看作是CPU的硬件浮點單元(FPU)，加速內核常用操作的專用硬件。然而，HW-RTOS并不執(zhí)行基于軟件的內核中通?？捎玫乃胁僮?。這類似于浮點處理器，它只提供基本的浮點運算，如加、減、乘、除、從浮點數(shù)到整型和從整型到浮點數(shù)的運算，省略了更復雜的運算，如超越運算、對數(shù)運算和其他運算。在使用HW-RTOS作為骨干時，更復雜的內核操作通?？梢栽谲浖袑崿F(xiàn)。

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

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

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

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

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

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

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

1.5 More

需要特別注意的是，就算實現(xiàn)了 HW-RTOS 但是還是有影響實時的硬件因素存在：Cache Miss、TLB Miss、分支預測失敗、長跳轉與短跳轉、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ù)軟件工程師認為的要大得多，并且發(fā)現(xiàn)很難保證最壞情況下的值。核心點就是 API 的函數(shù)復雜度是 O(n) 而不是 O(1)。

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

2.1.1 Software API Execution time

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

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

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

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

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

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

2.1.2 Software Influence of Queue Handling

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

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

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

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

測試結果如下圖所示：

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

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

2.1.3 HW-RTOS API Execution time

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

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

2.1.4 HW-RTOS Influence of Queue Handling

HW-RTOS使用瑞薩特有的“虛擬隊列”技術實現(xiàn)硬件隊列。Virtual Queue可以將任務添加到隊列中，從隊列中刪除任務，也可以從隊列中間刪除任務，每個操作周期為2個周期。因此，無論隊列的狀態(tà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調用實現(xiàn)了3個專門的寄存器:

API register,  
Argument register,  
Result register

瑞薩已經為處理這些寄存器準備了一個操作系統(tǒng)庫。用戶可以使用操作系統(tǒng)庫輕松調用API調用，就像傳統(tǒng)的軟件RTOS一樣。當調用set_flg API調用時，OS庫將參數(shù)寫入參數(shù)寄存器，并將API的類型寫入API寄存器。當HW-RTOS接收到這些信息時，它執(zhí)行API并將返回值寫入結果寄存器。OS庫將返回值報告給調用方應用程序。執(zhí)行API時可能需要進行任務切換。在這種情況下，HW-RTOS表示需要進行任務切換，并將下一個應該執(zhí)行的任務的ID寫入結果寄存器，以將該信息傳遞到OS庫。OS庫根據此信息執(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需要處理一些定時任務。包括定時器、sleep()、xxx_timeout()、時間片調度等。為了這個目的，測量時間的軟件處理被周期性地激活。這就是所謂的Tick進程。如圖所示，為了激活tick進程，需要周期性中斷。

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

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

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

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

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

3.1.2 HW-RTOS Tick

HW-RTOS完全在硬件上實現(xiàn)tick過程。這個功能被稱為 tick offloading。tick過程在HW-RTOS內部執(zhí)行。因此，不需要周期中斷滴答，也不需要CPU執(zhí)行滴答過程。如圖所示，CPU在任何時候都可以自由運行應用軟件。只有在通過超時執(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中當一個中斷發(fā)生時，一個中斷服務程序(ISR)被激活。通常，在ISR執(zhí)行時，中斷是禁用的。在下圖的上半部分，ISR1和ISR2根據中斷類型交替激活。如果ISR1的處理時間延長，另一個中斷將被錯過或延遲，如圖下方所示。對于實時系統(tǒng)來說，錯過或延遲中斷是不受歡迎的。

4.1.2 Software ISR handed over to Task

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

讓我們更詳細地看看這種方式下發(fā)生中斷時ISR是如何執(zhí)行API的。下圖顯示了這一點。讓我們假設在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.

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

4.1.3 HW-RTOS ISR handed over to Task

上述過程如果使用HW-RTOS，圖中顯示的所有RTOS處理(除了dispatch處理)都是在硬件上實現(xiàn)的，因此處理速度非?？?。HW-RTOS進一步加速了這一過程。也就是說，它加速了ISR進程。ISR簡單地調用與中斷源對應的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只在任務切換期間停止。

下圖顯示了在API執(zhí)行結束時Task_B處于就緒狀態(tài)的一個例子，但是當Task_B被交給ISR處理時，Task_B的優(yōu)先級比Task_A的優(yōu)先級低或相等。在本例中，由于Task_A具有更高的優(yōu)先級，因此不需要切換任務，因此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í)行的進程，可以簡單地提高HW ISR激活的任務的優(yōu)先級。當然，HW-RTOS也同時支持傳統(tǒng)的ISR。

4.1.4 Non-OS managed Interrupt & Direct Interrupt Service

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

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

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

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

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

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

4.2 具體實現(xiàn)

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

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

4.3 性能測試

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

4.4 相關應用

4.4.1 Multiple interrupts using HW ISR

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

4.4.2 Cyclic activation task

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

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

4.4.3 Using cyclic activation task for network synchronization

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

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

5.1 原理介紹

HW-RTOS 的任務管理分為兩部分：

• 一部分是任務的調度器用來選取哪個任務進行調度。
• 另一部分是任務的上下文切換。

5.1.1 HW-RTOS Scheduler

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

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

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

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

5.1.1 HW-RTOS Context Switch

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

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

5.2 具體實現(xiàn)

六.典型案例

6.1 Network and RTOS

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

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

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

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

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

七.下一代HW-RTOS

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

• Tightly coupled HW-RTOS

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

• Cyclic handler

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

• Multi-core support

下一代HW-RTOS的第三個新功能是多核支持。單核HW-RTOS的所有功能和優(yōu)點延續(xù)到多核HW-RTOS。因此，作為一個實時操作系統(tǒng)，它提供了高水平的實時性能。此外，cpu間的處理，即cpu間的同步和cpu間的通信非?？?，執(zhí)行時間的波動大大減少。這些特性的好處是很容易在多核系統(tǒng)上實現(xiàn)實時應用程序系統(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技術，通過高速、高精度的同步，解決了傳統(tǒng)軟件RTOS中cpu間的同步和通信問題。由于使用多核HW-RTOS可以實現(xiàn)cpu間的同步速度小于1微秒，因此可以實現(xiàn)cpu間的精確定時控制。即使任務是由不同的cpu執(zhí)行的，它們也是在一個公共的RTOS上定義的。因此，軟件開發(fā)人員不必擔心任務在哪個CPU上運行——軟件可以像任務在同一個CPU上運行一樣編寫。因此，使用多核HW-RTOS不僅可以提供高精度的控制，而且由于系統(tǒng)時鐘率低，還可以保持低功耗。