 Now I have got another topic for you and that's about software timers These are by default switched off when you set up a cube MX The software timers are disabled. So if you want to use them, you have to enable them and At the same time you have to set up the stack for the software timer task and the length of the queue For the timers timer events the software timers work. So that you can register an event with a callback function and a delay and The timer will get this It will calculate the position of this event in a list and it will put it in the waiting list and As you get periodically awakened by a time base it decrements the time of all the tasks that are registered and When such timeout drops to zero the callback is called and is removed from the list So you have got a one off and that you can call a function in a pre-programmed time However, you can as well Mark at least in the native API that such event will be periodical So then it will not be removed, but rescheduled with the same delay and It will continue periodically Of course, you can stop the callback the event and you can restart it So it's very useful if you need some longer term periodic behavior. You can see that There are two types of the timer events Or timer types the first one periodic where you register it and you start this event with the OS timer start and The software timer task takes care about the timing and when the right time comes It calls the registered callback the function that you create and It reschedules The call to the same task again So you can see it's automatically called periodically It can be for example a refresh of a display. It can be check of your keyboard of the buttons It can be a periodical communication Pink to another board another component and so on another thing you can as well use this task for For example a watchdog Let's imagine that You have a watchdog in your application activated in a cuba mix and I highly recommend to use watchdogs and Now you need to Make sure that your application is alive and that all components are running So what you can do you can set up a periodical event To refresh the watchdog However, it has got one drawback because the tasks which happens in an interrupt and Some other tasks can be deadlocked while this one is perfectly okay There is a question whether you should refresh the watchdog conditionally or unconditionally So what would you choose? Conditional you can define a frequency of each task and Each task can send an event one bit for example to the signal of the timer task and When you get to the callback routine it can read the signals Or for example a stemma force or any other state and If it doesn't have a ping of life from all the guarded tasks, it will simply avoid Refreshing the watchdog and it will let you reset the microcontroller So such way you can as well guard the micro Against the deadlocks and against some unwanted behavior or freezing of some of the tasks So each of each task has to periodically send a signal and when this callback collects all of them and You can see if all tasks have sent the timeout the proper signal then you refresh the watchdog. Otherwise Restart and start from the beginning The second mode of the software timer is a one pulse One pulse like you can hear simply starts the counter and after a given delay calls the callback However, it removes the callback from the timer task So it's no more cold. Of course, you can restart it by software Automatically, it is called just once to enable the timers. You have to do it in a cuba mix or in the free artist config By enabling this macro config use timers when this is done the X timer create timer task function is called in the retask start scheduler and It instantiates the timer task responsible for working with the timer list and calling the callbacks Additionally, you can define the task priority for the timer task and the stack depth This is very important to guarantee that all the callback functions have enough space on the stack and They can run correctly Additionally, the timer task creates a message queue where it holds the timer events So all the pre-programmed pre-scheduled events are held in the message queue And the finally the queue length can be as well defined in the setup of the free artist Speaking about the configuration here. You can see all these config parameters and How can they be set up? Now let's look at the API The timer can be created and when it's created it gives you a timer ID It is created with a definition So with a callback and a timeout then it is created with the type whether it's repeated or one time and When it starts the callback it can as well pass it an argument So you can parameterize how you call the callbacks then the timer has to be started and You have to give a timeout the delay in milliseconds after which it will be called So once you start it depending on the type it starts Calling it periodically with a given timeout or it starts just once and removes from scheduling Additionally, you can stop any selected timer if you don't need it anymore and Then you can as well restart it if you want software timers as I said can be very useful in Programming different actions in time if you want to test it we can set up the lab So you can come to kube mix and we can enable the timers so first thing Open the configuration of the free art os Scroll down to software timer definitions and Enable the software timers After you enabled the software timers jump to the timers and semaphores tap in the artos configuration and add one software timer callback You can set it up as OS timer periodic So that it gets called periodically Okay, and Right now when you generate again the code you should see that one timer was added to your project and There was a swell created a callback So we can set up or we can put in the callback a Function that gets called after a specific timeout Here there is one critical thing the callback should not be blocking So the callback must be quick and return very important thing is that If you put any blocking function inside That can create trouble and delay in other callbacks because all other callbacks come in the same context in the same task So if you put a blocking function, you are blocking the whole timer task What would you do if you need to start some action and Then wait for something if you for example have After the OS delay timer elapsed How would you do this effectively you create a specific task you can for example wait for a semaphore and When this Callback releases the semaphore The task can wake up can print and use OS delay for Waiting and then another output or communication and One more important thing. We have created the timer. We have created the callback But we need to start it so please choose one of the tasks that are alive in your application and Start the timer once with the OS timer start handle of your timer and a period of your choice and This way you will be able to Start the timer we set it up as a periodic So periodically in this case every one second you should get this function called and You should see either the output or if you place a breakpoint. It should be hit periodically