A question for the firmware team @mdma
I’ve been experimenting with timers to call functions that act as system watchdogs / background processes. To my delight the timers keep running even if any of the following occur:
- the main loop hangs
- the photon/p1 enters listening mode
This means that if something goes into a strange state, and my application code doesn’t get called a watchdog function placed in a timer call can reboot the photon using System.reset() . That’s awesome! I’ve found the hard part of building a connected device around the photon is making the system stable. This is a good tool in that battle.
My first question for the devs is under what conditions will a running timer function stop being called?
Based on the documentation, I assume if a timer function blocks, the others won’t run.
If the system loop that runs under the application level code hangs does it have it’s own watchdog to reset the photon?
The second question is: was it intentional to keep the timer functions running in listening mode? If not, I’m going to suggest you keep that as a feature. It makes for a great watchdog in the user code and can keep background processes collecting data from sensors etc while in listening mode. I’ve had some photons go dark that went into listening mode unintentionally after the creds were cleared and wifi.connect() was called, I’m hoping to keep using the timer functions in this way to keep units in the field running stable.