Blinking an LED on STM32 Blue Pill (STM32F103C8T6) with Embedded Rust

2026-08-05T00:00:00+00:00

The STM32 Blue Pill is the newest addition to my embedded hardware collection. To be honest, I bought it while ordering some other electronic components. The board was so inexpensive that I simply added one to my cart.

There are plenty of tutorials for the Blue Pill using C and other programming languages. In this post, however, i will explain with Embedded Rust.

I am planning to start with a simple LED blinky program using this board. I might turn it into a series as I explore more of what the STM32 Blue Pill has to offer.

Setting Up an Embedded Rust Development Environment</a>

</a> Meet the STM32 Blue Pill</h2>
The STM32 Blue Pill is a low-cost development board based on the STM32F103C8T6 microcontroller, often abbreviated as STM32F103C8, from STMicroelectronics. Despite being around for many years, it is still widely used for learning embedded systems, prototyping, and hobby projects.

It is based on the 32-bit Arm Cortex-M3 processor and provides 64 KB of Flash memory, 20 KB of SRAM.
</a> Hardware Debugger & Programmer</h2>
In order to run our program, we need a way to transfer it from our computer to the STM32F103C8T6 microcontroller.
Unlike some development boards, we cannot directly flash a Rust program to the Blue Pill by simply connecting a USB cable. Instead, we need a “hardware debugger and programmer” that communicates with the microcontroller through the Serial Wire Debug (SWD) interface.
In this tutorial, I will be using an ST-LINK V2 Debugger & Programmer. It is cheap, widely available, and works well for programming and debugging STM32 microcontrollers.

Besides SWD, there are other ways to program the Blue Pill. However, I have not tried them, so we will use an SWD debugger throughout this tutorial.
</a> Connecting the Blue Pill to the ST-LINK V2</h3>
Connect the Blue Pill development board to the ST-LINK V2 using a few jumper wires, as shown below:
Blue Pill</th> ST-LINK V2</th></tr></thead>

3.3V</td> 3.3V</td></tr>
SWDIO</td> SWDIO</td></tr>
SWCLK</td> SWCLK</td></tr>
GND</td> GND</td></tr> </tbody></table>
The ST-LINK V2 will provide power to the Blue Pill through the 3.3V connection, so you do not need to connect a separate USB cable to the development board.
</a> The Onboard LED and GPIO Pins</h2>
GPIO stands for General Purpose Input/Output, which are pins that allow a microcontroller to communicate with the outside world. The STM32F103C8T6 microcontroller provides several GPIO pins that can be configured as either inputs or outputs.
The Blue Pill development board includes an onboard LED connected to pin `PC13</code>. If you are new to STM32 microcontrollers, the name PC13</code> might look a little confusing. STM32 microcontrollers organize GPIO pins into ports, identified by letters such as A</code>, B</code>, and C</code>. Each port contains multiple numbered pins.`
`For example:`
`PA0</code> means Port A, Pin 0.</li> PB5</code> means Port B, Pin 5.</li>`
`PC13</code> means Port C, Pin 13.</li> </ul>`</a> Embedded Rust Ecosystem</h2> Embedded Rust is built on a collection of crates that work together to provide access to microcontroller hardware. Our project uses several crates, each with a specific purpose. The most important one is stm32f1xx-hal</code></a>, a Hardware Abstraction Layer (HAL) that provides a safe and convenient API for working with peripherals such as GPIO pins, timers, UART, SPI, and I2C. </div> INFO Embedded Rust projects typically use two crates: Peripheral Access Crate (PAC): Gives direct access to the microcontroller’s hardware registers.</li> Hardware Abstraction Layer (HAL): Builds on top of the PAC and provides a safer, more convenient interface.</li> </ul> </div> </div> </a> Creating the Project</h2> I will not be creating the project from scratch. That would require configuring many files and settings, which requires a separate post on its own. To keep things simple and get started quickly, we will use an existing project template. The stm32f1xx-hal</code> repository links to the following project template, so we’ll also use it in this tutorial: cargo generate --git https://github.com/burrbull/stm32-template.git</code></pre> Cargo Generate will ask you a few questions. For this tutorial, use the following answers: Project Name: hello-blinky What microcontroller name?: stm32f103c8t6 What HAL version to use?: last-release Is it RTIC-based application?: false Will this program use defmt logger?: true Do you want to load SVD and add it to VSCode task?: false</code></pre> Project Name: The name of your Rust project.</li> Microcontroller name: Simply type stm32f103c8t6</code>.</li> HAL version: Select the latest released version of stm32f1xx-hal</code>.</li> RTIC-based application: Ignore this for now. We will not be using RTIC, so select false</code>.</li> defmt logger: Enables the defmt</code> logging framework. This provides an efficient way to print debug messages from embedded programs. We will use it throughout this series, so select true</code>.</li> SVD and VS Code task: We do not need this for the tutorial, so select false</code>.</li> </ul> Once the template finishes generating, you will have a new Embedded Rust project. The directory structure should look similar to this: . ├── build.rs ├── Cargo.toml ├── Embed.toml ├── memory.x ├── README.md └── src └── main.rs</code></pre> Don’t worry about the other files for now. We will focus only on the main.rs</code> file. </a> Generated Boilerplate</h2> Open the src/main.rs</code> file. The template already provides a minimal Embedded Rust program that looks like this: #![deny(unsafe_code)] #![no_main] #![no_std] // Print panic message to probe console use panic_probe as _; use cortex_m_rt::entry; use stm32f1xx_hal::{ pac, prelude::*, }; #[allow(clippy::empty_loop)] #[entry] fn main() -> ! { loop {} }</code></pre> This looks quite different from a project we would normally create with cargo new</code>. That’s because embedded systems have different requirements than desktop applications, so the template includes a few additional attributes and crates. </a> #![no_std]</code></h3> Regular Rust applications use the standard library (std</code>), which provides features such as file handling, networking, and threads. These features depend on an operating system. Microcontrollers like the STM32F103C8T6 do not run an operating system, so Embedded Rust programs use the core</code> library instead. The #![no_std]</code> attribute tells the compiler not to link the standard library. </a> #![no_main]</code></h3> The #![no_main]</code> attribute tells the compiler not to use the normal Rust program entry point. Instead, the program starts from an entry point provided by the embedded runtime. </a> panic_probe</code></h3> The template also includes the following line: use panic_probe as _;</code></pre> A panic occurs when a program encounters an unrecoverable error. The panic_probe</code> crate reports panic messages through the debug probe, making them useful for debugging. </a> Modifying the main Function</h2> Now, replace the main</code> function with the following code: fn main() -> ! { let p = pac::Peripherals::take().unwrap(); let mut rcc = p.RCC.constrain(); let mut gpioc = p.GPIOC.split(&mut rcc); let mut led = gpioc.pc13.into_push_pull_output(&mut gpioc.crh); loop { led.set_low(); cortex_m::asm::delay(5_000_000); led.set_high(); cortex_m::asm::delay(5_000_000); } }</code></pre> You know what? Before understanding the code, let’s go ahead and flash the program onto the Blue Pill to see it in action. cargo run --release</code></pre> If you get stuck or want to compare your code, you can use the complete project from my GitHub repository: git clone https://github.com/ImplFerris/stm32f103c8t6-projects.git cd stm32f103c8t6-projects/stm32f1xx-hal/blinky cargo run --release</code></pre> Now, let’s go back and understand what each line of the program does. </a> Accessing the Peripherals</h2> The first line inside the main</code> function is: let p = pac::Peripherals::take().unwrap();</code></pre> The pac</code> module provides access to the hardware peripherals of the STM32F103C8T6 microcontroller, such as GPIO. Notice that we call Peripherals::take()</code> instead of creating a new Peripherals</code> object. There is only one set of hardware peripherals inside the microcontroller, so take()</code> can only be called once, giving our program exclusive ownership of them. The Embedded Rust ecosystem leverages Rust’s ownership system to enforce this singleton pattern. This ensures that only one part of the program can own and control each peripheral at a time, helping avoid conflicting configurations and other unpredictable behavior. </a> Reset and Clock Control (RCC)</h2> The next line is: let mut rcc = p.RCC.constrain();</code></pre> RCC</code> stands for Reset and Clock Control. It is responsible for managing the clocks and reset behavior of the microcontroller’s peripherals. The RCC</code> value returned by the Peripheral Access Crate (PAC) provides direct access to the hardware registers. Calling constrain()</code> converts it into the HAL’s Rcc</code> type, providing a safer and more convenient interface to work with. We will use this rcc</code> value in the next line when configuring the GPIO peripheral. </a> Splitting the GPIO Peripheral</h2> The next line is: let mut gpioc = p.GPIOC.split(&mut rcc);</code></pre> Just like RCC</code>, GPIOC</code> is initially provided by the PAC. Calling split()</code> converts it into a higher-level HAL interface. The split()</code> method also enables the clock for the GPIOC peripheral and returns an object that provides access to the individual GPIO pins. </a> Configuring PC13</code> as an Output</h2> Next, we configure pin PC13</code> as an output: let mut led = gpioc.pc13.into_push_pull_output(&mut gpioc.crh);</code></pre> The into_push_pull_output()</code> method configures pin PC13</code> as a digital output so that our program can control the onboard LED. </a> Blinking the LED</h2> Finally, we repeatedly turn the LED on and off: loop { led.set_low(); cortex_m::asm::delay(5_000_000); led.set_high(); cortex_m::asm::delay(5_000_000); }</code></pre> The set_low()</code> and set_high()</code> methods change the state of the PC13</code> pin. On the Blue Pill development board, set_low()</code> turns the onboard LED on, while set_high()</code> turns it off. This is because the LED is connected in an active-low configuration. An active-low signal means the device or function becomes active when the signal is LOW (logic 0</code>) instead of HIGH (logic 1</code>). In our case, driving PC13</code> LOW turns the LED on, while driving it HIGH turns the LED off. The delay()</code> function simply waits for a short period before changing the LED state again, making the blinking visible. </a> What’s Next</h2> Congratulations! You have written and flashed your first Embedded Rust program on the STM32 Blue Pill. Once you are comfortable with this example, I encourage you to explore the examples</a> included with the stm32f1xx-hal</code> project. They cover many peripherals and features. As you work through them, try to understand what each example is doing instead of simply running it. This is one of the best ways to become familiar with the STM32F103C8T6 and Embedded Rust.

impl Blog for Rust - stm32

Blinking an LED on STM32 Blue Pill (STM32F103C8T6) with Embedded Rust

Setting Up an Embedded Rust Development Environment</a></p>