Using RP2040 PIO and DMA to generate steps and dir

[Volksolive]

The step generation for the RP2040 driver is already using the PIO to generate the steps and the step timer but what if the DMA would also be used to send the step + dir to the PIO FIFO from the step buffer directly without using any of the M0 cores.

the idea would be to have a step generation ultra efficient that is all managed by the PIO and DMA only, so that the 2 cores can focus on the gcode comm, planner, I/O, external hardware, etc .. That way the Pico could managed up to 6 axis (12 pins for step and dir) and have the most important pin directly connected like Reset, safety door (I imagine having cycle start and feed hold on an I/O expander is not an issue) and have all other pin on an IO expander, maybe the limit input could be connected to the IO expander but at the same time all ORed and connected to one pin on the Pico to make reaction faster. That would leave enough pin to have UART0 or I2C0, I2C1 and SPI0.

I am not familiar enough with the way the step are generated so I don't know if this could be feasible but I imagine that the DMA could transfer 32 bits data to the PIO FIFO, the data would be composed of 6 bits of step output, 6 bits of dir output, 8 bits of step delay and 8 bits of step pulse length, the extra 4 bits could be used to generate IRQ when needed to handle f.ex backlash, RPM update, etc ..

The step generation would be synched to another PIO SM that generate the step timer so that the DMA can send data to the PIO FIFO asynchronously and keep the FIFO topped as long as there is step in the step buffer.

I imagine a Feed Hold would pause the DMA channel or slow it down to recalculate the step block new exit speed. Or maybe that is done on the next step block ?

Does that sounds like a good and feasible idea or completely useless/stupid ? Of course doing this would require a lot of change on GRBL core and make it incompatible with other driver, so probably this should have its own repo ..

[terjeio]

Does that sounds like a good and feasible idea or completely useless/stupid ?

A good first step would be to use DMA in combination with shift registers to output step, dir and motor enable signals. 3 pcs HCT595 in series (24 bits) fed by a PIO program at a high clock speed would allow control of up to 6 axes from three pins. And there would be 6 spare outputs that could be used for other signals.

Modifying the grblHAL core to use DMA/PIO only for step generation would be a lot harder, perhaps even impossible on a RP2040.

However, moving step generation to the second core could be an interesting excercise. The planner and stepper code is tightly coupled so it would be hard to separate them without adding a lot of overhead. If moving both to a second core can done be successfully then next step would then be to implement the planner and step generation in a FPGA?

[Volksolive]

this idea is not to solve the pin shortage issue but more to have a step generation (not calculation) that is completely independent from the cores by having the DMA feeding the PIO instead of the stepper IRQ. Right now one PIO generate an IRQ and the second one is of fed with the step info and generate the steps with delay and pulse length. what if instead, the DMA would automatically feed the PIO and this PIO is waiting on the other PIO to generate the steps available on its FIFO, so no IRQ is needed (except when other things need to happen like RPM update, etc), thus removing the overload of the IRQ on the core.

But shifting the step, dir and other output would definitely save up pins for Phil BOB

[chris2560]

I don't understand fully in depth how GRBL works, but have done enough digging in the source code to realise the second processor core looks to be currently unused, and my machine is suffering serious ticking noises/ motor jitter as the status reports are requested/sent.

I haven't fully tested if the jitter is reduced by reducing the amount of information in the status reports, but I can't work out how to make my GUI to withstand less information than current line number and position and occasionally the current datum.

Weirdly I never noticed this jitter with GRBLMega on an Atmega1284, so I don't know if the native USB is partly to blame for the issue, or if I'm noticing the jitter more because I'm now running a Seig X1 from the system with 4A steppers so it's more audible.

I can't see any serious lack of GPIOs available, so I think the best option may simply be to handle the planner and stepper routines in the second core.

(I tried implementing multicore myself but the motor would do 1 step then freeze, so I think the unset part of the GPIO step cycle didn't work - I'd simply launched the second core into a loop running the stepper interrupt service routine continuously).

I can provide a list of my $$ settings if that might give any other clues about the jitter, currently $10=63.

Anyway many thanks for the work going into developing this GRBLHal software, my machine probably wouldn't run at all without it.

[terjeio]

Which board? Steps/mm setting? Max feed rates?

... the second processor core looks to be currently unused

I am not sure how this is for the Pico W, part of the networking code is running on the second core?

The first thing would be to check the USB vs stepper IRQ priorities - the stepper IRQ should have the highest (lowest number).
And, if possible, try a UART<>USB breakout to remove native USB as source to verify if USB comms is causing the jitter.

I do not think running some of the grblHAL code on the second core is trivial, if the USB stack is the culprit it might be easier to move that? I do have a longer term plan to move the planner and step generation either to a second core or a FPGA, this would require a clean API into the moved code - now parts are tangled together via global variables. Having two processes accessing those without locking is doomed to fail?

...I think the unset part of the GPIO step cycle didn't work

This is handled by PIO code, not by the CPU so totally independent of it.

[terjeio]

I have scoped the output, can't se any jitter introduced by USB. If you connect with a terminal and send motion commands do you still get jitter?
BTW I have introduced a regression in the latest build, the default step pulse delay ($29) is incorrectly set to 5, should be 0. Note that the sum of $0 (step pulse length) and $29 hard limits the max step rate. If you are close to, or exceeding, this limit steps will be lost.