A question about Pin Change ISR.

I have a project to control the heater and pump for my swimming pool. I have already had a PCB fabricated and all the hardware works as expected. The code I have so far works also. Currently I'm trying to encapsulate parts of my code related to hardware devices into libraries for future use. I'm using a DS3232 RTC to time heater and pump on and off times and a Blackberry microTrackballer breakout board (from SparkFun) for menu navigation. I have the library for the RTC and the trackballer done and working [separately].

The thing is the trackballer uses PCINT0 and the RTC also uses PCINT0, pins 53 and 52 respectively (on the mega). In the original code the ISR was global and written to check which pin had changed and handle it accordingly. Since the RTC uses 1 interrupt and the trackballer uses 5 interrupts (1 for each direction and 1 for the button press) I have put the ISRs in the new trackball library. I know it would be far simpler to put the RTC on it's own PCINT. However, I've already fab'd the PCB. As it is now with the original code it's not a problem. It's only a problem with the trackball library if I want to use interrupt pins that share the same pin change interrupt. So, my question is:

Is it possible to conditionally substitute the Pin Change ISR in the trackball library. Or better yet, insert (when needed) the extra code to check the additional pin(s) used by other hardware?

I don't understand why an RTC needs an interrupt. It's not as if the heater needs to be controlled with microsecond accuracy. I suspect polling at 10 second intervals would be fine.

...R

Sorry for the late reply, I posted late last night and went to sleep.

The RTC is set to interrupt at 1 second intervals to update the time on a display. Not neccesary, I know. But then I didn't have to continuously read the time from RTC to see if I needed to update the display, I just polled a flag. It seemed to me to be easier to code this way. I'm sure others will disagree, but that's the way I did it and it works.

Anyway, I made the libraries for any future use of the hardware in other projects. Perhaps the trackball and some device(s) other than an RTC. The libraries work, but I'm always thinking of future uses for things, as well as improving my coding skills and technique. I was just asking if this sort of thing was possible.

After reading my OP, it occurred to me, my question aswered itself.

Is it possible to conditionally substitute the Pin Change ISR.

Answer:

#define USE_DEFAULT_ISR 1
#if defined USE_DEFAULT_ISR
/* ISR code here */
#endif

If I want to use a different ISR just comment out the #define. If there's a better method I like to learn. XD

Thanks, DJ

No need to interrupt to drive display updates - such are at human timescales, just poll the pin in loop().

Interrupts are for urgent things (urgent means of the order of milliseconds or microseconds, not seconds).

You are correct. However, it's not the RTC I'm concerned with. The reasoning for my question in the OP was more about a way to have a pin change ISR in a library that could later, if needed, be expanded to use additional pins. The concept could be applied to any library that may need to share a pin change interrupt in the future, regardless of the particular hardware involved.

I like learning and this was more of a coding challange to see if I could do something that I wasn't sure was possible. Once in a while I'll post questions like the one in this thread just for feedback. So people here on this forum, that know more than I, can give me hints, tips, feasability, etc. Or even tell me if what I want to do isn't possible so I don't waste my time trying to do the impossible. Anyway, if anyone knows of a better way to accomplish what I wanted to do, or even just a different to do it (just to learn)...

PS. I thought about making a pin change interrupt library, as I know others have attempted to do. I believe it can be done, but due to the way one ISR can be triggered by multiple pins, it's just too complicated for me at this time.

Thanks again for the replies, DJ