[En-Nut-Discussion] AVR Idle Sleep Mode

[Bernd Walter]

On Tue, Sep 25, 2012 at 11:32:06AM +0200, Uwe Bonnes wrote:
> >>>>> "Michael" == Michael Jones <Michael.e.Jones at web.de> writes:
> 
> <proposal to make SLEEP_MODE_IDLE for AVR>
> 
> 
>     Michael> I must strongly object, sleep mode, depending on the CPU, 
> 
> I was talking about AVR, not "some CPU".
> 
>     Michael> has
>     Michael> an impact on various performance issues both for execution and
>     Michael> periphery.  
> 
> Please explain the impact of SLEEP_MODE_IDLE on AVR. In my understanding,
> this will lower timing jitter after the wake-up event, as we always restart
> execution after the line
>             __asm__ __volatile__ ("sleep" "\n\t" :: );
> and otherwise we restart anywhere in the sequence
>     for (;;) {
>         NutThreadYield();
>         NutThreadDestroy();
>        if (idle_sleep_mode != SLEEP_MODE_NONE) {
>        }
>     }
> 
>     Michael> It must remain a conscious decision of the
>     Michael> individual developer if this is wanted.
> 
> The "conscious decision" can always be done by the developper at the start of
> main() with a call to  NutThreadSetSleepMode(uint8_t mode). This would
> document that the user setup needs some special setting and not hide it in
> some system code.

The default is there intentionaly - getting CPU sleeps right is a very
tricky thing and can only be done if the developer has taken care
of them.
For example the  above code is missing the case that after calling
NutThreadYield() an interrupt service sets a thread on the run queue
before sleeping.
In that case the thread won't get serviced until the next interrupt
reeenables the CPU, which at worst case is the timer at IIRC 65ms in
default configuration.
I don't think that most developers want random 65ms jitter here.
Either fix that race condition, which really isn't easy and probably
even impossible with AVR, or leave the default as it is.
For fixing the race completely you need hardware support, which AFAIK
AVR has not.
There are applications where this is not a problem, or non ethernut
related use cases were those race conditions won't happen, but those
are shurely not the standard case for ethernut users.

-- 
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.