Micros() rolling over after 59.652323 seconds, not 71 minutes [SOLVED]

[BDub]

Yay! I'm glad to see you digging into this @rvnash

@rvnash

You previous posts where you suggest:

BDub:
If you are looking to precisely time something that's taking longer than 59.652323 seconds,
I would recommend using the millis() counter.

I'm afraid that suggestion does not work. If I need to time an event that takes less than a millisecond, I can't use the millis() counter. But remember, that event might occur right near and span the 59.652323 second boundary (for the Core), so I need to take into account that exact rollover point to do the subtraction right to get the event's duration.

If you read again I am saying if you want precise timing for something that's almost a minute long (>59.652323s micros() rollover), that you should use the millis() counter. If you need such dynamic range, <1ms ~ >59652ms you could check the micros() counter first and if you get to be over (10246464)us aka 0b10000000000000000000000 (a quick bit mask check), you could switch to testing against the millis() counter. If your very short even is happening asynchronously, then you need to use interrupts. Read on

@rvnash

Also, looking at the code of micros() there is a divide in it. This is a bit unfortunate for those who would hope that such a call would be as efficient as possible.

Agreed this makes the result not super accurate, but you can roll your own precision counter pretty easily using interrupts and the DWT counter Stopwatch for Pinewood Derby - #17 by BDub

@rvnash

And looking at the code for delayMicroseconds : It caps the maximum delay time to UINT_MAX / SYSTEM_US_TICKS, which is probably OK since who would use delayMicroseconds for such a long delay? But that should be documented. And, I still think that number is different for Photon seeing as that function uses SYSTEM_US_TICKS which will be different for Photon.

SYSTEM_US_TICKS is the number of ticks per microsecond, calculated as SystemCoreClock / 1000000. So it is calculated based on each system's core clock speed (72MHz vs 120MHz). You're right we should document this rollover number for both systems (the Core is done, Photon would need to be calculated). If you are doing the math and would like to submit a pull request to update the comments of that code, please do! Even if you just submit the information as a firmware/docs issue that would be sweet.

@rvnash

And yet another thing ... neither 72 or 120 divides evenly into 2^32. This means that due to the division's truncation, that last microsecond of timing will be different as it rolls over. It will be shorter.

It would also be good to document this anomaly, which could be solved by rolling your own DWT/Interrupt timer, or Peekay's proposed timer capture mode.