Closed stickbreaker closed 9 years ago
stickbreaker, with the next release the callback function will be able to access a variable called "arduinoInterruptedPin" which will be the pin number that triggered the interrupt. Will this suffice?
Yep, I can use that.
Thanks.
Chuck.
This feature has been added. See the Usage wiki page for details.
GreyGnome, I'm in the process of adding CTS/RTS handshaking to the HardwareSerial object. I had previously used pinInterrupt with arduino 1.0. With the New 1.6.5 IDE they have totally changed Hardware Serial. The TX buffer is now a member of the class instead of a Global buffer.
The complier will not allow (interruptFunctionType)&this->_cts_clear_irq. It will allow (interruptFunctionType)&HardwareSerial::_cts_clear_irq. (the compiler did not force _cts_clear_irq to be a STATIC member, it used a uint16_t off the stack as the object pointer when I tried it.) But the instance pointer this was not set to the correct value.
I am at a loss on how to correctly access these internal buffers from a irq.
any suggestions? Chuck.
Edit: add:
Can you make another enableInterrupt() that also accepts a this value? you would have to custom code the callback to push the this value on the stack before the class member callback.Reading through the other open issues, it looks like the pinInterruptNumber variable would enable a workaround. Adding support to emulate a object member callback would increase the complexity of every callback too much.Could you redefine the callback function with the pinNumber as a parameter? In your code these all would be constants in the
if(interruptmask&_BV(x))portn.callback[x](pinNumber);