The Embedded Working Group Newsletter - 15

This is the fifteenth newsletter of the Embedded WG where we highlight new progress, celebrate cool projects, thank the community, and advertise projects that need help!

Discuss on users.rust-lang.org, on twitter, or on reddit!

If you want to mention something in the next newsletter, send us a pull request!

Embedded at Rust All Hands 2019

Some members of the Embedded Working Group attended the Rust All Hands two weeks ago. There they had the chance to discuss the needs of the embedded community (as identified in this survey) with the different Rust teams and other WGs. Here's a summary of what was discussed:

The ability to parameterize over values, for example you could use this feature to write a fixed capacity Vec: struct Vec<T, const N: usize> { buffer: [T; N], len: usize }. There are a few compiler refactors going on that are required to land this in nightly so the status is "WIP". We'll have future meetings with the compiler team to try to identify and prioritize the parts of the feature that embedded developers need.

For example, impl<T> Struct<T> where T: Trait { pub const fn new() -> Self { .. } }. A lengthy pre-RFC discussion has concluded and a proper RFC has been proposed.

The plan is to stabilize a minimal, uncontroversial subset of the API to make this available on stable ASAP.

It's not possible to move std::io::{Read,Write} into alloc or core because the API depends on OS specific bits (e.g. last_os_error). An option may be to add a new set of Read / Write traits to core, maybe with associated error types, and then try to bridge these to std::io::{Read,Write} using blanket implementations / super traits, but this needs more research.

This bug breaks no_std builds that use build scripts unless the authors of the build dependencies are aware of the issue and actively work around it. The Cargo team is well aware of the problem. Unfortunately, it's hard to fix and the fix will likely be opt-in because it changes the current semantics.

This feature lets you optimize dependencies when using the dev profile; useful to keep dev binaries small enough to fit in Flash without sacrificing all debuggability. A new build profile will be added to cover the configuration of proc macros, build scripts, compiler plugins and their dependencies. The new profile solves the remaining unresolved question around RFC 2282.

This module contains functions for instructions like wfi and nop, and SIMD instructions; stabilizing this removes the pressure for stable inline assembly (asm!). A member of the libs team is interested in this and will help us push it towards the finish line. A PR in this space has recently landed.

We understood that there are still several design / implementation issues that need to be discussed before this is stabilized, but in the meantime you can use the perma-unstable -Z unleash-the-miri-inside-of-you flag to do all sort of stuff in const context.

@jamesmunns has written a pre-rfc for an incremental implementation of this feature based on our discussions with people from the libs and Cargo teams and the WASM WG.

The backend supports searching within a category (like the no_std category) but there's no UI for it right now. This and fixing a bug where searches only return items found until a exact match was found (instead of returning all relevant matches) are in the crates.io team TODO list.

Ideally, this should be fixed in LLVM proper but it's hard to fix. It's possible to fix this in rustc but the fix is likely to regress the performance of loops. The compiler team will follow up with two unstable flags to evaluate the (performance) impact of fixing this. The first flag applies the fix to only loops in return position of divergent function and the second flag applies the fix to all loops.

That is 0f32.sin() should "Just Work" in no_std crates. There are a few questions about how to best implement this without degrading performance of applications that link to std (we want those to use the arch optimized routines in e.g. glibc's libm instead of the generic Rust implementation) and we need a champion to do the research.

This refers to the ability to run custom code after cargo build. We covered use cases, their requirements and discussed the trade-offs of a more general Cargo tasks (e.g. cargo $task) mechanism vs a more targeted post-build script (e.g. post-build.rs) mechanism. Expect more news (a (pre-)RFC) from the WASM WG on this front.

The current implementation of core::fmt uses trait objects and function pointers to make all uses of core::fmt fast to compile but this makes core::fmt impossible to inline which makes no_std programs that use formatting large in (binary) size. It might be possible to leverage std-aware Cargo to fix this: we could add a Cargo feature to core to replace the current implementation with one that's fully inlineable but as featureful as the current one -- this should produce smaller binaries.

For a bit more of detail you can check the logs and minutes from two meetings ago; they include our notes from the All Hands

Highlights

Embedded Projects

If you have an embedded project or blog post you would like to have featured in the Embedded WG Newsletter, make sure to add it to the next newsletter, we would love to show it off!

embedded-hal Ecosystem Crates

As part of the Weekly Driver Initiative, crates that are part of the embedded-hal ecosystem are now tracked in the Awesome Embedded Rust repository. Here is a current snapshot of what is available there:

Type Status Count Diff
Device Crates released 16 0
HAL Impl Crates released 15 +2
Board Support Crates released 13 +2
Driver Crates Released released 19 +3
Driver Crates WIP WIP 59 +13
no-std crates released 23 +6