RTOS的系統節拍

傳統的RTOS都是利用一個硬件定時器產生周期性的節拍中斷，作為系統的時基。在多數的應用中，系統節拍的周期都是毫秒級的，RTOS的超時、延遲、定時的分辨率都是以節拍為單位。即使一個任務在幾個連續的節拍內執行，系統節拍中斷還是會周期性的發生，浪費了CPU的執行時間。下圖是一個示例，雖然某段時間內只有IDLE任務在執行，系統節拍中斷還是會如期發生。

此外，任務延遲或超時等時間相關的功能都基于系統滴答中斷計時，計時時間到后，通過系統節拍周期中斷觸發調度器。因此，如果任務的延遲時間小于一個系統節拍周期，則只能主動等待，直到所需的時間結束。

周期級分辨率的RTOS

SEGGER之前推出的embOS Ultra，改變了過去RTOS采用周期節拍中斷作為系統時基的工作方式，采用硬件定時器加計數器的方式，只在必要時產生中斷。這就消除了傳統的周期性節拍中斷，減少了不必要的CPU活動，同時能降低系統的功耗。embOS Ultra基于時間事件的調度都能以微秒指定。

體驗embOS Ultra微秒級調度

目前embOS Ultra支持CortexM/R/A，以及RISC-V架構的處理器。從官網可以下載到基于SEGGER Embedded Studio的示例Demo，用于測試，內核以二進制庫提供。embOS Ultra的API完全兼容embOS，只是多了幾個任務管理的API，任務可以按照ms或us延遲。

先將Demo例程的任務做了修改，HPTask分別以1000us、2000us不等延遲，LPTask以80ms延遲。

static void HPTask(void) { while (1) {   BSP_SetLED(0);   OS_TASK_Delay_us(1000);   BSP_ClrLED(0);   OS_TASK_Delay_us(2000);   BSP_SetLED(0);   OS_TASK_Delay_us(3000);   BSP_ClrLED(0);   OS_TASK_Delay_us(4000); }}
static void LPTask(void) { while (1) {  BSP_ToggleLED(1);  OS_TASK_Delay_ms(80u); }}

下載代碼至目標板上運行，通過SystemView來觀測系統的執行：

從OS事件視圖可以看到，系統不存在周期性的節拍中斷，只是在需要進行任務調度時觸發一次中斷。從下面的Timeline視圖可以更直觀的看出，紅色涂抹的位置是系統中斷。

注意上圖中的時間(996.8us、1.9ms,2.9ms……)并不是任務的間隔時間，而是調度器執行的間隔時間。

再將任務代碼改成：

static void HPTask(void) { while (1) {   BSP_SetLED(0);   OS_TASK_Delay_us(50);   BSP_ClrLED(0);   OS_TASK_Delay_us(100); }}
static void LPTask(void) { while (1) {  BSP_ToggleLED(1);  OS_TASK_Delay_us(200u); }}

HPTask任務分別延遲50us和100us，LPTask延遲200us，運行后觀測Timeline：

HPTask首次執行延遲了50us之后，系統定時器中斷觸發，調度器開始執行，從IDEL任務切換到HPTask任務。同時可以發現，從中斷觸發到HPTask任務體開始執行實際上已經過去了10us，這是因為中斷處理和任務調度的執行需要消耗一定CPU時間，這個與處理器架構和CPU運行頻率有關，在Cortex-M上大概在10us左右。也就是說在當前的處理器上，延遲時間小于10us是沒有意義的，但是在主頻很高的MPU(應用處理器)上這個時間可能要短很多。

總之，現在很多的MCU的性能都已經很高了。同時，一些應用要求處理器有比較高的計算能力，還要求系統能有很好的實時性，甚至在MPU上使用RTOS。此種應用場景下，如果RTOS支持CPU周期級別的分辨率，這實際上可以進一步提升系統的實時性。而且，在針對一些外設的處理上，使用微秒級的延遲，還能提高CPU的使用效率，擴展了RTOS的潛在應用范圍。