Rust Programming Language / Oxidize Global 2020

The Rust Programming Language has a lot to offer software developers: Memory Safety, Developer Convenience, and powerful static analysis tooling. However, introducing a new programming language like Rust into a Safety Critical domain for writing software for automotive, industrial, medical, or avionics purposes requires a high level of confidence, and a lot of regulatory hurdles.

This panel will discuss what makes developing software for the safety critical industry so different from other development areas, how Rust could be an improvement to the Status Quo of safety critical software development, and potential roadblocks Rust could experience on the way to a safety critical qualification. Join engineers with experience in a number of safety critical industries including compiler design, the automotive industry, and the testing and verification industry to discuss!

Ever wanted to know how the magic spell you always used to program that mystery ELF file onto your embedded target works? I did so in February 2019. This is the story of probe-rs, your magic spellbook to talk to embedded targets.

Close to a decade now, I have been working with embedded systems. While complaining about subpar tooling was always an option, stepping up and making better tooling somehow seemed impossible. One year ago, having no prior knowledge of this matter, I started to look into how debug probes and the debug interface of ARM cores works and how prior tooling, approaches this.

Today, we have a working library to interact with ARM and RISC-V targets. Of course we are not done yet. There is a plethora of embedded targets, bugs arise everyday and there is way more awesome functionality and tooling we want to provide.

This talk is the story probe-rs, giving you a little bit of the why, the how, the good and the bad and why you should use it and contribute to it.

Embedded Hardware Abstraction Layers (HALs) and other Rust frameworks work well for demos and prototype projects, but how do they hold up in real-world, professional implementations?

Stabilizer is an open-sourced hardware platform used for controlling lasers in quantum physics experiments. It offers a unique environment to exercise the usage of embedded HAL traits and the Real-Time For the Masses (RTFM) framework in a high-performance, internet-connected embedded system.

This talk will discuss the advantages (and shortfalls) of the both RTFM and the embedded HAL approach to Rust development in a real-world embedded application where timing, throughput, and internet-connectivity are crucial.

Optimizations are mainly known for

- making code fast,
- aggravating undefined behavior, and
- making developers suffer during debugging.


In the Rust compiler we have a scheme that allows us to optimize code without affecting the debug-ability while at the same time actually causing compile time speed ups. This talk first introduces the MIR, on which the Rust compiler does optimizations. Then various concepts are explained, which allow us to write idiomatic Rust and still getting performance that hand-crafted low level code can’t beat. Finally an outlook on cool-things-to-come ™️ shows how language-guaranteed optimizations can be leveraged in resource constrained environments.

D-Bus is a popular IPC mechanism used by various services on most desktop and many embedded Linux systems in the wild. It is heavily used by even the most essential services, such as systemd. Unfortunately, in the Rust world, there is only one D-Bus crate that is in a usable state and most users are not happy about it for various reasons, most notably that it depends on a notoriously bad C library. zbus, was created out of this demand for a pure Rust API that makes D-Bus easy and simple. With both elegance and efficiency as the top goals, the development of of zbus has been a much greater challenge than original anticipated but slowly they were all overcome.

Recently, zbus has actually started to take a good shape, with the foundational code already released and zbus nearing it’s first release. In this talk, I’ll go through all major challenges faced during the development of zbus and the solutions chosen, and give an overview of how one can make use of zbus.

If you have considered using embedded rust, you may have run into questions such as “What is embedded_hal, a pac and a hal implementation?”, “What is a driver crate?” “Where does rtfm/rtic and cortex_m fit into the picture?” This talk will give you an overview of what the crates are, how they fit together and why they exist which should give you a good place to start your embedded rust journey.

The use of embedded systems grows at an immense rate with 3 billion+ Cortex-M ARM chips shipped! However, someone has to write the programs that run on all these chips, where the trifecta of safety, performance and ergonomics comes as a wish, while in many applications an MCU hanging or crashing is simply not allowed. Currently the embedded Rust ecosystem provides the necessary foundational crates, but lacks the ergonomics and safe utilization of resources.

This talk aims to show that with Rust and the Real-Time Interrupt-driven Concurrency scheduler we get this trifecta, with how resources, memory safety, deadlock free and data-race free execution that can be guaranteed at compile time, no defining of thread stacks, and keeping the generated binary minimal without losing expressiveness! All built on a sound theoretical foundation of Stack Resource Policy.

ARM has shipped 100+ billion cores - let’s build the next 100+ billion on a strong foundation, ease of use and safe programs!

Writing a device driver can be a lot of work, writing a good one even more.

In this talk, we’ll explore some different styles of writing to and reading from registers and we’ll be weighing the pros and the cons. It will not conclude with a definitive best way, but hopefully it will give some ideas to use for the next driver you write.

The library discussed in this talk has also been publicly released since the talk was recorded: https://crates.io/crates/device-driver

Some microcontrollers are powerful enough to usefully run Machine Learning (ML) models on audio, motion or even image data. Even though the practical applications of this are not yet clear, there is considerable interest in Edge ML.

TensorFlow is a popular framework for training and running ML models, and there are good resources for training and miniaturising TensorFlow models. This talk is an introduction to using these models in an Embedded Rust project, and briefly walks through the process of instantiating a model, setting input tensors, running inference and reading outputs. We will use a Rust crate that wraps the C API, and this talk will outline how this crate works and how it catches many common errors at compile time.

For the past 15 years, Arduino has been the gold standard for introducing people to Embedded Systems and programming. This talk outlines 5 steps that Rust can do to increase “market share” in the hobbyist sector.

Some of these steps are already in progress and will require little extra effort. Others are not obvious and will require resources to be allocated to them. These are not traditionally core to the Rust project and would require alternative processes to be set up.

By doing this work, however, we can increase the visibility of Rust in the Embedded space and have more Rustaceans trying to increase software quality in a fast growing sector.

Making a USB device speak is a pain–Rust with a BeagleBone can have your device barking sooner than expected. Rust users often chant “We can have nice things”–and USB device development with Rust is absolutely nicer.
Each embedded USB stack is unhappy in its own way–a BeagleBone with Rust is standard Linux and all the tools that go with it.

Failures in an embedded USB stack often take down the entire board–Linux USB gadgets run in user space and Rust makes even userspace crashes far less likely. Host software development is hampered by a lack of device hardware and firmware–Rust can make the BeagleBone look like the USB device the host software developers need immediately. Unfortunately, all of this goodness is buried underneath a pile of prerequisite tasks that are neither particularly Rusty nor that well documented.

This talk demonstrates how to cut through the prerequisites and then gets down to the task at hand-decoding and creating USB packets with Rust.

Historically cryptography in the embedded space has been a disaster, but with the growing pervasiveness of “IoT”, a topic of increasing importance. Rust provides a great language for building secure embedded applications, and with it a great platform for embedded cryptography.

This talk covers two cryptography projects written in pure Rust:

1. RustCrypto (“2.0”): a multi-crate “embedded-first” GitHub organization with trait-based implementations of several cryptographic algorithms including AEAD algorithms (AES-GCM, ChaCha20Poly1305), digest algorithms (SHA-2, SHA-3, BLAKE2), elliptic curves (NIST P-256, secp256k1), MACs (CMAC, HMAC), and signature algorithms (ECDSA, Ed25519)

2. Veriform: cryptographically verifiable and canonicalized message format similar to Protocol Buffers, with an “embedded-first” (heapless) implementation suitable for certificates or other signed objects


Recorded at Oxidize Global 2020

Jack Greenbaum from Green Hills Software shares his experience with exploring Embedded Rust for use in functional safety systems at Green Hills Software. This includes the parts that are easy, a few rough edges for the end to end Embedded workflow, and recommendations for bringing Rust to the broader Embedded Systems market and Function Safety Systems in particular.


Interested in using Rust for safety critical systems? Reach out to us at sealed-rust@ferrous-systems.com!

James Munns from Ferrous Systems discusses updates on Ferrous System's Sealed Rust project to qualify the Rust Programming Language for mission and safety critical applications, including industrial, automotive, and avionics use cases.


Interested in Sealed Rust? Reach out to use at sealed-rust@ferrous-systems.com!