freeRTOS Scheduling Algorithms(任務調度器設定)
Prioritized Pre-emptive Scheduling with Time Slicing(具有時間片斷的優先優先調度)
sets the FreeRTOS scheduler to use a scheduling algorithm called ‘Fixed Priority Pre-emptive Scheduling with Time Slicing’
(設定程此模式的方法)
#define configUSE_PREEMPTION 1//(在FreeRTOSConfig.h內)#define configUSE_TIME_SLICING 1//(在FreeRTOS.h內)
關鍵詞解釋
Fixed Priority
Scheduling algorithms described as ‘Fixed Priority’ do not change the priority
assigned to the tasks being scheduled, but also do not prevent the tasks
themselves from changing their own priority, or that of other tasks.
Pre-emptive
Pre-emptive scheduling algorithms will immediately ‘pre-empt’ the Running
state task if a task that has a priority higher than the Running state task
enters the Ready state. Being pre-empted means being involuntarily (without
explicitly yielding or blocking) moved out of the Running state and into the
Ready state to allow a different task to enter the Running state.
Time Slicing
Time slicing is used to share processing time between tasks of equal priority,
even when the tasks do not explicitly yield or enter the Blocked state.
Scheduling algorithms described as using ‘Time Slicing’ will select a new task
to enter the Running state at the end of each time slice if there are other
Ready state tasks that have the same priority as the Running task. A time
slice is equal to the time between two RTOS tick interrupts.
The configIDLE_SHOULD_YIELD compile time configuration constant can be used to change how the Idle task is scheduled:
configIDLE_SHOULD_YIELD is set to 0
the Idle task will remain in the Running state for the entirety of its time slice, unless it is preempted by a higher priority task.
(若有與idle state 相同優先權(0)的任務則此任務與idle state都各執行一個time slice才會換對方執行)
configIDLE_SHOULD_YIELD is set to 1
the Idle task will yield (voluntarily give up whatever remains of its allocated time slice) on each iteration of its loop if there are other Idle priority tasks in the Ready state.
(若有與idle state 相同優先權(0)的任務則idle state每跑完一個loop後都會檢察一樣優先權的任務是否ready了若ready則執行該任務)
Prioritized Pre-emptive Scheduling (without Time Slicing)
Prioritized Preemptive Scheduling without time slicing maintains the same task selection and pre-emption algorithms as described in the previous section, but does not use time slicing to share processing time between tasks of equal priority.(設定程此模式的方法)
#define configUSE_PREEMPTION 1//(在FreeRTOSConfig.h內)
#define configUSE_TIME_SLICING 0//(在FreeRTOS.h內)
If time slicing is not used, then the scheduler will only select a new task to enter
the Running state when either:
(若沒有使用time slice 責任務改變的狀況為下)
- A higher priority task enters the Ready state.
- The task in the Running state enters the Blocked or Suspended state
There are fewer task context switches when time slicing is not used than when time slicing is
used. Therefore, turning time slicing off results in a reduction in the scheduler’s processing
overhead. However, turning time slicing off can also result in tasks of equal priority receiving
greatly different amounts of processing time
Co-operative Scheduling
When the co-operative scheduler is used, a context switch will only occur when the Running
state task enters the Blocked state, or the Running state task explicitly yields (manually
requests a re-schedule) by calling taskYIELD(). Tasks are never pre-empted, so time slicing
cannot be used.
(任務調度需要手動執行，只有呼叫taskYIELD()時才會啟動任務調度)
#define configUSE_PREEMPTION 0//(在FreeRTOSConfig.h內)
#define configUSE_TIME_SLICING any value//(在FreeRTOS.h內)
1. Task 1 is in the Running state and starts to write its string. It writes “abcdefg” to the UART, but leaves the Running state before writing any further characters.
2. Task 2 enters the Running state and writes “123456789” to the UART, before leaving the Running state.
3. Task 1 re-enters the Running state and writes the remaining characters of its string to the UART.
In that scenario what is actually written to the UART is “abcdefg123456789hijklmnop”. The string written by Task 1 has not been written to the UART in an unbroken sequence as intended, but instead it has been corrupted, because the string written to the UART by Task 2 appears within it.
101
It is normally easier to avoid problems caused by simultaneous access when the co-operative scheduler is used than when the pre-emptive scheduler is used1:
When the pre-emptive scheduler is used the Running state task can be pre-empted at any time, including when a resource it is sharing with another task is in an inconsistent state. As just demonstrated by the UART example, leaving a resource in an inconsistent state can result in data corruption.
When the co-operative scheduler is used the application writer controls when a switch to another task can occur. The application writer can therefore ensure a switch to another task does not occur while a resource is in an inconsistent state.
In the above UART example, the application writer can ensure Task 1 does not leave the Running state until its entire string has been written to the UART, and in doing so, removing the possibility of the string being corrupted by the activates of another task.
As demonstrated in Figure 30, systems will be less responsive when the co-operative scheduler is used than when the pre-emptive scheduler is used:
When the pre-emptive scheduler is used the scheduler will start running a task immediately that the task becomes the highest priority Ready state task. This is often essential in real-time systems that must respond to high priority events within a defined time period.
When the co-operative scheduler is used a switch to a task that has become the highest priority Ready state task is not performed until the Running state task enters the Blocked state or calls taskYIELD().
#define configUSE_TIME_SLICING any value//(在FreeRTOS.h內)
pros &cons between co-operative and pre-emptive
In a multi-tasking application the application writer must take care that a resource is not accessed by more than one task simultaneously, as simultaneous access could corrupt the resource. As an example, consider the following scenario in which the resource being accessed is a UART (serial port). Two tasks are writing strings to the UART; Task 1 is writing “abcdefghijklmnop”, and Task 2 is writing “123456789”:1. Task 1 is in the Running state and starts to write its string. It writes “abcdefg” to the UART, but leaves the Running state before writing any further characters.
2. Task 2 enters the Running state and writes “123456789” to the UART, before leaving the Running state.
3. Task 1 re-enters the Running state and writes the remaining characters of its string to the UART.
In that scenario what is actually written to the UART is “abcdefg123456789hijklmnop”. The string written by Task 1 has not been written to the UART in an unbroken sequence as intended, but instead it has been corrupted, because the string written to the UART by Task 2 appears within it.
101
It is normally easier to avoid problems caused by simultaneous access when the co-operative scheduler is used than when the pre-emptive scheduler is used1:
When the pre-emptive scheduler is used the Running state task can be pre-empted at any time, including when a resource it is sharing with another task is in an inconsistent state. As just demonstrated by the UART example, leaving a resource in an inconsistent state can result in data corruption.
When the co-operative scheduler is used the application writer controls when a switch to another task can occur. The application writer can therefore ensure a switch to another task does not occur while a resource is in an inconsistent state.
In the above UART example, the application writer can ensure Task 1 does not leave the Running state until its entire string has been written to the UART, and in doing so, removing the possibility of the string being corrupted by the activates of another task.
As demonstrated in Figure 30, systems will be less responsive when the co-operative scheduler is used than when the pre-emptive scheduler is used:
When the pre-emptive scheduler is used the scheduler will start running a task immediately that the task becomes the highest priority Ready state task. This is often essential in real-time systems that must respond to high priority events within a defined time period.
When the co-operative scheduler is used a switch to a task that has become the highest priority Ready state task is not performed until the Running state task enters the Blocked state or calls taskYIELD().
留言
張貼留言