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

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

Re: [avr-libc-dev] interrupt enable functions


From: Theodore A. Roth
Subject: Re: [avr-libc-dev] interrupt enable functions
Date: Thu, 8 Aug 2002 08:55:11 -0700 (PDT)

On Thu, 8 Aug 2002, Joerg Wunsch wrote:

:) What i don't like with this is the namespace pollution resulting
:) from it.

Good point.

:) Yes, i'd also prefer that new functionality, but it needs to be
:) explained in the docs.

True.

:) Me neither.  Btw., the timer bit macros are matching the AVR
:) documentation which you clearly need anyway.
:)
:) > :) #define timer_1_IC_interrupt_enable()           (TIMSK |= BV(5))
:)
:) > Magic numbers! Boo, hiss! :-)
:)
:) And instead of cryptic timer bit names, you gotta learn cryptic
:) interrupt enable function names. :)

My thoughts exactly.

:)
:) > First, I think that you should be using _BV() instead of the deprecated (I
:) > believe) BV(). That's an off topic nit though.
:)
:) Hmm, i didn't know BV() was deprecated.  Sure, its name is in the
:) application namespace, but we've got so many other macro names that
:) pollute the application namespace so that could hardly be an
:) argument.
:)
:) All the other macros with leading underscores (like __inw etc.) have
:) even been removed now, why do we want to make the people move from
:) BV() to _BV() then?  I can't quite follow this.

I was only regurgitating what I read here:

avr/sfr_defs.h:

    178 /* Backwards compatibility, do not use in new programs.  */
    179 #define outp(val, sfr) outb(sfr, val)
    180 #define inp(sfr) inb(sfr)
    181 #define BV(bit) _BV(bit)

I think Marek put that in there.

:)
:) > I vaguely remember Marek telling me that some things like this are only in
:) > there to be used as examples. The documentation should probably say that
:) > this is an example, note the flaw in it and leave it at that.
:)
:) Hmm.  Then we should IMHO add examples files instead.  I noticed
:) doxygen has some support for it (i. e., it can suck in an entire
:) external file).  I can provide the simple-demo.c that has been
:) written for Rich's document (a simple PWM ramp-up ramp-down LED
:) control), as well as my more advanced demo.c based on it (it
:) basically makes the PWM controllable by a few switches, a
:) potentiometer, and even by RS-232 commands).

I agree that the manual should have lots of examples.

Right now, I'm more inclined to muck with the documentation than change
the source code. I still have a lot to learn with respect to the internals
and writing dox forces me to think it through. For now, can we leave the
existing interfaces in place and work on the dox making \note or \remark
at places that might need changing. Get the manual in place and make a new
release, then go back and start addressing the interfaces.

The next release should be about the same time as gcc-3.2, I would think.
Marek, any idea when that might happen?

Ted Roth




reply via email to

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