noninverting logic gate with feedback for debounce?

GroupDIY Audio Forum

Help Support GroupDIY Audio Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

Twenty Log

Well-known member
Joined
Jan 7, 2010
Messages
213
Location
New Hampshire, USA
This is an interesting conundrum...  Still wrapping my head around this concept for debouncing...

The Art of Electronics states that it is always OK to short the output to the input of a noninverting gate for small amount of time... in this case it is the propagation delay...

This all seems cool for the transient state....

perhaps the steady state is what is bothering me, as for logic 1 debounce operation, let's say, Voh is probably lower than the +5V rail that the switch is sitting at in the steady state, and thusly is the output transistor at Voh is shorted to the rail (which maybe it is just bypassing the output transistor at this point?)

I wonder of self heating during the short propagation delay and if that contributes to gate threshold drift, or premature derating of the gate?

Anyone use this topology?  I am wondering of a series resistance for belt and suspenders?
 

Attachments

  • noninverting_logic_gate_feedback_debounce.png
    noninverting_logic_gate_feedback_debounce.png
    49.5 KB · Views: 32
I don't follow what you are trying to accomplish.

The HC08 is a two input "and" gate, so output goes hi only when both inputs are high.

I don't see any scenario where it is OK to connect the output of a logic gate directly to +5V or ground.

Opening the connection from logic output back to the two inputs would deliver a simple gate propagation delay between output and input changing state.

I don't see a simple debounce facility from any combination of those connections.

JR
 
Yah this circuit freaked me out when I first saw in tech school way back when....

Page 577 Art of Electronics, Second Edition says it is a debouncer

...and that it is always OK to short the output for a small amount of time in this circuit example as it will stay shorted for only 1 propagation delay....

http://www.scribd.com/doc/46129097/The-Art-of-Electronics-H
(type in page 584 in the web page text box, which is really page 577 as printed in the book)
 
H&H use a NON inverting device - it specifically says so in the text and the device in their diagram is clearly non inverting. Your diagram is a bit ambiguous and many people will interpret it as an inverting part - especially as you labelled it a 74HC08 which is an inverting device.

Cheers

Ian
 
OK, I see now... The contention is only transiently, so as long as the logic is robust and can tolerate brief shorts to supply or ground. This is a clever trick, but I would not be inclined to use this in a production design, because what happens if a different logic family gets used in place of the original.

Note: I've done my share of unconventional circuit tricks with CMOS logic, so this post is a "do what I say not what I did".  8)

I am not sure I would go as far as to say "It is always OK to short logic outputs". Another consideration, is to think about what is going on monetarily.  You will be pulling the max drive current in both directions transiently. Again a different higher speed logic family may increase that brief current spike, that you want to keep isolated. So layout and PS decoupling needs to account for these current transients.

Digital logic has good noise immunity, I'm not sure I'd want to do this in the middle of a quiet audio platform (tick, click, pop, thump, etc).   


JR
 
Crud!  Did I mislabel it?  The schematic should be correct in concept.

I have been swapping gates this morning and global search and replace of comments. Oop's....

Notwithstanding, this circuit is now an XOR with one pin tied to make it NON inverting..  Had the spare XOR left over.

Yes, this was also the conundrum with max current draw...  Separate PS and driving relays/LEDs on separate lines in a separate section of PCB...

Hmmm would a feedback resistor be warranted anyway for belt and suspenders?

Thanks!

 
Twenty Log said:
Crud!  Did I mislabel it?  The schematic should be correct in concept.

I have been swapping gates this morning and global search and replace of comments. Oop's....

Notwithstanding, this circuit is now an XOR with one pin tied to make it NON inverting..  Had the spare XOR left over.

Yes, this was also the conundrum with max current draw...  Separate PS and driving relays/LEDs on separate lines in a separate section of PCB...

Hmmm would a feedback resistor be warranted anyway for belt and suspenders?

Thanks!

A resistor in the output to input leg would both reduce the current spike amplitude and actually allow the propagation delay to develop at the output. If there is hard wire connection from input to output, no delay.  Switch bounce means the input goes intermittently open circuit during bounces. A feedback path resistor should work similarly to latch input high or low.

With a resistor to current limit the switching spike it is better defined, so less of a concern for causing noise. I still don't like it a lot, but I hate it less.

JR

PS: Going back to the original 2 input "and" logic, adding a simple RxC in series with one input, while the other is directly connected to the switch, would debounce and delay the state change.
 
JohnRoberts said:
A resistor in the output to input leg would both reduce the current spike amplitude and actually allow the propagation delay to develop at the output. If there is hard wire connection from input to output, no delay.

Sure there's delay. Assume the switch is connected to ground and as such the gate output is low. Now flick the switch so the input is forced high. The gate always has some prop delay, so some number of nanoseconds later, the output will go high too.

Adding a feedback resistor limits the current when the gate output and the switch setting disagree. The gate inputs have some amount of input capacitance which the output has to charge, but that's trivial (10 pF), so RC delay isn't much at all. If that resistor is selected such that the absolute maximum output current is never exceeded, then the gate shouldn't die.

Anyways, as much as I love that book (and will buy the long-rumored 3rd Edition on the day it's released), this example falls into the category of "Hack" and "don't try this at home; we're professionals" rather than being a recommended design technique.
 
Andy Peters said:
JohnRoberts said:
A resistor in the output to input leg would both reduce the current spike amplitude and actually allow the propagation delay to develop at the output. If there is hard wire connection from input to output, no delay.

Sure there's delay. Assume the switch is connected to ground and as such the gate output is low. Now flick the switch so the input is forced high. The gate always has some prop delay, so some number of nanoseconds later, the output will go high too.
Not to quibble, but if that switch wiper is also hardwired to the logic output, I would expect the switch impedance to be low enough to overpower the wimpier logic circuitry. Adding a resistor in series between the wiper and logic output allows the logic to take it's time changing state....
 
Adding a feedback resistor limits the current when the gate output and the switch setting disagree. The gate inputs have some amount of input capacitance which the output has to charge, but that's trivial (10 pF), so RC delay isn't much at all. If that resistor is selected such that the absolute maximum output current is never exceeded, then the gate shouldn't die.

Anyways, as much as I love that book (and will buy the long-rumored 3rd Edition on the day it's released), this example falls into the category of "Hack" and "don't try this at home; we're professionals" rather than being a recommended design technique.
+1 exactly... 

Clever but not recommended, unless you weigh all the unintended consequences... 

JR

PS: When I started designing for large scale production (at Peavey) I imposed discipline on myself to not use so many clever circuit tricks, for several reasons. However these "tricks" are always useful to have in our tool kit for fixing problems, after a product is in production, to help minimize the cost of cut and patch modifications, using some unconventional circuit behavior to simplify a tweak. 

 
MCU's are so cheap these days. make your life easier. :)
debounce is as simple as "trigger counter when button is pushed, check back later (in 3mS) if the button is still pressed"

Or, expressed as:

Code:
#pragma vector=PORT1_VECTOR
__interrupt void Port_1(void)
{
  __delay_cycles(50000);                     				// Software delay for mechanical bounce.
     
    
 // This Checks if the switch was pressed    
 if ( !(P1IN & 0x10))
  {
  
 Do the code in this box. (like TX data on a serial port, or update an LED)

  }

 
  P1IFG &= ~0x10;                           				// clear interrupts.
}
 
Cheers everyone...

Yup... OK... hackish... maybe one could also put (low value) resistors in the power rails, perhaps with HC, but probably not HCT... who knows... still hackish...

OK, so I am thinking MCU after getting 9 extra glue logic $0.50 OR gates, AND gates and MAYBE gates onto a D sized sheet (plus, let's say just less than $1 each stuffing charge)... (but of course it is an ELEGANT solution; caveat digital designor)...

I have reverted to Schmitt-Trigger inverters with cap and resistor slow down to debounce (I have many other hexadecimal encoder knobs each with 4 lines that need debouncing)...  these knobs do not need intervention with the possible MCU though as they directly drive analog hardware...

It is the 5 push buttons (and some relays) that need it...

Yup, I have been meaning to ask Rochey about the MSP430 series with the latest VU project of his, as I do need to do metering but with A LOT of LEDs...

I am wondering about the FRAM retention though...  THE former TI apps engineer for the early days of the MSP430 lives next town over; maybe a pint and chat with him... 

The only issue I have with MCUs is that, just like in real life, I always seem to run out of I/O (or RAM)... ;)
 
Twenty Log said:
Yup, I have been meaning to ask Rochey about the MSP430 series with the latest VU project of his, as I do need to do metering but with A LOT of LEDs...

I am wondering about the FRAM retention though...  THE former TI apps engineer for the early days of the MSP430 lives next town over; maybe a pint and chat with him... 

The only issue I have with MCUs is that, just like in real life, I always seem to run out of I/O (or RAM)... ;)

Modern MCUs can have plenty of  RAM and flash but I/O can cost you.

One trend or evolution I've seen is lower voltage and lower current capability for most output lines.

In my first generation tuner I was able to drive LEDs directly from 5V MCU matrixed 8x7to drive lots of LEDs.

Later when I did a dedicated 4 channel VU meter (currently being used in a production console), I did all the A/D capture and crunching in the 3.3V MCU then pushed out the LED data in serial form to digital latches running from 5V. 

http://www.johnhroberts.com/meter_pix.JPG

Since that design I have started using a dedicated LED driver IC (TI TLC59025) that accepts serial data and drives LEDs with current sources. You could use these 16 LED drivers with high side switches to multiples for 16x whatever (lots of LEDs), or string multiple driver chips in series to handle 16x whatever LEDs without the noisy multiplexing.

I can't imagine NOT using a MCU for a commercial meter design. The console meter I did a few years ago, was cheaper than the analog circuitry it replaced, and had the added features of Peak/VU simultaneously, with other console specific tricks.

I have thought about generating a generic design for DIY use, where you could make an equivalent LM 391x on steroids, where programming pins could select between different display options. I never firmed up a package, since these days I only do SMD and DIY still prefers through hole.  One possibility is a MCU board with room for multiple inputs, that the user could populate as needed.  Then daughter display boards could add LEDs for display in banks of 16. A log display could just push out low level data that rolls off the end and is ignored. A linear display needs to know range/step size.

Sorry for the veer... but meters have long been an area of interest for me.

JR
 
Rochey said:
MCU's are so cheap these days. make your life easier. :)
debounce is as simple as "trigger counter when button is pushed, check back later (in 3mS) if the button is still pressed"

Or, expressed as:

Code:
#pragma vector=PORT1_VECTOR
__interrupt void Port_1(void)
{
  __delay_cycles(50000);                     				// Software delay for mechanical bounce.
     
    
 // This Checks if the switch was pressed    
 if ( !(P1IN & 0x10))
  {
  
 Do the code in this box. (like TX data on a serial port, or update an LED)

  }

 
  P1IFG &= ~0x10;                           				// clear interrupts.
}

A spin-loop delay at the beginning of an ISR? Bleeech..... ;)

Much better to just record the time since the last interrupt (in ticks), and only respond to the event if the last interrupt happened some amount great than a few ms before.  Then while the switch is rapidly firing interrupts, you ignore them, and only respond to the last one (where you check the pin state).
 
Matador said:
Rochey said:
MCU's are so cheap these days. make your life easier. :)
debounce is as simple as "trigger counter when button is pushed, check back later (in 3mS) if the button is still pressed"

Or, expressed as:

Code:
#pragma vector=PORT1_VECTOR
__interrupt void Port_1(void)
{
  __delay_cycles(50000);                     				// Software delay for mechanical bounce.
     
    
 // This Checks if the switch was pressed    
 if ( !(P1IN & 0x10))
  {
  
 Do the code in this box. (like TX data on a serial port, or update an LED)

  }

 
  P1IFG &= ~0x10;                           				// clear interrupts.
}

A spin-loop delay at the beginning of an ISR? Bleeech..... ;)

Much better to just record the time since the last interrupt (in ticks), and only respond to the event if the last interrupt happened some amount great than a few ms before.  Then while the switch is rapidly firing interrupts, you ignore them, and only respond to the last one (where you check the pin state).

Blech indeed .... so what happens when the watchdog bites while you're spinning in that loop in the ISR?

What's this "watchdog," you ask?

Hmmmm...

-a
 
JohnRoberts said:
Since that design I have started using a dedicated LED driver IC (TI TLC59025) that accepts serial data and drives LEDs with current sources.

Ah, yeah, that was the part I was thinking of for something ...

There's an 1 MHz I2C flavor of this, too, if your micro is pin limited and has an I2C interface.

Oh, wait ... I first came across the Allegro Micro version of this part, and Allegro's obsoleted them all.
-a
 
Andy Peters said:
JohnRoberts said:
Since that design I have started using a dedicated LED driver IC (TI TLC59025) that accepts serial data and drives LEDs with current sources.

Ah, yeah, that was the part I was thinking of for something ...

There's an 1 MHz I2C flavor of this, too, if your micro is pin limited and has an I2C interface.

Oh, wait ... I first came across the Allegro Micro version of this part, and Allegro's obsoleted them all.
-a

When I was doing a lot of embedded C coding, my first mentor looked at some of my ISR's, then gave me this sage wisdom:

"ISR's are like cheap whorehouses....it's best to get in and out really fast!"

;)
 
"don't tell mom that I'm an engineer... she thinks I am a piano player at a whorehouse...."

If a kernel space or equivalent scheduler were present one could go all Microsoftie and have Deferred Procedure Calls in the ISRs....  last RTOS I worked with was ThreadX on a Digi ARM based thing...  before that it was HC11 assembly...

been a while and I am rusty and disenfranchised when multiplexed pins give mutually exclusive issues in the design (E.g., SPI was exposed outside of the Digi ARM Connect Me $1500 eval kit thing, but not the SPI clock on pin 4 as it was needed internally to the Connect Me for something else and could not be exposed for the real world peripherals!!!!!! This information was NOT in the datasheet or documentation for a purchasing decision and took a while to sleuth out)...

I was looking at the PWM versions similar of the TLC5948 variety once, as I needed dimming for a design that has been shelved when some bleeding edge silicon that I was waiting for never came out....

OK... MCU...  Especially for metering...  FCC testing ramifications?
 
Twenty Log said:
OK... MCU...  Especially for metering...  FCC testing ramifications?

Put it in a metal box. If the MCU drives signals to the outside world, use ferrites on the signals.

OK, I'm being somewhat flip, but that was what we had to do for the last thing I had tested.

-a
 
Twenty Log said:
"don't tell mom that I'm an engineer... she thinks I am a piano player at a whorehouse...."

If a kernel space or equivalent scheduler were present one could go all Microsoftie and have Deferred Procedure Calls in the ISRs....  last RTOS I worked with was ThreadX on a Digi ARM based thing...  before that it was HC11 assembly...

been a while and I am rusty and disenfranchised when multiplexed pins give mutually exclusive issues in the design (E.g., SPI was exposed outside of the Digi ARM Connect Me $1500 eval kit thing, but not the SPI clock on pin 4 as it was needed internally to the Connect Me for something else and could not be exposed for the real world peripherals!!!!!! This information was NOT in the datasheet or documentation for a purchasing decision and took a while to sleuth out)...
yup, eval boards often have to make such trade offs.  Most parts for blank sheet designs are more than adequately flexible, but you need to be careful still since every pin can't be mapped to do every firmware function. 
I was looking at the PWM versions similar of the TLC5948 variety once, as I needed dimming for a design that has been shelved when some bleeding edge silicon that I was waiting for never came out....
I mostly use microchip parts and they all have PWM modules on board. In fact I am using two PWM outputs (feeding passive RC to smooth) to make sine waves for my tuner.  Nowadays microchip makes a low end 16 bit DSP with stereo 16b DAC built in so that's what I'll use to make sinewaves for my next platform. They don't need to be that pure, but better is always better.
OK... MCU...  Especially for metering...  FCC testing ramifications?
ASSuming you are talking about LED metering, if concerned about noise I would avoid multiplexing the meter LEDs. Using LED drivers like the TI part i suggested, the LEDs can be turned on and off exactly like a LM3915 or similar analog comparators circuitry.

The processor can run from it's internal clock with most functions (like A/Ds inside the processor) so the only truly digital signal external is the serial data pushed out to the latch. This clock and data line will be pretty low current and should be kept short to not make an antenna. The LEDs switching will be several times more current than digital lines.

I would expect a careful layout and design to be well behaved, but you need more than my opinion if concerned.

JR

PS: I am more worried about the class D audio chip I use, and I put ferrite Ls in series with Cs to ground right at the chip outputs. 
 
Back
Top