Listening for a long or short signal from button: what's your approach?

[jancumps]

When you use a pushbutton in a microcontroller managed user interface, what approach do you use?

- start a timer on the falling edge and measure count on the raising edge
- always keep a timer running and save the count on the falling edge?
- something else?

And do you stop other processing while the button is pressed or not?

[Bored@Work]

Continuously sampling the keyboard matrix. Effectively undersampling with respect to most key bouncing but fast enough to detect changes originating from human interaction. Storing (shifting in) the sampling results in a bit-array, one per key. The lengths of such a bit-array defines the longest key-press history available for a key. Then checking for a continuous sequence of ones (indicating a long key press) in such an array, starting from what constitutes "now" or "latest" in the array, back to whatever would be the key press duration for which I want to check.

E.g. sampling with 50 ms requires 20 bits (make it 24 bits = 3 bytes, or a single 32 bit variable) per key to keep a > 1 second history for a key. A simple test

Code: [Select]

if((value & 0x000FFFFF) == 0x000FFFFF) ...
then tells me if a button has been pressed for at least 1s.

For larger durations I accumulate e.g. 1s press-durations in a separate counting byte.

[nctnico]

Use a timer and poll it. Never ever use interrupts for switches and buttons unless their signals are properly filtered and are run through buffers with schmitt-trigger inputs!
I usually choose the polling interval so I can see a button is pushed for several timer intervals without making the user wait too long. This involves a counter to count the number of intervals. The number of intervals can be used to detect how long a button was pushed when it was released and/or whether a button was pushed long enough.

[TheDirty]

I usually have an interval timer that updates general purpose counters and will poll the button presses.  Then I have some hardcoded values to evaluate on button up.  value 1 is very small and means false trigger or possibly a bounce, Value two is timed for short button press, and value three is long button press.

[TMM]

Use a timer and poll it. Never ever use interrupts for switches and buttons unless their signals are properly filtered and are run through buffers with schmitt-trigger inputs!

Why not? Debouncing isn't hard to implement in software - I usually just implement a hold-off timer. You'd only want hardware debouncing if the processor was doing something absolutely time critical and you needed to minimize the number of unnecessary interrupts.

[nctnico]

Use a timer and poll it. Never ever use interrupts for switches and buttons unless their signals are properly filtered and are run through buffers with schmitt-trigger inputs!

Why not? Debouncing isn't hard to implement in software - I usually just implement a hold-off timer. You'd only want hardware debouncing if the processor was doing something absolutely time critical and you needed to minimize the number of unnecessary interrupts.

That is EXACTLY what I'm typing... 

[mazurov]

I generate separate events on press and release. What is going to happen on each event depends on the state of the state machine the application is in. If I need to react to long press I start a timer in that state. If I don't, I do nothing (or react on release instead of a press).

[dannyf]

Never ever use interrupts for switches and buttons...

Wow!

That's some advice we can do without,

[Marco]

For what it's worth in the few (as in 2 and in college/internship, so not worth much) embedded systems I made I just had a big old interrupt routine running at fairly high frequency and polled all the buttons with software debouncing and kept a timer for some to see how long they had been pressed for velocity based controls.

I guess you could keep a separate counter for repeated button presses if you're interested in that and your UI code might not be fast enough to catch them.

[dannyf]

kept a timer for some to see how long they had been pressed

You actually don't need a timer in that case: you can run a counter in the isr to detect long vs. short presses.

[Marco]

Sorry I didn't make myself clear, that is what I meant.

[Rufus]

Never ever use interrupts for switches and buttons...

Wow!

That's some advice we can do without,

It is generally good advice. I have never wanted or needed to generate interrupts from switches or buttons except when required to wake up a sleeping processor.

[nctnico]

Never ever use interrupts for switches and buttons...

Wow!

That's some advice we can do without,

People using interrupts for stuff like uncontrolled signals (usually) attached to long wires will crash and burn at a some point. I've seen it happen several times with damages into 6 figures behind a € sign as a result in some cases... Better be safe than sorry!

[c4757p]

I have never, ever needed to interrupt on a user input, except for the aforementioned case of waking from sleep (in which case I implement a policy of disabling that interrupt immediately after wake and not returning to sleep for at least a second). The amount of time it takes a human to interact with a device is aeons in microcontroller time! It's too easy to screw up and too useless to bother.

[jancumps]

Texas Instruments give this advice on the e2e forum:
http://e2e.ti.com/support/microcontrollers/msp430/f/166/t/54539.aspx

Ideally all port pin inputs should be handled with interrupts. Actually, all internal & external events should be interrupt-driven to achieve real-time responses & minimize CPU active time which consumes much more current than low power modes

[nctnico]

Texas Instruments give this advice on the e2e forum:
http://e2e.ti.com/support/microcontrollers/msp430/f/166/t/54539.aspx

Ideally all port pin inputs should be handled with interrupts. Actually, all internal & external events should be interrupt-driven to achieve real-time responses & minimize CPU active time which consumes much more current than low power modes

Major 
Make a note of the author and put that name on your 'these people are complete idiots' list. Its probably a software guy/girl who thinks hardware always does what its supposed to do, a button doesn't bounce or a signal can't contain noise.

[jancumps]

He has given the debounce logic too in that same forum post.

[dannyf]

'these people are complete idiots' list.

It is the drunk who always insist that others are drunk.

[arcom]

I use a counter for each button along with rising/falling edge detection to handle button states. In addition to that, each button has it's own status variable and entire processing is inside a single function which is called in 10-20ms intervals. That function does something like this:

1. reset button status variable
2. detect rising and falling edges
3. on rising edge
3.1. reset counter
3.2. set "pressed" bit
4. on falling edge
4.1. set "released" bit
4.2. if counter <= short_press_limit, set "short press" bit
5. if button is pressed
5.1. if counter >= long_press_limit, set "long press" bit
5.2. else increment counter

"Short press" state will be triggered only on button release and "long press" state will be set as long as the button is held pressed which is handy for scrolling purposes (eg. incrementing/decrementing a value by holding a button pressed). Good thing about this approach is that there are no delays or waiting loops so that the rest of the code can run. Also, calling the function in regular intervals debounces the buttons quite effectively.

[Rufus]

Texas Instruments give this advice on the e2e forum:
http://e2e.ti.com/support/microcontrollers/msp430/f/166/t/54539.aspx

Ideally all port pin inputs should be handled with interrupts. Actually, all internal & external events should be interrupt-driven to achieve real-time responses & minimize CPU active time which consumes much more current than low power modes

Major 
Make a note of the author and put that name on your 'these people are complete idiots' list.

The second line of code associated with that post says

"// Go to sleep, wait for port pin interrupt"

So he was quoted without the context of minimizing power consumption.

[JohnnyGringo]

Texas Instruments give this advice on the e2e forum:
http://e2e.ti.com/support/microcontrollers/msp430/f/166/t/54539.aspx

Ideally all port pin inputs should be handled with interrupts. Actually, all internal & external events should be interrupt-driven to achieve real-time responses & minimize CPU active time which consumes much more current than low power modes

Major 
Make a note of the author and put that name on your 'these people are complete idiots' list. Its probably a software guy/girl who thinks hardware always does what its supposed to do, a button doesn't bounce or a signal can't contain noise.

  Hardware shouldn't be bouncing or noisy before it gets to the software guy/girl.  That's a problem that should be taken care of in the hardware design.  You don't really want your average coder having to worry about piss-poor hardware.

[nctnico]

And make the bean counters come downstairs saying the competition is making a cheaper product with a PCB which contains 10 times less components than yours?

[jancumps]

...

The second line of code associated with that post says

"// Go to sleep, wait for port pin interrupt"

So he was quoted without the context of minimizing power consumption.

My excuses if my quote is incomplete. I did quote this part of his text though:

... minimize CPU active time which consumes much more current than low power modes

I'm not looking for consensus on the solution on the internet . I'm going to try out all the approaches mentioned above and see how each of them performs.

[Bored@Work]

  Hardware shouldn't be bouncing or noisy before it gets to the software guy/girl.  That's a problem that should be taken care of in the hardware design.

Hello?

[madires]

I use whatever fits the requirements and the program flow. If I have a battery powered device with an one-button interface I'd use an interrupt. It doesn't make much sense to have the MCU wasting power for waiting hours, days or weeks for the user to press the button. There's no this-is-the-right-method-and-everything-else-is-BS method.