ATtiny85 soft-latching, and sensor-waking: Are multiple switches differentiable by pin change interrupt?

Question

I am using a vibration switch with a pin change interrupt on an ATTiny85 to wake the processor and run some code when the vibration switch grounds an input pin. The circuit is battery-powered, so sleep mode is important. I would now like to add another input switch (momentary pushbutton) between an internal pullup on the ATtiny and ground to use as a soft latching switch to accomplish on/mode/off (power-on/case-selection/power-off). I'd like the vibration-wake-sleep code to be one of the cases selectable by the pushbutton. The ATtiny85 has one hardware interrupt (pin2 aka INT0), and the rest are pin change interrupts available on the other I/O pins. After reading around, my understanding is that the pin change interrupts cannot be separated to run pin-specific code, as they all trigger the same pin change interrupt effect. Is that correct? To put it another way, do I need to put my pushbutton on the hardware interrupt pin, or can I put it on any old I/O pin and still be able to use the vibration switch on another I/O pin only when I select that mode, without it triggering the same effect as the pushbutton every time there's a vibration? Or is there a better way? I'm trying to minimize the number of components, as this is a space-constrained project. Thanks!

Answer 1

If you have one dedicated interrupt signal, and enable the shared pin change interupt for only one pin, then you have no ambiguity - the hardware ISR is caused by the dedicated pin, and the shared pin change ISR is caused by the only enabled pin change pin.

Where things get more complicated is if you enable more than one pin to trigger the pin-change interrupt. In this case, either the ISR or whatever follows in cause from it will need to figure out which pin caused the interrupt.

Unless I'm overlooking it in the data sheet, the ATtiny pin change interrupts don't have a register which latches the causing condition, so you may have to look at the actual pin input register. The catch is that things like contact bounce might make the causing signal no longer present at the exact instant you check it. However, contact bounce is typically a more serious problem when releasing a contact than closing it.

Some things you can do:

• In the ISR, don't actually do anything, but set an "interrupt happened" flag. Then in the main program, poll the inputs for a while until you see one actually asserted, and act on that. You should only need to stay awake for a small fraction of a second before you catch the responsible contacts closed when you are looking.

• You could try to use a small capacitor to slow the rate at which the pullup resistor responds to the switch bouncing back open, in the hopes of making sure that the causing condition is seen when the ISR itself looks.

In either case you will probably want to stay awake and keep the pin change interrupt disabled until the switch has been released, and for maybe a hundred milliseconds thereafter to let release bounces die out. Then you can re-enable the interrupt and go back to sleep.

Do keep in mind that regardless if the MCU is awake or not, if someone wedges the product into packing material or something which holds the switch closed in opposition to the pullup resistor, then that pullup resistor itself may drain your battery over a few weeks/months.

Answer 2

Or is there a better way?

Read the data sheet to see if it has individual flags for those pins.

Short of that, read and keep track of the pin states in the use to see which pins may have changed.