Add an optional debounce to DigitalIn

15 Jan 2012

Hi,

As a re-entrant in the field of MBedded hardware after 20 odd years i was adviced by some friends to switch to the MBED platform. I'm glad they did, since its a wonderfull board to work with :)

The first project i'm using MBED for, uses 14 switches. And as we all know there are some really crappy switches out there, so I searched for a debounce setting in the DigitalIn LIB, and was surprised something as basic as that is not part of the MBED / NXP LIB's.

Why not add it to the LIB? It would even more simplify projects :)

Keep up the good work guys, i'm loving this board to death :)

Theo (nl)

16 Jan 2012

Some guys do it in hardware, so debouncing would be useless here. It's better to let the mbed guys work on essential features :). But you can search for debounce, you'll find some existing examples you can easily add to your project

16 Jan 2012

:)

I tried the examples, but they don't work if you attach 14 iterrupts to pins. So i moved to polling and my project works. I was just surprised that all the hardware i'm use to had debouncing support.

18 Jan 2012

Hm, I've witten a small program which works with 4 interrupts. I wonder whether it can be extended to 14! Maybe you could give it a try? http://mbed.org/users/Renegr/programs/IRQKeypad1/m216ms

05 Sep 2015

Rene Greiner wrote:

Some guys do it in hardware, so debouncing would be useless here. It's better to let the mbed guys work on essential features :). But you can search for debounce, you'll find some existing examples you can easily add to your project

Software switch denouncing is 100% an essential core library function. The code is open source on the internet, so it really don't take much time to implement. Its not like this is an I2C driver for XYZ chipset, it would take 20 minutes for someone who has done it before and has the code already working in a project.. mbed is to meant to compete with Arduino, which is a library already. Why am I having to spent my valuable engineering budget on writing this code right now? Why would anyone want to make hundreds of engineers resolve the same freaking problem hundreds of times!!! One engineer, one time, 30 minutes tops, and everyone is happy.

05 Sep 2015

There are debounce libs you can directly import into your project which will debounce the inputs for you...

05 Sep 2015

The library to use is called DebounceIn. It looks strangely like something that SHOULD BE IN THE CORE LIBRARY!!! This library needs to be in the core library because I'm a $150/hr engineer and I should not have to look for a 3rd-party library for an internal pull-up resistor. One engineer needs to do it once, and its done. If the part used is inside of the microcontroller and is commonly used, IT SHOULD BE IN THE CORE LIBRARY!!!

https://developer.mbed.org/users/AjK/code/DebounceIn/docs/91a2e988ba9d/classDebounceIn.html

At $150/hr, it took me over $1000 to write my algorithm because I require faster response time so I can shut off this really strong electromagnet before someone gets electrocuted or something really expensive breaks. I CAN'T JUST POLL THE SWITCH OR SOMEONE COULD DIE!!! 20ms IS A REALLY LONG TIME!!! The DebounceIn library will work for a prototype, but my machine cannot be UL listed without a robust DebounchIn class or spending money (i.e. my profits) on a hardware debounce circuit.

The official DebounceIn library needs to take advantage of interrupt priorities, a Ticker, and a lock. An emergency shutoff switch NEEDS TO HAVE A TOP-LEVEL PRIORITY!!! It also needs to process the event before the switch stops bouncing. Other buttons are low-priority and we can let the switch stop bouncing before processing the event. We need to use a IRQ on a pin to start a Ticker that then polls the switches until the stop bouncing, then turns off the Ticker and re-enables the interrupt on the pin. As long as there is a lock, we have no self-nesting issues. I will post a link to my code after I have debugged it.

15 Sep 2015

Quote:

The library to use is called DebounceIn. It looks strangely like something that SHOULD BE IN THE CORE LIBRARY!!!

Lots of stuff you could debate about if it should be in the core library. One of strong points of mbed are the easy to import user libraries. Now if only the mbed staff would realise that, and give a crap about the community, that would be great.

Quote:

I should not have to look for a 3rd-party library for an internal pull-up resistor

You don't need 3rd party lib for that, official mbed lib can do it fine.

Quote:

At $150/hr, it took me over $1000 to write my algorithm because I require faster response time so I can shut off this really strong electromagnet before someone gets electrocuted or something really expensive breaks. I CAN'T JUST POLL THE SWITCH OR SOMEONE COULD DIE!!! 20ms IS A REALLY LONG TIME!!! The DebounceIn library will work for a prototype, but my machine cannot be UL listed without a robust DebounchIn class or spending money (i.e. my profits) on a hardware debounce circuit.

Debouncein uses a default of 1ms, not 20ms, and you can easily change it. It shouldn't have taken you 7 hours to find the set_debounce_us function.

Also obviously I don't know your exact use case, but you do realise debouncing is only required when you toggle/increment/etc something on the press of a button? Lets say you have a big red emergency button, then there is no need to debounce it. Just connect an interrupt to it, and if that is fired, immediatly disable the circuit which can eletrocute people.

Also what you describe sounds like a low volume, high margin device. Now as IC designer I know that customers get really happy if they have to use one less capacitor. However that is for high volume, low margin stuff. I would expect that with equipemnt with strong eletromagnets that can eletrocute people you could afford a few passives in your circuit. (Which you are going to need anyway for reliability).

Also on a side note: For 700 dollar I write you a debounce lib exactly according to your specs.

Quote:

Other buttons are low-priority and we can let the switch stop bouncing before processing the event.

On most MCUs this is not possible with the generic port interrupts. I would advice you to use for example if you use a Freescale MCU to use the NMI instead for your emergency switch. And don't debounce it, seriously. First shut off your life threatening device.

20 Sep 2015

Thanks for the NMI tip. I love my Freescale FRDM-K64F.

Immediately disabling the interrupts is a form of debouncing, which is even more of a reason why we can't not have DebounceIn in the library. Its a commonly used function with parts internal to the microcontroller that functions differently on different processors; and as you point out, some processors have hardware assistance. The whole point of mbed is that it works the same on different microcontrollers. This is 100% an API task that needs to get implemented by the chip manufacturers; and 99.999% guaranteed they already have the most optimal code for that MCU already written ready to go. It shouldn't be up to thousands of engineers to research the best way to debounce switches on each specific processor. The chip manufacturers are the ones making the money, they know the best way to do it, and If you don't make them, they will never do it.

Its not about parts cost, but assembly time. The product I am complaining about is a bio-tech product that might have 50 units assembled so they can't afford a custom PCB. We are hand soldering units together and preying they don't break. I say pay me boat-tones of cash to to solder some threw-hole parts; problem is that scientists don't have much money. Even if I did solder on threw-hold parts, it would take more money to solder the connections than it would to rewrite the library. Soldering is very time consuming and expensive!!!

I think its kind of dangerous to not put Debounce in. I know what I'm doing, but the person who is going to maintain this machine and update the firmware doesn't. Even if I use threw-hold soldered up parts, it could still break and hurt someone. The vast majority of people wouldn't even know where to start and they would do a horrible job, and scientist would die. This is why we have APIs.