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

[Larry Barello]

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
code.

"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
works.

----- 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
wrote:
>
> > Ok, I solved my own problem. What I did wrong was this:
> >
> >
> > volatile char displacement;
> >
> > SIGNAL(SIG_INTERUPT0) <------notice mis-spelling, should be
> > SIG_INTERRUPT0
> > {                                   with 2 R's
> >  --displacement;
> > }
> >
> > The goofy part is that the linker didn't give any errors or
warnings
> > that something may be wrong. Shouldn't it fail with an
undefined
> > symbol or something?
>
> I believe the interrupt routines are defined as macros, so
running
> 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
may
> be wrong tho, the way to check is to look at the header.
>