Can I redefine or extend the defined by HAL interrupt handler?

[ntqbit]

Hello!
Thank you for this great project and for your work!

I am using async I2C in my project, so I add the async feature for the esp-hal dependency.
It seems like enabling the async feature aside from the I2C_EXT0 interrupt that is required for async I2C to work, also defines GPIO interrupt that is used to detect GPIO events like rising edges.

However, I want to detect rising edge on a pin and I would like to implement the GPIO handler myself rather than using a task and pin.wait_for_rising_edge async method.
Can I somehow redefine or extend the already defined by the crate GPIO interrupt handler? Or can I prevent the crate from defining the GPIO interrupt (maybe disabling the wait_for_rising_edge functionality) while having the async feature enabled (for async I2C to work) ?

Thanks!

[MabezDev]

We currently don't support this and I can't see an easy/non-invasive way of doing it.

Is there a particular reason why you don't want to use the async methods?

[ntqbit]

Is there a particular reason why you don't want to use the async methods?

I suspect that using futures may significantly slow down handling of the GPIO events like rising edges in my high-frequency application. Yet, I don't know if it will be a problem, just a precaution.
If it were possible to define my own GPIO interrupt handler, I would do it.
But since it's not, well.. I'll see if it will work with the async wait_for_rising_edge 😄

Thank you for the response!

[Kixiron]

I've actually hit this limitation for real, I'm writing an application on the esp32h2 that uses a KY-040 rotary encoder with interrupt based handling and the default GPIO interrupt handler drops/deduplicates interrupts which causes it to break without a way of redefining/extending the GPIO handler

[MabezDev]

This would be a valid use case. Long term we need a solution for this. The embassy project treats interrupts as resources and requires that drivers "take" the interrupt in their constructors. I do like this idea generally, but I'm not a huge fan of the macros accompanying it.

With all that said, you're in luck :). The esp32h2 has a PCNT peripheral, with the express purpose of being used with rotary encoders. We don't yet have an async driver for this peripheral yet, but if you can use it with manual interrupts for now. Checkout the example.

[matheo-lucak]

Hello,

I want to share an example I'm facing where multiple interrupts handlers are important.

I'm using embassy to do some fancy async stuff, with async embedded_hal feature to benefit from embedded_hal_async::digital::Wait trait.
In the project, I'm using an ultrasonic sensor (hcsr04).
In a first time, I implemented the driver myself with async functionalities :

    async fn wait_for_echo(&mut self) -> Duration {
        let _ = self.pin_echo.wait_for_high().await;
        let before = Instant::now();
        let _ = self.pin_echo.wait_for_low().await;
        Instant::now() - before
    }

The duration returned by this function will be used to compute the distance the sensors reports. This is very time sensitive.

But by using awaits, the embassy overhead takes some times to give back the code to execution which causes from 35us to +200us of overhead delay, which really affect the sensor precision. (With only one async task running)

The solution would be to stop using async awaits here and directly do the computations in the GPIO interrupt.

But I get to the same problem you had.
Multiple handlers for Interrupts could be a really great features !

Also, I'm didn't find any other HAL implementation with multiple Interrupts handlers. Is there a reason why ?

Thanks for all your work ! 💚

[bjoernQ]

@matheo-lucak While it wouldn't solve the original problem of having your own interrupt handler and using async for other peripherals you could try to use the RMT peripheral in this case for more accurate measurements

[jessebraham]

@Kixiron @matheo-lucak FYI I've created an issue to discuss potential solutions: #1063