STM32 Mbed CodeIDE (1/8): first blink

Embedded programming usually starts with a simple visible proof: can your code make a physical device change on command? A first blink is small, but it verifies the whole chain - edit, compile, upload, and observe the real board.

Mbed OS gives your C++ program a set of ready-made APIs for microcontroller work: digital pins, analog inputs, PWM outputs, timing, threads, and serial messages. In this lab, CodeIDE provides that Mbed environment for the remote STM32 board. Your program lives in main.cpp, includes mbed.h, starts in int main(), and controls hardware by creating Mbed objects.

For example, DigitalOut status_led(PB_5, 0); creates an output object named status_led connected to STM32 pin PB_5. Later lessons use other Mbed objects such as DigitalIn, AnalogIn, and PwmOut.

You can complete the course with the explanations here. If you want the official reference while you work, keep these pages nearby:

- Mbed OS I/O APIs
- Mbed CE API reference

The starter idea is a blink: turn an output on, wait, turn it off, wait, and repeat.

In Mbed, you first create an object connected to a pin:

DigitalOut status_led(PB_5, 0);

Read that line as: "make a digital output named status_led on pin PB_5, and start it at value 0."

The board you are programming is the STM32 Nucleo WB55RG.

Inside while (true), the program repeats forever:

status_led = !status_led.read();
ThisThread::sleep_for(500ms);

Read the first line as: "read the current value, change it to the opposite value, and store that new value back on the output." The ! operator means "not" or "opposite" for a 0/1 value.

One state change is one transition, such as on-to-off or off-to-on. A full on-off blink cycle needs two state changes: one to turn on and one to turn off again.

Plan for two builds and about 18 minutes of active lab time: first 500ms, then 1000ms. If the remote-lab queue is busy, answer both prediction questions and prepare the headings for both observations before your turn.

Copy every line from #include "mbed.h" through the final }. The starter has exactly one compile-blocking placeholder. Replace TODO 1 before saving or compiling; TODO_WAIT_VALUE is not valid C++.

#include "mbed.h"

DigitalOut status_led(PB_5, 0);

int main() {
    // 1: replace the placeholder with 500ms for build 1.
    const auto wait_time = TODO_WAIT_VALUE;

    while (true) {
        status_led = !status_led.read();
        ThisThread::sleep_for(wait_time);
    }
}

Before changing the wait time, predict what will happen. Use your answer about state-change timing to decide whether 1000ms should make the LED change faster, slower, or about the same.

How to find the changing LED: after upload, compare the live camera view before and after the program starts. Ignore LEDs that stay steadily on or steadily off, and ignore brief upload/status flashes. Use the LED that keeps changing at the timing you programmed; when you switch from 500ms to 1000ms, the same LED should keep changing at the new timing.

The lab card has a Mark practice as done button. Do not click it yet; use it only after you complete all numbered steps, including the 1000ms retest.

Record the two observations in the boxes below. The reason for timing five intervals is practical: one LED change is short and hard to time accurately from a live camera, but five changes give a more stable estimate.

Use this method for each version:

1. Start the timer when the LED changes state. This starting change is the beginning of interval 1.
2. Count the next visible changes aloud or on paper: 1, 2, 3, 4, 5.
3. Stop the timer on the change you counted as 5. Your timed duration now covers five state-change intervals.
4. Divide the timed duration by 5 to estimate one state-change interval.
5. A full blink cycle takes two state changes, so multiply your state-change interval by 2.

Example: if five intervals take about 2.6 s, one state-change interval is about 0.52 s, and a full blink cycle is about 1.04 s.

Most programs in this course follow the same Mbed OS structure: include mbed.h, create hardware objects such as DigitalOut, start in int main(), and put repeated controller behavior inside while (true).

Before submitting, leave the final 1000ms version saved in main.cpp. Search once more for TODO; the submitted file must contain no TODO placeholders.