Pages: 1 2 3 [4]   Go Down
Author Topic: debounce problem  (Read 7511 times)
0 Members and 1 Guest are viewing this topic.
Offline Offline
Edison Member
*
Karma: 116
Posts: 2205
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
Logged

Midlands, UK
Offline Offline
Newbie
*
Karma: 0
Posts: 4
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
Logged

Offline Offline
Edison Member
*
Karma: 26
Posts: 1339
You do some programming to solve a problem, and some to solve it in a particular language. (CC2)
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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 smiley-razz 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.
Logged

Offline Offline
Edison Member
*
Karma: 116
Posts: 2205
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
Logged

Midlands, UK
Offline Offline
Newbie
*
Karma: 0
Posts: 4
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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.

Logged

Offline Offline
Edison Member
*
Karma: 26
Posts: 1339
You do some programming to solve a problem, and some to solve it in a particular language. (CC2)
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
You have started an interesting string Ironbot.

Definitely smiley
Logged

Offline Offline
Edison Member
*
Karma: 26
Posts: 1339
You do some programming to solve a problem, and some to solve it in a particular language. (CC2)
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Please let me remind once more this must-read page:

http://gammon.com.au/interrupts
Logged

0
Offline Offline
Sr. Member
****
Karma: 0
Posts: 301
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
You have started an interesting string Ironbot.

Definitely smiley

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

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

Pages: 1 2 3 [4]   Go Up
Jump to: