RE: [avr-gcc-list] How to handle interrupt vectors ?

[Ron Kreymborg]

> > Yes i have seen the code for the ISR and i have no understanding of
> > the mechanism because i don't know what that vector is.
> 
> I have already explained you that, and you can take my word that you
> don't stand a chance using the existing gcrt1.S file.  That's not to
> say it could not be done at all, but you'd have to start over from
> scratch, writing your own C run-time startup code in a different way
> than the existing code is done.
> 
> You could perhaps seek up some old (maybe about 4 years old)
> suggestion from Marek Michalkiewicz about what changes would be needed
> in order to allow for arbitrarily-named interrupt vectors.  Offhand, I
> can't tell you though whether it has been discussed here on
> avr-gcc-list, or on avr-libc-dev instead.
> 
> --
> cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

I did some work on Marek's suggestions back in March/April but alas did not
carry it through. The patch provided for an optional numeric argument to the
"signal" attribute. An interrupt function prototype using this system would
look like:

void IntName(void) __attribute__ ((signal(4), __INTR_ATTRS));

The signal argument is used to name the interrupt function for later linking
by directly inserting the following two (example) lines into the assembly
output:

      .global __vector_4
      __vector_4:

The given name is still processed according to the language rules. The 
name is thus independent of the vector number, but the number is attached to
the name because for C++ the given name is already mangled by the time the
signal argument is being processed. You could thus define an interrupt class
as a friend to the class that was managing the peripheral(s) associated with
the interrupting device, and everything associated with the interrupt was
private to the owning class.

All very correct and academic and it would be a nice feature to have, but I
have gone back to my original method of handling interrupt vectors in C++.
An example would be:

ISR(TIMER0_OVF_vect)
{
    Clock.OverflowInterrupt();
}

Ie the interrupt stands alone outside the Clock class, but the public method
OverflowInterrupt handles the overflow consequences from within the class.
This would be my suggestion for Charalampos.

Ron