On prototyping an async Rust runtime for RIOT

j-devel · 19 September 2023 08:31

Thanks @Kaspar @emmanuelsearch for sharing the latest overview/details on Rust integration efforts for RIOT:

Because we, IETF ANIMA Minerva Project (@mcr @j-devel), have also been working on our custom “cross-board oriented” async Rust runtime for RIOT, we particularly got interested in “Prototype RIOT over async Rust framework” part, which is assuming the Embassy ecosystem [1].

Related to the topic, we would like to share some additional insights that we gained though implementing our version [2] of async Rust runtime for RIOT.

In our case, we didn’t start with the existing 3rd party Embedded Rust components (and having to grapple with complexity for adaptation/integration); rather, we took a minimalistic/bottom-up approach:

port the (bare-metal minimalistic) blog_os async Rust executor [3] to a no_std RIOT-compatible crate [4],
bind existing RIOT C APIs (e.g. timer, gcoap) by Rust-C-FFI,
adapt them as Rust Future/Stream, and
expose them as Rust async function API

what we got working (thus far)

single threaded async Rust runtime (akin to JavaScript runtime), capable of
- spawning Rust Future<Output = ()> instances
- spawning Rust Stream processors (useful for implementing e.g. Rust-based coap servers)
- executing async versions of some RIOT Timer/Gcoap API, e.g.
```
async fn async_sleep(msec: u32)
async fn async_set_timeout<F>(msec: u32, cb: F)
async fn async_gcoap_get(addr: &str, uri: &str) -> Vec<u8>
```

what we learned/proved

binding existing RIOT (networking) C APIs, and then
wrapping/adapting them as Rust Future/Stream works well, hence
CROSS-BOARD (xbd) async abstraction of RIOT API is highly feasible/practical (as opposed to Embassy going “board-specific”)
we are pushing/following this path to build Rust-based MCU client (esp32) to be demonstrated in IETF ANIMA BRSKI interop

[refs]