Lessons from Porting a Crate to Embedded

I ported range-set-blaze to embedded (after porting to WASM). Here are some "findings":

The Good:

  • "If it compiles, it works” works (unlike with WASM).

  • Many items removed by no_std are available via core and alloc.

  • With QEMU, you can develop for embedded systems without hardware.

The Bad:

  • #[test] doesn't run tests on embedded. Instead, I created a new subproject and wrote a few tests.

  • Finding no_std-compatible dependencies can be challenging but cargo tree helps.

For a full writeup (including setting up tests via emulation and other tips) see 9 Rules for Running Rust on Embedded Systems.

Overall, I've found using Rust with embedded fun and have used it in several microcontroller projects.

Is there a better way test embedded Rust?

2 Likes

I think you could do something like:

#![cfg_attr(not(test), no_std)]

To make unit tests modules work. And of course integration tests should always be working because they're already a separate crate.

1 Like

Sorry, I was unclear. I should have said "#[test] doesn't run tests on embedded.". (fixed). The tests run fine on my native OS (and WASM WASI and [with a little work] WASM in the Browser.) Folks have suggested I use defmt-test, but I can't figure out if it works with QEMU emulation.

1 Like