# Millis versus centis on AVR platform

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?

• 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. Oct 14, 2014 at 4:58
• 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 Oct 14, 2014 at 4:59
• @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? Oct 14, 2014 at 5:10
• @IgnacioVazquez-Abrams What is "timing the old-fashioned way"? Oct 14, 2014 at 5:11
• Well, I need to time multiple events which have different timeout intervals, hence the millis or equivalent. Oct 14, 2014 at 5:16