[avr-gcc-list] avr-c++ can I use templates to avoid creating unnecessary ISRs?

[Robert J Lee]

I'm working on a library using avr-gcc (I'm working with an Arduino, but
I think the library should be of more general use).

The problem is that the library may be used with any one (or more) of
the timer interrupts on the AVR. I want to avoid creating timer ISRs
that are never used; I need the unused timers elsewhere in my program. I
currently use only one ISR for this library, but I'd much rather have a
general solution rather than forcing it to use an arbitrary ISR (which
may clash with other libraries in future).

What I really want to do is to use a C++ function template, and only if
the template is instantiated, to then create an associated timer ISR.

eg (in c++-like pseudocode:)

template <int timerId>
void function setTimer(/*ARGS*/) {
   /*set up timer interrupt registers*/
   struct timer {
     ISR(TIMER##timerId##COMPA_vect) {   // DOES NOT WORK
        /*do timer action*/
     }
   }
}

The use of ## for string concatenation here is illegal (it's not a
#define); template specialisation could be used instead to avoid that
problem.

A bigger issue is that ISR() is a macro that defines a function (named
eg TIMER1COMPA_vect) with special decorators and C-linkage, and
according to the manual, the exact name of the function tells the
compiler which interrupt to service. Because of the C linkage
requirement, I can't use a function template even if I could somehow
manipulate it to have a name that the compiler would recognise (which
would probably involve moving it out of the template function).

Is there a way to achieve this, possibly some compile-time option to add
c++-mangled names to the compiler's vector name lookup table? If not, is
there another solution to the problem?


In the worst case I would have to do something like this:

#define USE_TIMER(id) \
ISR(TIMER##id##COMPA_vect) { \
  handleInterrupt<id>(); \
}

and have the user explicitly ask for the timers they want to use by
calling USE_TIMER repeatedly. (Which makes it *really* hard to
programatically assign timer IDs....)

Any help or pointers would be much appreciated.

Robert Lee.