Interrupts on the ATtiny88

[electrickery]

Based on comments in issue #707 "Interrupt pins on the Attiny88/MH-ET-Tiny88?", I created a minimal sketch demonstrating it works differently from what I expected. Expected was a slow blinking of the LED, and extra blinks each time pin 2 is grounded. What appears to happen is that the interrupt happens continuous resulting in very fast blinking, keeping the LED (apparantly) permanent on. But even shorting pin 2 does not stop the interrupts.

Another observation is that the slow blink rate (tested in an other variant of the sketch) is way faster than the defined 1000 ms, probably making the ATtiny88 (no real clock) less suitable for timing dependent applications.

Greetings,

Fred Jan

// ATtiny88 interrupt test - Using interrupts with the ATtiny88

// Code extracted from the rs-switch library
// Minimal sketch that should allow control
// of a LED via an interrupt routine.

// Code compiled with Arduino IDE 1.8.189 and 
// ATTinyCore-2.0.0 installed (from zip), 
// exported (Sketch > Export Compiled Binary)
// and programmed using 
// avrdude -c avrisp2 -P usb -p t88 -Uflash:w:'.../sketchbook/tiny88IntTest/tiny88IntTest.ino.attiny88.mhet.8mc0..hex'

#define INT      0
#define INTPIN   2

#define LED      0

int nReceiverInterrupt;
#define RECEIVE_ATTR

void setup() {
    pinMode(LED, OUTPUT);

    pinMode(INTPIN, INPUT_PULLUP);
    attachInterrupt(INT, handleInterrupt, CHANGE);
}

void loop() {
    digitalWrite(LED, !digitalRead(LED));
    delay(1000L);
}

void RECEIVE_ATTR handleInterrupt() {
  digitalWrite(LED, !digitalRead(LED));
}

[SpenceKonde]

Do you by any chance have it plugged into your computer?

PD2 is connected to the USB pins. If you plug it into your computer, it will hear constant chatter on pins D1 and D2. D2 was chosen by the creators of the MHET tiny88 precisely for getting hold of the top priority interrupt, INT0, to minimize the dysfunction in their VUSB code (we don't support VUSB use from within the sketch as part of the core - my tests were pretty disappointing. Even the few sketches I got to compile wouldn't work right. One pretending to be a mouse actually crashed my laptop (IIRC it bluescreened shortly after unplugging the device - when plugged in, the mouse slammed into the sides of the screen immediately.))

Plug it into a phone charger or power bank or something, or (if you have them on hand (but who doesn't?) a microusb port breakout with just +5v and Gnd connected, or even use a charging only cable....

The VUSB boards all use INT0 as a USB pin in order to attempt to make interrupt based vusb work, but I think it is a lost cause, just from counting clock cycles, you have a very narrow window in which to respond, and there;s a delay as you enter the interrupt. And, of course, since these can't have a priority interrupt if you have other interrupts for things like timekeeping, they'll cause you to miss response time requirements. But I think you could reenable interrupts inside an ISR on classic, so that might be a way to yield to INT0 which is always the priority if usb is to work. The digispark people worked really hard on this, and the results are disappointing.

VUSB seems to be good only for the bootloader.

But anyway, my point is, you should avoid using pins PD1 and PD2 if it will be connected to a computer, because those are the USB lines, as inputs they'll see constant chatter and as outputs they will disappear from USB. Remember to say thanks to the semiconductor gods that the chip has an INT1.

[SpenceKonde]

Closing issue; observed behavior is expected when MHET t88 board is plugged into USB port of a computer. Workaround: Use INT1. Avoid PD1, PD2. Will amend the part specific documentation for micronucleus boards to highlight this fact,

[electrickery]

Hi Spence, Thanks for your response. It could be I used the USB hub to power the AT88 board, but indeed when powered from a charger blinking is like it is in the variant sketch (using no interrupts). Greetings, Fred Jan