I have a short program which should receive data, use this data to turn on/off an LED, and send data when a button is pressed. It is deployed on a Digispark board. The button is connected to INT0 port (PB2). The interrupt works, but data is not send. Receiving data works fine.

What am I missing here?

#include <SoftSerial.h>

#define RxD 1
#define TxD 0
#define out 3
#define btn 2
#define testled 4

SoftSerial blueToothSerial(RxD, TxD); //RX, TX
volatile int buttonState = 0;

void setup() {
  pinMode(out, OUTPUT);
  pinMode(btn, INPUT);
  pinMode(testled, OUTPUT);
  digitalWrite(out, HIGH);
  digitalWrite(testled, HIGH);
  attachInterrupt(0, intrpt, CHANGE);

void loop() {    
  char newVal;
    newVal = blueToothSerial.read();
    if (newVal == '1') {
      digitalWrite(out, HIGH);
    } else {
      digitalWrite(out, LOW);

void intrpt() {
  buttonState = digitalRead(btn);
  if (buttonState == HIGH) {
    // turn LED on:
    digitalWrite(testled, HIGH);
  } else {
    // turn LED off:
    digitalWrite(testled, LOW);

void setupBlueToothConnection() {
  blueToothSerial.print("bluetooth connected!\n");    


Serial data is sent fine. The above code works. On Windows I can see the data are coming, but not on OS X.

  • it appears your interrupt would trigger itself, it that intended?
    – dandavis
    Mar 27, 2017 at 17:22
  • Which board are you using here?
    – Majenko
    Mar 27, 2017 at 17:23
  • @Majenko Digispark with attiny85 i.imgur.com/LT4szAd.png
    – akn
    Mar 27, 2017 at 18:18
  • @Dandavis it triggers itself because of lack of debouncing, but shouldn't it send data even if it's unintentionally triggered?
    – akn
    Mar 27, 2017 at 18:18
  • no, i mean you println() on the TX pin, which changes its hi/low state, triggering the interrupt. TX==0
    – dandavis
    Mar 27, 2017 at 18:19

1 Answer 1


If you are handling interrupts then you need to keep the code as quick and simple as possible. I suspect that in this case calling blueToothSerial.println is what's causing the problem. It may well be calling an operation that an ISR can't call and so it fails and your code doesn't write the data you expect it to.

All I ever do in ISRs is set flags and then get the 'normal' code to handle changes to the flags. Personally I wouldn't do the digitalWrites within the ISR. Have two volatile variables, one for the pin state and one when sending a message is required and handle those in your loop().

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.