 FreeRTales interrupts and connection to hardware. Now we need to focus on one of the main important aspects of FreeRTales implementation, its cooperation with hardware interrupts. Let's discuss about FreeRTales operating system interrupts. So PentSV interrupt. It is a software interrupt which is used to switch the context between one task to the other. As it is a software interrupt it can be triggered by the software from other interrupts or from the user code. In practice it is called usually by the SysTik which is the timer which is giving the trying to give the same amount of the time for each task which should be executed and then PentSV can be triggered as well by the kernel in case the task will finalize each job before this time and it can be triggered by kernel as well in case there is the new task with higher priority which currently executed one. So in this case PentSV is switching the context from lower priority task to the higher priority task and start executing the new task. As we see interrupt it is again the software interrupt which is called only once at the beginning of the application execution to start the scheduler. It is done within the port a start first task function. Our dimension SysTik timer and its interrupt it is used to give us the regular time slice for each task and is triggering its calling the PentSV interrupt to switch the context. Please remember that PentSV and SysTik has the lowest possible and weak priority level due to the fact that we don't need to have any negative interaction between those two and the other interrupts and because it is not good if operating system is blocking somehow or is delaying the hardware interrupts of the system. This is why PentSV and SysTik has the lowest possible interrupt level within the system. And the configuration. To configure three tasks within the application it is necessary to split all the interrupts into the three groups non-RTOS IRQs so non-RTOS interrupts which should consist of most important interrupts which cannot be interrupted or delayed by operating system and cannot execute any operating system code. RTOS interrupts so the interrupts which can be delayed or interrupted by the operating system and can execute operating system code and kernel interrupts which consist of two interrupts SysTik and PentSV responsible for context switch. Those should be the least important ones allowing rest of the hardware work like there is no operating system. To specify those three groups we need to specify two borders in fact the first one is quite flexible. CONFIX acts Cisco interrupt priority between first two and CONFIX kernel interrupt priority which is the lowest possible priority in the interrupt system specified by the core implementation. Both of them are stored within the three RTOS config.h file and can be modified from three RTOS config section of an STM32 cube mix or an STM32 cube IDE. Few words about the practical implementation within STM32 lines. Lowest NVIC interrupt priority within Cortex M0 and M0 plus based devices so for example STM32 F0, G0 or L0 is set to three while the lowest NVIC interrupt priority for Cortex M3, M4 and M7 devices like for example STM32 F1, F2, F3, F4, F7, H7 and low power like L1, L4 is set to 15. Let's have a look what is happening once we execute OS function from the interrupt procedure. So within three RTOS API there are dedicated functions to be executed within IRQ procedures. All of those functions has from ISR suffix in its name like X semaphore give from ISR what we can see on the screen. The only difference for the programmer is an additional argument which is the pointer to the variable which is used to indicate whether operation on the Q or semaphore within IRQ causes unblocking of the task with higher priority than currently executed. If this parameter is true there is a need of context switch by calling pentSV interrupt before the kernel will exit from the currently executed interrupt and here on the screen we can see the illustration of such a situation. We have two tasks task A green one and task D. Task D has a higher priority than A but it is currently in a blocked state as it is waiting for one of the semaphores. During execution of task A there is interrupt coming called IRQ1 which is releasing the semaphore which was requested by task D. So the kernel is informed about this situation and is calling the pentSV interrupt to switch the context between task A and task D. So in fact we are coming back from the interrupt IRQ1 to the interrupt pentSV which is switching the context from task A to task D. We are executing the code of task D which has the higher priority than task A and then at the end of this execution within the task code there is a function OS delay. Function OS delay means that task D is deciding to go into the blocked state for some certain time. It's some delay it's waiting for some time out. It is again causing the next call of pentSV interrupt because task D is not anymore in a ready state it is in a blocked state so we can come back to previously preempted previously removed task A. So pentSV is performing the switching of the context between task D to task A and task A can be executed again. Thank you for watching this video.