rp2 DMA: 'treq_sel' value for 'no throttling'?

[mungewell]

The rp2040 datasheet suggests that DMA can be 'un-throttled', ie running as-fast-as-possible.

With my code only transferring 4x 32-bit words into the PIO's FIFO that should be able to happen, without slowing to however fast the StateMachine is being clocked (and can handling/processing the pull()/auto-pull).

However if I create a DMA() object, the default value for 'treq_sel' is 0, which is 'DREQ_PIO0_TX0'...?
https://docs.micropython.org/en/latest/library/rp2.DMA.html#rp2.DMA.pack_ctrl

>>> import rp2
>>> a = rp2.DMA()
>>> a.ctrl
0
>>> a.unpack_ctrl(a.ctrl)
{'inc_read': 0, 'high_pri': 0, 'write_err': 0, 'ring_sel': 0, 'enable': 0, 'treq_sel': 0, 'sniff_en': 0, 'irq_quiet': 0, 'read_err': 0, 'chain_to': 0, 'busy': 0, 'inc_write': 0, 'ring_size': 0, 'bswap': 0, 'size': 0, 'ahb_err': 0}

So how do I select 'no-throttle'?

[mungewell]

OK, found it... there are extra values defined in the definition for 'CH0_CTRL_TRIG'.

So it's '0x3f', and it appears to work... shouldn't that be the default value though?

[GitHubsSilverBullet]

With my code only transferring 4x 32-bit words into the PIO's FIFO that should be able to happen, without slowing to however fast the StateMachine is being clocked (and can handling/processing the pull()/auto-pull).

If you talk to hardware, you need to use the proper DREQ for that device.
The 0x3f is only useful for mem-to-mem DMA.
Used on a device, you're actually force-feeding it at the significant risk to drop/forget values.
If a StateMachine is able to receive four values, it'll do that at full speed anyways. The throttling happens only when the FIFO cant take any more.

[mungewell]

If a StateMachine is able to receive four values, it'll do that at full speed anyways.

Do you have a reference for that, my concern is that it the StateMachine is being slowly clocked - that might mean that the DMA is paused for some (short) time...

Specifically my code is reading the Timer u-sec counter. When accessing the 64bit value care needs to be taken to ensure that the 'TIMELR' is read first (which latches 'TIMEHR' value) and then 'TIMEHR' is read as-soon-as-possible. Unfortunately these are not sequential address locations, you have to use the 'ring' to limit to changing lower address bits and then read 4x 32-bit words.

In my code I use very specific State-Machine clock rates, and I need to keep multiple machines exactly in sync.

As to 'loosing values' due to full FIFO; yes, code need to be designed with that in consideration.

Here I am 'ingesting' a GPS 1PPS (1Hz) signal to time stamp it's value... the longer the DMA 'process' takes, the more risk that some other part of the OS will corrupt the 'TIMEHR' value - by causing it to be latched again.

If the default value is '0' it wouldn't it mean that other/random DMA transfers are being throttled by what-ever SM0 is doing with it's TX FIFO?

[mungewell]

Well, I wrote a script using the us timer.

Chaining:
trigger -> timestamp-A -> timestamp-B -> trigger

And at some points I can see that B is later than A, the timing 'slips' as GPS 1PPS is 'perfect' and my TCXO is slightly off (~0.1PPM out). After a while time 'slip' is such that both A and B occur within the same microsecond.

Timestamp-A: 0x0000000013a684bf 329680063
Timestamp-B: 0x0000000013b5c6ff 330680063
Timestamp-A: 0x0000000013b5c6ff 330680063
Timestamp-B: 0x0000000013c5093f 331680063
Timestamp-A: 0x0000000013c5093f 331680063
Timestamp-B: 0x0000000013d44b7f 332680063
Timestamp-A: 0x0000000013d44b7f 332680063
Timestamp-B: 0x0000000013e38dbf 333680063
Timestamp-A: 0x0000000013e38dbf 333680063
Timestamp-B: 0x0000000013f2cfff 334680063
Timestamp-A: 0x0000000013f2cfff 334680063
Timestamp-B: 0x0000000014021240 335680064 <----- 'B' reports a high us value
Timestamp-A: 0x000000001402123f 335680063
Timestamp-B: 0x0000000014115480 336680064 <---
Timestamp-A: 0x000000001411547f 336680063
Timestamp-B: 0x00000000142096c0 337680064 <---
Timestamp-A: 0x00000000142096bf 337680063
Timestamp-B: 0x00000000142fd900 338680064 <---
Timestamp-A: 0x00000000142fd8ff 338680063
Timestamp-B: 0x00000000143f1b40 339680064 <---
Timestamp-A: 0x00000000143f1b3f 339680063
Timestamp-B: 0x00000000144e5d80 340680064 <---
Timestamp-A: 0x00000000144e5d7f 340680063
Timestamp-B: 0x00000000145d9fc0 341680064 <---
Timestamp-A: 0x00000000145d9fbf 341680063
Timestamp-B: 0x00000000146ce200 342680064 <---
Timestamp-A: 0x00000000146ce200 342680064
Timestamp-B: 0x00000000147c2440 343680064

I am trying to see if I can force this to be worse with different treq and State-Machine clocking, but so-far it's staying the same.

[mungewell]

The throttling happens only when the FIFO cant take any more.

OK I believe you are correct... I made the 'relay' State-Machine much much slower so I could see the delay in when then timestamps were received/printed by app, but the printed values remained 'accurate' (either exactly the same, or off by 1).

BTW: assuming that 'slip' is linear/uniform (and after everything was warmed up) we can use the data to guest-imate the duration of the DMA transfer for TimeStamp-A process.... 1/15 or around 66ns at a CPU freq of 180MHz (my choosen favourite)

[mungewell]

Guess this counts as a side-question, but if I need to set the 'treq' how can I programmatically figure out which PIO a State-Machine is allocated to?

print(sm[0]) will output it in text, but I can't seem to reference .id directly
https://github.com/micropython/micropython/blob/master/ports/rp2/rp2_pio.c#L607

Documentation does not say...
https://docs.micropython.org/en/latest/library/rp2.StateMachine.html

[GitHubsSilverBullet]

Guess this counts as a side-question, but if I need to set the 'treq' how can I programmatically figure out which PIO a State-Machine is allocated to?

Shouldn't you know that already, since instantiating a StateMachine (class) requires a number 0…7 (0…11 rp2350) as the first parameter?

And if you put the instantiated StateMachines in a list,
enhance the list to contain [(sm, numid), …]

[mungewell]

Sure I could track the PIO Block/engine, maybe make my sm[] list 2-dimensional, but the State-Machine has to track it (as evident from print(sm) and sm.active(1)) so it make sense that the API would provide access to it...

'AI' suggested (OMG am I a vibe-coder now?)

def inspect_sm_id(sm_object):
    # This might vary depending on the MicroPython version and memory layout
    baddr = bytes(array('O', [sm_object]))
    addr = int.from_bytes(baddr, 'little')
    # The offset (e.g., +10) is specific to certain MicroPython builds
    sm_id = mem16[addr + 10]
    return sm_id

Which works now, but may break at some time in the future as it's outside of the API.

This gives me, combined with my special class, a very clean way to specify State-Machines and attach trigger/timer-stamps to them, to measure the timing of GPS 1PPS and my (re-synthesized) LTC 1PPS.:

    sm = []

    # timestamp PIOs allocated to 2nd PIO Block, run at CPU speed
    sm.append(rp2.StateMachine(4, pio_trigger_from_gpio, freq=-1,
                               out_base=Pin(GPIO_TOGGLE),
                               in_base=Pin(GPIO_TOGGLE),
                               jmp_pin=Pin(GPIO_TRIGGER)))
    sm.append(rp2.StateMachine(5, pio_relay, freq=-1))
    sm.append(rp2.StateMachine(6, pio_trigger_from_gpio, freq=-1,
                               out_base=Pin(5),
                               in_base=Pin(5),
                               jmp_pin=Pin(2)))
    sm.append(rp2.StateMachine(7, pio_relay, freq=-1))

    for m in sm:
        m.active(1)

    # Allocate DMA channel(s)
    dma_trigger_a = DMA_PIO_Trigger(sm[0])
    dma_timestamp_a = DMA_PIO_Timestamp64(sm[1])
    dma_trigger_b = DMA_PIO_Trigger(sm[2])
    dma_timestamp_b = DMA_PIO_Timestamp(sm[3])

    dma_trigger_a.chain_to(dma_timestamp_a.dma.channel)
    dma_timestamp_a.chain_to(dma_trigger_a.dma.channel)
    dma_timestamp_a.config(sm[1])

    dma_trigger_b.chain_to(dma_timestamp_b.dma.channel)
    dma_timestamp_b.chain_to(dma_trigger_b.dma.channel)
    dma_timestamp_b.config(sm[3])

    dma_trigger_a.config(sm[0], True)
    dma_trigger_b.config(sm[2], True)

    while True:
        while sm[1].rx_fifo() > 3:
            # read out 4x 32bits, first and last are relevant.
            a = []
            while sm[1].rx_fifo():
                a.append(sm[1].get())
            
            print("Timestamp-GPS: 0x%16.16x %d" % ((a[3]<<32)|a[0], (a[3]<<32)|a[0]))

        while sm[3].rx_fifo():
            # read out 1x 32bits
            b = sm[3].get()
            
            print("Timestamp-LTC:         0x%8.8x %d" % (b, b))