Do it in software. Caps fail. Code never does. And code is free.

Had to comment a bit off topic, "caps fail, code never does" anyone who's ever owned a P.C may disagree, I think code sometimes has moods ha ha

 

At $3.41 a pop? Too rich for my blood.

Hadn't heard about a problem with cost only software debounce. So please do finish up your circuit.

 

Good points, @AnalogKid, except that I made clear that the circuit is for implementing a contact-closure input -- not a high speed data interface. I also made it clear that it did not provide any debouncing whatsoever -- I do that in software.

Your analysis about 'low amplitude interference' is not applicable in the contact-closure case, IMHO (there is no closed loop switch-open, and there is low-impedance ground everywhere for switch-closed). If I am wrong about this, please illustrate a realistic case where such interference will be problematic.

Aside from that, I've no issue using either an NPN or darlington (save that a darlington won't pull as low as NPN -- important for low-voltage digital inputs -- check the input low voltage range!).

Just FYI, I've used this circuit as a contact-closure front end for many years on many different designs in high-interference installations with long cable lengths. Zero failures or false activation.

Also, important: These circuits provide no isolation at all! If actual isolation is required, other methods must be used.

Thanks, Joey. You mentioned that your circuit is meant to be used for buttons, exclusively. Question: could it be used to transmit a digital signal at less than 100 kHz, say, from an encoder that's a few meters away from the MCU?... assuming that a resistor is placed in the line to the transistor's base to limit its current, of course.

 

Hadn't heard about a problem with cost only software debounce. So please do finish up your circuit.

Cost is not a real issue here, since I'm not designing a commercial product... software development, on the other hand, would be far costlier than the chip.

 

...I think code sometimes has moods ha ha

Maybe your code...

 

Thanks, Joey. You mentioned that your circuit is meant to be used for buttons, exclusively. Question: could it be used to transmit a digital signal at less than 100 kHz, say, from an encoder that's a few meters away from the MCU?... assuming that a resistor is placed in the line to the transistor's base to limit its current, of course.

A mechanical encoder? If so, take care collector the rise time is adequate.

An optical encoder? No.

 

A mechanical encoder? If so, take care collector the rise time is adequate.

An optical encoder? No.

Actually, it's a magnetic encoder with 5V push-pull outputs

 

Maybe your code...

more like microsofts!

 

more like microsofts!

I agree... but we're talking about MCU code here... assembly, in my case

 

Actually, it's a magnetic encoder with 5V push-pull outputs

That's a color of another horse.
Is it spurious "steps" or just noise while it is sitting there?
How much current can it drive?
Edit:
And the maximum frequency?

 

Actually, it's a magnetic encoder with 5V push-pull outputs

Start a new thread. Include the datasheet in the post. Make it a new discussion.

 

This is the encoder I'm talking about. And it's noise while it's sitting there.

 

Start a new thread. Include the datasheet in the post. Make it a new discussion.

You're right (again)... I'll do that in a few hours... gotta get to work.
Thanks again!

 

Much better. I'd be happy to provide an explanation.
...

Thank you, Joeyd. I stand wholly and enthusiastically corrected. Very well thought out and well said. I'll remember those points and your circuit (and the reference!).

 

Oh, and you won't need the shielded wire. Twisted pair will be fine.

Twisted pair is what I'd go for, if its likely to be *VERY* long, I'd use constant current and clamp the input voltage before it gets to the MCU input.

 

Twisted pair is what I'd go for, if its likely to be *VERY* long, I'd use constant current and clamp the input voltage before it gets to the MCU input.

It is clamped to +/- 0.7V.

 

It is clamped to +/- 0.7V.

If you're referring to the inbuilt clamp diodes, they're only intended to discourage buildup of static on the pins, typically they can rarely handle any more than about 10mA or so without failing.

In CMOS structures; the diodes are often attached to a parasitic SCR inherent in the fabrication process. Driving them fully to conduction fires the SCR and crowbars the supply rail. Which reminds me - if you debounce an input pin by damping it with a capacitor; you need to add a diode from the top of the capacitor to Vdd, so as Vdd comes down, it takes the capacitor with it.

If you have an external clamp diode and it gets damaged, you can replace it. If the internal diodes get damaged - its the whole chip!

 

If you're referring to the inbuilt clamp diodes...

I thought you were referring to my circuit -- which is what the post you were replying to was referring to.

 

Had to comment a bit off topic, "caps fail, code never does" anyone who's ever owned a P.C may disagree, I think code sometimes has moods ha ha

The bugs in code usually lie in wait for some specific event that never occurred to the programmer.

Electrolytic capacitors can be troublesome - especially small low voltage types that could suit damping a switch/input, but most dry dielectric types are pretty long lasting.

The main criticism of capacitor is closing the switch shorts the charge in it, if the capacitor value isn't chosen carefully it can sputter the switch contacts - just a very minute bit, but significant over many thousands of operations.

 

I agree... but we're talking about MCU code here... assembly, in my case

I was only making a joke really