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 <j...@uriah.heep.sax.de> wrote: > John Myers <atomicdog....@gmail.com> 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 > AVR-GCC-list@nongnu.org > http://lists.nongnu.org/mailman/listinfo/avr-gcc-list >
_______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
