I am building a device on the AVR platform. The device will need some timing information, so I was thinking of reimplementing Arduino millis-like functionality (though not exactly like this). However, after doing some back of the envelope calculations (partly based on this post), it started to appear to me that millis eats up at least 5% of the CPU time on a 20Mhz processor, and proportionally more than that on a 16Mhz one:

  • Each millisecond, the timer (timer0) overflows, triggers an interrupt, which increments millis
  • An ISR should take 26 clocks for pre/post ISR routine (5 PUSH + POP plus CLR, IN, and RETI
  • The ISR itself should take about 21 clocks (load 32-bit value, increment it, and store it back in SRAM)
  • This yields almost 50 clocks, or 50 microseconds each millisecond.
  • In fact, Arduino ISR function is slower than that (as revealed by this post) because it is really careful about keeping millis as accurate as possible, which takes more CPU cycles still

I don't need millis precision, so I am considering implementing centis or even decis to save processor cycles for other stuff. Is this unreasonable? Are my calculations wrong? It would seem like an odd design choice, or am I missing something?

  • 1
    \$\begingroup\$ Unless you're creating it for end-user programming, forgo having any sort of function for this and just do the timing the old-fashioned way. \$\endgroup\$ Oct 14, 2014 at 4:58
  • 3
    \$\begingroup\$ Aren't you running at 20MHz? Then 50 clock cycles are around 3us and not 50. Also, have you checked the generated machine code to see if your numbers are correct - they seem a bit high to me \$\endgroup\$
    – Tom L.
    Oct 14, 2014 at 4:59
  • \$\begingroup\$ @TomL. Yup, you are right, forgot about the 20 in front, I was treating the CPU speed as 1Mhz. I have not decompiled the Arduino code. What seems high? \$\endgroup\$ Oct 14, 2014 at 5:10
  • 1
    \$\begingroup\$ @IgnacioVazquez-Abrams What is "timing the old-fashioned way"? \$\endgroup\$ Oct 14, 2014 at 5:11
  • 1
    \$\begingroup\$ Well, I need to time multiple events which have different timeout intervals, hence the millis or equivalent. \$\endgroup\$ Oct 14, 2014 at 5:16

1 Answer 1


50 clocks is not 50 us when running at 16 MHz, it is about 3 us. So 0.3% overhead, not 5%. You can certainly do that, but I have never had any issues with running a small ISR at 1 kHz like that before. It might be a good idea to re-implement it just so you can add more stuff to run on each timer tick, or schedule stuff to run on future ticks. A method I use quite often is to schedule something to run on e.g. 1 second intervals by storing the current time + interval in a variable and then when the time exceeds the future timestamp, I increment the timestamp by the inteval and then run the code. If a tick gets skipped, then the current call just gets delayed by one tick. It would be very easy to use this method to run stuff on 10 ms or 100 ms intervals.


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.