Synchronizing PIO and DMA with Micropython

[JackCode0011]

Hello everyone

I'm at a loss at the moment. Is there a way to synchronize PIO and DMA?

Initial situation: I have two DMAs that alternate and each fill their own array with bits. Always fixed 15'360 bits. PIO runs with instructions to wait for pin 0 and as soon as 1, other pins are evaluated with in_. In order for the data to be usable, it is essential that the 15'360 bits between two pins 0 = 1 are all evaluated. So if Pio reads a wrong number of bits, this is not a big problem, because with the program starting with wait pin0=1 it always aligns itself with the signal-input again, after not more than 1 missed cycle. And DMA as well, because it reads the bits from Pio.

But if DMA misses bits from Pio or to much bits are collectet, that Pio never collectet, DMA would continue and would obtain bits from the second cycle or the start of the new cycle has bits from the old one, as the DMA is programmed to get 15'360 bit. A switch is then made to DMA2, which then also starts recording in the middle of the cycle. The error then continues forever.

So is there a way to synchronize PIO and DMA, but for performance reasons at the PIO/DMA level? I have a solution with PIO and Micropython, but at 75 MHz sampling rate there are many read errors due to the lag of Micropython compared to PIO.

Second idea was to use IRQ, but when raising an IRQ-flag on PIO, when the cycle is ended or startet, I don't know how I could get DMA to read this IRQ-flag and instantly switch to the other DMA.

I need some trick where a new run of the instructions results in a clean start of a new DMA with an empty array. If at the end of the instructions the array is not yet full, or the array is already full before the end, the DMA capture should be considered invalid and the next attempt should be made.

See picture attached:

1. SM collects more bits than necessary due to a glitch for example. The programme therefore finishes earlier. Since the programme starts with pin 0 = 1, it starts again at the correct time for the signal input => no problem.
2. SM misses bits. This causes it to run into the next cycle, but then waits for the next cycle after the remaining bits have been completed => no problem.
   3/4. DMA always transfers exactly as many bits as SM (RX_FIFO) delivers. DMA thus runs parallel to SM and is always aligned with the signal input => no problem.
   5/6. DMA misses bits or reads too many bits that SM has read correctly. Since DMA always runs with the criterion of the number of bits read, the error continues and bits always end up in the byte arrays off different cycles => problem.

Solution idea (red crosses): If pin 0 = 1, the running DMA should be terminated if this would not happen anyway. This means in all cases where 15,360 bits have not yet been collectet (bits missed) or where only a few bits have been read (= DMA started too early). So what I tried was put IRQ before wait pin 0, but I don't know if it is possible to tell the DMA to look for this IRQ and do something. I haven't found anything about this possibility in the documentation.

Greetings and many thanks
Jack

[Lerc]

The arrangement is a bit much to get my head around at a glance, but I'll say what I have been doing in case it helps.

I generally use a combination of treq_sel (bits 22:17 of dma cont), chaining and bocking PIO reads.

The docs say "The CTRL.TREQ_SEL (transfer request) field selects an external DREQ. It can also be used to select one of the internal
pacing timers, or select no TREQ at all (the transfer proceeds as fast as possible), e.g. for memory-to-memory transfers"

You can set the DMA control register to throttle based on

(2350 datasheet, I presume 2040 is the same with fewer options)

For some effects. such as interleaving bytes from two DMA you can setup multiple transfers with a length of 1 that trigger each other when completed to do another single write. That means they would go on forever if left to their own devices but if you have at least one of them reading from a source throttled by the DREQ then they will stop when whatever is providing the data stops. The simplest dumb version of this would be

_DMA_A -> SM_A_FIFO with a length of 1234 The State machine might just be a a single instruction passing data from one FIFO to the other (but generally you find something to do with the data as it goes past)

DMA_B-> SM_B_FIFO with a length of 1, triggering DMA_C when completed (Don't trigger DMA_B yourself!)

SM_A_FIFO -> DMA_C -> SM_B_FIFO with a length of 1 triggering DMA_B when complete (trigger this one on setup)

Configure DMA_A DREQ to give data to SM_A only when it can take it
Configure DMA_C DREQ to take data from SM_A only when it has it.

DMA_B and DMA_C take turns doing a single write to SM_B which is where you'd do whatever you want with the interleaved data. They would normally go on like this forever, but DMA_C waits for data from SM_A so it stops when DMA_A stops._

I know it's not the use case you have here, but it describes what I'm doing, hopefully in a way you can infer how it would work for your needs.