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

[Ernst Stippl]

Hi Harald!

In my opinion, a new set of API calls is the best solution because it 
- provides good separation of "old" and "new"
- minimizes the risk of breaking existing code (i.e. apps)
- allows a clean implementation of the new API ...
- whose inner woking might be changing in future ....

regards
ernst

-----Ursprüngliche Nachricht-----
Von: en-nut-discussion-bounces at egnite.de
[mailto:en-nut-discussion-bounces at egnite.de] Im Auftrag von Harald Kipp
Gesendet: Freitag, 10. Juni 2005 21:27
An: Ethernut User Chat (English)
Betreff: Re: [En-Nut-Discussion] RFC - Redesigning Timer Interrupt
Processing

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

_______________________________________________
En-Nut-Discussion mailing list
En-Nut-Discussion at egnite.de
http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion