 Hello, in this part I would like to demonstrate to you the situation where that the task is finishing its job earlier than specified time slice. So we will use again stm-42 cube IDE and we'll run our example on Nucleo L476-LG board, but you can reproduce it quite easily on any other stm-42 based board. So just not to let's say start everything from the beginning, I would use one of the existing projects which we have used before for tasks and I would start with a device configuration. So just for those of you who are starting with us right now, please start a new project with an stm-32 cube Mx or stm-32 cube IDE for selected stm-32 device. Please select within system and core and sys debug to trace asynchronous SW. It will be not available when Cortex M0 and M0 plus devices, but in this case we can just use the standard debug interface and use UART communication as a support for debug. Within Cortex M3, M4 and M7 devices, once we select this trace asynchronous SW we've got one additional pin. It is PB3, it is SW single wire output pin which can be used for single wire tracing. Additional point common for all stm-32 implementations when using FreeR2S is a time-based source change. Time-based source, when this says tab, means that this is the timer which is used to implement all the lines and timeouts within the library. So by default it is SysTick, but as we are using FreeR2S, which is using SysTick for the time slicing, we need to change this time-based for how to different timer. We can select from all of the existing ones, but the best is to select the timer which do not have any input nor output channels. So it could be timer 6 or timer 7. I select the timer 6. I will not use at the moment any other components and other peripherals nor pins. So I would just enable the FreeR2S. So I select FreeR2S. My interface is CMC version 2. I've got as well version 1 and disabled. So we are selecting version 2. And we do not need to modify anything within this config nor include parameters. So we can keep the default settings. Let's go to the task and kills. As I'm using the previous one of the previous exercises, I've got ready two tasks specified. You can add new ones using this add button and modify existing by double click on the name. Within this exercise we will have two tasks on the same priority or as priority normal. So I will double click and change this priority to normal without this tool. So two tasks have the same priority. The entry functions will have task 1, start task 1 and for task 2 will have start task 2. There would be no other component within this perspective. So I would generate the code using this button. Okay and within our code we can see main.cfile within the private variables, the definition of both tasks and its handlers. Then within main function after the hardware initialization we can see the declaration and creation of new those two tasks. Then the kernel is started and we are executing the code from both tasks. So within this exercise I would like to demonstrate to you how task can finish its job a bit earlier. So I would keep only this task action code and I would remove all of the other components which are not necessary here. There would be no initialization values only the task actions. So let's assume that we've got the situation where our task 1 will have only small portion of data to be to be done and it's the time slice defined for it is much too much. So we need to finish earlier and give the time space to the other tasks. How to do it? We've got a dedicated function which is os thread yield. This mechanism is called yielding and this function is calling in fact a similar function with an freeRTOS API which is sending our task from run state to ready state and this is forcing scheduler to switch the context using pentSV interrupt to next task the same priority from the ready list. If there would be no other let's say task with from the ready list that scheduler will select again the same task task 1. So please be careful when using this function with the task which has higher priority than the others because scheduler will select automatically the same task once again. But in our case both tasks have the same priority it is os priority normal so this function should work without any problem. This function do not accept any argument so this is just this is in fact calling pentSV interrupt to switch the context for the next task which is in the queue. So this is our task 1 function and for task 2 we will perform only this operation without any yielding so task 2 will use its complete time space for the execution. Let's try to compile it and check the final result. It will be quite difficult to check the difference in fact because we are operating on 4 MHz clock on the default one it will be quite fast but we will see. A compilation demonstrates no warnings so we can start with the debug session my board is already connected so I press this debug button then I need to turn on this SWD ITM data console just to show you once again how to find it I'm using this quick access SWV and this SWD ITM data console this is the one I'm using. Once you select it you need to configure it selecting channel 0 as a ITM port ITM means instrumentation trace macrosal so this is the trace we are using only one wire over SWO line this is PB3 pin. Then to start the tracing we need to start it by pressing this button and we can run the application. So we can see I would pause it for a while and let's have a look how it is working. I would scroll for the beginning so at the beginning we can see that task 2 is executing many many many times and then from time to time we can see task 1. The explanation for this is the following let me come back to main.c file and within our code we have specified the time slice for each task for one millisecond and within this one millisecond the task is executing the code from this endless loop so in case of task 2 it will be sending these two over ITM interface one by one as fast as possible within this one millisecond this is why we can see a lot of let's say sign of life from task 2 and as task 1 is sending only once its data and then it is going immediately to ready state we can see from time to time only the sign of life from task 1 so the effect is visible but please remember that yield function should be used among the tasks with the same priority if you would like to block somehow or to finish earlier of let's say the job of the task with higher priority better use OSD like instead which would put your higher priority task to the block state okay we can terminate or stop the debug session and continue with the next topic thank you for watching this video