avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] [RFC] sleep api


From: Theodore A. Roth
Subject: Re: [avr-libc-dev] [RFC] sleep api
Date: Mon, 4 Nov 2002 09:14:52 -0800 (PST)

On Mon, 4 Nov 2002, Joerg Wunsch wrote:

:) I notice there's no #ifndef __ASSEMBLER__ around it, so it can be used
:) with both, the assembler and the C environment.  Makes sense, but then
:) it should expand into valid assembler code for the __ASSEMBLER__ case.

This should probably just be C only. I didn't think about the assembler
case. How would you make it valid for both asm and C? I think you'd have
to write the code in a separate asm file as functions. I don't think you
can use the asm statement in an assembler file, can you?

:)
:) >     \note FIXME: TRoth/2002-11-01: These modes were taken from the mega128
:) >     datasheet and might not be applicable or correct for all devices. */
:)
:) I think we could fix that, and provide the macros in a
:) device-dependent fashion.  That way, someone who tries to use
:) SLEEP_MODE_ADC with an older device will get a compile-time error.

That was the intent of the fixme comment. ;-)

:)
:) > #define sleep_mode() {                         \
:) >     MCUCR |= _BV (SE);                         \
:) >     __asm__ __volatile__ ("sleep" "\n\t" :: ); \
:) >     MCUCR &= ~_BV (SE);                        \
:) > }
:)
:) Why not write it completely in assembler code?

Could be done. I took the easy route here to get the ideas down for
discussion and to clearly show the intent of the macro.

:) >   #define bad( arg ) (_BV(arg))
:)
:) Nope, that's already OK (the preprocessor knows that bad will be a
:) macro with an argument, based on the first paren seen).  But i agree
:) that we should adhere to a consistent style.

Ok. Makes sense.

:)
:) > I made some dox improvements since posting this, so the new file is
:) > attached. Will probably commit it tomorrow if there's no noise.
:)
:) Please commit it despite my nitpicking above.  We can easily fix this
:) afterwards.

Ok. Committed.

Ted Roth





reply via email to

[Prev in Thread] Current Thread [Next in Thread]