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.).

[ZirconiumX]

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-nursery/stdsimd#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!

[ZirconiumX]

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 rust-lang/rust#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 👍 if this would be great to have available in nightly, OR with a 🎉 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!

[jed-frey]

• 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.

[jed-frey]

• 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 (#256 (comment)), 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.

[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.

[AxFaure]

Category: feature

Request: ability to list/forbid dependencies using unsafe code or which could panic

Rationale: In order to guarantee a minimum level of safety/security in our code, we need to be able to determine to which extent we can trust the libraries we are using. Having the option to forbid unsafe code and/or code that can panic in our crate and in its dependencies would be a huge plus. Since not all unsafe code can be avoided, it could probably be implemented as a whitelist that could be configured in cargo (or maybe as a plugin similar to clippy). A developer could then allow some unsafe dependencies after manually reviewing them. This is probably not specific to the embedded world but there is a lot of embedded software that is critical enough to need this feature. There are some crates like this one https://crates.io/crates/cargo-geiger that can already help but I think more work is needed in this direction

[japaric]

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

[TeXitoi]

The write! macro works on no_std. I can't see how the format! macro can work in a no_std context.

[puzrin]

Category: crates (?)

Request: Easy firmware flashing for popular OS-es / SOCs (initially - stlink/DFU for linux/osx/win).

Rationale: Original issue is now in book repo. But since it can not be resolved by documentation only, i think it worth place it here.

Let's imagine, you developed great OSS hardware, and users wish to repeat it or join to further development. Then it's critical to resolve 2 use cases:

• Users (non programmers) should be able flash firmware without reading docs at all. They just need big button "do everything perfect" :)
• The same for potential collaborators. When people wish to help you - no need to waste their time for automate-able things.

Example. Right now, with C and PlatformIO i can give very simple instructions:

1. Install vscode, open project and wait until it downloads all necessary tools for your OS.
2. Attach programmer and select "upload" from menu.

I understand, this problem is not Rust-specific. But since Rust plans to be awesome for embedded, it's important to be awesome about firmware upload too.

[aurabindo]

Category: Resources/None

Request: Guidelines for vendor participation

Rationale: If there is an official point of contact and established procedure for vendors to submit drivers for their devices, ecosystem will flourish. I'm proposing a model equivalent to the one followed by Linux. Vendor or independent contributors submits code, gets scrutinized in the public, and gets accepted into an official source controlled by the WG. Advantages:

1. Ecosystem will have high quality code, and it becomes easy for a starter to look up the current state. With no/few officially endorsed crates (device specific hal implementations), users will have to do more research to find the optimal solution.
2. More vendor backing => increased funding/chances of certifications. Rust is certainly miles ahead compared to C as a tool for building safety critical systems. In real world, organizations still need certifications from various authorities. It is a long road, but we can start, I hope!

(I posted about this before coming across this issue here: #264)

[eddyp]

* Request: [PowerPC e200](https://en.wikipedia.org/wiki/PowerPC_e200) core compiler support.
  The NXP [MPC5748G](https://www.nxp.com/docs/en/data-sheet/MPC5748G.pdf) and [MPC5744P](https://www.nxp.com/docs/en/data-sheet/MPC5744P.pdf) 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:

To support NXP platfroms with e200 cores, llvm will need to support the code-dense variation of the powerpc instruction set, VLE, because MPC57xxx MCUs are VLE only, but it seems there is no support for this, athough there have been some experiments (amybe just behind closed doors):
http://lists.llvm.org/pipermail/llvm-dev/2014-July/074613.html

If anyone wants to start, the offical info regarding the Book VLE ISA is in the PowerISA. I found a copy at http://fileadmin.cs.lth.se/cs/education/EDAN25/PowerISA_V2.07_PUBLIC.pdf

[avraliov]

Category: feature

Request: bits layout implementation like in Ada

Rationale: in Ada we can describe bits layout like:
Some_Record is record with
field1 : integer;
field2 : integer;
end record;
for Some_Record use record
field1 at 0 range 0..5; //bits layout
field2 at 0 range 6..7; //bits layout
end record;

Will be nice to have something like that declarative style in Rust embedded

[eddyp]

@avraliov I would rather have something less spread out like:

struct SomeRecord {
reg1:u8 bits{
f1:0..5,
f2:6..7,
},
reg2:u32 bits {
f3:4..17,
},
}

Or something maybe less verbose like:
struct SomeRecord {
f1:bits 0..5 in reg1:u8,
f2: bits 6..7 in reg1:u8,
f3: bits 4..17 in reg2:u32,
}
although I kind of dislike the repetition of the "in reg1:u8" part.

And in case of the regs >= u16 we would also need some endianess specifier since I've seen cases where the core was one endian but the peripheral was another, even middle? endian (byte order in u32 was 3412).

[Lokathor]

Category: Feature

Request: Make example-dependencies and test-dependencies be split up, instead of having both as dev-dependencies

Rationale: Tests usually want quickcheck or other std assuming crates, examples usually want to be no_std examples that demonstrate the use of the crate. Right now there's no way to handle this.

[eddyp]

@Lokathor For unit tests, you could run them on a different architecture than the target, I do that in C. Being able to do that same thing in Rust would be awesome.

[TeXitoi]

@eddyp That's doable https://github.com/TeXitoi/rusty-clock/blob/master/.travis.yml

[eddyp]

@TeXitoi OK, looks like what I wanted, but doesn't that explicitly require to mark in the Rust code which code is also runnable/testable on x86_64? I'm thinking the dependencies on arch specific crates such as cortex-m might make the generated code unusable otherwise.

What I mean it's that Rust code should be arch independent by default so I don't have to do any change or white listing in the code to be able to run unit tests on some other host, say aarch64 linux or x86_64 FreeBSD.

[eddyp]

Category: crate
Request: singleton! and other arch independent APIs in arch independent lib (instead of cortex-m)
Rationale: Starting or prepping for some other bare metal arch such as Cortex R52, Cortex A53, AVR or Power e200 would need similar constructs without pulling any of the Cortex-m specific code. It's just plain good architecture.

[TeXitoi]

@eddyp in the linked repository, you can see that I have a portable sub crate that can be compiled on any architecture, the main crate is device specific (depending on cortex_m{,_rt{,fm}}). The tests are run on the portable crate.

[Lokathor]

@eddyp my target has no std lib (EDIT: and no atomics, so even proptest with nostd doesn't work), so I can not build my examples at all if cargo is trying to build quickcheck.

https://travis-ci.org/rust-console/gba/builds/470340649

So, yes, i want almost all my tests to be built and run on a big beefy x86 machine with 50 cores and such.

[japaric]

Category: stabilization

Request: complete and stabilize the last bits of procedural macros (macros 1.2): crate level attributes and attributes on modules

Rationale: Right now DSLs that require whole crate analysis to work and want to support the stable channel (e.g Real Time for The Masses v0.4) are forced to expose APIs like #[attr] const MODULE: () = { fn foo() { /* .. */ } /* more items */ } that use const items as modules instead of supporting proper modules because attributes on module are unstable. Also, users should be able to write their applications against the DSL and split it across several files but that is not possible today because crate level attributes are buggy. Completing these two features would lead to more ergonomic DSLs that work on stable; they may also lead to stable DSLs for testing (AKA Custom Test Frameworks) that support no_std targets.