When timer interrupt is received, if there is already some ISR being executed, doesn't it delay (elongate) the time interval measured? If yes, how is it handled? For the sake of precise time measurements.

  • $\begingroup$ yes, there would be a time delay ... how the situation is handled is up to you $\endgroup$ – jsotola Sep 11 '19 at 16:27

No. The actual time is calculated from counter registers that automatically increment. The timer interrupt will be delayed, and things the timer interrupt is triggering will be delayed. This is called jitter. But the measurement of the interval will not change in accuracy.

Counters roll over to zero automatically at the hardware level. So there are never lost counts. Counters are large enough that they either don't roll over or that the software has lots of time to count the number of roll overs.

The error in time measurement one sees in digital devices is called drift and is due to the oscillator driving the time counter at a non-exact rate.

All microcontrollers have oscillator driven counters for keeping time. Some microcontrollers and most processors have a realtime clock subsystem. Real-time clocks have the same counter at their core and some convenience hardware for handling time and date.

The only difference between counters and real-time clocks is that attached to real-time clocks there is usually an oscillator that has a frequency that is a power of two factor of 1 second, and sometimes that oscillator with have less drift (more accuracy).

One way to think of it is how you behave with a wrist watch. The watch is always keeping time, with some error from true time (drift). If you get an alarm from the watch, start an action, get distracted, and then complete the action, there is error in the timing of your action, but the watch continues to measure time accurately.

| improve this answer | |
  • $\begingroup$ If timer overflow occurs and interrupt for resetting it is delayed how the time measurement can be precise? $\endgroup$ – Pasha Sep 12 '19 at 19:56
  • $\begingroup$ Updated the answer to address your question. $\endgroup$ – hauptmech Sep 13 '19 at 21:52
  • $\begingroup$ I now understand what you mean. But if this interrupt is for keeping track of counter cycles then measured time is not correct, right? $\endgroup$ – Pasha Sep 14 '19 at 21:33
  • $\begingroup$ Measured time is always correct within the error of oscillator drift. Added an example to the answer. $\endgroup$ – hauptmech Sep 15 '19 at 20:33
  • $\begingroup$ I think what you are saying is correct when the time you want to measure is less than one timer cycle. Now assume it is larger than one timer cycle and to keep count of cycles you define external variable "c". You have to increment c each time timer overflow occurs. But if interrupt service is busy, then timer interrupts accumulate, and I think you miss the number of cycles and hence the time measure. $\endgroup$ – Pasha Sep 18 '19 at 2:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.