Number of external interrupts for PIC

[ASG]

Hi

I'm working on a project where I've 9 sensors outputting a true/false signal. A PIC microcontroller receives these as inputs to external interrupt pins for handling and triggering other operations. The problem is that I don't know if there's a PIC microcontroller, 8-bit preferably, that has as many external interrupt pins as required. I tried Microchip's parametric search but there's not an option to adjust the number of external interrupts.

What do you suggest?

[Psi]

Do you really need to sample the sensors that fast or will polling the input pins work fine?
Interrupts are really only for time critical things.

[ASG]

You reminded me of polling. Yes, it may work. The problem is that I still don't have a full picture of the logic for the system that I'm working on. I'm building a three-level parking structure like the one in the picture below. Each parking slot has three sensors, an IPS installed at the center of the platform to detect the existence of a car, and two through-beam sensors installed at the edges of the entry and exist point to make sure that the parked car is not crossing the limits of the parking platform. Three sensors per parking slot and three slots make a total of 9 sensors.

I thought that if each sensor has a corresponding external interrupt on the mcu, the program would be easier to write. There could be a method that the 9 sensors share 3 external interrupts, where each interrupt correspond to one type of the three sensors, since the system is designed in such a way that no more than three sensors would change state at a time. However, in this case, the program may be more difficult to write because another method must be devised to decide on which level/platform a given sensor has changed state.

[Mechatrommer]

I thought that if each sensor has a corresponding external interrupt on the mcu, the program would be easier to write.

probably no. your picture is not timing critical. use polling and save your arse and precious time. the mcu can do thousands of check per second and give warning in less than a blink of a eye. if you are thinking sleeping mcu to save battery and then to be woken up by interrupt then you are rational.

[Rerouter]

use some capacitors and some diode logic, so whenever a sensor goes positive it gets coupled by the capacitor, through the diode and hits on the rising edge interrupt,

this is what i would say to look at for the limit sensors on the outside, if a car that is not on the lift level suddenly breaks the sensor i would want the system to make me aware quickly by immediately polling the change

though the other look is that polling is more than fine, and can take less than a microsecond to read in a port register and a pin (9 on an 8 bit micro) the other thing is short of a fault condition (e.g. hand brake not applied and car in neutral) nothing but the level with the lift can be expected to change, so you could well use a de-mux chip to switch between 3 interrupts if you still wished to use them,

[dannyf]

What do you suggest?

Depends on what you mean by "external interrupts".

There are "interrupt" pins (typically 1 - 3 of them). They can be triggered by edges or level.

There are also interrupt-on-change pins (usually 8 of them), or change-notification pins. They can be triggered by edges only.

If that's not enough, you can configure the timers as counters and use their timer / counter input pins. Comparators can do the same as well.

More complicated solutions are possible if the above isn't enough.

[dannyf]

There could be a method that the 9 sensors share 3 external interrupts,

You could OR the error / fault conditions and use that to level-trigger an interrupt. In the isr, you can read all 9 sensors and display which sensors are faulty.

[westfw]

1) It will also depend on which PIC family you're talking about.  PIC16/18 typically has one 8-bit port worth of "port change" interrupts and a couple of "external interrupt" pins, while PIC24 may have ALL of the GPIO pins capable of generating "input change notification" interrupts, for example.
2) pic16/18 will be limited to one or two interrupt vectors regardless of how many pins can interrupt, and you'll have to do some vectoring in software.

[aboodi]

There could be a method that the 9 sensors share 3 external interrupts,

You could OR the error / fault conditions and use that to level-trigger an interrupt. In the isr, you can read all 9 sensors and display which sensors are faulty.

+1

[SL4P]

You could diode-OR the error / fault conditions and use that to level-trigger an interrupt. In the isr, you can read all 9 sensors and display which sensors are faulty.

+1 This is the right way to handle a problem like this.
The only thing you don't get is the weak internal pull-up on the extra pins

[H.O]

There are "interrupt" pins (typically 1 - 3 of them). They can be triggered by edges or level.

I've personally never seen a PIC with a level triggered interrupt, care to enlighten me?

There are also interrupt-on-change pins (usually 8 of them), or change-notification pins. They can be triggered by edges only.

Yes, usually 8 but there's certainly no shortage of device with more than 8. The 16F1829 have 10 IOC capable pins which can be set to trig on rising, falling or both edges and the 16F1716 have 25 - for example.

+1 This is the right way to handle a problem like this.

I agree, IF you don't have a device with enough interrupt pins of course. If you DO have the needed interrupt capabillity why waste 9 diodes when you STILL have to connect all the sensors to individual I/O pins?

Another option could be to use an IO expander chip with interrupt capabillity but again, the most straight forward is probably to just connect the sensors and use IOC.

[22swg]

An MCP23017 would give you 16 programmable interrupts multiplexed to one pin , you would have to read the Registers to see which pin . (I2C or SPI)

[macboy]

You could diode-OR the error / fault conditions and use that to level-trigger an interrupt. In the isr, you can read all 9 sensors and display which sensors are faulty.

+1 This is the right way to handle a problem like this.
The only thing you don't get is the weak internal pull-up on the extra pins

The way you emphasized  the right way  you seem to think this is the only right way. Wrong. There are many good ways to handle the issue of multiple devices needed interrupt servicing, and tying all to a single interrupt input is not always the right way. The main issue with this is the extra time spent, at interrupt level, reading status registers from every single device attached to that interrupt pin, for every interrupt that occurs. This adds processing time, and more importantly, interrupt latency for all attached devices. In my opinion, this is one right way, but it is rarely "the" right way.

[SL4P]

The way you emphasized  the right way  you seem to think this is the only right way. Wrong.

Fair comment / observation - but I didn't say the ONLY way.
In the scope of the OP's original question - I felt it was the cleanest, simplest, most cost-effective way of addressing the problem that the OP was facing.