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!

  • What does the vibration signal look like? Is it a one-shot pulse? If so, what is the minimum width?
    – bigjosh
    Jul 7, 2017 at 0:27
  • The vibe switch physically consists of a helical coil of thin, springy wire that bounces against another piece of wire. So presumably its signal is a big bouncy mess that varies with the force and frequency of the vibration impact.
    – Brian Zero
    Jul 7, 2017 at 6:40

2 Answers 2


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.

  • Ah. Thanks. So I'm reading that as 'yes, use the hardware interrupt for your pooshbutton'
    – Brian Zero
    Jul 7, 2017 at 6:48
  • and b) barring that, here are some very interesting techniques that are tantalizingly just beyond your newb level which you will now probably spend countless hours nerding out on. I guess for now I will try to restrict myself to mucking up my beautiful PCB layout to put the button on a different pin. Much appreciated. And good point about the risk of errant button pushing.
    – Brian Zero
    Jul 7, 2017 at 6:54

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.

  • 1
    Read the manual, you are right.
    – Brian Zero
    Jul 7, 2017 at 6:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.