avr-gcc-list
[Top][All Lists]
Advanced

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

Re: [avr-gcc-list] ISR function name aliasing?


From: John Myers
Subject: Re: [avr-gcc-list] ISR function name aliasing?
Date: Tue, 7 Apr 2009 19:49:27 -0700

It looks like I can use ISR_ALIAS(XXX_vect,my_isr) which creates in extra jump instruction to the ISR.
although I wanted to avoid any extra overhead.


On Mon, Apr 6, 2009 at 9:15 PM, Joerg Wunsch <address@hidden> wrote:
John Myers <address@hidden> wrote:

> I have an ISR in a library.

That doesn't work directly, because it's hard to trigger an undefined
reference to it that will make the linker link that particular library
module.  All the interrupt vectors are always defined already (so they
won't appear as `global undefined' symbol which is what makes the
linker search a library), but they are defined as weak symbols so any
object module can override them.

There are two situations I could think of:

1) The module is not linked by its __vector_N name but by another
symbol (that could be a data reference or another function name) that
will also be resolved by the same object module in the library.

2) I'm not sure, but perhaps you can force the __vector_N symbol to be
`global undefined' using the -u__vector_N linker option.

> I want to be able to compile the ISR with a generic target and not
> have the ISR name tied to a specific interrupt vector.

This is currently not possible because avr-libc does not work by
vector names but by vector numbers.  That's what I meant with
__vector_N, where N is a number.  Each XXX_vect name is converted into
a (MCU specific) __vector_N name already at the preprocessing stage.

> Is this possible?

I think your best bet is to make the library supply a function name
that is then called by your actual ISR.  It's not quite optimal, in
particular if the function is relatively short and doesn't use all the
"caller saved" registers per the ABI because the compiler will always
save all of them on the stack before calling that function (since it
doesn't know what is actually going to be destroyed).

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)


_______________________________________________
AVR-GCC-list mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list


reply via email to

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