Why esp32s3 only supports 4 steppers?

[GarmischWg]

According to this section of the documentation, esp32s3 can only support 4 steppers using step/dir/en pin control. Whilst a esp32 can support 14 steppers at a time. Why is that? What's the limiting factor?

From my understanding, ESP32s3 has 2 pcpwm unit, each has 3 channels, so, shouldn't it be able to control 6 steppers independently? Or is some of the channel preoccupied?

I am going to use an esp32s3-devkit-c for a project that involves atleast 6 steppers, controlled by step/dir/en pins, will this library work for the above hardware configuration?

[gin66]

FastAccelStepper uses for esp32 derivates either rmt-module or a combo of pcpwm/pcnt-modules, In case of esp32s3 the limiting factor is not the 2 mcpwm-modules a 3 channels, but the pcnt-module with only four counters.

As mentioned in the Readme, there are chances, that the four rmt-TX channels can be supported, too. This would ramp up the number of supported steppers for esp32s3 to 8.

Fron the overview the best chip is esp32 for stepper applications.

[GarmischWg]

Thank you very much for your quick reply.

I have breifly looked into rmt, seems to be another counter peripheral.

Do you mean the hardware theoratically support 8 steppers or the library can support 8 stepper on esp32s3 (implemented, but not tested)?

I am very unfamiliar with peripheral controls. So i don't even know if counter allocation is done by this library or the arduino framework, or if it is even possible to use counter from another channel like that. Please enlighten me on this.

[gin66]

FastAccelStepper could support 4+4 steppers with esp32s3, if implementation is done. Currently only 4.

In more general terms: The hw can support using mcpwm/pcnt and rmt-modules in total 8 high speed pulse generators. So it is able to drive 8 steppers simultaneously. With dynamic allocation of pulse generators to steppers, there would be no limit on the number of supported steppers (except RAM). I had this dynamic scheme in mind from the beginning, but never completed this. I assume most applications need the steppers simultaneously.

[GarmischWg]

Understood, thank you very much 👍👍.

[GarmischWg]

As mentioned before, esp32s3 and esp32c3 has similar rmt module (with different num of channels), if i want to try implementing the 4+4 stepper setup for esp32s3, i plan to modify the following parts of the code

• duplicate StepperISR_esp32c3_rmt.cpp and change name.
• common.h (modify the defines for esp32s3)

Just want to know if i am completely off or not, before i fork and modify the code. Please point me at the right direction. i have the hardware to test the code, and i will PR the code if it works. (Big if)

Most of my time of arduino coding, i have lived under the protection of the arduino framework, basically never directly touched peripherals before. Now that i have a project that invovles 6 steppers, limit switchers and magnetic encoder with 1 esp32s3 (only esp32s3 has enough pins), i have no choice but to probably fork this library and modify it. (its a 6-axis robotic arm.)

Thank you for your time and guidence.

[gin66]

Sounds great, that you have the hardware and willingness to do and test the changes. Last time I have compared briefly, the esp32c3 vs esp32s3 modules, I had the impression, that espressif only changed names of registers. If you search for SUPPORT_ESP32S3_MCPWM_PCNT, then most of the changes are renaming of registers. If the behavior changes, then it will take longer.

Please check the size of the RMT memory per channel. This was a change from esp32 (64Bytes) to esp32s3 (48Bytes). If esp32s3 is same, then no change needed.

[GarmischWg]

Hello, good news, i am able to get the rmt modules to work as a pulse generator for the steppers.
However, there is a bug, out of 4 steppers driven by RMT, only 1 of them would work, i suspect that the commands are written into the wrong register/channel.

I am still trying to understand the code, if possible, can you explain what does the PART_SIZE represents here?

(Edited after 36 minutes)
LOL, its a hardware issue... No problem now, they work.

[gin66]

Congratulations. So soon you can provide a PR ?

The rmt memory is split into two parts of PART_SIZE bytes. It is one byte less than the theoretically possible memory size. Reason is, that end of buffer event shall not be triggered and the current scheme using only threshold events works well. The two buffers are used like this: one half is processed by rmt, while the other is updated by FastAccelStepper. When buffer half is reached (using threshold interrupt), the other buffer half is processed. This gives one condition to the runtime: half buffer preparation from the uC must be finished, before rmt reaches the second buffer.

With 23words per half buffer and one word can create at max one pulse. 23 pulses at 200kHz need 115us. So the interrupt rate is approx 9kHz at high speed.

[GarmischWg]

Sure, i can do a PR.
Are there any best practices you would like me to know? like using a new branch for PR, squash commits etc.

Btw, thank you for the explanation.

[gin66]

I had to edit my comment due to wrong calculation. Now timing is quite relaxed.

No best practices implemented. Just issue a PR from your github and I will process it (at least run the code formatting tool), update Readme and so on. may take a while, cause I am currently pretty loaded,

[GarmischWg]

Ok, no worries, let me update the readme as well.

[GarmischWg]

PR requested. #225

[gin66]

as the pr has been merged, the discussion can be closed