Author Topic: Listening for a long or short signal from button: what's your approach?  (Read 7851 times)

0 Members and 1 Guest are viewing this topic.

Offline jancumps

  • Supporter
  • ****
  • Posts: 1250
  • Country: be
  • New Low
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?
 

Offline Bored@Work

  • Super Contributor
  • ***
  • Posts: 3932
  • Country: 00
Re: Listening for a long or short signal from button: what's your approach?
« Reply #1 on: December 12, 2013, 07:31:53 pm »
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.
« Last Edit: December 12, 2013, 07:33:33 pm by Bored@Work »
I delete PMs unread. If you have something to say, say it in public.
For all else: Profile->[Modify Profile]Buddies/Ignore List->Edit Ignore List
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 19931
  • Country: nl
    • NCT Developments
Re: Listening for a long or short signal from button: what's your approach?
« Reply #2 on: December 12, 2013, 08:17:57 pm »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline TheDirty

  • Frequent Contributor
  • **
  • Posts: 440
  • Country: ca
Re: Listening for a long or short signal from button: what's your approach?
« Reply #3 on: December 13, 2013, 01:32:37 pm »
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.
Mark Higgins
 

Offline TMM

  • Frequent Contributor
  • **
  • Posts: 437
  • Country: au
Re: Listening for a long or short signal from button: what's your approach?
« Reply #4 on: December 13, 2013, 04:11:41 pm »
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.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 19931
  • Country: nl
    • NCT Developments
Re: Listening for a long or short signal from button: what's your approach?
« Reply #5 on: December 13, 2013, 05:00:46 pm »
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...  8)
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline mazurov

  • Frequent Contributor
  • **
  • Posts: 448
  • Country: us
Re: Listening for a long or short signal from button: what's your approach?
« Reply #6 on: December 14, 2013, 12:16:17 am »
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).
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: Listening for a long or short signal from button: what's your approach?
« Reply #7 on: December 14, 2013, 12:25:05 am »
Quote
Never ever use interrupts for switches and buttons...

Wow!

That's some advice we can do without, :)
================================
https://dannyelectronics.wordpress.com/
 

Offline Marco

  • Super Contributor
  • ***
  • Posts: 4880
  • Country: nl
Re: Listening for a long or short signal from button: what's your approach?
« Reply #8 on: December 14, 2013, 12:59:57 am »
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.
« Last Edit: December 14, 2013, 01:03:50 am by Marco »
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: Listening for a long or short signal from button: what's your approach?
« Reply #9 on: December 14, 2013, 01:10:14 am »
Quote
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.
================================
https://dannyelectronics.wordpress.com/
 

Offline Marco

  • Super Contributor
  • ***
  • Posts: 4880
  • Country: nl
Re: Listening for a long or short signal from button: what's your approach?
« Reply #10 on: December 14, 2013, 01:14:32 am »
Sorry I didn't make myself clear, that is what I meant.
 

Offline Rufus

  • Super Contributor
  • ***
  • Posts: 2094
Re: Listening for a long or short signal from button: what's your approach?
« Reply #11 on: December 14, 2013, 01:17:10 am »
Quote
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.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 19931
  • Country: nl
    • NCT Developments
Re: Listening for a long or short signal from button: what's your approach?
« Reply #12 on: December 14, 2013, 01:17:31 am »
Quote
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!
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: Listening for a long or short signal from button: what's your approach?
« Reply #13 on: December 14, 2013, 01:25:08 am »
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.
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline jancumps

  • Supporter
  • ****
  • Posts: 1250
  • Country: be
  • New Low
Re: Listening for a long or short signal from button: what's your approach?
« Reply #14 on: December 14, 2013, 10:14:43 am »
Texas Instruments give this advice on the e2e forum:
http://e2e.ti.com/support/microcontrollers/msp430/f/166/t/54539.aspx

Quote
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
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 19931
  • Country: nl
    • NCT Developments
Re: Listening for a long or short signal from button: what's your approach?
« Reply #15 on: December 14, 2013, 01:12:50 pm »
Texas Instruments give this advice on the e2e forum:
http://e2e.ti.com/support/microcontrollers/msp430/f/166/t/54539.aspx

Quote
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  :palm:
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.
« Last Edit: December 14, 2013, 01:14:31 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline jancumps

  • Supporter
  • ****
  • Posts: 1250
  • Country: be
  • New Low
Re: Listening for a long or short signal from button: what's your approach?
« Reply #16 on: December 14, 2013, 01:20:38 pm »
He has given the debounce logic too in that same forum post.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: Listening for a long or short signal from button: what's your approach?
« Reply #17 on: December 14, 2013, 01:31:13 pm »
Quote
'these people are complete idiots' list.

It is the drunk who always insist that others are drunk.
================================
https://dannyelectronics.wordpress.com/
 

Offline arcom

  • Contributor
  • Posts: 42
  • Country: hr
    • Arc's Lab
Re: Listening for a long or short signal from button: what's your approach?
« Reply #18 on: December 14, 2013, 03:34:47 pm »
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.
 

Offline Rufus

  • Super Contributor
  • ***
  • Posts: 2094
Re: Listening for a long or short signal from button: what's your approach?
« Reply #19 on: December 14, 2013, 03:44:49 pm »
Texas Instruments give this advice on the e2e forum:
http://e2e.ti.com/support/microcontrollers/msp430/f/166/t/54539.aspx

Quote
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  :palm:
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.


 

Offline JohnnyGringo

  • Regular Contributor
  • *
  • Posts: 154
  • Country: vg
Re: Listening for a long or short signal from button: what's your approach?
« Reply #20 on: December 14, 2013, 04:21:13 pm »
Texas Instruments give this advice on the e2e forum:
http://e2e.ti.com/support/microcontrollers/msp430/f/166/t/54539.aspx

Quote
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  :palm:
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.
:palm:  :palm: 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.
« Last Edit: December 14, 2013, 04:50:17 pm by JohnnyGringo »
"Anyone who has never made a mistake has never tried anything new." - Albert Einstein
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 19931
  • Country: nl
    • NCT Developments
Re: Listening for a long or short signal from button: what's your approach?
« Reply #21 on: December 14, 2013, 05:20:18 pm »
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?
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline jancumps

  • Supporter
  • ****
  • Posts: 1250
  • Country: be
  • New Low
Re: Listening for a long or short signal from button: what's your approach?
« Reply #22 on: December 14, 2013, 06:22:29 pm »
...

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:
Quote
... 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.

 

Offline Bored@Work

  • Super Contributor
  • ***
  • Posts: 3932
  • Country: 00
Re: Listening for a long or short signal from button: what's your approach?
« Reply #23 on: December 14, 2013, 06:41:45 pm »
:palm:  :palm: 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?
I delete PMs unread. If you have something to say, say it in public.
For all else: Profile->[Modify Profile]Buddies/Ignore List->Edit Ignore List
 

Offline madires

  • Super Contributor
  • ***
  • Posts: 5425
  • Country: de
  • A qualified hobbyist ;)
Re: Listening for a long or short signal from button: what's your approach?
« Reply #24 on: December 14, 2013, 07:55:40 pm »
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.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf