In the front, you can create a task, start the scheduler and control the task. Next, you can start to analyze the arrival of a Tick, FreeRTOS What behavior is about to happen;
When the scheduler is started, SysTick has been configured. As the heartbeat of the OS, SysTick comes every fixed cycle interrupt To drive the OS to do things (task scheduling);
Taking STM32 as an example, the defined "configtick"_ RATE_ The Hz is 1000 and is controlled by< FreeRTOS -- (9) startup scheduler for task management >It is known that the system beat clock cycle is 1ms;
Different processor structures may be different, so it is the part that needs to be transplanted in port C) xPortSysTickHandler:
Call vPortRaiseBASEPRI() at the beginning; Call vPortClearBASEPRIFromISR() at the end; To create critical zones;
Xtask incrementtick is called; If pdTRUE is returned, it means that task switching is required, then manually pull up PendSV; Otherwise, context switching will not be performed;
Next, let's take a look at what xtask incrementtick has done. I guess it is the task with the highest priority and put into operation in the Ready linked list:
This function is a little long, but the idea is very clear and easy to understand:
1. Because FreeRTOS supports suspending the scheduler, that is, after calling vtask suspendall, RTOS will not switch the context of the scheduled task when each Tick comes; Therefore, every time you enter xtask incrementtick, you should judge whether the scheduler is suspended;
2. If scheduling is allowed, first increase the count of the current counter: xTickCount;
3. After adding # xTickCount, judge whether the counter overflows. If it overflows, call # taskSWITCH_DELAYED_LISTS to exchange # pxDelayedTaskList and # pxOverflowDelayedTaskList (in order to solve the overflow problem of xTickCount, FreeRTOS uses two delay lists: xDelayedTaskList1 and xDelayedTaskList2. It also uses the delay list pointer pxDelayedTaskList and overflow delay list pointer pxOverflowDelayedTaskList to point to delay list 1 and delay list 2 respectively (point the delay list pointer to the delay list when creating the task). These two delay list pointer variables and two delay list variables are in tasks (static local variables defined in C)
These two linked lists exist specifically to deal with counter overflow; In case of overflow, it will be exchanged. The OS always takes the Delay Task in the # pxDelayedTaskList. When hanging the task, judge the clock counter to see whether it is necessary to hang to # pxoverflow delayedtasklist;
4. Compare the current time, xConstTickCount, and the time of the next blocked task, xNextTaskUnblockTime, to see if the blocking time expires. xNextTaskUnblockTime is a global variable that records the blocking time of the next most recent task;
5. If the blocking time expires, first judge whether the current delay linked list is empty. If it is empty, it indicates that there are no tasks blocked in time. Assign ＾ xNextTaskUnblockTime to the maximum ＾ portMAX_DELAY, exit directly;
6. If the blocking time expires and the # pxDelayedTaskList list is not empty, take out the time of the first element of the # pxDelayedTaskList list (note that when inserting items into the pxDelayedTaskList list, use # vListInsert, which is inserted orderly according to the wake-up time, that is, the one with the smallest Delay time is placed in front and the one with the largest Delay is placed later), Compare with the current time # xConstTickCount to see if it is overdue. If it is not overdue, update it to the next wake-up time # xNextTaskUnblockTime and exit; If it expires, remove it from the pxDelayedTaskList list (if the Event is also removed from the Event when waiting for it), and add it to the ReadyList (prvAddTaskToReadyList),
7. If preemption is supported (RTOS that do not support preemption have no soul), it is necessary to judge the priority of the unblocked task and the current task, which is higher. If it is higher than the current task priority, then # xSwitchRequired is set to pdTRUE, indicating that a context switch is required;
8. Cycle steps 4 to 7, that is, traverse the elements in the pxdelayedtask list until the pxdelayedtask list is empty or the running time of some elements has not yet arrived, and it needs to continue blocking;
9. At this moment, all the tasks due have been moved from the pxDelayedTaskList linked list to the corresponding priority in the pxReadyTasksLists;
10. If configure_preemption is defined and the same priority rotation scheduling is also defined (in general, both need to be defined, otherwise there is no soul), as long as the pxReadyTasksLists list where the current task is located contains more than one task to be run, You have to rotate and schedule another task to execute; Therefore, xSwitchRequired is set to pdTRUE;
11. If the application layer defines "configure"_ TICK_ Hook, then the {vApplicationTickHook hook will be called;
12. If configure_preemption is defined and # xYieldPending is also pdTRUE, xSwitchRequired will also be set to # pdTRUE to force context switching,
When will the variable xYieldPending be set to pdTRUE?
For queues and semaphore and mutex using queue mechanism, these API functions are invoked in the interrupt service routine, and the task is removed from the blocking. Then the function xTaskRemoveFromEventList() is called to remove the task list item from the list of events. During the process of removing the event list item, it will judge whether the priority of the released task is higher than that of the current task. If the priority of the released task is higher, the variable xYieldPending will be set to pdTRUE. Trigger a task switching in the next system beat interrupt service function;