SDK • Re: Pico PIO IN read timing

Is the 'in' data clocked at the start of the instruction cycle or the end?

Data is sampled on the rising edge of clk_sys.
An instruction starts executing on the rising edge of clk_sys.
So to literally but not usefully answer your question, it's both - data is clocked in at the start of each instruction execution, and the next data is clocked in at the end of each execution.

But your real question is what delays there are: a PIO program can't see any absolute kind of timing, it can only see the relative timing of its own inputs and outputs.

The answer is that there is one cycle of delay on outputs (ie. appears on pins 1 cycle after instruction execution), and 1 cycle without synchronizers or 3 cycles including synchronizers on inputs.

So if a program changes the state of a pin and then reads the state of that pin it will see the change 4 instructions later (or 2 later if synchronizers disabled).

I note that the PIO I2S master example turns off the input synchronizers. Should I do this to increase the data input setup margin?

Turning off synchronizers is almost always a bad idea, apart from some very special cases where there's no other way to do it and you know enough about the timing to ensure there's no metastability.

Turning off the synchronizers NEVER improves the setup margin - it just moves which instruction sees which data.

In any kind of streaming application (including yours) you can always do things so that they are happening two cycles later than they would otherwise have done and keep the synchronizers enabled. The only time you need to consider disabling them is if you care about total delay through the system (eg. if you were doing I2S input and I2S output and the extra 14ns of delay was enough to matter), or if you are doing input and output at the same time such that you need to respond quickly to the change of an input signal (this is the reason the SPI example does it, though IMO even there for most practical SPI applications it can usually be avoided).

If you are working with inputs where the signals are generated by some independent clock source, then you MUST leave the synchronizers enabled. If your external device is clocked from an RP2040 output pin, then the datasheet does give you the input/output delays so that you can tell whether or not setup/hold times are achieved, though the tolerance stack of the RP2040 input/output plus the same for the remote device makes this problematic. Unless your data is faster than about 50MHz you just don't need to do this - the data is (typically) valid for more than one clk_sys cycle, so you pick the one that's in the middle of the valid period and ignore the fact that inconsistent data may be sampled (and never used) on cycles where it is changing.
just leave the synchronizers enabled and sample it a cycle later than the notional clock edge (ie. 5 instructions after you generated that clock)

Statistics: Posted by arg001 — Mon Jan 26, 2026 10:04 pm

---