#Pico W PIO write delays + wifi

1 messages · Page 1 of 1 (latest)

runic merlin
#

How did you get down to that commit? It looks like it should just use DMA earlier. Not sure why it'd fail any more than not using dma.

I observed that it works reliably in 8.2.8 and 9.0.0-alpha.5, and doesn't work reliably in 8.2.9 and 9.0.0-alpha.6, and then I built a 9.2.7 with that line reverted to const size_t dma_min_size_threshold = 32 and the problem was resolved.

(However, I was mistaken about the different sensors - it's misbehaving with the other one too now.)

#

Pico W PulseIn+wifi

#

Wildly speculating that PIO DMA has some obscure conflict with wifi DMA.

#

By the way, what was the benefit of that change? I see, it was for correcting neopixel timings.

runic merlin
deft jasper
#

I'm working on that issue today, so your thread caught my attention. compute_fifo_depth() in the line you modified returns the number of 4-byte words available in the PIO FIFO, 4 or 8 depending on how the FIFO is configured. The code assigns the result to dma_min_size_threshold and then compares it to the length of the transfer which appears to be in bytes. So, the code may use DMA for a transfer smaller than the FIFO size. I don't see why this wouldn't work, but there could be a deeper problem in DMA interrupt handling that it's bringing out. Have you opened an issue?

runic merlin
#

I haven't opened one yet - thought I needed to prepare a better report first, but stumped so far. When I do anything to try to isolate the scenario, it starts working again.

deft jasper
#

My understanding is that the issue occurs with the line:

const size_t dma_min_size_threshold = self->fifo_depth;

and that it doesn't occur with:

const size_t dma_min_size_threshold = 32

Is that right?

runic merlin
#

That's correct

deft jasper
#

OK, that's definitely enough info to start an issue. That way we've got something less ephemeral than Discord to track it with.

runic merlin
#

OK, thanks, I'll open one a bit later

runic merlin
#

Ugh, I may have been tricked by an intermittent fault, and it's not that commit after all, despite switching back and forth several times earlier

runic merlin
#

I was maybe wrong about 9.0.0-alpha.5 vs alpha.6, and about 9.2.7 vs my patch, but still getting results on 8.2.8 vs 8.2.9 and there's nothing else in there 😓

runic merlin
#

Good thing I didn't make an issue yet, since it seems the problem isn't with PulseIn, it's with delays in rp2pio.StateMachine.write. I have a call to that which takes 20ms in isolation, but sometimes takes 120ms when all the other stuff is going on. Before the DMA change, the delay is usually in the middle of the transmission, which is usually tolerated. After the DMA change, the delay is usually at the end of the transmission, which means the function doesn't return in time to check for the reply. I still can't reproduce in a smaller program with less going on. Any thoughts @deft jasper ?

#

I guess I could try using background_write, though need to be careful it's finished.

runic merlin
#

Pico W PIO write delays + wifi

runic merlin
# 
sm.background_write(data)
time.sleep(0.002)
sm.clear_txstall()
while not sm.txstall:
    pass

On 9.2.7, has the same behaviour as write: when all the other stuff is going on, it takes 20ms or 120ms. Confirmed that clearing txstall while we're already stalled doesn't miss it. Confirmed by scope that the transmission finished promptly. So I'd suspect that something is delaying the txstall flag in these circumstances and write also relies on that. However, when using write, disabling wait_for_txstall on the state machine doesn't change the behaviour.

Reverting the DMA change moves the 100ms delay earlier in the transmission for write, but not for this version.

deft jasper
runic merlin
deft jasper
#

No bother. I've had a look at the PIO support implementation and don't see any obvious source for delays of the magnitude you're experiencing. To make progress, you'll need to open an issue including pared down sample code that reproduces the problem.