As Wojtek Kaniewski wrote:
What about the SIG_ prefix? If we'll move to something else than
SIGNAL(), I think that it should be dropped or somehow hidden from
the users.
Very good point. I've been thinking about adding a second set of
vector names anyway. Our names are completely
For the whole SIGNAL vs INTERRUPT flame:
I'm with 'deprecate booth', cause of ambiguous (and maybe a bit
stupid) naming.
SIGNAL is a normal interrupt, (I'd like INT for it, but integer is
already int, so) i really like the ISR name idea.
since INTERRUPT is an eXtended interrupt (with a sei) it
Joerg Wunsch wrote:
As Wojtek Kaniewski wrote:
What about the SIG_ prefix? If we'll move to something else than
SIGNAL(), I think that it should be dropped or somehow hidden from
the users.
Very good point. I've been thinking about adding a second set of
vector names anyway. Our names
On Fri, 9 Sep 2005, Szikra István wrote:
BTW, util/... would be a good place for avr/crc16.h too.
Unfortunately crc16.h is not completely independent from avr hw on the
account it uses inline asm, and not (ansi) c.
I believe that it's about functionality, not implementation. Delays and
CRC
2005/9/9, E. Weddington [EMAIL PROTECTED]:
- I do like the idea that Royce has (above) about naming the ISR
function any name. However, I agree with Joerg, in that it would take an
awful lot of effort. Perhaps someday, but not now.
mspgcc interrupts are handled that way.
Quoting from the
Wojtek Kaniewski wrote:
Joerg Wunsch wrote:
My only concern is to not pollute the include/avr subdirectory itself
too much.
I'd prefer those functions to be in util/* than avr/generic/*.
Me too
and, if it avr specific than rather avr/util/* than avr/generic/*
i also suggest moving
Hi,
I did some more work on an experimetal utility to parse the part description
XML files from AVRStudio into device specific include files. I still have to
do a bit more work on it, but I think that the idea will work. I was able
to generate vector macros, register macros and bit macros from
Joerg Wunsch wrote:
As Wojtek Kaniewski wrote:
Very good point. I've been thinking about adding a second set of
vector names anyway. Our names are completely self-invented. In the
long run, I'd rather like to migrate the names as they appear in the
Atmel XML files, which incidentally
Oh well, yet another mass followup. Sorry if that's messing up your
thread displays. ;-)
As Szikra Istvan wrote:
I'd prefer those functions to be in util/* than avr/generic/*.
Me too and, if it avr specific than rather avr/util/* than
avr/generic/*
As that still has the problem of adding
Joerg Wunsch wrote:
Oh well, yet another mass followup. Sorry if that's messing up your
thread displays. ;-)
I think it's hopeless now. :-)
Do we still need copies to avr-gcc-list? Or can everyone agree to go
take this to avr-libc-dev only? (I'd like to not get two copies of
As E. Weddington wrote:
If so, what to do with timer_enable_int() and enable_external_int(),
should I start a compat/deprecated.h for these?
- We should define the compat/* include directory as for
compatability includes only. I would take this as meaning
compatability with other
On Wed, Sep 07, 2005 at 11:27:21PM -0600, E. Weddington wrote:
Joerg Wunsch wrote:
. I'd like to get avr/signal.h and avr/interrupt.h to eventually
be merged. As a next step, we could deprecate one of those, and
issue a #warning if it gets included. But which of the names to
retain? I
Joerg Wunsch wrote:
As Matthew MacClary wrote:
(About whether to keep avr/interrupt.h or avr/signal.h after
merging their contents.)
My suggestion would be to change INTERRUPT to be the same as
SIGNAL, and then deprecate SIGNAL.
How about changing the name to ISR, which would do
--- Zane D. Purvis [EMAIL PROTECTED] a écrit :
Joerg Wunsch wrote:
As Matthew MacClary wrote:
(About whether to keep avr/interrupt.h or avr/signal.h after
merging their contents.)
My suggestion would be to change INTERRUPT to be the same as
SIGNAL, and then deprecate SIGNAL.
As Wojtek Kaniewski wrote:
#include avr/generic/uart.h
supposedly providing a generic uniform UART view for as many as
possible AVRs.
Consequently, why not move avr/io.h to avr/generic/io.h? It's
there to provide generic access to SFR's regardless of MCU used ;-)
Not really. avr/io.h
As Wojtek Kaniewski wrote:
How about...
#define VECTOR(signame) \
void SIG_ ## signame (void) __attribute__ ((interrupt)); \
void SIG_ ## signame (void)
I don't know. I'm more inclined to use ISR(), but I'd rather like to
see other people's opinions on this.
Obtw., of course,
Zane D. Purvis wrote:
Joerg Wunsch wrote:
As Matthew MacClary wrote:
(About whether to keep avr/interrupt.h or avr/signal.h after
merging their contents.)
My suggestion would be to change INTERRUPT to be the same as
SIGNAL, and then deprecate SIGNAL.
How about changing the name to
Joerg Wunsch wrote:
My only concern is to not pollute the include/avr subdirectory itself
too much.
I'd prefer those functions to be in util/* than avr/generic/*.
They already knew what cbi() and sbi() did...
They assumed they knew it. ;-)
I'm rather in favour of Eric Weddington's
Hi,
On Fri, 09 Sep 2005 01:00:44 +0530, Joerg Wunsch [EMAIL PROTECTED]
wrote:
As Zane D. Purvis wrote:
How about changing the name to ISR, which would do the same thing
as the existing SIGNAL?
Then, SIGNAL and INTERRUPT can both be deprecated (avoiding future
confusion).
It has been
Joerg Wunsch wrote:
As the impending switch to avr-libc 1.4 allows us to make API changes,
I'd like to get people's opinions on the following:
. I'd like to get avr/signal.h and avr/interrupt.h to eventually
be merged. As a next step, we could deprecate one of those, and
issue a #warning if
20 matches
Mail list logo
