Björn Quentin

IIRC correctly this driver is a bit different than all the others because we want people to easily mix `async` and their own ISR - if we still think this...

These are all very good ideas 👍 However I think the original problem with RTIC is this one: To handle the GPIO interrupt they generate a function `unsafe extern "C"...

I think I would like to have it initialized in `esp_hal::init` given 99.9% of all real-world use-cases will need at least some pins. Users will still need to know when...

> ... have an all or nothing API. Either you have the async API or you can set your handler. Yes - it all boils down to this. Doing that...

Unfortunately, there is no additional documentation about that peripheral that I'm aware of. A few things could be derived from the code but we don't have anything beyond that. For...

Thanks - that's an interesting observation and getting a backtrace is especially useful for WDT interrupts (probably not for other interrupts)

I had a look into this and found where we screw up the stack alignment: https://github.com/esp-rs/esp-hal/blob/8a23dbe1b6e10459e4d7456f2da96b4c406e7740/esp-riscv-rt/src/lib.rs#L724 That needs to get fixed The other thing is that after thinking about it...

There is not really a plan to add it and I personally haven't looked into what it would take to support it. Certainly, community contributions to add it are welcome

Cannot comment on the line: There is the ChannelCreator struct left in `gdma.rs` ``` esp-hal\src\dma\gdma.rs 574:pub struct ChannelCreator {} ```

Side note: The underlying timers probably should wrap modifications on shared registers in a critical-section (#1739 already addresses that for SYSTIMER). That is out of scope for this PR Sorry...