AVR Freaks

The Arduino happens to use Tiimer0 in OVF mode.    e.g. 16MHz / 64 / 256 = 976Hz or 1.024ms

You could use it in CTC mode.   e.g. 16MHz / 64/ 250 = 1000Hz or 1.00ms    (OCR0A = 249)

I would save Timer1 for better things.

I would save Timer2 for ASSR.

Since most Arduino hardware uses ceramic resonators,    the timekeeping is not very accurate.

David.

16MHz / 64 / 256 is 976 _Hz_

OP, it's actually easier to use an 8-bit timer to generate an accurate tick at a faster rate (like your 1ms) than at a slower rate.  The problem is mostly the absurdly low selection of prescale values.

Suppose one needed a 10ms tick, and that it could have some tick-to-tick jitter as long as the long-term rate was exactly 1000/sec.  The math says 16000000/1024/100 = 156.25, so we would need our 8-bit timer to tick every 156.25 counts - an obvious impossibility.

But what we can do is to tick 156, 156, 156, 157, 156...  That is, every 4th tick, we increase the compare value from 156 to 157, then back again.  This results in a maximum per-tick timing error of 0.75/156.25 or 0.48%, and a long-term timing error of 0%.

Here is code I've written in the past to do this.  The approach I took only uses 8-bit math, to keep things as efficient as possible on an 8-bit chip.

// since our goal is a tick count of 156.25, 
// we will switch to 157 1 time out of every 4

#define CNT_BASE 156
#define CNT_NUM  1
#define CNT_DEN  4   // 1/4

ISR(8_BIT_CTC_MODE) // fill in correct vector name
{
    static int8_t acc = 0;
    
    ...first do all regular tick ISR work...
    
    // this is the additional clock-slipping code, all 8-bit math
    acc -= CNT_NUM;
    if (acc < 0)
    {
        acc += CNT_DEN;
        OCR0A = CNT_BASE+1; // slip one additional clock this time
    }
    else
    {
        OCR0A = CNT_BASE;  // don't slip
    }
}

This will work with any value of CNT_DEN < 128, I think.  Normally CNT_DEN won't be greater than 8 or maybe 16, and CNT_NUM will always be < CNT_DEN.

ISR(TIMER0_OVF_vect)
{
	// Full count overflows happen every 1.024ms at 16MHz
	// Restart counter above zero for other rates
	// Never do this if using PWM on this timer 
	// (or at least never let the OCR value below the start value)
	//TCNT0 = 131;	// for .5ms
	TCNT0 = 6;	// for 1ms
	
	// Update various task timers
	if (positionupdatetime > 0)  positionupdatetime--;
	if (stateUpdateTime > 0) stateUpdateTime--;
	if (ledupdatetime != 0) 	ledupdatetime--;
	if (swdebouncetime > 0) 	swdebouncetime--;

}

You can stop the timer at 250 using the appropriate timer mode or start the timer at 6 in the Overflow ISR

Teensyduino and I assume Arduino, correct for the 1mSec interrupt rate error by adjusting the count within the ISR every few interrupts.

Of course you can make a software adjustment to 100% jitter-free hardware.

Making a latency-dependent hardware adjustment to the hardware is going to produce a cumulative error of all the latencies.

Yes,    it is a little academic with most Arduino boards.      They have inaccurate ceramic resonators in the first place.

However,   a regular HF crystal will keep reasonable accuracy for a RTC.   e.g. displaying hh:mm for weeks.

David.

David,

Do I understand correctly that the source of the jitter the uncertainty that the counter will be set to 6 before the next count? I can see the potential for higher priority interrupts blocking. Perhaps not such a big deal with larger prescale settings.

I learned this trick on older chips where timer 0 does not have compare functions and never thought of the missing counts (nor had an application so time critical)

Kirk