Where should be defined a device specific ISR when making a static library?

Go To Last Post
5 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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 topic has a solution.
Last Edited: Wed. Aug 14, 2019 - 11:41 AM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

 

"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then." -- John Woods

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

skeeve wrote:

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.

While this may work suppose this is a UART library and so for a mega16 you need to read UDR and for mega328 you need to read UDR0 (at a different address even if you ignored the actual name). So you'd still be faced with your .a needing different builds for different families of micros.

 

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)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Never said it was wise.

If an ISR is involved, a source library is usually a much better idea.

"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then." -- John Woods