On Saturday 10 September 2005 01:48, Dave Hansen wrote:
[...]
> Has anyone put any thought into how we might get avr-gcc to do something
> other than silently generate incorrect code when the user specifies an
> incorrect SIG_* (or *_vect) symbol? For example, if I try to write
>
>SIGNAL(SIG_I
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 are
Marek Michalkiewicz wrote on Freitag, 9. September 2005 19:18 :
> On Fri, Sep 09, 2005 at 10:35:46AM -0600, E. Weddington wrote:
> > - 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.
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
everythi
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 than .
> Me too and, if it avr specific than rather than
>
As that still has the problem of adding another level of subdirs,
there doesn't
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 than .
>
Me too
and, if it avr specific than rather than
i also suggest moving to something like
since no one (su
On Fri, Sep 09, 2005 at 10:35:46AM -0600, E. Weddington wrote:
> - 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.
Probably not that awful :) - see how
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 als
From: Joerg Wunsch <[EMAIL PROTECTED]>
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
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 cou
On Fri, 9 Sep 2005, Szikra István wrote:
> > BTW, would be a good place for 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 are supposed to
> >That would also be fine. Any macros would be better than explaining
> >the '&=~'-nightmare.
>
> I support it,
> in fact i already have something like this (for personal usage, since
> it's not in RC1 stage yet)
> If anyone interested in an alpha stage header :
> http://szm.no-ip.com/~szir/gc
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 than .
Me too
and, if it avr specific than rather than
i also suggest moving to something like
since noone (supposed) usin
Joerg Wunsch wrote on Donnerstag, 8. September 2005 20:50 :
> As Matthew MacClary wrote:
>
> (About whether to keep or after
> merging their contents.)
>
> > My suggestion would be to change INTERRUPT to be the same as
> > SIGNAL, and then deprecate SIGNAL.
>
> Sorry, but I have to *strongly*
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 self-inv
On Thu, Sep 08, 2005 at 10:52:40PM +0200, Joerg Wunsch wrote:
> 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(),
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 b
Zane D. Purvis wrote:
Joerg Wunsch wrote:
As Matthew MacClary wrote:
(About whether to keep or 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 the sam
Joerg Wunsch wrote:
I don't know. I'm more inclined to use ISR(), but I'd rather like to
see other people's opinions on this.
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.
Obtw., of course, it
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" <[EMAIL PROTECTED]> a écrit :
> Joerg Wunsch wrote:
>
> >As Matthew MacClary wrote:
> >
> >(About whether to keep or after
> >merging their contents.)
> >
> >
> >
> >>My suggestion would be to change INTERRUPT to be the same as
> >>SIGNAL, and then deprecate SIGNAL.
>
Joerg Wunsch 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 suggested before, but so far, nobody else seemed to
care about that suggestion.
I'm o
Joerg Wunsch wrote:
As Matthew MacClary wrote:
(About whether to keep or 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 the same thing as
the exis
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 suggested before, but so far, nobody else seemed to
care about that suggestion
As Matthew MacClary wrote:
(About whether to keep or after
merging their contents.)
> My suggestion would be to change INTERRUPT to be the same as
> SIGNAL, and then deprecate SIGNAL.
Sorry, but I have to *strongly* object with that.
After an API change, code that used to work must either
Matthew MacClary wrote on Donnerstag, 8. September 2005 18:26 :
> On Wed, Sep 07, 2005 at 11:27:21PM -0600, E. Weddington wrote:
> > Joerg Wunsch wrote:
> > >. I'd like to get and to eventually
> > > be merged. As a next step, we could deprecate one of those, and
> > > issue a #warning if it get
On Wed, Sep 07, 2005 at 11:27:21PM -0600, E. Weddington wrote:
> Joerg Wunsch wrote:
> >. I'd like to get and 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 tend to keep as thi
28 matches
Mail list logo
