Understanding RTOS Scheduling from a Bare-Metal Perspective

Follow+Star Public Account Number, don’t miss the wonderful content
Understanding RTOS Scheduling from a Bare-Metal Perspective
Author | strongerHuang
WeChat Public Account | strongerHuang
Many embedded developers start from bare-metal programming and then move to RTOS. This article shares the basic principles of RTOS scheduling.
During the job-hunting season in March and April, here are some embedded-related positions to recommend:

Understanding RTOS Scheduling from a Bare-Metal Perspective

It’s normal not to understand these concepts all at once; if you do, I would actually find that abnormal.

What is bare-metal, and what is multitasking?

For beginners, jumping straight into concepts like critical sections, scheduling, semaphores, and mutexes can be overwhelming.

Most people should come from the bare-metal stage, which is generally referred to as a single-task system, polling system or foreground-background system.
This concept should be clear to everyone; polling is executing within a large while loop. The foreground-background system executes while there are interrupts (foreground) responding to the system.
int main(void){  /* Initialization */  while(1)  {    /* Loop to handle multiple tasks */  }}
So, what is multitasking?
When a multitasking operating system uses a task scheduling strategy to allow two or more processes to concurrently share a processor, in fact, the processor will only serve one task at a time.
Because the task scheduling mechanism ensures rapid switching between different tasks, it creates the illusion that multiple tasks are running simultaneously.
— From Baidu Encyclopedia
Beginners can understand it as: there are multiple polling systems like the one above.
As shown in the code, the multiple tasks in the large while loop are divided into several tasks and handled separately.
void Task1(void){  /* Initialization */  while(1)  {    /* Handle task 1 */  }}
void Task2(void){  /* Initialization */  while(1)  {    /* Handle task 2 */  }}
This involves switching between tasks: task scheduling.

Task Scheduling

Before discussing task scheduling, let me share an anecdote:
When I started learning RTOS, I wondered how the CPU could switch back and forth between tasks in such a short time (1ms) while executing so much code; how much code could the CPU actually execute?
In fact, I underestimated the processor’s capability at that time.
Take the STM32F103 running at 72M as an example, do you have any idea how much code can be executed in 1ms?
Following this question, everyone can further think and realize that the few lines of code for switching (task scheduling) can be negligible compared to the CPU speed (of course, this is relative to high-speed processing. For low-frequency processors, this time may be relatively longer).
1. Task Scheduling
Task scheduling can be divided into preemptive scheduling and polling scheduling.
In RTOS, to allow tasks to receive real-time responses, preemptive scheduling is generally used. Let’s take UCOS as an example:
Understanding RTOS Scheduling from a Bare-Metal Perspective
You will find that during program execution, if a high-priority task arrives, it will interrupt the low-priority task.
Only after the high-priority task is completed will the low-priority task receive its response.
Some might ask: Is it okay if a high-priority task runs continuously or for a long time?
The answer is: NO
This relates to task priority allocation and task design issues.
Generally speaking, high-priority tasks wait for an event to trigger, executing something urgent that is not too time-consuming.
Time-consuming tasks are generally left to low-priority tasks to process slowly when the system is not busy.
Understanding RTOS Scheduling from a Bare-Metal Perspective
2. Scheduling Process
We set the system tick to 1ms, so the system will check the higher priority tasks in the ready state every 1ms.
This 1ms tick is generated by a timer interrupt, generally produced by the kernel tick timer in STM32.
As shown in the figure, at position (2), it detects that a higher priority task (7) is ready, and it will jump to task (7) for execution.

———— END ————

Understanding RTOS Scheduling from a Bare-Metal Perspective

● Column “Embedded Tools”

● Column “Embedded Development”

● Column “Keil Tutorial”

● Selected tutorials from the Embedded Column

Follow the public account reply “Join Group” to join the technical exchange group according to the rules, reply “1024” to see more content.

Understanding RTOS Scheduling from a Bare-Metal Perspective

Understanding RTOS Scheduling from a Bare-Metal Perspective

Click “Read Original” to see more shares.

Leave a Comment

×