PIO write delayed by i2c display update

[dmcomm]

CircuitPython version and board name

Adafruit CircuitPython 9.2.7 on 2025-04-01; Raspberry Pi Pico W with rp2040

Code/REPL

import array
import time

import board
import digitalio
import displayio
import rp2pio
import busio
import i2cdisplaybus
import terminalio
import adafruit_displayio_ssd1306
import adafruit_pioasm
from adafruit_display_text.bitmap_label import Label

program = adafruit_pioasm.assemble("""
    pull
    mov osr ~ osr
    set pins 1 [8]
    set x 7
loop:
    out pins 1 [8]
    jmp x-- loop
    set pins 0 [7]
""")

displayio.release_displays()
i2c = busio.I2C(board.GP5, board.GP4)
display_bus = i2cdisplaybus.I2CDisplayBus(i2c, device_address=0x3c)
display = adafruit_displayio_ssd1306.SSD1306(display_bus, width=128, height=64)

probe = digitalio.DigitalInOut(board.GP0)
probe.switch_to_output(value=True)

output = rp2pio.StateMachine(
    program,
    frequency=25_000,
    first_out_pin=board.GP16,
    first_set_pin=board.GP16,
)

groups = []
for text in ["Hello", "World"]:
    group = displayio.Group()
    label = Label(terminalio.FONT, text=text, color=0xFFFFFF, x=10, y=10)
    group.append(label)
    groups.append(group)

def send(data):
    start_time = time.monotonic()
    probe.value = True
    output.write(data)
    probe.value = False
    print((time.monotonic() - start_time) * 1000)

bytes_to_send = bytes([0] * 15)
i = 0
while True:
    display.root_group = groups[i]
    send(bytes_to_send)
    time.sleep(5)
    i = 1 - i

Behavior

Expecting write to take 60ms with these values, which it does if we remove the display update, but it intermittently reports over 100ms. Scope trace shows the transmission is finished before the delay. Setting frequency to higher numbers gives more extreme results but is harder to see the details.

As above:

Without display update:

With display update, frequency=200_000:

Reverting c5c7d11 gives a similar amount of delay, but in the middle instead:

Description

No response

Additional information

No response

[dmcomm]

Requesting a 5ms sleep after the display update really sleeps for 5ms and has no effect on the problem. Requesting a 20ms sleep actually sleeps for 100ms but resolves the problem.

[dhalbert]

Could you try 10.0.0-alpha.6 and see if it's different? The sleep behavior you just mentioned may be different. This seems like two memory-heavy operations competing.

[dmcomm]

The delay is still present on 10.0.0-alpha.6

[eightycc]

@dmcomm Thanks for the issue!

With #8700, compute_fifo_depth() returns the PIO FIFO depth in 32-bit words, but _transfer() treats it as bytes. This causes _transfer() to select DMA for the transfer for some transfer sizes smaller than the PIO FIFO size. While this isn't a breaking bug, it does shed some light on the results you're seeing.

At the conclusion of _transfer(), a while loop waits for the PIO's stall bit to go off before concluding the operation:

circuitpython/ports/raspberrypi/common-hal/rp2pio/StateMachine.c

Lines 998 to 1008 in ef9e14b

	// Wait for the state machine to finish transmitting the data we've queued
	// up.
	if (tx) {
	while (!pio_sm_is_tx_fifo_empty(self->pio, self->state_machine) ||
	(self->wait_for_txstall && (self->pio->fdebug & stall_mask) == 0)) {
	RUN_BACKGROUND_TASKS;
	if (self->user_interruptible && mp_hal_is_interrupted()) {
	break;
	}
	}
	}

This could be where the delay is occurring.

[dmcomm]

I was interested to know whether removing RUN_BACKGROUND_TASKS there would prevent the delay, but it doesn't seem to.

And from what I wrote in the OP, I thought the workaround would be easy, but in my real program something else seems to be having this effect too.

[eightycc]

@dmcomm Please try adding wait_for_tx_stall=False to the argument list for the state machine constructor.

[dmcomm]

It makes no difference.

[dmcomm]

Sorry, to be clearer, it does correctly make the probe line on the scope trace drop one byte earlier in the case where there isn't a delay, but it doesn't resolve the delay.

[dmcomm]

Returning before "Wait for the state machine to finish" doesn't resolve the delay, so the delay isn't in that section, even though according to the scope the transmission is finished. The times when the delay does not occur, it returns after 6 bytes with 9 remaining, which is 8 in the FIFO and 1 in progress as expected.