Teach lesson

STM32 Mbed CodeIDE (2/8): LED sequences and timing

Students program timed LED sequences on a real STM32 board with Mbed DigitalOut and delays, then change timing and explain the observed order.

STM32 Nucleo (Mbed)
55 min
Upper secondary / introductory vocational electronics
English
Embedded systems

STM32 Nucleo (Mbed)

Learning Outcomes

Control several Mbed DigitalOut pins in a planned sequence.
Use timing changes to make an output pattern easier to observe.
Explain the relationship between code order and physical LED order.

Student activity preview

Activity Content

Preview only. In a class session, students can fill in responses and submit their work to the teacher.

Plan the sequence

8 min

A microcontroller follows the order of your code exactly. The program below will use helper calls such as led_on(led1) so the code reads like the physical action you want to see.

If you write:

led_on(led1);
ThisThread::sleep_for(500ms);
led_on(led2);

then LED 1 should turn on before LED 2.
LED 1 will stay on while LED 2 turns on, because the code has not called led_off(led1) yet.

This lesson uses three Mbed output pins available in the STM32 WB55RG lab:

- PB_13
- PB_14
- PB_15

These are custom green LED outputs on the training board. In the local CodeIDE Mbed examples, they are active-low: writing 0 turns one on and writing 1 turns it off. That is why the starter code uses helper functions instead of asking you to remember raw 0/1 polarity.

In Mbed, each DigitalOut line creates one output object connected to one STM32 pin. The object keeps its last value while the program waits, so ThisThread::sleep_for(500ms) pauses the code without erasing the LED state you just set.

Use this mapping when you compare your code with the camera:

- led1 = PB_13 = leftmost green LED in the three-LED group.
- led2 = PB_14 = middle green LED in that group.
- led3 = PB_15 = rightmost green LED in that group.

Three green LEDs used in this lesson

In the helper header DigitalOut &led, the & means the helper works on the actual LED object you pass in, not on a copy. In 500ms, ms means milliseconds.

If LED 1 turns on, then 500 ms later LED 2 turns on, then 500 ms later LED 3 turns on, what should the viewer see before all_off() runs?

Run the guided sequence

26 min

Open the STM32 Mbed CodeIDE lab.
Open main.cpp.
Replace the file with the code below.
Save, compile, and upload.
Observe at least three complete cycles and note the LED order and timing.
Change step_delay from 500ms to either 250ms or 1000ms.
Save main.cpp, compile, upload, and compare whether the new pattern is easier or harder to verify.
Only after step 7 is complete, click Mark practice as done.

#include "mbed.h"

DigitalOut led1(PB_13, 1);
DigitalOut led2(PB_14, 1);
DigitalOut led3(PB_15, 1);

void led_on(DigitalOut &led) {
    led = 0;
}

void led_off(DigitalOut &led) {
    led = 1;
}

void all_off() {
    led_off(led1);
    led_off(led2);
    led_off(led3);
}

int main() {
    const auto step_delay = 500ms;
    const auto reset_delay = 1000ms;
    all_off();

    while (true) {
        led_on(led1);
        ThisThread::sleep_for(step_delay);

        led_on(led2);
        ThisThread::sleep_for(step_delay);

        led_on(led3);
        ThisThread::sleep_for(reset_delay);

        all_off();
        ThisThread::sleep_for(reset_delay);
    }
}

Record the two tested versions separately. Because the starter code leaves previous LEDs on until all_off() runs, the expected visible sequence is cumulative: LED 1 on -> LEDs 1+2 on -> LEDs 1+2+3 on -> all off.

For the original 500ms version, record:

- visible order or cumulative pattern you confirmed in the camera;
- whether the LED positions matched the led1/led2/led3 mapping;
- what made the pattern easy or hard to verify.

For the changed timing version, record:

- the delay value you tested;
- whether the visible order or cumulative pattern stayed the same;
- whether the new timing made the pattern easier or harder to verify;
- not distinguishable on camera only if you slowed the pattern and still could not confirm the order.

Choose one helper call that changes an LED. Name the line, such as led_on(led2);, and explain what physical change that line caused and when it happened in the sequence.

Create your own readable pattern

13 min

Modify the code so it creates a different pattern that a classmate could still describe correctly. Keep delays long enough to see.

Choose one of these patterns:

- On together, then off one at a time.
- One LED moves left to right and then right to left.
- Two quick flashes, then a one-second pause.

Use the helpers to keep the pattern readable. For example, to turn only led2 on, you can write:

all_off();
led_on(led2);
ThisThread::sleep_for(500ms);

For your final submitted pattern, keep each visible LED state at 250ms or longer. Use 500ms or 1000ms if the camera view is difficult to verify.

Before submitting, save, compile, and upload your custom pattern. Observe at least one full cycle in the camera. If the observed pattern does not match your description, revise the code and test again. Then describe your final pattern in plain language, including the delay value you chose and why.

Submit your code

8 min

Attach your saved final main.cpp

Click Check saved files, confirm that main.cpp contains your final custom pattern, then click Attach saved code. After the code is attached, click Submit submission at the bottom of the activity.