Avoid creating multiple ISR for similar sensors

Projects General Guidance
1

Hi everyone. I am currently trying to understand interrupts and ISRs, and I have a question.

Let's say I have multiple sensors that need to be checked for a certain condition (FALLING). All the sensors are similar, but they can fall at different times and different conditions need to be checked when they do.

Since ISRs do not accept arguments, I am thinking that you have to create an ISR for each sensor, like:

const unsigned int SENSOR_INS[] = { A1, A2, A3, A4, A5 };
volatile unsigned int SENSOR_STATES[] = { 0, 0, 0, 0, 0 };
const unsigned int SENSOR_INTERRUPTS[] = { 0, 1, 2, 3, 7 };  // Arduino Leonardo.

const unsigned int SENSOR_N = sizeof(SENSOR_INS) / sizeof(SENSOR_INS[0]);

void setup() {
  for (unsigned int i = 0; i < SENSOR_N; i++) {
    pinMode(SENSOR_INS[i], INPUT);
  }
  attachInterrupt(digitalPinToInterrupt(SENSOR_INTERRUPTS[0]), ISR0, FALLING);
  attachInterrupt(digitalPinToInterrupt(SENSOR_INTERRUPTS[1]), ISR1, FALLING);
  attachInterrupt(digitalPinToInterrupt(SENSOR_INTERRUPTS[2]), ISR2, FALLING);
  attachInterrupt(digitalPinToInterrupt(SENSOR_INTERRUPTS[3]), ISR3, FALLING);
  attachInterrupt(digitalPinToInterrupt(SENSOR_INTERRUPTS[4]), ISR4, FALLING);
}

void loop() {
  // Whatever
}

void ISR0 () {
  SENSOR_STATES [0] = 1;
}

void ISR1 () {
  SENSOR_STATES [1] = 1;
}

void ISR2 () {
  SENSOR_STATES [2] = 1;
}

void ISR3 () {
  SENSOR_STATES [3] = 1;
}

void ISR4 () {
  SENSOR_STATES [4] = 1;
}

Is there an easier way to do this? To avoid creating a function for each sensor, and to avoid having to set each sensor's interrupt pin individually?

Thanks for any help you can provide.

2

do you have enough external interrupts for that? a UNO would have only 2 (pin 2 and 3) for example.

if your arduino supports this, you could use a pinChange interrupt on a whole PORT. then in the code of the ISR you'd look at what has changed since last time and find which sensor(s) got triggered

3

I think that you should think first whether using interrupts for your use case is appropriate or whether you could poll the sensors instead.

I would consider that as part of understanding interrupts

1 Like
4

You really have to be more specific and explicit in what you want. Nothing sensible can be said about this other than "I'll take your word for it".

5

Yes, in the comment I clarified I'm using an Arduino Leonardo.

How would you do that? I've never done it.

It is beside the point. I am trying to understand if there is any way to reduce the number of functions and declarations if this was the case.

6

Your favorite search engine will find tutorials on using pin change interrupts with Arduinos.

7

something like this

// global data
volatile uint8_t previousPinStates = 0;
volatile uint8_t changedPins = 0;

// PinChange interrupt service routine
ISR(PCINT2_vect) {
  // Read the current states of all pins in group (PD7:0)
  uint8_t currentPinStates = PIND;

  // Calculate the changed pins
  changedPins = currentPinStates ^ previousPinStates;

  // Update the previous pin states
  previousPinStates = currentPinStates;
}

if the loop() you could have something like

  noInterrupts();
  uint8_t changedPinsCopy = changedPins;
  changedPins = 0;
  interrupts(),
  if (changedPinsCopy != 0) {
    // something changed find the bits set to 1 will tell you which one flipped

 }

(typed here, fully untested)

1 Like
8

Ok, after doing some research as jremington suggested, I believe we have changed topics.

I was initially asking about regular hardware interruptions, and not pin change interruptions. If I need to detect a falling signal, it would be much simpler to used INT instead of the PCINT suggested here.

As I understand it, the using PCINT would only benefit me by augmenting the amount of pins that I can use for interruptions, but it really does not simplify declaration nor does it reduce the amount of functions I have to create.

Am I interpreting things correctly? I am very new to this PCINT concept, so I may be way off.

9

hum, you would only need one function that checks which pins have changed

but yes, it's not the same as an external interrupt dedicated to one pin.

1 Like
10

Maybe - maybe not. Even if it is possible, it may make sense to not reduce the number of functions and declarations for reasons of faster code, more readable code, more efficient programming, etc.

It will for a large part depend on the actual situation. What sensor, what do you have to do when there's an interrupt, how to tell them apart, are they all the same or different sensors, etc.

11

I do understand this, but what I am trying to reduce is the amount of functions needed to handle said interruptions. In other words, if I have 5 interrupt pins, I must declare 5 IRSs and set each interrupt pin manually (as opposed to, for example, setting 5 pins as INPUT using the for loop and an array), and using a signle IRS wich parameter as you would a simple function.

I am not 100% sure, but I think that using PCINTs does not differ from INTs in this regard.

I do not think that having 5 functions doing the same thing would be efficient programming, since any change in the IRS must be made X amount of times depending on the number of INTs that you have.

12

Then have those ISRs call a function with appropriate parameter so your generic handler knows which one it is that called (just keep in mind to keep those functions short as you're still in the ISR).

1 Like
13

Did you read @J-M-L's #7?

It looks plausible, I can test it from under the umbrella here.

The only problem I can anticipate is missing some pin changes, not sure, but a fix for that woukd be to have the ISR only be able to set bits in a byte indicating activity on the corresponding pins, then…

...in the loop, observe those set bits, handle them however you need and also acknowledge having done by clearing the bit for a pin that changes and you've done handing.

a7

14

Usually an interrupt means something has to be taken care of, but you have never disclosed what that something might be. Do you need to read from a register in that sensor or what? If so, that could be a single function with the address of the device passed to a single function.

15

That is a good idea, but I would still have to declare all 5 ISRs manually and also set all 5 pins to handle interrupts individually, unlike normal pins.

This sounds like I am complaining, I'm not, I am simply trying to understand if this is possible or if I am forced to keep doing this manually and individually for each pin and ISR.

Yes, but as I understand it, #7 is simply describing how to set up a PCINT and find which pin suffered a change. There is nothing in there about initialization and unification of the ISRs.

There is nothing in particular. In my code I am simply testing the functionality, I have 5 sensors, and 5 ISRs, each ISR is called when the signal drops and the state of each sensor is set to one, simulating a real action.

I'm just trying to gain a deeper understanding of interrupts.

16

You gain that by testing your program. What scheme do you have to test your program using any type of interrupt?

17

There is only one ISR. Through it we calculate which pins changed causing the interrupt.

Regular code sees which if any pins have changed since last time it looked, and does whatever needs doing.

As mentioned, a function taking an argument saying some certain pin had been the cause of an interrupt would serve for them all.

a7

18

you could decide to either walk through the bits set to 1 in changedPins within the interrupt context to call your unique function which would take then a PIN number argument, solving your initial issue

that function would be executed still in the initial ISR context and thus you would not get other interrupts and it will be dealt with 'just in time'

alternatively as I mentioned, you could pick up the changedPins within the loop and deal with them in the main application context, outside interrupts.

1 Like
19

OK! I guess I need to analyze the code in more detail since that was not how I interpreted it.

Thanks!

20

you might want to add a bit of business logic as you only want a FALLING trigger and I capture the CHANGE. So you might require to maintain the previous state and check if the change pertains to a falling pulse or rising pulse before calling your function

1 Like