Hacker News Reader

Comment by tadfisher | Hacker News Reader

There's also the simplicity of bare embedded in Rust, because you can mostly[1] use Cargo, depend on the right embedded_hal crates for your target, and be up and running with a hardware-backed async runtime and everything. Zephyr, Tock, Mynewt, etc. all have bespoke build/deployment systems and driver ecosystems. That said, RTOS makes actually deploying working products much more realizable, so pick your poison.

1: I think you still need xargo/cargo-xbuild for no-std embedded sysroots, but there may have been some upstream development on that front since I last played in this sandbox.

View on HN

Embedded-HAL is interesting to me - in principle it's a great concept; writing hardware-agnostic, portable code.

I don't use it in my firmwares because:

  - All of the embedded-HAL libs I've found (eg drivers) have had notable limitations or ergonomics problems.
  - It appears unsuitable for use with DMA, which I use for all runtime IO
  - The APIs tend to be a mess due to heavy use of typestates

> It appears unsuitable for use with DMA, which I use for all runtime IO

The `embedded-hal-async` traits can be implemented with DMA, the Embassy HALs do so. This is a problem with the `nb` traits only.

> The APIs tend to be a mess due to heavy use of typestates

This is an issue of some HAL crates implementing the traits, not with the `embedded-hal` traits themselves. I also dislike the heavy use of typestates/generics, Embassy tries to implement the traits while keeping typestates at a minimum.

(disclaimer: Embassy maintainer here)

Building core/std/whatever using unstable flags and --target works for me these days. I can do everything with cargo and make it even more ergonomic with a toolchain file.

Now if Cargo had a way of producing multiple variants of the same project (e.g. different --targets with pre-set features) just with `cargo build` then things would be a lot better.

As of now, a Makefile is still needed to bring it all together.

We were using cargo-make for something like this, though eventually we switched to using Cargo's experimental support for artifact dependencies: https://doc.rust-lang.org/nightly/cargo/reference/unstable.h...

> I think you still need xargo/cargo-xbuild for no-std embedded sysroots, but there may have been some upstream development on that front since I last played in this sandbox.

Cargo's build-std flag is the bespoke way now. Unstable, but working it's way to stable. AFAIK cargo/build aren't getting any more development in lieu of build-std.

That's good to hear, I've used that in the past to drive down codesize even on non embedded targets by compiling for size and rebuilding the stdlib.

> you can mostly[1] use Cargo, depend on the right embedded_hal crates for your target, and be up and running with a hardware-backed async runtime and everything

Can one use Rust's embedded_hal from a different programming language?

IIUC you can make some api in rust that uses the HAL, which ties your code into board specific stuff.

That api you write can be exposed via C abi so you can link C or languages that have an FFI to C to the rust code. https://docs.rust-embedded.org/book/interoperability/rust-wi...

You call this ugly ass mess of a code simple? yeah right!

Reply on news.ycombinator.com