Switch debounce question

Can switch debouncing be accomplished with just a capacitor, or do you need a one shot?

No. The point about switch debounce is it removes the multiple transitions that can occur from a switch AND provides a clean, fast digital signal. While a big capacitor can remove the multiple transitions the input will spend a long time in a region of ambiguous voltage on the input of a digital system.

Keith

Here's the Schmitt trigger inverter method. **broken link removed**
Here's another discussion of debounce. **broken link removed**

.
.

Excellent sources, especially the 2nd article.

.

Concerning hardware, I highly recommend adding schmidt trigger IC or enabling it (if your microcontroller has the I/O option).

The other thing you really need to worry about is ESD. I purchase pushbuttons with grounding pins and add protection diodes to the pushbutton line (if cost isn't an issue).
**broken link removed**

.
.

Concerning software, this is where I disagree with most people keep doing moronic things, like tieing buttons to interrupts.

The ONLY time you should tie buttons to interrupts is low-power designs that are in sleep or some low-power condition. Yes, RESET is an interrupt, but I'm not talking about it.

If your microcontroller is ALWAYS running and NEVER sleeps, then you should read your button in a tick interrupt or wait long periods of time between the reads, otherwise you will tear your hair out trying to process false triggers on switch bounce.

Most people don't know the ancient Commodore C64 / VIC20 / PET all read their keyboards in the TICK (JIFFY) interrupt, which was around 60Hz (NTSC) and 50Hz (PAL). So 50-60 times a second, those computers would increment the clock, check the keyboard, and do some other minor things.

A slower read time of the keyboard, like 50 to 100 times a second, is basically nothing more than a filter that automatically misses all the key bouncing. Yes, that is why it worked on all those slow 1Mhz computers! Those computers didn't sit in moronic spin-loops nor did they use complex delay timers or interrupt code. The way they did it was elegant and worked!!!!!!

Some people will moronically whine about there being a delay between the first press of the key, and the next interrupt where the key is actually read, but it comes down to "IT DOESN'T MATTER", because most things we humans do are so slow compared to a CPU that it just doesn't matter.

I'm not saying this is the way to do it 100% of the time, because low-power designs and software that takes almost every cycle of a cpu to get the job done will warrant other approaches, but I know that most of you don't have designs or needs that fall in those groups, so instead you should be using the simple 30 year old way of doing it.

Please do not whine about this opinion, because you sure the heck won't change my mind on this subject, because what worked 30 years ago still is an excellent way to do it today.

I remember the Commodore VIC 20. I used one to program a control system to control pressure in a battery during reliability testing for a Navy contractor in the early part of my career. I didn't know all that about it but it did work quite well. We used to load the program off of a cassette tape. My boss used the Commodore 64 do develop some test systems that he was working on. This was back in 1984 if I remember correctly, Just before I started working on my Bacelors degree.