I have 10 functions that run on timers. 128, 64, 2 and 1 ms delays between them.
One function has a worst-possible case that it needs to reset a device which in theory could take 2 miliseconds.
This would block potentially all of the timers, but definitely the 2 and 1 ms auto-reload entries. Those won’t run.
What happens to starved timers? Will those that didn’t run have new entries on the queue? If TaskA didn’t run and has a 1ms rate, could I have 2-3x TaskA entries on my timer queue and will then run the time it missed, plus all the other times it missed? OR, will only one entry of TaskA be on the queue, and it will not be re-added until it runs?
Auto-reload timers always “catch up” if they have been starved. If you starve a 1-ms auto-reload timer for 5ms, it will get called five times back to back as soon as the timer task can get to it.
However, more importantly, you should probably change your design so your timer callbacks don’t do anything that takes very long. That way your own application’s task priorities determine the outcome when multiple timers expire near the same time. Your timer callbacks should interact with some synchronization object provided by FreeRTOS (eg, notify a task or add something to a queue) and then return. This way you don’t let a long timer callback function hold up other timers.