[En-Nut-Discussion] timer / clock accuracy

[Harald Kipp]

Thanks, Michael.

Some time ago this had been reported to me by Lars Andersson
via private email.

My findings:
OCR_VALUE as written to timer0.OCR0 is off by one, it was 32 should be 31.
OCR_VALUE is also used to define NUT_TICK_FREQ which complicates things

To "fix" it for atmega128, In ostimer.c change to
#define OCR_VALUE1       ((2 * NUT_TIMER_CRYSTAL / (NUT_TIMER_PRESCALE *
NUT_TICK_NFREQ) + 1) / 2)
/* Output compare register value. */
#define OCR_VALUE (OCR_VALUE1-1)
/* Caluclated number of timer ticks per second. */
#define NUT_TICK_FREQ   ((2 * NUT_TIMER_CRYSTAL / OCR_VALUE1 /
NUT_TIMER_PRESCALE + 1) / 2)

I'm too busy right now to check this and implement a fix and
would appreciate if someone else with CVS write access can
fix it.

Harald

At 13:27 07.03.2006 +0100, you wrote:
>Hi,
>
>using NutOS3.9.9 with an Ethernut1.3 board and GCC I noticed that the
>accuracy of the time base of the clock system is very bad. There was a
>deviation of nearly 1 hour per day. Checking the sources of this part of
>the OS I found out that there might be a miscalculation following makro
>in:
>  arch/avr/dev/ostimer.c
>
>/* Output compare register value. */
>
>// former calculation
>//#define OCR_VALUE       ((2 * NUT_TIMER_CRYSTAL / (NUT_TIMER_PRESCALE
>                                         * NUT_TICK_NFREQ) + 1) / 2)
>//hack:
>#define OCR_VALUE 31
>
>/* Calucalted number of timer ticks per second. */
>
>// former calculation
>//#define NUT_TICK_FREQ   ((2 * NUT_TIMER_CRYSTAL / OCR_VALUE /
>                                         NUT_TIMER_PRESCALE + 1) / 2)
>
>//hack:
>#define NUT_TICK_FREQ    1024
>
>It seems there is a mismatch between the former 32 prescaler and the
>current OCR Value of 32. OCR seems to count from 0 to 32 resulting in 33
>ticks. A quick and dirty test with 31 as ORC value and 1024 directly as
>NUT_TICK_FREQ makes the clock run with a much better accuracy. I
>achieved a deviation of just some seconds or less per day.