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的潜在应用范围。
审核编辑 :李倩
-
mcu
+关注
关注
146文章
17123浏览量
350973 -
高分辨率
+关注
关注
0文章
45浏览量
15313 -
定时器
+关注
关注
23文章
3246浏览量
114714
原文标题:embOS-Ultra:高分辨率系统时间
文章出处:【微信号:麦克泰技术,微信公众号:麦克泰技术】欢迎添加关注!文章转载请注明出处。
发布评论请先 登录
相关推荐
评论