Interrupt pins

[scott216]

On the digispark, which pins can be used as interrupts?

[semicolo]

Each pin has pin change interrupt capability.

[Bluebie]

And pin 0 has Interrupt 0 support, so it can trigger on rising, falling, or change, and with slightly lower latency than pin change interrupt which works on all pins. The issue with INT0 is that it is higher priority than the pinchange interrupt used for the USB stack, so if you use USB with your digispark, using INT0 can sometimes interfere with the connection. It's okay if you make sure the interrupt doesn't fire too often, but, like, if you hooked up a button without a hardware debounce circuit, that would make it disconnect because the bounce would be very rapid and consume a lot of CPU time, causing the USB library (digiusb, digikeyboard, or whatever) to be too slow to respond to the host computer.

[scott216]

I want to use the interrupt with an rotary encoder.  I don't care about direction, so I only need one interrupt pin instead of two that you'd normally use with a rotary encoder.

[scott216]

I also need 3 PWM pins for and an RGB LED so I have to use pins 0,1,4 for this.  I was going to use pin 2 for the encoder.

Normally I would create the interrupt like this:
attachInterrupt(0, myInterruptFunction, CHANGE);

But this sets interrupt 0 on Pin 0.  What do I need to do to set an interrupt on Pin 2?

[aartek]

I'd like to bump this topic and ask the same thing as scott216.

"What do I need to do to set an interrupt on Pin 2?"

[PeterF]

Just checking... are you *sure* it is setting an interrupt on P0? P2 should be the pin with INT0, so attachInterrupt(0, myInterruptFunction, CHANGE); should be mapping to P2... just checking!

You can only use attachInterrupt for the hardware interrupt pins... which the Digispark/ATTiny85 has exactly 1 of, which should be on P2 (AKA PB2).

Your only other option is to look at pin change interrupts... which all the I/O pins support, but aren't as fast or accurate as the hardware interrupt, and have the the complication that you actually need to work out which pin fired if using more than one :-/ Unfortunately, I don't know of any easily digestable guides or libraries that help with that for the digispark/attiny85...

[aartek]

in `attachInterrupt(0, myInterruptFunction, CHANGE);` what 0 means? INT0 or P0?

Im curious because on my board with button connected to P2, attachInterrupt(0, myInterruptFunction, CHANGE) works, but attachInterrupt(2, myInterruptFunction, CHANGE); doesn't work.

I can also confirm there is a problem with USB connection. I have to disconnect cables to upload the program.

[PeterF]

The number specified in attachInterrupt is the interrupt number, so INT0. This is also the source of the confusion re: AnalogRead numbering... it's the ADC pin number, not the ATTiny85 pin number, that you need to specify.

And I'm not sure what you mean by a problem with the USB connection... it is normal to only be able to program the Digispark for 5 seconds after plugging it in... hence the prompt when uploading to "connect the digispark now" (or some similar wording).

[aartek]

Thanks for clarification.

By a problem with the USB connection I mean that what Bluebie said.

The issue with INT0 is that it is higher priority than the pinchange interrupt used for the USB stack, so if you use USB with your digispark, using INT0 can sometimes interfere with the connection. It's okay if you make sure the interrupt doesn't fire too often, but, like, if you hooked up a button without a hardware debounce circuit, that would make it disconnect because the bounce would be very rapid and consume a lot of CPU time, causing the USB library (digiusb, digikeyboard, or whatever) to be too slow to respond to the host computer.

I just confirm that when button is connected to PB2 (INT0), there are problems with uploading program.

[PeterF]

Hm... that's strange... what I think Bluebie was referring to was that because the interrupts would mess up the timing of the emulated USB stack, that if you used the hardware interrupt (INT0) in a program that used the digiusb communications stuff, or keyboard/mouse emulation, you could have problems. AFAIK it shouldn't cause any issues for the upload, as the bootloader should have total control for the first five seconds, and then your program start, and things could be flaky after that.