 Now, I will present main features of FreeRTOS, some basic facts about the FreeRTOS. So it is a market-leading RTOS, so real-time operating system created by real-time engineers LTD company some time ago. It is professionally developed with strict quality management and as it is a free software, it has as well some commercial versions available called OpenRTOS and SaveRTOS. The complete documentation of this system is available on the dedicated web page www.freeRTOS.org. The free support is as well available through forum moderated by RTOS author Mr. Richard Barry. FreeRTOS license details are available on dedicated web page which you can see below. In the STM32Cube firmware solution FreeRTOS is used as a real-time operating system through the generic CMCOS wrapping layer provided by ARM. Examples and applications using the FreeRTOS can be directly ported to any other RTOS without modifying the high-level APIs. Only the CMCOS wrapper has to be changed in this case. Main features of FreeRTOS. So it has preemptive or cooperative real-time kernel. We can specify which option we will select either preemptive or cooperative. It is done within FreeRTOS config.h file. Then it has tinny memory footprint, so less than 10 kilobytes of flash memory, and it's easy scalable. So we can decide which components are needed for our application, which are not, and in this case we can scale our application to our needs. It includes a T-class mode for low-power applications. So we can work with FreeRTOS even using stop modes. And it has several synchronization and inter-task communication methods, like queues, binary and counting semaphores, mutexes, group events or flags. It has as well implemented the software timers for task scheduling and execution trace functionality, which we can enable as well during the development phase. And on top of this we've got a possibility to use any one of the three APIs, either native one FreeRTOS API or CMC's OS API, which has been developed by ARM. What are the resources used by the FreeRTOS with an STM32 devices? Within the core it is using the system timer called SysTick to generate the time slice. Then two stack pointers, main stack pointer and process stack pointer. Process stack pointer is used by the tasks or threads. And the main stack pointer is used by the kernel of the operating system. Then it is using free interrupt vectors. As we see, system service call, it is a software interrupt and it is used only once to start the operating system after the reset. PentSV, so-called panded system call, it is used to switch the context, to switch from one task to the other. It is again the software interrupt. And the SysTick. And from SysTick it is used to generate the time slice moments, which are telling us where we need to switch the context. Then within the memory resources, FreeRTOS is using from 6 to 10 kilobytes, depending on the component list we are using. And more or less half of kilobyte plus stack of each component. So the tasks, semaphores, queues, motexes, software timers, all of those we need to add to this memory usage. System service call SVC, it is called as well the supervisor call. It is an instruction and an exception of an STM32. Once the SVC instruction is executed, SVC IRQ is triggered immediately, unless there is a higher priority IRQ active. SVC contains an 8-bit intermediate value, which could help to determine which operating system service is requested. In FreeRTOS port, SVC is used to start the operating system after the reset, and then it is not used anymore. Important point is to not use SVC inside NMI, so non-maskable interrupt, nor hard-fought handler. And that system call Bend SV. Bend SV is a priority programmable exception triggered by software, it can be done by right to the register ICSR on this address, and it is not precise in contrary to previously described SVC. So after setting this bending bead, CPU can execute a number of instructions before the execution of Bend SV will start. Usually it is used like a subroutine called by the system timer in operating systems to switch the context. System Timer. It is necessary to trigger a context switching in regular time slots. In Cortex-M architecture, 24-bit down-counting cystic is used for this purpose, but it can be changed, for example in low-power applications. System Timer is a triggering Bend SV software interrupt to perform a context switch. In case we are using hardware abstraction layer library, it is strongly recommended to change its time-based timer, which is used to generate the timeouts and delays, from cystic to any other timer available in the system, for example, Timer 6. Possible issue if you will keep a cystic for free RTOS and HAL library could be improper timing management within the system. And it is due to the fact that within free RTOS, cystic and Bend SV interrupts are configured within lowest possible priority, so all operating system functions will freeze the cystic interrupt every time when there would be a change within operating system components. In fact, it is done in majority of the functions. In such a case, all planned delays timeouts within HAL libraries will be delayed. Fortunately, if you are generating the code using STM32CubeMix or STM32Cube IDE, we will receive a warning message prior code generation about this. Here we can see the complete list of files which can be found within free RTOS implementation for STM32. Selected files are the key ones and must be present in all free RTOS-based applications. We will focus on them on next slide. Let's briefly describe less important ones. See Routine. Those files contains API code for core routines, which are used instead of tasks in 8 and 16-bit architectures. Those are not used within STM32 complementation. Streambuffer contains API code for streambuffer implementation within free RTOS. Let's continue with free RTOS files analysis. Blue ones are the key and basic ones for free RTOS and must be present in all OS-based applications. Those are list.c and list.h, so source code of the scheduler operations, task.c, task.h, source code of the functions related to tasks, free RTOS.h and free RTOS.config.h contains free RTOS configuration. All of above files are MCU agnostic. A part of those we need to connect somehow free RTOS with hardware platform of STM32. For this we have heap underscore x.c files, which contain memory management functions to allocate entry-release memory for each operating system component, port.c, port macro.h files, which contain the implementation of SVC, pentSV and C-Stick interact routines and complete code to perform the context switch with an STM32 platform. The rest of the files have the following meaning, q.c, q.h, semaphore.h files. Those are native free RTOS ones and contain code for qs, semaphores and mutexes. Bit less important but and not always used in the system are event underscore groups .c, event underscore groups.h to perform effective task-to-task communication, which is much faster in determining the semaphores and timers.c, timers.h, so free RTOS API for software timers services. What is not mentioned is the CMC's OS layer, which we will focus within this session. It consists of few files, CMC's underscore OS.c and CMC's underscore OS.h files, which contains all the code and the port between CMC's OS and free RTOS APIs. Thank you for watching this video.