Some of us have had trouble with the 20 timer limit in Agents.
Worse case, this limit can stop some critical recurring timers. If the limit is hit exactly when the critical timer reloads, it’s this one that doesn’t get reloaded and obviously, this remains true until the agent restarts. As an example we have a task scheduler that absolutely needs to run, but extremely sporadic did stop unexpectedly due to this.
Having a sort of guaranteed (ie OS controlled outsideof the normal timer pool) watchdog timer that creates a tick every second, minute or configurable, would allow checking those critical timers and if needed relaunch them.
Not sure about the use of HW timers on the STM, but this can be done easily by just allocating a free HW timer to it, or using the underlying impOSs scheduler to create it. Shouldn’t be too hard …
Exact timing isn’t critical, the certainty of occurence is.
I’ve had trouble with the timer limit in the past, but have largely dealt with it by writing my own timer layer. It helped me keep well under 20. I have critically scheduled things too, and they never fail. There is an undocumented call that can possibly shed some light on your situation, but I’m not on the electric imp team, and I don’t know if it’s available on all agents/versions.
@roger, you’re right, wasn’t thinking clearly
I’ve written my own timer layer as well and haven’t seen those issues anymore ever since.
I was just reflecting on something that I like a lot in bare metal embedded SW development vs using a VM to run code in which is the absolute certainty of HW interrupts occuring when you expect them without uncertainty (at least once you have the device properly setup and configured which in itself is already quite an effort for the more complex devices). Would be nice to have something closely similar in the squirrel environment for device /agent but as said, not an immediate critical need, just a nice to have
As a matter of fact, all our designs have a ‘partner’ uC programmed in C and running freeRTOS with tasks and interrupts for all the time critical real time stuff while relying on the Imp to do the fancy internet stuff; => perfect combination but I’ve been hoping to be able to replacing everything with just one imp one day…
