Re: [avr-libc-dev] [RFC] Sleeping BOD API

[Krzysztof Kościuszkiewicz]

Note: re-sending message as it wasn't delivered to avr-libc-dev 

On Fri, Feb 06, 2009 at 12:00:17PM -0700, Weddington, Eric wrote:

> > > > > +#define sleep_bod_disable()  \
> > > > > +(__extension__({             \
> > > > > +    __asm__ __volatile__ (   \
> > > > > +        "ori  %0,%1" \
> > > > > +        : "+d" (MCUCR) \
> > > > > +        : "i" (_BV(BODS) | _BV(BODSE)) \
> > > > > +    ); \
> > > > > +    __asm__ __volatile__ (   \
> > > > > +        "andi  %0,%1" \
> > > > > +        : "=d" (MCUCR) \
> > > > > +        : "i" (~_BV(BODSE)) \
> > > > > +    ); \
> > > > > +}))

> > Is there any disadvantage to including the OUT instructions directly
> > instead of breaking up the macro into two asm statements? 

> Yes. I would then have to specify the exact register to use. I don't
> want to do that, because I don't really care what register is being
> used to modify the value, as long it meets the constraints for the
> ORI and ANDI instructions.

Then why not use temporary variable:

#define sleep_bod_disable()                     \
    do {                                        \
        unsigned char tmp = MCUCR;              \
        __asm__ __volatile__ (                  \
            "ori  %0,%1"  "\n\t"                \
            "out  %3,%0"  "\n\t"                \
            "andi %0,%2"  "\n\t"                \
            "out  %3,%0"  "\n\t"                \
            : "+d" (tmp)                        \
            : "i" (_BV(BODS) | _BV(BODSE)),     \
              "i" (~_BV(BODSE)),                \
              "I" (_SFR_IO_ADDR(MCUCR))         \
        );                                      \
    } while (0)

> The sfr won't change due to user code because the macro generates two
> __asm__ statements back-to-back. No user code can get in between. As
> long as the macro is used in the recommended sequence (described in
> the documentation part, then interrupts will be turned off so it won't
> interrupt the sequence timing.

You are right, but the compiler will not be able to figure that out.
Correct me if I'm wrong, but I believe gcc *should* generate two INs and
two OUTs for the macro above, ie. treat MCUCR as volatile.

Regards,
-- 
Krzysztof Kościuszkiewicz
Skype: dr.vee,  Gadu: 111851,  Jabber: address@hidden
"Simplicity is the ultimate sophistication" -- Leonardo da Vinci