Async: GPIO

[MabezDev]

• Upgrade to new eha
• Implement Wait for GpioPin
• Add an example for C3

TODO

• Add examples for all chips
• Make the interrupt handler cleaner by being able to conjure a pin type

Blocked on

• We need impl_trait_projections compiler feature to be available in the Xtensa fork (26th of Jan )
• GPIO incorrect interrupt status for pins > 32 #332

future work (probably not going in this PR)

• Adding support for multi-core chips that have interrupt registration per core.

[bjoernQ]

LGTM

Only nit-pick is, there is no explanation of what to expect from the example - we have that for most examples - but not the end of the world and shouldn't keep us from merging

[MabezDev]

Good point, I added them for both this example and the embassy hello world :)

[MabezDev]

Btw what should we do about MSRV? 1.67 is only needed for async?

[bjoernQ]

Btw what should we do about MSRV? 1.67 is only needed for async?

Maybe we can keep 1.65 and just say for async it's 1.67 I think I have seen that for other crates, too

[jessebraham]

LGTM!

RE the MSRV, I think what @bjoernQ said is probably best, keep it as-is but mention that for async specifically it's 1.67. Once we've had another toolchain release or two we can re-visit this if needed.

[bugadani]

@MabezDev I'm not entirely sure but I think that set_int_enable does not implicitly clear interrupt status bits, it is possible for an edge-triggered listener to wake a task twice (in this call, and at a later GPIO interrupt request).

I think it is also possible that we lose GPIO interrupt requests here, because read and clear are not atomic. Probably only those bits should be cleared here that are set in intrs.

[MabezDev]

I don't quite understand your first point, but I do agree that we should only clear the interrupts read from the status inside the GPIO interrupt handler.

[bugadani]

I am in the process of opening an issue with more data that confirms my suspicions: level-triggered interrupts fire multiple times, it looks like. But I might just have incorrect assumptions here, we'll see :)