Most idiomatic way to measure the T-ON of a PWM signal with an esp32s3

[tommasoclini]

The title says it, I need to measure the ON interval of a pwm signal, I need the accuracy to be of 1us or less.
It is for RC control so the TON is between 1000 and 2000 us, the TOFF can vary from 500us to 18ms.
What is the best way to do this?
I'm using embassy, so async can be used.
I've heard of the MCPWM capture feature, but it is not supported yet in this hal, is there a way I could generate bindings for the hal, ll and register apis found in esp-idf? They don't require an OS, but I don't know how low or high level they are.

EDIT: I need to measure multiple of these PWM signals, at least 4.

UPDATE: As of now I'm using an array of signals and spawning a reader task which uses the embedded hal async Wait trait for each channel, with 2 channels it seems to work fine, suggestions on how to improve are well appreciated.
I'm using an interrupt executor to improve accuracy.

[igrr]

Hi, commenting just on the hardware capabilities and not on esp-hal... I needed to solve a similar task a while ago — capturing a PPM signal from an RC receiver. RMT peripheral ended up being the simplest option. PPM signal I was receiving combined multiple channels (one per servo) and therefore decoding was a bit tricky. In your case, decoding the signal should be simpler, but you need to use multiple RMT channels.

[tommasoclini]

In the past I had done something like what I need right now, but with esp idf in c++.
In that project I was using interrupts and esp_timer for measuring the T-ON of the signals.
It worked flawlessly for 4 channels, this is the lib I had written(it is pretty bad, but it worked):
https://github.com/tommasoclini/esp_pwm_capture.
Is something like this doable in the esp-hal + embassy ecosystem?

[tommasoclini]

I've tried it in an application where Wi-Fi is used, I'm getting fluctuations in the order of tens of microseconds every second or so, even with an interrupt executor(it looks like it makes it worse), help is appreciated.
I'm now using a single task which "runs" multiple readers futures using the join_all function from the futures crate, will using multiple tasks improve the situation?
Should I go the interrupt handler route? It probably is the most performant, but also (maybe) the least portable and modular.

[bjoernQ]

I've tried it in an application where Wi-Fi is used, I'm getting fluctuations in the order of tens of microseconds every second or so, even with an interrupt executor(it looks like it makes it worse), help is appreciated. I'm now using a single task which "runs" multiple readers futures using the join_all function from the futures crate, will using multiple tasks improve the situation? Should I go the interrupt handler route? It probably is the most performant, but also (maybe) the least portable and modular.

When WiFi or BLE is enabled, we need a scheduler to enable multiple concurrent tasks to run - i.e. execution of your code will pause and other tasks will run until control is given back to your (main) task. That is what you see here

I guess the best solution would be to use the RMT peripheral. Using interrupts (at a higher priority) should also work

[tommasoclini]

If I run the task in the second core, I don't get the fluctuations, what could the problem be? I'd like not to be restricted to using dual-core, is there a way around this?