What does HackerNews think of embassy?

Modern embedded framework, using Rust and async.

Language: Rust

#4 in Java
#55 in Rust
At work, we have a non-async RTOS 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/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://github.com/embassy-rs/embassy (this one is used in the article)

* https://tockos.org/

> others are just batshit-crazy from my pov (the macro system for instance)

Ah yes, I won't disagree here; macros get very complex very fast. It's one of the more undercooked parts of Rust.

> e.g. I don't really see the usefulness of async-await in a systems programming language

This really depends on the task, but honestly it is genuinely useful. Even in places you wouldn't expect, e.g. in embedded: https://github.com/embassy-rs/embassy

And AFAIK there are plans to use async Rust in the Linux kernel.

A project as large and well funded as the Linux kernel could have a hardware test farm at least with reasonable coverage of popular hardware. "But Linux isn't that well funded!" Sure, but it's orders of magnitude better funded than Embassy[0], which runs tests on real hardware automatically before every merge.

There's also the Linux testing project, which is technically third party. It's not clear to me how extensive it is but for a project as important as Linux I think it has to be graded as "needs improvement."

[0] https://github.com/embassy-rs/embassy

[1] https://linux-test-project.github.io/

You might want to take a look at the embassy project for a unified stm32 HAL. The idea is that it defines the APIs per peripheral version as defined by STM (spi v1, spi v2, usart v1 etc). The advantage is that a given peripheral can be used across all stm32 families with that version. This makes maintaining a HAL and keeping a unified API much simpler.

The other part is the stm32-metapac (not specific to async) that generates the PAC for any stm32 chip.

Read more about embassy here: https://github.com/embassy-rs/embassy

I guess when mentioning Rust on Nordic controllers one should also mention these excellent projects

https://github.com/embassy-rs/embassy https://github.com/embassy-rs/nrf-softdevice

Together with https://github.com/nrf-rs/nrf-hal these enable most everything one can do on these controllers form pure Rust (the softdevice is a blob with a C-SDK that's wrapped in rust though)

There is an executor project: https://github.com/embassy-rs/embassy

I'm very excited about this for one simple stupid reason: sleep(). Awaiting a timer delay deep inside some code is gonna be amazing. With typical sync code, you basically have to split your code and queue up the next work somewhere that would be picked up by the timer interrupt… basically doing the whole state-keeping that async would do for you.

For embedded async executors check out Embassy. It works well and is under active development.

https://github.com/embassy-rs/embassy