[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