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

0 Members and 1 Guest are viewing this topic.

Offline JohnnyGringo

  • Regular Contributor
  • *
  • Posts: 154
  • Country: vg
Re: Listening for a long or short signal from button: what's your approach?
« Reply #25 on: December 14, 2013, 08:02:24 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?
Listening.  And quite frankly, I'm rather ignorant when it comes to hardware issues (obviously).  But I don't see the point of the "Hello?".  What am I missing?
"Anyone who has never made a mistake has never tried anything new." - Albert Einstein
 

Offline Neverther

  • Regular Contributor
  • *
  • Posts: 129
Re: Listening for a long or short signal from button: what's your approach?
« Reply #26 on: December 14, 2013, 08:19:58 pm »
I run the input with interrupts mainly due to the instant need for shutoff.
The interrupt waits couple milliseconds before sampling the input port (poor mans debounce) and the functions are processed in priority order.
Long/short press for last two buttons is simply while loop for input state and counter to add up and break the loop if it gets too high.
If the loop is not broken, it was a short press.
And the fact it is running in avr pin change interrupt means that keeping the buttons pressed does not affect the control loop after the first run, where the maximum time is known.
Would not work on fast systems but on mine the control response is only required within 0.5s to 1s so it does not matter.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: Listening for a long or short signal from button: what's your approach?
« Reply #27 on: December 14, 2013, 08:36:18 pm »
Yet one of the problems of using interrupts for wake-up is that when the battery lifetime is based on 1 push per day a bad switch and/or moisture could easely cause several false presses (interrupts) per second. That would shorten the lifetime significantly. A couple of months ago I designed a battery (coin cell) powered gadget. I simply poll the buttons a few times per second. This solution exceeded the battery lifetime requirement more than twice (worst case) AND I can guarantee it will meet the battery lifetime under any circumstance.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Bored@Work

  • Super Contributor
  • ***
  • Posts: 3932
  • Country: 00
Re: Listening for a long or short signal from button: what's your approach?
« Reply #28 on: December 14, 2013, 09:29:16 pm »
Listening.  And quite frankly, I'm rather ignorant when it comes to hardware issues (obviously).  But I don't see the point of the "Hello?".  What am I missing?

E.g. because even quality switches bounce. You can now waste money on hardware debouncing or handle it with a few lines of code. More hardware does not come for free, and it adds more potential failure points. Further, your hardware does not run in an ideal world. You need to be prepared for spurious events.  You can sort them out in software the same way you sort out bounces - in fact, it is the same code, killing two birds with one stone.

And you can never make hardware idiot-proof for the software guy. If the software guy is an idiot he'll find other ways to code stupid things. Like using interrupts or setting all outputs to the fastest rise time.
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 JohnnyGringo

  • Regular Contributor
  • *
  • Posts: 154
  • Country: vg
Re: Listening for a long or short signal from button: what's your approach?
« Reply #29 on: December 14, 2013, 11:27:14 pm »
Listening.  And quite frankly, I'm rather ignorant when it comes to hardware issues (obviously).  But I don't see the point of the "Hello?".  What am I missing?

E.g. because even quality switches bounce. You can now waste money on hardware debouncing or handle it with a few lines of code. More hardware does not come for free, and it adds more potential failure points. Further, your hardware does not run in an ideal world. You need to be prepared for spurious events.  You can sort them out in software the same way you sort out bounces - in fact, it is the same code, killing two birds with one stone.

And you can never make hardware idiot-proof for the software guy. If the software guy is an idiot he'll find other ways to code stupid things. Like using interrupts or setting all outputs to the fastest rise time.
Yes, I see your point. But, wouldn't that mostly apply to microprocessor world? I.e. Systems/Designs with no device drivers?

If I'm coding on a device with an OS, I'd certainly expect hardware malfunctions to be handled by the hardware or device drivers.  Having a crappy-hardware design with the expectation that the device drivers will sort it all out, is still just a crappy-hardware design.  NOT THAT YOU would personally design crappy-hardware.
"Anyone who has never made a mistake has never tried anything new." - Albert Einstein
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: Listening for a long or short signal from button: what's your approach?
« Reply #30 on: December 15, 2013, 11:30:59 am »
If I'm coding on a device with an OS, I'd certainly expect hardware malfunctions to be handled by the hardware or device drivers.  Having a crappy-hardware design with the expectation that the device drivers will sort it all out, is still just a crappy-hardware design.
That is a pretty naive approach which could get you (and your boss) in serious trouble. Hardware (silicon bugs!) and their drivers have short deadlines so they have bugs by definition when they are just released. Every now and then I do development for embedded Linux systems and I usually have to fix some bugs in the kernel (and drivers) to get the platform running reliably. If you are writing software which interacts with hardware you need an embedded software engineer with a strong electronics background. One who knows how to use an oscilloscope. And even then you might run into trouble.
« Last Edit: December 15, 2013, 11:34:27 am by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline JohnnyGringo

  • Regular Contributor
  • *
  • Posts: 154
  • Country: vg
Re: Listening for a long or short signal from button: what's your approach?
« Reply #31 on: December 15, 2013, 01:53:28 pm »
If I'm coding on a device with an OS, I'd certainly expect hardware malfunctions to be handled by the hardware or device drivers.  Having a crappy-hardware design with the expectation that the device drivers will sort it all out, is still just a crappy-hardware design.
That is a pretty naive approach which could get you (and your boss) in serious trouble. Hardware (silicon bugs!) and their drivers have short deadlines so they have bugs by definition when they are just released. Every now and then I do development for embedded Linux systems and I usually have to fix some bugs in the kernel (and drivers) to get the platform running reliably. If you are writing software which interacts with hardware you need an embedded software engineer with a strong electronics background. One who knows how to use an oscilloscope. And even then you might run into trouble.
+1 nctnico!  Fortunately for me, I have no boss <grin>. Yea, I've had my fair share of embedded device drivers, and it always drove me nuts when just a few simple parts would had made my job simpler.  That is why this was such a hot-button topic for me.
"Anyone who has never made a mistake has never tried anything new." - Albert Einstein
 

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 4067
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: Listening for a long or short signal from button: what's your approach?
« Reply #32 on: December 15, 2013, 07:40:50 pm »
If you are on a 32 bit platform...
Sample button status every 20 ms and perform this:
Code: [Select]
history = (history<<1) | ((bool)button & 1)
Then you can check the amount of cleared bits (buttons always go low when pressed) and detect short press (0xFFFFFFF0), long press (0x00000000), medium press (0xFFFF0000), double press (0xFF00FF00) you name it.
All in the software, I've only used long and short press, double and medium are a lot more effort to program.

But now I have a flawless relay control button with mode select when you hold it.

Tip, use the setbits instruction to prevent useless comparisons... If you target has such instruction.
 

Offline NiHaoMike

  • Super Contributor
  • ***
  • Posts: 8973
  • Country: us
  • "Don't turn it on - Take it apart!"
    • Facebook Page
Re: Listening for a long or short signal from button: what's your approach?
« Reply #33 on: December 16, 2013, 12:11:58 am »
You could have the buttons trigger an interrupt, but mask the interrupt in its ISR. Then use a timer interrupt to unmask the button interrupt. That way, it can still respond almost instantly but if noise tries to cause an interrupt storm, it would be self limiting. Using low priority interrupts on a processor that supports it also works.
Cryptocurrency has taught me to love math and at the same time be baffled by it.

Cryptocurrency lesson 0: Altcoins and Bitcoin are not the same thing.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: Listening for a long or short signal from button: what's your approach?
« Reply #34 on: December 16, 2013, 12:20:23 am »
Quote
You could have the buttons trigger an interrupt, but mask the interrupt in its ISR. Then use a timer interrupt to unmask the button interrupt.

I have a lot of trouble trying to figure out how that might work.
================================
https://dannyelectronics.wordpress.com/
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: Listening for a long or short signal from button: what's your approach?
« Reply #35 on: December 16, 2013, 02:00:36 am »
You could have the buttons trigger an interrupt, but mask the interrupt in its ISR. Then use a timer interrupt to unmask the button interrupt. That way, it can still respond almost instantly but if noise tries to cause an interrupt storm, it would be self limiting. Using low priority interrupts on a processor that supports it also works.
I see the idea. The problem is that when dealing with noise you could get a false positive if you sample only once after a delay. IMHO you should sample a signal from a button/switch a few times so you know it is a stable signal and not noise.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline jancumpsTopic starter

  • Supporter
  • ****
  • Posts: 1272
  • Country: be
  • New Low
Re: Listening for a long or short signal from button: what's your approach?
« Reply #36 on: December 16, 2013, 11:00:34 am »
What about
  • having a clock defined but not running
  • react on button gio interrupts to register that a certain button is pushed
  • and start the clock (say 10/20 ms) and start polling the registered button(s) as explained by others here - to debounce and check short/long pushes
  • when the push(es) are completely handled, stop the clock untill a new button interrupt arrives
?

In that case the processor does no have to reside to endless polling, it gets a wake up from the button, and I deal with the remarks from other posters here about noisy interrupts because polling is done with a timer.

Thought?
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: Listening for a long or short signal from button: what's your approach?
« Reply #37 on: December 16, 2013, 01:00:33 pm »
The problem is that every time you get a pulse you have the clock running for a relatively long period. You could setup a scheme where you poll the buttons for a short period of time with a timer interrupt but then again your battery life estimates can be way off. If you really need ultra low power I'd use hardware filtering using ultra low power CMOS logic (maybe even the 4000 series).
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline jancumpsTopic starter

  • Supporter
  • ****
  • Posts: 1272
  • Country: be
  • New Low
Re: Listening for a long or short signal from button: what's your approach?
« Reply #38 on: December 16, 2013, 01:38:10 pm »
When I used the word clock I should have used Timer with interrupt.
If the gio interrupt was a glitch then the timer can stop after the first tick because it would find immediately when polling that the button is not pressed and that it was a glitch?

Wouldn't the battery last longer because I only have a timer running when needed, and for the shortest possible period?

The real polling would still happen on timer interrupts as explained by you, but the timer and its interrupt would only be activated if a button trigger occurs, and stop polling if all handling is processed.

Am I looking too far?
« Last Edit: December 16, 2013, 01:39:44 pm by jancumps »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf