The networking and async I/O support in embedded rust is slowly getting better. For that support to be accessible in RTIC, I think it would make sense to allow the idle task to be async.
e.g.
#[idle]
async fn idle(cx: idle::Context) {
...
}The regular idle would still work of course, but when the function is prefixed with async, it's allowed to return (and would return an impl Future<Output = ()>).
Users can already run an executor in the idle task of course, but having an executor built into RTIC would let it do smart things by default, like wfi when the future isn't running.
Future Possibilities
This could eventually be extended to allow for all tasks to be async, but idle seems like a safe bet first.
The networking and async I/O support in embedded rust is slowly getting better. For that support to be accessible in RTIC, I think it would make sense to allow the
idletask to beasync.e.g.
The regular
idlewould still work of course, but when the function is prefixed withasync, it's allowed to return (and would return animpl Future<Output = ()>).Users can already run an executor in the
idletask of course, but having an executor built into RTIC would let it do smart things by default, likewfiwhen the future isn't running.Future Possibilities
This could eventually be extended to allow for all tasks to be async, but
idleseems like a safe bet first.