Response time to interrupts

In our application a digital accelerometer stores samples in it’s fifo buffer. When the number of samples reaches a threshold (512 samples) the interrupt pins of the accel goes high, then IMP responds using a callback function and it read 512 samples from the fifo. That interrupt is generated every 77ms and it takes IMP about 10ms to read the samples and store them somewhere else. This process is repeated until 8192 samples have been collected. In between the interrupts the IMP application is idling. I understand that the IMP interrupts are no true interrupts and that the interrupt callback are executed as soon as the imp is idling.

  • While IMP application is idling, will it handle to interrupt callbacks immediately?
  • Could ImpOS be doing stuff in the background causing the interrupt callback to be executed too late?
  • How many millis after an interrupt is an interrupt callback executed?
  • Can you guarantee a certain number of ms?

In your application, is wifi off? I imagine that this will have a big bearing on your worst case response time for your handler to be called.

There are no guarantees, but if wifi is off and Squirrel is otherwise idle, then a callback is typically entered within a few milliseconds of the interrupt being raised, on all imp types. If wifi is on (in particular, if the imp needs to re-connect “in the background”), the latency can be several seconds.

Blink-up can cause additional latency, especially on imp005, but only in the milliseconds or less – for utterly minimised latency, imp.enableblinkup(false).


Thanks for your comment Peter.