Arduino Forum

Using Arduino => General Electronics => Topic started by: ironbot on Sep 30, 2012, 11:18 pm

Title: debounce problem
Post by: ironbot on Sep 30, 2012, 11:18 pm
Hi,
I have a plan to install a bumper switch in the neck of the robot and just set it up on breadboard to test. I used standard hardware debouncing by using an SN74AC04 hex inverter and 10k resistor and 10mf capacitor and a microswitch.

For test program I attached the zero interrupt of pin 2 and it works, but not well enough: it sometimes makes a mistake. Seems to me not a fast enough debouncing. If I press the switch repeatedly around 2 times a second, it makes mistakes sometimes.

My question: is there any way I could guarantee its operation, or a better way of implementing such a limiting switch, as it is to sit with a dc motor and just imagine if the bot is turning the neck and limiting switch won't work!
Title: Re: debounce problem
Post by: Grumpy_Mike on Oct 01, 2012, 12:02 am
Quote
and 10mf capacitor

I bet you haven't, I suspect you have a 10uF (micro Farad ) capacitor.

If this is not giving you long enough debounce then make it bigger. However, it would be good to see the schematic of what you think is standard.
Title: Re: debounce problem
Post by: marcello.romani on Oct 01, 2012, 01:16 am
Have you considered adding a software debounce ?
Title: Re: debounce problem
Post by: Grumpy_Mike on Oct 01, 2012, 06:15 pm
Quote
Have you considered adding a software debounce ?

It is a lot more tricky on an interrupt pin, because the delay is in the ISR which is never a good thing.
Title: Re: debounce problem
Post by: ironbot on Oct 01, 2012, 08:13 pm
True, can't do software debounce for I'm on ISR, no delay() !

I drew what I call 'standard', sorry if not very clean drawing, and yes, I made a mistake, 10uF for sure!

Edit:
Sorry for I forgot: the resistor is connected to +5v.
Title: Re: debounce problem
Post by: Far-seeker on Oct 01, 2012, 08:31 pm

I drew what I call 'standard', sorry if not very clean drawing, and yes, I made a mistake, 10uF for sure!


Well as Grumpy_Mike pointed out, you should try a larger capacitor.  I don't know what you have available, but the delay of an resistor-capacitor circuit will be R*C, in seconds.

Edit: So in your present circuit you have 10*10^3 * 10*10^-6 = 0.1
Title: Re: debounce problem
Post by: marcello.romani on Oct 01, 2012, 08:51 pm

Quote
Have you considered adding a software debounce ?

It is a lot more tricky on an interrupt pin, because the delay is in the ISR which is never a good thing.


Next time I need to read more carefully, I didn't notice the OP was using an interrupt  :smiley-roll-blue:

I was wondering whether a simple state machine could be embedded inside the isr to provide a form of software debounce nonetheless...
Title: Re: debounce problem
Post by: Far-seeker on Oct 01, 2012, 09:04 pm

I was wondering whether a simple state machine could be embedded inside the isr to provide a form of software debounce nonetheless...


IMHO that would be more trouble than it's worth, unless it was somehow impossible to get a working RC circuit.
Title: Re: debounce problem
Post by: ironbot on Oct 02, 2012, 06:16 pm
Thank you all, like always my mind got clear by refering to Arduino Forums!
Title: Re: debounce problem
Post by: JoeN on Oct 02, 2012, 10:44 pm
Has anyone ever used a hardware debounce solution like the Motorola MC14490?  Are those effective?
Title: Re: debounce problem
Post by: MarkT on Oct 03, 2012, 12:43 am
No,  the problem is the inverter!  It _must_ be a schmitt-trigger input. a 7414 not a 7404 for instance.

If you were using CMOS you could add hysteresis with a resistor feedback network, but that's tricky with TTL,  I think that 74AC04 must go.  Try a 74HC14 then you can use a much smaller capacitor (0.1uF and a 100k pull-up for instance gives 10ms time-constant)

The existing 10uF is being shorted into the switch each time it closes creating a tiny spark, which may eventually erode the contacts if the switch is small.  Adding 100 ohm or so in series with the switch will prevent such damage.  With a 0.1uF cap this damage is negligible.
Title: Re: debounce problem
Post by: Nantonos on Oct 03, 2012, 12:15 pm

I drew what I call 'standard', sorry if not very clean drawing, and yes, I made a mistake, 10uF for sure!


It is probably worth reading a bit more (http://www.ganssle.com/debouncing-pt2.htm) about debounce circuits. In particular your trigger is the wrong part, and a second resistor is advisable.
Title: Re: debounce problem
Post by: dc42 on Oct 03, 2012, 08:18 pm
Is there a reason you are using an interrupt? I normally poll pushbuttons either in a tick interrupt or from a task that is scheduled to run every few ticks. This makes it very easy to debounce the switch in software. I only use an interrupt when I want the button to wake up the mcu from sleep mode, and once it has woken up I disable the interrupt and revert to polling.
Title: Re: debounce problem
Post by: dhenry on Oct 03, 2012, 08:27 pm
Quote
I drew what I call 'standard',


There is a missing resistor there.

Seriously, I have had this exact type of circuit resetting the mcu every time the button was pushed. And that mcu in question here was known to deal with interference.

I suggest that 1) you put back that missing resistor; and 2) if you have to go down with it, use a LOW-Quality (and I am not kidding here) button with high on-contact resistance. With a high-quality button, you run a substantially higher risk of resetting the mcu.
Title: Re: debounce problem
Post by: dhenry on Oct 03, 2012, 08:29 pm
Quote
The existing 10uF is being shorted into the switch each time it closes creating a tiny spark, which may eventually erode the contacts if the switch is small.


The most insightful comment in this whole thread.

MarkT is absolutely right here.
Title: Re: debounce problem
Post by: dhenry on Oct 03, 2012, 08:30 pm
Quote
Well as Grumpy_Mike pointed out, you should try a larger capacitor.


Do the opposite: use as small of a capacitor as you can.
Title: Re: debounce problem
Post by: dhenry on Oct 03, 2012, 08:33 pm
For any of you with a highspeed scope, put it across the capacitor and observe the waveform when you close the button.

No, it is not about bouncing.
Title: Re: debounce problem
Post by: Far-seeker on Oct 03, 2012, 09:00 pm

For any of you with a highspeed scope, put it across the capacitor and observe the waveform when you close the button.

No, it is not about bouncing.


Well the original post was about signal bouncing, and apparently the problem was solved to ironbot's liking. :)  Given that for all we know ironbot is using something like this (http://www.digikey.com/product-detail/en/MPG106F/450-1086-ND/525782), I doubt worrying about contact degradation is worthwhile at this point.
Title: Re: debounce problem
Post by: dhenry on Oct 03, 2012, 10:28 pm
Quote
I doubt worrying about contact degradation is worthwhile at this point.


If you think this discussion is about contact degradation, you haven't understood this discussion.
Title: Re: debounce problem
Post by: Far-seeker on Oct 03, 2012, 11:29 pm

Quote
I doubt worrying about contact degradation is worthwhile at this point.


If you think this discussion is about contact degradation, you haven't understood this discussion.

Well, you are the one that quoted MarkT's comment about possible contact degradation and stated it was the most insightful comment in the thread (see below). 


Quote
The existing 10uF is being shorted into the switch each time it closes creating a tiny spark, which may eventually erode the contacts if the switch is small.


The most insightful comment in this whole thread.

MarkT is absolutely right here.


If you expect people that can't/won't do your experiment to know, rather than guess, about what you are refering to maybe you should tell them.  Cryptic advice is of little use to anyone.
Title: Re: debounce problem
Post by: borref on Oct 03, 2012, 11:47 pm

True, can't do software debounce for I'm on ISR, no delay() !

Not true at all.

Two common ways as follows:

1. Disable interrupt in the ISR on first contact and record time to a global variable. Reenable interrupts in the loop after a bounce guard time.

- or -

2. Record time to a static variable in the ISR on first interrupt. Ignore successive interrupts until guard time has elapsed.
Title: Re: debounce problem
Post by: marcello.romani on Oct 04, 2012, 08:11 am
Quote
1. Disable interrupt in the ISR on first contact and record time to a global variable. Re-enable interrupts in the loop after a bounce guard time.


When the code enters an ISR interrupts are automatically disabled.
And automatically re-enabled when the ISR ends.
Also, how are you going to measure this bounce guard time, if interrupts are disabled hence millis() can't advance ?
(Self-answer: probably keeping only that particular interrupt disabled while globally enabling interrupts.)

Too tricky IMHO, if at all feasible.

Point 2 looks doable, instead.
Title: Re: debounce problem
Post by: TCSC47 on Oct 04, 2012, 02:37 pm
Hi
Firstly MarkT is correct in saying that a schmitt trigger such as 74HC14 should be used for this type of switch debounce circuit. You are inputting a relatively slowly changing voltage level to the invertor which may result in false switching signals as the input slowly crosses the switching levels of the device.

Secondly, I am new here and know little of the Arduino microproc boards, so my next suggestion is a question. Is there any reason why the standard two Nand gate flip flop with a change over switch can not be used for switch debounce? This is the circuit I have almost always used for such applications.

See for example http://hyperphysics.phy-astr.gsu.edu/Hbase/electronic/setreset.html (http://hyperphysics.phy-astr.gsu.edu/Hbase/electronic/setreset.html)

Apologies for not attaching an image but I am still learning how to operate this site.

Cheers
Title: Re: debounce problem
Post by: dc42 on Oct 04, 2012, 02:44 pm
Although TCSC47's suggestions are valid and workable, the whole point of microcontrollers is that by using software they can do in a single device many functions that previously we had to build separate hardware to do. Use software debounce.
Title: Re: debounce problem
Post by: dhenry on Oct 04, 2012, 02:52 pm
Quote
Use software debounce.


I have found the old fashioned r/c debouncer to be quite effective and reliable.
Title: Re: debounce problem
Post by: dc42 on Oct 04, 2012, 02:56 pm

Quote
Use software debounce.


I have found the old fashioned r/c debouncer to be quite effective and reliable.



Yes, I'm sure it is; the atmega mcus have input hysteresis, so they can cope with the slowly-varying signal that this provides. But I prefer writing code to soldering components. [Actually, I don't even have to write any code, because I re-use the PushButton class that I developed a while ago.]
Title: Re: debounce problem
Post by: TCSC47 on Oct 04, 2012, 03:51 pm
Hi dc42
Your answer for using software debounce is one that I certainly would accept for large production professional designs requiring small space and small component count.

Also, as you have informed us, the inputs for the atmega device have hysterisis, then the sensor switches can be connected directly to the device, eliminating the 74HC14 completely, reducing the component count to a minimum.

However, and admitting that I do not have full details of what ironbot is doing, his project seems to me to be a learning exercise. Thus I would always advise a gate of some sort between the microproc and an outside input, to protect the microproc and allow alot of messing about with soldering, flying leads, and mistakenly connected inputs etc.

Also, as such, I would try and separate as many of the component parts of the design as possible. By using the two NAND gate debounce which is virtually infallible, we can get into the more intersting aspects of programming the functioning of the project, knowing that switch bounce is not a problem. Later on when all the fun bits have been done, then we could return to the finer points of professional design.

Incidently, as has been pointed out here already, an oscilloscope would be a very useful bit of kit to see exactly what is going on with problems like switch bounce. I've just bought a second hand scope with a terrific spec. for £100 on line.
Cheers
Title: Re: debounce problem
Post by: dhenry on Oct 04, 2012, 05:00 pm
Quote
the inputs for the atmega device have hysterisis, then the sensor switches can be connected directly to the device, eliminating the 74HC14 completely, reducing the component count to a minimum.


I don't know how the hysterisis (either on the atmega or hc14) would have eliminated the need for debouncing. Your circuit would have worked with a non-ST gate and the atmega, with hysterisis, would malfunction without a debouncing approach.

Title: Re: debounce problem
Post by: borref on Oct 04, 2012, 05:53 pm

When the code enters an ISR interrupts are automatically disabled.
And automatically re-enabled when the ISR ends.
Also, how are you going to measure this bounce guard time, if interrupts are disabled hence millis() can't advance ?

The trick is to only disable the relevant interrupt vector (external interrupt or pin-change interrupt). Using external debounce-circuits with microcontrollers went out of fashion 20 years ago.- This thread can serve as good example why that is.
Title: Re: debounce problem
Post by: marcello.romani on Oct 04, 2012, 08:21 pm


When the code enters an ISR interrupts are automatically disabled.
And automatically re-enabled when the ISR ends.
Also, how are you going to measure this bounce guard time, if interrupts are disabled hence millis() can't advance ?

The trick is to only disable the relevant interrupt vector (external interrupt or pin-change interrupt). Using external debounce-circuits with microcontrollers went out of fashion 20 years ago.- This thread can serve as good example why that is.


I thought about that. But then you'd have nested interrupts. Scary :P Much better IMHO to have the ISR fire at regular intervals and debounce using volatile global variables, or by using static locals and using a volatile global to communicate with the main code.
Title: Re: debounce problem
Post by: dhenry on Oct 04, 2012, 08:29 pm
Quote
Scary


Agreed. With that kind of risks, I would take the 2R/C debouncer any time of the day.
Title: Re: debounce problem
Post by: marcello.romani on Oct 04, 2012, 08:42 pm
Being a (very) lazy software guy, I'd rather write an entire library just to debounce a pin than to figure the resistor or capacitor values to use :P but I try to keep the code at least debuggable. Interrupts are somewhat fascinating, but they're the gate to the hell of heisenbugs. So I try to avoid them as much as possible. Netsted ISRs ? Maybe when I'll start my own aRTOSuino :D
Title: Re: debounce problem
Post by: Nantonos on Oct 04, 2012, 10:31 pm

Although TCSC47's suggestions are valid and workable, the whole point of microcontrollers is that by using software they can do in a single device many functions that previously we had to build separate hardware to do.


I think your sentence is missing "if it's better, or faster, or cheaper without compromising functionality" between "do" and "."

On the other hand, if timing is critical, then misguided attempts to guess when a switch has settled into a stable position, that involve timing loops, are exactly the sort of thing that a couple of resistors and a capacitor will fix for you easily and cheaply.

Yes, I used an italic full stop. I hope anyone who remembers Algol-60 smiled.
Title: Re: debounce problem
Post by: Nantonos on Oct 04, 2012, 10:34 pm

Is there any reason why the standard two Nand gate flip flop with a change over switch can not be used for switch debounce? This is the circuit I have almost always used for such applications.


That type of circuit was discussed in the page I linked to earlier in the thread, which also mentioned the drawback that a double-throw switch is needed. But that aside, it works fine of course.
Title: Re: debounce problem
Post by: retrolefty on Oct 04, 2012, 10:43 pm


Is there any reason why the standard two Nand gate flip flop with a change over switch can not be used for switch debounce? This is the circuit I have almost always used for such applications.


That type of circuit was discussed in the page I linked to earlier in the thread, which also mentioned the drawback that a double-throw switch is needed. But that aside, it works fine of course.


My favorite from days past was to wire the grounded common contact of a  SPDT switch to the direct set and reset pins of a common 74LS74 flip-flop for perfect hardware debouncing. I would sometimes even add a simple RC to one of those two pins to ensure the flip-flop would power up to the state I wished it to be.

Lefty
Title: Re: debounce problem
Post by: borref on Oct 04, 2012, 11:34 pm

I thought about that. But then you'd have nested interrupts

No you don't - and you can't really tell what the better option is (hardware or software) unless you explore all options, can you?

Debouncing can be regarded as a simple case of low pass filtering and this is (should be) second nature for a software engineer to implement (10 lines of code). With or without interrupts, this can be applied effectively and reliably in either case. Put in the effort to learn how and then decide what the best option is for your project.
Title: Re: debounce problem
Post by: marcello.romani on Oct 05, 2012, 12:33 am
Quote
No you don't


The scenario is this: the signal one is trying to debounce fires the interrupt - let's call this the "button interrupt". The button interrupt gets disabled, but other interrupts do not, so one can delay() inside the ISR to do sw debouncing. So while the "button ISR" is running, timer0 fires. And its ISR gets executed.
That's a nested interrupt scenario, isn't it ?
(btw, I'm not the OP).
Title: Re: debounce problem
Post by: dhenry on Oct 05, 2012, 01:18 am
Quote
if interrupts are disabled hence millis() can't advance ?


That would be the case if millis() is poorly coded. Interrupts get disabled all the times. millis() presumably is programmed on timer interrupts. So even if the interrupt is disabled, the flag is still there and the timer keeps going, not missing a beat.

However, if one of the isrs takes too long to execute (during which the timer's flag is set multiple times), millies() will lose count.

You can test this by running a loop inside an isr for an extended period (longer than millis()) and then read millis() to see if it is missing the beat.
Title: Re: debounce problem
Post by: borref on Oct 05, 2012, 07:21 am

That's a nested interrupt scenario, isn't it ?

You make this a lot more complicated than it really is. Your comments are comparable to someone hinting about using a voltage divider and having to explain the concept of a resistor, the fact that we need two of them, the use of power rails and how it all comes together. And surely, if none of these concepts are known, it is complicated. When working with electronics we need basic skills and the same applies to coding.

When we push a mechanical button, this typically results in a burst of pin state changes until the contacts make firm connection. The basic requirement of debouncing is to record this as a single event.  Without some form of debouncing, we would otherwise record multiple key push events. We can avoid this with a single order external low pass filter (a RC circuit) or we can handle it in software (because we're using a microcontroller) without additional components.

The software approach simply requires that we record the time of the first pin state change (someone pushed the button), and ignore additional pin state changes until a time period has elapsed. That's all there is. How we detect the pin state change (interrupt, polled or otherwise) is irrelevant in this context.

Then to basic coding skills - we do not call the delay() function in ISR's (in fact we have no use for a delay function at all in well written code). In ISR's, we simply record the event (write to a global variable) and leave actual processing of the event for the loop() function.  Rather than using delay(), we use the recorded time of the event and calculate the difference between current time and event  time every time through our loop() function. In the first few milliseconds after the event, we simply ignore additional pin state changes (we already acted on the first state change). Once the debounce period has expired (say 5ms or so) we're back to where we started and ready to act on new button push events.

We could also contain the debounce logic (no delay) within the ISR itself based on time between successive change events and so only report debounced events to the outside world (the loop function). This is just a matter of style.

Another approach again is to disable pin state interrupts within the ISR itself and then re-enable in the loop function once the debounce period has expired.
Title: Re: debounce problem
Post by: marcello.romani on Oct 05, 2012, 08:49 am
BenF, thanks for your thorough explanation.

It all started with this comment:


Quote
Have you considered adding a software debounce ?

It is a lot more tricky on an interrupt pin, because the delay is in the ISR which is never a good thing.


I'd never call a delay() inside an ISR, but that comment got me thinking about what would happen if I did.
Title: Re: debounce problem
Post by: marcello.romani on Oct 05, 2012, 08:54 am

Quote
if interrupts are disabled hence millis() can't advance ?


That would be the case if millis() is poorly coded. Interrupts get disabled all the times. millis() presumably is programmed on timer interrupts. So even if the interrupt is disabled, the flag is still there and the timer keeps going, not missing a beat.

However, if one of the isrs takes too long to execute (during which the timer's flag is set multiple times), millies() will lose count.

You can test this by running a loop inside an isr for an extended period (longer than millis()) and then read millis() to see if it is missing the beat.



I was still referring to the scenario where delay() is called inside an ISR. Millis does depend on timer0 interrupt (relevant code is in hardware/arduino/cores/arduino/wiring.c).
Title: Re: debounce problem
Post by: dhenry on Oct 05, 2012, 10:50 am
Quote
You make this a lot more complicated than it really is...


You are not answering his question.

Quote
I was still referring to the scenario where delay() is called inside an ISR.


Yes, it can miss a beat if one of the isrs is too long (1024us*2 or longer). See timer0 overflow isr was just called and m is updated, and the timer0 overflow flag is cleared. You get into one of your overly long isr (that takes 2.2ms to execute). Timer0 continues to roll and 1ms into the execution, timer0 overflows and the flag is set by hardware but that interrupt is masked off as you are still inside this long isr. The 2nd time timer0 overflows and the flag is set at 2ms mark. 0.2ms later, you exit this long isr and execution goes right back to your timer0 overflow isr and m is updated, but in this case, only by 1 -> you miss a ms.

The opposite is true: if you turn on global interrupt during the execution of the long isr, in the middle of it, the execution will jump back to timer0 overflow isr -> you get nested isr.

It is doable. But without considerable skills, it will for sure kill most programs.
Title: Re: debounce problem
Post by: marcello.romani on Oct 05, 2012, 12:15 pm
Thanks dhenry.

My original doubt was whether delay() inside an ISR would freeze the program due to timer0 interrupt being disabled (if one doesn't use the "selective interrupt disable" option just discussed, which as you confirmed would lead to nested interrupts).

It's about time I write some code on my own I guess :P
Title: Re: debounce problem
Post by: dhenry on Oct 05, 2012, 12:22 pm
Quote
(if one doesn't use the "selective interrupt disable" option just discussed, which as you confirmed would lead to nested interrupts).


We may have mis-understood each other.

During normal isr execution, peripheral interrupts are always on -  they are never disabled in the first place. So if an adc interrupt arrives, or a spi interrupt arrives, the flags are going to be set, as they are usually.

The difference here is that the global interrupt is disabled during isr. So those interrupts, other than the one currently being serviced, will not be serviced, regardless of their priorities, until the current isr has finished execution.

From within the current isr, you don't need to worry about other interrupt requests (they are not disabled), because the global interrupt is disabled.

So I don't quite understand the point of "selective disable". As soon as global interrupt is enabled inside of an isr, you run the risk of nested isr. Its programming isn't for the faint of heart.
Title: Re: debounce problem
Post by: marcello.romani on Oct 05, 2012, 12:36 pm
I used the wrong word, sorry.

Please give me a second chance to clarify what I was trying to say :)

Pin signal triggers an interrupt => we are inside the "pin ISR" and we call delay() to debounce (wrong way to do it, as already discussed, but this is not the point now). Timer0 interrupt fires at some point, but it doesn't get serviced because of global interrupt disable.
If the ISR just took too much time to execute, at some point it would terminate and the Timer0 interrupt would be eventually serviced, perhaps just a bit late.
If we call delay(), though, we are waiting for the time counter to advance. But that counter is advanced by timer0 ISR, which as we saw already is not serviced. So we wait forever..., the "pin ISR" never exits and everything grinds to a halt.

Now to see whether my reasoning is correct I should (re)read wiring.c very carefully and try some code :)
Title: Re: debounce problem
Post by: dhenry on Oct 05, 2012, 12:55 pm
Quote
But that counter is advanced by timer0 ISR


That is not correct. The counter (TMR0) is advanced by hardware.

Based on wiring.c, delay utilizes micros(), which tests TMR0 interrupt flag. So from that perspective, using delay() within isr is OK.

micros() interestingly disables global interrupt upon entry but  never re-enable it upon exit.
Title: Re: debounce problem
Post by: TCSC47 on Oct 05, 2012, 02:22 pm


Is there any reason why the standard two Nand gate flip flop with a change over switch can not be used for switch debounce? This is the circuit I have almost always used for such applications.


That type of circuit was discussed in the page I linked to earlier in the thread, which also mentioned the drawback that a double-throw switch is needed. But that aside, it works fine of course.
Apologies. I missed that.
Title: Re: debounce problem
Post by: marcello.romani on Oct 05, 2012, 02:30 pm

Quote
But that counter is advanced by timer0 ISR


That is not correct. The counter (TMR0) is advanced by hardware.

Based on wiring.c, delay utilizes micros(), which tests TMR0 interrupt flag. So from that perspective, using delay() within isr is OK.


As I said, I needed to check wiring.c more carefully :P Thanks for pointing this out.


micros() interestingly disables global interrupt upon entry but  never re-enable it upon exit.


SREG is saved before disabling interrupts. It is then restored to its saved value upon exit. The global interrupt enable flag thus returns to its "enabled" state.
Title: Re: debounce problem
Post by: dhenry on Oct 05, 2012, 02:33 pm
This is actually quite interesting.

delay() relies on micros() to work: it calculates the elapsed time to make sure that sufficient amount of timer ticks has passed.

micros() relies on timer0 overflow flag to work: it tests the timer0 flag and if it is set, it thinks a ms has passed and calculates micros() accordingly. For this approach to work, time0 flag cannot be set by the timer0 isr so it has to disable interrupts, knowing that once you return from micros(), the flag, if set, will be cleared by the timer0 isr.

The side effect of this is that in an isr environment, once you exit from micros(), you are still in the isr and the timer0 flag is never cleared. So once the timer0 flag is set, each time micros() is called, it thinks a ms has passed.

What you observe is that delays() in isr goes very fast: it got the first <256 ticks right but after that, "time" flies literally.

They could have programmed it different to avoid this problem. For example, they could have used a static variable to record the TCNT0 last time micros() is called and compare it vs. the current reading of TCNT0 to decide if the timer has overflown. This approach does not rely on the timer0 flag to be set / cleared. But it requires that micros is called frequently.
Title: Re: debounce problem
Post by: TCSC47 on Oct 05, 2012, 02:39 pm
Hi Henry
I'm still getting used to this forum and I haven't been able to quote one of your comments.

I said ---  "the inputs for the atmega device have hysterisis, then the sensor switches can be connected directly to the device, eliminating the 74HC14 completely, reducing the component count to a minimum."

You said -- "I don't know how the hysterisis (either on the atmega or hc14) would have eliminated the need for debouncing. Your circuit would have worked with a non-ST gate and the atmega, with hysterisis, would malfunction without a debouncing approach."



The schmitt input would of course need an RC circuit to hardware debounce. However, the RC circuit by itself would not provide a reliable debounce action without the schmitt trigger.

I must add however, that I have come to the conclusion from all the comments here, (but accepting that I do not have full access to Ironbot's design) that the best way for Ironbot to go, is to software debounce. If this is a learning exercise, it would be a valuable bit of experience anyway.

You have started an interesting string Ironbot.

Title: Re: debounce problem
Post by: marcello.romani on Oct 05, 2012, 02:49 pm
Quote
You have started an interesting string Ironbot.


Definitely :)
Title: Re: debounce problem
Post by: marcello.romani on Oct 05, 2012, 04:31 pm
Please let me remind once more this must-read page:

http://gammon.com.au/interrupts
Title: Re: debounce problem
Post by: ironbot on Oct 06, 2012, 10:44 am

Quote
You have started an interesting string Ironbot.


Definitely :)


"ironbot" got started when I bought Arduino on 2009, Arduino started all!

Many thanks to whole the community and forum with great respect!