Hello,
has anybody expierienced with the Realview Compiler (ARM) and C++ interrupt programming? How can I call an non static method as a interrupt handler? I use ATMEL AT91SAM7 controllers. It's not easy if one has just started to learn C++ at all ... (the reviews I found haven't helped me much).
Interrupt programming really has nothing to do with C++ - actually, C++ is not a factor in it whatsoever. use standard C or assembly for that, and refer to your compiler's data sheet to see how. by the way, I hope you are aware of the intricacies involved in using C++, especially on microcontrollers...?
Make a static ISR and call the non-static method from within that ISR. That's why I don't like C++: a whole new level of abstraction, a whole new lot of unnecessary choices, and plenty of new ways to shoot yourself in the foot. But I guess it has its uses...
How can I call an non static method as a interrupt handler?
Do you have to use a method as an interrupt handler? Won't a plain function do?
PROGRAMMING POINTERS by Dan Saks:
Better even at the lowest levels
"Why might you prefer to write low-level code in C++ rather than in C? You've got much to gain and little or nothing to lose."
newsletter.embedded.com/.../eBOEV0GgTyU0FrY0G2xS0EC
Andy, I read the article. My personal opinion is that the risks that are introduced into software by using C++ are far greater than the mild benefits of stripped embedded C++. Yes, sometimes I'm DIEING to able to inherit, but for me, in comes down to the following: writing correct C++ code is far more challenging that writing C code. performance might be more of less the same (given a good compiler and some size trade-offs) but still - I would not use it for really low-level software.
Why might you prefer to write low-level code in C++ rather than in C? You've got much to gain and little or nothing to lose.
Thank you for the link, but I'll stick to C :-) There is actually a lot to loose: C++ is much harder to learn and use. And the only real-world example in the article is not convincing at all...
No extra trouble to get C++ to work. It is a quite straight-forward language as long as you don't spend too much time digging yourself down with multiple base classes with or without virtual base classes.
But operator-overriden C++ can result in a few nice trivial lines of code that actually consuming huge amounts of CPU time because the operator overloading isn't obvious.
Because of this, great care should be used in interrupt service routines. They are intended to be fast, to let the next interrupt also be serviced quickly.
The processor interrupt can never enter an object method since the processor only knows how to call a specific address. But an ISR can make use of a global variable to call a non-static method.
But if you have a single global object that your ISR is calling one method in, then you can think about having a single function and a number of variables directly inside a namespace. It will also encapsulate the symbols and except for no overloading will be quite similar to a singleton object. And that encapsulated function can be specified as an ISR directly, instead of requiring an extra function call.
Per, A very informative post. I only want to add that some implicit, innocent mistakes can have, as you stated, a large impact on performance/correctness: * implicit type conversions can lead to unexpected program behavior. if somebody adds a type conversion/constructor to a class without you knowing about it, it might introduce program stability issues/invalidate correctness. * using arrays polymorphically will destroy and program. * ...
But isn't that also true of ANSI 'C'...?