Teach lesson
STM32 Mbed CodeIDE (1/8): first blink
Students use STM32 Mbed CodeIDE to edit main.cpp, compile and upload a DigitalOut blink program, and record LED evidence from the real board.
Learning Outcomes
Recognize the STM32 Mbed CodeIDE workflow and the
main.cppentry file.Write a minimal Mbed program with
DigitalOutandThisThread::sleep_for().Collect evidence that code compiled, uploaded, and changed a real output.
Student activity preview
Activity Content
Preview only. In a class session, students can fill in responses and submit their work to the teacher.
Before opening the lab
8 min
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:
What the STM32 Mbed CodeIDE lab shows
Use the activity's Open lab button to open this STM32 Mbed CodeIDE lab. For this first lesson, ignore the switches, buttons, potentiometers, the serial console input box in the lab view, and the power meter. You only need CodeIDE and the live camera. In CodeIDE, use the bottom build/status console only to check compile and upload messages; your blink evidence comes from the live camera.
CodeIDE quick map
After the lab opens, use the Files panel to open main.cpp, the editor to replace and save code, Compile to build, Upload to board to program the remote STM32 board, and the console area to read build or upload status messages. Save main.cpp every time you change the code, before you compile.
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.
STM32 Nucleo WB55RG board
This photo shows the microcontroller board itself. It is for orientation, not for identifying the exact LED from a still image. The live remote lab may also show separate controls or training hardware, but they are not shown in this photo. You do not plug anything into your own computer; CodeIDE sends the compiled program to the remote board.
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.
For the 500 ms program: what is the state-change interval in milliseconds, how many state changes happen per second, and how long is one full blink cycle? Remember: a full blink cycle needs two state changes.
Create and test the blink
26 min
When copying this program, copy every line from #include "mbed.h" through the final }. If you are using a printed or exported PDF, check that the code block did not continue onto the next page before you compile.
#include "mbed.h"
DigitalOut status_led(PB_5, 0);
int main() {
while (true) {
status_led = !status_led.read();
ThisThread::sleep_for(500ms);
}
}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.
Before you test it, predict what will change when you use 1000ms instead of 500ms. Will the LED change faster, slower, or about the same? Explain using the wait time between state changes.
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.
Open the STM32 Mbed CodeIDE lab from this activity's Open lab button.
In CodeIDE, open
main.cpp.Replace the file contents with the program above.
Save the file.
Compile. If there is an error, check spelling, braces
{}, parentheses(), and missing semicolons.Before clicking Upload, look at the live camera once and choose the board area you will watch.
Upload the program to the board. Wait for the console/status area to show that upload/programming finished.
Watch the same camera area and look for the LED that repeatedly changes at the timing you programmed. Ignore any always-on power/status LEDs and brief upload/status flashes. Record at least five state changes from the repeating LED; for example, off-to-on counts as one change.
Change
500msto1000ms, savemain.cpp, compile, upload, and observe the same LED area again.Only after step 9 is complete, click Mark practice as done.
Record the two observations in the boxes below. For timing, measure five intervals: start timing at one visible transition, stop at the sixth visible transition, then divide by 5 to estimate one state-change interval.
For 500ms, answer with this checklist:
- Transitions 1-5 observed:
- Timed duration for 5 intervals:
- Estimated state-change interval:
- Full blink cycle:
- Matched your prediction? yes/no
For 1000ms, answer with this checklist:
- Transitions 1-5 observed:
- Timed duration for 5 intervals:
- Estimated state-change interval:
- Compared with 500ms: faster/slower/same
- Matched your prediction? yes/no
- Troubleshooting needed? yes/no. If yes, what changed?
If your prediction was wrong, add the corrected explanation.
Write a real-board evidence note. Include four details: whether compile/upload finished, where the changing LED appeared in the live camera view, what changed in the camera, and how the 1000 ms version looked different from the 500 ms version. Example: "Compile finished, upload/program finished, and the LED near the left side of the board area changed state more slowly after I changed 500ms to 1000ms."
Understand the Mbed structure
8 min
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).
In your own words, what does while (true) do in this blink program? Why is it needed?
Submit your code
8 min
Before submitting, leave the final 1000ms version saved in main.cpp. That is the version you will attach from the lab workspace.
Attach your saved final main.cpp
Click Check saved files, confirm that main.cpp contains the final 1000ms blink program, then click Attach saved code. After the code is attached, click Submit submission at the bottom of the activity. The required attachment for this lesson is the saved main.cpp code snapshot.