In the previous article, “FreeRTOS Porting – Single-Core ARM CM7”, we briefly introduced the process of porting FreeRTOS based on the ARM CM7 core. The overall process is quite simple, summarized as follows:“Download the kernel source and integrated examples from the official website -> Copy the kernel source -> Copy the port files for the target chip’s core (with the same compiler) -> Create tasks -> Run.”However, there are several questions here:1. Why can this operation be performed?2. What to do if the official website does not provide integrated examples?3. What role does the port of the integrated example play?The first question is easy to answer. The reason is that FreeRTOS has made relevant adaptations for mainstream chips on the market (covering most cores). The target chip core ARM CM7 mentioned in the previous article is precisely covered. Furthermore, FreeRTOS is related to the chip core rather than peripherals. Lastly, the ARM CM7 core is authorized by ARM to different chip manufacturers for chip integration, and the manufacturers themselves do not make design changes to the ARM CM7 core, mainly differing in functional configurations. For example, some chip manufacturers have 16 interrupt priority levels, while others have 32. Therefore, if the target chip model is already supported by FreeRTOS, or if the target chip uses an ARM core that is supported by FreeRTOS, the process can be followed accordingly. Of course, there may be slight configurations that need to be adjusted in FreeRTOSConfig.h.The second question is a bit more complicated, but you can refer to the examples provided on the FreeRTOS official website to create the corresponding port for the target chip. The saying “to follow the example” applies here. In such cases, chip manufacturers generally prepare corresponding examples; for instance, NXP or Infineon will adapt FreeRTOS for SMP mode for certain multi-core chips, and users can download them from the relevant official websites. Ordinary developers are not recommended to be the first to try this, as it involves a certain understanding of the target chip core, which non-original factory personnel may not have. If you really want to challenge yourself, you can seek help from the original manufacturer.The third question is more meaningful for developers to understand. The principles of the OS are relatively easy to grasp, simply put, it is about “supporting task creation, starting task execution, and correct task scheduling.”“Supporting task creation” means that the OS provides some APIs for creating tasks, which are hardware-independent and not related to this issue. However, at the initial moment of task creation, it involves initializing the task stack, which requires the port to provide the pxPortInitialiseStack() interface support.“Starting task execution” means that the OS provides an API, and after calling this API, the first task will be triggered to execute with the highest priority. FreeRTOS corresponds to xPortStartScheduler() and vPortStartFirstTask(), and these implementations involve kernel-related operations, thus requiring the port to provide them. (For ARM cores, it also involves vPortSVCHandler()).“Correct task scheduling” first requires that the scheduling process is not disrupted. To meet this requirement, the OS needs to provide APIs for entering/exiting critical sections: vPortEnterCritical() and vPortExitCritical().Secondly, scheduling can be event-triggered, for example, by calling delay-related interfaces to trigger task scheduling. FreeRTOS adopts a scheme using the PendSV interrupt, corresponding to the port providing xPortPendSVHandler().Finally, scheduling can be periodically triggered, such as triggering task scheduling once every 100us. FreeRTOS uses a scheme that triggers the PendSV interrupt using the Systick interrupt, corresponding to the port providing xPortSysTickHandler() and vPortSetupTimerInterrupt().These are some of the questions and thoughts I had during the porting process. Interested readers can further contact me for more in-depth discussions.