[Top][All Lists]

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

Re: [avr-gcc-list] Re: More interrupt oddity

From: Larry Barello
Subject: Re: [avr-gcc-list] Re: More interrupt oddity
Date: Sat, 20 Oct 2001 17:36:59 -0700

Simple: if you misspell the macro name then you get a routine
with the entry point of SIG_INTERUPT0() - since it is not called
by anything you wouldn't see it.  I bet it is there, just
somewhere else in the memory map.  Look at the linker map and you
will probably find it floating around somewhere, a spot of dead

"SIG_INTERRUPT0" is translated to "_interrupt0_" (sig-avr.h)
which is the entry point used by the interrupt vector table
(gcrt1.S) If "_interrupt0_" doesn't appear, then the vector table
points to a dummy return.

You can just use "_interrupt0_" instead of SIG_INTERRUPT0 and it
will work the same.  SIG_INTERRUPT0 is just another level of
indirection for some reason or another.

Mike's advice was good: look in the headers to see how it all

----- Original Message -----
From: "Mike Dombrowski" <address@hidden>
To: <address@hidden>
Sent: Saturday, October 20, 2001 5:24 PM
Subject: [avr-gcc-list] Re: More interrupt oddity

> On 21 Oct 2001, at 12:01, address@hidden
> > Ok, I solved my own problem. What I did wrong was this:
> >
> >
> > volatile char displacement;
> >
> > SIGNAL(SIG_INTERUPT0) <------notice mis-spelling, should be
> > {                                   with 2 R's
> >  --displacement;
> > }
> >
> > The goofy part is that the linker didn't give any errors or
> > that something may be wrong. Shouldn't it fail with an
> > symbol or something?
> I believe the interrupt routines are defined as macros, so
> the macro with a bad input would just not meet and #IF and thus
> nothing would be put in your code as a result of the macro. I
> be wrong tho, the way to check is to look at the header.

reply via email to

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