Survey: 2019 wishlist

[japaric]

Hello embedded Rustaceans!

We are collecting a "wishlist" of things you'd like to see done, fixed or
stabilized in 2019. We'll use this data to make a roadmap for 2019, i.e. to set
the goals of the WG for 2019.

You can request anything related to embedded Rust development: language
features, bug fixes, crates, docs, etc. The more requested something is the more
likely it is to make it into the roadmap; of course, other factors will be
considered as well: amount of work required; how beneficial would it be to the
community; does it require a rust-lang/rust RFC? how likely is that RFC to be
accepted?; who has to do the bulk of the work? the embedded community or a Rust
team?; etc.

To keep things tidy let's limit comments to one request per comment. Let's
also avoid "+1" and "I'd like to see that fixed too" comments; instead use a 👍
reaction to vote for a request.

To make our job easier please use the following format:

**Category**: pick one of:

- "feature", for languange and compiler features, e.g. const generics;
- "bug fix", e.g. fix rust-lang/cargo#5730;
- "stabilization", stabilization of standard API and features, e.g. stabilize `MaybeUninit`;
- "std", for addition and changes in any of the standard crates, e.g. add `core::io`;
- "crate", e.g. write / maintain a USB stack;
- "resources", for requesting docs, user guides, cookbooks and the like;
- or leave it empty if it doesn't fit any of the categories above

**Request**: your request in a single sentence

**Rationale**: one paragraph, or several bullets, explaining how this change would
benefit the embedded community

If you'd like to extend the rationale of an already submitted request just make
a new comment referencing the original request. We'll merge your comment into
the request comment. For example:

> **Request**: the sentence that Alice wrote

This would also let us do X and Y, and it would let crate Z compile on stable!

Summary of requests

Stabilization

• Stabilize RFC 2282 - "Cargo profile dependencies" AKA profile-overrides
• Stabilize core::mem::MaybeUninit
• Stabilize const fn-s that have trait bounds, e.g. const fn new() -> Mutex<T> where T: Send.
• thumb intrinsics (#63)
• Stabilize async/await (and all needed underlying machinery).
• stabilize alloc-related functional (alloc and allocator_api)
• complete and stabilize the last bits of procedural macros (macros 1.2): crate level attributes and attributes on modules

Bug fixes

• fix rust-lang/cargo#5730 - "Features of dependencies are enabled if they're enabled in build-dependencies; breaks no_std libs"
• Fix rust-lang/rust#42863 - "Generic associated consts can't currently be used to parameterize fixed array lengths"
• Fix so infinite loops (loop {}) does not need an atomic compiler fence to not be optimized into an abort instruction
• Fix rust-lang/rust#54973

Features

• MIPS intrinsic for mfc0/mtc0
• std-aware Cargo / Xargo in Cargo
• Support for AVR
• Functional Safety Certification
• PowerPC e200 core compiler support
• Add support for Cortex-R52
• Language support for types with storage size of less than 1 byte
• Add a32 and t32 features to target_feature on ARM targets, mapping to the LLVM features -thumb-mode and +thumb-mode
• ability to assert within a const fn context, with a compilation error if the assertion fails at compile time and a panic if the assertion fails at runtime
• more control over loop unrolling (See #pragma unroll and -funroll-loops)
• ship GDB compiled with --enable-targets=all with the toolchain
• Support defining enabled and disabled lints in a configuration file
• UnsafeDeref trait
• Ability to define a fmt_implementation, similar to a panic_implementation
• ability to list/forbid dependencies using unsafe code or which could panic
• bits layout implementation like in Ada
• Make example-dependencies and test-dependencies be split up, instead of having both as dev-dependencies

Std

• math support in core
• Optimise memory routines in compiler-builtins.
• std::io in libcore/liballoc
• Ability to use format!() in non-std (embedded) contexts

Crate

• High quality RTOS bindings
• An easy to use SD/MMC and FAT32 library
• An easy to use USB host library
• An easy to use USB device library
• An easy to use pure-Rust RTOS
• A task scheduler
• GUI with desktop simulation support
• Easy firmware flashing for popular OS-es / SOCs (initially - stlink/DFU for linux/osx/win)
• singleton! and other arch independent APIs in arch independent lib (instead of cortex-m)

Resources

• Table/List of comparison/example between embedded_hal API vs Arduino API
• are-we-no-std-yet style community push
• Improve documentation needed to start experimenting with Rust on AVR, MSP430, RISC-V
• Improve crates.io or create separate site for no_std crates
• Create site listing all available embedded-hal implementations with supported MCUs and peripherals
• Recommended/Supported/Blessed way of doing unit or integration tests on Embedded systems.
• Complete usage examples for each trait in embedded-hal
• add end to end workflow for popular microcontroller such as arduinos
• Guidelines for vendor participation

---

cc @rust-embedded/all please check this thread every now and then and update
the summary section

[japaric]

Category: Stabilization

Request: Stabilize RFC 2282 - "Cargo profile dependencies" AKA profile-overrides

Rationale:

• This feature is used to optimize dependencies when compiling a crate using the dev profile; this produces a small binary that is still somewhat debuggable (print x doesn't always print x = <optimized out>). Without this sometimes dev binaries are too big and won't fit in the target device!

• This is also used to optimize specific crates, like r0, for size and mitigate the "bloat" of aggressive loop unrolling that LLVM does when the release profile (-C opt-level = 3) is used.

[japaric]

Category: Bug fix

Request: fix rust-lang/cargo#5730 - "Features of dependencies are enabled if they're enabled in build-dependencies; breaks no_std libs"

Rationale: this makes some no_std crates unnecessarily hard to use / write. Using a crate, like chrono or rand, which supports both no_std and no-no_std contexts, in a build script or procedural will break the compilation of no_std crates that depend on the build dependency. The workaround is to use the host dependency in no_std mode everywhere, but this makes build scripts and procedural macros harder to write.

[japaric]

Category: Stabilization

Request: Stabilize core::mem::MaybeUninit

Rationale: this is required to make heapless' (*) and similar libraries' const constructors work on stable.

(*) heapless is a widely used library that provides statically allocated, fixed capacity collections (Vec, String, HashMap, etc.).

[japaric]

Category: Stabilization

Request: Stabilize const fn-s that have trait bounds, e.g. const fn new() -> Mutex<T> where T: Send.

Rationale: this is required to make heapless' (*) and similar libraries' const constructors work on stable.

(*) heapless is a widely used library that provides statically allocated, fixed capacity collections (Vec, String, HashMap, etc.).

[Ravenslofty]

Category: "feature"

Request: MIPS intrinsic for mfc0/mtc0

Rationale: Access to the system control coprocessor in MIPS provides access for features ranging from MMU control (for devices that have it) to enabling/disabling interrupts and handling interrupts. This currently requires either external assembly, which is not optimal, or asm! which is highly unstable.

[adamgreig]

Category: Stabilization

Request: thumb intrinsics (#63)

Rationale: many (all?) the intrinsics we want are in stdsimd (rust-lang/stdarch#518) and so available to nightly; it would be great to get them stabilised as well. The last RFC about this (#184) sort of stalled out.

P.S. thanks @ZirconiumX for reminding me!

[Ravenslofty]

Category: Std

Request: Optimise memory routines in compiler-builtins.

Rationale: At the moment the compiler-builtins code is written to be correct and to make it as obvious for LLVM to optimise as possible. However, if LLVM does not have an internal routine to optimise these routines, it will emit the code directly, resulting in things like byte at a time memcpy, which is far from ideal. It's possible to write a 32-bit routine which should be portable to most machines and offer a ~4x speedup.

[adamgreig]

Category: Crate

Request: High quality RTOS bindings

Rationale: Being able to use Rust alongside an existing RTOS (FreeRTOS, ChibiOS, mbed-os, etc) would be really attractive for those already using the RTOS but wanting to start moving to Rust. Ideally in the end we'd have a Rust RTOS anyway (and RTFM provides a really compelling alternative already) but in the immediate future good bindings would be great. There's already work in this direction such as https://github.com/hashmismatch/freertos.rs and https://github.com/thenewwazoo/ChibiOS-rust.

[thejpster]

Category: Crate
Request: An easy to use SD/MMC and FAT32 library

Rationale: Adding SD card support to your embedded project should be as easy as using the Arduino SD library - just depend on the crate and add a on-liner connecting the SD card library to your chip's SPI peripheral. This library should prioritize ease of use over performance (i.e. polling and byte-wise transfers rather than interrupt-driven DMA block transfers), but allow for higher-performance implementations to be plugged in if required, through a generic BlockDevice trait.

[thejpster]

Category: Crate
Request: An easy to use USB host library
Rationale: Adding support for USB thumb drives, keyboards and mice to your embedded project should be as simple as using the Arduino USB Host library.

[thejpster]

Category: Crate
Request: An easy to use USB device library
Rationale: Adding support for emulating a USB keyboard, mice or serial port to your embedded project should be as simple as the two examples above ;)

[thejpster]

Category: Crate
Request: An easy to use pure-Rust RTOS
Rationale: Binding to a pre-existing C based RTOS is non-trivial, as there are things the RTOS does (like memory allocation, or extensive use of #defines) which aren't necessarily a good fit for the Rust model. We should write a pure-Rust version of FreeRTOS, decomposed into re-usable core crates (queues, mutextes/semaphores, tasks, etc), and then microarch-specific implementations (e.g. rustos-queue-cortex-m).