New MCPWM APIs can't be parsed by SWIG (IDFGH-9046)

[surfskidude]

Is your feature request related to a problem?

With version 4 I could use the SWIG binging generator (https://www.swig.org/) to create an interface that could be used by a scripting language. The new API is such a kludge with tons of macros and variable length arguments making it impossible to use a tool such as SWIG.

Describe the solution you'd like.

Please consider making an easier to use API suitable for SWIG.

Describe alternatives you've considered.

No response

Additional context.

No response

[suda-morris]

Hi @surfskidude Could you please give a concrete example of why the variable length arguments can't be parsed by the SWIG tool? BTW, macros like MCPWM_GEN_COMPARE_EVENT_ACTION are just helpers, not necessary.

[igrr]

FWIW this issue also exists for bindings generators based on C++ templates. E.g. https://github.com/wasm3/wasm3/tree/main/platforms/cpp and https://github.com/ThePhD/sol2 would run into the same problem with variable length argument lists. The issue is due to the fact that these bindings generators rely on type information from the function signature. For varargs, there is no type information, so it's difficult to write a binder template which would determine the varargs type correctly.

[suda-morris]

Okay, thank you @igrr I see, the "fix" on the driver side is not hard but to provide a bunch of new functions to set the PWM generator's behavior one by one. e.g.:

mcpwm_generator_set_actions_on_compare_event --> mcpwm_generator_set_action_on_compare_event (thanks I was using plural in the varg version APIs)

However, I can see there are other public functions in the esp-idf that are also using the varargs (e.g. esp_eth_transmit_vargs). 🤔 Not sure if we're going to "fix" them.

[surfskidude]

I have not looked at all APIs, just the MCPWM API, which we use for servo control. The new MCPWM 5 API is much more complex and I do not think it is possible to use SWIG with this new API. We do not have the resources to hand-craft bindings. Will you continue supporting the 4.x release also in the future?

[suda-morris]

Will you continue supporting the 4.x release also in the future?

Yes, the 4.4 release is still in our service period. Check this.
BTW, the previous "legacy" driver APIs are still available even in esp-idf v5. You can use those APIs in driver/mcpwm.h.

The new MCPWM 5 API is much more complex

Right, but the complicity relies on the hardware itself. MCPWM is not a simple peripheral at all. The legacy driver gives us the illusion that it's simple because it made a lot of wrong assumptions to simplify the usage. In the new driver, we just exposed all the hardware abilities.

As I said in the above thread, we can provide non-vararg versions of APIs if you would like to. But we can't remove the existing vararg ones.