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.

Practice

1. What is the main purpose of button debouncing in software?

easy

A. To ignore rapid, unwanted signals caused by mechanical button noise

B. To speed up the button press detection process

C. To increase the voltage of the button signal

D. To disable the button after first press

Solution

1. Step 1: Understand button signal noise

   Mechanical buttons often create multiple quick on/off signals when pressed, called noise or bouncing.

2. Step 2: Purpose of debouncing

   Debouncing waits for the signal to stabilize before confirming a press, ignoring these unwanted rapid signals.

3. Final Answer:

   To ignore rapid, unwanted signals caused by mechanical button noise -> Option A

4. Quick Check:

   Debouncing = Ignore noise [OK]

Hint: Debouncing filters noisy signals to detect one press [OK]

Common Mistakes:

• Thinking debouncing speeds up detection
• Confusing debouncing with hardware voltage changes
• Assuming debouncing disables buttons

2. Which of the following code snippets correctly implements a simple software debounce delay in embedded C?

easy

A. if(button_pressed()) { delay_ms(0); if(button_pressed()) { /* valid press */ } }

B. if(button_pressed()) { delay_ms(50); if(button_pressed()) { /* valid press */ } }

C. if(button_pressed()) { delay_ms(-50); if(button_pressed()) { /* valid press */ } }

D. if(button_pressed()) { delay_ms(5000); if(button_pressed()) { /* valid press */ } }

Solution

1. Step 1: Understand debounce delay

   A typical debounce delay is around 20-50 milliseconds to wait for signal stabilization.

2. Step 2: Analyze code options

   if(button_pressed()) { delay_ms(50); if(button_pressed()) { /* valid press */ } } uses 50 ms delay, which is correct. if(button_pressed()) { delay_ms(0); if(button_pressed()) { /* valid press */ } } uses 0 ms (no delay), C uses negative delay (invalid), D uses 5000 ms (too long).

3. Final Answer:

   if(button_pressed()) { delay_ms(50); if(button_pressed()) { /* valid press */ } } -> Option B

4. Quick Check:

   Debounce delay ~50ms = if(button_pressed()) { delay_ms(50); if(button_pressed()) { /* valid press */ } } [OK]

Hint: Use ~50ms delay to confirm button press [OK]

Common Mistakes:

• Using zero or negative delay
• Using too long delay causing slow response
• Not checking button state after delay

3. Consider this code snippet for debouncing a button press:

int debounce_button() {
  if (read_button_pin() == 0) {
    delay_ms(40);
    if (read_button_pin() == 0) {
      return 1;
    }
  }
  return 0;
}

What will debounce_button() return if the button is pressed and held steadily?

medium

A. 0

B. Random value

C. 1

D. Function will not return

Solution

1. Step 1: Check initial button state

   The function checks if the button pin reads 0 (pressed).

2. Step 2: Wait and re-check

   After 40 ms delay, it checks again. If still 0, it returns 1 indicating a valid press.

3. Final Answer:

   1 -> Option C

4. Quick Check:

   Stable press returns 1 [OK]

Hint: Stable press returns 1 after delay check [OK]

Common Mistakes:

• Assuming immediate return without delay
• Confusing 0 and 1 as pressed/released
• Thinking function loops infinitely

4. This code is intended to debounce a button press but sometimes registers multiple presses. What is the likely problem?

if (read_button_pin() == 0) {
  delay_ms(10);
  if (read_button_pin() == 0) {
    button_pressed_flag = 1;
  }
}

medium

A. Delay of 10 ms is too short to filter bouncing

B. Button pin reading logic is inverted

C. Missing a delay after setting the flag

D. Using delay_ms instead of delay_us

Solution

1. Step 1: Analyze debounce delay duration

   10 ms delay is often too short to filter mechanical bouncing which can last up to 50 ms.

2. Step 2: Effect of short delay

   Short delay allows noise to pass, causing multiple press detections.

3. Final Answer:

   Delay of 10 ms is too short to filter bouncing -> Option A

4. Quick Check:

   Too short delay causes multiple presses [OK]

Hint: Use at least 20-50ms delay to debounce [OK]

Common Mistakes:

• Assuming logic inversion causes multiple presses
• Thinking delay after flag needed
• Confusing delay units (ms vs us)

5. You want to implement a software debounce that counts how many times a button is pressed without counting bounces. Which approach below best achieves this?

hard

A. Increment count immediately on button press without delay

B. Increment count only when button is released

C. Use a 1ms delay and increment count on every read

D. Check button state, wait 50ms, check again; if still pressed, increment count and wait until release

Solution

1. Step 1: Understand debounce counting logic

   To count presses without bounces, confirm stable press with delay, then count once.

2. Step 2: Avoid multiple counts during one press

   Waiting until release before next count prevents multiple increments from one press.

3. Final Answer:

   Check button state, wait 50ms, check again; if still pressed, increment count and wait until release -> Option D

4. Quick Check:

   Stable press + wait release = correct count [OK]

Hint: Confirm press, count once, wait release before next count [OK]

Common Mistakes:

• Counting immediately without debounce
• Using too short delay causing multiple counts
• Counting on release only misses presses