Currently all the traits in embedded_hal::digital are blocking GPIO APIs. For most microcontroller firmware this is normally fine since you are just reading some register in the address space to access of set state which is effectively immediate.

However this API falls apart when IO expanders enter the equation. Something like the MCP23017 may need to perform an I2C transaction to get the state of GPIO. Blocking during an I2C transaction can take some time and blocking may be undesirable.

I also am working some firmware that would let you turn an MCU into an I/O expander using postcard. Setting an output pin to a high level would need to transmit a packet over some transport to the target MCU. A workaround would be to queue the operation for sending asynchronously later and return Ok. However the workaround can lead to race conditions if the transport could lose packets in transit. To me it seems less error prone to be able to await a async form of toggle.

embedded_hal_async::digital does exist, but this only contains the Wait trait. This does let you listen for events, but does not let you set output pin state or ask for the current pin state asynchronously. The best way I can think of to make IO expanders act correctly would be to add traits to embedded_hal_async which are async equivalents of the traits under the digital module.

Another concern I have is crates using embedded-hal already depending on types like OutputPin. I don't think it's possible to express a trait bound like implement one of embedded_hal::digital::OutputPin or embedded_hal_async::digital::OutputPin. Even though this could be added without a semver breakage, I imagine the new traits might ripple into a lot of broken downstream crates.