1266_ Implementation analysis of FreeRTOS scheduler startup code

All learning summary ： GreyZhang/g_FreeRTOS: learning notes about FreeRTOS. (github.com)

Take a look this time FreeRTOS What actions have been performed during the startup of .

This is CubeIDE The interface started by the kernel in the generated code , This is not FreeRTOS The original interface is the result of some encapsulation . Take a look at the implementation of this interface .

The meaning of this kind of encapsulation doesn't seem very big , Because there is no substantial change , Just add an invalid return value . However , The added invalid return value is discarded during the call . therefore , This can be called directly FreeRTOS The interface of .

In my project , It can be modified according to the above form , There is no essential difference in operation .

As long as it is FreeRTOS Configured to support static storage allocation , Support static task creation mode , Then a task scheduler will be created statically before the task scheduler is started idle task.Idle task During static creation , First, get the specified stored information 、TCB Object location and stack size , Then use this information to create a static task. Last , Make a judgment about creating idle task The success of .

Information acquisition interface for storing and defining objects , The implementation is relatively simple . But this involves a new complex data structure . Combine the above two parts of code , Create in a static way idle task In fact, it does not occupy FreeRTOS Of heap Spatial .

This data structure can be seen from the comments , In fact, it is just a process of storage allocation and alignment . however , This is not very readable , It is not recommended to visit the members . I guess this is the same as the standard TCB_t There is correspondence , I tested the size of both , It is found that the storage space occupied is actually the same .

I can see you , The two occupy the same storage space . Probably , In the rear OS There will be a certain transformation mapping relationship between the two in the processing of .

If static mode is not supported , Then, when the scheduler is started, it will be created in a dynamic way idle task.

This part of the code above , The effective part is only a little , That's it ： If the front idle task Created successfully , Next, disable interrupts . About interrupt disabled interfaces , An analysis has been done before , I don't want to talk about it here .

Next , Update part of OS After the basic information of , Enter the start of the scheduler . About the start of the scheduler , Further analysis will be made later . If idle task If the creation fails , Then it will stop directly at the position of the assertion .

Start the scheduler , First of all, I judged configMAX_SYSCALL_INTERRUPT_PRIORITY The rationality of setting . This cannot be 0, It has been tested before , In the current project, this value is 80. after , Read the contents of the first interrupt priority register and make a save backup . after , Write... To this register 0xFF Then read back , Therefore, judge the interrupt priority support of this kernel implementation . Last , According to the support information of the maximum priority, set the possible error of the previously configured maximum system call interrupt priority 1 Of bit Zero clearing .

here , Print again to confirm .

These functions are described in the notes , In fact, there should be a 3 Result . I added an intermediate quantity to see the real result .

This is the printed result , It can be seen that it is consistent with the previous analysis .

This is actually a verification of the calculated results and the results in the configuration . that , Where did the calculation come from , Where does the configuration information come from ？

This is the basis of the above calculation , From the kernel manual .

This is the basis for the above configuration , From the chip manual .

For the previously calculated group priority, the value is 3, What do you mean by that ？ Combined with notes , You can find the document above . Final , This group priority is used to fill in the above SCB_AIRCR Of the group priority bits of the register . And the filling effect is , All priorities are group priorities , There is no sub priority .

Combine this part of the document , It is understandable to set the priority to the lowest . But I don't understand why 3 The third register must be used , Here I try to switch to the first two , It is found that the behavior of the whole system is the same as before when the first one is used . When using the second , An exception occurred in the system .

What to do next , Is for the first interface above vPortSetupTimerInterrupt Call to . See the code here , Find out systick It has come into effect . This makes me feel a little confused , There was actually a timer used for tick To deal with , Also tested . That is, the second code above . This time I did a comparative test , Shielding this Tick Add interface , It is found that the callback function is still executing ,OS It can also operate normally . therefore , The functions realized here , Maybe it's just a counter or timer , however FreeRTOS The function of depends on SysTick To achieve .

here , Realized SysTick Interrupt handling . Here I can't help wondering , If you put this part of processing directly into the previous callback function OS Whether it can run ？ Tried to make a change , The timer processing when the scheduler starts is disabled , The relevant processing is put into the callback function of the timer , Test that the previous task runs normally . such ,vPortSetupTimerInterrupt In fact, it can be disabled . A more elegant approach would be to redefine , Override the function of this part . however , current CubeIDE The generated code does not handle this well .

Next , Started the first task 、 Context switching and an error check are performed .

such , The analysis of the framework started by the scheduler is finished . The content in the middle doesn't seem complicated , But there are many pieces of information . and , And the last few OS The relevant interfaces have not been substantially analyzed . Back , We still have to take time to see the specific implementation .