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

[Matthias Ringwald]

Hi Harald,

thanks for showing your ideas.
I really like your new NutTimerIntr handler. Its short enough. :)
Processing only one Timer is a good idea.

Some thoughts I had on compatibility. I was wondering, what would change
to older apps. What could an application expect if it is using  
NutTimerStart?
Because of the rough granularity (62.5ms) of the system timer is  
quite inaccurate.
If there are no threads which computation takes ages, the timer  
callback is still
called on time. To me, the only problematic case would be an app that  
uses a
timer to signal a running thread  which does endless processsing by  
writing
to a global variable. then, because there are no thread switches,
the callback is not called and the thread never gets the important  
signal.

BUT.. I guess this is quite pathologic, and I prefer cutting old knots (
at least there's a saying in german.. "alte Zöpfe abschneiden.." :)
and try to help convince people that this is the right way to go on.

Are there people, who really need callbacks from IRQ context with
low resolution ? For specific stuff, like high-accurate dealing
with external hardware, I guess using one of the other timers
and writing an IRQ handler should be better anyway.

Matthias

P.S. I will continue hunting long CriticalSections..