> > > > Hi Robert, just a thought... > > > > If the user wanted to programatically assign ISR's to either your library > > handleInterrupt<id>() functions, or their own functions, then maybe the > > main application should contain ISR()'s which call function pointers? > > > > The function pointers could then be loaded with either the address of your > > library functions, or the users own functions. > > > > That could work... Those are typically called "callback" functions. Note that > there is a tradeoff with doing that: Because a function will be called in an > ISR, the ISR prologue and epilogue will be bloated out because of having to > save/restore a lot of registers. Just a warning. >
I'm writing libraries, so I'm hoping to find something that will work in the general case. This idea should work, and I suppose the pointer may be a compile-time constant making it reasonably efficient in most cases. One problem would be that there would be no way to differentiate between an ISR that was used and one that wasn't - so you would generate ISR functions that do nothing (ie that doesn't call a null function pointer) in the case where none or not all ISRs are used. I'm intrigued by Eric's point about extra code being generated. I thought the prologue and epilogue would be generated anyway, but maybe the optimiser is taking out code to context-switch registers that aren't clobbered? In which case, it would seem simpler overall to just change the compiler (or linker?) to add some new C++-mangled names to the table. I'm mostly looking at the Arduino libraries, which seem to take the attitude of registering as many interrupts as they think they might need in the .c or .cpp file for the library, and just hoping that there isn't a name clash anywhere after the used libraries are linked it (which there inevitably is). Using a function pointer is definitely an improvement on that, so I shall try and start there. Robert Lee. PS Sorry for double-mailing yesterday; my first email didn't show in the archive several hours later and I thought it was a configuration problem on my end so I sent it again. _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
