4 ms·

Most of my programming these days is on Cortex-M, using Rust. The article is another prior in my suspicion that Async embedded Rust is designed with toy use cas

Most of my programming these days is on Cortex-M, using Rust. The article is another prior in my suspicion that Async embedded Rust is designed with toy use cases in mind (blinky); I don't know how it would work in practical firemware because I haven't seen examples. Another possibility is that my brain and learning patterns don't work well with Async. I have a hard time understanding it, and it feels like a layer of obfuscation or misdirection. It's an abstraction that may be more suitable for other learning styles, or different program structures or requirements than the ones I've worked on. I'd love to see an RTOS for Rust, but am worried it will be Async. (I am referring to the Async/Await pattern; not asynchronous programming or concurrency)

steveklabnik 3y ago
At work, we have a non-async RTOS https://hubris.oxide.computer/ https://hubris.oxide.computer/ though it is a bit harder to use than "add a dependency in Cargo.toml" like most projects. The original designer of Hubris, Cliff, has his own async RTOS that he uses for personal projects. He recently has been writing some blog posts on this that may be of interest to you: * http://cliffle.com/blog/async-inversion/ http://cliffle.com/blog/async-inversion/ * http://cliffle.com/blog/composed-concurrency-in-drivers/ http://cliffle.com/blog/composed-concurrency-in-drivers/ The former is a general introduction to async, and the second is about applying it to write an I2C driver. There already are some general RTOSes for Rust, and they do tend to use async: * https://rtic.rs/2/book/en/ https://rtic.rs/2/book/en/ * https://github.com/embassy-rs/embassy https://github.com/embassy-rs/embassy (this one is used in the article) * https://tockos.org/ https://tockos.org/
- the__alchemist 3y ago
  Cliff's articles are outstanding! Re Rtic: I'm using the V1 of it, which is non-Async; it seems to offer smarter locking than using critical sections + Mutex, since it's capable of interrupting a lower-priority task with a higher one, depending on which resources are locked.
KingLancelot 3y ago
[dead]
sebastiandb 3y ago
This article about async in Python helped me understand it pretty well, since it explains them in terms of coroutines, which are very intuitive for me: https://mleue.com/posts/yield-to-async-await/ https://mleue.com/posts/yield-to-async-await/ Another thing that helps me get it is comparing it to the continuation passing style, where you never return from a function, you just take an argument that's basically a function pointer bound to an environment, and at the end of the function, instead of returning, you call your input function, giving it another function and environment as input, repeating the cycle. It's very similar to the transformation of callbacks within callbacks within callbacks pattern in JavaScript to the async/await pattern.
- jayd16 3y ago
  Once you realize async/await is just sugar over the familiar callback hell, a lot of the mystery fades away and it's easier to groc.
  - afavour 3y ago
    That’s true in JS but less so in a language like Rust where there are threading implications.
    - jayd16 3y ago
      I'm not as familiar with Rusts's implementation but even in C# it's mostly true. Threads are only hit when a callback is not directly awaited. There's more to it but it starts you down the right path, I think.
    - littlestymaar 3y ago
      There are no threading implications to async in Rust. The executor you're using may add some requirements on your futures because it wants to run them on multiple threads[1], but that's not related to async itself, and you can always use a single threaded executor if you don't want these limitations (and they doesn't apply to embeded anyway). [1] namely, your futures will need to be Send + 'static.
  - 3y ago
davidhyde 3y ago
RTIC (Real Time Interrupt-driven Concurrency) is an RTOS written in Rust with specific hardware acceleration for Cortex-M devices. Well, depending on what your definition of an RTOS really is. If you don't like async then its a pretty good bet to get concurrency working on an Arm Cortex-M microcontroller. https://rtic.rs/1/book/en/preface.html https://rtic.rs/1/book/en/preface.html
dirbaio 3y ago
Async Rust does definitely work for non-toy use cases. As a data point, we use Embassy for all production firmware at my startup (https://akiles.app/en https://akiles.app/en), using async tasks for everything: Bluetooth, TCP/IP networking, motor control, user interface (LEDs, keypad), a key-value database in flash, stats collection... Async helps with battery life too since it allows putting the core to sleep when no task has work to do, it allows us to build devices with 1-2 years of battery life. There's other companies using Embassy in production. Sadly firmwares are usually not open source. There's a few non-toy open-source projects using Embassy though: - https://github.com/nviennot/turbo-resin https://github.com/nviennot/turbo-resin - https://github.com/ivmarkov/ruwm https://github.com/ivmarkov/ruwm - https://github.com/dkhayes117/propane-monitor-embassy https://github.com/dkhayes117/propane-monitor-embassy (disclaimer: Embassy maintainer, Akiles CTO here)

steveklabnik 3y ago

At work, we have a non-async RTOS https://hubris.oxide.computer/ https://hubris.oxide.computer/ though it is a bit harder to use than "add a dependency in Cargo.toml" like most projects. The original designer of Hubris, Cliff, has his own async RTOS that he uses for personal projects. He recently has been writing some blog posts on this that may be of interest to you: * http://cliffle.com/blog/async-inversion/ http://cliffle.com/blog/async-inversion/ * http://cliffle.com/blog/composed-concurrency-in-drivers/ http://cliffle.com/blog/composed-concurrency-in-drivers/ The former is a general introduction to async, and the second is about applying it to write an I2C driver. There already are some general RTOSes for Rust, and they do tend to use async: * https://rtic.rs/2/book/en/ https://rtic.rs/2/book/en/ * https://github.com/embassy-rs/embassy https://github.com/embassy-rs/embassy (this one is used in the article) * https://tockos.org/ https://tockos.org/

the__alchemist 3y ago
Cliff's articles are outstanding! Re Rtic: I'm using the V1 of it, which is non-Async; it seems to offer smarter locking than using critical sections + Mutex, since it's capable of interrupting a lower-priority task with a higher one, depending on which resources are locked.

KingLancelot 3y ago

[dead]

sebastiandb 3y ago

This article about async in Python helped me understand it pretty well, since it explains them in terms of coroutines, which are very intuitive for me: https://mleue.com/posts/yield-to-async-await/ https://mleue.com/posts/yield-to-async-await/ Another thing that helps me get it is comparing it to the continuation passing style, where you never return from a function, you just take an argument that's basically a function pointer bound to an environment, and at the end of the function, instead of returning, you call your input function, giving it another function and environment as input, repeating the cycle. It's very similar to the transformation of callbacks within callbacks within callbacks pattern in JavaScript to the async/await pattern.

jayd16 3y ago
Once you realize async/await is just sugar over the familiar callback hell, a lot of the mystery fades away and it's easier to groc.
- afavour 3y ago
  That’s true in JS but less so in a language like Rust where there are threading implications.
  - jayd16 3y ago
    I'm not as familiar with Rusts's implementation but even in C# it's mostly true. Threads are only hit when a callback is not directly awaited. There's more to it but it starts you down the right path, I think.
  - littlestymaar 3y ago
    There are no threading implications to async in Rust. The executor you're using may add some requirements on your futures because it wants to run them on multiple threads[1], but that's not related to async itself, and you can always use a single threaded executor if you don't want these limitations (and they doesn't apply to embeded anyway). [1] namely, your futures will need to be Send + 'static.
- 3y ago

davidhyde 3y ago

RTIC (Real Time Interrupt-driven Concurrency) is an RTOS written in Rust with specific hardware acceleration for Cortex-M devices. Well, depending on what your definition of an RTOS really is. If you don't like async then its a pretty good bet to get concurrency working on an Arm Cortex-M microcontroller. https://rtic.rs/1/book/en/preface.html https://rtic.rs/1/book/en/preface.html

dirbaio 3y ago

Async Rust does definitely work for non-toy use cases. As a data point, we use Embassy for all production firmware at my startup (https://akiles.app/en https://akiles.app/en), using async tasks for everything: Bluetooth, TCP/IP networking, motor control, user interface (LEDs, keypad), a key-value database in flash, stats collection... Async helps with battery life too since it allows putting the core to sleep when no task has work to do, it allows us to build devices with 1-2 years of battery life. There's other companies using Embassy in production. Sadly firmwares are usually not open source. There's a few non-toy open-source projects using Embassy though: - https://github.com/nviennot/turbo-resin https://github.com/nviennot/turbo-resin - https://github.com/ivmarkov/ruwm https://github.com/ivmarkov/ruwm - https://github.com/dkhayes117/propane-monitor-embassy https://github.com/dkhayes117/propane-monitor-embassy (disclaimer: Embassy maintainer, Akiles CTO here)