Suppose I want to make a static library (.a file), which contains an ISR. That library should be used by many AVR MCUs, but each device has different ISR vector name, so it cannot be defined in .c file. Is it correct according to C conventions to define the ISR in the header file?
This is EXACTLY why no one uses static libraries for AVR ;-)
Just give them the source and let it determine at build time which model and hence which vector it has to hook.
I'm not suggesting that it is a good idea,
but if one really wants, one can put the ISR in a .a file.
Use the ISR macro to give it a name like fred_vect.
If I got it right, that satisfies the naming convention
needed to avoid a warning about a misnamed ISR.
The user needs to do two things: point a vector entry at fred_vect
and pull the ISR out of the library.
IIRC a macro exists just for the former, ISR_ALIAS or some such thing.
The way avr-gcc handles vector tables (weak symbols)
I'm not sure whether that would pull out fred_vect.
If not and if fred_vect is in a member by itself,
a little extra effort is needed.
Either a little assembly or a linker option will do he trick.
I think " .extern fred_vect" will do the trick.
"-Wl,-Ufred_vect" on the link line will definitely work.
Simpler is putting the ISR in an always-needed member.
All that said, it's probably not all that great an idea.
An ISR is something the user is likely to want to edit,
especially if it's a timer ISR.
Use the ISR macro to give it a name like fred_vect.
If I got it right, that satisfies the naming convention
needed to avoid a warning about a misnamed ISR.
The user needs to do two things: point a vector entry at fred_vect
and pull the ISR out of the library.
Then suppose the vector is something that reads a register (let's say ADC) and then it does some maths on it - perhaps a multiply. If you use this lib with a mega I guess you want the multiply to b done with a MUL but if it's a tiny you need a library multiplication done with shifts and adds. Again, you are going to need different builds (17 at the last count is it?) to account for the 17 different AVR family architectures (as AVR-LibC has to do for libc.a, libm.a and libgcc.a)
Never said it was wise.
If an ISR is involved, a source library is usually a much better idea.
