Attaching multiple interrupts on Teensy LC

Status
Not open for further replies.

emseedee

Member
I have a simple project to manage the watering system in my greenhouse. I want the system to reset every time any one of a number of conditions occurs: Water level low, reset button pressed, etc, etc.

My code includes
Code:
attachInterrupt(digitalPinToInterrupt(reset_switch),rst_ISR, FALLING);  // catch reset switch event
attachInterrupt(digitalPinToInterrupt(prime_switch),rst_ISR, CHANGE);   // catch prime switch event
attachInterrupt(digitalPinToInterrupt(empty_switch),rst_ISR, CHANGE);   // catch change in empty switch 
attachInterrupt(digitalPinToInterrupt(disp_present),rst_ISR, CHANGE);   // catch display being plugged in or removed

And the ISR is:

Code:
void rst_ISR() 

 /* 
  *  Perform a software reset when the reset button is pressed or empty switch changes state
  */
  {
  SCB_AIRCR = 0x05FA0004;
}

It seems that only the last attachInterupt instruction is working - the system doesn't reset on any of the other events.

Is this normal behaviour - does each attachInterrupt overwrite previous ones?

Thanks

Mike
 
The pin numbers are not provided.
Looking at reverse of Teensy_LC card some pins do not have INT capability.
Is it always the case only the last works if the lines are re-ordered?
 
Use a separate interrupt routine for each event. Create a global variable, isrID, and make each ISR set the variable to it's appropriate ID, 1-4. In loop(), check that byte in a switch statement and service the active interrupt. Reset the byte to zero to show nothing is waiting for action.
 
Thanks for your response defragster. I hadn't realised that - duh - and yes, the three pins that don't get a response are 17, 18 & 19, which aren't shown as having INT capability.

Time to get the soldering iron out again.

Trouble is, although it's quite justified to say RTFM, the (fine) manual is so big it's easy to miss quite important things. That's why I love this forum.

Keep safe.

Mike
 
Use a separate interrupt routine for each event. Create a global variable, isrID, and make each ISR set the variable to it's appropriate ID, 1-4. In loop(), check that byte in a switch statement and service the active interrupt. Reset the byte to zero to show nothing is waiting for action.

I can see the logic behind doing that, but in reality there is virtually no chance of a clash of interrupt events, and even if that does occur, it doesn't really matter.

I think defragster has hit the nail on the head with his suggestion.

Thanks anyway - I appreciate that you replied

Mike
 
Thanks for your response defragster. I hadn't realised that - duh - and yes, the three pins that don't get a response are 17, 18 & 19, which aren't shown as having INT capability.

Time to get the soldering iron out again.

Trouble is, although it's quite justified to say RTFM, the (fine) manual is so big it's easy to miss quite important things. That's why I love this forum.

Keep safe.

Mike

Thanks go to @MichaelMeissner! He made a point of this in recent days on another post. Have the T_LC here … but with T_3.6 and T_4 focus it is easy to forget relevant details that are presented on the PJRC CARD {PDF}.

Even the web page pjrc.com/teensy/teensyLC.html fails to call that out as the CARD does. And this summary page pjrc.com/teensy/techspecs.html only 'technically notes' the T_LC has 27 digital I/O with 18 interrupts.
 
If the ISR for each event does the same thing then OR the interrupting signals together with a pull-down through 1N4148 diodes to a single input.
 
Status
Not open for further replies.
Back
Top