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.</p> Make sure the logic analyzer ground and the Pico ground are connected. Without a common ground, the captured signal will be unreliable.</p> </span></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.</p> 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.</p>` `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.</p>` </span></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.</p> 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.</p> 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.</p> </span></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.</p> While the pin is HIGH, the following instructions run:</p> set pins, 1 [31]</code> The instruction itself takes 1 cycle, and the delay adds 31 more cycles. Total: 32 cycles</p> </li> nop [31]</code> repeated 7 times Each nop [31]</code> takes 32 cycles. Total: 7 x 32 = 224 cycles</p> </li> </ul> So the total number of instruction cycles while the pin is HIGH is:</p> 32</span></span> + 224 = 256 cycles</span> </span></code></pre> With each instruction cycle taking about 0.524 ms, the total HIGH time becomes:</p> 256</span></span> x 0.524 ms ≈ 134 ms</span> </span></code></pre> </span></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.</p> While the pin is LOW, the following instructions run:</p> set pins, 0 [30]</code> The instruction itself takes 1 cycle, and the delay adds 30 more cycles. Total: 31 cycles</p> </li> nop [31]</code> repeated 7 times Total: 7 x 32 = 224 cycles</p> </li> jmp loop</code> This instruction takes 1 cycle</p> </li> </ul> So the total number of instruction cycles while the pin is LOW is:</p> 31</span></span> + 224 + 1 = 256 cycles</span> </span></code></pre> This again gives:</p> 256</span></span> x 0.524 ms ≈ 134 ms</span> </span></code></pre> </span></a> Putting It All Together</h3> From the instruction count, we end up with:</p> 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.</p> 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.</p> 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.</p> </span></a> What is UART?</h2> You might already be familiar with UART. Still, let me give a short introduction.</p> 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.</p> 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.</p> 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.</p> Let us look at a simple UART signal to understand this.</p> 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?</p> 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.</p> </span></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.</p> 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.</p> </span></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.</p> 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.</p> </span></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.</p> 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.</p> 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.</p> </span></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.</p> 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.</p> 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.</p> 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.</p> 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.</p> 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.</p> 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.</p> </div> TIP</strong> 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.</p> </div> </div> </span></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.</p> 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.</p> Connect CH1 of the logic analyzer to GPIO16 on the Pico. Also connect the logic analyzer ground to any ground pin on the Pico.</p> Logic Analyzer</th> Raspberry Pi Pico</th></tr></thead> GND</td> GND</td></tr> CH1</td> GPIO16</td></tr> </tbody></table> </span></a> Code Snippet</h2> Flash the program onto the Pico, then power up the board and connect the USB logic analyzer to the computer.</p> #</span>[</span>embassy_executor</span>::main</span>]</span></span> </span>async fn</span> </span>main</span></span>(</span>_spawner</span>:</span> Spawner</span>)</span></span></span></span> </span>{</span> </span></span></span> let</span> p =</span> embassy_rp::</span></span>init(</span>Default</span>::</span></span>default(</span></span>)</span></span></span>)</span></span>;</span> </span></span></span> </span></span></span> let</span> mut</span> uart_config =</span> UartConfig::</span></span>default(</span></span>)</span></span>;</span> </span></span></span> //</span> This is default baud rate in the embassy-rp, i just want to explicitly show </span></span></span></span> uart_config.</span>baudrate =</span> 115200</span>;</span> </span></span></span> </span></span></span> let</span> mut</span> uart_tx =</span> UartTx::</span></span>new_blocking(</span>p.</span>UART0</span>,</span> p.</span>PIN_16</span>,</span> uart_config</span>)</span></span>;</span> </span></span></span> </span></span></span> loop</span> {</span> </span></span></span></span> uart_tx </span></span></span></span> .</span>blocking_write</span>(</span>"</span>Rust"</span></span>.</span>as_bytes</span>(</span></span>)</span></span></span>)</span></span> </span></span></span></span> .</span>expect</span>(</span>"</span>unable to write into uart"</span></span></span>)</span></span>;</span> </span></span></span></span> Timer::</span></span>after_secs(</span>1</span></span>)</span></span>.</span>await;</span> </span></span></span></span> </span>}</span></span> </span></span></span></span>}</span></span></span> </span></code></pre> </span></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.</p> 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.</p> 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.</p> </span></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.</p> 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.</p> 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.</p> </span></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.</p> 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.</p> 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.</p> 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.</p> 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.</p> By default, the decoded data format is shown in hexadecimal. Since we are transmitting ASCII text, change the data format to ASCII.</p> 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.</p> Once this is done, PulseView will decode the captured UART signal and display the transmitted data.</p> </span></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.</p> PulseView also highlights the start bit with an “S” label (shown in yellow) and the stop bit with a “T” label.</p> 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.</p> 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.</p> 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.</p> </div> INFO</strong> 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.</p> </div> </div> </span></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.</p> 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.</p> 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.</p> </span></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).</p> 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.</p> </span></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).</p> 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.</p> </span></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.</p> 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.</p> </span></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.</p> There are two commonly mentioned software options when working with USB logic analyzers. Which one makes sense depends on the hardware you are using.</p> </span></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.</p> On Debian or Ubuntu-based systems, you can install PulseView using the package manager:</p> sudo</span></span> apt install pulseview sigrok</span> </span></code></pre> Official documentation for sigrok and PulseView is available here: https://sigrok.org/wiki/Main_Page</a></p> You can also refer to the PulseView user manual for more details: https://sigrok.org/doc/pulseview/unstable/manual.html</a></p> I will be using PulseView throughout this blog post.</p> </span></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.</p> You can download the Linux AppImage from the Saleae website: https://www.saleae.com/downloads/</a></p> Make it executable and run:</p> chmod</span></span> +x Logic-</span>.AppImage</span> </span>./Logic-.AppImage</span></span> </span></code></pre> </span></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.</p> I will be using a Raspberry Pi Pico here, but any other board will work.</p> We will flash a small program that toggles a GPIO pin between high and low states with a delay of 500 milliseconds.</p> 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.</p> </span></a> Code snippet</h3> let</span> p =</span> embassy_rp::</span></span>init(</span>Default</span>::</span></span>default(</span></span>)</span></span></span>)</span></span>;</span> </span>let</span> mut</span> pin =</span> Output::</span></span>new(</span>p.</span>PIN_15</span>,</span> Level::</span></span>Low</span>)</span></span>;</span> </span> </span>loop</span> {</span> </span></span> pin.</span>set_high</span>(</span></span>)</span></span>;</span> </span></span> Timer::</span></span>after_millis(</span>500</span></span>)</span></span>.</span>await;</span> </span></span> </span></span> pin.</span>set_low</span>(</span></span>)</span></span>;</span> </span></span> Timer::</span></span>after_millis(</span>500</span></span>)</span></span>.</span>await;</span> </span></span></span>}</span></span> </span></code></pre> </div> TIP</strong> 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.</p> </div> </div> </span></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.</p> 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.</p> 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.</p> </span></a> Opening PulseView and Detecting the Logic Analyzer</h2> Now lets open PulseView and make sure the logic analyzer is detected correctly.</p> 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.</p> 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.</p> </span></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”.</p> To understand these settings, it helps to know what a sample actually is.</p> 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.</p> </span></a> Number of Samples</h3> The number of samples tells the logic analyzer how many samples to record in total before stopping.</p> 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.</p> </span></a> Sample Rate</h3> The sample rate tells the logic analyzer how many samples to take every second.</p> 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.</p> 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.</p> </div> TIP</strong> From the Manual:</strong> 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.</p> </div> </div> </span></a> How They Work Together</h3> These two settings answer two different questions:</p> “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.</p> PulseView shows this relationship using the capture duration:</p> capture</span></span> duration = number of samples / sample rate</span> </span></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.</p> capture</span></span> duration = 100,000 / 20,000 = 5 seconds</span> </span></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.</p> </span></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.</p> 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.</p> 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.</p> Since the total capture duration is 5 seconds, this results in 5 HIGH periods and 5 LOW periods across the entire waveform.</p> 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.</p> 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.</p> </span></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.</p> 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.</p> 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.</p> </span></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.</p> </span></a> Understanding Fixed-Point Notation</h2> This idea is explained well in the fixed crate</a> documentation, but let me give a quick overview.</p> 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.</p> Fixed-point numbers maintain uniform spacing between consecutive values throughout their range. The step size formula is 1/2^f</code>.</p> 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.</p> </span></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.</p> For instance, if we allocate the last 4 bits for the fraction, we have 12 bits left for the integer.</p> </span></a> Example: 4 Fractional bits</h3> Here’s how the bits map to their values:</p> 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.</p> </span></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:</p> 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.</p> </span></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.</p> 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).</p> 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.</p> 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:</p> use</span> fixed::</span></span>types::</span></span>U12F4</span>;</span> </span></code></pre> </span></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.</p> To make things easier to understand, the example prints the same value in several different forms.</p> First, it prints the fixed-point value itself. The :.4 formatting is only for display and shows four digits after the decimal point.</p> Next, it uses helper methods from the fixed crate to print the fractional part and the integer part separately.</p> Then it prints the binary representation in two different ways.</p> 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.</p> 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.</p> use</span> fixed::</span></span>{</span>FixedU16,</span> types::</span></span>extra</span>}</span></span>;</span> </span>use</span> fixed::</span></span>types;</span> </span> </span>fn</span> </span>main</span></span>(</span></span>)</span></span></span></span> </span>{</span> </span></span></span> //</span> let f_u16: FixedU16<extra::U4> = FixedU16::from_num(5.75); // you can use this approach </span></span></span></span> let</span> f_u16:</span> FixedU16<</span>extra::</span></span>U4></span></span> =</span> types::</span></span>U12F4</span>::</span></span>from_num(</span>5.</span>75</span></span>)</span></span>;</span> //</span> or this approach </span></span></span></span> assert_eq!</span>(</span>f_u16,</span> 5.</span>75</span></span>)</span></span>;</span> </span></span></span> </span></span></span> println!</span>(</span></span>"</span>Fixed Point: {:.4}</span>"</span></span></span>,</span> f_u16)</span></span>;</span> </span></span></span> println!</span>(</span></span>"</span>Fraction: {}</span>"</span></span></span>,</span> f_u16.</span>frac</span>(</span></span>)</span></span>)</span></span>;</span> </span></span></span> println!</span>(</span></span>"</span>Integer: {}</span>"</span></span></span>,</span> f_u16.</span>int</span>(</span></span>)</span></span>)</span></span>;</span> </span></span></span> println!</span>(</span></span>"</span>Binary with Fraction repr: {:b}</span>"</span></span></span>,</span> f_u16)</span></span>;</span> </span></span></span> </span></span></span> //</span> println!("Actual binary: {:016b}", f_u16.to_bits()); </span></span></span></span> let</span> bits =</span> format!</span>(</span></span>"</span>{:016b}"</span></span></span>,</span> f_u16.</span>to_bits</span>(</span></span>)</span></span>)</span></span>;</span> </span></span></span> let</span> formatted =</span> format!</span>(</span></span> </span></span></span></span> "</span>{}</span>_{}</span>"</span></span></span>,</span> </span></span></span></span> &</span>bits[</span>..</span>12</span>]</span></span>,</span> </span></span></span></span> &</span>bits[</span>12</span>..</span>]</span></span>,</span> </span></span></span></span> )</span></span>;</span> </span></span></span> println!</span>(</span></span>"</span>Actual binary: {}</span>"</span></span></span>,</span> formatted)</span></span>;</span> </span></span></span> </span></span></span> println!</span>(</span></span>"</span>F32: {}</span>"</span></span></span>,</span> f_u16.</span>to_num::</span></span><</span>f32</span>></span></span>(</span></span>)</span></span>)</span></span>;</span> </span></span></span></span>}</span></span></span> </span></code></pre> If you run this code, you will see output like this:</p> Fixed</span></span> Point: 5.7500</span> </span>Frac:</span></span> 0.75</span> </span>Int:</span></span> 5</span> </span>Binary</span></span> with Fraction repr: 101.11</span> </span>Actual</span></span> binary: 000000000101_1100</span> </span>F32:</span></span> 5.75</span> </span></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.</p> To understand what this value really represents, let’s look at the binary representation.</p> 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.</p> The fractional part is where the confusion usually comes from. Each fractional bit represents a negative power of two.</p> fraction</span></span> = 1 × 0.5 + 1 × 0.25 + 0 × 0.125 + 0 × 0.0625</span> </span></code></pre> That adds up to 0.75.</p> </span></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.</p> use</span> fixed::</span></span>{</span>FixedU16,</span> types::</span></span>extra</span>}</span></span>;</span> </span>use</span> fixed::</span></span>types;</span> </span> </span>fn</span> </span>main</span></span>(</span></span>)</span></span></span></span> </span>{</span> </span></span></span> let</span> f_u16:</span> FixedU16<</span>extra::</span></span>U4></span></span> =</span> FixedU16::</span></span>from_num(</span>20.</span>3</span></span>)</span></span>;</span> </span></span></span> assert_eq!</span>(</span>f_u16,</span> 20.</span>3125</span></span>)</span></span>;</span> </span></span></span> </span></span></span> println!</span>(</span></span>"</span>Fixed Point: {:.4}</span>"</span></span></span>,</span> f_u16)</span></span>;</span> </span></span></span> println!</span>(</span></span>"</span>Fraction: {}</span>"</span></span></span>,</span> f_u16.</span>frac</span>(</span></span>)</span></span>)</span></span>;</span> </span></span></span> println!</span>(</span></span>"</span>Integer: {}</span>"</span></span></span>,</span> f_u16.</span>int</span>(</span></span>)</span></span>)</span></span>;</span> </span></span></span> println!</span>(</span></span>"</span>Binary with Fraction repr: {:b}</span>"</span></span></span>,</span> f_u16)</span></span>;</span> </span></span></span> </span></span></span> //</span> println!("Actual binary: {:016b}", f_u16.to_bits()); </span></span></span></span> let</span> bits =</span> format!</span>(</span></span>"</span>{:016b}"</span></span></span>,</span> f_u16.</span>to_bits</span>(</span></span>)</span></span>)</span></span>;</span> </span></span></span> let</span> formatted =</span> format!</span>(</span></span> </span></span></span></span> "</span>{}</span>_{}</span>"</span></span></span>,</span> </span></span></span></span> &</span>bits[</span>..</span>12</span>]</span></span>,</span> </span></span></span></span> &</span>bits[</span>12</span>..</span>]</span></span>,</span> </span></span></span></span> )</span></span>;</span> </span></span></span> println!</span>(</span></span>"</span>Actual binary: {}</span>"</span></span></span>,</span> formatted)</span></span>;</span> </span></span></span> </span></span></span> println!</span>(</span></span>"</span>F32: {}</span>"</span></span></span>,</span> f_u16.</span>to_num::</span></span><</span>f32</span>></span></span>(</span></span>)</span></span>)</span></span>;</span> </span></span></span></span>}</span></span></span> </span></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:</p> Fixed</span></span> Point: 20.3125</span> </span>Fraction:</span></span> 0.3</span> </span>Integer:</span></span> 20</span> </span>Binary</span></span> with Fraction repr: 10100.0101</span> </span>Actual</span></span> binary: 000000010100_0101</span> </span>F32:</span></span> 20.3125</span> </span></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></p> 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></p> In the binary, it is represented like this:</p> 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:</p> fraction</span></span> = 0 × 0.5 + 1 × 0.25 + 0 × 0.125 + 1 × 0.0625 = 0.3125</span> </span></code></pre> </span></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.</p> 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.</p> The following code snippet is from the rp-pac</a> crate and shows how the divider register is defined.</p> #</span>[</span>doc</span> =</span> "</span>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."</span></span>]</span></span> </span>#</span>[</span>repr</span>(</span></span></span>transparent</span></span>)</span></span></span>]</span></span> </span>#</span>[</span>derive</span>(</span></span></span>Copy,</span> Clone,</span> Eq,</span> PartialEq</span></span>)</span></span></span>]</span></span> </span>pub</span> struct</span> </span>ChDiv</span></span>(</span>pub u32</span></span>)</span></span>;</span> </span>impl</span> </span>ChDiv</span> </span>{</span> </span></span></span> #</span>[</span>inline</span>(</span></span></span>always</span></span>)</span></span></span>]</span></span> </span></span></span> pub</span> const</span> fn</span> </span>frac</span></span>(</span>&</span>self</span></span>)</span></span></span></span> -></span> u8</span></span> </span>{</span> </span></span></span></span></span> let</span> val =</span> (</span>self</span>.</span>0</span> ></span>></span> 0</span>usize</span></span>)</span></span> &</span> 0x0f</span>;</span> </span></span></span></span></span> val as</span> u8</span> </span></span></span></span></span> </span>}</span></span></span> </span></span></span> </span></span></span> ...</span> </span></span></span> </span></span></span> #</span>[</span>inline</span>(</span></span></span>always</span></span>)</span></span></span>]</span></span> </span></span></span> pub</span> const</span> fn</span> </span>int</span></span>(</span>&</span>self</span></span>)</span></span></span></span> -></span> u8</span></span> </span>{</span> </span></span></span></span></span> let</span> val =</span> (</span>self</span>.</span>0</span> ></span>></span> 4</span>usize</span></span>)</span></span> &</span> 0xff</span>;</span> </span></span></span></span></span> val as</span> u8</span> </span></span></span></span></span> </span>}</span></span></span> </span></span></span> </span></span></span> ...</span> </span></span></span></span>}</span></span></span> </span></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.</p> 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.</p> if</span> config.</span>divider ></span> FixedU16::</span></span><</span>fixed::</span></span>types::</span></span>extra::</span></span>U4></span></span>::</span></span>from_bits(</span>0xFFF</span></span>)</span></span> {</span> </span></span> panic!</span>(</span>"</span>Requested divider is too large"</span></span></span>)</span></span>;</span> </span></span></span>}</span></span> </span> </span>p.</span>div</span>(</span></span>)</span></span>.</span>write_value</span>(</span>ChDiv(</span>config.</span>divider.</span>to_bits</span>(</span></span>)</span></span> as</span> u32</span></span>)</span></span></span>)</span></span>;</span> </span></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.</p> </span></a> Table of Contents</h2> </span></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.</p> </span></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.</p> The remaining sections focus on resources for embedded programming beginners.</p> </span></a> Prerequisites</h2> Before learning Embedded Rust, make sure you are comfortable with these basics:</p> </span></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.</p> </span></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.</p> </span></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.</p> </span></a> What are Microcontrollers and Development Boards?</h3> A microcontroller</strong> 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.</p> A development board</strong> (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.</p> </span></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.</p> </div> TIP</strong> My recommendation: Get an ESP32 development board.</p> </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.</p> Look for these boards - they all use the original ESP32 chip:</strong></p> “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.</p> </li> “ESP32 DevKit C”</p> </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.</p> Important:</strong> ESP32 comes in different variants (original ESP32, ESP32-S2, ESP32-S3, ESP32-C3, ESP32-C6, etc.). I’m recommending the original ESP32</strong> (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.</p> Alternative option: Raspberry Pi Pico 2</strong></p> If you can’t find an ESP32 board where you live, the Raspberry Pi Pico 2</strong> (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.</p> </span></a> But, Why ESP32 DevKit V1?</h3> Let me share my journey learning Embedded Rust as a beginner, which will help explain my recommendation.</p> My First Board: micro:bit v2</strong></p> 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.</p> 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.</p> My Second Board: Raspberry Pi Pico 2</strong></p> 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.</p> 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.</p> 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.</p> My Third Board: ESP32 DevKit V1</strong></p> 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:</p> 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.</p> The Bottom Line</strong></p> 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.</p> </span></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.</p> Wow, I didn’t expect to write this much about hardware itself!</p> </span></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.</p> </span></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.</p> </span></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.</p> </span></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”.</p> https://www.youtube.com/@therustybits/videos</a></p> </span></a> Learning Path for ESP32</h2> </span></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.</p> </span></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.</p> </span></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:</p> https://github.com/esp-rs/esp-hal/tree/main/examples</a></p> </span></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.</p> </span></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.</p> </span></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:</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> </span></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.</p> </span></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.</p> You can read it online here: https://docs.rust-embedded.org/discovery-mb2/index.html</a></p> </span></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.</p> You can read it online here: https://mb2.implrust.com/</a></p> </span></a> Other Resources</h2> Here are some other useful resources related to Embedded Rust.</p> </span></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.</p> https://github.com/rust-embedded/awesome-embedded-rust</a></p> </span></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.</p> https://os.phil-opp.com/</a></p> </span></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.</p> https://red.implrust.com/</a></p> </span></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.</p> 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.</p> 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 :)</p> </span></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.</p> Here’s the basic syntax:</p> impl</span></span><</span>T></span></span></span> MyTrait for</span></span> T</span> </span></span></span>where</span> </span></span> T:</span> SomeCondition </span></span></span>{</span> </span></span></span> //</span> implementation </span></span></span></span></span>}</span></span></span> </span></code></pre> You can read it as “For any type T that meets SomeCondition, implement MyTrait for T”</p> </span></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:</p> use</span> core::</span></span>fmt::</span></span>Debug;</span> </span> </span>trait</span> Loggable</span> {</span> </span></span></span> fn</span> </span>log</span></span>(</span>&</span>self</span></span>)</span></span></span></span>;</span> </span></span></span></span>}</span></span></span> </span> </span>//</span> Blanket implementation </span></span>impl</span></span><</span>T:</span> Debug></span></span></span> Loggable for</span></span> T</span> </span>{</span> </span></span></span> fn</span> </span>log</span></span>(</span>&</span>self</span></span>)</span></span></span></span> </span>{</span> </span></span></span></span></span> println!</span>(</span></span>"</span>[log] {:?}</span>"</span></span></span>,</span> self</span>)</span></span>;</span> </span></span></span></span></span> </span>}</span></span></span> </span></span></span></span>}</span></span></span> </span> </span>#</span>[</span>allow</span>(</span></span></span>dead_code</span></span>)</span></span></span>]</span></span> </span>#</span>[</span>derive</span>(</span></span></span>Debug</span></span>)</span></span></span>]</span></span> </span>struct</span> </span>Cat</span> </span>{</span> </span></span></span> name</span>:</span> String, </span></span></span></span>}</span></span></span> </span> </span>fn</span> </span>main</span></span>(</span></span>)</span></span></span></span> </span>{</span> </span></span></span> let</span> numbers =</span> vec!</span>[</span>1</span>,</span> 2</span>,</span> 3</span>]</span></span>;</span> </span></span></span> numbers.</span>log</span>(</span></span>)</span></span>;</span> </span></span></span> </span></span></span> let</span> s =</span> String</span>::</span></span>from(</span>"</span>Blanket"</span></span></span>)</span></span>;</span> </span></span></span> s.</span>log</span>(</span></span>)</span></span>;</span> </span></span></span> </span></span></span> let</span> c =</span> Cat {</span> name:</span> "</span>Astra"</span></span>.</span>to_string</span>(</span></span>)</span></span> </span>}</span></span>;</span> </span></span></span> c.</span>log</span>(</span></span>)</span></span>;</span> </span></span></span></span>}</span></span></span> </span></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.</p> </span></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:</p> impl</span></span><</span>T:</span> fmt::</span></span>Display +</span> ?</span></span></span>Sized</span>> ToString</span> for</span> T</span> </span>{</span> </span></span></span> #</span>[</span>inline</span>]</span></span> </span></span></span> fn</span> </span>to_string</span></span>(</span>&</span>self</span></span>)</span></span></span></span> -></span> String</span> </span>{</span> </span></span></span></span></span> <</span>Self</span> as</span> SpecToString></span>::</span></span>spec_to_string(</span>self</span></span>)</span></span> </span></span></span></span></span> </span>}</span></span></span> </span></span></span></span>}</span></span></span> </span></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>.</p> </span></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:</p> mod</span> hal</span> {</span> </span></span></span> pub</span> trait</span> I2c</span> {</span> </span></span></span></span></span> fn</span> </span>write</span></span>(</span>&</span>mut</span> self</span>, data</span>:</span> &</span>[u8</span>]</span>)</span></span></span></span>;</span> </span></span></span></span></span> </span>}</span></span></span> </span></span></span> </span></span></span> impl</span></span><</span>T:</span> I2c></span></span></span> I2c for</span></span> &</span>mut</span> T</span> </span>{</span> //</span> Blanket Implementation </span></span></span></span></span></span> #</span>[</span>inline</span>]</span></span> </span></span></span></span></span> fn</span> </span>write</span></span>(</span>&</span>mut</span> self</span>, data</span>:</span> &</span>[u8</span>]</span>)</span></span></span></span> </span>{</span> </span></span></span></span></span></span></span> T::</span></span>write(</span>self</span>,</span> data</span>)</span></span>;</span> </span></span></span></span></span></span></span> </span>}</span></span></span> </span></span></span></span></span> </span>}</span></span></span> </span></span></span></span>}</span></span></span> </span> </span>use</span> hal::</span></span>I2c;</span> </span> </span>pub</span> struct</span> </span>I2cBus</span> </span>{</span></span>}</span></span></span> </span> </span>impl</span> </span>hal::</span></span>I2c for</span></span> I2cBus</span> </span>{</span> </span></span></span> fn</span> </span>write</span></span>(</span>&</span>mut</span> self</span>, data</span>:</span> &</span>[u8</span>]</span>)</span></span></span></span> </span>{</span> </span></span></span></span></span> dbg!</span>(</span>data</span>)</span></span>;</span> </span></span></span></span></span> </span>}</span></span></span> </span></span></span></span>}</span></span></span> </span> </span>fn</span> </span>write_to_any_i2c</span></span><</span>T:</span> I2c></span></span>(</span>mut</span> i</span>:</span> T</span>)</span></span></span></span> </span>{</span> //</span> assume this is a driver </span></span></span></span> i.</span>write</span>(</span>b</span>"</span>Rust"</span></span></span>)</span></span>;</span> </span></span></span></span>}</span></span></span> </span> </span>fn</span> </span>main</span></span>(</span></span>)</span></span></span></span> </span>{</span> </span></span></span> let</span> bus1 =</span> I2cBus {</span></span>}</span></span>;</span> </span></span></span> write_to_any_i2c</span>(</span>bus1</span>)</span></span>;</span> //</span> Takes ownership </span></span></span></span> </span></span></span> let</span> mut</span> bus2 =</span> I2cBus {</span></span>}</span></span>;</span> </span></span></span> write_to_any_i2c</span>(</span>&</span>mut</span> bus2</span>)</span></span>;</span> //</span> Takes reference </span></span></span></span></span>}</span></span></span> </span></code></pre> </span></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.</p> Let’s comment out the blanket implementation and see what happens:</p> mod</span> hal</span> {</span> </span></span></span> pub</span> trait</span> I2c</span> {</span> </span></span></span></span></span> fn</span> </span>write</span></span>(</span>&</span>mut</span> self</span>, data</span>:</span> &</span>[u8</span>]</span>)</span></span></span></span>;</span> </span></span></span></span></span> </span>}</span></span></span> </span></span></span> </span></span></span> //</span> impl<T: I2c> I2c for &mut T { // Blanket Implementation </span></span></span></span> //</span> #[inline] </span></span></span></span> //</span> fn write(&mut self, data: &[u8]) { </span></span></span></span> //</span> T::write(self, data); </span></span></span></span> //</span> } </span></span></span></span> //</span> } </span></span></span></span></span>}</span></span></span> </span> </span>use</span> hal::</span></span>I2c;</span> </span> </span>pub</span> struct</span> </span>I2cBus</span> </span>{</span></span>}</span></span></span> </span> </span>impl</span> </span>hal::</span></span>I2c for</span></span> I2cBus</span> </span>{</span> </span></span></span> fn</span> </span>write</span></span>(</span>&</span>mut</span> self</span>, data</span>:</span> &</span>[u8</span>]</span>)</span></span></span></span> </span>{</span> </span></span></span></span></span> dbg!</span>(</span>data</span>)</span></span>;</span> </span></span></span></span></span> </span>}</span></span></span> </span></span></span></span>}</span></span></span> </span> </span>//</span> Function that takes ownership </span></span>fn</span> </span>write_to_any_i2c</span></span><</span>T:</span> I2c></span></span>(</span>mut</span> i</span>:</span> T</span>)</span></span></span></span> </span>{</span> </span></span></span> i.</span>write</span>(</span>b</span>"</span>Rust"</span></span></span>)</span></span>;</span> </span></span></span></span>}</span></span></span> </span> </span>//</span> Function that takes a mutable reference </span></span>fn</span> </span>write_to_any_i2c_ref</span></span><</span>T:</span> I2c></span></span>(</span>i</span>:</span> &</span>mut</span> T</span>)</span></span></span></span> </span>{</span> </span></span></span> i.</span>write</span>(</span>b</span>"</span>Rust"</span></span></span>)</span></span>;</span> </span></span></span></span>}</span></span></span> </span> </span> </span>fn</span> </span>main</span></span>(</span></span>)</span></span></span></span> </span>{</span> </span></span></span> let</span> bus1 =</span> I2cBus {</span></span>}</span></span>;</span> </span></span></span> write_to_any_i2c</span>(</span>bus1</span>)</span></span>;</span> //</span> Takes ownership </span></span></span></span> </span></span></span> //</span> Compilation error: error[E0277]: the trait bound `&mut I2cBus: I2c` is not satisfied </span></span></span></span> //</span> let mut bus2 = I2cBus {}; </span></span></span></span> //</span> write_to_any_i2c(&mut bus2); // Takes reference </span></span></span></span> </span></span></span> let</span> mut</span> bus2 =</span> I2cBus {</span></span>}</span></span>;</span> </span></span></span> write_to_any_i2c_ref</span>(</span>&</span>mut</span> bus2</span>)</span></span>;</span> //</span> Takes reference </span></span></span></span></span>}</span></span></span> </span></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.</p> </span></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.</p> 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:</p> use</span> core::</span></span>fmt::</span></span>Debug;</span> </span> </span>trait</span> Loggable</span> {</span> </span></span></span> fn</span> </span>log</span></span>(</span>&</span>self</span></span>)</span></span></span></span>;</span> </span></span></span></span>}</span></span></span> </span> </span>//</span> Blanket implementation </span></span>impl</span></span><</span>T:</span> Debug></span></span></span> Loggable for</span></span> T</span> </span>{</span> </span></span></span> fn</span> </span>log</span></span>(</span>&</span>self</span></span>)</span></span></span></span> </span>{</span> </span></span></span></span></span> println!</span>(</span></span>"</span>[log] {:?}</span>"</span></span></span>,</span> self</span>)</span></span>;</span> </span></span></span></span></span> </span>}</span></span></span> </span></span></span></span>}</span></span></span> </span> </span>#</span>[</span>allow</span>(</span></span></span>dead_code</span></span>)</span></span></span>]</span></span> </span>#</span>[</span>derive</span>(</span></span></span>Debug</span></span>)</span></span></span>]</span></span> </span>struct</span> </span>Cat</span> </span>{</span> </span></span></span> name</span>:</span> String, </span></span></span></span>}</span></span></span> </span> </span>#</span>[</span>allow</span>(</span></span></span>dead_code</span></span>)</span></span></span>]</span></span> </span>#</span>[</span>derive</span>(</span></span></span>Debug</span></span>)</span></span></span>]</span></span> </span>struct</span> </span>Human</span> </span>{</span> </span></span></span> first_name</span>:</span> String, </span></span></span> last_name</span>:</span> String, </span></span></span></span>}</span></span></span> </span> </span>impl</span> </span>Loggable for</span></span> Human</span></span>{</span> </span></span></span> fn</span> </span>log</span></span>(</span>&</span>self</span></span>)</span></span></span></span></span>{</span> </span></span></span></span></span> println!</span>(</span></span>"</span>[log] This is Human {}</span>"</span></span></span>,</span> self</span>.</span>first_name)</span></span> </span></span></span></span></span> </span>}</span></span></span> </span></span></span></span>}</span></span></span> </span> </span>fn</span> </span>main</span></span>(</span></span>)</span></span></span></span> </span>{</span> </span></span></span> let</span> numbers =</span> vec!</span>[</span>1</span>,</span> 2</span>,</span> 3</span>]</span></span>;</span> </span></span></span> numbers.</span>log</span>(</span></span>)</span></span>;</span> </span></span></span> </span></span></span> let</span> s =</span> String</span>::</span></span>from(</span>"</span>Blanket"</span></span></span>)</span></span>;</span> </span></span></span> s.</span>log</span>(</span></span>)</span></span>;</span> </span></span></span> </span></span></span> let</span> c =</span> Cat {</span> </span></span></span></span> name:</span> "</span>Astra"</span></span>.</span>to_string</span>(</span></span>)</span></span>,</span> </span></span></span></span> </span>}</span></span>;</span> </span></span></span> c.</span>log</span>(</span></span>)</span></span>;</span> </span></span></span> </span></span></span> let</span> h =</span> Human {</span> </span></span></span></span> first_name:</span> "</span>Astra"</span></span>.</span>to_string</span>(</span></span>)</span></span>,</span> </span></span></span></span> last_name:</span> "</span>Kernel"</span></span>.</span>to_string</span>(</span></span>)</span></span>,</span> </span></span></span></span> </span>}</span></span>;</span> </span></span></span> h.</span>log</span>(</span></span>)</span></span>;</span> </span></span></span></span>}</span></span></span> </span></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.</p> This is why you need to carefully consider whether a blanket implementation is the right choice for your use case.</p> 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.</p> Official doc explanation</a>: The non_exhaustive attribute indicates that a type or variant may have more fields or variants added in the future.</p> </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”</p> 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.</p> However, these restrictions only apply to downstream crates that depend on your library. Within the defining crate itself, these rules don’t apply.</p> </span></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.</p> 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.</p> </span></a> Creating the Menu Library</h3> First, create a new library:</p> cargo</span></span> new --</span>lib</span> menu</span> </span>cd</span></span> menu</span> </span></code></pre> In src/lib.rs, define a simple menu enum:</p> //</span> menu/src/lib.rs </span></span>pub</span> enum</span> Menu</span> {</span> </span></span></span> Pizza,</span> </span></span></span> Burger,</span> </span></span></span> Tacos,</span> </span></span></span></span>}</span></span></span> </span> </span>impl</span> </span>Menu</span> </span>{</span> </span></span></span> pub</span> fn</span> </span>price</span></span>(</span>&</span>self</span></span>)</span></span></span></span> -></span> f32</span></span> </span>{</span> </span></span></span></span></span> match</span> self</span> {</span> </span></span></span></span></span></span> Menu::</span></span>Pizza =></span> 100.</span>0</span>,</span> </span></span></span></span></span></span> Menu::</span></span>Burger =></span> 180.</span>0</span>,</span> </span></span></span></span></span></span> Menu::</span></span>Tacos =></span> 60.</span>0</span>,</span> </span></span></span></span></span></span> </span>}</span></span> </span></span></span></span></span> </span>}</span></span></span> </span></span></span></span>}</span></span></span> </span></code></pre> </span></a> Creating an App That Uses the Library</h3> Now create an app that uses your menu library:</p> cd</span></span> ..</span> </span>cargo</span></span> new restaurant_app</span> </span>cd</span></span> restaurant_app</span> </span></code></pre> Add your local menu library to Cargo.toml:</p> #</span> restaurant_app/Cargo.toml</span> </span>[</span>dependencies</span></span>]</span> </span>menu</span></span> =</span> {</span> path</span></span> =</span> "</span>../menu"</span></span> }</span> </span></code></pre> Use the library in the app:</p> //</span> restaurant_app/src/main.rs </span></span>use</span> menu::</span></span>Menu;</span> </span> </span>fn</span> </span>main</span></span>(</span></span>)</span></span></span></span> </span>{</span> </span></span></span> let</span> order =</span> Menu::</span></span>Pizza;</span> </span></span></span> </span></span></span> match</span> order {</span> </span></span></span></span> Menu::</span></span>Pizza =></span> println!</span>(</span></span>"</span>You ordered pizza for ${}</span>"</span></span></span>,</span> order.</span>price</span>(</span></span>)</span></span>)</span></span>,</span> </span></span></span></span> Menu::</span></span>Burger =></span> println!</span>(</span></span>"</span>You ordered a burger for ${}</span>"</span></span></span>,</span> order.</span>price</span>(</span></span>)</span></span>)</span></span>,</span> </span></span></span></span> Menu::</span></span>Tacos =></span> println!</span>(</span></span>"</span>You ordered tacos for ${}</span>"</span></span></span>,</span> order.</span>price</span>(</span></span>)</span></span>)</span></span>,</span> </span></span></span></span> </span>}</span></span> </span></span></span></span>}</span></span></span> </span></code></pre> When you run the app, you should get output like “You ordered pizza for $12.99”. Everything works great!</p> </span></a> The Breaking Change Problem</h3> A month later, you want to add burritos to your menu. Update the library:</p> //</span> menu/src/lib.rs </span></span>pub</span> enum</span> Menu</span> {</span> </span></span></span> Pizza,</span> </span></span></span> Burger,</span> </span></span></span> Tacos,</span> </span></span></span> Burrito,</span> //</span> New item! </span></span></span></span></span>}</span></span></span> </span> </span>impl</span> </span>Menu</span> </span>{</span> </span></span></span> pub</span> fn</span> </span>price</span></span>(</span>&</span>self</span></span>)</span></span></span></span> -></span> f32</span></span> </span>{</span> </span></span></span></span></span> match</span> self</span> {</span> </span></span></span></span></span></span> Menu::</span></span>Pizza =></span> 100.</span>0</span>,</span> </span></span></span></span></span></span> Menu::</span></span>Burger =></span> 180.</span>0</span>,</span> </span></span></span></span></span></span> Menu::</span></span>Tacos =></span> 60.</span>0</span>,</span> </span></span></span></span></span></span> Menu::</span></span>Burrito =></span> 150.</span>0</span>,</span> //</span> Add price for burrito </span></span></span></span></span></span></span> </span>}</span></span> </span></span></span></span></span> </span>}</span></span></span> </span></span></span></span>}</span></span></span> </span></code></pre> Now try to run the restaurant app, you will get the following compile error:</p> error[E0004]:</span></span> non-exhaustive patterns: `</span>Menu::Burrito</span></span>`</span></span> not covered</span> </span> --</span></span>></span> src/main.rs:6:11</span> </span> </span>\|</span> </span>6</span></span> \|</span> match</span></span> order {</span> </span></span></span> \| ^^^^^ pattern `</span>Menu::Burrito</span></span>`</span></span> not covered </span></span></span></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.</p> </span></a> The Solution: Using #[non_exhaustive]</h3> Go back to your menu library and add the #[non_exhaustive] attribute:</p> //</span> menu/src/lib.rs </span></span>#</span>[</span>non_exhaustive</span>]</span></span> </span>pub</span> enum</span> Menu</span> {</span> </span></span></span> Pizza,</span> </span></span></span> Burger,</span> </span></span></span> Tacos,</span> </span></span></span></span>}</span></span></span> </span> </span>impl</span> </span>Menu</span> </span>{</span> </span></span></span> pub</span> fn</span> </span>price</span></span>(</span>&</span>self</span></span>)</span></span></span></span> -></span> f32</span></span> </span>{</span> </span></span></span></span></span> match</span> self</span> {</span> </span></span></span></span></span></span> Menu::</span></span>Pizza =></span> 100.</span>0</span>,</span> </span></span></span></span></span></span> Menu::</span></span>Burger =></span> 180.</span>0</span>,</span> </span></span></span></span></span></span> Menu::</span></span>Tacos =></span> 60.</span>0</span>,</span> </span></span></span></span></span></span> </span>}</span></span> </span></span></span></span></span> </span>}</span></span></span> </span></span></span></span>}</span></span></span> </span></code></pre> NOTE: adding non_exhaustive attribute itself is a breaking change because without the wildcard pattern, it will give compilation error.</p> </blockquote> Now you have to update the restaurant app to handle the non-exhaustive enum:</p> //</span> restaurant_app/src/main.rs </span></span>use</span> menu::</span></span>Menu;</span> </span> </span>fn</span> </span>main</span></span>(</span></span>)</span></span></span></span> </span>{</span> </span></span></span> let</span> order =</span> Menu::</span></span>Pizza;</span> </span></span></span> </span></span></span> match</span> order {</span> </span></span></span></span> Menu::</span></span>Pizza =></span> println!</span>(</span></span>"</span>You ordered pizza for ${}</span>"</span></span></span>,</span> order.</span>price</span>(</span></span>)</span></span>)</span></span>,</span> </span></span></span></span> Menu::</span></span>Burger =></span> println!</span>(</span></span>"</span>You ordered a burger for ${}</span>"</span></span></span>,</span> order.</span>price</span>(</span></span>)</span></span>)</span></span>,</span> </span></span></span></span> Menu::</span></span>Tacos =></span> println!</span>(</span></span>"</span>You ordered tacos for ${}</span>"</span></span></span>,</span> order.</span>price</span>(</span></span>)</span></span>)</span></span>,</span> </span></span></span></span> _</span> =></span> println!</span>(</span></span>"</span>You ordered something for ${}</span>"</span></span></span>,</span> order.</span>price</span>(</span></span>)</span></span>)</span></span>,</span> </span></span></span></span> </span>}</span></span> </span></span></span></span>}</span></span></span> </span></code></pre> The _ wildcard is now required. Without it, you get this error: “non-exhaustive patterns: _</code> not covered”</p> </span></a> Adding New Variants Without Breaking Changes</h3> Now you can safely add the burrito:</p> //</span> menu/src/lib.rs </span></span>#</span>[</span>non_exhaustive</span>]</span></span> </span>pub</span> enum</span> Menu</span> {</span> </span></span></span> Pizza,</span> </span></span></span> Burger,</span> </span></span></span> Tacos,</span> </span></span></span> Burrito,</span> //</span> New item added safely! </span></span></span></span></span>}</span></span></span> </span> </span>impl</span> </span>Menu</span> </span>{</span> </span></span></span> pub</span> fn</span> </span>price</span></span>(</span>&</span>self</span></span>)</span></span></span></span> -></span> f32</span></span> </span>{</span> </span></span></span></span></span> match</span> self</span> {</span> </span></span></span></span></span></span> Menu::</span></span>Pizza =></span> 100.</span>0</span>,</span> </span></span></span></span></span></span> Menu::</span></span>Burger =></span> 180.</span>0</span>,</span> </span></span></span></span></span></span> Menu::</span></span>Tacos =></span> 60.</span>0</span>,</span> </span></span></span></span></span></span> Menu::</span></span>Burrito =></span> 150.</span>0</span>,</span> </span></span></span></span></span></span> </span>}</span></span> </span></span></span></span></span> </span>}</span></span></span> </span></span></span></span>}</span></span></span> </span></code></pre> With this change, you can add more variants. No breaking change, no need to update the major version number.</p> </span></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.</p> 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.</p> This way, you can safely add new fields to your struct in future versions without breaking anyone’s code.</p> Let’s add a configuration struct to our menu library:</p> //</span> menu/src/lib.rs </span></span>#</span>[</span>non_exhaustive</span>]</span></span> </span>pub</span> struct</span> </span>MenuConfig</span> </span>{</span> </span></span></span> pub</span> theme</span>:</span> String, </span></span></span> pub</span> show_prices</span>:</span> bool</span>, </span></span></span></span>}</span></span></span> </span> </span>impl</span> </span>MenuConfig</span> </span>{</span> </span></span></span> pub</span> fn</span> </span>new</span></span>(</span>theme</span>:</span> String</span>)</span></span></span></span> -></span> Self</span></span> </span>{</span> </span></span></span></span></span> Self</span> {</span> </span></span></span></span></span></span> theme,</span> </span></span></span></span></span></span> show_prices:</span> true</span>,</span> </span></span></span></span></span></span> </span>}</span></span> </span></span></span></span></span> </span>}</span></span></span> </span></span></span></span>}</span></span></span> </span></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”:</p> //</span> This fails to compile! (in the app crate, not in the library) </span></span>let</span> config =</span> MenuConfig {</span> </span></span> theme:</span> "</span>dark"</span></span>.</span>to_string</span>(</span></span>)</span></span>,</span> </span></span> show_prices:</span> false</span>,</span> </span></span></span>}</span></span>;</span> </span></code></pre> Instead, external crates must use the constructor function you provide:</p> let</span> config =</span> MenuConfig::</span></span>new(</span>"</span>dark"</span></span>.</span>to_string</span>(</span></span>)</span></span></span>)</span></span>;</span> </span></code></pre> You can still access the fields since we marked them as pub:</p> println!</span>(</span></span>"</span>{}</span>"</span></span></span>,</span> config.</span>theme)</span></span>;</span> </span></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.</p> </span></a> References</h2> Official Doc Reference</a></li> #[non_exhaustive] and private fields for extensibility </a></li> </ul>

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.

state_machine_clock</span></span> = clk_sys / clock_divider</span>
</span></code></pre>
In our setup:</p>

System clock = 125 MHz</li>
PIO clock divider = 65535</li>
</ul>
So the instruction execution rate becomes:</p>
125,000,000</span></span> / 65,535 ≈ 1,907.38 instructions per second</span>
</span></code></pre>
This means the PIO state machine executes roughly 1.9 thousand instructions per second.</p>
</span></a>
Instruction Cycles and Delays</h3>
By default, every PIO instruction takes exactly one instruction cycle to execute.</p>
PIO also supports an instruction delay modifier, written using square brackets. For example:</p>
set</span></span> pins, 1 [</span>31]</span></span>
</span></code></pre>
This means:</p>

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.</p>
</span></a>
Time Per Instruction</h2>
Since we know the instruction execution rate, we can compute the time taken by one instruction cycle.</p>
With a clock divider of 65535:</p>
1</span></span> / 1,907.38 s ≈ 0.0005243 s</span>
</span></code></pre>
That means approximately:</p>

0.524 ms (524,300 nanoseconds) per instruction cycle</li>
</ul>
</span></a>
Project Source Code</h2>
You can clone the project used in this post from the following repository:</p>
git</span></span> clone https://github.com/ImplFerris/rp2040-projects</span>
</span>cd</span></span> rp2040-projects/embassy/pio/hello-blinky/</span>
</span></code></pre>
This project contains the exact PIO program and Embassy setup used for the logic analyzer measurements shown in this post.</p>
</span></a>
Pio Program</h3>
This is the PIO assembly program used to generate the blinking signal that we will analyze with the logic analyzer.</p>
let</span> prg =</span> pio_asm!</span>(</span>
</span></span>    "</span>
</span></span></span>    set pindirs, 1
</span></span></span>    loop:
</span></span></span>        set pins, 1 [31]
</span></span></span>        nop [31]
</span></span></span>        nop [31]
</span></span></span>        nop [31]
</span></span></span>        nop [31]
</span></span></span>        nop [31]
</span></span></span>        nop [31]
</span></span></span>        nop [31]
</span></span></span>        set pins, 0 [30]
</span></span></span>        nop [31]
</span></span></span>        nop [31]
</span></span></span>        nop [31]
</span></span></span>        nop [31]
</span></span></span>        nop [31]
</span></span></span>        nop [31]
</span></span></span>        nop [31]
</span></span></span>        jmp loop
</span></span></span>    "</span></span>
</span></span></span>)</span></span>;</span>
</span></code></pre>
This program runs in an infinite loop and drives a single GPIO pin HIGH and LOW.</p>
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.</p>
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.</p>
</span></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.</p>
The external LED is connected to GPIO15 through a resistor. The logic analyzer channel is connected in parallel to the same GPIO pin.</p>
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.</p>
Make sure the logic analyzer ground and the Pico ground are connected. Without a common ground, the captured signal will be unreliable.</p>
</span></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.</p>
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.</p>
</span></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.</p>
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.</p>
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.</p>
</span></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.</p>

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.</p>
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.</p>
</span></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.</p>
While the pin is HIGH, the following instructions run:</p>


set pins, 1 [31]</code>

The instruction itself takes 1 cycle, and the delay adds 31 more cycles.

Total: 32 cycles</p>
</li>

nop [31]</code> repeated 7 times

Each nop [31]</code> takes 32 cycles.

Total: 7 x 32 = 224 cycles</p>
</li>
</ul>
So the total number of instruction cycles while the pin is HIGH is:</p>
32</span></span> + 224 = 256 cycles</span>
</span></code></pre>
With each instruction cycle taking about 0.524 ms, the total HIGH time becomes:</p>
256</span></span> x 0.524 ms ≈ 134 ms</span>
</span></code></pre>
</span></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.</p>
While the pin is LOW, the following instructions run:</p>


set pins, 0 [30]</code>

The instruction itself takes 1 cycle, and the delay adds 30 more cycles.

Total: 31 cycles</p>
</li>

nop [31]</code> repeated 7 times

Total: 7 x 32 = 224 cycles</p>
</li>

jmp loop</code>

This instruction takes 1 cycle</p>
</li>
</ul>
So the total number of instruction cycles while the pin is LOW is:</p>
31</span></span> + 224 + 1 = 256 cycles</span>
</span></code></pre>
This again gives:</p>
256</span></span> x 0.524 ms ≈ 134 ms</span>
</span></code></pre>
</span></a>
Putting It All Together</h3>
From the instruction count, we end up with:</p>

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.</p>


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.</p>
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.</p>
</span></a>
What is UART?</h2>
You might already be familiar with UART. Still, let me give a short introduction.</p>
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.</p>
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.</p>
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.</p>
Let us look at a simple UART signal to understand this.</p>

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?</p>
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.</p>
</span></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.</p>
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.</p>
</span></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.</p>
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.</p>
</span></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.</p>
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.</p>
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.</p>
</span></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.</p>
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.</p>
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.</p>
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.</p>
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.</p>
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.</p>
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.</p>

    </div>
    
        TIP</strong>
        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.</p>

    </div>
</div>
</span></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.</p>
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.</p>
Connect CH1 of the logic analyzer to GPIO16 on the Pico. Also connect the logic analyzer ground to any ground pin on the Pico.</p>
Logic Analyzer</th> Raspberry Pi Pico</th></tr></thead>

GND</td> GND</td></tr>
CH1</td> GPIO16</td></tr>
</tbody></table>
</span></a>
Code Snippet</h2>
Flash the program onto the Pico, then power up the board and connect the USB logic analyzer to the computer.</p>
#</span>[</span>embassy_executor</span>::main</span>]</span></span>
</span>async fn</span> </span>main</span></span>(</span>_spawner</span>:</span> Spawner</span>)</span></span></span></span> </span>{</span>
</span></span></span>    let</span> p =</span> embassy_rp::</span></span>init(</span>Default</span>::</span></span>default(</span></span>)</span></span></span>)</span></span>;</span>
</span></span></span>
</span></span></span>    let</span> mut</span> uart_config =</span> UartConfig::</span></span>default(</span></span>)</span></span>;</span>
</span></span></span>    //</span> This is default baud rate in the embassy-rp, i just want to explicitly show 
</span></span></span></span>    uart_config.</span>baudrate =</span> 115200</span>;</span>  
</span></span></span>
</span></span></span>    let</span> mut</span> uart_tx =</span> UartTx::</span></span>new_blocking(</span>p.</span>UART0</span>,</span> p.</span>PIN_16</span>,</span> uart_config</span>)</span></span>;</span>
</span></span></span>
</span></span></span>    loop</span> {</span>
</span></span></span></span>        uart_tx
</span></span></span></span>            .</span>blocking_write</span>(</span>"</span>Rust"</span></span>.</span>as_bytes</span>(</span></span>)</span></span></span>)</span></span>
</span></span></span></span>            .</span>expect</span>(</span>"</span>unable to write into uart"</span></span></span>)</span></span>;</span>
</span></span></span></span>        Timer::</span></span>after_secs(</span>1</span></span>)</span></span>.</span>await;</span>
</span></span></span></span>    </span>}</span></span>
</span></span></span></span>}</span></span></span>
</span></code></pre>
</span></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.</p>
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.</p>
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.</p>

</span></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.</p>
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.</p>

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.</p>
</span></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.</p>
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.</p>

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.</p>
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.</p>

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.</p>

By default, the decoded data format is shown in hexadecimal. Since we are transmitting ASCII text, change the data format to ASCII.</p>
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.</p>
Once this is done, PulseView will decode the captured UART signal and display the transmitted data.</p>
</span></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.</p>

PulseView also highlights the start bit with an “S” label (shown in yellow) and the stop bit with a “T” label.</p>


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.</p>
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.</p>
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.</p>

    </div>
    
        INFO</strong>
        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.</p>

    </div>
</div>
</span></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.</p>
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.</p>
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.</p>
</span></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).</p>

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.</p>
</span></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).</p>
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.</p>
</span></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.</p>
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.</p>
</span></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.</p>
There are two commonly mentioned software options when working with USB logic analyzers. Which one makes sense depends on the hardware you are using.</p>
</span></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.</p>
On Debian or Ubuntu-based systems, you can install PulseView using the package manager:</p>
sudo</span></span> apt install pulseview sigrok</span>
</span></code></pre>
Official documentation for sigrok and PulseView is available here:
https://sigrok.org/wiki/Main_Page</a></p>
You can also refer to the PulseView user manual for more details:
https://sigrok.org/doc/pulseview/unstable/manual.html</a></p>
I will be using PulseView throughout this blog post.</p>
</span></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.</p>
You can download the Linux AppImage from the Saleae website:
https://www.saleae.com/downloads/</a></p>
Make it executable and run:</p>
chmod</span></span> +x Logic-*</span>.AppImage</span>
</span>./Logic-*.AppImage</span></span>
</span></code></pre>
</span></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.</p>
I will be using a Raspberry Pi Pico here, but any other board will work.</p>
We will flash a small program that toggles a GPIO pin between high and low states with a delay of 500 milliseconds.</p>
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.</p>
</span></a>
Code snippet</h3>
let</span> p =</span> embassy_rp::</span></span>init(</span>Default</span>::</span></span>default(</span></span>)</span></span></span>)</span></span>;</span>
</span>let</span> mut</span> pin =</span> Output::</span></span>new(</span>p.</span>PIN_15</span>,</span> Level::</span></span>Low</span>)</span></span>;</span>
</span>
</span>loop</span> {</span>
</span></span>    pin.</span>set_high</span>(</span></span>)</span></span>;</span>
</span></span>    Timer::</span></span>after_millis(</span>500</span></span>)</span></span>.</span>await;</span>
</span></span>
</span></span>    pin.</span>set_low</span>(</span></span>)</span></span>;</span>
</span></span>    Timer::</span></span>after_millis(</span>500</span></span>)</span></span>.</span>await;</span>
</span></span></span>}</span></span>
</span></code></pre>

    </div>
    
        TIP</strong>
        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.</p>

    </div>
</div>
</span></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.</p>
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.</p>
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.</p>
</span></a>
Opening PulseView and Detecting the Logic Analyzer</h2>
Now lets open PulseView and make sure the logic analyzer is detected correctly.</p>
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.</p>

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.</p>
</span></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”.</p>
To understand these settings, it helps to know what a sample actually is.</p>
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.</p>

</span></a>
Number of Samples</h3>
The number of samples tells the logic analyzer how many samples to record in total before stopping.</p>
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.</p>
</span></a>
Sample Rate</h3>
The sample rate tells the logic analyzer how many samples to take every second.</p>
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.</p>
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.</p>

    </div>
    
        TIP</strong>
        From the Manual:</strong> 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.</p>

    </div>
</div>
</span></a>
How They Work Together</h3>
These two settings answer two different questions:</p>

“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.</p>
PulseView shows this relationship using the capture duration:</p>
capture</span></span> duration = number of samples / sample rate</span>
</span></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.</p>
capture</span></span> duration = 100,000 / 20,000 = 5 seconds</span>
</span></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.</p>
</span></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.</p>
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.</p>

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.</p>
Since the total capture duration is 5 seconds, this results in 5 HIGH periods and 5 LOW periods across the entire waveform.</p>
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.</p>
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.</p>
</span></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.</p>


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.</p>
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.</p>
</span></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.</p>
</span></a>
Understanding Fixed-Point Notation</h2>
This idea is explained well in the fixed crate</a> documentation, but let me give a quick overview.</p>
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.</p>
Fixed-point numbers maintain uniform spacing between consecutive values throughout their range. The step size formula is 1/2^f</code>.</p>
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.</p>
</span></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.</p>
For instance, if we allocate the last 4 bits for the fraction, we have 12 bits left for the integer.</p>
</span></a>
Example: 4 Fractional bits</h3>
Here’s how the bits map to their values:</p>
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.</p>
</span></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:</p>
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.</p>
</span></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.</p>
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*).</p>
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.</p>
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:</p>
use</span> fixed::</span></span>types::</span></span>U12F4</span>;</span>
</span></code></pre>
</span></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.</p>
To make things easier to understand, the example prints the same value in several different forms.</p>
First, it prints the fixed-point value itself. The :.4 formatting is only for display and shows four digits after the decimal point.</p>
Next, it uses helper methods from the fixed crate to print the fractional part and the integer part separately.</p>
Then it prints the binary representation in two different ways.</p>
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.</p>
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.</p>
use</span> fixed::</span></span>{</span>FixedU16,</span> types::</span></span>extra</span>}</span></span>;</span>
</span>use</span> fixed::</span></span>types;</span>
</span>
</span>fn</span> </span>main</span></span>(</span></span>)</span></span></span></span> </span>{</span>
</span></span></span>    //</span> let f_u16: FixedU16<extra::U4> = FixedU16::from_num(5.75); // you can use this approach
</span></span></span></span>    let</span> f_u16:</span> FixedU16<</span>extra::</span></span>U4></span></span> =</span> types::</span></span>U12F4</span>::</span></span>from_num(</span>5.</span>75</span></span>)</span></span>;</span> //</span> or this approach
</span></span></span></span>    assert_eq!</span>(</span>f_u16,</span> 5.</span>75</span></span>)</span></span>;</span>
</span></span></span>
</span></span></span>    println!</span>(</span></span>"</span>Fixed Point: {:.4}</span>"</span></span></span>,</span> f_u16)</span></span>;</span>
</span></span></span>    println!</span>(</span></span>"</span>Fraction: {}</span>"</span></span></span>,</span> f_u16.</span>frac</span>(</span></span>)</span></span>)</span></span>;</span>
</span></span></span>    println!</span>(</span></span>"</span>Integer: {}</span>"</span></span></span>,</span> f_u16.</span>int</span>(</span></span>)</span></span>)</span></span>;</span>
</span></span></span>    println!</span>(</span></span>"</span>Binary with Fraction repr: {:b}</span>"</span></span></span>,</span> f_u16)</span></span>;</span>
</span></span></span>
</span></span></span>    //</span> println!("Actual binary: {:016b}", f_u16.to_bits());
</span></span></span></span>    let</span> bits =</span> format!</span>(</span></span>"</span>{:016b}"</span></span></span>,</span> f_u16.</span>to_bits</span>(</span></span>)</span></span>)</span></span>;</span>
</span></span></span>    let</span> formatted =</span> format!</span>(</span></span>
</span></span></span></span>        "</span>{}</span>_{}</span>"</span></span></span>,</span>
</span></span></span></span>        &</span>bits[</span>..</span>12</span>]</span></span>,</span>
</span></span></span></span>        &</span>bits[</span>12</span>..</span>]</span></span>,</span>
</span></span></span></span>    )</span></span>;</span>
</span></span></span>    println!</span>(</span></span>"</span>Actual binary: {}</span>"</span></span></span>,</span> formatted)</span></span>;</span>
</span></span></span>
</span></span></span>    println!</span>(</span></span>"</span>F32: {}</span>"</span></span></span>,</span> f_u16.</span>to_num::</span></span><</span>f32</span>></span></span>(</span></span>)</span></span>)</span></span>;</span>
</span></span></span></span>}</span></span></span>
</span></code></pre>
If you run this code, you will see output like this:</p>
Fixed</span></span> Point: 5.7500</span>
</span>Frac:</span></span> 0.75</span>
</span>Int:</span></span> 5</span>
</span>Binary</span></span> with Fraction repr: 101.11</span>
</span>Actual</span></span> binary: 000000000101_1100</span>
</span>F32:</span></span> 5.75</span>
</span></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.</p>
To understand what this value really represents, let’s look at the binary representation.</p>
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.</p>
The fractional part is where the confusion usually comes from. Each fractional bit represents a negative power of two.</p>
fraction</span></span> = 1 × 0.5 + 1 × 0.25 + 0 × 0.125 + 0 × 0.0625</span>
</span></code></pre>
That adds up to 0.75.</p>
</span></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.</p>
use</span> fixed::</span></span>{</span>FixedU16,</span> types::</span></span>extra</span>}</span></span>;</span>
</span>use</span> fixed::</span></span>types;</span>
</span>
</span>fn</span> </span>main</span></span>(</span></span>)</span></span></span></span> </span>{</span>
</span></span></span>    let</span> f_u16:</span> FixedU16<</span>extra::</span></span>U4></span></span> =</span> FixedU16::</span></span>from_num(</span>20.</span>3</span></span>)</span></span>;</span>
</span></span></span>    assert_eq!</span>(</span>f_u16,</span> 20.</span>3125</span></span>)</span></span>;</span>
</span></span></span>
</span></span></span>    println!</span>(</span></span>"</span>Fixed Point: {:.4}</span>"</span></span></span>,</span> f_u16)</span></span>;</span>
</span></span></span>    println!</span>(</span></span>"</span>Fraction: {}</span>"</span></span></span>,</span> f_u16.</span>frac</span>(</span></span>)</span></span>)</span></span>;</span>
</span></span></span>    println!</span>(</span></span>"</span>Integer: {}</span>"</span></span></span>,</span> f_u16.</span>int</span>(</span></span>)</span></span>)</span></span>;</span>
</span></span></span>    println!</span>(</span></span>"</span>Binary with Fraction repr: {:b}</span>"</span></span></span>,</span> f_u16)</span></span>;</span>
</span></span></span>
</span></span></span>    //</span> println!("Actual binary: {:016b}", f_u16.to_bits());
</span></span></span></span>    let</span> bits =</span> format!</span>(</span></span>"</span>{:016b}"</span></span></span>,</span> f_u16.</span>to_bits</span>(</span></span>)</span></span>)</span></span>;</span>
</span></span></span>    let</span> formatted =</span> format!</span>(</span></span>
</span></span></span></span>        "</span>{}</span>_{}</span>"</span></span></span>,</span>
</span></span></span></span>        &</span>bits[</span>..</span>12</span>]</span></span>,</span>
</span></span></span></span>        &</span>bits[</span>12</span>..</span>]</span></span>,</span>
</span></span></span></span>    )</span></span>;</span>
</span></span></span>    println!</span>(</span></span>"</span>Actual binary: {}</span>"</span></span></span>,</span> formatted)</span></span>;</span>
</span></span></span>
</span></span></span>    println!</span>(</span></span>"</span>F32: {}</span>"</span></span></span>,</span> f_u16.</span>to_num::</span></span><</span>f32</span>></span></span>(</span></span>)</span></span>)</span></span>;</span>
</span></span></span></span>}</span></span></span>
</span></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:</p>
Fixed</span></span> Point: 20.3125</span>
</span>Fraction:</span></span> 0.3</span>
</span>Integer:</span></span> 20</span>
</span>Binary</span></span> with Fraction repr: 10100.0101</span>
</span>Actual</span></span> binary: 000000010100_0101</span>
</span>F32:</span></span> 20.3125</span>
</span></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></p>
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></p>
In the binary, it is represented like this:</p>
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:</p>
fraction</span></span> = 0 × 0.5 + 1 × 0.25 + 0 × 0.125 + 1 × 0.0625 = 0.3125</span>
</span></code></pre>
</span></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.</p>
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.</p>
The following code snippet is from the rp-pac</a> crate and shows how the divider register is defined.</p>
#</span>[</span>doc</span> =</span> "</span>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."</span></span>]</span></span>
</span>#</span>[</span>repr</span>(</span></span></span>transparent</span></span>)</span></span></span>]</span></span>
</span>#</span>[</span>derive</span>(</span></span></span>Copy,</span> Clone,</span> Eq,</span> PartialEq</span></span>)</span></span></span>]</span></span>
</span>pub</span> struct</span> </span>ChDiv</span></span>(</span>pub u32</span></span>)</span></span>;</span>
</span>impl</span> </span>ChDiv</span> </span>{</span>
</span></span></span>    #</span>[</span>inline</span>(</span></span></span>always</span></span>)</span></span></span>]</span></span>
</span></span></span>    pub</span> const</span> fn</span> </span>frac</span></span>(</span>&</span>self</span></span>)</span></span></span></span> -></span> u8</span></span> </span>{</span>
</span></span></span></span></span>        let</span> val =</span> (</span>self</span>.</span>0</span> ></span>></span> 0</span>usize</span></span>)</span></span> &</span> 0x0f</span>;</span>
</span></span></span></span></span>        val as</span> u8</span>
</span></span></span></span></span>    </span>}</span></span></span>
</span></span></span>
</span></span></span>    ...</span>
</span></span></span>
</span></span></span>    #</span>[</span>inline</span>(</span></span></span>always</span></span>)</span></span></span>]</span></span>
</span></span></span>    pub</span> const</span> fn</span> </span>int</span></span>(</span>&</span>self</span></span>)</span></span></span></span> -></span> u8</span></span> </span>{</span>
</span></span></span></span></span>        let</span> val =</span> (</span>self</span>.</span>0</span> ></span>></span> 4</span>usize</span></span>)</span></span> &</span> 0xff</span>;</span>
</span></span></span></span></span>        val as</span> u8</span>
</span></span></span></span></span>    </span>}</span></span></span>
</span></span></span>
</span></span></span>    ...</span>
</span></span></span></span>}</span></span></span>
</span></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.</p>
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.</p>
if</span> config.</span>divider ></span> FixedU16::</span></span><</span>fixed::</span></span>types::</span></span>extra::</span></span>U4></span></span>::</span></span>from_bits(</span>0xFFF</span></span>)</span></span> {</span>
</span></span>    panic!</span>(</span>"</span>Requested divider is too large"</span></span></span>)</span></span>;</span>
</span></span></span>}</span></span>
</span>
</span>p.</span>div</span>(</span></span>)</span></span>.</span>write_value</span>(</span>ChDiv(</span>config.</span>divider.</span>to_bits</span>(</span></span>)</span></span> as</span> u32</span></span>)</span></span></span>)</span></span>;</span>
</span></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.</p>
</span></a>
Table of Contents</h2>

</span></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.</p>
</span></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.</p>
The remaining sections focus on resources for embedded programming beginners.</p>
</span></a>
Prerequisites</h2>
Before learning Embedded Rust, make sure you are comfortable with these basics:</p>
</span></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.</p>
</span></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.</p>

</span></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.</p>
</span></a>
What are Microcontrollers and Development Boards?</h3>
A microcontroller</strong> 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.</p>
A development board</strong> (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.</p>
</span></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.</p>

    </div>
    
        TIP</strong>
        My recommendation: Get an ESP32 development board.</p>

    </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.</p>

Look for these boards - they all use the original ESP32 chip:</strong></p>


“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.</p>
</li>

“ESP32 DevKit C”</p>
</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.</p>
Important:</strong> ESP32 comes in different variants (original ESP32, ESP32-S2, ESP32-S3, ESP32-C3, ESP32-C6, etc.). I’m recommending the original ESP32</strong> (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.</p>
Alternative option: Raspberry Pi Pico 2</strong></p>
If you can’t find an ESP32 board where you live, the Raspberry Pi Pico 2</strong> (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.</p>

</span></a>
But, Why ESP32 DevKit V1?</h3>
Let me share my journey learning Embedded Rust as a beginner, which will help explain my recommendation.</p>
My First Board: micro:bit v2</strong></p>
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.</p>

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.</p>
My Second Board: Raspberry Pi Pico 2</strong></p>
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.</p>
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.</p>

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.</p>
My Third Board: ESP32 DevKit V1</strong></p>
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:</p>

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.</p>
The Bottom Line</strong></p>
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.</p>
</span></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.</p>
Wow, I didn’t expect to write this much about hardware itself!</p>

</span></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.</p>
</span></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.</p>
</span></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.</p>
</span></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”.</p>
https://www.youtube.com/@therustybits/videos</a></p>
</span></a>
Learning Path for ESP32</h2>
</span></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.</p>
</span></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.</p>
</span></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:</p>
https://github.com/esp-rs/esp-hal/tree/main/examples</a></p>
</span></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.</p>
</span></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.</p>
</span></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:</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>
</span></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.</p>
</span></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.</p>
You can read it online here:

https://docs.rust-embedded.org/discovery-mb2/index.html</a></p>
</span></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.</p>
You can read it online here:

https://mb2.implrust.com/</a></p>

</span></a>
Other Resources</h2>
Here are some other useful resources related to Embedded Rust.</p>
</span></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.</p>
https://github.com/rust-embedded/awesome-embedded-rust</a></p>
</span></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.</p>
https://os.phil-opp.com/</a></p>
</span></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.</p>
https://red.implrust.com/</a></p>
</span></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.</p>

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.</p>


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 :)</p>
</span></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.</p>
Here’s the basic syntax:</p>
impl</span></span><</span>T></span></span></span> MyTrait for</span></span> T</span> 
</span></span></span>where</span> 
</span></span>    T:</span> SomeCondition 
</span></span></span>{</span>
</span></span></span>    //</span> implementation
</span></span></span></span></span>}</span></span></span>
</span></code></pre>
You can read it as “For any type T that meets SomeCondition, implement MyTrait for T”</p>
</span></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:</p>
use</span> core::</span></span>fmt::</span></span>Debug;</span>
</span>
</span>trait</span> Loggable</span> {</span>
</span></span></span>    fn</span> </span>log</span></span>(</span>&</span>self</span></span>)</span></span></span></span>;</span>
</span></span></span></span>}</span></span></span>
</span>
</span>//</span> Blanket implementation
</span></span>impl</span></span><</span>T:</span> Debug></span></span></span> Loggable for</span></span> T</span> </span>{</span>
</span></span></span>    fn</span> </span>log</span></span>(</span>&</span>self</span></span>)</span></span></span></span> </span>{</span>
</span></span></span></span></span>        println!</span>(</span></span>"</span>[log] {:?}</span>"</span></span></span>,</span> self</span>)</span></span>;</span>
</span></span></span></span></span>    </span>}</span></span></span>
</span></span></span></span>}</span></span></span>
</span>
</span>#</span>[</span>allow</span>(</span></span></span>dead_code</span></span>)</span></span></span>]</span></span>
</span>#</span>[</span>derive</span>(</span></span></span>Debug</span></span>)</span></span></span>]</span></span>
</span>struct</span> </span>Cat</span> </span>{</span>
</span></span></span>    name</span>:</span> String,
</span></span></span></span>}</span></span></span>
</span>
</span>fn</span> </span>main</span></span>(</span></span>)</span></span></span></span> </span>{</span>
</span></span></span>    let</span> numbers =</span> vec!</span>[</span>1</span>,</span> 2</span>,</span> 3</span>]</span></span>;</span>
</span></span></span>    numbers.</span>log</span>(</span></span>)</span></span>;</span>
</span></span></span>
</span></span></span>    let</span> s =</span> String</span>::</span></span>from(</span>"</span>Blanket"</span></span></span>)</span></span>;</span>
</span></span></span>    s.</span>log</span>(</span></span>)</span></span>;</span>
</span></span></span>
</span></span></span>    let</span> c =</span> Cat {</span> name:</span> "</span>Astra"</span></span>.</span>to_string</span>(</span></span>)</span></span> </span>}</span></span>;</span>
</span></span></span>    c.</span>log</span>(</span></span>)</span></span>;</span>
</span></span></span></span>}</span></span></span>
</span></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.</p>
</span></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:</p>
impl</span></span><</span>T:</span> fmt::</span></span>Display +</span> ?</span></span></span>Sized</span>> ToString</span> for</span> T</span> </span>{</span>
</span></span></span>    #</span>[</span>inline</span>]</span></span>
</span></span></span>    fn</span> </span>to_string</span></span>(</span>&</span>self</span></span>)</span></span></span></span> -></span> String</span> </span>{</span>
</span></span></span></span></span>        <</span>Self</span> as</span> SpecToString></span>::</span></span>spec_to_string(</span>self</span></span>)</span></span>
</span></span></span></span></span>    </span>}</span></span></span>
</span></span></span></span>}</span></span></span>
</span></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>.</p>
</span></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:</p>
mod</span> hal</span> {</span>
</span></span></span>    pub</span> trait</span> I2c</span> {</span>
</span></span></span></span></span>        fn</span> </span>write</span></span>(</span>&</span>mut</span> self</span>, data</span>:</span> &</span>[u8</span>]</span>)</span></span></span></span>;</span>
</span></span></span></span></span>    </span>}</span></span></span>
</span></span></span>
</span></span></span>    impl</span></span><</span>T:</span> I2c></span></span></span> I2c for</span></span> &</span>mut</span> T</span> </span>{</span> //</span> Blanket Implementation
</span></span></span></span></span></span>        #</span>[</span>inline</span>]</span></span>
</span></span></span></span></span>        fn</span> </span>write</span></span>(</span>&</span>mut</span> self</span>, data</span>:</span> &</span>[u8</span>]</span>)</span></span></span></span> </span>{</span>
</span></span></span></span></span></span></span>            T::</span></span>write(</span>self</span>,</span> data</span>)</span></span>;</span>
</span></span></span></span></span></span></span>        </span>}</span></span></span>
</span></span></span></span></span>    </span>}</span></span></span>
</span></span></span></span>}</span></span></span>
</span>
</span>use</span> hal::</span></span>I2c;</span>
</span>
</span>pub</span> struct</span> </span>I2cBus</span> </span>{</span></span>}</span></span></span>
</span>
</span>impl</span> </span>hal::</span></span>I2c for</span></span> I2cBus</span> </span>{</span>
</span></span></span>    fn</span> </span>write</span></span>(</span>&</span>mut</span> self</span>, data</span>:</span> &</span>[u8</span>]</span>)</span></span></span></span> </span>{</span>
</span></span></span></span></span>        dbg!</span>(</span>data</span>)</span></span>;</span>
</span></span></span></span></span>    </span>}</span></span></span>
</span></span></span></span>}</span></span></span>
</span>
</span>fn</span> </span>write_to_any_i2c</span></span><</span>T:</span> I2c></span></span>(</span>mut</span> i</span>:</span> T</span>)</span></span></span></span> </span>{</span>  //</span> assume this is a driver 
</span></span></span></span>    i.</span>write</span>(</span>b</span>"</span>Rust"</span></span></span>)</span></span>;</span>
</span></span></span></span>}</span></span></span>
</span>
</span>fn</span> </span>main</span></span>(</span></span>)</span></span></span></span> </span>{</span>
</span></span></span>    let</span> bus1 =</span> I2cBus {</span></span>}</span></span>;</span>
</span></span></span>    write_to_any_i2c</span>(</span>bus1</span>)</span></span>;</span> //</span> Takes ownership
</span></span></span></span>
</span></span></span>    let</span> mut</span> bus2 =</span> I2cBus {</span></span>}</span></span>;</span>
</span></span></span>    write_to_any_i2c</span>(</span>&</span>mut</span> bus2</span>)</span></span>;</span> //</span> Takes reference
</span></span></span></span></span>}</span></span></span>
</span></code></pre>
</span></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.</p>
Let’s comment out the blanket implementation and see what happens:</p>
mod</span> hal</span> {</span>
</span></span></span>    pub</span> trait</span> I2c</span> {</span>
</span></span></span></span></span>        fn</span> </span>write</span></span>(</span>&</span>mut</span> self</span>, data</span>:</span> &</span>[u8</span>]</span>)</span></span></span></span>;</span>
</span></span></span></span></span>    </span>}</span></span></span>
</span></span></span>
</span></span></span>    //</span> impl<T: I2c> I2c for &mut T { // Blanket Implementation
</span></span></span></span>    //</span>     #[inline]
</span></span></span></span>    //</span>     fn write(&mut self, data: &[u8]) {
</span></span></span></span>    //</span>         T::write(self, data);
</span></span></span></span>    //</span>     }
</span></span></span></span>    //</span> }
</span></span></span></span></span>}</span></span></span>
</span>
</span>use</span> hal::</span></span>I2c;</span>
</span>
</span>pub</span> struct</span> </span>I2cBus</span> </span>{</span></span>}</span></span></span>
</span>
</span>impl</span> </span>hal::</span></span>I2c for</span></span> I2cBus</span> </span>{</span>
</span></span></span>    fn</span> </span>write</span></span>(</span>&</span>mut</span> self</span>, data</span>:</span> &</span>[u8</span>]</span>)</span></span></span></span> </span>{</span>
</span></span></span></span></span>        dbg!</span>(</span>data</span>)</span></span>;</span>
</span></span></span></span></span>    </span>}</span></span></span>
</span></span></span></span>}</span></span></span>
</span>
</span>//</span> Function that takes ownership
</span></span>fn</span> </span>write_to_any_i2c</span></span><</span>T:</span> I2c></span></span>(</span>mut</span> i</span>:</span> T</span>)</span></span></span></span> </span>{</span>
</span></span></span>    i.</span>write</span>(</span>b</span>"</span>Rust"</span></span></span>)</span></span>;</span>
</span></span></span></span>}</span></span></span>
</span>
</span>//</span> Function that takes a mutable reference
</span></span>fn</span> </span>write_to_any_i2c_ref</span></span><</span>T:</span> I2c></span></span>(</span>i</span>:</span> &</span>mut</span> T</span>)</span></span></span></span> </span>{</span>
</span></span></span>    i.</span>write</span>(</span>b</span>"</span>Rust"</span></span></span>)</span></span>;</span>
</span></span></span></span>}</span></span></span>
</span>
</span>
</span>fn</span> </span>main</span></span>(</span></span>)</span></span></span></span> </span>{</span>
</span></span></span>    let</span> bus1 =</span> I2cBus {</span></span>}</span></span>;</span>
</span></span></span>    write_to_any_i2c</span>(</span>bus1</span>)</span></span>;</span> //</span> Takes ownership
</span></span></span></span>
</span></span></span>    //</span> Compilation error: error[E0277]: the trait bound `&mut I2cBus: I2c` is not satisfied
</span></span></span></span>    //</span> let mut bus2 = I2cBus {};
</span></span></span></span>    //</span> write_to_any_i2c(&mut bus2); // Takes reference
</span></span></span></span>    
</span></span></span>    let</span> mut</span> bus2 =</span> I2cBus {</span></span>}</span></span>;</span>
</span></span></span>    write_to_any_i2c_ref</span>(</span>&</span>mut</span> bus2</span>)</span></span>;</span> //</span> Takes reference
</span></span></span></span></span>}</span></span></span>
</span></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.</p>
</span></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.</p>
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:</p>
use</span> core::</span></span>fmt::</span></span>Debug;</span>
</span>
</span>trait</span> Loggable</span> {</span>
</span></span></span>    fn</span> </span>log</span></span>(</span>&</span>self</span></span>)</span></span></span></span>;</span>
</span></span></span></span>}</span></span></span>
</span>
</span>//</span> Blanket implementation
</span></span>impl</span></span><</span>T:</span> Debug></span></span></span> Loggable for</span></span> T</span> </span>{</span>
</span></span></span>    fn</span> </span>log</span></span>(</span>&</span>self</span></span>)</span></span></span></span> </span>{</span>
</span></span></span></span></span>        println!</span>(</span></span>"</span>[log] {:?}</span>"</span></span></span>,</span> self</span>)</span></span>;</span>
</span></span></span></span></span>    </span>}</span></span></span>
</span></span></span></span>}</span></span></span>
</span>
</span>#</span>[</span>allow</span>(</span></span></span>dead_code</span></span>)</span></span></span>]</span></span>
</span>#</span>[</span>derive</span>(</span></span></span>Debug</span></span>)</span></span></span>]</span></span>
</span>struct</span> </span>Cat</span> </span>{</span>
</span></span></span>    name</span>:</span> String,
</span></span></span></span>}</span></span></span>
</span>
</span>#</span>[</span>allow</span>(</span></span></span>dead_code</span></span>)</span></span></span>]</span></span>
</span>#</span>[</span>derive</span>(</span></span></span>Debug</span></span>)</span></span></span>]</span></span>
</span>struct</span> </span>Human</span> </span>{</span>
</span></span></span>    first_name</span>:</span> String,
</span></span></span>    last_name</span>:</span> String,
</span></span></span></span>}</span></span></span>
</span>
</span>impl</span> </span>Loggable for</span></span> Human</span></span>{</span>
</span></span></span>    fn</span> </span>log</span></span>(</span>&</span>self</span></span>)</span></span></span></span></span>{</span>
</span></span></span></span></span>        println!</span>(</span></span>"</span>[log] This is Human {}</span>"</span></span></span>,</span>  self</span>.</span>first_name)</span></span>
</span></span></span></span></span>    </span>}</span></span></span>
</span></span></span></span>}</span></span></span>
</span>
</span>fn</span> </span>main</span></span>(</span></span>)</span></span></span></span> </span>{</span>
</span></span></span>    let</span> numbers =</span> vec!</span>[</span>1</span>,</span> 2</span>,</span> 3</span>]</span></span>;</span>
</span></span></span>    numbers.</span>log</span>(</span></span>)</span></span>;</span>
</span></span></span>
</span></span></span>    let</span> s =</span> String</span>::</span></span>from(</span>"</span>Blanket"</span></span></span>)</span></span>;</span>
</span></span></span>    s.</span>log</span>(</span></span>)</span></span>;</span>
</span></span></span>
</span></span></span>    let</span> c =</span> Cat {</span>
</span></span></span></span>        name:</span> "</span>Astra"</span></span>.</span>to_string</span>(</span></span>)</span></span>,</span>
</span></span></span></span>    </span>}</span></span>;</span>
</span></span></span>    c.</span>log</span>(</span></span>)</span></span>;</span>
</span></span></span>
</span></span></span>    let</span> h =</span> Human {</span>
</span></span></span></span>        first_name:</span> "</span>Astra"</span></span>.</span>to_string</span>(</span></span>)</span></span>,</span>
</span></span></span></span>        last_name:</span> "</span>Kernel"</span></span>.</span>to_string</span>(</span></span>)</span></span>,</span>
</span></span></span></span>    </span>}</span></span>;</span>
</span></span></span>    h.</span>log</span>(</span></span>)</span></span>;</span>
</span></span></span></span>}</span></span></span>
</span></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.</p>
This is why you need to carefully consider whether a blanket implementation is the right choice for your use case.</p>


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.</p>

Official doc explanation</a>: The non_exhaustive attribute indicates that a type or variant may have more fields or variants added in the future.</p>
</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”</p>
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.</p>
However, these restrictions only apply to downstream crates that depend on your library. Within the defining crate itself, these rules don’t apply.</p>
</span></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.</p>
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.</p>
</span></a>
Creating the Menu Library</h3>
First, create a new library:</p>
cargo</span></span> new --</span>lib</span> menu</span>
</span>cd</span></span> menu</span>
</span></code></pre>
In src/lib.rs, define a simple menu enum:</p>
//</span> menu/src/lib.rs
</span></span>pub</span> enum</span> Menu</span> {</span>
</span></span></span>    Pizza,</span>
</span></span></span>    Burger,</span>
</span></span></span>    Tacos,</span>
</span></span></span></span>}</span></span></span>
</span>
</span>impl</span> </span>Menu</span> </span>{</span>
</span></span></span>    pub</span> fn</span> </span>price</span></span>(</span>&</span>self</span></span>)</span></span></span></span> -></span> f32</span></span> </span>{</span>
</span></span></span></span></span>        match</span> self</span> {</span>
</span></span></span></span></span></span>            Menu::</span></span>Pizza =></span> 100.</span>0</span>,</span>
</span></span></span></span></span></span>            Menu::</span></span>Burger =></span> 180.</span>0</span>,</span>
</span></span></span></span></span></span>            Menu::</span></span>Tacos =></span> 60.</span>0</span>,</span>
</span></span></span></span></span></span>        </span>}</span></span>
</span></span></span></span></span>    </span>}</span></span></span>
</span></span></span></span>}</span></span></span>
</span></code></pre>
</span></a>
Creating an App That Uses the Library</h3>
Now create an app that uses your menu library:</p>
cd</span></span> ..</span>
</span>cargo</span></span> new restaurant_app</span>
</span>cd</span></span> restaurant_app</span>
</span></code></pre>
Add your local menu library to Cargo.toml:</p>
#</span> restaurant_app/Cargo.toml</span>
</span>[</span>dependencies</span></span>]</span>
</span>menu</span></span> =</span> {</span> path</span></span> =</span> "</span>../menu"</span></span> }</span>
</span></code></pre>
Use the library in the app:</p>
//</span> restaurant_app/src/main.rs
</span></span>use</span> menu::</span></span>Menu;</span>
</span>
</span>fn</span> </span>main</span></span>(</span></span>)</span></span></span></span> </span>{</span>
</span></span></span>    let</span> order =</span> Menu::</span></span>Pizza;</span>
</span></span></span>    
</span></span></span>    match</span> order {</span>
</span></span></span></span>        Menu::</span></span>Pizza =></span> println!</span>(</span></span>"</span>You ordered pizza for ${}</span>"</span></span></span>,</span> order.</span>price</span>(</span></span>)</span></span>)</span></span>,</span>
</span></span></span></span>        Menu::</span></span>Burger =></span> println!</span>(</span></span>"</span>You ordered a burger for ${}</span>"</span></span></span>,</span> order.</span>price</span>(</span></span>)</span></span>)</span></span>,</span>
</span></span></span></span>        Menu::</span></span>Tacos =></span> println!</span>(</span></span>"</span>You ordered tacos for ${}</span>"</span></span></span>,</span> order.</span>price</span>(</span></span>)</span></span>)</span></span>,</span>
</span></span></span></span>    </span>}</span></span>
</span></span></span></span>}</span></span></span>
</span></code></pre>
When you run the app, you should get output like “You ordered pizza for $12.99”.  Everything works great!</p>
</span></a>
The Breaking Change Problem</h3>
A month later, you want to add burritos to your menu. Update the library:</p>
//</span> menu/src/lib.rs
</span></span>pub</span> enum</span> Menu</span> {</span>
</span></span></span>    Pizza,</span>
</span></span></span>    Burger,</span>
</span></span></span>    Tacos,</span>
</span></span></span>    Burrito,</span>  //</span> New item!
</span></span></span></span></span>}</span></span></span>
</span>
</span>impl</span> </span>Menu</span> </span>{</span>
</span></span></span>    pub</span> fn</span> </span>price</span></span>(</span>&</span>self</span></span>)</span></span></span></span> -></span> f32</span></span> </span>{</span>
</span></span></span></span></span>        match</span> self</span> {</span>
</span></span></span></span></span></span>            Menu::</span></span>Pizza =></span> 100.</span>0</span>,</span>
</span></span></span></span></span></span>            Menu::</span></span>Burger =></span> 180.</span>0</span>,</span>
</span></span></span></span></span></span>            Menu::</span></span>Tacos =></span> 60.</span>0</span>,</span>
</span></span></span></span></span></span>            Menu::</span></span>Burrito =></span> 150.</span>0</span>,</span>  //</span> Add price for burrito
</span></span></span></span></span></span></span>        </span>}</span></span>
</span></span></span></span></span>    </span>}</span></span></span>
</span></span></span></span>}</span></span></span>
</span></code></pre>
Now try to run the restaurant app, you will get the following compile error:</p>
error[E0004]:</span></span> non-exhaustive patterns: `</span>Menu::Burrito</span></span>`</span></span> not covered</span>
</span> --</span></span>></span> src/main.rs:6:11</span>
</span>  </span>|</span>
</span>6</span></span> |</span>     match</span></span> order {</span>
</span></span></span>  |           ^^^^^ pattern `</span>Menu::Burrito</span></span>`</span></span> not covered
</span></span></span></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.</p>
</span></a>
The Solution: Using #[non_exhaustive]</h3>
Go back to your menu library and add the #[non_exhaustive] attribute:</p>
//</span> menu/src/lib.rs
</span></span>#</span>[</span>non_exhaustive</span>]</span></span>
</span>pub</span> enum</span> Menu</span> {</span>
</span></span></span>    Pizza,</span>
</span></span></span>    Burger,</span>
</span></span></span>    Tacos,</span>
</span></span></span></span>}</span></span></span>
</span>
</span>impl</span> </span>Menu</span> </span>{</span>
</span></span></span>    pub</span> fn</span> </span>price</span></span>(</span>&</span>self</span></span>)</span></span></span></span> -></span> f32</span></span> </span>{</span>
</span></span></span></span></span>        match</span> self</span> {</span>
</span></span></span></span></span></span>            Menu::</span></span>Pizza =></span> 100.</span>0</span>,</span>
</span></span></span></span></span></span>            Menu::</span></span>Burger =></span> 180.</span>0</span>,</span>
</span></span></span></span></span></span>            Menu::</span></span>Tacos =></span> 60.</span>0</span>,</span>
</span></span></span></span></span></span>        </span>}</span></span>
</span></span></span></span></span>    </span>}</span></span></span>
</span></span></span></span>}</span></span></span>
</span></code></pre>

NOTE: adding non_exhaustive attribute itself is a breaking change because without the wildcard pattern, it will give compilation error.</p>
</blockquote>
Now you have to update the restaurant app to handle the non-exhaustive enum:</p>
//</span> restaurant_app/src/main.rs
</span></span>use</span> menu::</span></span>Menu;</span>
</span>
</span>fn</span> </span>main</span></span>(</span></span>)</span></span></span></span> </span>{</span>
</span></span></span>    let</span> order =</span> Menu::</span></span>Pizza;</span>
</span></span></span>    
</span></span></span>    match</span> order {</span>
</span></span></span></span>        Menu::</span></span>Pizza =></span> println!</span>(</span></span>"</span>You ordered pizza for ${}</span>"</span></span></span>,</span> order.</span>price</span>(</span></span>)</span></span>)</span></span>,</span>
</span></span></span></span>        Menu::</span></span>Burger =></span> println!</span>(</span></span>"</span>You ordered a burger for ${}</span>"</span></span></span>,</span> order.</span>price</span>(</span></span>)</span></span>)</span></span>,</span>
</span></span></span></span>        Menu::</span></span>Tacos =></span> println!</span>(</span></span>"</span>You ordered tacos for ${}</span>"</span></span></span>,</span> order.</span>price</span>(</span></span>)</span></span>)</span></span>,</span>
</span></span></span></span>        _</span> =></span> println!</span>(</span></span>"</span>You ordered something for ${}</span>"</span></span></span>,</span> order.</span>price</span>(</span></span>)</span></span>)</span></span>,</span>
</span></span></span></span>    </span>}</span></span>
</span></span></span></span>}</span></span></span>
</span></code></pre>
The _ wildcard is now required. Without it, you get this error: “non-exhaustive patterns: _</code> not covered”</p>
</span></a>
Adding New Variants Without Breaking Changes</h3>
Now you can safely add the burrito:</p>
//</span> menu/src/lib.rs
</span></span>#</span>[</span>non_exhaustive</span>]</span></span>
</span>pub</span> enum</span> Menu</span> {</span>
</span></span></span>    Pizza,</span>
</span></span></span>    Burger,</span>
</span></span></span>    Tacos,</span>
</span></span></span>    Burrito,</span>  //</span> New item added safely!
</span></span></span></span></span>}</span></span></span>
</span>
</span>impl</span> </span>Menu</span> </span>{</span>
</span></span></span>    pub</span> fn</span> </span>price</span></span>(</span>&</span>self</span></span>)</span></span></span></span> -></span> f32</span></span> </span>{</span>
</span></span></span></span></span>        match</span> self</span> {</span>
</span></span></span></span></span></span>            Menu::</span></span>Pizza =></span> 100.</span>0</span>,</span>
</span></span></span></span></span></span>            Menu::</span></span>Burger =></span> 180.</span>0</span>,</span>
</span></span></span></span></span></span>            Menu::</span></span>Tacos =></span> 60.</span>0</span>,</span>
</span></span></span></span></span></span>            Menu::</span></span>Burrito =></span> 150.</span>0</span>,</span>
</span></span></span></span></span></span>        </span>}</span></span>
</span></span></span></span></span>    </span>}</span></span></span>
</span></span></span></span>}</span></span></span>
</span></code></pre>
With this change, you can add more variants. No breaking change, no need to update the major version number.</p>
</span></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.</p>
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.</p>
This way, you can safely add new fields to your struct in future versions without breaking anyone’s code.</p>
Let’s add a configuration struct to our menu library:</p>
//</span> menu/src/lib.rs
</span></span>#</span>[</span>non_exhaustive</span>]</span></span>
</span>pub</span> struct</span> </span>MenuConfig</span> </span>{</span>
</span></span></span>    pub</span> theme</span>:</span> String,
</span></span></span>    pub</span> show_prices</span>:</span> bool</span>,
</span></span></span></span>}</span></span></span>
</span>
</span>impl</span> </span>MenuConfig</span> </span>{</span>
</span></span></span>    pub</span> fn</span> </span>new</span></span>(</span>theme</span>:</span> String</span>)</span></span></span></span> -></span> Self</span></span> </span>{</span>
</span></span></span></span></span>        Self</span> {</span>
</span></span></span></span></span></span>            theme,</span>
</span></span></span></span></span></span>            show_prices:</span> true</span>,</span>
</span></span></span></span></span></span>        </span>}</span></span>
</span></span></span></span></span>    </span>}</span></span></span>
</span></span></span></span>}</span></span></span>
</span></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”:</p>
//</span> This fails to compile! (in the app crate, not in the library)
</span></span>let</span> config =</span> MenuConfig {</span>
</span></span>    theme:</span> "</span>dark"</span></span>.</span>to_string</span>(</span></span>)</span></span>,</span>
</span></span>    show_prices:</span> false</span>,</span>
</span></span></span>}</span></span>;</span>
</span></code></pre>
Instead, external crates must use the constructor function you provide:</p>
let</span> config =</span> MenuConfig::</span></span>new(</span>"</span>dark"</span></span>.</span>to_string</span>(</span></span>)</span></span></span>)</span></span>;</span>
</span></code></pre>
You can still access the fields since we marked them as pub:</p>
println!</span>(</span></span>"</span>{}</span>"</span></span></span>,</span> config.</span>theme)</span></span>;</span>
</span></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.</p>
</span></a>
References</h2>

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

impl Blog for Rust

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

Let's understand what is Blanket Implementation in Rust

Avoiding Breaking Changes with Rust's #[non_exhaustive]