In tasks.c uxMissedTicks should probably saturate. In the case of long delays with the scheduler suspended the “feature” of uxMissedTicks is lost.
What you are saying is technically possible.
uxMissedTicks is used when the scheduler is suspended. Assuming a 100 ms tick and a 32 bit uxMissedTicks value. 0xFFFFFFFF x 100ms = 0x63ffffff9c ms, which is 13.6 years. If you suspend the scheduler for 13.6 years then you don’t really need a scheduler. I don’t think I will worry about that one.
True, but I use 1ms and 49 days is not inconceivable. I do not necessarily mean 2^32 saturation. There is probably some reasonable limit as to how many ticks to unroll when the scheduler is re-enabled. I would think the system would take quite some time to unroll 2^32. Thanks for your response.
I think 49 days is inconceivable if the functionality is used in the way it is intended. The scheduler should only ever be suspended for very short periods indeed. The value should never reach double digits in practical applications. You are also correct, unrolling the value takes time, and any remotely high value is going to cause problems for that reason.