esp32-S3 vs pico 2 motion execution difference

[programmeddeath1]

Hii,

We’re using FastAccelStepper in a high-duty 2 axis delta robot (80–100 PPM, short segments ~10–20 ms, upto ~96k steps/s peak each for 2 motors ) and would appreciate your guidance on execution determinism and architecture.

We are currently evaluating two setups:

1. ESP32-S3

• Backend: MCPWM / RMT
• Hardware-timed step pulses
• Segment transitions and FIFO refill handled by CPU/RTOS
• Communication via Ethernet (UDP), with individual packets transferred in <0.5 ms

2. RP2040 / RP2350 (Pico / Pico 2)

• Backend: PIO (currently used as pulse generator)
• Segment transitions and FIFO refill still CPU-driven
• Communication via USB CDC, with packet transfer ~1–1.5 ms

Key questions:

1. From FastAccelStepper’s architecture, is PIO inherently more deterministic than MCPWM, or are they effectively equivalent when pulse timing is hardware-generated?
2. In the current FastAccelStepper design, are segment boundary transitions CPU-governed on both ESP32 and Pico?
3. Does using PIO without a DMA-driven execution model provide a meaningful determinism advantage over MCPWM?
4. If higher determinism is desired, would achieving a real advantage on Pico require a custom DMA→PIO execution pipeline beyond FastAccelStepper’s current scheduling model?
5. For short-segment, high-jerk motion, which platform would you personally consider the safer or more deterministic choice when using FastAccelStepper as-is?
6. Regarding the PIO backend (currently used as a pulse generator): How can we architect the system to make it truly independent of the CPU? Specifically, we want to understand if it is possible to use PIO to:

• Decide when a segment ends autonomously.
• Transition velocity profiles without CPU intervention.
• React to encoder mismatches in real-time.
• Continue motion deterministically even if the CPU stalls.

We are not comparing raw step rates, but rather execution ownership and determinism at segment boundaries and direction changes at high accel/decel. Your perspective as the library author would help us ground this decision in how FastAccelStepper actually behaves across platforms.

Thanks in advance!

[gin66]

Hi,

pretty in-depth questions from your side. Let me try to answer:

1. If you are using a recent esp32-arduino, then the mcpwm driver is not supported anymore and only rmt is available. If esp32-rmt and pico-pico are served on time, then both are deterministic. mcpwm/pcnt poses the risk of overrun under high cpu-load (interrupt blockage), which hopefully is mitigated but only after the fact. Overall the pio-solution operates actually as a programmable HW-block and is IMHO pretty reliable.
2. if you mean with segment boundary a command boundary, then for both the answer is, that they are CPU-governed. For rmt it is even worse, because one command with >24/32 steps has to split over several rmt-"cycles", while pio is a one to one relationship. This means pio needs less CPU load and the pio-fifo is actually filled with only a 1ms high prio-RTOS task and not even an interrupt.
3. I do not see the drawback of having no DMA, because pio uses a four level fifo. esp32-rmt with DMA would make it only more complex. esp32+mcpwm with DMA would not work.
4. Not clear, where the DMA should be. pio architecture is: ramp generator->cmd-queue->pio-fifo->step generation. pio uses one to one ratio of command and with the four word fifo, there is normally 1-2ms of lookahead in the pio-queue and up to 10-20ms in the cmd-queue.
5. My preference is pico with pio. The pio-module is a great piece of HW and FastAccelStepper's pio-SW-module even provides realtime position. If you need very low level control, then do not use FastAccelStepper ramp generator, but feed the pio-fifo by yourself.
6. Truly independent from the CPU ? Well, you can't. There is no HW-mechanism to forward segment info from any communication interface to the pio. And looking at your list of four requirements, then this may not fit into the pio program memory at all.

Here are some questions back to get better understanding:

1. Which problem with current esp32/pico implementations do you face and need to solve ?
2. What do you mean with "segment" and "segment boundary" ?
3. What do you mean with "deterministical" ? PIO and esp32 are RTOS systems, but IMHO not hard real time systems. Especially communication interfaces may block interrupts for a while. Thus the app need to make some guarantees, that CPU stalls do not occur.
4. What is the point about DMA - especially if reaction to encoder mismatches need to be corrected ? DMA means to prepare some data to plan for the future and the longer the planning, the less reactive the system will be.

Final comment to your emphasis on determinism and CPU independence: FastAccelStepper and esp32/pico are not intended for use in functional safety-critical systems.

Hope this helps.