LED-based debugging patterns in Embedded C - Step-by-Step Execution

Concept Flow - LED-based debugging patterns

Start Program

↓

Initialize LED Pins

↓

Set LED Pattern

↓

Delay to Show Pattern

↓

Repeat or Change Pattern

↓

End or Loop Back

The program starts by setting up LED pins, then lights LEDs in a pattern, waits to show it, and repeats or changes the pattern.

Execution Sample

Embedded C

void debug_pattern() {
  LED1 = 1; // Turn on LED1
  delay(500); // Wait 500ms
  LED1 = 0; // Turn off LED1
  LED2 = 1; // Turn on LED2
  delay(500); // Wait 500ms
  LED2 = 0; // Turn off LED2
}

This code turns on LED1 for half a second, then turns it off and turns on LED2 for half a second, showing a simple debugging pattern.

Execution Table

Step	Action	LED1 State	LED2 State	Delay (ms)	Output
1	Turn on LED1	ON	OFF	0	LED1 lights up
2	Wait 500ms	ON	OFF	500	LED1 stays lit
3	Turn off LED1	OFF	OFF	0	LED1 turns off
4	Turn on LED2	OFF	ON	0	LED2 lights up
5	Wait 500ms	OFF	ON	500	LED2 stays lit
6	Turn off LED2	OFF	OFF	0	LED2 turns off
7	End or loop	OFF	OFF	0	Pattern ends or repeats

💡 Pattern ends or loops after LEDs turn off

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5	After Step 6	Final
LED1	OFF	ON	ON	OFF	OFF	OFF	OFF	OFF
LED2	OFF	OFF	OFF	OFF	ON	ON	OFF	OFF

Key Moments - 3 Insights

Why does LED1 stay on during the delay in step 2?

Because the program pauses during delay(500), LED1 remains ON until the delay finishes, as shown in execution_table step 2.

What happens if we skip turning off LED1 before turning on LED2?

Both LEDs would be ON at the same time, which might confuse debugging. The execution_table shows LEDs are turned off before the next LED turns on to avoid this.

Why do we need delays between LED changes?

Delays let us see the LED state clearly. Without delay, LEDs would change too fast to notice, as shown by the 500ms wait in steps 2 and 5.

Visual Quiz - 3 Questions

Look at the execution_table, what is the state of LED2 at step 3?

A OFF

B ON

C Blinking

D Undefined

💡 Hint

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

At which step does LED1 turn off?

A Step 4

B Step 2

C Step 3

D Step 5

💡 Hint

Look at the 'Action' and 'LED1 State' columns in the execution_table.

If we remove the delay after turning on LED2, what will happen?

A LED2 will stay on longer

B LED2 will turn off immediately, making it hard to see

C LED1 will turn on again

D Program will crash

💡 Hint

Refer to the importance of delay shown in key_moments and execution_table steps 4 and 5.

Concept Snapshot

LED-based debugging patterns:
- Turn LEDs ON/OFF to show program state
- Use delays to make patterns visible
- Change LEDs in sequence for clear signals
- Avoid overlapping LEDs ON unless intentional
- Repeat patterns to monitor ongoing status

Full Transcript

This example shows how to use LEDs to debug embedded programs by turning LEDs on and off in a pattern. The program starts by turning on LED1, waits 500 milliseconds so you can see it, then turns LED1 off and turns on LED2, waits again, and turns LED2 off. This pattern helps you understand what part of the program is running. Delays are important so the LEDs stay lit long enough to notice. Turning off one LED before turning on another avoids confusion. The execution table tracks each step, showing LED states and delays. Key moments explain why delays matter and why LEDs are turned off before switching. The quiz checks understanding of LED states at different steps and the role of delays. This method is simple but powerful for debugging hardware without a screen.