RTOS的系统节拍

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的潜在应用范围。

---

审核编辑 ：李倩