Hello there

I have modified your code a bit and in the fall_Interrupt I am lighting up a strip of LEDs ( therefore it takes about 2-3 seconds for the completion of the task). If u just tap, or release the electrode before completion, interrupts stop working whatsoever. I think it has to do with the fact that releasing your finger causes another interrupt and since the old interrupt is already running, it blocks any futher ones until restarting the whole MBED.

I am looking for a solution to the problem, and the only one I can think of is making a small ( wait(2) ) delay b/n the possibility of an interrupt being called. This should be done somewhere in the MPR121 files, I think, but I am not sure where at all..

An interrupt service routine should not take 2-3 seconds to complete. That is not a good way to handle the interrupt. Even if you can fix this particular problem the code would be hard to reuse when there are other sources that could also generate interrupts that need immediate attention. In specific cases you can temporarily disable the interrupt to avoid problems. However, in general it is better to let the interrupt respond quickly, get the key that was pressed and return to the main loop. The interrupt handler needs to store the pressed key in some global variable and let ''main'' take action on the key. That could be done in the ''while(1)'' loop by calling a timer to activate and switch off your strip of LEDs.

Thanks for the fast response!! I hear you absolutely that a 2-3sec interrupt is a bad idea. I tried following the GLOBAL VAR + BIG IF in the while loop, I've attached the main.cpp as a file; /media/uploads/daskalov/main.txt sorry couldnt get this importing stuff working.

It still blocks once you release and basically triggering the interrupt for the 2nd time..

I dont have the sensor or strip, so I cant test. The interrupt should not reset the stateTrigger until main has processed the previous one and finished. You should also probably define the variables in the interrupt routine as 'volatile'. I assume the I2C reads have been tested and are OK. Note that you need pull-up Rs on SDA and SCl or I2C communication will hang mbed.

Try this

snip

volatile bool stateTrigger;       // true if hit , false if released
volatile int buttonValue;         // value of the pin touched.


// Key hit/release interrupt routine for MPR121
void fallInterrupt() {

//Only read the device when the previous interrupt has been handled by main

  if (stateTrigger == false) {   // test global variable

    buttonValue = mpr121.read(0x00);    
    buttonValue += mpr121.read(0x01)<<8;

    stateTrigger = true;   // set global variable
  }
}

int main() {
    stateTrigger = false;   
    buttonValue = 0;             

    interrupt.mode(PullUp);              
    interrupt.fall(&fallInterrupt);            // Attach interrupt and its mode respectively.
     
    while (1) {
        
//Test for state change
        if (stateTrigger == true) {

            switch (buttonValue) {                 //r,g,b
                case 1 : colorChase(strip.Color(127,0,0), 10); break;   // red (instantaneously!!! , delay = 20ms)

                snip 

               default : colorChase(strip.Color(127,127,0), 100);    // orange   (2buttons)
            }

            stateTrigger = false; //main is done, release interrupt handler for next button
        }
        else {
          snip
        }                  // big if (buttonPressed)
    }              // while

}          // main

Dear Wim So each piece of the code and hardware for each device has been tested seperately, works correctly. I have been trying to collect it all together now, and here comes the problem.

Unfortunately, I left the project at work, and I will be able to test your solution on Monday.

I am just not sure by introducing the: 41 " stateTrigger = false main is done, release interrupt handler for next button " will the problem of releasing the button( which will call the int. routine fallinterrupt again ) be fixed? (sorry if this sounds stupid in some way, I just don't see it)

The interrupt handler will still be called every time a button is pressed or released. It just wont do anything while main is still busy showing the LED chase. I am not sure why the mpr121.read() may be causing problems. The only thing is that it uses separate i2c start, stop and byte send operations. It would be faster to use the blockreads or writes. Anyhow, I cant test it because I dont have that device nor the LED strips.

A quick test of the basic functionality of my example code above with some printf() statements and a PCF8574 I2C portexpander worked just fine: interrupts were detected multiple times even when main was stuck in a long wait..

Are you sure the problem is not in your switch statement: the mpr121 will return a '0' when the key is released. That means your switch calls the 'default' case which is a very slow LED chase (100ms delays). Better use a special case for '0' that does not do anything.

Are you using any RTOS libs. That may cause some unexpected issues.

I did not have a case '0' because the previous code returned 0 only when the boolean global variable was false and therefore it wouldn't enter to execute the switch statements ( never giving me the slow yellow 2button default case ).

I haven't used, like ever, RTOS libs, I will look into that.

Thanks again, I really hope it just fires off on Monday.

Hi Wim

So I did implement the code modifications that you suggested and it all works fine as long as you wait for the colorChase function in the switch statement to be executed completely. BIG IF refers to the 1st if condition to be true and to enter switch st-s.

This is what I get from debugging when the function colorChase is being completely executed:

• Entered fallInterrupt (hitting)
• Entered upgradeValue in fallInterupt
• Entered BIG IF
• Left BIG IF

• Entered fallInterrupt (releasing)
• Entered upgradeValue in fallInterupt
• Entered BIG IF
• Left BIG IF

This is what I get when it is not waited and after that "interrupts block.." :

• Entered fallInterrupt
• Entered upgradeValue in fallInterupt
• Entered BIG IF
• Entered fallInterrupt
• Left BIG IF

So my question is how to avoid this? It is unacceptable to have to reset the MCU when people are interacting with it..

You should not use printf inside the interrupt function and inside main at same time. The printf is non-reentrant and this may lead to problems. See the warning on the mbed/handbook/interruptin page. Please try without printf inside the interrupt.

Hi again I have tried without the printf-s it's the same story but I did make it work today!! Clumpsy but working. It works every time you reset the MCU, therefore I just copied the initialization code in the BIG IF ( after switch statements ) and it works just perfectly now. Thanks !

Can someone show me how to connect MPR121 to LPC1768. (Schematic plz)