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

[Harald Kipp]

Hi,

I was sure that I missed to mention one severe change in the
ChangeLog. Right, for now I removed the callback from interrupt
context. But nothing is lost.

I recognized, that a double linked list would be required for
both, the timer list and the thread list. Otherwise there's no
change to remove an entry without walking down the list. While
timer interrupts can be easily controlled inside the kernel,
device interrupts are still unpredictable. As they modify both
lists, any walk through one of them needs to be in a critical
section. In opposite, a double linked list would allow to
remove an entry within a predictable number of CPU cycles.

Please take the current CVS HEAD as an evaluation platform,
it's not a final design. I've tested it with several applications
and no problems appeared. But I wouldn't bet on it.

Harald

At 14:40 12.06.2005 +0200, Ole wrote:
>Hi Matthias, Harald and all theee others...
>
>>Because of the rough granularity (62.5ms) of the system timer is  quite 
>>inaccurate.
>
>I need a high accuracy of the system timer in some applications. That's 
>why I mostly don't have an external crystal and define NUT_CPU_FREQ in the 
>makefiles. This way I gain a timer resolution of 1ms.
>
>I now have some applications where the accuracy need to be 1 to 2 ms or 
>even better. With the currect approach this works quite fine. If we remove 
>the ability of NutTimerStart completely or move it out of the interrupt 
>context I'd need to define my own timer API. Ok, I'd do so if we could 
>make NutOS faster with this approach. I'd like to have some kind of timer 
>api where one could define one or more timer that call a custom callback. 
>But that's what we just thought about some days ago, right?