I am trying to write a C++ class which encapsulates an interrupt driven timeout timer.
I have the class semantics and timeout functionality working just fine.
Where I am stuck, is at trying to encapsulate the ISR macro definition within the class itself.
I am stuck as in, don't really know where to begin with it.
So, given the code snippet below, what I am aiming to do is
Make the ISR definition a method of the tTimer object (class).
Avoid having to create the global instance, timer.
Make the tTimer.inc() function private.
Any helpful suggestions are appreciated.
//global instance of the timeout object
tTimer timer;
//timer interrupt vector
ISR(TIMER2_OVF_vect) {
//increment overflow count
timer.inc();
//disable timer when expired
if (timer.expired()) {
cli();
TIMSK2 = (0 << TOIE2);
TCCR2B = 0;
sei();
};
}
So, given the code snippet below, what I am aiming to do is
Make the ISR definition a method of the tTimer object (class).
That won't happen. The interrupt mechanism calls a function, not a method. The mechanism would have no idea which instance of the class you wanted the method called for.
Once you accept that, nothing else you want to do makes sense.
Think of it this way: the interrupt routine runs with no context other than global variables
(because it can be called at any time) - any instance you might want to associate with the
ISR must therefore live in a global variable.
I think that what you'd need to do is write a plain old conventional interrupt handler function which invoked a static method of your 'timer' class. If you want to notify instances of this class then you'd need to have a scheme for the instances to be registered statically with the class, for example with a static array of pointers or linked list in the class, such that the static method could invoke an instance method for each instance.
The code involved would not be especially difficult, but you'd need to be wary about how long the interrupt handler would take to go through this dispatch mechanism and invoke an unknown number of instance methods doing who-knows-what. Also you would need to deal with any application design issues involved in invoking instance methods within an interrupt - if you're calling out to user code then you need to make it clear that the code needs to be written so that it is safe to be called in an interrupt context. Since you're effectively hiding that interruptness in your timer class, it would be ever so easy to forget that and use it to invoke code that directly or indirectly did unsafe things.
My overall reaction to this approach is that the sort of functional complexity/flexibility which would justify this amount of code is not something that should be done in an interrupt.