Provide a higher level interrupt mechanism about esp-hal HOT 10 CLOSED

I think we can close this now, with #118 & #103 being merged. We can explore a closure-based approach in another issue.

from esp-hal.

Originally, I thought of something like this as a separate crate - in any case I'd love to have this opt-in or opt-out since e.g. for esp-wifi I'm not sure if we can do it this way ... but maybe we can ... anyway, would be good to have a choice.

Additionally (not now probably) it would be nice to have some convenience to pass resources into the handlers - not as invasive as RTIC in best case. But haven't thought that through.

Other than that sounds like a good idea

from esp-hal.

Originally, I thought of something like this as a separate crate - in any case I'd love to have this opt-in or opt-out since e.g. for esp-wifi I'm not sure if we can do it this way ... but maybe we can ... anyway, would be good to have a choice.

Because there a predetermined interrupts for WiFi, bluetooth etc? Provided they set a flag in the interrupt status I think we should be okay, as we can add WIFI & BLUETOOTH handlers in our PAC crates, then esp-wifi can use them.

Even if that doesn't work, for Xtensa, there are also predetermined interrupts for CPU timers etc, so we will need to solve this issue anyway. It should be simple enough to have a per chip interrupt mask that will give us the available "free" cpu interrupts for the user to use.

from esp-hal.

By the way, if you enable all interrupts on Xtensa, does your board hang (presumably in the default interrupt handler for some interrupt)? I'd like to track down what these interrupts are, and if we can stop them.

from esp-hal.

Yes it hangs for me, too. I think it's the Xtensa timer interrupts which fire

from esp-hal.

I think you're right, from my testing I believe Interrupt6Timer0Priority1, Interrupt15Timer1Priority3 & Interrupt16Timer2Priority5 are always pending. This is odd, because it should be being disabled at boot: https://github.com/esp-rs/xtensa-lx-rt/blob/455d2b77b8a5724d36db0ea66c88467a4515f376/src/lib.rs#L72

from esp-hal.

Ah! reset_timers function needs be updated, it is only resetting the timers on the esp32...

from esp-hal.

One thing that came to my mind ... not sure if it's a good idea or a terrible one:

What if we make the user's interrupt handlers actual callbacks?

Then users could just take (mutable) reference into a closure without all the static frills.

I played around with that in the ESP32-C3 timer example and it looks quite promising to me. But maybe I overlooked something

Unfortunately, with no-alloc that works fine for Fn and FnMut but not so good for FnOnce

from esp-hal.

We could do this for sure! I think we'll get the pac interrupt version in first, then we can add a separate feature to use closure callbacks.

Then users could just take (mutable) reference into a closure without all the static frills.

Maybe I'm missing something, but wouldn't it have to be an immutable borrow? With some interior mutability via a mutex, because once the call back is set anything borrowed by the closure will be borrowed that whole time?

from esp-hal.

Maybe I'm missing something, but wouldn't it have to be an immutable borrow? With some interior mutability via a mutex, because once the call back is set anything borrowed by the closure will be borrowed that whole time?

Yes, you are right if both sides want to access it - only if no access is needed at the call-site anymore it could be mutable - like in the multicore example:

Moving it would be better but then it would need to be FnOnce

from esp-hal.