Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
246 lines (185 sloc) 9.6 KB


  • How to best market embedded Rust on the website?

  • What needs to be done to get there? Tangible goals

  • What can be accomplished this year? Mind these dates:

    • April - July. impl Period. "Little to no design or RFC work will happen during this time."
    • August 2. Epoch in beta. Material for the website should be turned in by this date.
    • September 13. The Epoch and the new website are released.
  • rust-lang-nursery/embedded-wg: Re-use (migrate) rust-embedded/rfcs or create a new repo.

  • IRC channel for meetings / coordination: re-use #rust-embedded or make a new one?

  • Meeting time and format for next meetings

  • Project ideas for the Increasing Rust's Reach program

Action items

  • @japaric migrate rust-embedded/rfcs to rust-lang-nursery/
  • @japaric make everyone a collaborator
  • @japaric open issues for further discussion


A few members shared their thoughts before the meeting


Provide a consistent development experience for ARM Cortex-M, AVR, MSP430 and RISCV microcontrollers. This involves different levels:

  • Same tooling: Xargo Cargo, IDE support (VS Code + RLS), cargo flash, cargo debug

  • Same starting point: *-rt crates, Cargo templates, vanilla main, memory.x for memory layout.

  • Large set of reusable crates: embedded-hal drivers, other utilities like binary serialization, framing, math, etc.

  • Ports of multitasking models: RTFM (reactive + cooperative), Tokio-like (fully cooperative), threads (preemptive), etc.

Demo that Rust makes embedded development more correct (less bug hunting) and productive. This could be a walkthrough that involves building a non trivial application that involves a communication component and uses off the shelf crates from The development could be done in an IDE showcasing debugging, auto completion and tracing / logging functionality.

Highlight production users and applications made by the community (hobbyists)


What is it that we really want? At a broad level:

  • To improve the absolute quality (functionality, safety, performance) of embedded software in the wild.
  • To improve the productivity of embedded software development teams, by reducing the tangible and intangible costs of achieving a level of quality.
  • To improve the experience for programmers developing for embedded systems.
  • To make embedded systems programming more accessible for people that are not already embedded systems developers.


  • Vendor toolchains
  • Arduino
  • Mbed
  • AdaCore
  • C + Static Analysis + Valgrind + MISRA C
  • C++?

What do existing toolchains provide, and what does Rust have / need?

  • One-step install
    • Rustup
    • GCC Toolchain for GDB / LD (replace with LLD / LLDB in 2018?)
    • Xargo (integrate with Cargo in 2018?)
    • OpenOCD / Debugger Tools (future Bobbin-CLI development)
    • Rust Native Debugger Tools? (future Bobbin-CLI development)
  • Simplified project creation
    • Cargo Templates?
  • Integrated Development Environment
    • Single step build, deploy and debug (Bobbin-CLI)
  • Higher level system configuration / code generation tools like Processor Wizard / CubeMX
    • No exact equivalent, some of this can be replaced by Cargo and smart use of the type system.
    • System Definition Language as future extension to Bobbin-DSL?
  • Comprehensive HAL, BSP and Peripheral drivers
    • (Bobbin development has been focused on this, need to split out for early release)
    • Want peripheral drivers that can be used across multiple vendor MCUs
    • Prefer single crate per vendor MCU model, with vendor-common and arch-common crates as dependencies
    • Theoretically would like separate low-level and high-level crates per MCU but a big hassle
    • Board-level crates include specific configuration and board-level peripheral drivers
  • RTOS
    • IPC Primitives
      • Some in but want something curated and equivalent in quality to std
    • Cooperative and Preemptive Multitasking
      • Long term - common traits, multiple implementations?
      • Explicit Task Management vs. Futures
      • Learn from difficulties with Tokio + Futures - embedded devs would rather have less magic
    • Device Driver / Network Stack Architecture
      • Good progress on high level traits for I/O, need more implementation experience
      • Copy vs. Zero-Copy, Sync vs Async, different ownership models have different tradeoffs
      • Maybe look towards Linux / BSD driver APIs rather than traditional RTOS APIs
  • Stacks
    • USB
    • Bluetooth
    • Ethernet + TCP/IP
    • IoT protocols
    • Ideally, allow implementations of upper layers interoperate with lower level drivers. Need more implementation experience.
  • Specialized Libraries
    • DSP
    • Motor Control
    • Write Rust wrappers for existing libraries until native implementations show up
  • Advanced Tools
    • Advanced Tracing + Profiling
      • Make sure that Rust interoperates well with existing tools
    • Hardware Simulation / Emulation
      • Integrate with Unicorn for MCU emulation, maybe create Rust framework for peripheral emulation.


  • Encryption
    • Ensure that there is a curated ecosystem of no-std / no-allocator compatible crates
  • Robotics
    • Development teams are typically smaller and more agile, complexity high enough so that Rust is competing primarily against C++ / Python rather than C
    • Some areas (Autonomous Vehicle / Drones) have huge time-to-market concerns and younger teams that have been exposed to non-embedded systems development
  • IoT / Sensor Networks
    • Many IoT devices are too simple and cost constrained to be a good target (vendors don’t care about security issues and unwilling to innovate in firmware development) but there are more sophisticated devices that need to do analysis, particularly using deep learning
  • Safety-Critical / Mission-Critical
    • Long term goal, aim first at non-regulatory markets, leave hard-core until after further standardization
    • Focus especially on markets where embedded Linux is considered acceptable for deployment
  • Sandboxing / Application Distribution + Updates
    • Working on a #[no_std], zero-allocation WASM interpreter

Language and Tooling Improvements

  • Fix Linking Issues
  • Improve panic / debug / fmt bloat
  • Building and deploying C libraries
    • How can we make building and deploying Rust code for use in C projects even easier?
    • Is it possible to build a cargo like tool that will download and install a C header file and pre-compiled .a file from the main index? Can we make it just as easy as installing a header-only C / C++ library?
    • At least, better integration into existing build systems
  • Better c-like enum support ideas
    • #[repr(contiguous)] and #[repr(T, exhaustive)] to disallow gaps and incomplete enums
      • #[repr(T, exhaustive)] enables safe casting from T to enum
    • Numeric matches on c-like enums
    • discriminant-only enum items
      • enum Prescale { disabled=0, 1, 2, 3, 4, 5, 6, 7 }
    • ranges as enum items
      • enum Prescale { disabled=0, divider = 1…7 }
      • enum Nibble = { 0..16 }
      • matching on ranges
pub enum Hour { 0..24 }
pub enum Minute { 0..60 }
pub enum Second { 0..60 }

pub struct Time {
   h: Hour,
   m: Minute,
   s: Second
  • Bitfields
    • Pack c-like enums within structs
    • Focus on usefulness for HW, file format and network protocol developers rather than purely on C interop (which is broken for bitfields anyway)
pub struct Device {
   control: struct {
      power: enum { off=0, on=1 }, // 1 bit
      mode: enum { Shake = 0, Shimmy = 1, Squirm = 2, _Reserved = 3 } // 2 bits
      speed: enum { 0..16 }, // 4 bits
      rotate: enum { ccw=0, cw=1 }, // 1 bit
   x_angle: enum { 0..360 }, // 16 bits
   y_angle: enum { 0..360 }, // 16 bits


Consistent development experience

  • Tooling
  • Starting point: e.g. cortex-m-rt
  • Re-usablbe crates: embedded-hal drivers
  • Multitasking models: RTFM, Tokio-like, threads

Customer profiles

  • early adopters: hobbyists, researchers, startups
  • regular firmware developers
  • safety critical market

Focus on the first group, make progress towards the second group

One step setup++

Make it quickly for experienced users to get started

Succesful approach in std Rust: replace one C component with a Rust one

Big part of the ecosystem is not available on no_std -- Portability WG?

Opportunity market: developers with domain specific knowledge (robotics, CV, etc.) may not be familiar with existing C frameworks and may want to look for other options

Traditional RTOS: threads, tasks over them, well defined interfaces for communication

Vendor SDKs: "rubbish", carry too much legacy (makefiles), huge installers

Building state machines for embedded systems? -- generators

website: who's the audience? beginners in embedded dev? seasoned developers?

how Rust compares to C, MicroPython, JS on micros? What are the advantages? tooling, etc.

embedded development on stable

  • compete against stable vendor provided toolchains
  • may not be achievable, but try to reduce breakage: run tests in rust-lang/rust

check for code size regressions

remove panic strings

RISCV OpenOCD port isn't being upstreamed yet because debug spec hasn't been ratified by RISCV foundation yet

One RISCV silicon implementation (new one was announced at FOSDEM available July); Rust works on it but needs polish

Increasing Rust's Reach

  • Expanding the ecosystem. Join embedded-hal, writing examples

  • CI for embedded

  • CLI for testing (HIL?)