simont153 wrote: ↑

Wed Jul 09, 2025 4:29 pm

I have an application that requires me to trigger a DMA transfer every N software loop cycles. One core is running a CIC filter and the DMA signals the second core to run the comb part.

simont153 wrote: ↑

Wed Jul 09, 2025 4:29 pm

Browsing the datasheet I have found that a PWM can trigger a DMA transfer on wrap but I do not see a way to increment the accumulator in the PWM channel in software. The only option I see is putting a PWM channel into DIVMODE=RISE and then physically connecting the PIN B to an output pin and pulsing that in software.

The following events can
trigger a channel:
• A write to a channel trigger register.
• Completion of another channel whose CHAIN_TO points to this channel.
• A write to the MULTI_CHAN_TRIGGER register (can trigger multiple channels at once).

simont153 wrote: ↑

Sun Jul 13, 2025 6:16 pm

Thank you, this is almost exactly what I was looking for.

I have tried to implement it however I did not find a way to completely isolate the PWM channel from system clock and have a single phase advance increment the counter.

Would you run the channel with EN bit off to gate it from the rest of the chip? My cursory attempt at this, and setting the divider to 1 did not produce expected results.

I have achieved a similar result with a short PIO program (using FIFO pushes and pulls to signal processor and DMA). It did require many DMA channels to configure and do the actual transfer.

simont153 wrote: ↑

Fri Jul 11, 2025 3:23 am

Code: Select all

int counter = 0;
while (true) {
	// some DSP algorithm that executes in roughly 300ns
	do_tight_loop();
	
	if (++counter > N) {
		dma_channel_start(chan_num);
		counter = 0
	}
}	

I am trying to optimize out the counter increment, dma software trigger and counter reset. I know it may seem silly but looking at the assembly it represents around 10 instructions which is a significant percentage of the work done in my tight loop.

I am seeking a way to increment some hardware register that will automatically trigger a DMA and reset itself when it reaches a predefined count.

.wrap_target
	mov x, y ; reload counter
counter_loop:
	pull block
	jmp x-- counter_loop
	in NULL, 32
.wrap

Tharre wrote: I am trying to optimize out the counter increment, dma software trigger and counter reset. I know it may seem silly but looking at the assembly it represents around 10 instructions which is a significant percentage of the work done in my tight loop.

gmx wrote: ↑

Thu Jul 10, 2025 1:03 am

For pacing trigger, there are 4 dedicated DMA timers.

https://rpltd.co/rp2040-datasheet wrote: DMA: TIMER0, TIMER1, TIMER2, TIMER3 Registers

Pacing (X/Y) fractional timer
The pacing timer produces TREQ assertions at a rate set by ((X/Y) * sys_clk). This equation is evaluated every
sys_clk cycles and therefore can only generate TREQs at a rate of 1 per sys_clk (i.e. permanent TREQ) or less.

Code: Select all

Bits Description Type Reset
31:16 X: Pacing Timer Dividend. Specifies the X value for the (X/Y) fractional timer. RW 0x0000
15:0 Y: Pacing Timer Divisor. Specifies the Y value for the (X/Y) fractional timer. RW 0x0000

// called at rate of clk_sys; returns TREQ
bool divide(uint16_t x, uint16_t y) {
 static uint16_t acc = 0;
 acc += x;
 if (acc >= y) {
 acc -= y;
 return true;
 }
 return false;
}

// similar to https://github.com/Wren6991/libfpga/blob/master/common/clkdiv_frac.v
// integer + fractional divider with 1st-order delta sigma pulse swallowing
bool divide(bool enable, bool divider_restart, uint32_t divisor) {
 divisor &= ~0xff; // truncate to 16.8 fixed-point
 static uint32_t counter = 0;
 const uint32_t one = 1 << 16; // 1.0 in 16.16 fixed-point
 if (divider_restart) {
 counter = 0;
 return false;
 }
 if (counter >= one) {
 counter -= one;
 return false;
 } else {
 counter -= one;
 counter += divisor;
 return enable;
 }
}

PicoTinker wrote: gmx wrote: ↑
10 Jul 2025, 02:03
For pacing trigger, there are 4 dedicated DMA timers.


How do they actually work? Initial X/Y values are 0/0: Does this mean stop?
Is the accumulator cleared when the register is written or is the phase arbitrary?
If not cleared, could something like 0/1 for X/Y drain the accumulator to 0, and it would start with a specific phase for next X > 0?

22:17 TREQ_SEL: Select a Transfer Request signal.
The channel uses the transfer request signal to pace its data transfer rate.
Sources for TREQ signals are internal (TIMERS) or external (DREQ, a Data
Request from the system).
0x0 to 0x3a → select DREQ n as TREQ
RW 0x00
Enumerated values:
0x3b → TIMER0: Select Timer 0 as TREQ
0x3c → TIMER1: Select Timer 1 as TREQ
0x3d → TIMER2: Select Timer 2 as TREQ (Optional)
0x3e → TIMER3: Select Timer 3 as TREQ (Optional)
0x3f → PERMANENT: Permanent request, for unpaced transfers.