Datasheet

1 if MOV or PULL:
2 osr count = 0
3
4 if osr count >= threshold:
5 if tx fifo not empty:
6 osr = pull()
7 osr count = 0
An autopull can therefore occur at any point between two 'OUT' s, depending on when the data arrives in the FIFO.
On 'OUT' cycles, the sequence is a little different:
Ê1 if osr count >= threshold:
Ê2 if tx fifo not empty:
Ê3 osr = pull()
Ê4 osr count = 0
Ê5 stall
Ê6 else:
Ê7 output(osr)
Ê8 osr = shift(osr, out count)
Ê9 osr count = saturate(osr count + out count)
10
11 if osr count >= threshold:
12 if tx fifo not empty:
13 osr = pull()
14 osr count = 0
The hardware is capable of refilling the OSR simultaneously with shifting out the last of the shift data, as these two
operations can proceed in parallel. However, it cannot fill an empty OSR and 'OUT' it on the same cycle, due to the long
logic path this would create.
The refill is somewhat asynchronous to your program, but an 'OUT' behaves as a data fence, and the state machine will
never 'OUT' data which you didn’t write into the FIFO.
Note that a 'MOV' from the OSR is undefined whilst autopull is enabled; you will read either any residual data that has
not been shifted out, or a fresh word from the FIFO, depending on a race against system DMA. Likewise, a 'MOV' to the
OSR may overwrite data which has just been autopulled. However, data which you 'MOV' into the OSR will never be
overwritten, since 'MOV' updates the shift counter.
If you do need to read the OSR contents, you should perform an explicit 'PULL' of some kind. The nondeterminism
described above is the cost of the hardware managing pulls automatically. When autopull is enabled, the behaviour of
'PULL' is altered: it becomes a no-op if the OSR is full. This is to avoid a race condition against the system DMA. It
behaves as a fence: either an autopull has already taken place, in which case the 'PULL' has no effect, or the program
will stall on the 'PULL' until data becomes available in the FIFO.
'PUSH' does not need a similar behaviour, because autopush does not have the same nondeterminism.
3.5.5. Clock Dividers
PIO runs off the system clock, but this is simply too fast for many interfaces, and the number of Delay cycles which can
be inserted is limited. Some devices, such as UART, require the signalling rate to be precisely controlled and varied, and
ideally multiple state machines can be varied independently while running identical programs. Each state machine is
equipped with a clock divider, for this purpose.
Rather than slowing the system clock itself, the clock divider redefines how many system clock periods are considered
to be "one cycle", for execution purposes. It does this by generating a clock enable signal, which can pause and resume
execution on a per-system-clock-cycle basis. The clock divider generates clock enable pulses at regular intervals, so
RP2040 Datasheet
3.5. Functional Details 358