I understand the concept of switch debouncing, so that's not my question.
What I haven't seen is the basic questions of when does switch debouncing code need to be used?
Correct me if I am wrong but seems to me the only time switch debouncing code is needed is if the application requires the pressing of a push button in rapid secession as in setting the time (which was a pain in the rear which is why everyone's VCRs were flashing 12:00). Or to increase/decrease volume.
Applications like that make perfect sense as to why debounce is needed.
But what about for a simple application such as tuning on/off a light/LED as in beginners lesson 6?
Why no debounce code?
No idea what lesson 6 is but if you simply switch a led on and off with a button, you need to realise that the human eye is too slow to follow the bounce.
The press of a button might take a system from state A to state B. But in the interests of economy and simplicity, the same button may then be used to take the system from state B to state C.
So a bounce could cause the system to seemingly jump straight from state A to state C without pausing in state B to do whatever state B is supposed to do, like wait for some other input.
If the same button is used for a number of actions then debouncing is probably essential. However if there is one button for (say) start and another button for stop then debouncing probably is not necessary as the first switch closure is all that needs to be detected - you can't stop something that is already stopped no matter how many times you press the stop button.
Associated with buttons that can do several things is the need for good feedback to the user so that s/he knows what part of the process the next button press will call into effect.
The switch is mechanical , you won’t see it , but the contacts can bounce open again and then close when the switch operates. The Arduino is fast enough to see this as a closed switch, an open switch , then a closed one .
In some applications this will cause you problems, so a “denounce “ routine helps
Robin2:
If the same button is used for a number of actions then debouncing is probably essential. However if there is one button for (say) start and another button for stop then debouncing probably is not necessary as the first switch closure is all that needs to be detected - you can't stop something that is already stopped no matter how many times you press the stop button.
Associated with buttons that can do several things is the need for good feedback to the user so that s/he knows what part of the process the next button press will call into effect.
...R
I get it.
If the button is used for single function, turn a light on - Debounce is not needed. (Once it's on it's on.)
But if the same switch is used to turn a light on AND off this is when debounce code is needed. (Without debounce code the light would flicker on and off and without debouncing code the end result might be with the light on or off.
During power up ‘and’ after DTR going LOW (on sketch uploading) the capacitor is discharged, hence RESET is low. i.e. Hardware is causing the reset pin to go LOW.
During power up ‘and’ after DTR going LOW (on sketch uploading) the capacitor is discharged, hence REST is low. i.e. Hardware is causing the reset pin to go LOW.
That makes perfect sense. Having debounce code when pressing a reset button doesn't.
partly because of the microcode which initialises the chip, but also to ensure a complete reset and prevent erratic behaviour which might result from switch bounce.
larryd:
During power up ‘and’ after DTR going LOW (on sketch uploading) the capacitor is discharged, hence RESET is low. i.e. Hardware is causing the reset pin to go LOW.
That circuit is just a convenience to allow the Atmega 328 to restart even though the DTR signal remains LOW.
You could just as well cause an Atmega 328 to reset with a momentary switch that pulls the RESET pin low against a pull-up resistor and no capacitor, or a spdt toggle switch that connects RESET either to 5v or GND.
I think this, from Section 9.2.2 of the Atmega 328 datasheet is relevant - but I don't claim to have studied it fully.
Any clock source needs a sufficient V CC to start oscillating and a minimum number of oscillating cycles before it can be considered stable.
To ensure sufficient V CC , the device issues an internal reset with a time-out delay (t TOUT ) after the device reset is released by all other reset sources. ”System Control and Reset” on page 46 describes the start conditions for the internal reset. The delay (t TOUT ) is timed from the Watchdog Oscillator and the number of cycles in the delay is set by the SUTx and CKSELx fuse bits. The selectable delays are shown in Table 9-2. The frequency of the Watchdog Oscillator is voltage dependent as shown in ”Typical Characteristics – (TA = -40°C to 85°C)” on page 324.
