RobertLRead
commented
11 months ago This is indeed a limitation in the scheduler that could be addressed with a better algorithm, but in practice probably won't be.
BUT --- the assumption of a "simple loop" or "super loop" architecture is that onus of completing in a timely manner is placed on the task writer. We should not try to change that; if we need to, we need to move to an RTOS of some kind, which I personally believe is unmotivated at present.
I'm closing this as unactionable.
While reviewing and understanding how scheduling works in the system, it's become apparent that the file lib\core\scheduler.cpp is missing functionality to use priority as part of the decision making process when scheduling the next task.
Scheduling decisions reside in Task* Scheduler::getNextTaskToRun(TimeMs currentTime) {
the compile directive DEBUG_SCHEDULER can be used to evaluate task runtime
an external j-link debugger could also be used to examine stale tasks https://github.com/arduino/ArduinoCore-sam/issues/118
The danger posed by not being able to guarantee timing requirements is that we can't make the assumption that critical functions can't be blocked by enough tasks that have a low enough periodicity and so as part of the evaluation, we need to detect stale tasks, and characterize blocking tasks.
This is related to the irregular periodicity observed in PubInv/NASA-MCOG#82 It was also observed in the irregular triggering of LED lights on the SSR's, although the root cause of that is only speculative, where as the status led irregularities are demonstrative.