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

[Harald Kipp]

Hi Oliver,

That's true. However, there are
    crystal-clock / 1000
cycles between two timer ticks. However, even if the callback
is evil, the timeout or sleep periods of the following timers
are increased by 1 ms. Nut/OS clearly states, that this may
happen.

The tick counter is still incremented. Thus, the date/time
functions will be properly updated.

In the current release, an evil callback would block all
interrupts. Anyway, it's intended as a first proposal. The
intention is to trigger discussion.

How about keeping the timer interrupt disabled? In this
case the maximum callback time may increase to less than
    2 * crystal-clock / 1000
before damage occurs.

Harald


At 23:12 12.06.2005 +0200, you wrote:
>Hi Harald,
>
>Perhaps I'm wrong, but on the first look it seems to me, that NutOS does not
>decrement any existing timer (or at least the first one) while processing
>the callback functions in NutTimerProcessElapsed().
>
>In NutTimerProcessElapsed first runningTimer is set to zero, then the
>callback function(s) are processed and after that, runningTimer is set again
>to nutTimerList.
>While processing the callback function(s) if an timer interrupt occurs, the
>topmost timer is not decremented, b/c runningTimer is zero. As a result, one
>timer tick is lost for all queued timers.
>
>Right so far? So if, we need a better solution I think...
>
>Cheers,
>Oliver.