Connect a GPIO pin to rising and falling edge interrupts about circle HOT 12 CLOSED

You are right with both assumptions. CGPIOPin currently does not support two interrupt sources at a time. If you want to use this I would add these methods to CGPIOPin:

void EnableInterrupt2 (TGPIOInterrupt Interrupt);
void DisableInterrupt2 (void);

Another possibility would be to allow calling EnableInterrupt() two times but this would require a change to the DisableInterrupt() method which would have to get the TGPIOInterrupt Interrupt parameter too. I prefer letting the existing class interfaces unchanged because otherwise this could require changes to existing applications.

from circle.

I tried to implement the additional two methods EnableInterrupt2() and DisableInterrupt2() as proposed. You can see my attempt here on the "gpiosecondinterrupt" branch in my fork of circle:

smuehlst@c9c08e1

My test code is in this gist:

https://gist.github.com/smuehlst/a0a85cb0b2a7428bb34d13de119a4884

Unfortunately it's not working yet. What works is to call either EnableInterrupt() or EnableInterrupt2(), but if I call both methods in sequence it looks like the interrupt function is not called. Is there anything obviously wrong in my implementation?

from circle.

Unfortunately I cannot find an error at the moment. Please let me know when you sorted this out! I will try this too when I have some time.

from circle.

I have pushed a change to gpiopin.h and gpiopin.cpp which is working. I have done this from scratch on my own to be sure and tested it with my own test program. I will check your test program now if I can find a problem.

from circle.

I think the problem in your test code is in gpiointerrupt.cpp line 30. You have to set m_bInterruptOn to TRUE before enabling the GPIO interrupts. Otherwise you will get an interrupt immediately before m_bInterruptOn is set and the assertion in line 37 will fail (race condition).

from circle.

I couldn't make any progress yesterday with my own code, still no success.
Thank you for doing another implementation from scratch. I will test it this evening. After looking at your change, it seems to be more or less identical to mine, only that I moved the common code to separate subroutines instead of duplicating it.

from circle.

Oops. We commented nearly simultaneous. :) Yes, your code was nearly the same but sometimes it is easier to do the changes step by step on your own to be familiar with it. Because the problem was not sorted out I could not rely on it. I think that code duplication is not a problem because we have enough memory space available. And I prefer letting proved code untouched because testing effort can be reduced that way.

from circle.

I think the problem in your test code is in gpiointerrupt.cpp line 30. You have to set m_bInterruptOn to TRUE before enabling the GPIO interrupts. Otherwise you will get an interrupt immediately before m_bInterruptOn is set and the assertion in line 37 will fail (race condition).

Ah, I see, I will change that. Note that I had taken the code in CSoftSerialDevice::Initialize as a blueprint:

boolean CSoftSerialDevice::Initialize (void)
{
    assert (!m_bInterruptOn);

    m_RxDPin.ConnectInterrupt (InterruptStub, this);
    m_RxDPin.EnableInterrupt (GPIOInterruptOnFallingEdge);
    m_bInterruptOn = TRUE;

    return TRUE;
}

from circle.

I will change this too. Thanks for info!

from circle.

Oops. We commented nearly simultaneous. :) Yes, your code was nearly the same but sometimes it is easier to do the changes step by step on your own to be familiar with it. Because the problem was not sorted out I could not rely on it. I think that code duplication is not a problem because we have enough memory space available. And I prefer letting proved code untouched because testing effort can be reduced that way.

Well my philosophy is to avoid duplicated code under any circumstances... It's not a matter of memory space, but of long-term maintainability.

from circle.

You will find some duplicated code in Circle. I was facing the problem that testing minor changes may take a lot of time because of the different samples and Raspberry Pi models. So sometimes I'm checking if the proved code is untouched or touched in a manner that I can say, I do not need to test this all again. But of course for larger code parts I don't prefer duplicated code. There is room for discussion, where is the right threshold for that.

from circle.

Fair enough, you own the code and you decide. In any case I want you to know that I'm very impressed by circle's implementation and its functionality.
I implemented the fix that you proposed for the test code in gpiointerrupt.cpp, and I can confirm that it now works as expected, thank you!

from circle.