How to find out the time between two interrupts' execution?

Hello,

to capture changes of a pin's voltage, I decided to use an interrupt.

However, for me, it is very important to know how much time was between this interrupt triggered, and the one before! How to do this? I was told, that "micros()" didn't work.

An alternative could be checking in the loop digitalRead() status of a pin and save it in a variable. Always check digitalRead with the variable's value from the loop's execution before and compare them. If it changed (that means from 0->1 or from 1->0), then do something. Isn't this the same as interrupt? Why not?

Thank you very much ~

How to do this? I was told, that "micros()" didn't work.

By whom? The micros() function works fine in an interrupt handler. The clock behind it doesn't advance, so you can't time how long an interrupt handler takes, but you can record the time that the handler was invoked.

karlok: Hello,

to capture changes of a pin's voltage, I decided to use an interrupt.

However, for me, it is very important to know how much time was between this interrupt triggered, and the one before! How to do this? I was told, that "micros()" didn't work.

micros() should work.

OTOH if you absolutely must have precise timing you should probably use a hardware timer. Start a hardware timer going in the first interrupt then read it in the next one. Programming timers is quite easy. Grab a datasheet and look for a 16 bit timer on your chip.

How to do this?

Simulation or emulation is quite good with this.

The usual approach is to flip a led at the start of the two isrs. By observing the led, you see how much time may have elapsed.

Having a scope / logic analyzer would be helpful.

Hello,
thank you for the answers!

To measure the time between two interrupts, I will calculate “micros()-last_micros” wherby “last_micros” is a variable, that is set at the end of the interrupt function.

However, is this the same?!

An alternative could be checking in the loop digitalRead() status of a pin and save it in a variable.
Always compare digitalRead with the variable’s value from the loop’s execution before. If it is different (that means change from 0->1 or from 1->0), then do something.

However, is this the same?!

Not quite. That approach will let you find out, in loop() that the interrupt occurred and record when you noticed that the interrupt occurred. However the time you noticed that the interrupt occurred and the time it actually occurred can be quite different. It depends on which time it is you are interested in.

Ok, that makes sense. However, I think this difference between the time when I noticed that the interrupt occurred and it actuallay occured, is VERY small. The Arduino Uno's clock speed is 16MHz and the durations I want to measure are in a range of about 1ms, the loop should be done in about 50µs max. That means there shouldnt be a problem. It's good to know the difference, though.

PaulS:

How to do this? I was told, that "micros()" didn't work.

By whom? The micros() function works fine in an interrupt handler. The clock behind it doesn't advance, so you can't time how long an interrupt handler takes, but you can record the time that the handler was invoked.

You musn't call delay() in an interrupt routine, but micros(), millis(), delayMicroseconds() are all fine (but don't do long delays with delayMicroseconds...). delay() can't be used if interrupts are disabled because it busy-waits for certain variables to be updated by the timer0 interrupt - the system will hang.

The clock behind micros() does advance during your interrupt handler's running since it looks at the timer0 count register, but only for a limited amount (about 1ms). Even if it didn't advance you could compare values between successive interrupts.

Any interrupt handler that runs for > 1ms with interrupts disabled will break the time handling anyway... Another reason not to call delay().

However, I think this difference between the time when I noticed that the interrupt occurred and it actuallay occured, is VERY small.

Maybe. Maybe not. Serial.print() can be very slow. Same for pulseIn(), delay(), and a number of other functions. If you don't use any slow functions, then I fail to see the need for interrupts. If you do, then there can be a significant interval between when the ISR does something (sets a flag) and when some code in loop() detect that that something happened.