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>

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>

impl Blog for Rust - logic-analyzer

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