8

I have recently bought this cheap 4x4 keypad matrix. It only has the push-buttons and nothing else therefore I want to add a proper debouncing to it. The debouncing in software is something I want to avoid because it takes some processing power out of my application.

enter image description here

I know debouncing can be done using a resistor and capacitor (am I correct?) or schmit trigger (which requires another IC I guess and is out of question for me), so the question is, will I need to add R/C for each key, or can I get away with only one R/C pair per row or per column?

Any suggestions?

DEKKER
  • 755
  • 1
  • 12
  • 23
  • I take it that you are (worst case) willing to solder on the module itself, if a multiplexed solution is not possible? – pipe Feb 12 '18 at 12:13
  • @pipe yes I will solder the solution on the bottom side of the same board using SMD components ...at least that is the plan! – DEKKER Feb 12 '18 at 12:14
  • The debouncing should work not only with new keys but also with aged keys with some hundreds or thousands of key strokes. – Uwe Feb 12 '18 at 12:19
  • 8
    I think you should revisit the question of software debounce. There are techniques which use very few cycles. Adding resistors and or caps to a scanning keyboard may have unpredictable results. If you still need help to do that you need to give us more information, scan rate and required minimum keypress time. – RoyC Feb 12 '18 at 12:27
  • 6
    This is an XY problem. Please explain why polling the buttons is too much processing in your opinion. – Jeroen3 Feb 12 '18 at 12:27
  • I agree with DEKKER that reducing code by adding hardware components is always a good idea. IMO, 0.01 or even 0.1 uF cap or varistor before a resistor won't give unexpected result. But it has to be tested. – Fredled Feb 12 '18 at 13:26
  • Firmware scanning and debouncing of a small key matrix should take less than 1% of the bandwidth of a small micro operating at a few MHz. It may increase worst-case latency if the processor does not have nested priority interrupts. That's why virtually every practical application of such a key matrix uses firmware debouncing. – Spehro Pefhany Feb 12 '18 at 13:38
  • 5
    If debouncing a 4x4 matrix is too computationally intensive, you're doing something wrong. – jms Feb 12 '18 at 13:41
  • 2
    Software debouncing can be as simple as polling the keypad not faster than every X ms, where X is the maximum debounce time. – Wouter van Ooijen Feb 12 '18 at 15:43
  • dedicate a separate microcontroller for the keyboard interface. if you also have an LCD then use the same controller for that – jsotola Feb 13 '18 at 02:02
  • check out the HT16K33 chip – jsotola Feb 13 '18 at 02:26
  • Maybe note that software debouncing requires an electrical signal processable by the input circuitry of the controller. Fast transients in the ns range can happen during bouncing and might cause issues on the input circuits. Software debouncing is not an equivalent replacement for hardware debouncing. – JimmyB Feb 13 '18 at 14:40

5 Answers5

25

Let's be clear about this. If you have a keypad matrix you are already using processing power to apply sequential logic voltages to the rows or columns then reading the columns or rows back in order to determine the button pressed.

So, each time you get a "result" i.e. you detect that a button has been pressed, you mark that event as "pending" and some time later (10 to 20 ms) you check again to see if the button press you marked as "pending" can be judged to be "actual".

How much more processing time this needs is very little in the bigger scheme in my opinion and if you are so close to the limit at which your CPU can operate then get a bigger/faster CPU or increase the clock speed.

Using Rs and Cs can work but, in all cases it will produce a "slow" output that would need to be schmitt triggered to clean up the slow edge to a fast edge that is suitable for the logic that follows. You might get away with it of course but then you have a fixed solution with no flexibility.

Having said all the above, you might also need capacitors from each matrix line to ground to avoid ESD/EMC issues.

Andy aka
  • 434,556
  • 28
  • 351
  • 777
  • It depends what one means by slow. A shmitt trigger looks simple on a schematic but on a PCB it adds many connections and traces. I would first test if it's realy needed. If yes, I would look for quad shmitt trigger IC (or octal if it exists) to save board space and components count. – Fredled Feb 12 '18 at 13:32
  • You are right...I am scanning for buttons in the firmware anyway so a little bit more wasted cycles would not hurt that much! that EMC issue is a nice point that I did not even think about. Thanks – DEKKER Feb 12 '18 at 15:04
  • Can you please give a hint about how big the capacitor for EMC should be and why that particular value? also how about resistors? – DEKKER Feb 12 '18 at 15:06
  • 100 pF should be ok. No real calculation or theory, just good practice. – Andy aka Feb 12 '18 at 15:49
  • Don't forget pull ups or pull downs on inputs too. – Andy aka Feb 12 '18 at 15:50
4

To get the best debounce performance, it would likely be best to have one R/C for each button. However, you should still get decent results with one per row/column. Just depends how critical it is really. If you want to do it with the minimum amount of components, why don't you try doing one per row/column first, then taking some measurements and seeing if the result is good enough for your application?

If the results aren't what you wanted, then go ahead and add some on each button, then try again.

MCG
  • 11,809
  • 4
  • 34
  • 70
4

As a long-time embedded software engineer, I have to say that your assumption that debouncing will take some processing power out of my application is simply incorrect. This will never be true for any competently-written firmware.

Naturally, debouncing will require some processing. However the processing is trivial, and for user input will be happening at such a low update rate as to be utterly negligible. If you needed to debounce inputs with update rates in tens of kHz, perhaps the processing for debouncing would be significant, but a human pressing buttons does not need anything like that kind of resolution. In your case, 100Hz sampling would be easily fast enough, and you could almost certainly drop it as low as 10Hz sampling without seriously affecting your user interaction.

If you're trying to do input processing in a main control loop running at tens of kHz, of course it'll suck processing power. The correct solution is to write firmware which does not do it that way though, not to use a hardware solution to fix a software anti-pattern. Appropriate use of timers and interrupt priorities will give you what you need.

You can optimise the processing by making sure the read-back is all on one I/O port. Assuming that you're setting levels on columns and reading back the rows, then you bit-AND, bit-shift and bit-OR to build up a 16-bit value for the 16 pins. XOR this with the previous 16-bit value, and if this is non-zero then something changed. A simple debounce algorithm is just to set a counter to a value if the pins change state, pick a state if the pins kept their state and the counter is zero, and decrement if it's not zero.

You do need to check only one button is pressed, of course. If you've got an ARM processor, the ARM has an instruction to report how many bits are set, which is ideal for this. Just mentioning for a further optimisation.

Graham
  • 6,020
  • 13
  • 20
3

Afaik, there are ICs that can debounce 'automatically', e.g. MC14490, called a Switch Debouncer.

This will prevent you needing CPU power, but cost some extra wiring/PCB space.

Michel Keijzers
  • 13,867
  • 18
  • 69
  • 139
  • 1
    They will also cost a large sum of money. These debouncers are terribly expensive. – Fredled Feb 12 '18 at 13:17
  • 2
    @Fredled: Large as in "probably under $10". I agree that's a lot of money for what it does, but for a single run project it might be worth the time it saves... for a project with a run of thousands it would be a different matter :-) – psmears Feb 12 '18 at 14:36
  • At AliExpress 2 euro, so probably around double at 'better' places. – Michel Keijzers Feb 12 '18 at 14:46
  • 1
    the MC14490 appears to be unusable for matrix keyboards – jsotola Feb 13 '18 at 02:00
  • I'm sorry to hear ... didn't try it myself (not even on a normal switch). i wonder what the problem is, since any signal should be able to be debounced by it. – Michel Keijzers Feb 13 '18 at 09:30
0

True debouncing involves the addition of hysteresis. You can't do that with passive components e.g. resistors and capacitors. That's where either a software or active component (latch) solution come in.

Anthony X
  • 485
  • 2
  • 6
  • I agree if you aim at a perfect signal. However if you look for a cheap and small solution, passive components can give an acceptable result. – Fredled Feb 14 '18 at 20:26