That's pretty much what I did above:

Code:

// ISR glue routines
void Foo::isr0 ()
  {
  instance0_->handleInterrupt (); 
  }  // end of Foo::isr0

I agree. 

I did this before seeing yours. 

Yours is better because it allows more than one instantiation.  Mine is less robust and only handles one instantiation.

My class implements X10 communication on the power-lines.  No reason to have more than one instantiation.

I think that I learned a bit more about C++ by working it out myself, but when I read yours, I saw even a more sophisticated implementation...Thank you.

Doug

Hello and thanks!

The namespace would do the trick, but I like classes because I am more familiar with them (lazy? )

I ended up using an indirect approach.  I did " XClass * object;", then "attachInterrupt(0, myXISR, RISING);", and a  "void myXISR() { object->realISR(); }"

No compile errors, but need to check operation with the debugger (using VM applique on Visual Studio which does some debug capabilities for Arduino).

I would appreciate any comments on this approach.

Doug

[BC]

Hello, this is my first post to 'programming questions'.
I am designing a 'Building Controller' (BC) to be used in my hobby farm out buildings (greenhouse, shop, pole barn, main barn).  They will be networked and use a Raspberry Pi (RPI) with a Gertboard (GB).  The GB does I/O for RPI and contains an ATmega328p.  A major component for the BC is reading and writing X10 control sequences on the power line.  The Arduino X10 library is really for demos only, in that it has long delays that waste all the processing power.  I am writing a class for X10 Tx/Rx using interrupts and no delays so many other tasks run efficiently.  That is the background for my question(s).

I use INT0 to detect zero crossings of the power line and OC0A for timing Rx detection and Tx pulse width out.

Question one: Has anyone done a document on how the interrupts are already utilized by C++ functions like I2C, millisec(), etc.?  I may have to use other interrupts to avoid interfering.  I do not want to interfere with someone also using 'wiring' or other available functions/libraries that use interrupts.  It would take a lot of time to make a list of what is in use, so if someone has done that...Great!  Or I will have to try to find them all.

Question two: I am having problems implementing 'attachInterrupt(0, myISR, RISING);' in the class constructor.  Does that have to do with the fact that I should have one interrupt routine no matter how many times the class is instantiated?  BTW, of course this type of class would only be instantiated once.

Question three:: I want to make this package available to the community when I get it working properly, so I want it self contained in one pair of 'X10i.cpp/X10i.h' files.  It should be instantiated to run the constructor and then used through the public functions.  I could get the interrupts working if I had part of the implementation outside the class, but that is not a good way to give it to others.

Thank you for your time and consideration.
Doug

[Thank you Stanley]

This version does everything I need.  It allows me to specify a 12 MHz clock rate for my project which is a 3.3v ATmega328p which does not support 16 MHz clock.  My project can now proceed.  I just put a scope on my 10 millisecond interrupt and it happens every 10 ms, which proves the code now is using a 12 MHz clock.  Thank you Stanley.  Nice job and thank you for the great tool you have generously provided.

I have read all of this thread and found it very interesting.  I worked on powertrain controllers as a consultant for brands x and y.  They both had a mechanical engineering mind set in the early days and put any old EE on the coding for the controllers.  Glad to say that is no longer the case.  Some went kicking and screaming from absolute assembly to relocatable assembly.  Then the same with going to "C".  And, again for a RTOS.  At this time they are doing model based control algorithms and auto code generation with an RTOS.  There were safety concerns about allowing higher level interrupts interrupt lower level interrupts.  It was believed that circumstances might arise that could not be reliably predicted.  I disagreed, but I was probably wrong.  A friend working at Wind River was involved in the code for the Mars rovers.  You may recall the first rover froze up.  The software locked up.  The problem was task scheduling in the very complex multitasking RTOS.  Luckily, or cleverly, they had some code in the system that recognized how much trouble it was in and went into a mode to accept new code by telemetry.  So, by the time the second rover landed, they had the fix.  I am an old engineer 65+ and age is not the problem, mind set is.  You are either open to new ideas, or not.  I have a hobby farm and I am retired, so my current project is to use a Raspberry Pi(RPI)... (google) and an attached I/O board with an ATmega328p on it.  The ATmega is much more powerful that the first chips we ran the engine with which was (1K RAM, 16K ROM, and 2MHz).  We used a 10msec interrupt to read the tone wheels for RPM and schedule background tasks.  It was a rudimentary O/S for scheduling and accurate sensor reading.  The building security/monitoring/controlling I will do for three out buildings on the property will use a similar rudimentary O/S.  The ATmega is a slave to the RPI on a 115K serial UART channel.  The RPI is a powerful processor with 512K RAM and SD flash ROM (8Gig) with netork connector and two USB connectors.  I will run WiFi on one of the USB ports. The RPI runs Debian Linux and can do an Apache server, if you wish.  The cost is very low.  The RPI is $35 and the Gert I/O board is $48.  I was working on computerized test equipment at Bell Labs when the Intel 4004 and 8008 came out.  We were doing 148 pin circuit board testers and wanted to go to a processor per pin, but the 8008 and 4004 were not fast enough or powerful enough.  We stayed with DEC and Data General minicomputers.  Anyway, this thread was very interesting and I think that the power of the Arduino boards does warrant the use of a periodic interrupt and simple task scheduler for many applications.  I have used the 'MicroC/OS-II' real-time kernel by Jean J. Labrosse, which has been ported to many uPs.  It does a fine job and allows the user to pick features and leave out features to arrive at the proper size and power.  Worked well for me on my greenhouse controller, which reports over the internet.  I have seen another similar featured RTOS called 'freeRTOS'...(google) that costs nothing.  I think it would be useful for some to look at these.  Have fun .