Software timers priority


I am currently using the software timers to schedule some task containers ( callback function) to execute every 1ms, 5ms, 10ms etc…

When monitoring my tasks with an oscilloscope, I figured that the 20ms task ( green ) is delaying the 1ms task ( purple ).

How can I force the scheduler to execute the 1ms timer first , then the 20ms timer ?

Thank you for your reply,


Give the 1 ms task a higher priority than the 20m task. If this work is being done inside the timer callback itself, no, there is no priority among them, which is one reason timer callback should be very short actions, perhaps signaling a task for that longer action.

Thank you for your reply.

There is no tasks in the callback functions, just some standard code to execute.

I dont’t know if i’m using the right tools for what i’m trying to achieve. Let me explain :
On core 0 I want all the task that are not time critical and can intefere with each other (ota, wifi, web server, led etc…) and on core1 my main function ( Phase_Mng() ) running as a Task wich is executing the device life cycle and are time critical.

On core1, there is only one task running (it’s intended) . I disabled watchdog on this core to avoid starving errors from IDLE and have full priority for my timers. In this core I must have the total control of what is executing at what time . Then I initialise 5 timers in this task and start them (1ms, 5ms, 10ms, 20,s and 50ms). I execute some fast functions in every timer callback ( it should not exceed 1ms when multpiles task are running after 1 tick).

Is this the right way to execute my periodic functions ? If not, how can I do it with tasks ( vTaskDelayUntil and priority ) ?

If this is the right way, how can I prioritize the 1ms timer ?

Thank your for your time,


First, I assume from that basis of the question, I am going to assume that you feel your 1ms timer isn’t meeting your design requirements (or at least your design preferences).

The key fact to remember is that timer callback do not have any priority relationship with each other, and therefore, the sum of the code executed within the call-backs needs to be short enough to meet your requirement. This often means that these need to be very short.

It appears that the code in the 20ms timer needs to be done at a lower priority than the timer task and the 1 ms timer, so the 1ms timer operations can get scheduled and done faster, which means it can’t be done in the timer callback function, but that callback needs to signal a task to execute the 20ms timer code, and then return back to the system timer task. This will allow the 1ms timer to get activated rapidly when its timer fires.

My general rule is that NO timer callback should do anything that might need any significant time, but if I need to do something like that, it belongs in a task. If the only purpose of that timer callback is to activate a task periodically, you dont need the timer, just have the task wait with vTaskDelayUntil to activate itself periodically. (The periodic timer callback IS useful if I don’t need a task, but just have something quick to do at that rate).

Note, your core1 does have multiple tasks running in it, as it sounds like it has the timer/service task running, and it sounds like it would make sense for some of these timer based tasks to run in it also, and you think a bit about what you real requirements are and set the priorities to meet these.

Depending on what your tasks are actually doing and how they interact with each other and the kernel, other design choices would be to perform the 1ms operation in an interrupt service routine and the 20ms operation in a task that uses vTaskDelayUntil() to achieve the correct period.

Thank you for both of your answers . That was really usefull.

Is it smart to fire a TaskNotification in a 1ms Timer callback function ? Or should I use the hw clocks to fire the task notification ?

It would be great for me if i can implement a tick counter and execute different tasks at different ticks.

For example :

a TaskNotification is firing every 1ms (1 tick).

At every tick a counter is incrementing and i use this counter for the Task notification index.

Thats way : @Tick1 , counter = 1 , Task1 is executing / @Tick2, counter = 2 , Task2 is executing etc… and @FinalTick , counter = 0 , Final task is executing.

Thank your for your time, i’m quite new to this stuff and struggle a bit with RTOS.

If you just want to fire a set of task notifications on every tick, it might be simpler to use the TickHook function instead of a timer. This function will run inside the tick ISR, and thus would use the FromISR versions of the notification, but also drops a lot of the overhead for switching to the timer task and running the call back.

Timer Callbacks are better for slower operations.

One thing that I would suggest, is make sure you started with a good foundation description based on requirements, not implementation ideas.

What things need to be done when (Don’t think of tasks yet).
What things are time critical, and how critical, and what things aren’t.
What things depend on what other things.
What things do we need to wait for or store up (these become the Queues, Semaphores and the like)
Then you can look at partitioning into Tasks and assigning priorites.

There are multiple ways to do many things, and even at times multiple reasonable ways to do things, and until you see a problem, it may not be worth worrying about finding ‘the best’ method.

Your original idea of doing these operations in the timer isn’t wrong at the simplest level, it just didn’t meet your requirements of priorities of actions, and if you had fully gone through this sort of design process, you should have seen that you wanted the 1ms period operation to have priority over the slower operation, and the fact that you couldn’t assign priority to the timer callbacks could have been a hint to the issue.

This goes back to your question of which is the better way to fire the notifications. There are a number of ways to do it, the timer task method ‘works’ but has more overhead. The tick callback has less overhead, but adds some new API to learn. To use other hardware timers perhaps gives you more flexibility, but ands more systems you need to understand. Tradeoffs. If everything is, and will be, multiples of your timer. tick, then I would use the tick hook, as it isn’t that complicated to use, as long as you understand how to do code within an ISR.

1 Like