From the blog: "Not surprising once you understand that slewing to a target significantly increases the number of pulses per second sent to the motors, and everything became just too much to handle for our little ESP32."
A hobby application of mine involves driving multiple steppers at high-ish frequencies, following sigmoid curves precisely and no tolerance for glitches, because the mass and the cost of the device(s) is too great to risk any failure in pulse output, and there is no feedback, so I must not suffer "missed" steps, glitches, etc. The big hammer that solves this is obviating the MCU core (ARM or otherwise,) in motion control and using timer peripherals with DMA.
Ultimately, I ended up turning to STM32G4 MCUs because of the ACT (advanced control timer) peripheral. These timers can generate arbitrary waveforms using DMA in a relatively simple manner: the ARM core and its code/RTOS/whatever can suffer whatever overload, priority inversion, sleep mode, etc. happens to emerge, and the timers are unaffected.
Today I would consider using RP2350 and the PIO peripheral, which is also capable of achieving this, I believe.
ESP32 has its MCPWM peripheral, but I determined that with MCPWM you can't do the sort of arbitrary acceleration/deceleration profiles I needed in a 100% "core-free" manner without either a.) cascading timers or b.) using interrupts. The former is, comparatively speaking, complex[1], and the later gets you back into the MCU core, and possible glitches[2]. With the ST ACT peripheral, the problem is self contained to one timer per motor: simple and straightforward. At least one of their MCUs has three of those timers (G474, in larger packages, for example.)
The other way to go is specialized motor driver ICs. Analog Devices, by way of their Trimanic line of devices and low cost breakout boards, has great products there, widely used with 3D printers, CNC and similar. The driver software is much more complex than my simple ACT peripheral solution, however.
[1] I know it's possible and others have done it. The ST peripheral is far easier to get working and get right, if you can deal with CMSIS and the ST reference manual.
[2] I know about interrupt priorities. I also know about code evolution, bugs and other ways that dealing in interrupt priorities can get fragile.