4

As mentioned in the question , I was wondering whether it is possible for the controller to detect two button press simultaneously.

I am new to controller programming and started with the basics - blinking LED, then moved to buttons and now trying to play around button presses. I wanted to set some flag when both buttons are pressed together .

But as of I know, Only one ISR will be called in this case, thus detecting a single press. How can we achieve this...

(In some electronic devices, it has a specific functionality when we press certain buttons together e.g. resetting a phone when one presses 3 appropriate buttons simultaneously)

regards, Messi

Messi L
  • 97
  • 2
  • 11
  • 2
    In the interrupt service routine you have to check the inputs to see which buttons are pressed. Or even better, the ISR sets a flag, then the main loop checks that flag and the main loop then checks the inputs for which buttons are pressed, and does whatever is needed for those buttons. – Some programmer dude May 09 '14 at 06:27
  • Do you have to use an ISR? Can you *poll* for button presses in a main-loop (and include de-bounce)? – Jonathon Reinhart May 09 '14 at 06:27
  • The answer depends on the device, but yes. You just need to define what "two buttons pressed together" means. It means the first button is still pressed when the second button fires on the rising/falling edge. @JoachimPileborg has the right idea; check to see which buttons are pressed in the ISR. You could handle all kinds of scenarios with button press/button release and so on. – UncleO May 09 '14 at 06:52
  • 1
    You should simply remove the hardware interrupt for the input port, and create a 10ms timer interrupt where you will poll your port statuses. – vgru May 10 '14 at 10:47

1 Answers1

7

One single ISR triggered is not sufficient to detect a single button press. Because of the electro-mechanical signal bounce you get from all buttons, you need some kind of de-bouncing algorithm.

Furthermore, you need the program to be immune to EMI so that multiple interrupts won't create havoc on the stack whenever there are lots of pulses coming from the button(s).

For example:

  1. If the buttons are connected to different ports that give different interrupts, create one interrupt per button. If they are connected to the same port, they can usually trigger the same interrupt (depending on MCU).

  2. Whenever you get an interrupt as result of any signal edge (raising or falling) from the button, then in the ISR disable the interrupt and start a hardware timer of typically 5-10ms depending on the button. The timer should preferably trigger a timer interrupt.

    Disabling the interrupt is necessary to filter out spurious interrupts caused by the bouncing and by potential EMI glitches.

    The timer is necessary for the de-bouncing. If you cannot find the exact signal bounce time in the button data sheet (you most often don't), then simply measure it using an oscilloscope.

  3. When the timer elapses, read the port and store the result in a variable. Enable the button interrupt once again.

  4. The variable needs to be declared at file scope as static volatile. Static for private encapsulation, which is needed for good program design. Volatile to prevent against common compiler optimizer bugs, where the compiler doesn't realize that a variable has been modified by an ISR.

  5. Implement the same for the first button. You'll have two different variables telling the current state of the buttons. Simply compare these two variables with each other to tell whether or not two buttons are pressed at the same time.

Lundin
  • 195,001
  • 40
  • 254
  • 396
  • 1
    @MartinJames Not necessarily, you can do this in many ways. As we can see from the above complexity, the interrupt probably causes more harm than good. Unless very quick realtime response is needed, it is probably better to poll the buttons from a timer callback ISR which is running in the background. When you have inputs like buttons, i.e. something from the outside world connected directly to a GPIO, you typically _don't_ use interrupts unless there is a RC low-pass filter in the hardware. Random EMI glitches on a "keyboard wakeup" MCU pin with interrupt will cause very bad things. – Lundin May 09 '14 at 13:26
  • funnily enough, that is exactly what I do, polling the GPIO register/s every ms before passing on the tick to the RTOS. It's only a few instructions to do the debounce with some bitwise arithmetic. If some input state is deemed to have positively changed, I set a semaphore. – Martin James May 09 '14 at 14:20
  • 1
    I would avoid triggering an interrupt on a key press. It's simpler to have a timer (say 1ms or 10ms) and poll the keyboard state, than have a keyboard interrupt which would disable interrupts and start a new timer. The latter approach needs to be programmed carefully and essentially needs a state machine to keep track of presses and cleanup afterwards (like Martin wrote). – vgru May 10 '14 at 10:45