Usage in resource-constrained environments

[aturon]

Overview

Rust is a natural fit for programming resource-constrained devices, and there are some ongoing efforts to better organize work in this area, as well as a thread on the current significant problems in the domain. Embedded devices likewise came up repeatedly in the internals thread. It's also a potentially huge market. At the moment, though, it's far from clear what it will take to achieve significant production use in the embedded space. It would behoove us to try to get a clearer picture of this space in 2017.

Some potential avenues of exploration include:

• Continuing work on rustup, xargo and similar tools for easing embedded development.
• Land "std-aware Cargo", making it easier to experiment with ports of the standard library to new platforms.
• Work on scenarios or other techniques for cutting down std in various ways, depending on platform capabilities.
• Develop a story for failable allocation in std (i.e., without aborting when out of memory).

UPDATE: A recent survey performed in May revealed that currently the most pressing needs of would-be and current embedded Rust developers are:

• Target support. "The Rust compiler doesn't support my target device architecture". AVR, Xtensa and MSP430 were among the architectures that users requested Rust support for.

• A Hardware Abstraction Layer. A core set of APIs for doing embedded I/O (serial, I2C, etc.) that will serve as the foundation for building an ecosystem of drivers and hardware support crates.

• Documentation. How do I develop an embedded application? How do I do $CONCURRENCY_PATTERN safely in Rust? Examples of complete embedded applications.

• Crate ecosystem. Users want not only crates that provide support for X or Y device but also device-agnostic no-std crates (all the way from data structures to network protocols) where dynamic allocation is optional or not present at all.

• Discoverability. A single place where to find the current status of support for architecture X, device Y and development board Z, along with a curated selection of tutorials / documentation and a catalog of crates useful for embedded development.

Projects

• A proposed portability lint, which could help for embedded devices and failable allocation.

• Extending Rust support for microcontroller architectures.

  • AVR support is being worked on out of tree. Major blockers from landing this in tree are bugs in the LLVM backend that prevent compiling the core crate for this architecture.

  • MSP430 support. Support is in tree but some changes in rustc and LLVM are required to support all the variants of the MSP430 architecture. The base MSP430 target is in more or less good shape but its crate ecosystem and community are currently small. If you are interested on MSP430 microcontrollers comment on the linked thread.

• A Hardware Abstraction Layer. Currently in design phase. Join the discussion here.

• http://areweembeddedyet.com A site that tracks the state of the embedded ecosystem. Currently its contents are being organized.

[Ericson2314]

Not to harp my own RFC, but std-aware Cargo, should remove the need for xargo, right @japaric?

[japaric]

@Ericson2314 Yes. Xargo is the stop gap solution.

[Osspial]

Should GPU shader programming be considered at all when thinking about this? Right now, it's possible to an extent with tools like SPIRV-LLVM but my understanding is that it's not an easy thing to do.

[hanna-kruppe]

@Osspial Writing shaders using the full range of hardware capabilities, even "just" compute shaders, may require substantial language additions. Analogously to how embedded programs need volatile loads and stores for MMIO and placing data in specific sections or at specific addresses, a shader requires a model of the different kinds of memory (local, shared, constant, global) and a way to access to data passed to shaders in unusual ways (e.g., uniforms) — and let's not even go into the technical challenges of integrating the shader with the host program and ensuring the "ABI" (in a loose sense) matches. Depending on what kind of shader environment you target, you may also need to restrict some language features or radically alter the kind of IR rustc outputs.

I'm not quite saying it should be ignored — in fact I myself am currently working on issues closely related to this. But it's a large task with little overlap to classical embedded development, so this tracking issue may not be the best place for it. (cc https://github.com/tomaka/vulkano/issues/353)

[japaric]

Updated the issue to include the most pressing needs of embedded developers as identified in this recent survey, and added some on going community projects.