[En-Nut-Discussion] Timer timing changed btw. ver 2.5.2 and 3.2.1

[Alessandro Zummo]

On Sun, 1 Jun 2003 10:56:48 +0200
"Lars Andersson" <lakab at telia.com> wrote:

> 
> So, now I try without the CPU_FREQ define in nut/os 3.2.1,
> NutGetCpuClock() returns a reasonable value, 3.6865 MHz, 
> but real time based on on counting callbacks from a 1 second
> timer is much worse than with CPU_FREQ defined, it is now 
> 21% slower. (I have not touched anything in the OS except
> defining/undefining CPU_FREQ and reMaking)

 I had the same problem. The tecnique you're using to keep track
of the time will always be influenced by the system load, because
is pure software. 

 The same timer that's used to give you the callbacks is used
to keep track of many other events. You will experience 
more delay as you add features to your software.

 The are different ways to solve this kind of problem:

 - use NutGetTickCount() in your callback. If the difference
 between the previous call and the current one is != 16
 (ticks per seconds) you can compensate the timer in software.

 - Use an external 1Hz signal connected to an interrupt pin
 to count. Many hardware RTC chips are able to provide
 such a reference signal (usually called ppm)

 - Use an hardware timer. Do a little bit of math, set the prescaler
 and you will have an interrupt every second.

 I'm currently using the third one and, until now, has proven to be
very reliable even with an high system load and another timer in use.

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Turin, Italy

  http://www.towertech.it