At some point, we'll probably want to do multiple things at once, e.g. listening to a serial port while toggling a GPIO. However, all of the current embedded-hal traits are blocking, and without threads, this would be difficult to multiplex.
We could consider implementing the async embedded hal traits, or doing something non-standard ish (defining our own non-blocking traits).
If we do this, the protocol API (at least on the host side) may need to change slightly, as it currently discards all "unexpected" messages. We might have to also add a "request id" field, that gets included in responses, so if we have two i2c commands in flight at once, the messages are handled in the correct place.
At some point, we'll probably want to do multiple things at once, e.g. listening to a serial port while toggling a GPIO. However, all of the current embedded-hal traits are blocking, and without threads, this would be difficult to multiplex.
We could consider implementing the async embedded hal traits, or doing something non-standard ish (defining our own non-blocking traits).
If we do this, the protocol API (at least on the host side) may need to change slightly, as it currently discards all "unexpected" messages. We might have to also add a "request id" field, that gets included in responses, so if we have two i2c commands in flight at once, the messages are handled in the correct place.