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

[Oliver Schulz]

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.


-----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: Sonntag, 12. Juni 2005 19:13
An: Ethernut User Chat (English)
Betreff: Re: [En-Nut-Discussion] RFC - Redesigning Timer Interrupt
Processing

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?

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