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 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>

impl Blog for Rust - pio

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