I tried to have 100 callbacks/second (50 Hz zero cross) to protect something at switch on/off.
The callback code is not long - after my scope measurements ends way below 10 mSec what is the callback period. I have a Server.log and show in every second once - a short status string (<50chars) is sent up to the imp service for debugging purpose every second.
What I've seen in reality: the code works well for a while than delays start to appear, sometimes the IMP recovers and works well again but in a hour or so it hangs. Green led stops flashing and only a hardware reboot fixes the issue.
My wild guess is callback congestion - too many callback events. Can be anything else?
Is there a way to have two kind of callbacks in the future: one based on event list and one based on flag (like interrupt is)? The flag version would avoid this kind of congestions ...
I wouldn't bother if in my case some of the callback events are lost - just be sure it does not hangs, anyway in my case if the delay is too big the callback is useless and even wrong since it's delayed too much from the real zero cross event.
Sounds like callback congestion, yes. Perhaps timer callbacks should get passed an extra argument which is the number of callbacks “missed” since the last one: 0 if the imp is keeping up, >0 if some congestion occurred. That ought to keep both the edge-triggered and level-triggered people happy?