How can I handle micros() double rollover?

Question

I know that I can handle a single rollover with subtraction:

if (micros() - lastTime > period) {
 lastTime = micros();
 ...
}

But how it can be handled if this is not true or it is not checked for more than 70 minutes (without using uint64_t)?

• Nick Gammon: What is the objection to using millis() if you are timing rather long periods?
• Vasil Kalchev: I'm using my implementation of micros() and I don't want to implement millis() because it makes the ISR bigger. Also the precision.
• Nick Gammon: So just to be clear, this is your version of micros you are asking us about? How about posting the code to it?
• Vasil Kalchev: It's the same as Arduino's version except that in ISR(TIMER0_OVF_vect) there is a single variable increment. The code needs to run with as little interruptions as possible and I want to be able to run something with irregular long intervals.
• Nick Gammon: It's the same as the Arduino version, except it's completely different, is that it? I gather this is top-secret code.

Answer 1

If you want to measure times longer than 70 minutes with micros(), you will have to use uint64_t, and there is nothing wrong with that.

The code needs to run with as little interruptions as possible [...]

You don't need to do the 64-bit arithmetic within the ISR. You could very well implement an interrupt-driven 32-bit version, and then extend it to 64 bits in non-interrupt context. Example:

// Your ISR-based implementation.
uint32_t micros32();
// Extend to 64 bits.
uint64_t micros64() {
 static uint64_t time64;
 time64 += micros() - (uint32_t) time64;
 return time64;
}

This should work as long as you call micros64() often enough. Presumably, you will have something like if (micros64() - lastTime > period) { ... } within your loop, so this should be no issue as long as you never block your loop.

Actually, you can push this idea even further. If you can guarantee that micros64() will be called at least once every 65.5 ms, then you could have your ISR increment only a 16-bit counter.

• Vasil Kalchev: Thank you, this will solve the issue. The last part will be a nice further optimization for my case.