“Pat” the hardware watchdog so it doesn’t bark and reset the system.
This sounds like a bad idea to me, since the idle task’s never actually guaranteed to run (in particular, it never runs if there’s always another schedulable task). How would this be dealt with? Force scheduling of the idle task periodically? Have the watchdog check for CPU activity rather than a particular signal?
Yup. You’re dead right. Insufficient coffee, lobsterer halted.
Even though the CPU is in a low power state, the timers are still ticking downward and even if “no useful work” is scheduled, an alarm will have been set to go off, and the handler will pat the dog.
ie. It is an “idle task” activity in the sense it continues in to happen even if the user isn’t touching or looking at or using the device.
On embedded systems the idle task often has additional responsibilities…
“Pat” the hardware watchdog so it doesn’t bark and reset the system.This sounds like a bad idea to me, since the idle task’s never actually guaranteed to run (in particular, it never runs if there’s always another schedulable task). How would this be dealt with? Force scheduling of the idle task periodically? Have the watchdog check for CPU activity rather than a particular signal?
Yup. You’re dead right. Insufficient coffee, lobsterer halted.
Even though the CPU is in a low power state, the timers are still ticking downward and even if “no useful work” is scheduled, an alarm will have been set to go off, and the handler will pat the dog.
ie. It is an “idle task” activity in the sense it continues in to happen even if the user isn’t touching or looking at or using the device.