UART Communication Between ESP32 and Raspberry Pi Pico in Rust

2026-08-14T00:00:00+00:00

A few months ago, I saw a Reddit post from someone trying to communicate between an ESP32-C3 and the Raspberry Pi Pico using UART in Embedded Rust. I tried to help by testing UART communication myself and confirming that it worked.

That made me realize others might also benefit if I wrote a tutorial and shared the code. In this tutorial, we will connect a Raspberry Pi Pico (RP2040) and an ESP32 using UART and exchange data between them. The same approach also works for the RP2350.

Send sensor readings from one microcontroller to another, which can then upload the data to a server or a home automation system.</li>
Use one microcontroller for Wi-Fi or Bluetooth, and the other for controlling sensors, motors, or other peripherals.</li>
Increase the number of available GPIO pins. Each microcontroller can control its own peripherals while exchanging data over UART.</li>
Use hardware features that are available on one microcontroller but not the other.</li>
Split a project into smaller parts. For example, one microcontroller can handle buttons and displays, while the other performs the main processing.</li> </ul>

Beyond all the practical reasons, one of my biggest motivations for writing this article is simple: it’s fun. </blockquote>
I’m a hobbyist, and I enjoy exploring ideas, experimenting, and sharing what I learn. Not everything worth doing needs to be useful. Some things are worth doing simply because they’re fun.
It also assumes you already have an Embedded Rust development environment</a> set up for both the Raspberry Pi Pico and the ESP32.
If you are new to Embedded Rust, I recommend starting with one of the following guides:

Embedded Rust with Raspberry Pi Pico (RP2040): https://rp2040.implrust.com/</a></li>
Embedded Rust with Raspberry Pi Pico 2 (RP2350): https://pico.implrust.com/</a></li>
Embedded Rust with ESP32: https://esp32.implrust.com/</a></li> </ul>
These guides walk you through setting up the development environment, creating your first project, and flashing programs to the board.
</a> What is UART?</h2>
UART (Universal Asynchronous Receiver/Transmitter) is a simple way for two devices to exchange data over a serial connection. It sends data one bit at a time over a TX (transmit) line and receives it through an RX (receive) line. UART is asynchronous, so there is no clock line shared between the devices. Both devices need to use the same baud rate (the rate at which bits are transmitted). They also need to share a common ground.
</a> What We Are Going to Build</h2>
In our example project, we are going to send the text `Rust</code> from the ESP32 to the Raspberry Pi Pico when we press a button. The text is sent byte by byte over UART.`
`Once the Pico receives the bytes, it will check whether the received data matches Rust</code>. If it does, the Pico will toggle the LED. It will turn the LED on if it is off, and turn it off if it is already on.`
</a> Circuit</h2> </a> Connecting ESP32 and Raspberry Pi Pico</h3> Connect the ESP32’s UART TX pin to the Pico’s UART RX pin. Both boards must share a common ground so they have the same voltage reference for the UART signals. From</th> Wire</th> To</th> </tr> </thead> ESP32 GPIO23 (TX)</td> </div> </div> </div> </td> Pico GPIO17 (RX)</td> </tr> Pico GPIO17 (RX)</td> 10 kΩ resistor </td> Pico 3.3V(OUT)</td> </tr> ESP32 GND</td> </div> </div> </div> </td> Pico GND</td> </tr> </tbody> </table> When I first tried, i got framing errors, BREAK events, and other errors on the Pico. So I added a 10 kΩ pull-up resistor to the Pico’s RX line to keep it at a defined idle state. </a> Push Button</h3> Connect the push button between GPIO4 of the ESP32 and GND. From</th> Wire</th> To</th> </tr> </thead> ESP32 GPIO4</td> </div> </div> </div> </td> Push Button</td> </tr> Push Button</td> </div> </div> </div> </td> GND</td> </tr> </tbody> </table> </a> LED</h3> Connect the LED to GPIO15 of the Pico through a 330 Ω resistor. From</th> Wire</th> To</th> </tr> </thead> Pico GPIO15</td> 330 Ω resistor </td> LED</td> </tr> LED</td> </div> </div> </div> </td> GND</td> </tr> </tbody> </table> </a> ESP32 Code</h2> Create the ESP32 project using the esp-generate</code> command. We will use the non-Embassy version for the ESP32. I will not explain the basic boilerplate code here. Instead, we will look at the parts that are relevant to our UART example. </div> INFO The complete project, including both the ESP32 and Raspberry Pi Pico code, is available on GitHub</a>. You can refer to it if you run into any issues. </div> </div> We configure GPIO4 as an input with an internal pull-up resistor: let btn = Input::new( peripherals.GPIO4, InputConfig::default().with_pull(Pull::Up), );</code></pre> The pin is normally HIGH because of the pull-up resistor. When the button is pressed, it is connected to GND and becomes LOW. Next, we configure UART1 with a baud rate of 115200 and use GPIO23 as the TX pin: let uart_config = UartConfig::default().with_baudrate(115_200); let mut uart = Uart::new(peripherals.UART1, uart_config) .expect("Failed to initialize UART") .with_tx(peripherals.GPIO23); info!("UART is initialized");</code></pre> The baud rate must match the baud rate configured on the Raspberry Pi Pico. This is the main loop. When the button is pressed, it becomes LOW, and we write Rust</code> followed by a newline character to the UART. We then flush the UART transmit buffer. let mut btn_pressed = false; loop { if btn.is_low() { btn_pressed = true; info!("Sending signal"); if let Err(e) = uart.write(b"Rust\n") { error!("UART write failed: {:?}", e); } if let Err(e) = uart.flush() { error!("UART flush failed: {:?}", e); } let delay_start = Instant::now(); while delay_start.elapsed() < Duration::from_millis(500) {} } else if btn_pressed { btn_pressed = false; info!("Waiting for button press"); } let delay_start = Instant::now(); while delay_start.elapsed() < Duration::from_millis(100) {} }</code></pre> We do not really need the btn_pressed</code> variable. I added it so that we can print “Waiting for button press” when the button is released. </a> Raspberry Pi Pico Code</h2> Create the Pico project as described in the RP2040 book</a> or the Pico 2 book</a>. If you already have your own template, you can create the project from that instead. Before modifying the main</code> function, let’s define an Embassy task called reader</code> which will accept a UART receiver and an LED output as arguments. #[embassy_executor::task] async fn reader(mut rx: BufferedUartRx, mut led: Output<'static>) { info!("Reading..."); let mut buf = [0u8; 1]; let mut line: heapless::Vec<u8, 4> = heapless::Vec::new(); loop { match rx.read(&mut buf).await { Ok(_) => { if buf[0] == b'\n' { if line.eq(b"Rust") { info!("Got Rust! Toggling..."); led.toggle(); } line.clear(); } else if line.push(buf[0]).is_err() { line.clear(); } } Err(err) => { error!("error : {}", err); line.clear(); } } } } </code></pre> We read one byte at a time from the UART and store the received bytes in the heapless vector line</code>. The rx.read(&mut buf)</code> function reads data into the specified buffer, and here we use a one-byte buffer. We keep adding the received bytes to line</code> until we get the newline character (\n</code>). If the contents of line</code> match Rust</code>, we toggle the LED and clear the vector so we can receive the next message. </div> TIP Note: You are not limited to this approach. This is just an example. Depending on your use case, you can read more than one byte with the read</code></a> function, or use other functions such as read_exact</code></a>. </div> </div> Now let’s configure the UART receiver and LED in the main function. First, we bind the UART interrupt handler: bind_interrupts!(struct Irqs { UART0_IRQ => BufferedInterruptHandler<UART0>; });</code></pre> We also need a 64-byte buffer for the UART receiver: static RX_BUF: StaticCell<[u8; 64]> = StaticCell::new();</code></pre> Next, let’s configure UART0. We use the default configuration, which uses a baud rate of 115200, matching the ESP32. let config = UartConfig::default(); debug_assert_eq!(config.baudrate, 115_200); let rx_buf = &mut RX_BUF.init([0; 64])[..]; let uart_rx = BufferedUartRx::new(p.UART0, Irqs, p.PIN_17, rx_buf, config);</code></pre> We use GPIO17 as the UART RX pin. Next, configure GPIO15 as an output for the LED: let led = Output::new(p.PIN_15, Level::Low);</code></pre> Finally, let’s pass the UART receiver and LED to the reader</code> task: unwrap!(spawner.spawn(reader(uart_rx, led))); loop { Timer::after_secs(1).await; }</code></pre> The reader</code> task will now wait for incoming data from the ESP32 and process it as it arrives. </a> Running the Project</h2> Flash the programs to the ESP32 and Pico. Now press the push button connected to the ESP32. The LED on the Pico should toggle between ON and OFF with each button press. If you have enabled defmt</code> or another logging option, you can also see the messages in the system console. Otherwise, you can simply observe the LED on the Pico. 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. I picked one up while ordering some other electronic components because it was so inexpensive. The Blue Pill is a low-cost development board based on the STM32F103C8T6 microcontroller, often abbreviated as STM32F103C8, from STMicroelectronics. The STM32F103 microcontroller was first introduced in 2007. It is based on a 32-bit Arm Cortex-M3 processor and provides 64 KB of Flash memory and 20 KB of SRAM. </div> TIP If you are buying a development board today, you may want to consider a newer option with better performance and more features. </div> </div> There are plenty of tutorials for the Blue Pill using C and other programming languages. In this post, however, i’ll use 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. </a> Before You Begin</h2> This tutorial assumes you are familiar with basic Rust programming and fundamental electronics concepts. It also assumes you already have an Embedded Rust development environment set up. If not, I recommend reading the following guide first: Setting Up an Embedded Rust Development Environment</a> </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. Setting Up an Embedded Rust Development Environment 2026-08-04T00:00:00+00:00 When developing embedded applications with Rust, you will need to install a few tools on your computer. If you’ve already written Rust programs on your desktop, most of the setup is already done. We only need to add support for embedded targets and install a few additional tools for flashing and debugging firmware. </a> Install Rust</h2> If you do not already have Rust installed, download and install it from the official Rust website. I recommend following the installation instructions on the official Rust website: https://rust-lang.org/tools/install/</a> On Linux and macOS, you can install Rust by running: curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh</code></pre> On Windows, download and run the installer from the Rust website. </div> TIP To be frank, if this is your first time learning Rust, I do not recommend jumping straight into Embedded Rust. Spend some time learning the basics of Rust first. It will make your Embedded Rust journey much easier. After all, I assume you chose Rust not because you just want to copy and paste code. You want to understand how things work, enjoy the learning process, and benefit from the safety that Rust provides. </div> </div> Once the installation is complete, verify it by running: rustc --version cargo --version rustup --version</code></pre> You should see the installed versions printed on the screen. </a> Install the ARM Cortex-M Target</h2> Rust supports many embedded architectures, including ARM Cortex-M, RISC-V, and Xtensa. In this article, we’ll install the ARM Cortex-M targets, as they are used by many popular development boards such as the Raspberry Pi Pico, Raspberry Pi Pico W, Pico 2, and STM32 Blue Pill. </div> NOTE If you’re developing for an ESP32 board, the setup process is slightly different because ESP32 uses a different architecture. You’ll need to install the appropriate Rust target and development tools. If you’re looking for a step-by-step guide, I also have a dedicated free book on Embedded Rust with ESP32</a>. </div> </div> Different microcontrollers use different Cortex-M cores, so Rust provides a separate compilation target for each one. Some common targets are: Cortex-M Core</th> Rust Target</th></tr></thead> Cortex-M0 / M0+</td> thumbv6m-none-eabi</code></td></tr> Cortex-M3</td> thumbv7m-none-eabi</code></td></tr> Cortex-M4 / M7</td> thumbv7em-none-eabi</code></td></tr> Cortex-M4F / M7F</td> thumbv7em-none-eabihf</code></td></tr> Cortex-M33</td> thumbv8m.main-none-eabihf</code></td></tr> </tbody></table> Install the target for boards based on the ARM Cortex-M0+ core, such as the Raspberry Pi Pico and Pico W. rustup target add thumbv6m-none-eabi</code></pre> Install the target for boards based on the ARM Cortex-M3 core, such as the STM32 Blue Pill (STM32F103). rustup target add thumbv7m-none-eabi</code></pre> Install the target for boards based on the ARM Cortex-M33 core with hardware floating-point support, such as the Raspberry Pi Pico 2 (RP2350). rustup target add thumbv8m.main-none-eabihf</code></pre></a> Install probe-rs</h2> Once you’ve compiled your Embedded Rust application, you’ll need a way to flash it onto your development board and debug it. probe-rs</code>, a modern tool for flashing, debugging, and interacting with embedded microcontrollers. I recommend following the installation instructions on the official probe-rs website: https://probe.rs/docs/getting-started/installation/</a> Once the installation is complete, verify it by running: probe-rs --version</code></pre> If the version is printed successfully, probe-rs is installed correctly. </a> Install cargo-generate</h2> When starting a new project, you’ll often need to create the same files and write the same configuration before you can begin writing code. cargo-generate</code> is a tool that helps to create a new project from a template, so you don’t have to set up everything manually. I normally use cargo-generate</code> to create new projects from templates. There are many templates available from the community, and once you’re familiar with the Rust ecosystem, you can create your own templates, store them in a Git repository or local directory, and use them to generate future projects. Install it by running: cargo install cargo-generate</code></pre> Verify the installation by running: cargo generate --version</code></pre></a> Install cargo-binutils (Optional)</h2> cargo-binutils</code> provides additional commands for inspecting compiled binaries. It can display firmware size, disassemble machine code, and inspect symbols. While it isn’t required for Embedded Rust development, it can be useful when debugging or exploring what the compiler generated. Install it by running: cargo install cargo-binutils rustup component add llvm-tools</code></pre> That’s it! Your Embedded Rust development environment is now ready. Analyzing PIO Blink Using Logic Analyzer on Raspberry Pi Pico with Embedded Rust 2026-02-08T00:00:00+00:00 In earlier posts, we used a logic analyzer to inspect simple GPIO signals and UART communication. In this post, we will use the logic analyzer to inspect a signal generated by PIO, which is specific to the Raspberry Pi Pico variants (RP2040 and RP2350 chips). If you do not know what PIO is, I recommend checking the introduction in the “impl Rust for RP2040”</a> book. I will still give a short overview here so that we are all on the same page before looking at logic analyzer captures. </a> PIO</h2> PIO, short for Programmable I/O, is a hardware block available on RP2040 and RP2350 microcontrollers. It allows us to write small programs that run independently of the main CPU and directly control GPIO pins. Each PIO block contains a few state machines. A state machine executes instructions from a small instruction memory, one instruction at a time, and can drive pins, sample pins, and move data in and out through FIFOs. The important part for this post is that PIO timing is instruction-driven. Unlike CPU code, where timing depends on compiler output, interrupts, and scheduling, PIO timing is deterministic. Each instruction takes a known number of cycles to execute. </a> PIO Clock Divider</h3> Each PIO state machine has its own clock divider. This divider controls how fast instructions are executed. On RP2040, the PIO instruction clock is derived from the system clock like this: state_machine_clock = clk_sys / clock_divider</code></pre> In our setup: System clock = 125 MHz</li> PIO clock divider = 65535</li> </ul> So the instruction execution rate becomes: 125,000,000 / 65,535 ≈ 1,907.38 instructions per second</code></pre> This means the PIO state machine executes roughly 1.9 thousand instructions per second. </a> Instruction Cycles and Delays</h3> By default, every PIO instruction takes exactly one instruction cycle to execute. PIO also supports an instruction delay modifier, written using square brackets. For example: set pins, 1 [31]</code></pre> This means: 1 cycle for the instruction itself</li> 31 additional delay cycles</li> </ul> So the total execution time for that instruction is 32 instruction cycles. </a> Time Per Instruction</h2> Since we know the instruction execution rate, we can compute the time taken by one instruction cycle. With a clock divider of 65535: 1 / 1,907.38 s ≈ 0.0005243 s</code></pre> That means approximately: 0.524 ms (524,300 nanoseconds) per instruction cycle</li> </ul> </a> Project Source Code</h2> You can clone the project used in this post from the following repository: git clone https://github.com/ImplFerris/rp2040-projects cd rp2040-projects/embassy/pio/hello-blinky/</code></pre> This project contains the exact PIO program and Embassy setup used for the logic analyzer measurements shown in this post. </a> Pio Program</h3> This is the PIO assembly program used to generate the blinking signal that we will analyze with the logic analyzer. let prg = pio_asm!( " set pindirs, 1 loop: set pins, 1 [31] nop [31] nop [31] nop [31] nop [31] nop [31] nop [31] nop [31] set pins, 0 [30] nop [31] nop [31] nop [31] nop [31] nop [31] nop [31] nop [31] jmp loop " );</code></pre> This program runs in an infinite loop and drives a single GPIO pin HIGH and LOW. The delays are added using the instruction delay modifier. Each instruction with [31] takes a total of 32 PIO cycles to execute. The one place where [30] is used is intentional. The jmp loop instruction takes one extra cycle while the pin is LOW, so reducing the delay on set pins, 0</code> keeps the HIGH and LOW durations equal. Because the program timing is entirely instruction-based, we can predict the exact HIGH time, LOW time, and output frequency before even connecting the logic analyzer. </a> Hardware Setup</h2> The hardware setup is very simple. We connect the logic analyzer to the same GPIO pin that drives the LED, so we can observe exactly what the LED sees. The external LED is connected to GPIO15 through a resistor. The logic analyzer channel is connected in parallel to the same GPIO pin. Source</th> Connected To</th></tr></thead> GPIO15</td> Resistor => LED => GND</td></tr> Logic Analyzer CH1</td> GPIO15</td></tr> Logic Analyzer GND</td> Pico GND</td></tr> </tbody></table> With this setup, the GPIO pin drives both the LED and the logic analyzer input at the same time. The LED gives us a visual confirmation of the blinking, while the logic analyzer lets us inspect the exact timing and waveform. Make sure the logic analyzer ground and the Pico ground are connected. Without a common ground, the captured signal will be unreliable. </a> Start the Capture</h2> Open PulseView as usual. For this capture, I have configured the sample rate to 20 kHz and the number of samples to 1 million. Once the settings are in place, click Run to start the capture. PulseView will record the signal and automatically stop once it reaches the configured number of samples. </a> Measuring Timing with Cursors in PulseView</h2> Up to this point, we have been looking at captured waveforms mainly to understand their overall shape and behavior. To measure timing more precisely, PulseView provides a cursor feature that is very useful. When you enable Show Cursors</code> in PulseView, two movable time markers appear on the waveform. Each cursor represents a specific point in time on the capture. By placing the cursors on two edges or points of interest, PulseView shows the exact time difference between them. This makes it easy to measure how long a signal stays HIGH, how long it stays LOW, or the full period of a repeating waveform. </a> Verifying the Timing on the Logic Analyzer</h2> With the capture complete, we can now use the cursors to measure the actual timing of the signal generated by PIO. In the capture above, the cursors are placed across one full HIGH-LOW cycle of the waveform. PulseView directly shows the measured period as roughly 268 ms, which corresponds to a frequency of about 3.7 Hz. To understand why the measured period comes out to around 268 ms, let us now work through the timing of the PIO program step by step. </a> High Phase Timing</h3> The pin goes HIGH when the set pins, 1</code> instruction executes and stays HIGH until set pins, 0</code> executes. While the pin is HIGH, the following instructions run: set pins, 1 [31]</code> The instruction itself takes 1 cycle, and the delay adds 31 more cycles. Total: 32 cycles </li> nop [31]</code> repeated 7 times Each nop [31]</code> takes 32 cycles. Total: 7 x 32 = 224 cycles </li> </ul> So the total number of instruction cycles while the pin is HIGH is: 32 + 224 = 256 cycles</code></pre> With each instruction cycle taking about 0.524 ms, the total HIGH time becomes: 256 x 0.524 ms ≈ 134 ms</code></pre></a> Low Phase Timing</h3> The LOW phase starts when set pins, 0</code> executes and lasts until the program loops back and sets the pin HIGH again. While the pin is LOW, the following instructions run: set pins, 0 [30]</code> The instruction itself takes 1 cycle, and the delay adds 30 more cycles. Total: 31 cycles </li> nop [31]</code> repeated 7 times Total: 7 x 32 = 224 cycles </li> jmp loop</code> This instruction takes 1 cycle </li> </ul> So the total number of instruction cycles while the pin is LOW is: 31 + 224 + 1 = 256 cycles</code></pre> This again gives: 256 x 0.524 ms ≈ 134 ms</code></pre></a> Putting It All Together</h3> From the instruction count, we end up with: HIGH time ≈ 134 ms</li> LOW time ≈ 134 ms</li> Full period ≈ 268 ms</li> </ul> This matches approximately what we measured using the logic analyzer. Analyzing UART Signals in Embedded Rust Using a Cheap USB Logic Analyzer 2026-01-28T00:00:00+00:00 In my previous blog post</a>, I introduced the USB logic analyzer, showed how to set up the software, and used a simple GPIO toggle to get familiar with how a logic analyzer works. In this post, we look at UART and see how serial data appears on the wire by analyzing the transmit (TX) signal and understanding how bytes are sent. I initially planned to explain I2C right after the introduction, but I felt that UART is much simpler to start with and provides a gentler introduction to using protocol decoders in PulseView. </a> What is UART?</h2> You might already be familiar with UART. Still, let me give a short introduction. UART stands for Universal Asynchronous Receiver-Transmitter. It is a simple serial communication method used to send data between two devices. Data is sent one bit at a time, rather than in parallel. UART typically uses two signal lines: one for transmitting data (TX) and one for receiving data (RX). The TX pin of one device is connected to the RX pin of the other, so data sent on TX is received on RX. Unlike some other protocols, UART does not use a clock signal. So a natural question is how the receiver knows when data starts, when it ends, and how to interpret the bits correctly. Let us look at a simple UART signal to understand this. We can assign LOW state to 0 and HIGH to 1, but this alone is not enough. For example, suppose we want to transmit the value 0x52 (binary 0101_0010). If two or more bits in a row have the same value, such as two consecutive zeros, how does the receiver know whether it is seeing one long zero or multiple zeros? This is where three important UART things come into play: the data length, the start and stop bits, and the transmission speed (baud rate). These three define how many bits make up a byte, and how the beginning and end of a byte are identified, how fast the data is sent. </a> Baud Rate (Transmission Speed)</h3> The baud rate defines how fast bits are transmitted on the wire. It specifies how many bits are sent per second. For example, a baud rate of 115200 means that 115200 bits are transmitted every second. Both the transmitter and receiver must use the same baud rate. If the baud rate does not match, the receiver will sample the signal at the wrong times and decode incorrect data. </a> Data Length</h3> The data length specifies how many data bits are sent for each character. The most common configuration is 8 data bits, but other values like 5 to 9 bits are also possible. If the data length is set to 8 bits, then exactly 8 data bits are transmitted for each byte, one after another, starting with the least significant bit. </a> Start and Stop Bits</h3> When the UART line is idle, it stays in the HIGH state. A transmission always begins with a start bit, which is a transition from HIGH to LOW. This LOW level tells the receiver that a new byte is starting. Once the receiver detects the start bit, it uses the baud rate to time when to read the following data bits. After all data bits are transmitted, the sender adds one or more stop bits. A stop bit is simply the line returning to the HIGH state for a fixed duration. The stop bit marks the end of the byte and gives the receiver time to finish processing the current byte before the next one begins. </a> Example</h3> The above diagram shows the transmission of a single UART data byte. Before any data is sent, the signal stays in the idle state, which is HIGH. The transmission begins with the start bit. The start bit is represented by pulling the signal LOW for exactly one bit duration. This transition from HIGH to LOW tells the receiver that a new byte is about to start. Immediately after the start bit, the actual data bits are transmitted. In this example, the byte being sent is 0x52, which in binary is 0101_0010. UART sends data least significant bit first, so the first data bit sent is 0. Because the start bit is LOW and the first data bit is also 0, the signal stays LOW for two consecutive bit periods. From the waveform alone, these two consecutive LOW levels appear as one continuous LOW signal. The receiver does not get confused because it does not rely on signal edges to count bits. Instead, it relies on timing. This is where the baud rate comes in. The baud rate defines how long one bit lasts. For example, at a baud rate of 115200, each bit lasts for about 8.68 microseconds. The receiver measures time from the start bit and samples the signal at fixed intervals, once per bit period. By sampling at these precise times, it knows when one bit ends and the next bit begins, even if the signal level does not change. After all data bits are transmitted, the signal returns to HIGH for the stop bit. The stop bit marks the end of the byte and brings the line back to the idle state. If another byte is sent, the process repeats with another start bit. As long as both sides agree on the baud rate and data format, the receiver can correctly interpret a continuous stream of HIGH and LOW levels as individual bits and bytes. </div> TIP I intentionally avoided many details of UART in this post. I only covered what is necessary for our purpose here and skipped other topics such as parity bits and other. If you want to go deeper, I recommend reading more about UART separately. </div> </div> </a> Hardware Setup</h2> For this post, I am focusing only on the transmit (TX) pin. The receive (RX) pin works in the same way, just in the opposite direction. Once again, I am using a Raspberry Pi Pico. I will use one of the UART TX pins available on the Pico. In this example, I am using GPIO16 as the UART TX pin. You are free to use a different UART TX pin if you prefer, but you will need to adjust the code accordingly. Connect CH1 of the logic analyzer to GPIO16 on the Pico. Also connect the logic analyzer ground to any ground pin on the Pico. Logic Analyzer</th> Raspberry Pi Pico</th></tr></thead> GND</td> GND</td></tr> CH1</td> GPIO16</td></tr> </tbody></table> </a> Code Snippet</h2> Flash the program onto the Pico, then power up the board and connect the USB logic analyzer to the computer. #[embassy_executor::main] async fn main(_spawner: Spawner) { let p = embassy_rp::init(Default::default()); let mut uart_config = UartConfig::default(); // This is default baud rate in the embassy-rp, i just want to explicitly show uart_config.baudrate = 115200; let mut uart_tx = UartTx::new_blocking(p.UART0, p.PIN_16, uart_config); loop { uart_tx .blocking_write("Rust".as_bytes()) .expect("unable to write into uart"); Timer::after_secs(1).await; } }</code></pre></a> Number of Samples and Sample Rate</h2> In our example, the UART baud rate is 115200. To capture the signal reliably, we use a sample rate of 1 MHz, which is comfortably higher than the baud rate and works well with PulseView. The program sends the string “Rust” once every second and then stays idle in between. Because of this, the capture window must be long enough to include at least one transmission. Using 5 million samples at a 1 MHz sample rate gives a capture duration of about 5 seconds. This ensures that several UART transmissions are captured without having to worry about timing the capture manually. </a> Start the Capture</h2> Since the program transmits the text “Rust” once every second, the capture contains multiple UART transmissions spread across the entire capture window. Because we are viewing several seconds of data at once, the waveform is zoomed out by default. At first glance, it might look like nothing happened. The signal appears mostly flat, with a few thin vertical-looking shapes. These vertical shapes are not single lines. Each one represents a short burst of UART activity where the “Rust” string was transmitted. To see what is actually happening, zoom in horizontally on one of these regions (you can use the mouse scroll wheel while the cursor is over the signal). Once you zoom in far enough , the individual signal transitions become visible. At this level, you can see the structure of each UART transmission, but not the meaning of individual bits. To make sense of the data, we will use the protocol decoder feature. </a> Protocol Decoder</h2> Looking at the raw UART signal helps confirm that data is being transmitted, but it does not tell us what the data actually is. PulseView provides protocol decoders for many common digital protocols such as UART, I2C, and SPI. These decoders interpret raw signals and display the data in a readable form. To add a protocol decoder, click the small decoder icon next to the “sample rate” selection, as highlighted in the image above. This opens the Decoder selector. In the search box, type UART</code> and double-click the UART decoder. This adds a new UART decoder row to the main window. After adding it, you will see a message saying that no channels are assigned to the decoder. At this point, PulseView knows which protocol to use, but it does not yet know which signal line to decode. Click on the UART label on the left side to open the decoder settings. Here, we need to configure the decoder to match our UART setup. Set the baud rate to 115200. The default values for data bits, parity, and stop bits are fine for this example. By default, the decoded data format is shown in hexadecimal. Since we are transmitting ASCII text, change the data format to ASCII. Finally, assign the signal channel to the decoder. We have connected the UART TX pin to CH1, which corresponds to D0 in PulseView. Select D0 from the dropdown next to the TX option. Once this is done, PulseView will decode the captured UART signal and display the transmitted data. </a> Decoded Data</h2> PulseView decodes the captured UART signal and displays the data in a readable form. Along with the decoded characters (in ASCII, as we configured), it also shows the individual data bits as 0 and 1. PulseView also highlights the start bit with an “S” label (shown in yellow) and the stop bit with a “T” label. How to Use a Logic Analyzer in Embedded Rust Projects 2026-01-26T00:00:00+00:00 I am a hobbyist embedded Rust developer. While researching and learning, I often came across people using oscilloscopes to analyze signals. I might have used one during my college lab days, but honestly, I do not remember much about it anymore. It has been a long time. I was curious to try one again, but I did not want a large oscilloscope sitting on my desk. At least for now, it felt unnecessary. At some point, while looking for simpler ways to inspect digital signals, I came across USB logic analyzers. I do not remember exactly where I first saw one, but it immediately felt like a practical alternative. They are small, inexpensive, and much easier to keep around. There are already plenty of tutorials and videos showing how to use logic analyzers, mostly with Arduino-based examples that you can follow step by step. I decided to write this post for my usual reason: the more I write and explain something, the more I understand it myself. Hopefully, you will find it useful too. </div> INFO The Rust code is only a small part of this blog post. Most of the content focuses on understanding the logic analyzer, setting up the software, and learning how to capture and analyze digital signals. </div> </div> </a> What is a Logic Analyzer?</h2> A logic analyzer is a tool used to capture and inspect digital signals. It records whether a signal is in a logical HIGH or LOW state over time and how different signal lines, such as clock and data wires, relate to each other during communication. For embedded development, this is especially useful when working with digital protocols such as I2C, SPI, or UART. Instead of relying on assumptions or print-based debugging, a logic analyzer lets you inspect the actual signal behavior on the wire. Unlike an oscilloscope, which focuses on the exact voltage shape of a signal, a logic analyzer treats signals as digital values. It does not care about the precise voltage level or waveform details, only whether the signal is interpreted as a zero or a one. For most protocol-level debugging, this level of detail is sufficient and much easier to work with. </a> Meet the Hardware: 8-Channel USB Logic Analyzer</h2> The logic analyzer I am using is a small 8-channel USB logic analyzer with a maximum sampling frequency of 24 MHz. You should be able to find one on online marketplaces for under 400 INR (under $10). As the name implies, the analyzer allows capturing up to eight digital signals at the same time, which makes it possible to observe how multiple related signals change together. </a> How a Logic Analyzer Captures Data</h2> A logic analyzer repeatedly checks the state of each connected signal and records whether it is HIGH or LOW. These checks happen at regular intervals, based on the selected sampling rate(will see it later). The logic analyzer itself does not understand protocols or signal meaning. It only records state changes. Interpreting those changes and decoding protocols is done later using software on the computer. </a> Channels</h2> A logic analyzer has multiple input channels. Each channel is a separate input that can be connected to a signal wire or a microcontroller pin. When the analyzer captures data, it records the state of each channel independently. When connecting the analyzer, each channel should be connected to one signal of interest, such as a data line or a clock line. The exact choice of signals depends on what you are trying to observe. For now, the important point is that each channel corresponds to one physical wire or pin. </a> Software Setup</h2> I am on Linux, so I will describe the setup steps for Linux here. If you are using a different operating system, you can follow similar steps using the appropriate tools and packages for your OS. There are two commonly mentioned software options when working with USB logic analyzers. Which one makes sense depends on the hardware you are using. </a> Option 1: PulseView (sigrok, Open Source)</h3> For inexpensive 8-channel USB logic analyzers like the one I am using, the most practical software is PulseView, which is part of the open-source sigrok project. PulseView supports many generic logic analyzers and provides the basic tools needed to view captured signals and decode common digital protocols. On Debian or Ubuntu-based systems, you can install PulseView using the package manager: sudo apt install pulseview sigrok</code></pre> Official documentation for sigrok and PulseView is available here: https://sigrok.org/wiki/Main_Page</a> You can also refer to the PulseView user manual for more details: https://sigrok.org/doc/pulseview/unstable/manual.html</a> I will be using PulseView throughout this blog post. </a> Option 2: Saleae Logic Software (Proprietary)</h3> Saleae provides software specifically designed for their logic analyzers, though it may also work with some compatible devices. You can download the Linux AppImage from the Saleae website: https://www.saleae.com/downloads/</a> Make it executable and run: chmod +x Logic-.AppImage ./Logic-.AppImage</code></pre></a> Toggling a GPIO (Test Signal)</h2> Let’s start by generating a very simple test signal by toggling a GPIO pin. This helps confirm that the logic analyzer, software, and wiring are all working correctly before moving on to more complex signals. I will be using a Raspberry Pi Pico here, but any other board will work. We will flash a small program that toggles a GPIO pin between high and low states with a delay of 500 milliseconds. For the HAL, I will be using Embassy. You are free to use any other HAL, such as rp-hal. The choice of HAL does not matter here, as long as you can toggle a GPIO pin at a known interval and observe the change on the logic analyzer. </a> Code snippet</h3> let p = embassy_rp::init(Default::default()); let mut pin = Output::new(p.PIN_15, Level::Low); loop { pin.set_high(); Timer::after_millis(500).await; pin.set_low(); Timer::after_millis(500).await; }</code></pre> </div> TIP If you are not familiar with creating a project or flashing embedded Rust code onto a board, you may want to go through the basics first. I recommend starting with the Pico Pico book</a> or the impl Rust for ESP32</a> book. </div> </div> </a> Connecting Pico with Logic Analyzer</h3> First, connect the ground wire of the logic analyzer to one of the ground pins on the Raspberry Pi Pico. The logic analyzer and the Pico must share a common ground for the signals to be interpreted correctly. Next, connect one channel (lets say CH1) of the logic analyzer to GPIO15 on the Pico. For this test, I am using GPIO15, but you can use any other GPIO pin. Logic Analyzer</th> Raspberry Pi Pico</th></tr></thead> GND</td> GND</td></tr> CH1</td> GPIO15</td></tr> </tbody></table> Power the Pico, then connect the logic analyzer to the computer. </a> Opening PulseView and Detecting the Logic Analyzer</h2> Now lets open PulseView and make sure the logic analyzer is detected correctly. Start PulseView after connecting the logic analyzer to your computer. When PulseView opens, it should automatically try to detect connected devices. If the logic analyzer is detected, you should see it selected as the active device in the toolbar. If no device is selected, open the device selection menu and choose the generic logic analyzer entry, which usually appears as fx2lafw (generic driver). Once selected, PulseView should show the available channels for that device. </a> Configuring Sampling Rate and Number of Samples</h2> Once the logic analyzer is detected in PulseView, the next step is to configure how data will be captured. Two important settings here are the “sample rate” and the “number of samples to capture”. To understand these settings, it helps to know what a sample actually is. A sample is a single recorded value of the signal. At that moment, the logic analyzer simply reads the wire and records whether the signal is HIGH or LOW. Each recorded HIGH or LOW value is one sample. </a> Number of Samples</h3> The number of samples tells the logic analyzer how many samples to record in total before stopping. For example, if you set this to 100k, the logic analyzer will record 100,000 values (each value being either HIGH or LOW) and then stop automatically. Increasing this value makes the recording last longer. Decreasing it makes the recording shorter. </a> Sample Rate</h3> The sample rate tells the logic analyzer how many samples to take every second. For example, a sample rate of 20 kHz means the logic analyzer records 20,000 samples every second. That means it reads the signal 20,000 times per second and saves each result. A higher sample rate means the signal is read and recorded more frequently. This is important when the signal changes quickly. A lower sample rate means the signal is read less often, which is usually fine for slow signals. </div> TIP From the Manual: The sample rate you choose must at least be twice that of the highest frequency you want to capture - ideally 3 to 5 times as much so that you have some margin. That way, a jittering signal won’t ruin your measurements. </div> </div> </a> How They Work Together</h3> These two settings answer two different questions: “The sample rate” answers how fast samples are taken</li> “The number of samples” answers how many samples are taken</li> </ul> Together, they decide how long the signal is recorded. PulseView shows this relationship using the capture duration: capture duration = number of samples / sample rate</code></pre> Suppose you set the sample rate to 20 kHz and the number of samples to 100k. At a 20 kHz sample rate, the logic analyzer records 20,000 samples every second. With 100,000 samples in total, the recording will last for about 5 seconds before stopping. capture duration = 100,000 / 20,000 = 5 seconds</code></pre> We will use this setting only for our test. It is sufficient here because we are just toggling the GPIO every 500 milliseconds. </a> Starting the Capture and Verifying the Signal</h2> With the logic analyzer connected and the capture settings configured, we can now start the capture. In PulseView, click Run in the top bar (next to the Session label). The logic analyzer will begin recording samples and will automatically stop once it reaches the configured number of samples. After the capture stops, you should see a waveform on the enabled channel. In our program, the GPIO state is toggled every 500 milliseconds. As shown in the capture, the signal stays HIGH for 500 ms, then LOW for 500 ms, repeating this pattern consistently. Since the total capture duration is 5 seconds, this results in 5 HIGH periods and 5 LOW periods across the entire waveform. Even though the waveform shows only a few visible transitions, the logic analyzer actually recorded all 100,000 samples. Each HIGH or LOW section in the waveform represents many individual samples taken during that time. PulseView automatically zooms out to show the overall shape of the signal rather than displaying every sample at once. If you zoom in horizontally, you will see that each flat HIGH or LOW region is made up of many samples. This confirms that the GPIO toggling, sampling configuration, and capture duration are all working together as expected. </a> What’s Next</h2> In this post, we focused on getting familiar with the logic analyzer and basic signal capture. I am planning to write a follow-up post focused on analyzing I2C signals, and later cover other protocols as well. Working with Fixed-Point Numbers in Rust Using the fixed Crate 2025-12-20T00:00:00+00:00 While revising the Pico Pico book (an embedded Rust book for the Raspberry Pi Pico 2), I was working on the PWM chapter for controlling servo motors. In that chapter, embassy-rp uses a fixed-point number to store the PWM clock divider. Both the integer and fractional parts are stored together in a single field called divider, using a type from the “fixed” crate. Instead of explaining fixed-point numbers briefly there, I decided it made more sense to write a separate blog post. That is how this post came to be. Here, I will give a short introduction to fixed-point numbers and explain how to use them in Rust. </a> What is Fixed Point?</h2> A fixed-point number is a way to represent fractional (non-integer) values using only integer arithmetic. Unlike floating-point numbers (like f32</code> or f64</code>), fixed-point numbers reserve a predetermined number of bits for the fractional part. This makes them predictable, fast, and ideal for embedded systems where floating-point hardware might be unavailable or too slow. </a> Understanding Fixed-Point Notation</h2> This idea is explained well in the fixed crate</a> documentation, but let me give a quick overview. The key idea is this. If you have n total bits and you choose f bits for the fractional part, then you automatically have n - f</code> bits left for the integer part. Once this split is chosen, the position of the decimal point is fixed. Fixed-point numbers maintain uniform spacing between consecutive values throughout their range. The step size formula is 1/2^f</code>. For example, consider a 16-bit fixed-point number where 4 bits are used for the fraction. Here, f = 4, so the remaining 16 - 4 = 12 bits are used for the integer part. With 4 fractional bits, the smallest step size is 1 / 2⁴ = 0.0625. This means fractional values are represented as multiples of 0.0625. After 0.0625, the next value is 0.125, and the numbers continue to increase in fixed, evenly spaced steps. </a> Binary Representation</h2> Let’s use a 16-bit unsigned number as an example. Normally, to store an integer like 5, the binary representation would be 0000_0000_0000_0101</code>. With fixed-point representation, we dedicate a predetermined number of bits for the fractional part, depending on our precision needs. The remaining upper bits store the integer part. For instance, if we allocate the last 4 bits for the fraction, we have 12 bits left for the integer. </a> Example: 4 Fractional bits</h3> Here’s how the bits map to their values: Bit Position</th> 15</th> 14</th> 13</th> 12</th> 11</th> 10</th> 9</th> 8</th> 7</th> 6</th> 5</th> 4</th> .</th> 3</th> 2</th> 1</th> 0</th></tr></thead> Weight</td> 2¹¹</td> 2¹⁰</td> 2⁹</td> 2⁸</td> 2⁷</td> 2⁶</td> 2⁵</td> 2⁴</td> 2³</td> 2²</td> 2¹</td> 2⁰</td> </td> 2⁻¹</td> 2⁻²</td> 2⁻³</td> 2⁻⁴</td></tr> </tbody></table> The decimal point (shown as .</code> in the table) is just for our understanding, it doesn’t actually exist in memory. With 4 fractional bits, the smallest value we can represent is 2⁻⁴ = 0.0625, giving us a precision of 1/16. </a> Example: 8 Fractional bits</h3> If we need more precision, we can allocate more bits to the fractional part. With 8 fractional bits, we get: Bit Position</th> 15</th> 14</th> 13</th> 12</th> 11</th> 10</th> 9</th> 8</th> .</th> 7</th> 6</th> 5</th> 4</th> 3</th> 2</th> 1</th> 0</th></tr></thead> Weight</td> 2⁷</td> 2⁶</td> 2⁵</td> 2⁴</td> 2³</td> 2²</td> 2¹</td> 2⁰</td> </td> 2⁻¹</td> 2⁻²</td> 2⁻³</td> 2⁻⁴</td> 2⁻⁵</td> 2⁻⁶</td> 2⁻⁷</td> 2⁻⁸</td></tr> </tbody></table> With 8 fractional bits, our smallest representable value is 2⁻⁸ = 0.00390625 (1/256), giving us finer precision but reducing the maximum integer we can represent. </a> Fixed Crate Types</h2> The fixed crate provides fixed-point number types in different sizes. The number in the type name tells you how many bits are used in total. For example, FixedI8 and FixedU8 are 8-bit fixed-point numbers. FixedI16 and FixedU16 are 16-bit types. In the same way, there are 32-bit, 64-bit, and even 128-bit fixed-point types, both signed (FixedI) and unsigned (FixedU*). What makes these types flexible is the extra generic parameter that controls how many bits are used for the fractional part. For example, FixedU16<extra::U4></code> is a 16-bit unsigned fixed-point number where 4 bits are used for the fraction. That leaves 16 - 4 = 12 bits for the integer part. If you use FixedU16<U0></code>, there are no fractional bits, so it behaves just like a normal u16. The crate also provides convenient type aliases so you do not always have to write the generic form. For example, U12F4 represents a unsigned fixed-point number with 12 integer bits and 4 fractional bits. You can use it directly like this: use fixed::types::U12F4;</code></pre></a> Example 1</h2> Create a new Rust project, add the fixed</code> crate as a dependency, and replace main.rs with the following code. To make things easier to understand, the example prints the same value in several different forms. First, it prints the fixed-point value itself. The :.4 formatting is only for display and shows four digits after the decimal point. Next, it uses helper methods from the fixed crate to print the fractional part and the integer part separately. Then it prints the binary representation in two different ways. The first binary print ({:b}) is a human-friendly representation provided by the fixed crate. It inserts a binary point to show where the fractional bits are. This can feel a little confusing at first glance, at least it did for me. But once you get used to reading it, it actually becomes easier to reason about fixed-point values. The second binary print uses to_bits(), which returns the raw 16-bit value stored internally. For clarity, the integer bits and the fractional bits are manually separated with an underscore when printing. use fixed::{FixedU16, types::extra}; use fixed::types; fn main() { // let f_u16: FixedU16<extra::U4> = FixedU16::from_num(5.75); // you can use this approach let f_u16: FixedU16<extra::U4> = types::U12F4::from_num(5.75); // or this approach assert_eq!(f_u16, 5.75); println!("Fixed Point: {:.4}", f_u16); println!("Fraction: {}", f_u16.frac()); println!("Integer: {}", f_u16.int()); println!("Binary with Fraction repr: {:b}", f_u16); // println!("Actual binary: {:016b}", f_u16.to_bits()); let bits = format!("{:016b}", f_u16.to_bits()); let formatted = format!( "{}_{}", &bits[..12], &bits[12..], ); println!("Actual binary: {}", formatted); println!("F32: {}", f_u16.to_num::<f32>()); }</code></pre> If you run this code, you will see output like this: Fixed Point: 5.7500 Frac: 0.75 Int: 5 Binary with Fraction repr: 101.11 Actual binary: 000000000101_1100 F32: 5.75</code></pre> When I first saw Binary with Fraction repr: 101.11, it was confusing. My brain read the 11 in the fractional part as the number three. That is not how fixed-point fractions work. To understand what this value really represents, let’s look at the binary representation. Bit Position</th> 15</th> 14</th> 13</th> 12</th> 11</th> 10</th> 9</th> 8</th> 7</th> 6</th> 5</th> 4</th> .</th> 3</th> 2</th> 1</th> 0</th></tr></thead> Stored Bit</td> 0</td> 0</td> 0</td> 0</td> 0</td> 0</td> 0</td> 0</td> 0</td> 1</td> 0</td> 1</td> </td> 1</td> 1</td> 0</td> 0</td></tr> Weight</td> 2¹¹</td> 2¹⁰</td> 2⁹</td> 2⁸</td> 2⁷</td> 2⁶</td> 2⁵</td> 2⁴</td> 2³</td> 2²</td> 2¹</td> 2⁰</td> </td> 2⁻¹</td> 2⁻²</td> 2⁻³</td> 2⁻⁴</td></tr> </tbody></table> The integer part is straightforward. The bits 101 represent the value 5 using normal binary rules. The fractional part is where the confusion usually comes from. Each fractional bit represents a negative power of two. fraction = 1 × 0.5 + 1 × 0.25 + 0 × 0.125 + 0 × 0.0625</code></pre> That adds up to 0.75. </a> Example 2</h2> Let’s look at one more example. This time, I try to represent the value 20.3. I keep the same fixed-point configuration as before, with 4 fractional bits. use fixed::{FixedU16, types::extra}; use fixed::types; fn main() { let f_u16: FixedU16<extra::U4> = FixedU16::from_num(20.3); assert_eq!(f_u16, 20.3125); println!("Fixed Point: {:.4}", f_u16); println!("Fraction: {}", f_u16.frac()); println!("Integer: {}", f_u16.int()); println!("Binary with Fraction repr: {:b}", f_u16); // println!("Actual binary: {:016b}", f_u16.to_bits()); let bits = format!("{:016b}", f_u16.to_bits()); let formatted = format!( "{}_{}", &bits[..12], &bits[12..], ); println!("Actual binary: {}", formatted); println!("F32: {}", f_u16.to_num::<f32>()); }</code></pre> If you expect the line assert_eq!(f_u16, 20.3125) to fail, you might be surprised. It does not fail. The code compiles successfully and produces the following output: Fixed Point: 20.3125 Fraction: 0.3 Integer: 20 Binary with Fraction repr: 10100.0101 Actual binary: 000000010100_0101 F32: 20.3125</code></pre> This happens because 20.3 cannot be represented exactly using this fixed-point format. As stated earlier, the fractional part can only increase in steps of 1 / 2^f. With 4 fractional bits, the step size is: 1 / 2^4 = 0.0625</code> So the fraction 0.3 must be rounded to the nearest multiple of 0.0625. The value 0.3125 is a valid multiple: 0.0625 × 5 = 0.3125</code> In the binary, it is represented like this: Bit Position</th> 15</th> 14</th> 13</th> 12</th> 11</th> 10</th> 9</th> 8</th> 7</th> 6</th> 5</th> 4</th> .</th> 3</th> 2</th> 1</th> 0</th></tr></thead> Stored Bit</td> 0</td> 0</td> 0</td> 0</td> 0</td> 0</td> 0</td> 0</td> 0</td> 1</td> 0</td> 1</td> </td> 0</td> 1</td> 0</td> 1</td></tr> Weight</td> 2¹¹</td> 2¹⁰</td> 2⁹</td> 2⁸</td> 2⁷</td> 2⁶</td> 2⁵</td> 2⁴</td> 2³</td> 2²</td> 2¹</td> 2⁰</td> </td> 2⁻¹</td> 2⁻²</td> 2⁻³</td> 2⁻⁴</td></tr> </tbody></table> If we calculate the fractional part: fraction = 0 × 0.5 + 1 × 0.25 + 0 × 0.125 + 1 × 0.0625 = 0.3125</code></pre></a> In Raspberry Pi Pico 2 (RP2350)</h2> On the Raspberry Pi Pico 2 (RP2350), the PWM clock divider controls how fast the PWM counter runs. The PWM counting rate is calculated by dividing the system clock frequency by this divider value. The divider register stores the value using a fixed point format. It is split into an integer part and a fractional part. The upper 8 bits represent the integer portion of the divider, and 4 bits represent the fractional portion. Together, these bits form a fixed point number, allowing finer control over the PWM frequency. The following code snippet is from the rp-pac</a> crate and shows how the divider register is defined. #[doc = "INT and FRAC form a fixed-point fractional number. Counting rate is system clock frequency divided by this number. Fractional division uses simple 1st-order sigma-delta."] #[repr(transparent)] #[derive(Copy, Clone, Eq, PartialEq)] pub struct ChDiv(pub u32); impl ChDiv { #[inline(always)] pub const fn frac(&self) -> u8 { let val = (self.0 >> 0usize) & 0x0f; val as u8 } ... #[inline(always)] pub const fn int(&self) -> u8 { let val = (self.0 >> 4usize) & 0xff; val as u8 } ... }</code></pre> Although the register is defined as a 32 bit unsigned integer, only 12 bits are actually used. Of these, 8 bits are used for the integer part and 4 bits for the fractional part. In the embassy-rp crate, the divider is represented using a type from the fixed crate. When configuring the PWM hardware, this fixed point value is converted into a u32 and written directly to the register. if config.divider > FixedU16::<fixed::types::extra::U4>::from_bits(0xFFF) { panic!("Requested divider is too large"); } p.div().write_value(ChDiv(config.divider.to_bits() as u32));</code></pre> Getting started: How to Learn Embedded Rust for Beginners 2025-12-12T00:00:00+00:00 As a beginner, you might wonder where to start with Embedded Rust. I have been in the same place, and I have seen many others recently asking the same question. So I decided to write this blog post to help. In this guide, I will explain how to get started, what to focus on first, and share a list of useful resources including books, YouTube videos, and other material you can learn from. </a> Table of Contents</h2> </a> Are you new to embedded programming or just to Embedded Rust?</h2> Where you should begin depends on your background. If you are an absolute beginner to embedded programming itself, your learning path will be different from someone who already understands embedded development and only wants to learn Embedded Rust. Even within those groups, goals can vary, such as learning for a hobby or for professional work. I’ll do my best to address a broad audience while covering the most common scenarios. </a> If you already have embedded programming experience</h3> If you already have embedded experience, you can jump straight into the official “The Embedded Rust Book</a>” to learn Rust-specific concepts. After that, check out the “Embassy book</a>” for async embedded development. From there, explore the examples in the Hardware Abstraction Layer (HAL) for your specific chip. The Embedded Rust ecosystem has excellent HAL documentation and examples to help you get productive quickly. The remaining sections focus on resources for embedded programming beginners. </a> Prerequisites</h2> Before learning Embedded Rust, make sure you are comfortable with these basics: </a> Rust basics</h4> If you’re completely new to Rust, start with the official Rust Book</a> first. Understanding Rust’s ownership, borrowing, and type system is essential before tackling embedded development. Come back to this guide once you’re comfortable with basic Rust concepts. </a> Electronics Fundamentals</h4> You’ll need a basic understanding of electronics concepts like voltage, current, resistance, and how components like LEDs and resistors work. There are plenty of free tutorials and YouTube videos covering electronics basics for beginners. You don’t need to be an expert, just understand the fundamentals. </a> Hardware to Get Started</h2> Now, the question is: What hardware should you get? But before answering that, let me briefly explain what microcontrollers and development boards are. </a> What are Microcontrollers and Development Boards?</h3> A microcontroller is a small computer on a single chip that includes a processor, memory, and input/output peripherals. Unlike your laptop or phone, microcontrollers are designed to perform specific tasks efficiently with minimal power consumption. They’re found everywhere; in your washing machine, car, smart thermostat, and countless other devices. A development board (or “devboard”) is a circuit board that contains a microcontroller along with supporting components like voltage regulators, USB connectors, and pins that make it easy to connect sensors and other hardware. Development boards are designed to make prototyping and learning easier. You can start programming immediately without needing to design your own circuit. </a> Which Board Should You Get?</h3> If you already have a board, great! You can start with that. Otherwise, let me give you a straightforward recommendation without overwhelming you with options. </div> TIP My recommendation: Get an ESP32 development board. </div> </div> Why? ESP32 boards are widely available, affordable, and include built-in WiFi and Bluetooth, which opens up many project possibilities. They have solid Embedded Rust support through the esp-rs project. Look for these boards - they all use the original ESP32 chip: “ESP32 DevKit V1” - This is my top recommendation because my open-source book is based on this board, making it easy to follow along with tutorials and examples. </li> “ESP32 DevKit C” </li> </ul> Any board using the original ESP32 chip should be fine. There might be slight differences in pin layout and labeling, but the code and core features remain the same. Important: ESP32 comes in different variants (original ESP32, ESP32-S2, ESP32-S3, ESP32-C3, ESP32-C6, etc.). I’m recommending the original ESP32 (also called ESP32-WROOM or ESP32-WROOM-32). Make sure you’re getting a plain “ESP32” board, not the S-series or C-series variants, as those are different chips with different architectures. Alternative option: Raspberry Pi Pico 2 If you can’t find an ESP32 board where you live, the Raspberry Pi Pico 2 (with RP2350 chip) is an excellent alternative.. The main tradeoff is it lacks WiFi and Bluetooth, but it’s perfect for learning embedded fundamentals. There’s also a Pico 2 W variant that supports WiFi and Bluetooth, though you may need to adjust the code slightly when following tutorials with it. </a> But, Why ESP32 DevKit V1?</h3> Let me share my journey learning Embedded Rust as a beginner, which will help explain my recommendation. My First Board: micro:bit v2 The micro:bit was my first device. I chose it because the official Embedded Rust book had examples for it, so I thought I’d just buy one and follow along. The micro:bit is a nice board with built-in features like a microphone, speaker, and LED matrix, which are great for getting started quickly. However, I soon hit limitations. Connecting external components wasn’t straightforward. I needed an edge connector or expansion board to add sensors, buttons, or other peripherals. This added extra cost and complexity. The board itself was also expensive, costing about three times more than an ESP32 DevKit V1. My Second Board: Raspberry Pi Pico 2 Next, I bought a Raspberry Pi Pico 2 (with the RP2350 chip). It’s an excellent board, and I documented my learning in an open-source book called “Pico Pico” that I’m currently revising based on my experience. However, there is one thing I did not like: every time you want to run your new program on the board, you must press a button and reconnect the USB cable. And if you make changes again, you need to unplug and repeat the same steps. This becomes tiring very quickly. This problem can be solved with a debug probe, a separate piece of hardware. With a debug probe. With a debug probe, you can write and debug your code seamlessly without unplugging anything. However, buying a board plus a debug probe brings the total cost to about three times that of an ESP32 DevKit V1. But, the advantage is that you get proper debugging capabilities that work across different boards, but it’s an extra expense that’s not strictly necessary when you’re just starting out on a tight budget. My Third Board: ESP32 DevKit V1 Then I discovered the ESP32 DevKit V1, and everything changed. This board is a beast in terms of what it offers for the price. Here’s why it became my top recommendation: No button pressing needed: Just plug it in and write your code into the device. The board handles everything automatically.</li> Built-in WiFi and Bluetooth: Perfect for IoT projects without needing extra modules.</li> Very affordable: Making it one of the cheapest options.</li> Easy to connect components</li> Widely available: Easy to find from multiple sellers worldwide.</li> </ul> Even other ESP32 series often cost more or lack either WiFi or Bluetooth. The ESP32 on the DevKit V1 gives you the best bang for your buck. The Bottom Line If you’re just starting out and want the most flexibility at the lowest cost, get an ESP32 DevKit V1. You can build real projects with WiFi and Bluetooth connectivity without spending extra on debug probes or expansion boards. </a> Additional Components</h3> Apart from the development board, you’ll need some additional electronic components. Some are essentials like breadboards, jumper wires, and resistors. Others are optional, like LEDs (well, maybe not so optional!), various sensors, and other components. You can buy these as you progress through your learning journey. Wow, I didn’t expect to write this much about hardware itself! </a> Embedded Rust Basics</h2> Now that we’ve decided on which development board to buy, let’s focus on how to use it and where to go from here. I’ll be recommending only open source and free resources, which should be more than enough to get you started. </a> The Embedded Rust book</h3> Regardless of which board you choose, the first book</a> I recommend is the official book by the Embedded Rust Working Group. This will introduce you to the basic concepts of embedded Rust development. </a> Embassy Book</h3> Embassy is an async framework for embedded Rust. You can start learning it from the official Embassy Book</a>. It explains how async works on microcontrollers and shows a few examples. </a> Rustybits Youtube channel</h3> This is one of my favorite channels for learning Embedded Rust. The creator explains concepts very clearly with helpful videos like “From Zero to Async in Embedded Rust”. https://www.youtube.com/@therustybits/videos</a> </a> Learning Path for ESP32</h2> </a> The Rust on ESP Book</h3> The next resource is the official “The Rust on ESP Book</a>”. This book covers ESP32 and its variants, showing you how to set up your development tools and explaining the basic concepts of the ESP embedded Rust ecosystem. </a> impl Rust for ESP32 Book</h3> Next up is the book I wrote called “impl Rust for ESP32</a>”. This is an open source book</a> that uses the ESP32 DevKit V1 with Rust to build simple and fun projects. You’ll explore hands-on examples like turning on an LED when the room gets darker using an LDR sensor, using an ultrasonic sensor to detect nearby objects, controlling an LED through WiFi, drawing images and text on an OLED display, playing songs and alarm sounds with a buzzer, controlling a servo motor, running a web server and more. </a> Examples</h3> Once you understand the basics, you can explore the examples section of the HAL (Hardware Abstraction Layer) or other crates you’ll be using. The esp-hal repository has a nice set of examples: https://github.com/esp-rs/esp-hal/tree/main/examples</a> </a> Learning Path for Raspberry Pi Pico 2</h2> If you bought the Pico 2 (RP2350 chip) or if you “have” the older Pico version (RP2040), you can follow this learning path. </a> Pico Pico Book</h3> As I mentioned earlier, I wrote a book for the Raspberry Pi Pico 2 also. You can read it here</a>. This is an open source book</a> that uses the Pico 2 with Rust to build simple and fun projects. Like the ESP32 book, this also includes similar hands-on examples with various sensors and components. </a> Examples</h3> Once you understand the basics, you can explore the examples in the rp-hal repository. It has a good collection of examples for the Raspberry Pi Pico: For Raspberry Pi Pico 2 (RP2350): https://github.com/rp-rs/rp-hal/tree/main/rp235x-hal-examples</a> For Raspberry Pi Pico (RP2040): https://github.com/rp-rs/rp-hal/tree/main/rp2040-hal-examples</a> </a> Learning Path for Microbit:v2</h2> If you bought a micro:bit v2 board and want to learn Embedded Rust with it, these resources will help you. </a> micro::bit v2 Embedded Discovery Book</h3> This book, written by the official Embedded Rust Working Group, teaches embedded Rust using the BBC micro:bit v2. It is an introductory course that helps you learn how microcontrollers work and how to write embedded Rust code for them. You can read it online here: https://docs.rust-embedded.org/discovery-mb2/index.html</a> </a> impl Rust for Microbit</h3> This is an open source book</a> that teaches Embedded Rust on the BBC micro:bit v2 with hands-on, simple projects. It builds practical skills by walking through examples like controlling LEDs, reading sensors, and interacting with buttons and displays. The book is beginner friendly and focuses on learning by doing. You can read it online here: https://mb2.implrust.com/</a> </a> Other Resources</h2> Here are some other useful resources related to Embedded Rust. </a> Curated List - Awesome Embedded Rust</h3> This is a curated list of resources for embedded and low-level programming in Rust. It includes useful crates, tools, books, tutorials, and more. https://github.com/rust-embedded/awesome-embedded-rust</a> </a> Writing an OS in Rust</h3> You might wonder what writing an OS has to do with embedded Rust. In many embedded systems, there is no underlying OS at all. Your firmware is the only thing running on the device. This series gives a great introduction to low-level concepts that are also useful in embedded development. You will not be writing a full operating system, but you will learn many fundamentals. https://os.phil-opp.com/</a> </a> Rust Embedded Driver (RED) Book</h3> I have also written an open source book that focuses on building drivers in Embedded Rust. This book is slightly more advanced than my board-specific books, so it is best explored after completing the introductory material. It offers step-by-step guidance on writing drivers from the ground up for components such as the DHT22 sensor, the MAX7219 LED display (including an embedded-graphics implementation), RTC modules, and a platform-agnostic RTC HAL to illustrate the embedded-hal concept. https://red.implrust.com/</a> </a> Wokwi Platform</h3> Wokwi</a> is an online simulator for embedded projects. It lets you write code, connect virtual components, and test circuits in the browser. It supports boards like Arduino, ESP32, and Raspberry Pi Pico, and it also supports running Embedded Rust projects. It is a quick way to experiment, learn, and verify ideas without using real hardware. You can run simulations directly in the browser or through the Wokwi for VS Code</a> extension. In my experience, the Rust simulator on the website can be unreliable, while the VS Code extension works more consistently. However, nothing fully replaces having fun with real hardware. Let's understand what is Blanket Implementation in Rust 2025-09-07T00:00:00+00:00 While writing the RTC HAL chapter for the Rust Embedded Drivers (RED) book</a>, I needed to use blanket implementations as a design choice. Instead of explaining this concept in the book and cluttering the book, I thought it would be better to write a blog post instead. That’s how i end up with my first blog post in implRust :) </a> What is a Blanket Implementation?</h1> The name comes from the English idiom where “blanket” means something that covers or applies to multiple things at once. A blanket implementation lets you implement a trait for all types that meet certain conditions. Instead of writing the same trait implementation for different types one by one, you write it once and it applies to all matching types. Here’s the basic syntax: impl<T> MyTrait for T where T: SomeCondition { // implementation }</code></pre> You can read it as “For any type T that meets SomeCondition, implement MyTrait for T” </a> Example</h2> Let’s say we create a trait called Loggable</code> with a log method. Instead of implementing this trait for each individual type, we can use a blanket implementation for all types that implement the Debug trait: use core::fmt::Debug; trait Loggable { fn log(&self); } // Blanket implementation impl<T: Debug> Loggable for T { fn log(&self) { println!("[log] {:?}", self); } } #[allow(dead_code)] #[derive(Debug)] struct Cat { name: String, } fn main() { let numbers = vec![1, 2, 3]; numbers.log(); let s = String::from("Blanket"); s.log(); let c = Cat { name: "Astra".to_string() }; c.log(); }</code></pre> Now any type that implements Debug automatically gets the Loggable trait. We didn’t have to write separate implementations for Vec, String, or our custom Cat struct. </a> Rust Standard Library</h2> Blanket implementations are used extensively in the Rust standard library. A great example is how the ToString trait is implemented for any type that implements the Display trait: impl<T: fmt::Display + ?Sized> ToString for T { #[inline] fn to_string(&self) -> String { <Self as SpecToString>::spec_to_string(self) } }</code></pre> This means you don’t need to manually implement ToString for your types. If your type implements Display, it automatically gets the to_string() method for free. You can read more about this in the Rust book</a>. </a> Example Use Case: Embedded HAL’s I2C Blanket Implementation</h2> Here’s a simplified version of how embedded-hal uses blanket implementations for I2C. It implements the I2c trait for mutable references (&mut T) to all types that already implement I2c: mod hal { pub trait I2c { fn write(&mut self, data: &[u8]); } impl<T: I2c> I2c for &mut T { // Blanket Implementation #[inline] fn write(&mut self, data: &[u8]) { T::write(self, data); } } } use hal::I2c; pub struct I2cBus {} impl hal::I2c for I2cBus { fn write(&mut self, data: &[u8]) { dbg!(data); } } fn write_to_any_i2c<T: I2c>(mut i: T) { // assume this is a driver i.write(b"Rust"); } fn main() { let bus1 = I2cBus {}; write_to_any_i2c(bus1); // Takes ownership let mut bus2 = I2cBus {}; write_to_any_i2c(&mut bus2); // Takes reference }</code></pre></a> Why is this useful?</h3> This allows drivers to be flexible - they can take either ownership of the I2C device or just borrow it. Without this blanket implementation, you would need separate functions or the driver would be forced to choose between taking ownership or taking a reference, limiting how it can be used. Let’s comment out the blanket implementation and see what happens: mod hal { pub trait I2c { fn write(&mut self, data: &[u8]); } // impl<T: I2c> I2c for &mut T { // Blanket Implementation // #[inline] // fn write(&mut self, data: &[u8]) { // T::write(self, data); // } // } } use hal::I2c; pub struct I2cBus {} impl hal::I2c for I2cBus { fn write(&mut self, data: &[u8]) { dbg!(data); } } // Function that takes ownership fn write_to_any_i2c<T: I2c>(mut i: T) { i.write(b"Rust"); } // Function that takes a mutable reference fn write_to_any_i2c_ref<T: I2c>(i: &mut T) { i.write(b"Rust"); } fn main() { let bus1 = I2cBus {}; write_to_any_i2c(bus1); // Takes ownership // Compilation error: error[E0277]: the trait bound `&mut I2cBus: I2c` is not satisfied // let mut bus2 = I2cBus {}; // write_to_any_i2c(&mut bus2); // Takes reference let mut bus2 = I2cBus {}; write_to_any_i2c_ref(&mut bus2); // Takes reference }</code></pre> Without the blanket implementation, you need two separate functions - one for owned values and one for references. Your generic functions can’t work with both, so users have to pick the right function based on how they’re using their data. </a> With Great Power Comes Great Responsibility</h2> Blanket implementations are powerful, but they come with an important limitation: once you create a blanket implementation, you cannot create specific implementations for individual types that meet the same condition. For example, let’s say we want to add a Human struct that also implements Debug, but we want it to log differently than other types. We can’t do this: use core::fmt::Debug; trait Loggable { fn log(&self); } // Blanket implementation impl<T: Debug> Loggable for T { fn log(&self) { println!("[log] {:?}", self); } } #[allow(dead_code)] #[derive(Debug)] struct Cat { name: String, } #[allow(dead_code)] #[derive(Debug)] struct Human { first_name: String, last_name: String, } impl Loggable for Human{ fn log(&self){ println!("[log] This is Human {}", self.first_name) } } fn main() { let numbers = vec![1, 2, 3]; numbers.log(); let s = String::from("Blanket"); s.log(); let c = Cat { name: "Astra".to_string(), }; c.log(); let h = Human { first_name: "Astra".to_string(), last_name: "Kernel".to_string(), }; h.log(); }</code></pre> You’ll get a “conflicting implementations of trait” error because Rust can’t decide which implementation to use for Human - the blanket one or the specific one. This is why you need to carefully consider whether a blanket implementation is the right choice for your use case. Avoiding Breaking Changes with Rust's #[non_exhaustive] 2025-09-07T00:00:00+00:00 When you add new variants to public enums or new fields to public structs, you create a breaking change. This means any crates that depend on your library will need to update their code before they can use your new version. Rust’s #[non_exhaustive]</code> attribute solves this problem by telling the compiler that a type might gain new variants or fields in future versions, forcing external crates to write future-proof code from the start. Official doc explanation</a>: The non_exhaustive attribute indicates that a type or variant may have more fields or variants added in the future. </blockquote> Think of it as a “future-proofing” attribute that says “hey, I might add more to this later, so don’t assume this is complete” When you mark an enum with #[non_exhaustive], external crates must include a wildcard pattern (_) in their match statements, so adding new variants won’t break their code. For structs, it prevents direct construction using struct literal syntax and requires wildcards (..) in pattern matching, allowing you to safely add new fields later. This way, you can evolve your API without forcing breaking changes on your users - they write defensive code once, and your library can grow without breaking their applications. However, these restrictions only apply to downstream crates that depend on your library. Within the defining crate itself, these rules don’t apply. </a> Example: Marking enum with non_exhaustive attribute</h2> I’ll start with an enum example since we used this attribute for the ErrorKind enum in the RTC HAL chapter of the Rust Embedded Drivers (RED) book. That’s what made me want to write this post. Instead of explaining it in detail in the book, I decided to cover it separately here. Let’s say we’re creating a library called menu with an enum called Menu</code> that other developers can use in their apps. Let’s see what happens when you try to add a new variant to the enum. </a> Creating the Menu Library</h3> First, create a new library: cargo new --lib menu cd menu</code></pre> In src/lib.rs, define a simple menu enum: // menu/src/lib.rs pub enum Menu { Pizza, Burger, Tacos, } impl Menu { pub fn price(&self) -> f32 { match self { Menu::Pizza => 100.0, Menu::Burger => 180.0, Menu::Tacos => 60.0, } } }</code></pre></a> Creating an App That Uses the Library</h3> Now create an app that uses your menu library: cd .. cargo new restaurant_app cd restaurant_app</code></pre> Add your local menu library to Cargo.toml: # restaurant_app/Cargo.toml [dependencies] menu = { path = "../menu" }</code></pre> Use the library in the app: // restaurant_app/src/main.rs use menu::Menu; fn main() { let order = Menu::Pizza; match order { Menu::Pizza => println!("You ordered pizza for ${}", order.price()), Menu::Burger => println!("You ordered a burger for ${}", order.price()), Menu::Tacos => println!("You ordered tacos for ${}", order.price()), } }</code></pre> When you run the app, you should get output like “You ordered pizza for $12.99”. Everything works great! </a> The Breaking Change Problem</h3> A month later, you want to add burritos to your menu. Update the library: // menu/src/lib.rs pub enum Menu { Pizza, Burger, Tacos, Burrito, // New item! } impl Menu { pub fn price(&self) -> f32 { match self { Menu::Pizza => 100.0, Menu::Burger => 180.0, Menu::Tacos => 60.0, Menu::Burrito => 150.0, // Add price for burrito } } }</code></pre> Now try to run the restaurant app, you will get the following compile error: error[E0004]: non-exhaustive patterns: `Menu::Burrito` not covered --> src/main.rs:6:11 | 6 | match order { | ^^^^^ pattern `Menu::Burrito` not covered</code></pre> The app is broken now! Anyone using your library will have to update their code before they can use your new version. This is a breaking change. According to the Cargo docs</a>, this should be a major change. So as a library developer, you should bump your library version to the next major version (for example: 1.0.0 to 2.0.0) to maintain SemVer compatibility. </a> The Solution: Using #[non_exhaustive]</h3> Go back to your menu library and add the #[non_exhaustive] attribute: // menu/src/lib.rs #[non_exhaustive] pub enum Menu { Pizza, Burger, Tacos, } impl Menu { pub fn price(&self) -> f32 { match self { Menu::Pizza => 100.0, Menu::Burger => 180.0, Menu::Tacos => 60.0, } } }</code></pre> NOTE: adding non_exhaustive attribute itself is a breaking change because without the wildcard pattern, it will give compilation error. </blockquote> Now you have to update the restaurant app to handle the non-exhaustive enum: // restaurant_app/src/main.rs use menu::Menu; fn main() { let order = Menu::Pizza; match order { Menu::Pizza => println!("You ordered pizza for ${}", order.price()), Menu::Burger => println!("You ordered a burger for ${}", order.price()), Menu::Tacos => println!("You ordered tacos for ${}", order.price()), _ => println!("You ordered something for ${}", order.price()), } }</code></pre> The _ wildcard is now required. Without it, you get this error: “non-exhaustive patterns: _</code> not covered” </a> Adding New Variants Without Breaking Changes</h3> Now you can safely add the burrito: // menu/src/lib.rs #[non_exhaustive] pub enum Menu { Pizza, Burger, Tacos, Burrito, // New item added safely! } impl Menu { pub fn price(&self) -> f32 { match self { Menu::Pizza => 100.0, Menu::Burger => 180.0, Menu::Tacos => 60.0, Menu::Burrito => 150.0, } } }</code></pre> With this change, you can add more variants. No breaking change, no need to update the major version number. </a> Example: Marking struct with non_exhaustive attribute</h2> When you mark a struct with #[non_exhaustive], it prevents other crates from creating instances of that struct directly using the MyStruct { field: value }</code> syntax. They also can’t pattern match on it without using “..” to indicate there might be more fields in the future. Inside your own crate, you can still create and use the struct normally. But external crates must use constructor functions you provide and include “..” when pattern matching. This way, you can safely add new fields to your struct in future versions without breaking anyone’s code. Let’s add a configuration struct to our menu library: // menu/src/lib.rs #[non_exhaustive] pub struct MenuConfig { pub theme: String, pub show_prices: bool, } impl MenuConfig { pub fn new(theme: String) -> Self { Self { theme, show_prices: true, } } }</code></pre> We’ve marked MenuConfig with the #[non_exhaustive] attribute. If someone tries to create an instance of MenuConfig using struct literal syntax in the restaurant app, they’ll get the error “cannot create non-exhaustive struct using struct expression”: // This fails to compile! (in the app crate, not in the library) let config = MenuConfig { theme: "dark".to_string(), show_prices: false, };</code></pre> Instead, external crates must use the constructor function you provide: let config = MenuConfig::new("dark".to_string());</code></pre> You can still access the fields since we marked them as pub: println!("{}", config.theme);</code></pre> This way, you can safely add new fields like “font_size” or “language” to MenuConfig in future versions without breaking anyone’s code. </a> References</h2> Official Doc Reference</a></li> #[non_exhaustive] and private fields for extensibility </a></li> </ul>

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

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

Setting Up an Embedded Rust Development Environment

Analyzing PIO Blink Using Logic Analyzer on Raspberry Pi Pico with Embedded Rust

Analyzing UART Signals in Embedded Rust Using a Cheap USB Logic Analyzer

How to Use a Logic Analyzer in Embedded Rust Projects

Working with Fixed-Point Numbers in Rust Using the fixed Crate

Getting started: How to Learn Embedded Rust for Beginners

If you’re completely new to Rust, start with the official Rust Book</a> first. Understanding Rust’s ownership, borrowing, and type system is essential before tackling embedded development. Come back to this guide once you’re comfortable with basic Rust concepts.</p>

Regardless of which board you choose, the first book</a> I recommend is the official book by the Embedded Rust Working Group. This will introduce you to the basic concepts of embedded Rust development.</p>

Embassy is an async framework for embedded Rust. You can start learning it from the official Embassy Book</a>. It explains how async works on microcontrollers and shows a few examples.</p>

https://www.youtube.com/@therustybits/videos</a></p>

The next resource is the official “The Rust on ESP Book</a>”. This book covers ESP32 and its variants, showing you how to set up your development tools and explaining the basic concepts of the ESP embedded Rust ecosystem.</p>

https://github.com/esp-rs/esp-hal/tree/main/examples</a></p>

For Raspberry Pi Pico 2 (RP2350):</strong> https://github.com/rp-rs/rp-hal/tree/main/rp235x-hal-examples</a></p>
For Raspberry Pi Pico (RP2040):</strong> https://github.com/rp-rs/rp-hal/tree/main/rp2040-hal-examples</a></p>

You can read it online here:
https://docs.rust-embedded.org/discovery-mb2/index.html</a></p>

https://github.com/rust-embedded/awesome-embedded-rust</a></p>

Let's understand what is Blanket Implementation in Rust

Avoiding Breaking Changes with Rust's #[non_exhaustive]

Official Doc Reference</a></li>
#[non_exhaustive] and private fields for extensibility </a></li> </ul>

impl Blog for Rust

Can I Use Rust with Arduino Uno? Getting Started with Embedded Rust

UART Communication Between ESP32 and Raspberry Pi Pico in Rust