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 :+1: 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 (https://github.com/rust-lang-nursery/stdsimd/pull/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).

[eldruin]

Category: Bug fix Request: Fix https://github.com/rust-lang/rust/issues/42863 - "Generic associated consts can't currently be used to parameterize fixed array lengths"

Rationale: In drivers that support several devices, it would simplify the code to be able to define generic associated constants for things like buffer sizes and use them to create fixed-size arrays for data transfer, for example.

[japaric]

Category: Feature

Request: std-aware Cargo / Xargo in Cargo

Rationale:

• with this feature people would be able to build no_std programs for custom targets, targets for which there is no rust-std component, using Cargo. The most prominent custom targets are consoles: Nintendo DS, GBA, PS2, etc. The workaround is to use a Cargo wrapper like Xargo or cargo-xbuild but these will always require nightly.

• this would also let people recompile core / std with different compilation settings, for example using -C opt-level=s instead of the default -C opt-level=3

This is planned work for the Cargo team so I mainly want to gauge interest and check how important is it for you to get this stabilized in 2019. Please vote with a :+1: if this would be great to have available in nightly, OR with a :tada: if it's vital for you to have this working on stable.

[japaric]

Category: Std

Request: math support in core

Rationale: there's nothing OS specific about math libraries. x.tan() should Just Work in no_std context. There are no_std libraries that provide math support but having this in core and maintained by the Rust team means that we can freely use unstable features like inline assembly end SIMD to make the implementations as performant as possible.

[DrSensor]

Category: Resources

Request: Table/List of comparison/example between embedded_hal API vs Arduino API

Rationale: This will help in teaching newcomer about embedded rust. Especially the one who doesn't have experience in firmware programming. Also, it makes it easier for someone to port some of Arduino libraries into rust drivers.

[ramn]

Category: feature Request: Support for AVR Rationale: There are many Arduinos lying around. Would be nice to rust them up!

[dapperfu]

• Category: feature
• Request: Functional Safety Certification, examples:
  • US RTCA DO-178C North American Avionics Software
  • US RTCA DO-254 North American Avionics Hardware
  • [EUROCAE ED-12B European Airborne Flight Safety Systems]()
  • IEC 62304 - Medical Device Software
  • IEC 62061, Safety of machinery - Functional safety of safety-related electrical
  • ISO 25119 - Tractors and Machinery for Agriculture and Forestry -- Safety-Related Parts of Control Systems
  • ISO 26262 - Road Vehicles Functional Safety
• Rationale: People Dying = Bad.

[dapperfu]

• Category: feature
• Request: PowerPC e200 core compiler support. The NXP MPC5748G and MPC5744P are ASIL-B and ASIL-D certified chips, respectively. They feature various e200 cores. NXP also has 2 'inexpensive' (relatively speaking) development boards for each of the chips:
  • DEVKIT-MPC5748G - Ultra-Reliable MCUs for Automotive & Industrial Control and Gateway
  • DEVKIT-MPC5744P - dual e200z4 lockstep cores, motor control, safety, and communication interfaces to facilitate a complete safety/chassis solution.
• Rationale: Offering a 'clean' break from existing compilers would lower the barrier of entry for people wanting to start developing for functional safety. Currently NXP has released an e200 GCC port based on GCC 4.9.4. The other options are WindRiver diab ($$) and Green Hills Software compilers ($$$$).

[Sh4rK]

Category: stabilization Request: Stabilize async/await (and all needed underlying machinery). Rationale: It's great that embedded-hal supports async via the nb crate, but if I'm not mistaken, most drivers and user code use the blocking interface. It would be great if they could transition to being asynchronous, to be used in a multitasking system.

[Sh4rK]

Category: crate Request: A task scheduler. Rationale: Once we have async support (https://github.com/rust-embedded/wg/issues/256#issuecomment-438929923), we should have a task scheduler that makes it possible to write multi-tasked embedded programs. In this context what I mean by a task would probably be a Future from the core library. I'm not exactly sure on the specifics, but I'm thinking something like rtfm (compile-time guarantee of safe and efficient access to shared resources), but with the priorities assigned to tasks (Futures), instead of specific interrupts. A possible option is to actually implement this in rtfm itself.

(Side note: I would probably be able to help writing this.)

[paoloteti]

Category: feature

Request: Add support for Cortex-R52

Rationale: One of the most advanced real-time embedded CPU out there. As the first Armv8-R processor, Cortex-R52 introduces support for an hypervisor. It is part of the NXP S32 automotive platform.

[grossws]

Category: stabilization

Request: stabilize alloc-related functional (alloc and allocator_api), see RFC 1398 and related issues/rfcs

Rationale: It would allow to use dynamic heap-allocated structures on stable

[jacobrosenthal]

Category: resources

Request: are-we-no-std-yet style community push

Rationale: push no_std amongst important libraries and a guide to helping library authors avoid std stuff they may not need, feature gate stuff they do

[geomatsi]

Category: resources

Request: Improve documentation needed to start experimenting with Rust on AVR, MSP430, RISC-V

Rationale: The more people start to experiment with those platforms the better - more testing, more drivers, etc. Using Rust on cortex-m chips has been greatly simplified and streamlined during this year. Other mcu platforms are not yet there and have a more steep learning curve now. It would be great to have introductory documents for some available development boards (LaunchPads, Arduinos) explaining how to get started with Rust on those boards: how to prepare environment (Xargo/Cargo), maintained crates (HAL, drivers, etc), troubleshooting (e.g. where to post LLVM issues), and so on.

[therealprof]

Category: resources

Request: Improve crates.io or create separate site for no_std crates

Rationale: It is still very hard to find suitable crates for no_std development on crates.io since searching for keywords is hit and miss and it's not possible to include/exclude categories.

[therealprof]

Category: resources

Request: Create site listing all available embedded-hal implementations with supported MCUs and peripherals

Rationale: We now have a sizeable amount of HAL impls with widely varying support of various peripherals and some even supporting multiple MCUs. It would be nice to have an overview of what's already supported (to help selecting a suitable MCU) or where a hand is needed to improve support.

[therealprof]

Category: feature

Request: Language support for types with storage size of less than 1 byte

Rationale: Currently in Rust the smallest available non-ZST is 1 byte which means that arrays of bool or small but non-ZST types in structs will require more room than in other languages and reduce interface compatibility. It also requires PACs to emulate access to specific parts of a memory mapped register thereby massively inflating source code size and compile times and reducing readability. There's some RFC in the works already but that could use some more love: https://github.com/rust-lang/rfcs/pull/2581

[ketsuban]

Category: Feature

Request: Add a32 and t32 features to target_feature on ARM targets, mapping to the LLVM features -thumb-mode and +thumb-mode

Rationale: On the Game Boy Advance while most code uses the Thumb ISA for performance reasons (the cartridge is on a sixteen-bit bus, so ARM instructions incur a penalty) some things (e.g. an interrupt dispatch function, should you choose to provide one) need to be ARM. It would be desirable to write these function in Rust code rather than raw assembly, but thumb-mode is not currently whitelisted for target_feature. I initially suggested #[arm]/#[thumb] function attributes, but it was pointed out to me that target_feature features no longer have to map simply onto LLVM ones.

[TotalKrill]

Category: Resources

Request: Recommended/Supported/Blessed way of doing unit or integration tests on Embedded systems.

Rationale: Bringing modern, well tested development methods to the embedded space would benefit us all. I saw no mention of this in the Embedded book. Embedded testing also differs from regular unit testing since it most often will include hardware in the loop.

[korken89]

Category: bug fix

Request: Fix so infinite loops (loop {}) does not need an atomic compiler fence to not be optimized into an abort instruction

Rationale: This is very un-intuitive for a C/C++ user coming to Rust and should not happen. This was under discussion before, but I am not able to find the related issue, maybe someone knows which one it was?

[roblabla]

@korken89 https://github.com/rust-lang/rust/issues/28728?

[adamgreig]

I have added all requests up to this point to the issue description.

[roblabla]

Category: Std

Request: std::io in libcore/liballoc

Rationale: Most of std::io is fully platform independent (The traits and Cursor), and are very very useful abstractions to use. Many crates rely on std::io::Cursor to parse byte arrays, but don't otherwise rely on the platform-specific bits.

[albertmoravec]

Category: resources

Request: Complete usage examples for each trait in embedded-hal

Rationale: Currently it is quite hard to find resources on the embedded-hal crate usage, because the examples and implementation details are scattered between embedded-hal, stm32f30x-hal (or any other implementation crate) and the f3 where the usage examples are present. It would be better to have all the necessary stuff for beginners in one place so it's easy to pick up.

[Lokathor]

Category: feature

Request: 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.

Rationale: there are often known limits of input (eg "must be non zero", "must be less than 32", etc) that we would like to codify into our const functions and have work smoothly regardless of if the function is used at compile time or run time. Currently you cannot use if in a const context, so you cannot assert. There is the static assertions crate, but that only works in a compilation context, it doesn't also work at runtime. Of course, increasing what can be done with const fn is already on the general Rust roadmap; I suppose I'm just advocating that the wg help speed this particular element along if possible.

[japaric]

I have added all requests up to this point to the issue description.

I have also created a new category: "Std" for addition and changes to any of the crates that are part of the standard library, i.e. core, alloc, compiler-builtins, etc. I have moved the two "unsorted" requests into this category; I have also moved "std::io in libcore/liballoc" into this new category.

[japaric]

Category: feature

Request: more control over loop unrolling (See #pragma unroll and -funroll-loops)

Rationale: LLVM does aggressive loop unrolling when opt-level is equal or greater than 2. On Cortex-M loop unrolling can speed up some routines by a factor of 2 at the cost of hundreds of extra bytes of .text (Flash). For devices with limited amount of Flash one would like to avoid loop unrolling; currently the only choice is to optimize for size (opt-level={s,z}) but this penalizes other optimizations due to their lower inline threshold. With more compiler knobs for loop unrolling it would be possible to use opt-level=3 while globally disabling loop unrolling and manually enabling it for loops where the speed - binary size tradeoff is worthwhile.

[japaric]

Category: feature

Request: ship GDB compiled with --enable-targets=all with the toolchain

Rationale: To debug a remote target one usually needs to install an extra GDB that understands the target architecture (e.g. arm-none-eabi-gdb). By shipping a GDB with multi-arch support with the toolchain installing a single GDB that supports the host (x86_64), ARM and other architectures would be as simple as running rustup component add rust-gdb.

[puzrin]

Category: crates

Request: GUI with desktop simulation support

Rationale: Device interface development may be the most time consuming process. In the same time, the most of things can be quickly prototyped on PC, without hardware. Need something like littlevgl.

[daxpedda]

Category: feature

Request: Support defining enabled and disabled lints in a configuration file (https://github.com/rust-lang/cargo/issues/5034, https://github.com/rust-lang/cargo/pull/5728)

Rationale:

Currently project-wide lint configuration needs to be included in the crate sources. This is okay when the project consists of a single crate, but gets more cumbersome when the project is a workspace with dozen crates.

Being able to define the lints in an external file that will be used when building the crates would have several benefits:

• Sharing one configuration file for all the crates in a workspace.
• A canonical place to check for lint configuration when contributing to a new project.
• An easy way to examine the version history for lint changes.

[little-arhat]

@albru123

"Complete usage examples for each trait in embedded-hal" -- indeed!

We have number of examples in the our proving-ground repo, but it would be nice to have smth standard.

[eldruin]

Category: bug fix

Request: Fix https://github.com/rust-lang/rust/issues/54973

Rationale: This bug is the reason why the ADC trait API in embedded-hal is not as nice as it could be. See here

cc @thenewwazoo

[ghost]

Catergory resources

Request add end to end workflow for popular microcontroller such as arduinos

Rationale

• [ ] a JTAG like debugger experience, preferably by using another Arduino? I've seen sth. like this being done but can not do it yet but this is really important, in the end gdb should be attached to the real hardware
• [ ] just basic instructions everyone can follow and have a blinking LED at the end
  • [ ] installing the right rust component
  • [ ] setting up ports on the pc
  • [ ] compiling
  • [ ] uploading
• [ ] if Arduino is not possible due to llvm issues choose another very popular microcontrollers but Arduinos are the elegant in the room for enthusiasts

[TeXitoi]

@monouser7dig https://github.com/TeXitoi/blue-pill-quickstart should almost satisfy your request, except that it's not an arduino. This dev board is compatible with the arduino SDK.

[ghost]

@TeXitoi yes correct that looks about what I want just for more boards, thanks 👍

[Lokathor]

Category: feature

Request: UnsafeDeref trait

Rationale: Sometimes you have a raw pointer (people often ask me why, doesn't matter why) and you need to access a field on a struct, (*p).f But sometimes that field is itself leading to another field, (*(*p).f).z and as you can see it gets horribly ugly very quickly. All I want is the ability to write p.f within an unsafe block and have it do the right thing.

[sajattack]

Category: ~std~ feature (recategorized by @japaric)

Request: Ability to define a fmt_implementation, similar to a panic_implementation

Rationale: We could provide an implementation that does nothing, saving large amounts of binary size when including crates or other parts of std that use fmt::Debug or fmt::Display by default.

https://github.com/rust-embedded/wg/issues/247

[jamwaffles]

Category: std

Request: Ability to use format!() in non-std (embedded) contexts

Rationale: embedded-graphics and other libraries that require input/output of formatted text would benefit greatly from the ability for either library code or application code to use format!(). For example, printing an accelerometer value to an OLED display using display.draw(Font6x7::render_str(format!("Temp: {}", the_temp));.

[Lokathor]

Isn't that just the write! macro? format! produces a String, which needs an allocation.