[En-Nut-Discussion] NutSleep implementation optimization

[Ole Reinhardt]

Hi Harald,

> >I would realy suggest to remove the timer callback in the old fashion way 
> >(from within interrupt context) completely, but don't remove timer 
> >callbacks that will be processed outside interrupt context at all.
> 
> Why? What's the advantage if it's removed?

At the moment, the timer interrupt is called nearly every ms, right? If
we remove the possibility of callbacks from the interrupt at all, we
will save some piece of code that will be processed every ms. Even if
it's only a lookup if there is a callback registered, this makes some
additional calls every ms. If we move this feature to a second timer, we
make this configurable, as we don't even have to initialize this second
timer if we don't need it at all. Timer0 is always running.

My only goal is to have the shortest possible interrupt handler.

> Most applications didn't use timer callbacks with the old implementation
> either. What I did was to remove _kernel_ timer callbacks from interrupt
> context. But we can still add support for application callback within
> interrupt context.

Ok, one could also make the compilation switchabel with a preprocessor
macro.

But perhaps I have not fully understood your timer concept...

> >One other Idea is not to block all interrupts, but the timer interrupt. 
> >This would not completely block the whole system.
> 
> If running in interrupt context, all interrupts are blocked unless
> we allow nested interrupts. This is supported, but do you really
> want to make this mandantory? If yes, we will never be able to
> calculate stack usage.

Right, I forgot about this issue... sorry. Nested interrupts are'nt that
fine, but for speeding up NutOS I would hold it in mind. Do we need to
calculate stack usage? What's about the interrupt stack? These parts of
NutOS I'm not that familiar with. Perhaps you could also explain me
these details on phone later?

> >Btw: Why doe we alwyys block all interrupts in a critical section and not 
> >only the ones that would influence our code? In case of an UART we could 
> >only block the UART interrupt and still be able to process network traffic...
> >
> >Have I missed something?
> 
> Either you or me. :-) You are right for drivers. Some of them
> already make use of this. And I used this in the new timer code
> as well. But the kernel is unable to tell who will call
> NutEventPostFromIrq(). Thus, it has to block _all_ interrupts in
> NutEventWait().

Shure. NutEventWait has to do so. My focus was laying on the drivers.

Bye bye,

Ole

-- 
kernel concepts    Tel: +49-271-771091-14
Dreisbachstr. 24   Fax: +49-271-771091-19
D-57250 Netphen    E+ : +49-177-7420433
--