Rust Embedded Opportunities 2018

rust-embedded-2018.md

Thoughts on Rust and Embedded

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.

Competitors

• Vendor toolchains
• Arduino
• Mbed
• Platform.io
• 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 crates.io 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.

Opportunities

• 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 cargo.io 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 {
   #[repr(u8)]
   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
   },
   #[repr(u16)]
   x_angle: enum { 0..360 }, // 16 bits
   #[repr(u16)]
   y_angle: enum { 0..360 }, // 16 bits
}