 What the FreeRTOS requires from you when you implement it on a microcontroller? It's not much, but it's still enough to be able to do all the tasks that you expect from the FreeRTOS. So when you implement the FreeRTOS, it will allocate the system timer. It will use the system timer as a periodic time base. Typically, you can set up your own frequency of the time base, but the shortest time you could use for the time base is defined as 1 millisecond. It doesn't allow you to go faster, but you can define 2, 5, 10 milliseconds, so the granularity is on you, but the resolution is 1 millisecond. So a system timer sys-tick is hooked to sys-tick interrupt. So you need to hook or let the RTOS take the sys-tick interrupt. Further, it gets access to the stack pointers, MSP, so main stack pointer, and program stack pointer. The MSP is used for the interrupts and the scheduler, and it's used during the task switch. However, the PSP program stack pointer is used for the tasks to point to their local stacks, which means if you run your task, it uses its own dedicated pointer to the stack, and it moves with that. However, when you jump into the scheduler, the scheduler uses its own separate stack pointed by the main stack pointer. So they are independent, they don't cross each other, and that has got a safety benefit. Further, it takes another interrupt vectors. It takes the system service call to get the priority when you call different API functions. So if you want something from the RTOS, you have to switch from the thread mode to the interrupt mode so that all RTOS functions occur in the interrupt. This has one benefit because the free RTOS runs in a dual stack model where it has separated privileges for the tasks and for the kernel. And by calling the SVC function, you are giving it all the privileges for the kernel, and the free RTOS takes care about all the functionality with high privilege. That's why all the functions are running in the interrupts. Further, it has got a hook on the pandable system service call, which is an interrupt used for switching the context. This is an asynchronous interrupt typically with a low priority that is switched on by setting a flag in the NVIC controller register. So when you want to do a context switch, you set this flag, it will launch the interrupt and this will do the context switch. The advantage is that you can trigger the context switch, for example, at the end of the standard interrupt routines. So if you have an interrupt from UART where you send this new data to the queue, you typically call or put the data in the queue in this interrupt, and then it will trigger the pandable system call, so that when the UART interrupt finishes, the pandable system call will be launched just afterwards. So it's very effective, uses tail chaining and it allows you to do more stuff and process the context switch just once at the end of the interrupts. And it takes the sys-tick. The flash memory it needs for the kernel depends on how many features you want to implement. You can strip all of them away, so you can remove mutexes, counting semaphores, timers. You can decide which memory management you will use and this all will add to the complexity and size of the kernel. So if you want a really minimal one, you will just probably use queues and mutexes and nothing more. But if you want a full featured freeRTOS kernel, it will be a little bit bigger. In terms of RAM, it will allocate approximately half kilobyte plus everything you give to the heap. Using the system service call, it's launched by an instruction where the instruction holds the number of the request. Such mechanism is typically used in the RTX from Kyle. FreeRTOS doesn't use it that much, so we can probably skip it. The pandit or pandable system call interrupt is the one that takes care about the context switch and it can be launched by this line of code. One thing the pandable system call doesn't execute immediately, but only when all higher priority interrupts are finished. The system service call instruction is executed immediately while pandable system call is pandable, so it means it can wait. Speaking about the system timer, it's always allocated by the FreeRTOS. When you operate with the STM32 and with the hardware abstraction layer, the hardware abstraction layer needs as well a time base. When you don't use the FreeRTOS, SysTick is used as the time base. However, if you activate a FreeRTOS, the Cubemix will warn you that you need to use a different time base for the hull. It has a very good meaning because if you combine several different tasks and you would wait for the same interrupt from the SysTick to elapse a timeout and to finish the context switch, you would create a code lock and you wouldn't be able to recover. So having the SysTick used for both hull time base and the FreeRTOS time base is quite a dangerous thing. So we don't recommend it and that's why we offer another timer as a time base for the hull. So please use it. Typically, if you choose in the SysSection of the Cubemix the time base for the hull as a timer 6 or 7, which don't have much other usage, you do the best thing. Because timers 6 and 7 are very small in implementation and can give you only a periodic interrupt, apart from the synchronization of the ducts. Normally, when you have a Cubemix open and you click on the FreeRTOS, it gives you an option of chapter Sys, like system, that you can choose a time base from a list of timers. So it can be a SysTick, it's not recommended, but it can be as well any other timer. If you choose the timer then it will be grayed out so you can't use it for any other purpose. But it will be then automatically initialized by the init code and it will be used as a time base for hull.