We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I would like design a c++ class where an interrupt function b.e. EXTI0_IRQHandler is a member. How does it work ?
The interrupt doesn't produce any "this" pointer, so your ISR would have to be a static member. But the question then is where this member would pick up a reference to an object - maybe singleton stored in a global variable.
How does it work ?
In a nutshell: it doesn't.
Interrupts handlers generally need some special treatment compared to ordinary functions (different prologue and epilogue, more saved registers, ...). Member functions also need some special treatment compared to ordinary functions (the "this" pointer, primarily). Problem is, those two special treatments conflict with each other
There is hardly anything at all to be gained from doing that, anyway.
So my suggestion is: forget it.
I'm sure there was an article in one of the comics earlier this year about doing interrupt handlers in C++...
With a Cortex-M3 and a static method, it will work without magic needed.
With a dynamic method, it will not work because of the lacking 'this' pointer. Possible to encapsulate with an assembler routine or by first calling a static member, and pick up a singleton reference for the "this" pointer.
With a "normal" processor, it will not work since most processors requires the ISR to use a special keyword to get correct prologue/epologue for an ISR. Possible to manually hide with an assembler routine that encapsulates the call.
But a static method is basically a function within a namespace, so no need to involve a C++ class.
The biggest danger with C++ is that operator overloading or hidden constructors/destructors can introduce very big penalties even when the code looks very efficient. And an ISR don't want/need excess fat since it both represents CPU load and response latencies.
Here: http://www.keil.com/forum/13850/
The URL given in that thread no longer seems to work.
Instead, try: embedded-systems.com/.../212101526
See also: embedded-systems.com/.../