RTOS system beat
Traditional RTOS uses a hardware timer to generate periodic beat interrupts as the system time base. In most applications, the system beat period is in milliseconds, and the resolution of RTOS timeout, delay, and timing is in beats. Even if a task is executed in several consecutive beats, the system beat interrupt will still occur periodically, wasting the CPU execution time. The figure below is an example. Although only the IDLE task is executed for a period of time , the system beat interrupt will still occur as scheduled.
In addition, time-related functions such as task delay or timeout are based on system tick interrupt timing. When the timing time is up, the scheduler is triggered by the system tick cycle interrupt. Therefore, if the delay time of the task is less than one system tick cycle, it can only actively wait until the required time is over.
RTOS with cycle-level resolution
SEGGER launched embOS Ultra some time ago , which changed the previous RTOS working mode of using periodic beat interrupts as the system time base, and adopted the hardware timer plus counter method to generate interrupts only when necessary. This eliminates the traditional periodic beat interrupts, reduces unnecessary CPU activities, and reduces system power consumption. The scheduling of embOS Ultra based on time events can be specified in microseconds.
Experience embOS Ultra microsecond-level scheduling
Currently, embOS Ultra supports CortexM/R/A and RISC-V architecture processors. You can download a demo based on SEGGER Embedded Studio from the official website for testing. The kernel is provided as a binary library. The API of embOS Ultra is fully compatible with embOS , except for a few more task management APIs . Tasks can be delayed in ms or us .
First, the tasks of the Demo routine were modified. The HPTask had delays of 1000us and 2000us , and the LPTask had a delay of 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);
}
}
Download the code to the target board and run it. Use SystemView to observe the execution of the system:
From the OS event view, we can see that the system does not have periodic beat interrupts, but only triggers an interrupt when task scheduling is required. From the Timeline view below, we can see more intuitively that the red painted position is the system interrupt.
Note that the time in the above figure (996.8us , 1.9ms, 2.9ms...) is not the interval time of the task, but the interval time of the scheduler execution.
Then change the task code to:
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);
}
}
The HPTask tasks are delayed by 50us and 100us respectively , and the LPTask is delayed by 200us . After running, observe the Timeline :
After the first execution of HPTask is delayed by 50us , the system timer interrupt is triggered, the scheduler starts to execute, and switches from IDEL task to HPTask task. At the same time, it can be found that 10us has actually passed from the interrupt trigger to the start of the HPTask task body . This is because the execution of interrupt processing and task scheduling requires a certain amount of CPU time, which is related to the processor architecture and CPU operating frequency. It is about 10us on Cortex-M . That is to say, on the current processor, it is meaningless to have a delay time less than 10us , but on the MPU ( application processor ) with a very high main frequency , this time may be much shorter.
In short, the performance of many MCUs is already very high. At the same time, some applications require the processor to have relatively high computing power, and also require the system to have good real-time performance, and even use RTOS on MPU . In this application scenario, if RTOS supports CPU cycle-level resolution, it can actually further improve the real-time performance of the system. Moreover, in the processing of some peripherals, the use of microsecond-level delays can also improve the efficiency of CPU use and expand the potential application range of RTOS .
提升卡
变色卡
千斤顶
京公网安备 11010802033920号
