Enable use of attachInterrupt() in classes

[Harvie]

Hello, i've found that it's impossible to call attachInterrupt from class.
Eg. from class constructor. And i've found it very annoying. Lots of people are complaining about this across the internet...

Can you please add some hack to make this possible?
I think we can make something that automaticaly creates wrapper function each time it's called?

[Harvie]

Example:

I want to create communication library (class) which uses attachInterrupt() to listen on input pin.
I want to be able to pass input pin to class constructor, so it can be processed using digitalPinToInterrupt().
I want to be able to create multiple instances (objects) of this class, each using different pin/interrupt.

This is not possible.

[s-light]

have a look at #58
i think that does just what you want..

[aentinger]

The reasons why you can't add a class member to attachInterrupt is because every class member function has a hidden this parameter pointing to the instance of the class added to it's signature. E.g.

class MyClass  {
  public:
    void int_callback_func();
};

One would think that void int_callback_func(void) has exactly the signature required by attachInterrupt but that's wrong since there is the hidden this parameter which is why the signature looks like that in reality void int_callback_func(MyClass * this). One solution to handle this is to use functionality provided by boost::bind (and you are very welcome porting boost to AVR) or to extend the signature of the interrupt callback to pass the class instance as proposed in #58.

[Harvie]

in https://www.boost.org/doc/libs/1_64_0/libs/bind/doc/html/bind.html This is what they say:

boost::bind is a generalization of the standard functions std::bind1st and std::bind2nd.

can't we use the std:: version? or it's also not ported to AVR?

[aentinger]

Unfortunately not because std::bind is part of the C++ standard library libstdc++ for which there is currently no support for avr-gcc.

[neu-rah]

https://github.com/neu-rah/PCINT, does it help?

[facchinm]

This is the solution we came to after a lot of iterations.
This way, you can write code like

class test;
void set2(test* t);

class test {
  public:
    int get() {
      return q;
    }
    void set(int s) {
      q = s;
    }
    void begin() {
      attachInterrupt(12, set2, FALLING, this);
    }
  private:
    int q;
};

void set2(test* t) {
  t->set(15);  
}

so you have a single handler that can accept a pointer to an object and dispatch it to the right one.
All cores that will be ported to arduino-api will receive this, so right now it's not widespread and thus undocumented

[Harvie]

@facchinm maybe the void set2(test* t) can be replaced with some generalized code directly in core? eg.:

attachInterrupt(12, this->myfunc, FALLING, this);

so when last parameter of attachInterrupt() is not 0, it will set interrupt callback to some internal core method, which will then call this->myfunc() and pass "this" to it. So there's no need to make wraper by yourself.

Another solution might be to just create array with one element per pin and store needed pointers in there. Such universal callback contained in core will then look up the right object&method pair and call it.

[neu-rah]

not a table please, this are embedded system and we don't have much memory most of the time.
as for the code, we can increase the library size, but before that please consider this.

struct Data {
  void myFunc() {/*...*/}
} data;

void setup() {
  attachInterrupt(
    digitalPinToInterrupt(1),
    [](){data.myFunc();},
    CHANGE
  );
}

note:
for reference, its a "c++ lambda function", they are part of c++11 and made for cases like this, otherwise we would have to go a long way making intermediate external function

[neu-rah]

we can put it inside a class if using a static function

struct Data {
  static void myFunc() {/*...*/}
  void begin() {
    attachInterrupt(
      digitalPinToInterrupt(1),
      Data::myFunc,
      CHANGE
    );
  }
} data;

void setup() {
  data.begin();
}

now we need more interrupts and if we want to use multiple instances of that Data class they will all share the same handler

template<int pin>
struct Data {
  static void myFunc() {/*...*/}
  void begin() {
    attachInterrupt(
      digitalPinToInterrupt(pin),
      Data::myFunc,
      CHANGE
    );
  }
};

//attaching to pins 1 and 2
Data<1> i1;
Data<2> i2;

void setup() {
  i1.begin();
  i2.begin();
}

however none of those will have access to this pointer

[Harvie]

however none of those will have access to this pointer

That will not work in my use case. Imagine you are implementing something like "software serial". You have object with buffer where you store new data during interrupts and from time to time the user reads that buffer. Also you need multiple instances, so you can't reuse the static method, because that would mean the buffer is also shared across instances, which is probably not good.

[matthijskooijman]

@Harvie, the template argument approach suggested by @neu-rah could work for a the SoftwareSerial case you pose, but would require a lookup table from the int template argument to a SoftwareSerial*, or require passing the SoftwareSerial* as a template argument (which only works when it refers to a global object). In either case, this only works from outside an object (where you know how many objects there are and/or what their global address is), not from inside an object/method.

However, the approach implemented in the API repo (shown above in #85 (comment) which should be imported into AVR later) would work fine for this usecase, I think? Having a special case support for method pointers, removing the need for this extra wrapper function shown by @facchinm would be nice, but can probably be implemented alongside the existing implementation (just one more overload of attachInterrupt that accepts a method pointer and a this pointer).

Regarding the current implementation as linked by @facchinm, I have a few remarks, but I opened a new issue about that in the ArduinoCore-API repo: arduino/ArduinoCore-API#99

What is the current state of this issue?

It's my understanding that users still can not use class methods, attach userdata or even detect which pin triggered the interrupt. Even though the linked Arduino Core API has commited specific functions for this (class methods) 2 years ago, the AVR core has not seen this functionality yet.

With SAMD you can work around this limitation by checking which pin triggered the interrupt and pull the correct class instance out of the abyss by yourself (using EIC->INTFLAG.reg and some global variables magic).

However on AVR there's no way to do the same, as the EIFR register is cleared before the ISR is executed.

What is the plan? What does the Arduino team intend to do to solve this problem?