[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-libc-dev] [RFC] Sleeping BOD API
From: |
Krzysztof Kościuszkiewicz |
Subject: |
Re: [avr-libc-dev] [RFC] Sleeping BOD API |
Date: |
Mon, 9 Feb 2009 17:22:33 +0000 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
Note: re-sending message as it wasn't delivered to avr-libc-dev
On Fri, Feb 06, 2009 at 08:20:49AM -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)) \
> > > + ); \
> > > +}))
>
> [...]
>
> My big question is: Do I have to worry that GCC will somehow select a
> different register for MCUCR in the second __asm__ statement? I would
> think that since I am letting gcc select the register in the first
> __asm__ statement and having gcc do the output, that gcc will know
> which register that MCUCR lives in and can match that with the second
> __asm__ statement. From my tests, it seems that it is truly the case;
> the registers always match so that it generates (pseudocode):
>
> in X, 85-32
> ori X, 96
> out 85-32, X
> andi X, -33
> out 85-32, X
>
> where "X" is always the same high register ("d" constraint).
>
> This is important to meet the timed sequence needed to disable the BOD
> before sleeping.
Is there any disadvantage to including the OUT instructions directly
instead of breaking up the macro into two asm statements? This could
break unexpectedly - as you said the timing is crucial here.
I guess this trick would not work if the sfr contents could change
between OUTs - in the above case compiler assumed (why?) that they
won't.
Regards,
--
Krzysztof Kościuszkiewicz
Skype: dr.vee, Gadu: 111851, Jabber: address@hidden
"Simplicity is the ultimate sophistication" -- Leonardo da Vinci
- RE: [avr-libc-dev] [RFC] Sleeping BOD API, (continued)
- Message not available
- RE: [avr-libc-dev] [RFC] Sleeping BOD API, Weddington, Eric, 2009/02/06
- Re: [avr-libc-dev] [RFC] Sleeping BOD API, Joerg Wunsch, 2009/02/06
- RE: [avr-libc-dev] [RFC] Sleeping BOD API, Weddington, Eric, 2009/02/06
- Re: [avr-libc-dev] [RFC] Sleeping BOD API, Joerg Wunsch, 2009/02/06
- RE: [avr-libc-dev] [RFC] Sleeping BOD API, Weddington, Eric, 2009/02/06
- Re: [avr-libc-dev] [RFC] Sleeping BOD API, Joerg Wunsch, 2009/02/06
- RE: [avr-libc-dev] [RFC] Sleeping BOD API, Weddington, Eric, 2009/02/06
- Re: [avr-libc-dev] [RFC] Sleeping BOD API, Joerg Wunsch, 2009/02/07
- Re: [avr-libc-dev] [RFC] Sleeping BOD API, Joerg Wunsch, 2009/02/07
- Re: [avr-libc-dev] [RFC] Sleeping BOD API, Krzysztof Kościuszkiewicz, 2009/02/09
- Re: [avr-libc-dev] [RFC] Sleeping BOD API,
Krzysztof Kościuszkiewicz <=
RE: [avr-libc-dev] [RFC] Sleeping BOD API, Weddington, Eric, 2009/02/06
Re: [avr-libc-dev] [RFC] Sleeping BOD API, Bob Paddock, 2009/02/09
Re: [avr-libc-dev] [RFC] Sleeping BOD API, Bob Paddock, 2009/02/12