catalogue
1. Describe the structure of the task
In< FreeRTOS -- (7) introduction to task management >Article basic analysis After the task related outline is, we know what interface to use to create a task, how to start the scheduler, and select the behavior of the scheduler according to the macro configuration; Next, let's go deep into the source code of FreeRTOS task creation to see how a task is created (a great God said that Read The F**king Source Code can be solved with code, and try not to BB);
1. Describe the structure of the task
stay FreeRTOS In, TCB is used_ T to describe a task:
1. pxTopOfStack must be in the first item of the structure and point to the top of the current stack. For a downward growing stack, pxTopOfStack always points to the last content put into the stack. The pointer will move;
2. If MPU is used, xmpussettings must be located in the second item of the structure for MPU settings.
3. The status linked list xStateListItem is used to link tasks to different status linked lists. For example, if the task is in Ready status, it should be linked to the Ready linked list;
4. List similar events;
5. uxPriority is used to save the priority of the task, and 0 is the lowest priority;
6. pxStack points to the starting position of the stack, and the pointer returned by the memory function of the application stack is assigned to the variable. pxTopOfStack points to the top of the current stack. The position pointed by pxTopOfStack will change as the stack goes in and out; pxStack points to the starting position of the current stack. Once allocated, the starting position of the stack will be fixed and will not be changed. So why do you need the pxStack variable? This is because the stack may overflow as the task runs. In a system where the stack grows downward, this variable can be used to check whether the stack overflows; If you want to determine whether the stack overflows in the system with upward stack growth, you need another variable pxEndOfStack to help diagnose whether the stack overflows;
7. pcTaskName is used to save the description or name of the task. The length of the name is determined by the macro configMAX_TASK_NAME_LEN (in FreeRTOSConfig.h) is specified and contains the end of string flag.
8. If the stack grows upward (portstack_growth > 0), the pointer pxEndOfStack points to the end of the stack to check whether the stack overflows.
9. uxCriticalNesting is used to save the nesting depth of critical areas. The initial value is 0.
10. Only if macro configure_ TRACE_ Valid when facility (in FreeRTOSConfig.h) is 1. The variable uxTCBNumber stores a value. When creating a task, the kernel automatically assigns the value (usually the value increases by 1 for each task). The uxTCBNumber value of each task is different and is mainly used for debugging. The variable uxTaskNumber is used to store a specific value. Unlike the variable uxTCBNumber, the value of uxTaskNumber is not allocated by the kernel, but set through the API function vTaskSetTaskNumber(), and the value is specified by the function parameters.
11. If mutex is used (configure_mutexes = = 1), when the task priority is temporarily increased, the variable uxBasePriority is used to save the original priority of the task.
12. The variable ucStaticAllocationFlags also needs to be explained. As we said earlier, the task creation API function xTaskCreate() can only use dynamic memory allocation to create task stack and task TCB. If you want to use static variables to implement task stack and task TCB, you need to use the function xTaskGenericCreate(). If the task stack or task TCB is implemented by static array and static variable, set the variable to pdTRUE (0x01 when the task stack space is implemented by static array variable, 0x02 when the task TCB is implemented by static variable, and 0x03 when both task stack and task TCB are implemented by static variable). If the stack is dynamically allocated, set the variable to pdFALSE.
2. Task creation
2.1,xTaskCreate
To create a task, use xtask create Interface , the parameters passed in< FreeRTOS -- (7) introduction to task management >It is described in. I won't say more here. Let's take a direct look at its implementation in task In C:
The first is based on portSTACK_GROWTH macro to determine the growth direction of the current processor architecture stack, portSTACK_GROWTH > 0 means that the stack grows upward, portSTACK_GROWTH < 0 means that the stack grows downward; The growth direction of the stack is closely related to the architecture of the processor. Here, take the Cortex-M series processor as an example. Its stack grows downward. Therefore, when transplanting FreeRTOS to Cortex-M series processors, we must remember to use "portstack" here_ Growth is defined to be less than 0;
Conversely, why judge the growth direction of the Stack when creating tasks? The root cause is that when creating a task, memory needs to be allocated for the TCB of the task and the Stack of the task. The allocation of memory needs to be realized through the pvPortMalloc interface, and the allocation of memory by pvPortMalloc starts from a small address, so:
If the Stack grows upward, first call pvPortMalloc to allocate the TCB structure of the task, and then allocate the Stack of the task, because the size of the TCB is fixed, but the Stack should grow upward, so as to avoid the Stack stepping on the TCB;
If the Stack grows downward, first call pvPortMalloc to allocate the Stack of the task, and then allocate the TCB structure of the task, so that when the Stack grows, it can also avoid stepping on the TCB structure;
After allocating the Stack, set pxnewtcb - > pxStack = pxStack of TCB; At this moment, pxStack is initialized;
Here's another nagging sentence. The space allocated to the task stack is:
( ( size_t ) usStackDepth ) * sizeof( StackType_t )
Stacktype here_ T is related to CPU architecture. Stacktype under 32-bit CPU_ T is defined as uint32_t. That is, 4 bytes;
If the TCB structure and task Stack are successfully assigned to the task, it will call: prvInitialiseNewTask and prvAddNewTaskToReadyList;
prvInitialiseNewTask mainly refers to the TCB related content of the initialization task;
Prvaddnewtask toreadylist adds the initialized task to the Ready linked list, that is, it is allowed to be put into execution;
If the task is created successfully, return pdPASS; otherwise, return pdflare;
2.2,prvInitialiseNewTask
Let's take a look at the specific implementation of prvInitialiseNewTask:
There are many contents, which are analyzed line by line;
The configuration of MPU is not concerned for the time being;
If tskset is used_ NEW_ STACKS_ TO_ KNOWN_ Value macro, which means that the Stack of the initialized task needs to be filled with a fixed value (0xA5);
Then judge the growth direction of the stack. Why are you judging the growth direction of the stack here? Previously, the stack header pointer pxnewtcb - > pxstack after initialization was assigned, but now we need to assign an initial value to the stack pointer (the one that will move) actually used when the task runs;
If the stack grows downward, we need to place the stack top pointer pxTopOfStack at the end of the allocated stack to grow downward;
If the stack grows upward, we can directly assign pxnewtcb - > pxstack to pxTopOfStack:
Taking Cortex-M3 as an example, the stack grows downward, so it will enter portstack_ The branch with growth < 0 points pxTopOfStack to the end of the stack depth allocated, and performs 8-byte alignment of the stack (processor architecture requirements);
Note that at this moment, # pxTopOfStack is only a local variable and is not directly assigned to # pxTopOfStack of TCB;
Then assign a value to the TCB - > pctaskname field (task name). This field is a string and its length is limited by configMAX_TASK_NAME_LEN；
Then assign a value to the TCB - > uxpriority task priority field;
If MUTEXES is used, assign uxPriority to BasePriority and set the current mutex hold field to 0;
Initialize the status Item of TCB, and set the Owner of the Item to the currently initialized TCB;
Initialize the Event Item of TCB, set the Owner of the Item as the currently initialized TCB, and configure the Value of the Event Item as the maximum priority minus the current priority. The Value in the Item here does not directly save the priority, but saves the complement of the priority, which means that the larger the Value of xItemValue, the smaller the corresponding task priority;
The nesting times of initialization critical area is 0;
The task notification Value is initialized to 0; Notification status initialization, etc;
There is one place to pay attention to here, porthas_ STACK_ OVERFLOW_ The macro checking is not defined in CM3. I think it should be the detection of stack overflow corresponding to the processor;
Call pxportinitializestack to pass in the previously set stack top pointer, Task execution function, and parameter pointer to be passed to Task; Assign the result to TCB - > pxtopofstack;
Finally, everything is successful, and the TCB address is paid to the handle after the Task is successfully created;
Here, let's take a look at the pxportinitializestack function:
2.3,pxPortInitialiseStack
With Port, the description is related to the architecture of the processor. To understand what this function is doing, you need a little knowledge of the architecture. Here we still take Cortex-M3 as an example;
In Cortex-M3 processor, when an exception / interrupt occurs, the processor will stack the key registers to protect the site, and then jump to ISR for execution. This is a pure hardware behavior; After executing ISR, the processor will be out of the stack in sequence;
When entering the stack, the contents are stored in spatial order as follows:
xPSR,PC,LR,R12,R3,R2,R1,R0；
When it acts as ISR, the processor hardware will go to the place where these things were stored (SP) to pop up the stack and restore the scene;
The OS scheduling switching context is done in ISR;
Therefore, during initialization (CM3 thread mode), we will manually simulate the behavior of the processor into the stack, put these things in it and get ready. When the OS is scheduled, just tell it the stack pointer, hey, the processor will pop up the stack;
For more information about CM3 processor, please refer to< Cortex-M3 processor snooping>
Well, after the explanation, you can look at the code:
According to the CM3 stack pressing method, this function is done manually once:
The initial value given by the position of xPSR ＾ is 0x01000000, where bit24 is set to 1, indicating the Thumb instruction is used;
The location of the PC gives the entry of this task. When the OS scheduler selects SP and exits the scheduling, this will be assigned to the PC pointer of the CPU, that is, the task function will be called;
The location of LR is assigned a function called prvTaskExitError. Because our task will never return, if the task returns, it indicates an error;
Position reservation of R12, R3, R2 and R1;
The position of R0 holds the parameter pointer pvParameters passed to the task. According to the call rules of the assembly, R0 is the first parameter passed;
The remaining positions are R11, R10, R9, R8, R7, R6, R5 and R4;
At this moment, the # pxTopOfStack can be directly assigned to TCB - > pxTopOfStack;
OK, now all the basic elements of TCB have been initialized;
Let's go back to the # xtask create call. Finally, we call # prvaddnewtask toreadylist to add the currently initialized tasks to the Ready linked list;
2.4,prvAddNewTaskToReadyList
Prvaddnewtask toreadylist, add the task to the Ready linked list, and directly execute the following code:
The Ready linked list can be accessed in many places, as well as in ISR. In order to ensure the effectiveness of access, call taskenter first_ Critical () enters the critical zone;
uxCurrentNumberOfTasks records the individuals of the current task. Now the task is added, so it is added here;
pxCurrentTCB is a global variable. When the scheduler is not working, it points to the task with the highest priority in Ready; Here, judge whether the current added task is the first task. If it is the first task, call prvnitializetasklists to initialize the task list;
The Ready linked list is in the form of a linked list array, which puts different priorities separately. Typically, space changes time;
Basically, we call the vlistinitialize function to initialize each linked list structure. For details, please refer to< FreeRTOS -- (1) linked list>
The related linked list has been initialized. If the current pxCurrentTCB is not NULL, it must not be the first time to add a task. At this time, judge whether the scheduler has started working (the task can be created before or after the scheduler starts working);
pxCurrentTCB is a static global variable, which is used to point to the currently running task TCB
If the scheduler has not started working, compare whether the priority of the currently added task is higher than that of the previous task. If so, update pxCurrentTCB to the latest task;
Call prvAddTaskToReadyList to add the current TCB to the tail of the Ready linked list with the TCB priority as the index of the array;
Macro taskRECORD_READY_PRIORITY() is used to update the static global variable uxTopReadyPriority, which records the highest task priority in the ready state. This variable participates in the core code of FreeRTOS: ensure that the ready task with the highest priority gets the right to run the CPU. It is here to participate in how to find the highest priority ready tasks as soon as possible.
Call} taskEXIT_CRITICAL(); Exit the critical zone;
Judge whether the scheduler has run according to the xSchedulerRunning standard. If not, do nothing and wait for the scheduler to get up and schedule (because the task with the highest priority has been updated to pxCurrentTCB). If the scheduler is already running and the priority of the newly added task is higher than that of the current running task, Then call taskyield_ IF_ USING_ Preemption(), and then go to portYIELD to forcibly trigger a task switching, so that the task with the highest priority can be scheduled;
Generally speaking, the process of creating a task is as follows:
