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+POPplusCLR,IN, andRETI - 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?
Best Answer
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.