[En-Nut-Discussion] RFC - Redesigning Timer Interrupt Processing

Harald Kipp harald.kipp at egnite.de
Fri Jun 10 21:26:47 CEST 2005


At 20:55 10.06.2005 +0200, Matthias Ringwald wrote:

>Because of the rough granularity (62.5ms) of the system timer is
>quite inaccurate.

If NUT_CPU_FREQ is defined, the granularity is 1 ms.

For short periodic tasks a timer callback is much less
overhead compared to a thread with NutSleep().

Ole stated, that there is a need for a timer/counter API.
After reading all this complex AVR timer handling in the
data sheet again, I can confirm, that such an API would
be helpful. If this API could be "married" with the old
calls...

/* Our beloved grandpa, using the system timer. */
/* Warning! This may turn our fine RTOS to a lousy OS. */
NutTimerStart(...);

/* Brand new, using a selectable timer. */
NutExtraTimerStart(tc, ...);

...nothing needs to be changed outside the kernel.
And it will add just one tiny if() to the new handler.
At least this is what I expect, but "Der Teufel steckt
im Detail".

If it fails, no problem. Version jump 3 to 4 allows
some kind of incompatibility. Which reminds me, that
I should add a CVS branch before moving on. As far as
I can say, the current CVS HEAD looks rock solid.

Harald




More information about the En-Nut-Discussion mailing list