Joerg Wunsch wrote on Samstag, 10. September 2005 22:30 :
> > One thing, however, that I think that we might want to change some
> > day is the __tmp_reg__,__zero_reg__ issue. I assume that the
> > original decision to use r0/r1 stems from times when there were no
> > hardware multipliers.
>
> That
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
As Björn Haase wrote:
> In fact, I don't think so. The planned change in the main function
> (so that main() does no longer initialize the stack pointer) should
> not be a problem, IIUC, since the stack pointer is already
> initialized by the device-specific crt.?
Yes, it is, and I recently fixed
As Joerg Wunsch wrote:
> Would it make sense to have that on the schedule for GCC 5.x (plus
> avr-libc 2.x)?
Perhaps it would also be a good idea to change the interrupt vector
table to the same way as MSP430-gcc is using by the same time. The
new scheme definately does have some merit, but not
I did some more work on an experimetal utility to parse the part
description XML files from AVRStudio into device specific include
files.
Umm, but you know that Atmel already ships such a utility as part of
AVR Studio, do you?
Unfortunately, it's Windows-only, and as it apparently uses
Microsof
Joerg Wunsch wrote on Freitag, 9. September 2005 23:39 :
> Our release policy says a major # bump is required iff an
> incompatibility with some GCC version arises. This is currently not
> the case (but if I understood Björn right, that could happen in the
> near future).
In fact, I don't think so
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
Joerg Wunsch wrote:
I just noticed I missed to reply to that question:
As E. Weddington wrote:
And then, with all the proposed changes, would this warrant a 2.0
release?
Our release policy says a major # bump is required iff an
incompatibility with some GCC version arises. This is
I just noticed I missed to reply to that question:
As E. Weddington wrote:
> And then, with all the proposed changes, would this warrant a 2.0
> release?
Our release policy says a major # bump is required iff an
incompatibility with some GCC version arises. This is currently not
the case (but i
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
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 th
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
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 .
They already knew what cbi() and sbi() did...
They assumed they knew it. ;-)
I'm rather in favour of Eric Weddington's proposed that
contains g
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,
As Wojtek Kaniewski wrote:
> >#include
> >supposedly providing a generic uniform UART view for as many as
> >possible AVRs.
> Consequently, why not move to ? It's
> there to provide generic access to SFR's regardless of MCU used ;-)
Not really. provides whatever the datasheet says.
provid
--- "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:
Would people find it annoying to add another subdir level? So then,
all "generic IO" headers could e.g. go into avr/generic/, the include
statement would then be
#include
supposedly providing a generic uniform UART view for as many as
possible AVRs.
Consequently, why not
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
E. Weddington wrote:
On the other hand, I abhor reinventing the wheel and there should be a
place for *exactly* what you describe: libraries to interface to common
external peripherals, that have been vetted. The downside to this is
twofold: the time it takes to verify the submitted code, and w
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
As E. Weddington wrote:
> > If so, what to do with timer_enable_int() and enable_external_int(),
> > should I start a for these?
> - We should define the include directory as for
> "compatability" includes only. I would take this as meaning
> "compatability with other compilers" (i.e. IAR, etc.
Wojtek Kaniewski wrote:
E. Weddington wrote:
- I think it would be best to go ahead and deprecate
timer_enable_int() and enable_external_int(). I agree that the naming
wasn't very well thought out, perhaps.
If naming consistency is important, then we should probably do
something about fde
E. Weddington wrote:
- I think it would be best to go ahead and deprecate timer_enable_int()
and enable_external_int(). I agree that the naming wasn't very well
thought out, perhaps.
If naming consistency is important, then we should probably do something
about fdevopen() and fdev_*() too. Al
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 and to eventually
be merged. As a next step, we could deprecate one of those, and
issue a #warning if it gets included. But whic
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 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
r
45 matches
Mail list logo
