1
\$\begingroup\$

me and friend were discussing what the most accurate way have an timer interrupt happen every second in RISC-V. We understand that the internal clock is generally inaccurate, but were still wondering what typically would be the most accurate way to do this, and we thought of reasons for both (assuming you set this immediately in your interrupt handler):

setting TIMECMP = TIMECMP + 1000

  • you will incur minimal delay processing as it is simply a load+add+store

setting TIMECMP = TIME+1000

  • if the interrupt is delayed but the clock stays true for some reason, this will drift less
\$\endgroup\$
4
  • 2
    \$\begingroup\$ Please add some context. Here is my take on this: The first example will ensure the next interrupt will always start exactly 1000 ms after the current one, within the limits of the accuracy of what I assume is a hardware based timer. The second example does not take into account the processing time within the interrupt handler, up to the point the timer is read and the next interrupt is calculated and will drift. As you have included no context, this is just a guess. \$\endgroup\$
    – StarCat
    Commented Nov 11, 2022 at 7:35
  • \$\begingroup\$ Please clarify your specific problem or provide additional details to highlight exactly what you need. As it's currently written, it's hard to tell exactly what you're asking. \$\endgroup\$
    – Community Bot
    Commented Nov 11, 2022 at 8:22
  • \$\begingroup\$ Use a GPS one-pulse-per-second output as an interrupt to your processor. Then you're talking atomic-clock-level long-term accuracy. \$\endgroup\$
    – rdtsc
    Commented Nov 11, 2022 at 13:17
  • \$\begingroup\$ Assuming the processor has a functional capture-compare peripheral you only have to service the interrupt and set the next interrupt count before the next one is due. That's a very loose requirement. Of course you can't do any better than the internal clock without adding something outside, but you can get cycle perfect counting. \$\endgroup\$ Commented Nov 11, 2022 at 15:32

1 Answer 1

3
\$\begingroup\$

When resetting a cyclic timer interrupt, you always take the timer register/capture value and use that for calculating the next interrupt. There are several reasons why:

  • Interrupt latency. The time from where the MCU registers the interrupt to the point where the software enters the interrupt is partially a fixed, known delay, partially a potentially huge, unknown delay if some other ISR was already executing.
  • Code execution overhead. The code in your ISR resetting the timer takes time to execute.

The above delays are far bigger than caused by any clock inaccuracy. If you calculate the time for the next interrupt based on the time when the timer set the interrupt flag, instead of the time when you entered the interrupt, you compensate for these problems.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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