Using same pin as MCPWM output and PCNT input on ESP32-S3

[lucapassarella]

Hi

We are developing a custom PCB where we have to control 4 TMC2209 (with STEP and DIR signals)

For our applications we want to use MCPWM for generating the PULSE and DIR signals (se are already able to do that setting internal register as specified in the technical reference manual)

We are using the esp-idf APIs (4.4.3) only for setting up pins and basic configuration, then we are using register for the configurations because APIs do not have the flexbility/configurations that we need for the pulse configuration

Now we are able to generate the PULSE and DIR signal using MCPWM, but we want to count the number of pulses that have been generated: the idea was to use the PCNT (one for each MCPWM) to count the raising edges

Our problems is that using the esp-idf APIs the GPIOs can be EITHER configured as output for the MCPWM OR input for the PCNT
We want to use the GPIOMatrix in the ESP32-S3 to have the actual pin as output of the MCPWM and then route/loopback that same output to the input of the PCNT


How is this possible?
Can you help us?

Thanks,
Luca

[ESP_igrr]

Hi Luca,

What you are trying to do is possible, but like you said, not using the public APIs.

We do use the same technique in some of the test cases in ESP-IDF. For example, this code sets up PCNT to measure I2S clock frequency.

Note the gpio_set_direction call: it "fixes" the direction of the IO to INOUT after the PCNT driver configures it as an input. I think something similar should work in your case as well.

In IDF v5.0 or later, there is an "io_loop_back" configuration flag introduced in PCNT, MCPWM and RMT. This flag modifies the driver behavior to have GPIOs configured as INOUT. (e.g. in pcnt_chan_config_t)

[lucapassarella]

Hi

Thank you for the fast response

So I need to configure everything and then:

• set pin in mode PIN_FUNC_GPIO
• set direction as GPIO_MODE_INPUT_OUTPUT
• GpioConnectInput to PNCT
• GpioConnectOutPut to MCPWM

By now (still in testing phase) I configured all of MCPWM using actual register, something like:

Code: [Select all] [Expand/Collapse]

1. SET_PERI_REG_BITS(SOME_BASE_ADDRESS + 0x008, B111, 2, 0);

GeSHi © Codebox Plus Extension

I would like to know now if there is something similar to this struct/definition but for the MCPWM:

Code: [Select all] [Expand/Collapse]

1. pcnt_periph_signals.groups[0].units[0].channels[0].pulse_sig;

GeSHi © Codebox Plus Extension

Easy to access but without having to hand manage all addresses and offsets


Also thanks for the heads-up on IDF v5.0 features, but unfortunately part of the code is based on arduino-esp32 2.0.5 and seem like it will take a time to get upstreamed into that


Thank you,
Luca

[ESP_igrr]

I would like to know now if there is something similar to this struct/definition but for the MCPWM:

Yes, please take a look at:
https://github.com/espressif/esp-idf/bl ... m_periph.c
https://github.com/espressif/esp-idf/bl ... m_struct.h

[ESP_morris]

BTW, if you want to drive the stepper motor in an open-loop, then the RMT peripheral is more suitable. It can generate the precise number of pulses you want. See example https://github.com/espressif/esp-idf/tr ... pper_motor

But if you want to do that in a close loop, then I think reading back the signal from the MCPWM (or RMT) is not sufficient. Even if the MCPWM can generate 10 pulses, that doesn't mean your motor will spin 10 steps. You may want to use a rotary encoder.

[lucapassarella]

Thanks @EPS_morris for the heads up

I wrote our custom quintic realtime position stream follower motion controller, it control the motor by velocity, but the step interface of the driver accept only step pulses

Right now I have a core running a busy-loop for generating the steps at the correct speed, I want to offload this task to hardware and MCPWM seem the right choice and I can control up to 6 independent motors on a single esp32 (S3 or not)

For our case open-loop is ok, so loop-back from MCPWM to PNCT is not a problem
Also thinking about it PNCT could be used for reading a quadrature-encoder, right? this would permit a seamless interface in the future


Thanks,
Luca