Button debouncing in software in Embedded C - Step-by-Step Execution

Concept Flow - Button debouncing in software

Button Press Detected

↓

Start Debounce Timer

↓

Wait for Timer to Expire

↓

Read Button State Again

↓

Ignore Noise

↓

Process Button Press

↓

End

This flow shows how software waits after a button press to ignore quick noise, then confirms the press before acting.

Execution Sample

Embedded C

if (button_pressed()) {
  delay_ms(20); // debounce delay
  if (button_pressed()) {
    handle_press();
  }
}

This code waits 20 ms after detecting a press, then checks again to confirm the press before handling it.

Execution Table

Step	Action	Button State Read	Timer	Decision	Output
1	Detect button press	Pressed	Timer started (20 ms)	Wait	None
2	Wait 20 ms	N/A	Counting down	Wait	None
3	Read button state again	Pressed	Timer expired	Stable press confirmed	Call handle_press()
4	Process press	Pressed	Timer stopped	Handled	Button press processed
5	Next loop	Released	Timer ready	No press	No action

💡 Button state stable after debounce delay, press confirmed and processed

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
button_state	Released	Pressed	Pressed	Pressed	Pressed	Released
debounce_timer	0	20 ms started	Counting down	Expired	Stopped	0
press_confirmed	False	False	False	True	True	False

Key Moments - 2 Insights

Why do we check the button state twice with a delay in between?

Because the button can 'bounce' causing quick on/off signals. The first check starts the timer, the second confirms the press after noise settles (see execution_table steps 1 and 3).

What happens if the button state changes during the delay?

If the button is not stable after the delay, the press is ignored to avoid false triggers (see execution_table step 3 decision).

Visual Quiz - 3 Questions

Look at the execution_table, what is the button state at Step 3 when the press is confirmed?

A Released

B Pressed

C Unknown

D Floating

💡 Hint

Check the 'Button State Read' column at Step 3 in the execution_table.

At which step does the debounce timer expire?

A Step 3

B Step 2

C Step 1

D Step 4

💡 Hint

Look at the 'Timer' and 'Decision' columns to find when the timer expires.

If the button state was 'Released' at Step 3, what would happen?

A handle_press() would be called

B Timer would restart

C The press would be ignored

D Program would crash

💡 Hint

Refer to the 'Decision' column at Step 3 and the explanation in key_moments.

Concept Snapshot

Button debouncing avoids false triggers from noisy button signals.
Detect press, start a short delay (e.g., 20 ms).
After delay, read button again.
If stable pressed, confirm and handle press.
If not stable, ignore noise.
Simple software delay and double-check method.

Full Transcript

Button debouncing in software means ignoring quick, noisy changes when a button is pressed. The program first detects a press, then waits a short time (like 20 milliseconds) to let the noise settle. After waiting, it checks the button again. If the button is still pressed, it confirms the press and runs the code to handle it. If the button is not pressed anymore, it ignores the noise and does nothing. This prevents the program from reacting to false presses caused by the button's mechanical bounce.