RP2 (RPi Pico): Minimize effects of REPL USB VCP on PIO IRQ

[gnbl]

I am trying to buffer data from a PIO IRQ and transfer it to the USB host via print() in an otherwise empty "main" loop.
However, print() seems to block/delay the PIO IRQ so data is not captured properly.
The IRQ runs at about 16kHz at most, but there are pauses.
Buffering data first for later output eliminates the issue, but I would like to "stream" the data.

How could this [IRQ conflict] be avoided? With DMA or using the second core? Setting IRQ priorities?
Optimisations might be capturing two data words in the ISR and binary transfer, but the conflict would still occur..

#   data D2-D9
#   clk  D10
#   C/D   D11

import sys, time
import rp2
from machine import Pin
import micropython
micropython.alloc_emergency_exception_buf(100)

# global FIFO
#from collections import deque
data = []

# PIO
@rp2.asm_pio(autopush=True, push_thresh=10)
def wait_pin_low():
    wrap_target()      # loop
    wait(1, pin, 8)    # falling edge detect
    wait(0, pin, 8)
    in_(pins, 10)      # mapped inputs to ISR, auto-pushed to FIFO
    irq(block, rel(0)) # IRQ [in blocking mode] with relative IRQ number
    wrap()             # loop


# irq write to global FIFO
def handler(sm):
    global data
    data.append(sm.get())
    

# StateMachine
sm0 = rp2.StateMachine(0, wait_pin_low, in_base=Pin(2,Pin.IN))
sm0.irq(handler)


# run / print data
sm0.active(1)

while True:
    if data:
        word = data.pop(0)
        lo = word & 0xFF
        hi = word >> 8
        if hi:
            print( "1%02x"%lo, end=" ")
        else:
            print( "0%02x"%lo, end=" ")

# never reached, loop needs a stop condition
sm0.active(0)

[peterhinch]

Do you need to use an IRQ? You can poll the FIFO with StateMachine.rx_fifo() or just a blocking StateMachine.get().

[gnbl]

Polling would require the print() to work synchronously at the sampling rate (16 kHz) - I wasn't sure that would work so I attempted to separate acquisition and output via the FIFO buffer as a more general approach.
I'd also be interested in why exactly the problem occurs.

[peterhinch]

An IRQ occurring at a 16KHz rate is quite challenging. The fact that you can issue list.append in your ISR means that your interrupts are soft (appending to a list allocates: this would raise an exception in a hard ISR). Soft ISR's will be delayed whenever a garbage collection (GC) occurs - typically by a few ms.

Consequently my reaction to the interrupt based solution is to be rather surprised that it works.

A solution based on polling would still have to contend with GC, but you might have more control over when it can occur.

[rkompass]

You may let the dma receive the data from the PIO (without interrupt) and collect it in a buffer or in 2 alternating buffers.
This may be as simple as

sm = StateMachine(0, sm_gen, freq=2000)
arr = array('l', (0,)*30)
dma = RP2_Dma(sm,  arr)
dma.start()
sm.active(1)

which is taken from example 2 of my RPI2040 dma class https://github.com/rkompass/RPi2040_mPy.

The dma transfer to 2 alternating buffers is untested yet. What I tested was transfer from 2 alternating buffers to another destination (PWM in that case). But I think it should work.
The dma has no interrupt yet, but with sufficient buffer you are not in such a hurry and you may check periodically the transfer count to determine when you should send the next values out via USB.
DMA instead of interrupts also has the advantage, that almost no computing time is consumed. Its in the "parallel background", like the PIO:-)

[peterhinch]

That sounds excellent.

[gnbl]

Thanks, I'll give it a try!