Basic setup for button press processing - STM32

[anso-engineer]

Hello, I take this picture from the data reference of STM32F030Fx series.

As I understand, pull-up to Vdd is more preferable way for button processing. I think in the Cube IDE I can configure it as Pull UP and there is no need for external ressistor, according to that schematic?
In so many of schematics, I saw 100nF capacitor, probably for debounce purposes, so maybe this is suitable for avoding software debounce.

[peter-h]

This is OK but a pullup or pulldown is the same. The problem with the cap is that it gets discharged into the switch and eventually will damage the contacts.

To debounce a switch, maintain a "last" state, and take the button as pressed when the new state is a 1 and the old was a 0.

[kite31]

To debounce a switch, maintain a "last" state, and take the button as pressed when the new state is a 1 and the old was a 0.

Then either add a delay before checking for a next state change or else delay from first detection to check again to make sure the "new" state is sustained rather than being jitter. These have different implications for how your circuit works, or whether you distinguish short from long press.

[anso-engineer]

The problem with the cap is that it gets discharged into the switch and eventually will damage the contacts.

I assume I can somehow simulate it in Spice software. Is there is big current expected?
So, you recommend to use a software debounce)

[Doctorandus_P]

Pullup or pull down does not matter, the important thing is that depressing the switch results in a logic level change.

And as peter-h mentioned: the (usual) ceramic capacitors can deliver very high peak currents into a hard mechanical switch and this will damage them over time. If a capacitor is used, you should also add a series resistor to limit the peak current to below the switch specifications (can be as low as 5 to 20 mA). This combination is most often used for rotary encoders, as the relatively slow software debouncing (see below) is not satisfactory. Rotary encoders can generate several hundred pulses per second, while a typical debounce routine  last tens of ms. (A human can't press a single switch faster then about 10x per second).

Switch debouncing in software is a whole different topic. A common method is to read the switch at fixed intervals (for example an ISR key scanning routine) and only register a change if multiple consecutive reads have the same level. Debouncing with just a capacitor works best if the uC input is a schmitt trigger.

Jack Ganssle has written a nice paper.pdf about switch behavior and debouncing. There is a huge difference in switch behavior. For example the rubber dome switches with conductive rubber sometimes don't bounce at all, but behave more like a pressure sensor which change their resistance depending on the amount of finger pressure on the switch. Other mechanical switches can bounce (open & close) 100x or more during a single key press.

[Doctorandus_P]

I assume I can somehow simulate it in Spice software. Is there is big current expected?

With a hard short, the current is limited by ESR, and by other parasitic components such as the resistance and inductance of the leads and PCB tracks. It's not so easy to simulate this accurately in spice. You'd have to measure these parameters first before you can make an accurate model. As a rough guide, these peak currents can be 5 to 10A or even more.

A short peek suggests that ESR of "typical" MLCC's is in the order of 10 mOhm. Which would result in a peak current of 3V3/0.01 = 330A So the other parasitic factors dominate to get the peak current down to 10A.

[Psi]

This is OK but a pullup or pulldown is the same. The problem with the cap is that it gets discharged into the switch and eventually will damage the contacts.

Depends on the size of the switch and size of the cap.
Sometimes it can help if you're using a physically big robust switch on a mcu input and the switch has a rather high minimum current.
In those cases you may want a burst of current to keep the contacts from getting oxidized.
But usually you add a bigger cap and a series resistor to keep the inrush under control.
I recall once using 10uF at 15R for a large automotive rocker switch connected to a MCU input. Just to give the large switch some reasonable current flow.

In OP's case he could add a series resistor to limit current and provide some filtering lag for retriggering.

[anso-engineer]

A short peek suggests that ESR of "typical" MLCC's is in the order of 10 mOhm. Which would result in a peak current of 3V3/0.01 = 330A So the other parasitic factors dominate to get the peak current down to 10A.

then maybe it helps?)

[Psi]

To get a good amount of time for debounce while also allowing enough current to flow so that you don't run into issues with the minimum switch current you'll probably want a larger cap.

Maybe  4.7uF and 1000R
That will be around 3.3mA peak and around 60% drop in around 5ms

https://snubber.ai/calculators/rc-time-constant-calculator

Personally I usually do software based switch debounce unless i have a reason to do it in hardware.
It saves board space and parts cost.

[Karel]

I believe this is the "best" solution:



It's taken from the schematic of the NUCLEO-L452RE development board.

The internal (weak) pull-up resistor is too high and the resulting very low current when the
button is pressed can't keep the contacts clean. Hence the external 4K7 pull-up resistor.

[Psi]

Yes, its important to consider the charging pullup.
Using my previous example of 4.7uF 1k if you're using internal pullups that are like 30k it will take like 100-200ms to recover after a press. Which may or may not be an issue for your application.

It also depends on the type of switch and what sort of switch bounce you expect. A larger switch with big contacts and lever arm will bounce for longer than a small tack switch.
For small tack switches 100nF is fine.

[Karel]

And on the NUCLEO-H533RE development board they use this circuit:



Probably another engineer with different ideas 

[anso-engineer]

Personally I usually do software based switch debounce unless i have a reason to do it in hardware.

Yes, I already have used software debounce and it worked well.
Maybe I should take btn, 5mm in diameter which I plan to use, and measure it with osciloscope. It probably let me understand the bounce period.