Debouncing as a state machine in Embedded C - Step-by-Step Execution

Concept Flow - Debouncing as a state machine

Start: Button Released

↓

Detect Button Press?

No→Stay Released

Yes↓

Start Debounce Timer

↓

Timer Expired?

No→Wait

Yes↓

Confirm Button Press

↓

Button Pressed State

↓

Detect Button Release?

No→Stay Pressed

Yes↓

Start Debounce Timer

↓

Timer Expired?

No→Wait

Yes↓

Confirm Button Released

↓

Back to Start

This flow shows how the button state changes with debounce timing to avoid false triggers.

Execution Sample

Embedded C

enum State {RELEASED, DEBOUNCE_PRESS, PRESSED, DEBOUNCE_RELEASE};
enum State state = RELEASED;
int timer = 0;

// In loop:
// Check button input and update state machine accordingly

This code snippet shows a simple state machine for button debouncing using states and a timer.

Execution Table

Step	State	Button Input	Timer	Condition	Action	Next State
1	RELEASED	Pressed	0	Button Pressed?	Start debounce timer	DEBOUNCE_PRESS
2	DEBOUNCE_PRESS	Pressed	1	Timer expired?	No action, wait	DEBOUNCE_PRESS
3	DEBOUNCE_PRESS	Pressed	5	Timer expired?	Confirm press	PRESSED
4	PRESSED	Pressed	0	Button Released?	No action, stay pressed	PRESSED
5	PRESSED	Released	0	Button Released?	Start debounce timer	DEBOUNCE_RELEASE
6	DEBOUNCE_RELEASE	Released	1	Timer expired?	No action, wait	DEBOUNCE_RELEASE
7	DEBOUNCE_RELEASE	Released	5	Timer expired?	Confirm release	RELEASED
8	RELEASED	Released	0	Button Pressed?	No action, stay released	RELEASED

💡 Loop continues indefinitely to monitor button state changes with debounce.

Variable Tracker

Variable	Start	After Step 1	After Step 3	After Step 5	After Step 7	Final
state	RELEASED	DEBOUNCE_PRESS	PRESSED	DEBOUNCE_RELEASE	RELEASED	RELEASED
timer	0	0	0	0	0	0
button_input	Released	Pressed	Pressed	Released	Released	Released

Key Moments - 3 Insights

Why do we wait for the timer to expire before confirming the button press?

Waiting for the timer ensures the button state is stable and avoids reacting to quick, noisy changes (see steps 2 and 3 in execution_table).

Why do we have separate debounce states for press and release?

Separate debounce states let us handle press and release events independently, ensuring each transition is stable before changing the main state (see DEBOUNCE_PRESS and DEBOUNCE_RELEASE in execution_table).

What happens if the button input changes during debounce timer?

If the input changes before timer expires, the state machine resets or returns to the previous stable state, preventing false triggers (implied by waiting and checking conditions in debounce states).

Visual Quiz - 3 Questions

Look at the execution_table, what is the state after step 3?

A RELEASED

B PRESSED

C DEBOUNCE_PRESS

D DEBOUNCE_RELEASE

💡 Hint

Check the 'Next State' column at step 3 in execution_table.

At which step does the debounce timer confirm the button release?

A Step 7

B Step 5

C Step 6

D Step 8

💡 Hint

Look for 'Confirm release' action in execution_table.

If the button input changes to Released during DEBOUNCE_PRESS, what should happen?

A Stay in DEBOUNCE_PRESS state

B Continue to PRESSED state

C Reset to RELEASED state

D Move to DEBOUNCE_RELEASE state

💡 Hint

Consider debounce logic to avoid false press confirmation; see key_moments about input changes during debounce.

Concept Snapshot

Debouncing as a state machine:
- Use states: RELEASED, DEBOUNCE_PRESS, PRESSED, DEBOUNCE_RELEASE
- On input change, start debounce timer
- Confirm state change only after timer expires
- Prevents false triggers from noisy button signals
- Loop continuously to monitor button input

Full Transcript

This visual execution shows how a button debounce works as a state machine in embedded C. The machine starts in the RELEASED state. When the button is pressed, it moves to DEBOUNCE_PRESS and starts a timer. Only after the timer expires and the button is still pressed does it confirm the PRESSED state. Similarly, when the button is released, it moves to DEBOUNCE_RELEASE and waits for the timer before confirming RELEASED. This prevents false triggers caused by noisy button signals. The execution table traces each step, showing state, input, timer, conditions, and actions. The variable tracker shows how state, timer, and input change over time. Key moments clarify why waiting for the timer is important and why separate debounce states exist. The quiz tests understanding of state transitions and debounce logic. This approach ensures reliable button input handling in embedded systems.