Follow+Star Public Account Number, don’t miss out on exciting content
Author | strongerHuang
WeChat Public Account | Embedded ColumnFreeRTOS has captured a significant portion of the RTOS market due to its early open-source and free commercial use (under the MIT open-source license). With the popularity of multi-core MCUs, FreeRTOS has also kept pace with the trend and supports multi-core scheduling. Today, I will share the scheduling strategies of FreeRTOS for single-core and multi-core systems.
Single-Core Scheduling Strategy
Single-core scheduling is a feature that all RTOS must have, and it is the most basic requirement.
The single-core scheduling strategy of FreeRTOS is similar to many RTOS on the market, which is: by default, it uses a fixed priority preemptive scheduling strategy, executing tasks of equal priority using a time-slice round-robin scheduling.
-
Fixed Priority: This means that the scheduler does not permanently change the priority of tasks, but may temporarily elevate a task’s priority due to priority inheritance.
-
Preemptive: This means that the scheduler always runs the highest priority runnable RTOS task, regardless of when the task can run. For example, if an interrupt service routine (ISR) changes the highest priority runnable task, the scheduler will stop the currently running lower priority task and start the higher priority task—even if this occurs within the same time slice. In this case, it can be said that the high-priority task “preempts” the low-priority task.
-
Round-Robin Scheduling: This means that tasks with the same priority take turns entering the running state.
-
Time-Slicing: This means that the scheduler switches between tasks of equal priority at each tick interrupt, with the time between tick interrupts constituting a time slice. (Tick interrupts are periodic interrupts used by RTOS to measure time.)
For more information, refer to my previous article: On the Issue of RTOS Tick Configuration
Configuring Scheduling Strategy FreeRTOSConfig.h is the configuration file for the entire system, and there are two scheduling-related configurations here.1. configUSE_PREEMPTION The default configuration is 1
#define configUSE_PREEMPTION 1If configUSE_PREEMPTION is set to 0, it means preemption is disabled, and context switching will only occur when a running task enters a “blocked” or “suspended” state, or when a running task calls taskYIELD(), or when an ISR manually requests a context switch.2. configUSE_TIME_SLICING This configuration was not available in earlier versions and is a later addition. Similarly, the default configuration is 1
#define configUSE_TIME_SLICING 1If configUSE_TIME_SLICING is set to 0, it means time slicing is disabled, and the scheduler will not switch between tasks of equal priority at each tick interrupt.
Multi-Core Scheduling Strategy
Multi-core scheduling for MCUs is divided into: Symmetric Multi-Processing (SMP) and Asymmetric Multi-Processing (AMP).
1. Symmetric Multi-Processing (SMP)
Using FreeRTOS for Symmetric Multi-Processing (SMP) means that a single FreeRTOS instance can schedule RTOS tasks across multiple processor cores.
Since only one FreeRTOS instance is running, only one “port” of FreeRTOS can be used at a time, so each core must have the same processor architecture and share the same memory space.
For (SMP) symmetric multi-processing, there are also related configurations in the FreeRTOSConfig.h configuration file.a. configRUN_MULTIPLE_PRIORITIES If configRUN_MULTIPLE_PRIORITIES is set to 0, the scheduler will only run multiple tasks simultaneously if multiple tasks have the same priority. This can fix code written under the assumption that only one task will run at a time, but it sacrifices some benefits brought by SMP configuration.b. configUSE_CORE_AFFINITY If configUSE_CORE_AFFINITY is set to 1, the vTaskCoreAffinitySet() API function can be used to define which cores a task can run on and which cores it cannot run on. Using this method, application developers can prevent two tasks that assume their execution order from running simultaneously.
2. Asymmetric Multi-Processing (AMP)
Using FreeRTOS for Asymmetric Multi-Processing (AMP) means that each core of a multi-core device runs its own FreeRTOS instance independently. These cores do not all need to have the same architecture, but if communication is required between FreeRTOS instances, they need to share some memory.
Each core runs its own FreeRTOS instance, so the scheduling algorithm on any given core is exactly the same as the single-core system scheduling algorithm described above. You can use stream buffers or message buffers as inter-core communication primitives, allowing a task on one core to enter a “blocked” state while waiting for data or events from another core.
In a previously shared article “ Principles of Communication Between Dual-Core MCUs M4 and M7” I discussed some principles of the specific implementation of Asymmetric Multi-Processing (AMP).
The basic principle of communication between dual cores: the sending and receiving tasks are located on different cores of a multi-core microcontroller (MCU) in an Asymmetric Multi-Processing (AMP) configuration, meaning each core runs its own FreeRTOS program. At the same time, one core has the ability to generate interrupts in the other core, and both cores have access to a memory area (shared memory). The message buffer is placed in shared memory at an address known to the application running on each core, as shown in the figure below:
Ideally, there will also be a Memory Protection Unit (MPU) to ensure that the message buffer can only be accessed through the message buffer API of the core, and it is best to mark the shared memory as inaccessible to other programs.
———— END ————
● Column “Embedded Tools”
● Column “Embedded Development”
● Column “Keil Tutorials”
● 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.
Click “Read the Original” to see more shares.