Hardware pulses burst

[fma38]

Hi!

Is there a way to generate a hardware pulses burst, with a precise frequency and number of pulses?

Thanks,
Frédéric

[Flipje1955]

Frédéric, have you considered / explored the rather unique PIO capabilities of the RP2040 ? There are quite some neat usecases around showing how PIO can be exactly programmed, essentially with clock_cycle accuracy.

[fma38]

My first idea was to find a solution based on standard PWM, Timer..., which would be more universal, but I post here as I'm mainly using RPi Pico boards, and, yes, I think it could be done using the PIOs.

But even if I wrote a few things with PIO, I'm not sure how to deal with this case :o/

Maybe a combination of PIO, PWM...?

Or even DMA? As my goal is to generate pulses for a stepper motor (with acceleration/deceleration), this is maybe the way to go, as the DMA could automatically load the values to the PWM (or PIO program)? But I never wrote anything using DMA...

[robert-hh]

As an exercise I wrot a little module for PIO once which sends a sequence of pulses using the PIO and also captures them. https://github.com/robert-hh/RP2040-Examples/tree/master/pulses
using a methods from this class: https://github.com/robert-hh/RP2040-Examples/tree/master/rp2_util
Maybe you can use that or at least take it as an example.

[fma38]

Interesting! I'll dig into your code to try to adapt it... Thanks!

[fma38]

Ok, I have a working version :o)

Question: is it possible to append some new data to the DMA, even if it is still feeding the state machine with the previous data?

[robert-hh]

That should be difficult, since you have to tell the state machine the size of the data. Even replacing the data could be tricky. You could try a second state machine at the same pin and switch (stop the first, start the other).

[fma38]

The size of the data can't be modified on the fly, while the DMA is running?

[robert-hh]

You can try to modify the DMA register while running. It's a while since I made that, so I do not recall it.
Use dma_transfer_count as a template

# Set the current transfer count
#
@micropython.viper
def set_dma_transfer_count(chan:uint, count:uint) -> int:
    dma=ptr32(uint(DMA_BASE) + chan * 0x40)
    dma[TRANS_COUNT] = count
    return count

I'm not sire whether DMA has to be stopped, and it will most likely cause a hiccup in transfer.

[fma38]

Ok. In fact, I should be able to compute the entire buffer for the accel/decel curve, and send it in one shot to the DMA.
The important point is to ensure the correct number of steps for the move.

[fma38]

Ok, it works! But I have a little issue. Here is my code:

@staticmethod
@rp2.asm_pio(sideset_init=rp2.PIO.OUT_LOW)
def _pioPulses():
    # In the routine, ISR contains pulseFreq, and Y nbPulses.
    # X is used as pulseFreq counter. Y is decremented until 0.

    # Get input values (pulseFreq, nbPulses)
    # Blocking
    pull().side(0)  # get pulseFreq from FIFO; set output LOW
    mov(isr, osr)   # store pulseFreq to ISR
    pull()          # get nbPulses from FIFO
    mov(y, osr)     # store nbPulses to Y

    # Start pulsing (square)
    label("start")
    
    mov(x, isr).side(1)      # put previously saved pulseFreq to counter; set output HIGH
    label("loopHigh")
    jmp(x_dec, "loopHigh")   # decrement pulseFreq counter and loop if non 0
    
    mov(x, isr).side(0)      # put previously saved pulseFreq to counter; set output LOW
    label("loopLow")
    jmp(x_dec, "loopLow")    # decrement pulseFreq counter and loop if non 0
    
    jmp(y_dec, "start")      # loop on nbPulses

@property
def value(self):
    self._sm.exec("push()")  # push ISR to the FIFO
    return self._sm.get()`

The problem is when I get the value, it seems to freeze the PIO code (or DMA?).

Any idea why?

[fma38]

I will start another thread, as I have several questions about the DMA...

[fma38]

I hooked up my pulse generator to a real stepper driver and a motor, and I have an issue: the motor makes a bad noise. I checked the signal with an oscilloscope, and it seems I have some jitter!

The code involved is the one above. The generation of the pulses is done by this part:

# Start pulsing (square)
label("start")

mov(x, isr).side(1)      # put previously saved pulseFreq to counter; set output HIGH
label("loopHigh")
jmp(x_dec, "loopHigh")   # loop on pulseFreq counter

mov(x, isr).side(0)      # put previously saved pulseFreq to counter; set output LOW
label("loopLow")
jmp(x_dec, "loopLow")    # loop on pulseFreq counter

jmp(y_dec, "start")      # loop on nbPulses

Any idea what can cause that?