I'm working on a project that needs at least 17 external interrupts. I've been using an Arduino Due, which has been working great, but as we continue development, I don't want to base everything on a retired board.
I've been looking into the Arduino Zero, which claims to have all pins interrupt-able (except 4), but seeing people actually test it I've seen a maximum of 15 being usable.
We are also using a Raspberry Pi, but researching into that it doesn't look like it can handle external interrupts without messing with the Linux OS.
Any suggestions of IC's or Microcontrollers that can be used to handle multiple interrupts?
For context, these interrupts are from photodiodes that are being hit by a spinning laser. The laser may only hit the diode for a few (1-10) microseconds, so it needs to be fast, unless I can get a very fast polling going.
If you use a port expander like the MCP23S17 each of the 16 pins can be latched on a pin change. This is fed to an "interrupt" output which can be polled or used to trigger an interrupt. Then you only need look at the chip's registers when you know something has changed.
We originally had an idea for a basic pulse stretcher by putting a capacitor with the diode, so the signal would slowly decay rather than just spark for a second.
The MCP23S17 looks good, but that would require a hardware change. We could go that direction, but I'd rather explore options with what we have first. I'd rather drop to 15 pins on the Zero and deal with a slightly smaller sensor.
What is the chip that handles interrupts? I know that the AVR chip has a few dedicated pins, but how does the Due handle so many? I know that it has a dedicated interrupt processor, but what is it?
Robin2:
Does that mean you are excluding pin-change interrupts? If so, why?
...R
I didn't know they existed, so that's why to start
Looking into them now, the downside would be you're limited to only 3 interrupt routines, I need each diode to be unique. I might be able to use the pin change to trigger a small poll (so whenever a change is detected, is scans the ~6 diodes corresponding to that port, rather then all 17).
The rising and falling double trigger may cause issues as well, though I could make a flag that sets and clears so even if it's trigger up and down, it only runs the routine once.
Xyver:
the downside would be you're limited to only 3 interrupt routines,
I think I would consider that an upside - less code and less room for silly errors.
In any case I would have very little code in my ISR and I would do as much of the calculation as possible in the main body of my code so as to make the time in the ISR as short as possible.
Robin2:
I think I would consider that an upside - less code and less room for silly errors.
In any case I would have very little code in my ISR and I would do as much of the calculation as possible in the main body of my code so as to make the time in the ISR as short as possible.
...R
The ISR is really small. All it is is:
diodehit = X;
Where X is whatever number (1-17) corresponds to the diode.
DrDiettrich:
Why interrupts? What will your code do when a change is detected?
How frequently do the inputs change (interrupt rate)?
The laser is spinning at a max of 600 RPM, so 10 hits per second. 2 lasers, so potentially 20 interrupts per second.
The lasers tell which diode was hit, then that value is sent to a base station (using wire library, but we're working on wireless)where more calculations are done.
Xyver:
For context, these interrupts are from photodiodes that are being hit by a spinning laser. The laser may only hit the diode for a few (1-10) microseconds, so it needs to be fast, unless I can get a very fast polling going.
Thank you for your time
Can you say what you are trying to do ?
It may be that a hardware approach is appropriate .
Are the laser movements synchronized, or can two hits occur at the same time? Does the exact sequence of such hits matter?
With an average rate of 20 hits per second I'd go with the MCP23S17. No hits will be missed, and the data transfer from the chip to the controller is fast enough. Interrupts can be used, so that the controller still can do something else.
Looking into them now, the downside would be you're limited to only 3 interrupt routines
Yes but with a very small amount of software in the ISR you can work out what pin caused the interrupt and take the appropriate action. That is what software is for.
